MOOSE - Roadmap

# Moose

## Mapping Interface

##### Development Roadmap

###### Welcome to the MOOSE Browser Client development Roadmap. For up-to-the-minute answers to frequently-asked questions, click Here
The best types of Roadmaps contain historical notes and tips on points of interest. The Roadmap must keep integrating the present as it passes, or it soon becomes useless. It records design decisions their rationales. Such a Roadmap reflects unforeseen terrain unexpected inventions as they emerge, rather than starting from some (unrealistic) fixed architecture and proceeding through mundane implementation.

##### Brief History

###### This first version of a roadmap is occurring somewhat late in the development cycle. The hope is to keep this process up to date on a regular basis as new ideas come to bear on the project. A lot of great work has already occurred (and is occurring) in the development process. More and more functions are being set up to run autonomously and be less dependent on other chunks of code. This allows for a very flexible system of components that can be integrated at the developers’ leisure to achieve just the right client Interface.

##### Where we're Going

###### We're on our fourth iteration of the Code base, five if you count my ancient and anemic code that started it all. We now have a much more flexible code base, learning from the previous versions about what works and what doesn't. The new layout components are the most flexible to date functionally. The road ahead better supports the business needs of not just Public Works but other Departments in the City as well. Development of the code base has all but ceased for previous versions of MOOSE.
Moving more operations related to data upkeep to the owners is a primary goal of the development team. Automating these tasks for the data keepers is a high priority in the development Process. MOOSE2 started us down the path of letting the owners manage their respective datasets with few requirements, MOOSE3 will put more power and control into those hands.
The new server hardware will provide for much more reliability of service than the old (not that we've had that many problems with it) and ramps up the entire system as a City Wide Production Service.

##### Re-Introduction

###### This document will serve as a narrative roadmap for the MOOSE Browser Client development. It won't be a schedule, although schedules should be attempted that refer to the ideas and problems recorded and projected here. It will list the Rules and Design Principles we'd like to employ, to build on the value of the existing MOOSE interface, and its modularity. Major items of work will be listed. And it'll be updated over time.
Nothing (apart from the history) in this roadmap should be taken as irrevocable. Although we try to avoid unduly revisiting decisions, we welcome all developer comments and corrections. Much of the work done to date has a measure of controversy behind it. Just pass us your evidence and reasoning and we the MOOSE designers will change our course and this Roadmap to follow the actual events.

##### Design Principles

###### Here are the MOOSE road rules. Some items listed here are Concrete design decisions. We think they reflect sound ideas.

##### MOOSE the Client

- Design Decisions should be public. All development messages will be made public via . . . . <wiki link will go here>
- As much as possible UI structure should be implemented via XML and HTML. Style should be implemented using CSS. Structure that can be queried, modified, and superposed from remote sources should probably be RDF, expressed in its XML syntax. Actions should be implemented (or at least, be implementable) via well-defined events and their JavaScript handlers
- Modules will use <What goes here Duck?> to specify and query their programmatic interfaces. That way, all modules are scriptable without requiring all interface creators to write repetitive-yet-tricky script-engine glue by hand.

##### MOOSE data warehouse and data owners

- Data upkeep is left up to the individual dataset owners as much as possible.
- All datasets have an assigned owner for upkeep
- All publishing decisions are up to the data Owners, including frequency and accuracy of the data.
- All Styling of Published services are at the discretion of the data owners.

##### MOOSE System

- The System Administrators will be responsible for an initial install of a dataset for each dataset owner, the owner will be responsible for the subsequent upkeep of the data.

1. Future versions will allow for adding layers to the catalog via the Web.

- The System Operators will train the data owners in the process of publishing their respective datasets. The emphasis is on the Data owners managing their own data for publication.
- The System Operators will use a hands off approach to the data upkeep (unless they own the dataset) once a dataset has been installed and published.

##### MOOSE Services

- Services are to be kept discrete and purposeful.
- Each service has a specific Purpose and is implemented in as close to a standalone fashion as possible, with little or no dependencies on other services in order to function.
- Strive to build a system with no single point of failure for operation..

##### Major Work Items

###### Each of the following constitutes a major Milestone. This list is not ordered or express dependencies. It shall be refined to include Sub-Tasks and missing items of work. For now it's a rough list of projected things I think we'll be doing in the next few months.

##### MOOSE Client(s)

- Interface Layout, a user configurable interface as an end goal.
- Debugger for developers. Completed, but has many extensibility option still.
- Documentation for all aspects of project to be completed first as code base comments and later as user readable formats.
- Look and feel (skinning) of interface upon completion of MOOSE 3 Build.
- User Selector Toolset developed (and added to over time).
- Report generation

- Address Labels
- User definable SQL report requesting.
- Spatial report query. Thematic Mapping.
- Spatial Query Builder based on Free form selection tools.
- Address Assignment Certificate generation.

- AutoCad Importer. Partially Completed.
- Arc Importer. Awaiting Development Sponsor.

##### MOOSE data warehouse

- Additional outside dataset acquisitions (to be owned by System Operators).

- Weather Maps.
- State, (neighboring) County and Municipal Data.

- 3D data Formatting Partially completed.

- Importer for AutoCAD, Proof of Concept completed.
- Browser Proof of Concept Completed.

- Pictometry added as dataset (and Service)
- State CARS system Integration (and new corresponding Service)

##### MOOSE System and Data Owners

- More Control added to the Owners capabilities

- Popup Styling Control.
- Popup Lookup and Feel and Positioning.

- More option for downloading of Report outputs.

- Excel Output
- Comma Seperated.
- Formatted Text.

##### MOOSE Services

- Print Canvas Service.
- 3D Service (Mirage)

(C) 2006 City of Saint Paul, All Rights Reserved.
Updated: Nov 2, 2006
Note: This page is optimized for Mozilla Firefox 1.5+