In the international space, use of opensource Web GIS has quickly expanded in recent years. However, there are still significant barriers to delivering web-based GIS products to potential users within related decision-making windows. This gap in the opensource ecosystem is readily apparent in humanitarian decision-making (from strategic decisions about funding to tactical decisions on how to get X aid to Y location).
With cloud-based infrastructure, big data, streaming data, and OpenStreetMap, we can develop some pretty neat applications. For many questions from customers, the necessary data is out there. However, we struggle to match our production cycle to quick changes in the data environment or to real-world shocks (e.g., Earthquakes, Ebola, etc.). When we do succeed, it is commonly with narrow product lines. The hardest questions require rapidly integrating heterogeneous datasets and presenting some value-add when we don’t know all the inputs a priori. It’s harder to handle “acceleration” in the information environment than “velocity”.
It’s harder to manage “acceleration” in the information environment than “velocity”.
Given a shock (natural disaster, conflict, or economic), if decisions are getting made in 4 hours, you can’t wait 1 week (or even 8 hours) to hear back from a customer on your proposed color scheme or datasets for an online map.
For the last 5 years, most Web GIS developers have been essentially stuck between 2 bad options when trying to operate in that small decision-making window.
First, you can try to use modern libraries and platforms like Leaflet, C3, MapBox, etc. to produce a beautiful dashboard that meets your customer’s needs. In most/all efforts, you never get it right the first time and it takes weeks/months of back and forth. A new singular product line that can handle high-velocity data and deliver timely visualizations might be worth it, but the cost is high.
Second, you quickly produce an online map with a current snapshot of data. It’s nice, gets a little traction on social media, might be used for “general situational awareness”, but never jumps the barrier to tangible operational use.
There are some exceptions, but not many.
To really have “Spock in the boardroom”, as DJ Patil says, we need to shrink the time from question to answer (read: visualization). And not just for a one-off, but as part of a reliable feedback cycle with customers.
- Image at http://geodash.io/GeoDash.png
GeoDash enables developers to rapidly create new online web maps and visualizations. GeoDash accelerates the production cycle to match the decision-making cycle. By itself GeoDash doesn’t solve data pipeline issues, bureaucratic impediments, etc, but can be part of an effective workflow. Software development (“development cycle”) is only part of the overall production cycle, but is traditionally the least responsive (read: days not minutes).
What is GeoDash?
GeoDash is a modern web framework and approach for quickly producing visualizations of geospatial data. The name comes from “geospatial dashboard”. It’s still under development and can be considered in alpha stage (so lots of bugs to fix and features to add).
I’ll quickly discuss what’s in the the stack. Then, I’ll discuss the benefits of 2 key components. Then, I’ll discuss how this leads to an insanely fast development / user feedback cycle.
- Image at http://geodash.io/geodash_gulp.png
Gulp (http://gulpjs.com/) is a streaming build system. Unlike a “static” build system (e.g., grunt), gulp can be adjusted during runtime. The ability to dynamically inject content into the pipeline enables recursion which consequentially enables a distributed plugin architecture. We’ve also used angular events to enhance the distributed nature of the platform, but it all starts with using Gulp.
- Image at http://geodash.io/geodash_yaml.png
YAML is a data exchange format that is disrupting existing paradigms of system architecture in multiple areas. For example, JKAN (https://jkan.io/) is an open data portal built on Jekyll and YAML. YAML is nearly fully-translatable with JSON. It is machine AND human readable. With supporting libraries for multiple languages (pyyaml, yamljs, etc.) your configuration files can be seamlessly interpreted by the frontend, backend, AND developers, which makes powerful functionality much more accessible to users. The entirety of a GeoDash dashboard can be reduced to 1 configuration file, easy to understand for users, developers, and all the code in-between.
GeoDash, with the use of YAML and Gulp, provides a very pleasant development experience. With the modularity provided by Angular and enhanced by Gulp, you can very quickly customize existing components or create new ones! In seconds, you’ve created a new component, added to the build, and deployed to production. The modularity also reduces errors, since individual features are self-contained.
This insanely fast development cycle allows developers to adapt dashboards to the needs of customers in seconds/minutes rather than going through a traditional long development cycle with gathering requirements, business plan, feedback, development, code review, etc. Sometimes the most basic modifications are what hold up use of a dashboard, such as colors, text size, missing layers. With GeoDash, you can quickly move past the small stuff and focus on the real use cases. You can incorporate customer feedback during a meeting instead of weeks later.
“Incorporate customer feedback during a meeting instead of weeks later.”
The only public implementation of GeoDash is available at http://demo.geodash.io/dashboard/test, but hopefully more will become available soon!
How to contribute?
Let us know what needs fixing or improving in GitHub Issues or #geodash on Twitter. See the list of repos at http://geodash.io/.
Second, you can fork the code base and create new plugins and features. GeoDash was built to be extremely extensible.
GeoDash is still under development. If this is something you’d be interested in contributing substantially to, get in contact on Twitter or elsewhere!