One of the most useful references for me in this process was a workshop Tom Carden gave at ETech last year on the data rendering capabilities of a variety of approaches. The readers digest version of the workshop went something along these lines:

HTML/Javascript – handles 100-1000 data points – loads in .1 seconds
Flash – handles up to 10,000 data points – loads in 1 second
Java/Processing – handles up to 100,000 points – loads in 10 seconds
OpenGL – handles upwards of 1,000,000 points – loads in 100 seconds

For Maker we wanted to be able to handle 10,000+ points/polygons and there was no way JavaScript was going to be able to handle it. Of course rendering the data was just one of many problems. Not only did we have to render the data but also parse it from the server out to the client while running the mathematical operation enabling you to take advantage of the structured data being sent. The team came with lots of clever tricks to pull it off, but the level of performance afforded by using Flash for rendering the vector data was not available with JavaScript. Processing could be a very cool option as the technology matures. Silverlight could also be a great option if they can get the plug-in universally embedded into browsers as with Flash.

While Flash was a great option for the tiling and vector rendering we did not want to build out the entire application in Flash for a variety of reasons. In GeoCommons everything outside of the map itself is JavaScript/HTML. This is probably rudimentary for many folks, but reading the debate on James’ blog I think sometimes developers lose sight of picking the best tool for the job. Oftentimes it is easy to get wedded to an approach just because it is what you know well. We were complete Flash rookies when we started, but got some great help from Tom with Modest Maps, Axis Maps with the Flash development and cartography, hired some full time resources, and learned a lot on our own. It ended up being a great approach for the specific problems we were facing. As long as you are using standard interfaces in your development, you should be able to fluidly adapt to the technology that makes the most sense for your set of problems.

Yahoo Maps

Microsoft Virtual Earth

Google Maps

When it comes to cartographic design I would rank it 1) Yahoo 2) MSVE 3) Google, which should not be too surprising since Yahoo! hired a bunch of cartographers to design theirs. Since Yahoo! unveiled their new cartography, Google has introduced terrain view and MSVE has added elevation reliefs to their maps as well – although I cannot for the life of me find a reference to when the upgrade happened.

While the race for more content, and sometimes more cartography, has raged amongst the big three providers, there has been a backlash in the developer community. This was most poignantly seen in Paul Smith’s “Take Control of Your Map” article on A List Apart. As you can see in the screen shots above, the base maps from Google, Yahoo and Microsoft have become pretty crowded and dense. Many Web designers would like to control the design on their maps the same way they do their Web pages leading to a movement to “roll your own maps”.

This movement has leveraged the pioneering work of OpenStreetMaps to create their own independent base maps for streets. The OSM effort led to creation of applications like Mapnik and Osmarender to style the GPS data they collected for the project, although both are some what notorious for their lack of usability. This has not stopped EveryBlock from using Mapnik to make custom maps for their data.

The map is definitely less busy than the big three providers, and I believe suits EveryBlocks purposes well, although I might have gone with a different color combination. The beauty, though, of EveryBlock’s approach is that if I wanted another color sequence, I could take Mapnik and OSM data and have at it. I believe it is just one of the many examples we’ll see democratizing cartography – allowing the public to “roll their own”.