I, for one, don’t begrudge Google the chance to charge for their excellent product.  What that does, however, is make certain business models that were previously viable now unviable.  That is, if they remain with Google Maps.  In my previous post, I went over some alternatives.

The company I work for, after evaluating all the alternatives, including paying Google for a license, has decided to go with Mapquest.  While the API is not as gorgeously documented (both on the company site and on the web), it has the same licensure as Google Maps used to (free for any publicly accessible website), with much of the same base functionality.

I’ll be very interested to see how many people are doing such high value work with Google maps that they can afford to pay for licenses or per use.

Alternatives for javascript map generation:

• bing, though they only offer 500,000 mapviews/year
• Mapquest, which recently announced no mapview limits (other than for service degradation)
• OpenStreetMap, which has a number of vendors which use their geodata (CloudMade, Chitika, MapQuest).  If you want to use OpenStreetMap tiles directly, make sure you follow their usage policy and cache them.

Google Maps has made mapping ubiquituous (I’m sure Brian Timoney would agree), and in doing so has done the web a great service.  It will be interesting to see what happens as they try to charge for this service.

The v parameter within the http://maps.google.com/maps?file=api&v=2 URL refers to the version number of the Google Maps API to use. Most users of the API will want to use the current “Version 2″ API by passing the v=2 parameter within that URL. You may instead obtain the latest release (including the latest features) by passing v=2.x instead. However, be aware that the latest release may not be as reliable as the v=2 release. We update the Google Maps API often (sometimes every week), at which point features within the v=2.x release are migrated into the v=2 release unless problems are discovered.

If you want to know exactly what version of code you are pulling down when you put a ‘v=2′ on your maps javascript load, view this API changelog page on the google maps wiki.

FRUGOS (Front Range Users of Geospatial Open Source) is holding its
first GeoSummit on Saturday, June 16th at Churchill Navigation–100
Arapahoe–in Boulder.

This will be a unique gathering of a variety of folks interested in
Place–geo-types, hackers, academics, artists, amateur enthusiasts,
etc. While there certainly will be representation from the GIS and open
source worlds, we encourage all who are fascinated about the
intersections of technology and engagement with the world around us to
participate.

Also, we’ll be structuring the day around the “un-conference” model (see
http://www.barcamp.org), so, for starters, you
can expect:
No Pitches
No PowerPoint
No Passivity (unless you’re a little sleepy after lunch)

Bring your laptop (we’ll have wireless), and a project or enthusiasm
you’d like to talk about with the group, get feedback, and collaborate
on fresh solutions: the agenda of the day will be structured during
the morning registration/sign-up/socializing period.

If interested–
1) RSVP by joining the Google Groups set up for this event–

http://groups.google.com/group/geosummit

2) Bring a laptop (and cellphone/GPS if your enthusiasms tilt that
way), your idea/project, and willingness to collaborate

3) Spread the word

Tentative Schedule

9:30-10:30AM Registration, refreshment, socializing
10:30-12ish Sessions
12ish-2 Lunch (there’s a grill, beverages, and hiking trails)
2-? Sessions

This promises to be a great combination of creativity, intellectual
engagement, eating and drinking, and socializing.

————————

[tags]barcamp,gis,unconference[/tags]

I decided to upgrade this map last week to version two. Since openInfoWindowXSLT is no longer supported on every browser, I feared that the upgrade would take significant effort, even though the map very simple. However, the upgrade ended up being easier than I thought it would be. To get started, I read the Google Upgrade Guide–this document explains just what changes were made in the API. The changes that affected my map included:

• A few method name changes–centerAndZoom becomes setCenter
• GPoint is no longer used to indicate a latitude and longitude location on a map, and its replacement, GLatLng, reverses the order of the constructor’s arguments.
• Zoom levels are flipped around, with larger numbers now signifying higher resolutions
• The biggest effort was modifing the code not to use the XSLT process for generating infoWindows. However, this was easier than I thought it would be. I simply wrote a javascript method that mimicked what the XSL had previously done. Sure, accessing the DOM elements was a bit of a hassle that required some debugging (that’s the win of XSL–declarative DOM access), but the alternatives were either ignore browsers that don’t have built-in XSLT support (Safari) or integrate AJAXSLT, a Google sponsored project to provide cross browser XSLT support. If this were a larger project that depended on more XSLT, I probably would have done the latter.

Upgrading my (admittedly very simple map) took about 1.5 hours. Visit the new map and take a look at the code.

[tags]google maps upgrade[/tags]

The good: first, the ordering was easy, and I received my custom PDF (complete with “Prepared Exclusively for Daniel Scott Moore” as a footer on every page) in less than 20 minutes. Scott explains in a very easy to understand fashion how to create a map. He also covers each of the API’s javascript objects and how to use them. In particular, I thought the list of events and objects that fire them (in the ‘Events’ chapter) was a good reference. Now, Google provides a class reference, but Scott’s are a bit easier to understand here’s a comparison, for the Gmarker class:

Google API:

A GMarker marks a position on the map. It implements the GOverlay interface andthus is added to the map using the GMap2.addOverlay() method.A marker object has a point, which is the geographical position where the marker is anchored on the map, and an icon. If the icon is not set in the constructor, the default icon G_DEFAULT_ICON is used.

After it is added to a map, the info window of that map can be opened through the marker. The marker object will fire mouse events and infowindow events.

Davis’ Book:

In the Core Objects section, we introduced the GLatLng. A GLatLng stores a Latitude / Longitude coordinate, but it doesn’t offer you a way to visualize it on a map. A GMarker is the way to add GLatLngs GMarker to the map for display purposes. The GMarker constructor takes a GLatLng as the only required argument.Once we have the marker, we need to tell the map to display it; map.addOverlay(myMarker) should do the trick. (Objects that you superimpose over the map are called Overlays.) You can remove the Overlays marker using map.removeOverlay(myMarker). To remove all overlays, use map.clearOverlays( ).

var myPoint = new GLatLng(38.898748, -77.037684);
var myMarker = new GMarker(myPoint);
map.addOverlay(myMarker);

Theoretically a map can support an unlimited number of markers, but anecdotal evidence suggests that performance starts to slow down significantly after a hundred or so markers. (File under, “Doc, it hurts when I do this.”)

I liked the real world examples–the fact that you could click through and see the code Scott was writing about in action on his website is a real plus. In addition, he builds a decently complex example in Chapter 7 where the user can add and delete cities. He also gives a good warning about examples that use Gmap, rather than Gmap2.

However, there were some issues. Scott’s coverage of the upgrade to version two of the API is, unfortunately, rather spotty. In his blog, the June release of that feature, and the April revision of the book). He also doesn’t cover GDownloadURL, a convenience method for XMLHttpRequest processing, or the GUnload methods. I’ll freely admit that the maps API is a moving target, and some of the omissions above may be due to that.

However, there are other problems. Though billed as a beginner book, he omits what I consider to be one of the fundamental challenges of Google Maps development–the performance obstacles large numbers of database driven markers (other than the comment mentioned above in the GMarker reference). In addition, he doesn’t cover design options, nor cross browser issues (like the transparent PNG in IE issue).

In the last chapter, he mentions good examples of mapping websites, but Scott omits references to useful websites–something that even dead tree books do. In particular, he doesn’t mention mapki.com (a wiki full of useful user provided data) nor the Google Maps group (which some users consider a primary differentiator between Google and Yahoo Maps).

One final gripe is that the 75 pages of content that I expected were really only 45–text only filled about 60% of the column width. I expect that in articles I read for free on the web, but in books that I pay for, I like a bit higher content to page ratio.

In short, this ebook is a good choice for the first time Google Maps builder. This is due to the tutorial nature of much of the book, the examples, and the explanation of typical good javascript code, such as using anonymous functions for the event handlers. It is not entirely adequate in covering version 2 of the API, possibly due to API changes, and it ignored some of the more complex aspects of the API.

If you’re looking for a folksy introduction to Google Maps api, it’s worth the $8.50 to have a coherent guide. If you’ve muddled through one google maps project, piecing together things from the API docs and various blogs, it becomes less worthwhile. But if you want some kind of discussion about complex Google Maps issues this document is not the right place to look.

[tags]Scott Davis, Google Maps, Pragmatic Fridays[/tags]