MetroGIS Project Proposal Template Version 1.0 1 MetroGIS provides an on-going opportunity for collaborative projects among its stakeholders. Crucial to the success of collaborative projects are the identification of clear project goals, deliverables, and the resources and personnel needed. This template is provided to assist stakeholders to identify and list the core information to shape and start a collaborative project. Part 1: Project Overview Project Title Project Description What is the goal of the project? What are the specific business needs to by satisfied by the project? See also: Business Case Template(s) completed for the project What are the deliverables? What does a successful outcome for this project look like?
MetroGIS Project Proposal Template Version 1.0 2 Part 2: Stakeholders and Resources Who are the stakeholders and/or beneficiaries of the project? Who is the Project Champion and what agency do they represent? Champion: A policy-level advocate from a stakeholder agency Who is the Project Manager and what agency do they represent? Manager: A stakeholder responsible for the delivery of the project Who is the Project Owner and what agency do they represent? Owner: A stakeholder invovled in the ongoing decisions, results and success Who would perform the work? Examples: Contracted vendor, stakeholder staff, specific agency staff, combinations of these listed, etc. Who are the Project Team members? Team: Technical and managerial staff that guide, shape and make functional decisions about the project. Is funding needed, if so, where would the funding come from? Please list approximate amounts and possible sources of funding.
MetroGIS Project Proposal Template Version 1.0 3 Part 3: Practical Considerations Does this project have policy implications? If yes, please explain: Is there a need for existing policies, practices or laws to change? Are there pre-requisites that must be met or satisfied? Is there research, background information or outreach that must precede the project? What is the anticipated deadline or lifespan of the project? Please indicate any/all relevant time constraints on the project. Does this project tie to other/similar projects or initiatives? What is the likelihood of success for this project? Very High, High, Medium, Low, Unknown Please include any other relevant facts or details about the project Please attach additional relevant research or supporing materials to this project
5/7/2014 Introduction MetroGIS Regional Project Proposal GIS Dashboard Application Dashboard applications have become commonplace over the past several years. The term generally refers to a simple, graphical representation of key indicators of data or processes (see examples). Dashboard Examples Indicators may be presented in a variety of forms using widgets which may include maps, graphs, charts, tables, and lists. Widgets can be integrated, sharing the same context, so a selection or query in one widget may impact related representations in other widgets. When used with geospatial data, a dashboard can help visualize multiple aspects of features as well as display them on a map. The map dashboard has great potential in a web environment by leveraging map services published by government agencies for other applications or simply as a mechanism for providing convenient access to data without the need for moving data around. Typical web mapping applications have tended to be narrowly focused on viewing and querying with a map display, a table of contents, and an attribute display. A dashboard can greatly expand the usefulness of public geospatial data already available and encourage others to publish more data in this way. As internal applications, it expands the potential users of GIS to those who are looking for a productivity tool that leverages GIS technology in a very
5/7/2014 focused way. This can be accomplished by developing a single JavaScript application that can be configured at run time to use a specific web mapping service. Objective Develop an application that provides advanced view and query capabilities through multiple linked widgets related to an ArcGIS Server REST map service including a map, a list, a summary count, custom query, feature attribute detail, and a pie chart. Each widget will support its unique interactive functions, which may be reflected in other widgets. Data sources for widgets can be a layer from the map service or the results of a query. The application will be configurable through a collection of variables representing a specific implementation of the application. Multiple implementations will use the same program files (not copies). The primary variable will be the active map service or web map and associated custom queries, and the general layout of widgets, including whether they are active or not. No programming or recompilation of specific implementations will be necessary to incorporate the configuration variables. Developed in JavaScript, this application will be available to anyone to set up and configure to access any public map services or internal map services for internal applications. The application will be developed as a software framework, providing a foundation for additional enhancements and extensions. For example, numerous JavaScript libraries exist for charting, graphing, and displaying tables. It should be relatively easy to add new libraries and associated supporting JavaScript code to replace or extend initial capabilities. The Esri Operations Dashboard The design of this application is largely based on the capabilities of a limited implementation of the Esri Operations Dashboard. That application is very rich in capabilities and options, which can be configured through a GUI interface, with options for users to configure the application themselves, creating their own personal variations. Configurations are stored as Operations Views in ArcGIS Online. Accessing Operations Views requires a named ArcGIS Online account. Named accounts are available from Esri on an annual subscription basis at a bundled cost of $17,500 per 100 users. This proposed GIS Dashboard Application is intended to be a low cost, entry level alternative, similar to the Esri Operations Dashboard, without the ArcGIS Online dependency. It will have fewer capabilities but can be deployed at a fixed cost associated with its development, not the number of users. Users who exhibit a need for advanced dashboard capabilities can be easily upgraded to the Esri Operations Dashboard, with the associated ArcGIS Online subscription, using the same map services used for this application. The core capabilities outlined in this document are demonstrated in the Esri JavaScript Samples online. Development of this application fits within the Esri JavaScript API license for internal and public non commercial (no charge) use.
5/7/2014 Cost Estimate Preliminary inquiries of potential commercial GIS application developers have led to an estimate of 200 240 hours to develop this application. At an estimated rate of $120/hour for a developer, this leads to a cost estimate of $24,000 $28,800. This estimate is entirely dependent on development of detailed requirements and level of effort necessary to achieve them. This application can be developed using an agreement similar to that which was used with the Address Point Editor, which was developed with the condition that it could be used by any government entity in the State of Minnesota at no additional cost. The developer retained the right to remarket the application to private companies and government organizations outside Minnesota. This may also be a candidate for an open source project, making it available to anyone, potentially engaging a broad development community. Development Methodology The Address Point Editor project is also a good model for developing this application. It employed an agile software development methodology of iterative and incremental requirements gathering and coding sprints. The initial requirements will be focused on core capabilities in a flexible framework. This can then be followed by iterations to add widgets. In this case, this methodology will work very well, maximizing available funding to create a flexible, extensible application that will support future enhancements. Project Team The MetroGIS Data Producer Workgroup, composed of the 7 County GIS Managers, and Olmsted County GIS Manager, which together form an 8 County IT Collaborative, support this proposal. A core team will be formed with representatives from some of those counties. Additional interested individuals will be recruited from cities and other Metro local government organizations to provide a broad perspective for defining requirements. References Esri ArcGIS Server REST API: http://resources.arcgis.com/en/help/rest/apiref/ ArcGIS Online Operations Dashboard: http://www.esri.com/software/arcgis/arcgisonline/apps/operations dashboard ArcGIS API for JavaScript: https://developers.arcgis.com/javascript/ ArcGIS API for JavaScript License Agreement: https://developers.arcgis.com/javascript/jshelp/terms.html
5/7/2014 Widgets (see diagram at end for letters referenced) Widgets represent specific component capabilities in the application. They can be added or removed from a specific configuration. Widgets generally share the same data context, thereby reflecting changes in the shared context through queries and selections. Widgets help the user perform basic data analyses by visualizing multiple aspects of a data context at the same time. Map (A) The map provides basic capabilities to zoom, pan, zoom to an address, and identify features. Clicking on a feature presents the attributes for that feature in a popup on the map (F). Maps can also have a user selectable base map service. Pie chart (B) A pie chart is configured to present a summary based on the value of a specific field. Each slice of the pie represents the portion of all records with a specific value. All values for the field are represented, based on the filter. Pie charts change when the map filter changes. Hovering the cursor over a slice pops up the value represented and the total number of records with that value. Multiple pie charts can be present in a dashboard. List (C) A list shows all records displayed in the map along with select attributes. The list can be scrolled up and down. Clicking on an entry in the list causes it to be highlighted in some way on the map. Corresponding map symbols for each record will be visible in the list, retrieved from the map service. Custom queries (D) Queries are presented as a series of criteria, allowing the user to set values for specific fields. The query operates within the context of the filter, with an option to limit the query to the current map extents. Query results are presented as an indexed display of record attributes with simple record navigation options to move to next, previous, first, and last records (G). Query results provide an option to highlight the selected records in the map. Displayed attributes are configurable, including alias names for fields. Summary count (E) The summary count reflects the sum, average, min, or max of the value of a specific field for the current records in the map. Multiple summary counts can be present in a dashboard. Filter (H) The map service can be filtered based on a specific attribute, which impacts other widgets accordingly, each displaying various aspects of the result set. A filter may be defined as mutually exclusive or as added to other filters (logical OR).
Dakota County Supportive Housing Dashboard 5/7/2014 C E H F A G A Interactive map B Pie chart C List D Custom queries E Summary F Identify feature G Query results H Filters B B D
Detailed Use Case: Dakota County Supportive Housing 5/7/2014 This Dashboard is designed to assist social workers matching clients with housing needs to available housing. The dashboard presents several aspects of housing at the same time. The map (A) shows dots representing registered housing providers with two symbols representing those with openings (orange) and those without openings (black). Users can pan and zoom on the map and zoom to an address to see available housing in a particular vicinity. They can click on a dot and get more information about the individual site it represents in a popup (F). The alphabetical list (C) of housing providers allows users to search or scan for available housing by name, then click a particular provider to highlight or zoom to it on the map. There is a running tally (E) of the current number of openings displayed at all times. This updates as filters and search criteria change, so that overall housing available is discernible at a glance. Similarly, the pie charts (B) provide a quick breakdown of housing providers by type and by licensor. Users are able to limit the providers shown on the map by applying a filter (H). There are filters to single out housing providers by housing program type or by licensor. The map, list, summary, and charts automatically update to reflect the filtered inventory. Complex querying capabilities are necessary to effectively match clients with appropriate housing. Custom queries (D) allow users to create subsets of housing providers by selecting criteria from a series of dropdowns. For instance, a worker may need to find housing that is available to seniors, wheelchair accessible, non smoking, provides 24 hr supports, serves DD adults, and accepts GRH+Rate 2 funding. Query results (G) can be paged through record by record, and can also be highlighted or zoomed to on the map. Although this is a very specific use case, it represents only one implementation of the capabilities of this application. Other government organizations will have the need for the same capabilities applied to other business processes. The application will allow these capabilities to be used for a variety of use cases. The following pages show examples that are variations of the same dashboard, simply reconfigured to display and query other Esri REST map services.
Land Conservation Easements 5/7/2014 Real Estate Foreclosure Sales
Subdivision Plat Review Process 5/7/2014 Photogrammetric Basemap Updating Process