I'm about to start a Google map based project and am wondering if the release version of GMaps v3 has most of the features that are available in v2, or if it would be best to stick with v2 for now.
Is there anywhere that has a list of features in v2 that are not built into v3 yet - and features of v3 that are not in v2.
Personally, I'd avoid using v3 for live sites until it comes out of Google Labs unless you gain a significant advantage from the v3 features.
APIs in Code Labs may change at any time as they evolve. They are also not committed to the 3 year deprecation policy, and Google's obligations with regards to testing and bug fixing are more lightweight.
That's not just theoretical. The change of the get_ and set_ syntax only ran in parallel for a few weeks. Because v2 is a mature product, syntax changes that break large numbers of existing pages are avoided. If you do go with v3 you have to remain attentive to the possibility of future page-breaking syntax changes.
V3 releases end up having to be pulled back significantly more often than v2, that could be partly due to lightweight testing, but also because there's no equivalent of a v2.x release. v3 code goes directly from "Google internal testing" to "live on all v3 sites" in one step.
I'm using v3 for hobby, I've made a small project which allows you to add markers, measure distances, add polys, save maps and realod... I've found that v3 is faster than v2 with many markers (less than 100, without any clustering), and I've found simpler to add markers and customizing the icons. But, often, the guys in google changes the rules... so if you're starting a real job, I suggest to use v2, or you will have to always check if everything works.
Related
I am about to start a new project which will be used about 80% through non-mobile devices like desktops and laptops and 20% through mobile devices. And yes, I want to use KML capabilities too, use JQuery for all my JS work and do not want users to download any plugin separately.
I have implemented two projects already using Google Maps API blissfully unaware of Google Earth API. Now I started reading about the two and nothing is clear about what is the right choice. I even referred to posts on this site so please do not mark this as a duplicate.
Google's documentation on Google Earth API states:
Welcome to the developer documentation for the Google Earth API. The Google Earth Plugin and its JavaScript API let you embed the full power of Google Earth and its 3D rendering capabilities into your web pages. Just like in the Google Maps API, you can draw markers and lines—but in 3D!
Well, with that statement from the horse's mouth, it confused me even more. Why would anyone use Maps API then. Can someone with experience in both these tools, give some definite statements for the specific environment I have described? The earlier posts do not give convincing answers.
I believe when I last looked Google Earth support in the browser is implemented through the use of Web GL which will severely limit your browser support and I think eliminate mobile devices.
While Earth may be prettier Maps is more performant and arguably stable and I would think it would be the logical choice for you in this case.
This page contradicts some of this but requires the use of a plugin which you specify you do not want.
For information on using KML layers with the Maps API see here.
Here is how I understand the situation.
There were two similar but different products co-existing for a long time:
2D Maps born on web
3D Earth born on desktop and brought to the web as plugin.
This caused a lot of confusion.
It would be beneficial to unite the two, but that only became possible recently with WebGL.
Last week Google released new Maps having Earth integrated.
Unfortunately, I was not able to find any documentation about this integration yet.
But, still, my answer is: use Maps and eventually you'll get Earth for free.
As the Google Maps JavaScript API Version 2 has been officially deprecated as of May 19, 2010. The V2 API will stop to work after May 19, 2013.
Does all the applications which we have develop using V2 going to stop after May19, 2013 and we have to migrate these to V3 before this?
I don't know if google has expressly said that they will remove the API and assets from being able to be used, but I do know that after May 19, all bets are off, they are free to take down the API and any/all assets that are required to support v2 at any time without notice, so it's kind of an "at own risk" deal.
It's time for you to migrate over....v2 has been deprecated for years and v3 is very well supported.
It's not ridiculously hard to migrate over, you can probably keep the majority of your existing codebase and just call a few different functions.
For instance, all of the original functions that you used to call like this:
new GMap2()...
new GMarker()...
new GLatLng()...
Have all been namespaced, so their equivalents in v3 would be:
new google.maps.Map()...
new google.maps.Marker()...
new google.maps.LatLng()...
Any time you'd be using services, however, like StreetView or DirectionsRenderer, you'd need to check the docs on that because those have changed slightly.
You'll have to chase some bugs down as you go through, but the docs are very very well organized and you shouldn't have that much trouble.
Best of luck!
Here's an easy guide on how to do the upgrade: http://gabrielduque.wordpress.com/2011/01/13/upgrading-from-google-maps-api-v2-to-v3/
I manage the development of some academic web mapping software for authoring collections of geographic data. It's a fairly simple interface for creating historic maps. The project is based on Google Maps v.2, and because v.2 is going to be discontinued in 2013, we thought we'd bite the bullet early and upgrade to v.3.
It turns out that's a big job that requires completely rethinking how the map part of our application works. We have to rewrite all our custom Gmap controls, restructure several parts of the application, and a few other big changes--for example, v.3 doesn't integrate with Google Earth as well as v.2, and we use Google Earth a lot. Because of this, and because we're starting to use more features that Gmap doesn't support natively (like WMS maps), I've been wondering if it might be worth switching from Gmap to OpenLayers. From what I understand, OpenLayers has all the features of Google Maps, has native support for WMS and supports many more data formats, lets us use all the Google imagery anyway, and works with KML.
My question to the community is for people who know OpenLayers and Google Maps: can you give me an idea of how the workload for upgrading from Gmap v.2 to v.3 compares to a complete port from Gmap v.2 to OpenLayers? And what other downsides should we be aware of?
One of our biggest concerns: we use Google Earth a lot. If we went to OpenLayers, we'd have to synchronize Earth and OpenLayers ourselves, but it sounds like that's what we'd have to do in Gmap v.3 as well. From what I've read, OpenLayers doesn't have native support for Google Earth or any kind of 3D geobrowser, but there are some projects (like this) that try to bridge the gap. How much of a headache would this be?
Very interesting question!
Upgrade to newer version of Google Maps should be less time consuming because you already have working code and even though you make will have to make big changes you should be able to reuse some parts of the codebase. That's only my guess, because it's hard to be more precise without seeing the code :)
You should still take a look at OpenLayers. You mentioned that you already need WMS support and probably there are more features out there that OpenLayers supports and Google Maps doesn't. OpenLayers supports a wide variety of datasources, is open and follows OGC standards. It has support for Google Maps, and if you one day decide to change to Bing, Yahoo or your own maps you will only need to make minor changes to your code.
I was in the same situation. I took a look at openlayers and started implementing some of the functionality in openlayers. I was able to replace SOOOOO much google maps api code with just a few lines in openlayers. So i kept going, in no time i had re-developed in openlayers and cut down the javascript required to do so by more than half! I am also able to do much more! exporting, importing from all sorts of formats is now just lines of code rather than man lines. OpenLayers all the way!
My map project needed an update this month and when i referred gmap i saw the notification requesting to migrate to version3. This is from may 19th 2010.
There are three projects live which used gmap extensively.
Those projects are for Transportation department in which we have plotted a route for a bus service with many options.
What will be the problem if i let the existing projects be as they were. that is in version 2.
I would like to have suggestions for the above.
From the Google Deprecation Policy:
"For a period of 3 years after an announcement (the “Deprecation Period”), Google will use commercially reasonable efforts to continue to operate the Deprecated Version of the Service and to respond to problems with the Deprecated Version of the Service deemed by Google in its discretion to be critical. During the Deprecation Period, no new features will be added to the Deprecated Version of the Service."
http://code.google.com/apis/maps/terms.html#section_4_4
So you are probably good to keep using it for awhile - but eventually you will need to update.
Note that V3 is not guaranteed to be compliant with IE6, which is the reason why I am temporarily holding off on updating my own applications.
If v3 has all the features you need, then go with v3.
I want to know if anyone who has experience of using both the Google Maps API and the Multimap API can give a good reason as to why one is better than the other - or maybe a list of pros and cons?
I will be working on a complete re-development of a site which currently uses the Multimap (Classic) API and want to consider the possibility of using Google Maps API instead of Multimap (now MS Bing), but I need a compelling reason to justify this decision.
The site currently provides a search mechanism allowing users to search for addresses using postcode/partial postcode or city. The current system has a sqlserver database back-end containing full address details and also uploads (geocodes this information to Multimap with a daily scheduled task). I'm wondering if it's possible with the Google API to avoid the need for the daily upload and just use it's geocoding API instead (though this is limited by Google's restriction of a certain number of geocoding requests per day).
In my experience using the two, Bing Maps are more accurate with regards to their geocaching, but Google have slightly nicer looking Road Maps.
The Google Maps API is slightly more helpful - for example, if you have 2 markers, the map automatically zooms out to the right level, Bing takes a bit more work.
Aerial maps look pretty much the same on both, as do the Hybrid maps.
My advice would be - use Bing maps for geocaching, then if you want really nice looking road maps, use Google. If you're using Aerial, Hybrid or Birdseye view, you might as well stick with Bing.
According to Wikipedia Multimap was purchased by Microsoft some years ago and its direction features were merged into the Microsoft Bing api. I suppose the Multimap API primarily exists for legacy purposes. By the end of 2010 multimap might disappear, so this is definitely a compelling reason to re-write the geocoding part of your app...
In any case I would contact Multimap how long they plan to support their API and if there is a migration path (probably to bing maps).
Bing Maps as well as Google Maps now offer real-time geocoding services over Javascript (see http://msdn.microsoft.com/en-us/library/ff710027.aspx for an example in bing). Which one to pick? Check the terms of usage and the costs of the geocoding requests per day.
Yes skip the old legacy Multimap and use Google Maps or Bing Maps. Both are in active competition and under active development. So one might be better in one area for a few months but the chances are it will change. Eg. Bing Maps was the first with multi-touch support (using Silverlight) but Google Maps now supports it with its v3 API. (unfortunately all but the most basic map overlays will crash Google Maps multi-touch apps crash with the most widely available multi-touch platform: Safari on the iPad/iPhone).
At the moment I think Bing Maps has the edge, but at the end of the day your decision is probably going to be subjective (those maps look nicer / I find the API slightly nicer / etc), or depending on the exact wording of the EULA (ie. do you pay? and how much? for your specific application).
You talked about geocoding. An increasing number of people are looking at using multiple geocoding platforms. Primarily because geocoding coverage of all the services are imperfect, but it also gives you cover if one service goes down.