"(a) No "Wrapping." You must not create or offer a "wrapper" for the Service, unless you obtain Google's written consent to do so. For example, you are not permitted to: ... (ii) create a Maps API Implementation that reimplements or duplicates Google Maps/Google Earth. For clarity, you are not "re-implementing or duplicating" Google Maps/Google Earth if your Maps API Implementation provides substantial additional features or content beyond Google Maps/Google Earth, and those additional features or content constitute the primary defining characteristic of your Maps API Implementation."
No, this applies to client-side libraries. OpenLayers required a specific letter from Google saying the terms didn't apply to them (but will apply to others).
Complex? For some certain tasks perhaps it's verbose, but I do like that the API is structured in a Java-like way.
With wrappers like these I need to constantly consult the docs to find out what arguments to pass to the constructors.
With the google maps api I just create a new object and can use the various setters and getters to set and retrieve values. Everything is mostly self-descriptive as well.
You can place an extern file so that you can get additional help via intellisense in an IDE as well.
Personally, I don't like the Java smell. GMaps.js is more idiomatic JS; I have no problem remembering props to pass in to a method, but can never keep straight a bunch of classes and getters/setters. And I prefer building abstractions over relying on IDEs; being able to go back and change some keys/vals is more maintainable to me than having to go back to a bunch of explicit methods, with all their quirks and gotchas.
ugh, I was hoping we were moving past the "smells like Java" kneejerk objection. It doesn't apply here. Maybe you don't use the Maps API very much? It (v3, at least) actually strongly embraced being a Javascript API in a time when most APIs were not. Almost all objects are created with options specified almost exactly the same way as here. The main thing this seems to add is being able to specify event handlers in the same way (that really does appear to be the majority of the code).
It does look lighter to use, but that's just the age-old difficulty of writing an API that's both lightweight when it needs to be and completely flexible when it needs to be. You'll run into the same problem with this library, but in the other direction, if you need more than one click handler on something, or you need to use the underlying MVC structure directly, etc.
edit: it's a minor thing, but not having to create a LatLng object every time you need one is nice on the code verbosity scale. That's one of the first things I alias when making a project with the maps api, actually. Lots of "new"s in your code isn't unidiomatic Javascript, though, even if some wish it were :)
Maybe it's not a "smells like Java" but from Google's perspective, they treat every api method with equal weight because so many people use different parts of it. GMaps is trying to solve the simple use cases where the other 80% of the api methods are unnecessary.
If you need something specific and you're building something beyond the typical google maps customer, then you'll have to use the google standard apis, but most people would be happy to use something simpler.
Completely agree. It's really pretty easy. The main problem is that it's ugly in places and some things you may want to do are downright impossible (such as separating the results containers from address autocomplete from the input to create a mobile interface. You have no way to get at the results json. The only option to do that is to proxy their HTTP API through your server because JSONP is no longer an option.
I really like that the interface is generic, abstracting away the mapping service. This way it may be possible to write bindings to other mapping services, such as OpenStreetMap or Bing Maps, and switch the service by just changing a variable.
There's OpenLayers too (http://openlayers.org/). Google Maps or Bing Maps are one of the possible layers. Works well for GIS-type folks, has some quirks otherwise. Don't like the layer switcher myself however, not very strong UX wise.
Yeah, using OpenLayers here too-- I was about to say almost the exact same thing. My PM is one of those GIS-type folks; I'm not, and there's some frequent pain. I've actually been messing with layer switching this morning, we have our own control UI for it. The native OL controls are generally pretty lame (especially compared to GMaps). We're progressively throwing out most of them, opting for a different direction that fits more with our filtering/search features.
Code-wise, I've found OL pretty awkward. It stinks of Java to me: over-organization, unnecessary complication in the name of feature completeness, confusing function sigs, overuse of `new`, etc. Feature-wise, I have little to complain about, but GMaps.js's look a lot more idiomatic and nicer to write code against, though I bet there's still comparatively a lot missing...
It was born as a jQuery plugin for a couple of projects we had to use Google Maps and that incidentally used jQuery as well, so it made sense.
We aren't totally sure it will move forward as an independent Javascript library but it's certainly a turn it could have. We are rewriting it with Coffeescript now, so maybe is something to consider more closely.
Has anyone compared this to Leaflet[1] or Mapstraction[2]? Leaflet was a big help on a quick project, but the abstraction was somewhat leaky and there were annoying bugs switching between maps.
While I respect the work done by the Mapstraction guys, I found that to get several non-trivial things working, I had to dig into the proprietary parts of the individual underlying framework - which defeats the purpose of using Mapstraction in the first place.
I had to rewrite large portions of the map interface code when I switched from Google to Open Street Map.
That said, the project is still young and maybe once I get some time, I should really contribute code to it to get those bits I needed working.
I does not. You have access to a, albeit limited, number of requests to to Geolocating, Geo-referencing and others. Should be no problem for a personal or small project.
Also nice is this JQuery plugin by Shawn Allen that uses simple html and data attributes to generate basic maps. Very useful if the maps are just supplemental, because they can be just built out in a template: http://prag.ma/code/htmapl/
Not really. Demonte's is a much thinner wrapper and have a totally different API. This is a brand new (and nicer to use IMHO) solution to the same problem.
Disclaimer: I commited the "staticMapURL" method to gmaps.js
The gmap3 and also the one on google code(forget name) seem to have a larger API, for example I really like the "DirectionsRenderer",I don't see anything like that gmaps.js.
https://developers.google.com/maps/terms 10.2(a):
"(a) No "Wrapping." You must not create or offer a "wrapper" for the Service, unless you obtain Google's written consent to do so. For example, you are not permitted to: ... (ii) create a Maps API Implementation that reimplements or duplicates Google Maps/Google Earth. For clarity, you are not "re-implementing or duplicating" Google Maps/Google Earth if your Maps API Implementation provides substantial additional features or content beyond Google Maps/Google Earth, and those additional features or content constitute the primary defining characteristic of your Maps API Implementation."