Google Maps API or the VirtualEarth API? From a developer’s viewpoint
I came across an interesting blog post by the Redfin developers about their experience with moving from the VirtualEarth API to the Google Maps API. That got me thinking about my experiences with both the APIs. I am not going to be talking about whose imagery looks better or has a higher resolution here. But, as a developer, I should say that I actually prefer the Google Maps API over the VirtualEarth API. For most cases, both the APIs are really to use and are comparable in their feature sets. But here are something in the Google Maps API that I miss in the VirtualEarth API.
- The TileOverlay feature in Google Maps is present in the form of a custom tile layer in VirtualEarth. The GroundOverlay feature in the Google Maps API is absent in VirtualEarth. Wouldn’t this feature come in handy?
- The Google Maps API exposes their shape drawing and editing API but VirtualEarth doesn’t. This is a BIG one for me. Almost a MUST have. I don’t understand why the shape drawing and editing functionality available in live maps is not exposed in the API. I also love the vertex editing functionality and its usability especially how easy it is to insert a new vertex in a polygon.
- The latitude/longitude encoding feature in the Google Maps API is a nice to have feature and will help save bandwidth. The GPolyline factory method helps create geometry overlays straight from the encoded string. Try out the encoding here.
- The getLength and getArea functions on GPolyline and GPolygon are good enough for most cases where accuracy is not real important.
- Google maps API provides static methods to handle XML documents and fragments (GXml) and methods to apply Xslt to Xml (GXslt). The VirtualEarth API doesn’t contain any such equivalents.
- The geo-coding functionality in Google Maps also has added functionality like
- A client side geocode cache.
- Ability to set an extent within which to geocode using the setViewport function on the GClientGeocoder.
- Geocoding via HTTP requests.
- A useful set of utility libraries for the Google maps API.
- The StreetView is currently only available in google maps
Did I miss anything else either with the Google Maps API or the VirtualEarth API?
Subscribe
Follow Me
Contact me
I tend to agree that Google has quite a few more features than Virtual earth, but here are 2 in the other direction:
Virtual Earth has multipoint routing, Google does not.
Virtual Earth has the Bird’s Eye View. (Same goal as the street view, entirely different, perhaps inferior, approach)
[...] does a great job of listing what he is missing from the Virtual Earth API. Many ESRI users are exposed to these differences in the ArcGIS [...]
Adam, actually the Google Maps API does have multi-point directions (GDirections.loadFromWaypoints)
I stand corrected, thanks for the info.
I agree that Gmap has more features than VE…
Did you ever test your 10000 lat/long points to overlay …..
I believe, you would give up on Gmap…. VE is an excellent solution, in terms of showing large datasets ….
None of the Gmap functions are really super helpful except methods like GXml …..
Abhi – I don’t believe that VE handles large datasets better than google does. VE may be marginally better but the differene is not considerable at all. And I have found that adding > 200 points to any map canvas makes the map unusable. If do have the need to show large number of points, i either cluster them on the server-side and show only some of them on the client or add them to the map as a tile overlay (the ground overlay can also be used if needed).
Vish
FYI-
Our default marker class (GMarker) is designed so that it works well across-browsers, has hot spot shape, can be draggable, has a shadow, prints well in any browser, etc. It is not optimized for performance.
Developers who wish to overlay many markers (and not invest in clustering – which I agree increases usability) can create a custom overlay. There’s an example that compares performance here:
http://gmaps-samples.googlecode.com/svn/trunk/manymarkers/randommarkers.html