If your data does not exceed a certain size, the browser does a great job in rendering the data and taking care of the interaction. Just download the feature geometries to the client using GeoJSON, KML, or some other vector format, and use SVG or canvas to render the geometries.

But if you try to map all deaths in the Iraq war, show election data in a choropleth map or display a large number of buildings, then rendering your features inside the browser does not work that well any more. For several reasons: First, it will take some time to transfer the whole vector data to the client. Then, rendering gets slow and your map does not feel that responsive any more when panning or zooming.

So at this point you will do the same as you (or someone else) did with your base map: You will render your geometries on the server-side and serve the data as image tiles. But with plain images we are loosing interactivity! We still want to be able to click on features and we want visual feedback when hovering a feature, so that we know where to click! So, that is what this post is about: How do you preserve interactivity when using feature tiles?

In the following we will take a look at three different web mapping applications that use tiles for displaying features and we will compare the different approaches taken to make these tile layers interactive.

Google Fusion Tables

Google Fusion Tables is a service that lets you upload large sets of tabular data. The data can then be visualized using different kinds of charts, but you can also show your data on a map.

For example, this is a table with all counties of the USA. To get a map with all counties, you just have to hit Visualize » Map. The counties are rendered as red dots that you can click on. If you zoom in a bit further, the counties will be shown as polygons.

Image tiles

Now let’s try to understand how it works! The features are rendered on transparent tiles that are fetched just like the tiles of the base map. For example this is the URL for tile (3, 5) at zoom-level 4:

http://mt0.google.com/mapslt?
  lyrs=ft:210217
   |s:select col4 from 210217
   |h:false|uit:AIGcsfM_tVdc0DJ2ucYf0FrsPlxv22KwIA
   |t:1307554407
  &x=3&y=5&z=4
  &w=256&h=256
  &source=maps_api

Line 2 (lyrs=ft:210217) contains the ID of the table, the query that selects the geometries is in line 3 (select col4 from 210217). The information about which tile is requested is in line 6 (x=3&y=5&z=4).

Interactive markers

So much about the tile images. But how does the browser know on which areas of the images you can click on? At the beginning, when the map is displayed for the first time, the Google Map client library just fetches the tile images. But once you start hovering the map with your mouse pointer, the client will dynamically request position data for the tile that you are just hovering. For example a request can look like this:

http://mt0.google.com/vt/ft
  ?lyrs=ft:210217
   |s:select col4 from 210217
   |h:false|uit:AIGcsfNfL6pLSANzTVnbSlwncVdo-FccYA
   |t:1307632793
  &las=tuvt
  &z=3
  &source=maps_api
  &callback=_xdc_._bgopuz14u

The request looks similar to the tile URL, but the tile coordinates (for example: x=3&y=5) are not passed in clear text. I guess the coordinates are either encoded in line 6 (las=tuvt) or in line 9 (callback=_xdc_._bgopuz14u). The response for this request was:

_xdc_._bgopuz14u && _xdc_._bgopuz14u([
 {
  id:"tuvt",
  base:[295698432,668991488],
  zrange:[3,3],
  layer:"ft:210217
    |h:false
    |s:select col4 from 210217
    |t:1307632793
    |uit:AIGcsfNfL6pLSANzTVnbSlwncVdo-FccYA",
  features:[
   {
    id:"4:6113019567",
    a:[0,0],
    bb:[-4,-4,4,4]
   },
   {
     id:"4:6113167168",
     a:[-25165824,-2097152],
     bb:[-4,-4,4,4]
   },
   ...
  ]
}])

If the tile contains features, they are listed in the features attribute (line 11). Every feature has an identifier (id:”4:6113019567″), a position (a:[0,0]) and a bounding box in pixels relative to the position (bb:[-4,-4,4,4]) that marks the area you can click on. The feature position is probably relative to the tile position (line 4: base:[295698432,668991488]). And I am not really sure what unit Google is using for the coordinates, pixel coordinates or some real world coordinate system?

Interactive polygons

So the clickable area for points features is a rectangle, which works fine for small symbols. But for polygons and lines a rectangle would be too imprecise. That is why the response for a tile containing polygons or lines looks a bit different:

_xdc_._1kgooi20ar && _xdc_._1kgooi20ar([{
  id:"tuvuuv",
  zrange:[5,5],
  layer:"ft:210217
   |h:false
   |s:select col4 from 210217
   |t:1307550131|uit:AIGcsfOMgmq2ezQxiAgCamH-DAbYFlDFfA",
  features:
   [
    {id:"4:6112682473"},
    {id:"4:6112987488"},
    ...
   ],
  raster:"?A?A??ED?ED?ED?ED? ... D@B@wD@AEGD?D@"
}])

You still have the feature list, but now only the feature identifiers are given. Instead of feature positions you have this weird looking string in line 14 (raster:”..”). This string contains information about which feature was rendered to which pixel. At first, this sounds like a lot of data, but there are not many responses larger than 10 KB (gzipped). Unfortunately there is no information available about how this works in detail, but our next application uses a very  similar approach.

Mapbox: TileMill

Our next example is the tile server TileMill based on node.js and developed by DevelopmentSeed. First, let’s take a look at this beautiful map made with TileMill using OpenLayers as mapping client:

Like Google Fusion Tables, TileMill uses two different files for feature tiles: the tile image and a JSON file containing information that makes the image interactive. The JSON file is also loaded on-the-fly when you hover a tile. But unlike Google Fusion Tables, TileMill is an open-source project (GitHub: mapbox/tilemill), so that we can actually see how it works.

UTFGrid

For TileMill the format of these JSON files is specified in the MBTiles specification (MBTiles: UTFGrid). For example this is the JSON file for tile (7,10) at zoom level 4 (the strings in line 3, 5 and 6 were shortened):

grid({
  "grid":[
    "                !!!!!!!!!!!!!!!    ",
    ...
    "         )))))))))(((((((((((((((((",
    "          )))))))(((((((((((((((((("],
  "keys":[
    "",
    "GBR",
    "IRL",
    "IMN",
    "FRA",
    "GGY",
    "JEY",
    "ESP",
    "PRT"],
  "data":{
    "ESP":{"ABBREV":"Sp.", ...},
    "FRA":{"ABBREV":"Fr.", ...},
    ...}
});

The JSON string contains three main attributes: grid (line 2), keys (line 7) and data (line 17). The attribute keys contains a list of all feature identifiers and the optional attribute data can be used to provide additional information for a feature (for example the country name).

The attribute grid is a bit more interesting. It is an array of 64 strings where as each string contains 64 characters. So we have got an 64×64 grid of characters. If we map this grid to our 256×256 pixel tile, we see that each character stores the data for 4×4 pixels. So a character contains the encoded feature identifier, if a feature was rendered to the corresponding 4×4 pixel area.

The following graphic shows the original tile and a screen-shot of the grid array displayed in a text editor and resized to match the 256×256 pixel tile. As you can see, the shapes look very similar.

A cell of the grid does not directly contain one of the identifiers given in the keys list. To keep the amount of data low, the identifier is encoded. For example, let’s assume the user clicks on Spain, somewhere in the lower right corner of the tile. To get the feature identifier we have to do the following:

• We do a lookup in the grid using the pixel coordinates and get the character “(” (for example in line 6).
• Now we take a look at the UTF table and see that the character “(” equals the codepoint value 40.
• According to the specification (UTFGrid: Encoding IDs) we have to subtract 32 and 1 (because 40 >= 35), so we get: 40 – 32 – 1 = 7
• The number 7 is the index of the feature identifier in the keys array. key[7] is “ESP” (line 15), so we have found Spain which is correct.

DevelopmentSeed luckily provides extensions for the mapping clients OpenLayers, Modest Maps, Leaflet and the Google Maps API, so that you do not have to care about the encoding and loading the JSON files. The library containing these extensions is called Wax (the file gridutil.js reads the grid).

To generate the JSON files, TileMill uses the Mapnik grid_renderer (via node-mapnik: the file js_grid_utils.grid2utf writes the grid). The tiles can be served using TileStream. More implementations of the MBTiles specification can be found here.

Update: Presenting on Map Interactivity Without Flash at Where 2.0 and How Interactivity Works with UTFGrid give a good explanation about UTFGrid.

Switzerland Mobility

Our last example is the map on Switzerland Mobile, which was developed by Camptocamp using MapFish and OpenLayers.

The map consists of ~50 POI and line layers that can be switched on and off arbitrarily. The different layers are rendered on the same tile so that the browser does not have to deal with keeping all tiles of all layers properly lined up when panning.

The layers are interactive: Your mouse cursor turns into a pointer when you hover a track or POI and you can click on these features.

How does it work? There is no additional JSON file for every tile like in the first two examples. A different approach is taken: When you hover the map, the client constantly keeps asking the server if there are any features nearby the position your mouse cursor is pointing to. If a new request is made before a response was received for an old request, the old request is aborted, as you can see in the following screen-shot:

If there are features within a certain distance to the mouse position, the server just returns “got something here“. This tells the client to change the cursor style to a pointer. If you click on the map, a new request is made which directly returns the HTML code to be displayed in a map pop-up.

Often there is not only one biking or hiking track at the mouse position, so all hits are displayed in the pop-up (as shown in the above screen-shot). With the current UTFGrid specification you could only get one hit, because it only allows to store one feature identifier per grid cell. But the two different approaches could be combined: You could use the grid to decide whether your mouse cursor is hovering a feature, and then, when clicking somewhere, you would make a new request. This would reduce the number of server requests and you still would get all hits.

Wrap-up

The UTFGrid specification is a promising technique to make feature tile layers interactive. The size of the JSON file containing the grid is reasonable through run-length encoding and and gzipping. Additionally Wax makes sure that only those grids are requested that are actually needed.

Wouldn’t this make a good Web Map Feature Tile Service specification (WMFTS), combining WFS and WMTS?

A map with all customers

I wanted to start simple, so my first goal was to get a map showing a dot for every customer. The first thing to do is getting your data into Google Fusion Tables, so you have to prepare your data for the import.

Geocoding your addresses with Google Fusion Tables

To display a customer on a map, all customer addresses have to be geocoded. Google Fusion Table takes care of the geocoding, you just have to make sure that the address is stored in a single column and not in multiple columns. For example the following SQL query generates a valid import table:

select customerId, name1, name2, ...,
(street & ', ' & zipCode & ' ' & city & ', ' & country) as address
from customers

The result table of this query can directly be imported in Google Fusion Tables, and then simply be geocoded using the column “address” (File » Geocode).

“Manually” geocoding

Unfortunately, you can only geocode 2500 addresses per day, so I couldn’t use the built-in geocoder for my customer table. I had to take a different approach: The Mapbender project provides a file with the polygons of all German postal codes (plz.zip). I took this file, imported the data into a PostGIS database and then generated a KML file with the centroids of all postal codes. Then I imported the KML file into Google Fusion Tables and already could display the postal codes on a map.So now I had my customer table (with columns like customerId, name and zipCode) and the postal code table (with column zipCode and geometry). In a relational database you would perform a join to connect the two tables using the zipCode column. In Google Fusion Tables this join is called Merge (actually merge is a left-outer join). When you merge two tables, the data of the two tables is not copied into the new table. A merged table is more like a view. So when you make changes in the original tables, these changes are also visible in the merged table.

Aggregate your data

Ok, now I could display the customers on a map using the merged table. But there was a big drawback: No matter if there was only one customer or 20 customers in a postal code area, on the map you would only see a single point for that postal code. So I generated a new table thats consists of two columns: the postal code and the number of customers within the postal code area.

select zipCode, count(*) as customerCount
from customers
group by zipCode

But I also wanted to take it a step further and group all customers together whose postal code number is the same in the first three digits (the call of function mid returns the first three digits):

select zipCodeGrouped, sum(customerCount) as sumCustomerCount
from (
   select (Mid(zipCode, 1, 3) || '00') as zipCodeGrouped, count(*) as customerCount
   from customers
   group by zipCode)
group by zipCodeGrouped

Imported in Google Fusion Tables, the table looked like this:

For the new postal code groups I had to create a new KML file in which the geometries of postal codes, that have the same first three digits, were merged using the PostGIS function ST_Union.

Configure the map styling

Once your table has a geometry column, you can put your geometries on a map simply by clicking on Visualize » Map. But often you also want to visualize data associated with the geometries, in my example the number of customers in a postal code group. So I changed the style of postal code polygons to use a gradient.

Postal code areas with many customers are using a darker color, while areas with only a few customer use a lighter color. And this is what the final map looked like:

What is cool

• Easy to get started
  Even if you have never heard of GIS, you can easily import your data, geocode your addresses and create a map.
• Just scales
  This is what I really like about Google Fusion Tables! No matter if you have 10 points or 100 000 points, 10 simple polygons or 100 000 very complex polygons – you won’t notice a difference. Instead of rendering the geometries on the client side, the geometries are rendered on image tiles in the Google cloud. So you also don’t have to worry about simplifying your geometries, Google Fusion Tables does that job for you.
• Integrates with the Google Maps API
  Google added a Fusion Table Layer to their Google Maps API, so it got a lot easier to publish your data on your own maps.

What is not so cool (yet?)

• Limited styling
  Especially for points the styling options are limited. For points, you can currently only choose a marker out of a limited set of markers. Proportional symbols, chart symbols and labels would be nice. Google Fusion Tables is still beta, so likely there will be improvements.
• Style of background maps
  The standard background maps provide too much additional information, that you are not interested in. For the above example you don’t need the street network, a few larger cities would be enough for the background map. If you are using your layer with the Google Maps API, you can change the map style. But not directly in Google Fusion Tables.
• No spatial joins/filters/operations
  Queries like “Get me all customers in this area that live not more than 10 km away from the next store.” are not possible in Google Fusion Tables (without using the API).

So would I use Google Fusion Table to generate business reports? Preparing the postal code geometries was a bit tedious, but you only have to do it once. Then you could import your data using the Google Fusion Tables API. In my case I would prefer a solution that integrates with our existing Pentaho BI Platform setup.

Links

• Google Fusion Table
• “Managing and visualizing your geospatial data with Fusion Tables” at Google I/O 2011 (Slides)
• Google Fusion Tables API
• Google Maps API: Fusion Table Layer
• “New Features in Google Geo Fusion Tables, Places API and Custom Street View” at Hamburg JS Meetup 2011

1. Create a new Google Code project with a SVN repository.
2. Reset the Google Code SVN repository.
   By default every Google Code SVN repository does have an initial structure, but svnsync needs an empty repository. So go to the “Source” tab and at the bottom of the page there is a link “reset this repository”.
3. Now open up a terminal.
   

   $ export FROMREPO=https://svn.kenai.com/svn/YOUR-PROJECT
   $ export TOREPO=https://YOUR-PROJECT.googlecode.com/svn/

4. Then you will be asked for your username/password after running this command.
   

   $ svnsync init ${TOREPO} ${FROMREPO}

5. And finally to start the process, execute the following:
   

   $ svnsync --non-interactive sync ${TOREPO}

See also: using-svnsync

• phpcpd (PHP Copy&Paste Detection)
• phploc (PHP Lines of Code)
• PHP Depend
• PHPCode Sniffer
• PHPUnit – CodeCoverage

phpcpd (PHP Copy&Paste Detection)

Einzige Aufgabe dieses Tools von Sebastian Bergmann ist es, den Code auf die Verwendung des Copy&Paste-Anti-Pattern hin zu untersuchen. Ab wann eine Code-Passage als „kopiert“ gilt, lässt sich über die Anzahl der Zeichen/Zeilen, die identisch sind, einstellen.

Eine Beispiel-Ausgabe findet sich auf der Projekt-Homepage von phpcpd.

phploc (PHP Lines of Code)

Auch dieses kleine Tool ist von Sebastian Bergmann. Es erstellt einfache Codemetriken, wie die Anzahl der Zeilen, der Kommentar-Zeilen, der Klassen, und mehr.

Eine Beispiel-Ausgabe findet sich auch wieder auf der Projekt-Homepage von phploc.

PHP Depend

Komplexere Metriken, zum Beschreiben und Charakterisieren der Architektur eines Systems, erstellt PHP Depend, das Äquivalent zu JDepend.

Hauptbestandteil dieser Analyse ist die sog. „Overview Pyramid“ (weitere Informationen dazu: “The overview pyramid in detail” (PDF) oder “Software-Metriken” (PDF)), die drei wichtige Aspekte (Größe/Komplexität, Kopplung und Verwendung der Vererbung) in einem übersichtlichen Format darstellt.

Die linke, untere Seite beschreibt Größe und Komplexität des Systems. Die Maßzahlen sind im einzelnen (jeweils von unten nach oben):

• Direkt erfassbare Kennzahlen:
  • CYCLO (zyklomatische Komplexität): Maß für die Komplexität des Kontrollflusses eines Programms
  • LOC: Lines of Code
  • NOM: Number of Methods
  • NOC: Number of Classes
  • NOP: Number of Packages
• Abgeleitete Kennzahlen:
  • Intrinsic operation complexity (CYCLO/LOC)
  • Operation structuring (LOC/NOM)
  • Class structuring (NOM/NOC)
  • High-Level structuring (NOC/NOP)

Die abgeleiteten Kennzahlen ermöglichen Aussagen über die Granularität des Systems, zum Beispiel wieviele Methoden in einer Klasse vorkommen.

Die rechte, untere Seite der Pyramide beschreibt die Kopplung innerhalb des Systems.

• Direkt erfassbare Kennzahlen:
  • FANOUT: Zahl der aufgerufenen Klassen
  • CALLS: Zahl der Methoden-Aufrufe

• Abgeleitete Kennzahlen:
  • Coupling disperson (FANOUT/CALLS): Wie viele andere Operationen werden von einer Operation aus aufgerufen?
  • Coupling intensity (CALLS/NOM) : Wie stark sind die Klassen gekoppelt?

Der obere Teil der Pyramide gibt die folgenden, direkt erfassbaren Kennzahlen an, die die Verwendung von Vererbung charakterisieren:

• AHH: Average Hierarchy Height (Tiefe des Vererbungsbaums)

• ANDC: Average Number of Derived Classes (durchschnittliche Anzahl der direkt abgeleiteten Klassen: Breite des Vererbungsbaums)

PHP CodeSniffer

PHP CodeSniffer dient dazu, den Code auf die Einhaltung von Coding-Standards hin zu überprüfen. Dabei wird folgendes untersucht:

• Vollständige Kommentar-Abdeckung
• Einrückung / Groß- und Kleinschreibung
• Namenskonventionen
• Gestaltung von Kontrollstrukturen / Klammersetzung
• und mehr

Vorgefertigte Coding-Standards zum Beispiel von Zend oder PEAR können verwendet werden oder es können auch eigene Coding-Standards mit neuen Regeln angelegt werden. Wie dies funktioniert, wird hier beschrieben: PHP Code Sniffer – Parameter und eigene Regelset.

PHPUnit – Code Coverage

PHPUnit beinhaltet auch eine Funktionalität zur Überprüfung der Code-Abdeckung der Unit-Tests: Code Coverage Analysis.

Als Ausgabe wird ein übersichtlicher Report erstellt, aus dem auch genau ersichtlich wird, welche Codezeilen durch welche Tests abgedeckt wurden und welche gar nicht getestet wurden.

Wer sich näher mit der Qualitätssicherung in PHP beschäftigen will/muss, dem kann ich folgende Seiten empfehlen:

• phpUnderControl: Eine Erweiterung für CruiseControl, die einige der oben genannten Tools unter einer Oberfläche vereint.
• Quality Assurance in PHP Projects
• Statische Code-Analyse mit dem PHP Code Sniffer

Alle Jugendherbergen in Deutschland werden auf dieser Karte angezeigt, dies ist die passende KML-Datei dazu.

Für alle anderen Länder sind die URL’s ähnlich aufgebaut. Es muss einfach das Länderkürzel ersetzt werden.

Zum Beispiel für Frankreich (FR):
URL zur Karte: http://www.hihostels.com/dba/cmap-FR.de.htm?himap=Y
URL zur KML-Datei: http://www.hihostels.com/mapcoord/FR.de.kml

Oder auch für Luxemburg (LU):
URL zur Karte: http://www.hihostels.com/dba/cmap-LU.de.htm?himap=Y
URL zur KML-Datei: http://www.hihostels.com/mapcoord/LU.de.kml

int* a, b;

Ist b jetzt vom Typ “Zeiger auf Integer” oder vom Typ “Integer”?

Mit folgendem Aufruf hat man dies schnell geklärt:

int* a, b;
std::cout << (typeid(b) == typeid(int*)) << std::endl;
//Ausgabe: 0

Siehe auch: typeid()

Nun selektiere ich einfach ein paar Photos, mache einen Rechtsklick und wähle “Skripte > Open in Google Maps” aus.

Im Hintergrund werden jetzt die EXIF-Header der ausgewählten Photos mit Hilfe von exiftool auf Koordinaten untersucht. Es wird dann eine temporäre HTML-Seite in Firefox geöffnet, die eine Google Maps-Karte mit allen Photos enthält.

Alternativ können die Photos auch in Google Earth angezeigt werden. Hierfür wird dann eine temporäre KML-Datei erstellt.

Und so lassen sich die Skripte einrichten:

Kopiere nachfolgenden Quelltext in einen Texteditor und speichere die Datei unter “/home/{User}/.gnome2/nautilus-scripts/Open in GoogleMaps” (ohne Dateiendung).

# Get the calling dir
CURRENTDIR=$(echo ${NAUTILUS_SCRIPT_CURRENT_URI})

# Path to the temporary KML file
KMLFILE="/tmp/$$.html"

#Write KML - Header
echo "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Strict//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\">" >> $KMLFILE
echo "<html xmlns=\"http://www.w3.org/1999/xhtml\">" >> $KMLFILE
echo "<head>" >> $KMLFILE
echo "<title>Open in GoogleMaps</title>" >> $KMLFILE
echo "<meta http-equiv=\"Content-Type\" content=\"text/html; charset=utf-8\" />" >> $KMLFILE
echo "" >> $KMLFILE
echo "<script src=\"http://maps.google.com/maps?file=api&v=2&amp\" type=\"text/javascript\">" >> $KMLFILE
echo "</script>" >> $KMLFILE
echo "<style type=\"text/css\">" >> $KMLFILE
echo "	html, body, #map {" >> $KMLFILE
echo "		width: 100%;" >> $KMLFILE
echo "		height: 100%;" >> $KMLFILE
echo "	}" >> $KMLFILE
echo "" >> $KMLFILE
echo "	body {" >> $KMLFILE
echo "		margin-top: 0px;" >> $KMLFILE
echo "		margin-right: 0px;" >> $KMLFILE
echo "		margin-left: 0px;" >> $KMLFILE
echo "		margin-bottom: 0px;" >> $KMLFILE
echo "	}" >> $KMLFILE
echo "</style>" >> $KMLFILE
echo "</head>" >> $KMLFILE
echo "" >> $KMLFILE
echo "<body>" >> $KMLFILE
echo "
<div id=\"map\"></div>
" >> $KMLFILE
echo "
<div id=\"footer\">" >> $KMLFILE
echo "" >> $KMLFILE
echo "<script type=\"text/javascript\">" >> $KMLFILE
echo "//<![CDATA[" >> $KMLFILE
echo "var map;" >> $KMLFILE
echo "var markerOptions;" >> $KMLFILE
echo "var bounds;" >> $KMLFILE
echo "" >> $KMLFILE
echo "function addPoint(name, fileName, lat, lng) {" >> $KMLFILE
echo "	var latlng = new GLatLng(lat, lng);" >> $KMLFILE
echo "	var marker = new GMarker(latlng, markerOptions);" >> $KMLFILE
echo "	marker.value = 1;" >> $KMLFILE
echo "	GEvent.addListener(marker,\"click\", function() {" >> $KMLFILE
echo "		var myHtml = \"<b>\" + name + \"</b>
<img src=\\\"\" + fileName + \"\\\" width=\\\"200\\\" />\";" >> $KMLFILE
echo "        map.openInfoWindowHtml(latlng, myHtml);});" >> $KMLFILE
echo "	map.addOverlay(marker);" >> $KMLFILE
echo "	bounds.extend(latlng);" >> $KMLFILE
echo "}" >> $KMLFILE
echo "" >> $KMLFILE
echo "if (GBrowserIsCompatible()) {" >> $KMLFILE
echo "	map = new GMap2(document.getElementById(\"map\"));" >> $KMLFILE
echo "	map.setCenter(new GLatLng(0,0));" >> $KMLFILE
echo "	var mgr = new GMarkerManager(map);" >> $KMLFILE
echo "	map.setMapType(G_SATELLITE_MAP);" >> $KMLFILE
echo "	map.enableScrollWheelZoom();" >> $KMLFILE
echo "	map.addControl(new GLargeMapControl());" >> $KMLFILE
echo "	map.addControl(new GMapTypeControl());" >> $KMLFILE
echo "	map.addControl(new GScaleControl());" >> $KMLFILE
echo "	map.addControl(new GOverviewMapControl());" >> $KMLFILE
echo "" >> $KMLFILE
echo "	var photoIcon = new GIcon(G_DEFAULT_ICON);" >> $KMLFILE
echo "	photoIcon.image = \"http://maps.google.com/mapfiles/kml/pal4/icon46.png\";" >> $KMLFILE
echo "	photoIcon.iconSize = new GSize(30, 30);" >> $KMLFILE
echo "	markerOptions = { icon:photoIcon };" >> $KMLFILE
echo "	bounds = new GLatLngBounds();" >> $KMLFILE

PHOTOSADDED=1
#Loop selected files
while [ $# -gt 0 ]; do
	fileName=$1

	# Try to get GPS coordinates of this file
	KOORD=$(exiftool -n -f -p '$GPSLatitude,$GPSLongitude' "${fileName}")

	#If the coordinates are invalid, they do look like this: "-,-"
	PRUEF=$(expr index "$KOORD" "-")

	if [ $PRUEF = 0 ]
	then
		#This is a valid photo, so add to KML
		PHOTOSADDED=0

		echo "	addPoint(\"${fileName}\", \"`pwd`/${fileName}\", ${KOORD});" >> $KMLFILE

	fi
	shift
done

#Write KML - Footer
echo "	map.setZoom(map.getBoundsZoomLevel(bounds));" >> $KMLFILE
echo "	map.setCenter(bounds.getCenter());" >> $KMLFILE
echo "   }" >> $KMLFILE
echo "//]]>" >> $KMLFILE
echo "</script>" >> $KMLFILE
echo "</div>
" >> $KMLFILE
echo "</body>" >> $KMLFILE
echo "</html>" >> $KMLFILE

if [ $PHOTOSADDED = 0 ]
then
	firefox "${KMLFILE}"
else
 	zenity --error --text "Not one photo containing coordinates. Could not create KML file!"
fi

Und das Skript für Google Earth kann unter dieser Datei gespeichert werden:
“/home/{User}/.gnome2/nautilus-scripts/Open in GoogleEarth” (auch ohne Dateiendung)

# Get the calling dir
CURRENTDIR=$(echo ${NAUTILUS_SCRIPT_CURRENT_URI})

# Path to the temporary KML file
KMLFILE="/tmp/$$.kml"

#Write KML - Header
echo "<?xml version=\"1.0\" encoding=\"UTF-8\"?>" >> $KMLFILE
echo "<kml xmlns=\"http://earth.google.com/kml/2.1\">" >> $KMLFILE
echo "<Document>" >> $KMLFILE
echo "	<name>KmlFile</name>" >> $KMLFILE
echo "	<Style id=\"Photo\">" >> $KMLFILE
echo "		<IconStyle>" >> $KMLFILE
echo "			<Icon>" >> $KMLFILE
echo "				<href>http://maps.google.com/mapfiles/kml/pal4/icon46.png</href>" >> $KMLFILE
echo "			</Icon>" >> $KMLFILE
echo "		</IconStyle>" >> $KMLFILE
echo "	</Style>" >> $KMLFILE

PHOTOSADDED=1
#Loop selected files
while [ $# -gt 0 ]; do
	fileName=$1

	# Try to get GPS coordinates of this file
	KOORD=$(exiftool -n -f -p '$GPSLongitude,$GPSLatitude' "${fileName}")

	#If the coordinates are invalid, they do look like this: "-,-"
	PRUEF=$(expr index "$KOORD" "-")

	if [ $PRUEF = 0 ]
	then
		#This is a valid photo, so add to KML
		PHOTOSADDED=0

		echo "<Placemark>" >> $KMLFILE
		echo "	<name>${fileName}</name>" >> $KMLFILE
		echo "	<description><![CDATA[<img src=\"`pwd`/${fileName}\" width=\"200\"/>]]></description>" >> $KMLFILE
		echo "	<styleUrl>#Photo</styleUrl>" >> $KMLFILE
		echo "	<Point>" >> $KMLFILE
		echo "		<coordinates>${KOORD}</coordinates>" >> $KMLFILE
		echo "	</Point>" >> $KMLFILE
		echo "</Placemark>" >> $KMLFILE
	fi
	shift
done

#Write KML - Footer
echo "</Document>" >> $KMLFILE
echo "</kml>" >> $KMLFILE

if [ $PHOTOSADDED = 0 ]
then
	googleearth "${KMLFILE}"
else
 	zenity --error --text "Not one photo containing coordinates. Could not create KML file!"
fi

Nach einem Neustart von Nautilus werden diese zwei Skripte jetzt im Rechtsklick-Menü aufgeführt.

Zur Ausführung werden folgende Pakete/Programme benötigt:

• libimage-exiftool-perl
• zenity
• Firefox
• Google Earth

Die Skripte dürfen frei verwendet und weiter entwickelt werden.

Update:

Mittlerweile bietet Hosting International auch direkt Karten an, siehe KML-Dateien mit europäischen Jugendherbergen.

Beim Planen einer Tour in die Provence mit GoogleMaps ist mir aufgefallen, dass dafür gar keine Layer/Karten mit allen Jugendherbergen zu finden sind.

Deshalb habe ich mir heute auf die Schnelle ein kleines Java-Programm geschrieben, dass alle Jugendherbergen von Hostelling International heraussucht und die Adressen in eine KML-Datei schreibt. Über GoogleEarth habe ich diese Adressen dann geokodieren lassen.

Hochgeladen in GoogleMaps kann diese Karte nun frei verwendet werden:

Karte mit allen Jugendherbergen in Deutschland (KML)

Und dies ist die Karte für Frankreich:

Karte mit allen Jugendherbergen in Frankreich (KML)

Da in GoogleMaps nur die Jugendherbergen auf der Karte angezeigt werden, die links auf der im Inhaltsverzeichnis ausgewählten Seite aufgelistet sind, schaut man sich es besser in GoogleEarth über die KML-Dateien an.