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.
MetroGIS Project Proposal Template
Version 1.01
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?
What are the deliverables? What does a successful outcome for this project look like?
See also: Business Case Template(s) completed for the project
GIS Dashboard Application
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.
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.
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. However, that application requires an ArcGIS Online Organizational Account for anyone who wishes to use it. Although those subscriptions can be cost-effective on a limited basis and a certain number of them are included with Esri desktop licenses, when a single configuration is intended for use by a large number of users, it is less cost-effective. Further, the Organizational Account prevents the application from being deployed for public applications. This proposal would overcome those issues and create a fixed cost model based on development and maintenance costs distributed over many
organizations.
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.
Owner: A stakeholder invovled in the ongoing decisions, results and success
MetroGIS Project Proposal Template
Version 1.02
Part 2: Stakeholders and Resources
Who are the
stakeholders
and/or
beneficiaries
of the project?
Who is the
Project Owner
and what agency do they represent?
Manager: A stakeholder responsible for the delivery of the project
Who is the
Project Manager
and what agency do they represent?
Champion: A policy-level advocate from a stakeholder agency
Who is the
Project Champion
and what agency do they represent?
Examples: Contracted vendor, stakeholder staff, specific agency staff, combinations of these listed, etc.
Who
would perform the work?
Team: Technical and managerial staff that guide, shape and make functional decisions about the project.
Please list approximate amounts and possible sources of funding.
Who are the
Project Team
members?
Is
funding
needed, if so, where would the funding come from?
Anyone and everyone, that is, all MetroGIS stakeholders able to deploy the application or utilized deployed applications, including but not limited to cities, counties, private companies, and the general public. 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.
Randy Knippel, Dakota County Office of GIS
Randy Knippel, Dakota County Office of GIS
Randy Knippel, Dakota County Office of GIS
The project team would develop the requirements and retain an application developer knowledgeable in the Esri Javascript API, interactive mapping applications, and developing Javascript application frameworks.
Randy Knippel - Dakota County, project lead
Mary Hagerman - Dakota County, GIS, JavaScript, user perspective Trent Huber - Dakota County, Lead Software Architect, programmer
Tony Mosour - Scott County, JavaScript programmer (worked on MetroGIS Address Editor application) Keith Anderson - LOGIS - JavaScript programmer, city services perspective
Tami Maddio - City of Eagan, GIS Coordinator, city perspective
$28,000 estimated cost for contracting with a reputable, experienced Javascript contractor. Estimate based on 200 hrs. programming time at $125/hr. and 20 hrs. project management/design at $150/hr. 100% funding is requested through MetroGIS regional project budget. No other funding sources are known at this time, although there is potential for partial funding by other interested parties.
Is there a need for existing policies, practices or laws to change?
MetroGIS Project Proposal Template
Version 1.03
Part 3: Practical Considerations
Does this project have policy implications? If yes, please explain:
Is there research, background information or outreach that must precede the project?
Please indicate any/all relevant time constraints on the project.
Are there pre-requisites that must be met or satisfied?
What is the anticipated
deadline
or
lifespan
of the project?
Does this project tie to other/similar projects or initiatives?
Please include any other relevant facts or details about the project
What is the
“likelihood of success”
for this project?
Very High, High, Medium, Low, UnknownPlease attach additional relevant research or supporing materials to this project
no
no
2 - 5 years, depending on unknown potential for Esri to address apparent shortcomings in their ArcGIS Online business strategy as it relates to providing similar applications and the costs associated with deploying them (e.g. Organizational subscriptions requirement and costs).
Conceptually, the Address Point Editor project is 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.
High
5/7/2014
MetroGIS Regional Project Proposal
GIS Dashboard Application
Introduction “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 very5/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).
5/7/2014 Dakota County Supportive Housing Dashboard
A
F
H
C
B
B
D
G
E
A –Interactive map B – Pie chartC – List D – Custom queries E – Summary F – Identify feature G – Query results H – Filters
5/7/2014 Detailed Use Case: Dakota County Supportive Housing 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.
5/7/2014 Land Conservation Easements
Real Estate Foreclosure Sales
5/7/2014 Subdivision Plat Review Process
Photogrammetric Basemap Updating Process