views:

259

answers:

5

I'm doing some research for a Maps project I'll be starting soon, and I'm trying to evaluate which of the Map APIs will be best-suited to this project. I've worked pretty extensively with the Google Maps Javascript API, but no others. My basic requirements are, in no particular order:

  • Free: as in beer, not necessarily as in speech.
  • Web-based: Javascript, Flash/Flex, Silverlight, etc. are all okay.
  • Long-running and stable: the map needs to be able to live in a browser for days/weeks/months without gradually consuming too much memory or other system resources.
  • Fast: The map absolutely must be able to plot thousands of points (upwards of 10k points) with ease. Every few seconds I need to be able to update a small number of these (say, changing their color).

Other things I'd like to see:

  • Flexible: the Google Maps JS API is a good example of this. Basically this leads to lots of good things like numerous third-party plugins/extensions, and puts a lot of power in the devs' hands.
  • Well-documented and supported: again, the GMap JS API is a good example. If I'm going to start working with a new, rich API, I'm going to need to be able to find answers.

As of now, I'm inclined to use the Google Map Javascript API since I am familiar with it. However, the question of whether or not the Flash API might be able to handle many points more efficiently and gracefully prompted this SO question.

So, what have you had good or bad experiences with? Based on my criteria, which API would you recommend? I'm sure there are good ones out there that I just don't know about.

A: 

No matter which implementation you choose, you'll probably need to use server-side clustering if you want to display 10k points. Even the Flash API won't be able to handle that many individual points (non-clustered).

Chris B
A: 

I've used OpenLayers in a project. It's a JavaScript API, but we were trying to use it via an incomplete/unsupported GWT wrapper - not an experience I'd recommend. As an API itself OpenLayers isn't too bad. It does have a few issues (such as consuming right-mouse clicks and converting them to left clicks, from memory), but was under active development. I'd say it's not as slick as Google Maps, but it did have the advantage of being able to host your own map server.

If you're willing to use a Java applet, you could try using GeoTools.

Ash
A: 

I'm a fan of Google Maps for their incredibly thorough documentation and resources, as well as the general ease of use of the GMaps API.

Also, if anybody can scale (and optimize code to meet high demand), it's Google.

Dan Beam
+2  A: 

The Google Maps Javascript API has problems with your third and fourth requirements, unless you do some clever stuff to work round the problems.

(3) In badly written browsers (e.g. MSIE) a constantly updated Google Map will gradually require more and more memory. If you're careful to remove all references and event handlers on objects that you don't need, then in browsers with goof garbage collection routines, I believe that it is possible to write a page that will run for days, but not in MSIE.

The workround is to have a timer that does a complete reload of the page at regular intervals, using GUnload() on the way out to tidy the memory as much as possible.

(4) 10,000 GMarkers on a Google Map is out of the question. The number of GMarkers that you can get away with before the browser becomes unacceptably slow and uses 100% of the CPU varies depending on your CPU power and the browser. MSIE6 becomes unusably slow with a few hundred GMarkers, Google Chrome will cope with a few thousand.

The usual workround is to create tiles like the ones that Google uses for its GLayers. Because you're updating them every few seconds, you'd have to create them dynamically using a server-side graphics library like gd or ImageMagic. Display them on the client with a GTileLayerOverlay. Use GTileLayerOverlay.refresh() to call for an update.

The browser will attempt to cache the tiles and defeat your attempt to fetch new ones. In your case, the best solution is probably to arrange for your server to set the http headers to instruct the browser to never cache the tile images.

It also raises the question of whether the memory used to hold old copies of the tile images gets released properly. I've never heard of any reports on that, so you should probably do some experiments before you get too far into developing your project.

Mike Williams
`badly written browsers (e.g. MSIE)` :D
Rakesh Juyal
A: 

I talk about my reasons for using the Google Maps API in this answer.

Cannonade