GPS-Strecken in den Lungen von Berlin mit Google Fusion Tables

26 Februar 2010 von Klaus Bechtold

Gestern las ich einen Artikel des Blogs von MTBguru über ein Anwendungsbeispiel der Google Fusion Tables, mittels dem man riesige Mengen an Geo-Daten visualisieren kann.

Ich habe es natürlich gleich für einige GPSies-Strecken an Berlins populären Outdoor-Orten ausprobiert und bin völlig von den Socken! Schade dass GPSies nur ein Hobby ist ;-)


Laufstrecken im Berliner Grunewald (Auswahl: ca. 400 Strecken, Großansicht)

Kommentar: Hier erkennt man deutlich die Läufer-Autobahn am Schlachtensee.



Mountainbike-Strecken im Berliner Grunewald (Auswahl: ca. 110 Strecken, Großansicht)

Kommentar: Die Mountainbiker fahren offensichtlich nicht immer auf den Wegen. Deutlicher Unterschied zu Lauf-Strecken im Grunewald.



Laufstrecken im Berliner Tiergarten (Auswahl: ca. 160 Strecken, Großansicht)

Kommentar: Die Läufer laufen auch hier auf “Autobahnen” und meiden kleine Wege.


Eines vorweg ;-)

  1. Die Linien spiegeln nicht die Qualität wieder, die GPSies von den Strecken hat. Die Strecken wurden von Google stark gekürzt. Das reicht aber vollkommen aus.
  2. Jetzt stelle ich mich der Kritik, dass auch GPSies den Berlin-Marathon 20 mal hat ;-) – ok, aber das kann ich leider nicht vermeiden. Da es unterschiedliche GPS-Aufzeichnungen sind, sind es auch für GPSies unterschiedliche Strecken.
  3. Die Daten habe ich per Geobound ausgewählt, die irgendeinen freien Bezug zu dem Ausschnitt haben (Start- und Endpunkte). Der von mir gewählte Ausschnitt (BBOX) war wesentlich kleiner, als der jetzt sichtbare. Bei GPSies gibt es schon alleine für Berlin so viele Strecken, dass der limitierte Speicherplatz von 100MB pro Datei nicht ausreichen würde (Limitierung siehe weiter unten).

Wer oder was steckt dahinter?

Google natürlich. Wie immer. Google stellt mit den Fusion Tables einen Speicherplatz und Technologie zur Verfügung, die man ohne ein kleines Rechenzentrum und ohne einem Geoinformatiker (oder einem Klon von mir ;-)) mal eben nicht so nachbauen kann. Ich hatte mir schon oft die Frage gestellt, wie ich denn alle Strecken von GPSies so darstellen kann. Nach 10 Sekunden Nachdenken war der Traum aus geträumt – geht nicht – zu wenige Server – keine Zeit usw. Doch mit den Fusion Tables kann dieser Traum wahr werden – mal sehen.

Das Problem ist zur Zeit noch der auf 250 MB limitierte Speicherplatz bei Google. Mit den zur Zeit 320.000 Strecken, also ca. 30 GB an Geo-Daten, komme ich natürlich nicht aus. Wenn jedoch Google die Technologie zum Beispiel vermietet, dann könnte ich diese Cloud auch für GPSies nutzen. Das kommt natürlich auf den Preis an. Denkbar wäre dann fast alles:

  1. Visualisierung nach Aktivität, Benutzer, Dichte, Merkmalen, usw., einstellbar vom Benutzer
  2. Suche nach Streckenüberschneidungen (in Bezug auf Routing)
  3. Suche nach Streckendurchquerungen

Es bleibt spannend – ich bleibe dran…


  1. Berlinaut    26. Februar 2010, 12:56    #

    Ich würds politisch ganz korrekt finden, wenn GPSies auf OSM statt Google setzen würde. Speicher auf Webservern kostet doch heute fast nichts mehr.

  2. Klaus    26. Februar 2010, 13:02    #

    Hallo,

    ich verstehe deinen Kommentar ehrlicherweise nicht. GPSies ist doch schon einer der größten Unterstützer von OSM, siehe: Top 50 users for uploads of GPS data, derzeit Platz 11. Außerdem geht es doch nicht um den Festplatten-Speicher… davon habe noch 750 GB frei. Es geht doch um Rechenleistung…

    Viele Grüße,

    Klaus

  3. Tom    26. Februar 2010, 19:19    #

    Klaus,

    as you noted, Google does a significant amount of down-sampling before rendering the track. We aren’t sure exactly what kind of algorithm is used: it seems to be a combination of lowering the resolution and well as limiting the numbers of track points to a certain maximum (~50 per track?)

    It takes about 10 bytes to store a track point, so with 250MB and 50 points per track, you should be able to render ~500000 tracks.

    Obviously, for our site with just ~6000 public tracks, this is less of problem. :-)

    Tom@mtbguru

  4. Klaus    27. Februar 2010, 09:31    #

    Hi Tom,

    good idea and hint. I do have some algorithms (see download options by the tracks detail view), that reduces a track to an amount of points. If I would send each public track with this reduction into the cloud, it should be possible, to store all tracks. I also could use more than one Google account, maybe one for each country or continent, this would be good for scaling reasons.

    Nevertheless, thank you very much for your article and the inspiration at MTBguru.com!

    Cheers, Klaus


Schreibe einen Kommentar (Veröffentlichung erst nach Freischaltung):




* Pflichtfelder

Vor dem Absenden, bitte zuerst "Vorschau" anklicken...



|