The intention is to embed a small Google Map into a Web site, on which the user can click to pop up a full map. A target location should be indicated by a marker. The map size, type (Map, Satellite, Terrain), zoom, and centering should be specifiable.
My original plan was to capture a screen shot from Google Maps, complete with their copyright, and make that image a link to the full map. This does not seem to be permitted by Google's Terms of Use. As I've discovered, though I'm a strong proponent for structured information, there's nothing as simple as having a static image capturing exactly what I want, which won't "break" sometime in the [near] future!
HTML for embedding a map directly in a Web page can be obtained from the desired http://maps.google.com map via Link to this page / Paste HTML to embed in Web site.
This example shows Google headquarters (1600 Amphitheatre Parkway, 94043). Customized map size, type, zoom, and centering were specified using Customize and preview embedded map from Link to this page.
One problem with this solution is that the marker location is off by several hundred yards (as of 2008-01-15). Compare it with the correct location in the full size map (View Larger Map). This is due to the Tele Atlas data (which is used for embedding and API access) being less accurate than the NAVTEQ data (which is used for the main GoogleMaps.com site).
Another problem is that the InfoWindow bubble obscures part of the map. Though it's not too bad here due to the centering chosen in this example, drag the map to see how bad it could be for a location where having the target in the lower left was more appropriate. There appears to be no way to omit the InfoWindow via URL parameters. Closing it during customization is not reflected in the resulting HTML.
KML (Keyhole Markup Language) files allow specification of overlays for Google Maps. A marker for an address or coordinates (latitude, longitude) can be specified in a KML file which can then be displayed by Google Maps. The hope had been that a KML file could show the location without having the InfoWindow included.
For example, here is the KML file for Google headquarters. This was obtained by: mapping "1600 Amphitheatre Pkwy, 94043" at Google Maps; using Link to this page and copying the link to the address bar; appending "&output=kml" to the address; and going to that address. A window pops up asking where to open or save the KML file.
The KML file can then be used to open a Google Map by specifying the KML file URL as the q (query) parameter in a Google Maps URL. This has the desired lack of an InfoWindow, however, I could not find a way to integrate it with the embedded mapping facility using an IFrame.
The API is impressive in scope and organization. The main reason it's less than ideal for my Web site design use is the requirement to track changes to the API. Specifically, the Google Maps signup page states "If we make a non-backwards compatible change, we will give you at least a month's notice to make the transition, during which both versions of the API will be available." My clients would not be happy if the maps on their Web sites stopped working in 30 days.
This example, again, shows Google headquarters with the customized map size, type, zoom, and centering. The API makes this trivial to create. Clicking on the map pops up a new window with a full size map.
In this case, the marker location is correct, 'though its determination was reverse engineered, which may not stand up to improvements in the Tele Atlas latitude,longitude mapping.
This solution uses only basic parts of the API. The hope is these are fairly stable and less likely to be changed in non-backwards compatible ways.
Using the API, as above, requires: (for the small map) the target location, the map center, the zoom, and the map view type, and (for the large map) the Google Maps URL.
Use the determined values to replace the corresponding ones in the API example.
Sometimes, Google Maps does not map a known street address to the correct location, where "correct" is defined by looking at the satellite image which contains the known location, e.g. the green marker arrow doesn't point to a known building or other feature.
The process of overlaying the marker on the map requires determining the latitude, longitude of the target from a street address (geocoding), and then locating these coordinates on the map. There may be additional parts of the process, e.g. determining a street address from a business name (is this also part of "geocoding"?), overlaying street/terrain graphics onto the map, and registering the satellite image. Inaccuracies in any of these steps may contribute to location discrepancies.
Google currently uses two completely separate sources for map data: NAVTEQ and Tele Atlas. The NAVTEQ data is used at the main Google Maps interface. It is more accurate much of the time. The Tele Atlas data is used for map embedding and the API. Use of two sources appears to be primarily a licensing issue.
Geocoding is [approximately] the process of determining the latitude, longitude of a given street address. Geocoding is integrated into mapping at the Google Maps user interface. It is separated in the API, allowing different geocoders to be used for different purposes. The process of geocoding results in latitude, longitude coordinates, and is thus, theoretically, independent of any underlying map data (NAVTEQ vs Tele Atlas).
There are separate geocoders in use for the Google Maps user interface and the API. They are available, respectively, by typing in an address at the Google Maps user interface and specifying an address parameter to http://maps.google.com/maps/geo?q=1600+Amphitheatre+Pkwy,+94043&output=csv&key=<key>. In the latter, replace the query here, which is for "1600 Amphitheatre Pkwy, 94043", with the target street address, and the <key> with a valid Google Maps API key. The output will be "csv" (comma-separated values) for: HTTP status, accuracy (8=address level), latitude, longitude.
In theory, geocoders should map the same address to the same latitude and longitude. It is an involved process, and, currently, the one at the Google Maps user interface seems to do the better job (and better now than it did even a few months ago). Google Maps now allows end users to correct (Edit) mappings via the user interface. This provides the geocoder with additional hints to assist in accurate locating. This hinting may be used by some of the geocoders and not others.
Currently (2008-01-15), the geocoder at the Google Maps user interface maps "1600 Amphitheatre Pkwy, 94043" to 37.421861,-122.083962, as seen in the first screen shot below. That has been "corrected" by an end user (via Edit in the InfoWindow UI, not shown) to 37.423088,-122.085099, as seen in the second screen shot below. You can see the Show original option, which is how I found the original coordinates above. The geocoder available at http://maps.google.com/maps/geo maps "1600 Amphitheatre Pkwy, 94043" to 37.423111,-122.081783, as seen in the third screen shot below.
These locations are several hundred yards apart. (I've pasted the scale into the third screen shot for reference.) Though one could argue that they're all within the property at 1600 Amphitheatre Parkway, I've noted similar discrepancies at other locations, where a property is off by half a block or more.
Once latitude and longitude coordinates for a location are known, they must be located on the map. This should be an exact science, though perhaps not a trivial one depending on what projection ("flattening" of the surface of the Earth, an oblate spheroid, onto a 2-D map) is used. I believe NAVTEQ and Tele Atlas both use Mercator projection.
The NAVTEQ and Tele Atlas systems currently do indicate the same point on their respective satellite images for latitude and longitude.
It is possible to compensate for any mapping inaccuracy by determining what coordinates need to be specified to obtain the desired map image. However, as Google and its affiliates continue to improve mapping accuracy, such "compensations" may end up incorrectly adjusting correct results.
Using coordinates given by latitude, longitude wherever possible should provide consistent locations in the various map data.
A list of URL parameters is available at Mapki. Here are a few notes I made along the way: