Is anyone in the GIS community trying to publish choropleth web maps with a large (10s to 100s of thousands) number of polygons? and if so what's your current approach and what are the shortcomings of that approach?

My company is thinking about reviving an old project, but would like to get a sense of the demand before we invest too much time in something that may not be needed.

Features of the service would include:

  • Support for millions of polygons.
  • Ultra fast updates (recolor the maps in < 1 second, our goal is 60ms).
  • Realtime query support (mouseover or click a polygon to display it's info).
  • Bring your own data (upload your own shapes, classifications, etc)
  • Built in Census Data (all census layers and data preloaded)
  • Web access (no coding required)
  • API access (REST API with clients in Python and Javascript to start)
  • Overlay (display your published maps as overlays in Google Maps, Bing Maps, Open Layers, etc)

The core of this system is already working, but it would be a pretty major push wrap it in something useable. We're unsure at this point if there is enough demand to justify the effort. My apologies in advance if this isn't the appropriate forum for this sort of question.

closed as primarily opinion-based by Devdatta Tengshe, Radar, whuber Jan 30 '14 at 17:56

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • This is not a comment on demand for your service, but one on features of an ideal choropleth map: The area of each region (polygon) should be directly proportional to the denominator of the ratio (fraction) being mapped. That is more stringent than the usual "only map ratios, not totals". – Martin F Jan 30 '14 at 21:35

At work we did a project for a customer that needed millions of polygons. It was other requirements that pushed us to CartoDB, but it handled millions of polygons fine.

The customer is hosting their own instance of CartoDB because the amount of data they're using made CartoDB's plans too expensive.

That said, self hosted CartoDB setup is a real pain, so if your solution can alleviate that then there might be a market for it.

Not the answer you're looking for? Browse other questions tagged or ask your own question.