Leider musste ich in letzter Zeit wiederholt die Erfahrung machen, dass einzelne Objekte oder ganze Gegenden, die ich mit viel Mühe nach (GPS-korrigiertem) Luftbild und Ortskenntnis präzise gemappt habe, von anderen Mappern wieder „vergröbert“ werden.

Da werden zum Beispiel sauber ausgerundete Kurven wieder eckig gemacht oder S-Kurven in Wegen, die tatsächlich vorhanden sind (ich war vor Ort und hab’s gesehen), einfach begradigt, und auf meine Nachfrage im CS heißt es mit etwas höhnischem Unterton, so genau könne mein GPS ja gar nicht sein, dass ich den Verlauf so exakt erfassen kann. (Doch, kann es. Und was speziell diesen Kollegen angeht, so stoße ich häufig auf von ihm gemappte Wege im Wald, wo nur Dickicht ist und auch vor zehn Jahren mit Sicherheit nur Dickicht war. Diesbezügliche Nachfragen bleiben unbeantwortet.)

Nun wurden vor zwei Wochen in meinem Wohnort massenhaft straßenbegleitende Flächenränder, die ich sauber bis zum Straßenrand und parallel zum Straßen-Way gemappt hatte, vergröbert bis zur Straßenmitte gezogen. Das ist mir aufgefallen, als ich mich daran machte, die Straßen hier als area:highway=* zu erfassen. Wäre eine leichte Übung entlang der schon sauber gemappten Ränder gewesen, aber jetzt lasse ich das Projekt halbfertig liegen, weil ich wirklich null Lust habe, die ganze Arbeit an den Rändern nochmal zu machen. Schade. Ich war ein wenig stolz darauf, dass hier fast alles präzise detailgemappt war. Auf meine Frage im CS kam bislang keine Antwort.

Über die Gründe kann ich nur spekulieren, da ich auf meine Nachfragen selten Antworten bekomme. Im ersten Fall wurde offenbar eine solche Präzision für weder technisch möglich noch überhaupt erforderlich gehalten. Im zweiten bestand das Ziel wohl darin, die weißen Lücken neben dem gerenderten Straßenway in höchsten Zoomleveln zu vermeiden, und das quick’n’dirty.

… See full entry

Zwar werden heute in Smartphones größtenteils erfreulich gute GPS-Module eingesetzt, die sich vor dem klassischen Garmin nicht mehr zu verstecken brauchen. Doch sprechen gute Gründe dafür, den GPS-Empfang „outzusourcen“, wenn Tracks aufgezeichnet werden. Beispielsweise zeichnet mein OnePlus 5T zwar ausgezeichnete, linealgerade Tracks auf, wenn ich es in der Hand halte, separat vom Körper – aber so will ich nicht länger als fünf Minuten durch die Gegend spazieren, schon gar nicht mit Hund an der Leine. In der Hosen- oder Jackentasche verschlechtert sich der Empfang sofort deutlich, weil mein Körper dann den halben Himmel abschirmt.

Meine Lösung: ein kleiner Bluetooth-GPS-Empfänger, den ich auf dem Scheitel unter der Kopfbedeckung trage und der von dort aus immer bestmöglichen Empfang hat. Das Handy muss nur noch dieses Gerät per Bluetooth empfangen, und da stört mein Körper nicht; es kann stecken, wo es will, der Track hat immer ausgezeichnete Qualität.

Mit meinen Androiden hatte ich noch kein Problem, den externen GPS-Huber in Betrieb zu nehmen. So geht’s, und zwar in dieser Reihenfolge:

1. Eine App installieren, die die per Bluetooth empfangenen GPS-Daten ins System einspeisen kann.
2. Dem Handy verklickern, dass es die in 1. installierte App als GPS-Quelle nutzen soll statt des eingebauten Moduls.
3. Das Bluetooth-GPS mit dem Handy koppeln.
4. Der in 1. installierten App sagen, dass es das in 3. gekoppelte GPS-Gerät empfangen soll.

Im einzelnen:

… See full entry

Jeder Mapper kennt das: Auf der grünen Wiese wird gebaut. Ob Supermarkt oder Wohnsiedlung, die Gebäude wollen erfasst werden. Sie sind garantiert auf keinem Luftbild zu sehen, sollten aber in die Datenbank, möglichst positionsgenau. Wie machen wir das?

Wie schön wäre es, man könnte einfach mit laufendem GPS-Tracking das Gebäude entlang seiner Außenwände umlaufen und hätte den exakten Umriss. Aber der nicht mehr ganz grüne Mapper weiß: Das geht nicht. Abgesehen davon, dass kein Bauleiter es gern sieht, wenn irnkwelche Leute auf seiner Baustelle rumlaufen, wird das auch messtechnisch nichts. Gerade das Gebäude, das wir vermessen wollen, stört den Empfang so stark, dass die Spur wild von links nach rechts springt und nicht zu gebrauchen ist. Das können wir vergessen.

Ich vermesse so was anders: mit Fluchtlinien.

Beispiel: Wir nehmen an, auf diesem Acker werden zwei Marktgebäude errichtet. Erstmal nehme ich Fotos von der Baustelle auf, um eine grobe Vorstellung zu haben (die kann ich hier nicht zeigen, weil es die Baustelle nicht gibt).

… See full entry

Warum ich mich immer so ärgere, wenn ich auf solche Kreuzungen treffe? Hier wurde doch alles richtig gemacht, oder? Alle Ways exakt in der Mitte des Straßenabschnittes, den sie repräsentieren, das Luftbild optimal nachgezeichnet.

… See full entry

Es ist gut, dass wir Öffnungszeiten in OSM erfassen. Echtzeit-Navi-Anwendungen wie OsmAnd markieren in den Suchergebnissen gleich, welche Einrichtungen geöffnet sind und welche nicht.

Das Schema, nach dem die Zeiten angegeben werden, ist allerdings einigermaßen komplex, und einer der beliebtesten Fehler ist das falsch gesetzte Semikolon. Ich habe schon viele davon ausgemerzt (und in meiner Anfangszeit einige selbst gesetzt, ich bin keineswegs besser!).

Deshalb die erste Regel: Benutz im Zweifelsfall immer das evaluation tool. Da kannst du oben eine Kalenderwoche aussuchen, darunter dein opening_hours-Konstrukt eingeben, und dann wird dir übersichtlich angezeigt, wann demnach offen und wann zu ist. Du kannst den String auch gleich da überarbeiten und dann mit copy&paste ins OSM-Tag übernehmen.

Das oben angesprochene falsche Semikolon schleicht sich immer gern dann ein, wenn nur wenige Wochentage von einem ansonsten festen Schema abweichen – nehmen wir an, Montag bis Samstag ist 08:00-12:00, Dienstag und Donnerstag zusätzlich 14:00-18:00 geöffnet.

Elegant ist es, je eine Regel für die Vormittags- und für die Nachmittagszeiten anzugeben, und ganz schnell hat man dann so was getippselt:

opening_hours = Mo-Sa 08:00-12:00; Tu,Th 14:00-18:00

… und ist schon reingefallen. Erklärung: Eine mit Semikolon abgetrennte Regel bedeutet eine vollkommen neue Angabe, wird also als „nur dann geöffnet“ interpretiert und macht damit die gerade genannten Vormittagszeiten am Dienstag und Donnerstag gleich hinterrücks wieder ungültig. Aus OSM-Sicht ist diese Einrichtung dienstags und donnerstags jetzt vormittags geschlossen, denn von widersprüchlichen Regeln gilt immer die letzte.

Richtig wäre dagegen ein Komma zwischen den zwei ergänzenden Regelsätzen:

opening_hours = Mo-Sa 08:00-12:00, Tu,Th 14:00-18:00

… auch wenn das irgendwie komisch aussieht, weil das Komma ja auch die Wochentage trennt. Auf Nummer Sicher geht natürlich, wer die Wochentage einzeln aufzählt:

… See full entry

Die schlechte Nachricht: Nein, ist es nicht.
Die gute Nachricht: Es gibt nur zwei Sorten.

Schon einige Male stand ich mit meinem autogasgetriebenen Fahrzeug vor einer Tankstelle, die zwar Erdgas feilbot, aber damit kann mein Vehikel nichts anfangen. Ein Mapper kannte wohl die feinen Unterschiede nicht und hatte das Gasangebot als fuel:lpg=yes drangetaggt. Kann passieren.

Dabei ist es praktisch, Spritsorten zu erfassen. OsmAnd zum Beispiel kann diese Tags auswerten und etwa gezielt Autogastankstellen als POIs auf der Karte hervorheben. Daher danke fürs Lesen, und noch mehr fürs Mappen :-)

Damit es seltener zu Verwechslungen kommt, mal eine kurze Klärung der beiden unterschiedlichen Gaskraftstoffe:

Autogas

fuel:lpg=yes

Bezeichnungen: Autogas, LPG, GPL, Propan …

Autogas ist mehr oder weniger das, was man auch im Campingkocher oder im Feuerzeug hat, chemisch ist es eine Mischung von Propan und Butan in unterschiedlicher Zusammensetzung. Dieser Treibstoff hat mehrere angenehme Eigenarten. Erstens verbrennt er sehr schadstoffarm und erzeugt vor allem fast keinen Feinstaub, zweitens ist er schon bei relativ geringem Druck (5 bis 8 bar) dauerhaft flüssig (daher der Name „Flüssiggas“, einklich ein Oxymoron). Der Witz: In flüssigem Zustand bekommt man viel mehr davon in den Tank als in gasförmigem, denn eine Flüssigkeit ist, verglichen mit einem Gas, maximal dicht gepackt. Getankt wird über einen einfachen Druckanschluss, für den es allerdings verschiedene Ausführungen gibt, so dass man halt den richtigen Adapter dabei haben muss (national sind die zum Glück größtenteils gleich), abgerechnet wird nach Liter.

… See full entry

Mal die wichtigsten Bedienelemente kurz & bündig:

A Das Taggingfenster der Relation. Tags, die sich auf die Relation als Ganzes beziehen und nicht nur auf einzelne Members, werden hier eingetragen.

B Die Members der Relation in der vorliegenden Reihenfolge. „Unvollständig“ sollte besser „unbekannt“ heißen: Der betreffende Member wurde schlicht noch nicht vom Server geladen, deshalb sind dessen Eigenschaften noch unbekannt. Links stehen die jeweiligen Roles. Die Spalte rechts zeigt an, ob die Members zusammenhängende oder sogar geschlossene Linienzüge ergeben. Die kleinen Pfeile sind die Richtungen der einzelnen OSM-Ways. Hier sind Lücken sofort erkennbar (Rechtsklick → Auf Lücke springen bringt die Lücke in den Haupteditor).

… See full entry

Ich muss mal was über highway=service loswerden, nachdem ich gerade einen ganzen Sack davon zurechtgerückt habe. Viele davon sind nämlich mit Hilfe des service=*-Tags „zu klein“ getaggt, was Folgen für unterschiedliche Anwendungen hat und deshalb vermieden werden sollte.

Zum Beispiel macht die Anwesenheit eines Parkplatzes nicht jede Fahrspur darauf automatisch zum service=parking_aisle!

Hier mal kurz meine Auffassung der Dinge, die sicher kein Evangelium ist. Aber sie deckt sich mit dem Wiki, und das sollte doch unser gemeinsamer Nenner sein, damit unsere Daten optimal auswertbar sind.

service=parking_aisle

… See full entry

Die Faszination des Bing-Luftbildes als Mapping-Quelle macht sich besonders dann bemerkbar, wenn man eine Gegend bearbeitet, die in der Vor-Bing-Ära gemappt wurde, meist nach einmaligem Abtracken per GPS, wo schnurgerade Straßen Schlangenlinien machen oder um 50 m versetzt sind. Man lächelt milde und stellt das alles „richtig“. Nach dem Bing-Luftbild, versteht sich, denn das hat ja recht.

Oder?

Auch 170 Jahre Fotografie und fast ebenso viele Jahre Fototricks haben uns offenbar noch nicht abgewöhnen können, das, was wir realitätsnah auf einem Bild sehen, als Wahrheit zu betrachten. Auch Bing verführt uns in dieser Weise. Dabei wäre Vorsicht angebracht. Schaun wir mal auf die B 54 nördlich Bad Schwalbach:

Wieso ist die Straße ein gerader Strich? Hat es sich hier nicht ein Mapper zu einfach gemacht? Auf dem Luftbild geht sie doch nach rechts. Komm, das müssen wir gleich mal korrigieren!

… See full entry

Nehmen wir mal eine relativ einfache Landstraßenkreuzung, hier bei Oberems im Taunus. Diese Kreuzung kommt ohne irnkwelche Spezialitäten aus, sie braucht keine Abbiegebeschränkungen, keine Einbahnstraßen, nichts. Sie sieht in der Karte vernünftig aus und wird auch in jedem Router einwandfrei funktionieren. Die Abbiegespuren auf der B8 sind getaggt, Fahrspurhinweise können also gegeben werden. Und daß man von der B8 schon 10 Meter vor der einklichen Kreuzung rechts abbiegen kann, wird jeder Fahrer vor Ort intuitiv erfassen, das muß sein Navi ihm nicht sagen.

Jetzt kommt aber ein eifriger Mapper daher und zeichnet die zwei Rechtsabbiegeverbindungen zusätzlich als highway=secondary_link ein. Das ist zunächst einmal gerechtfertigt, schließlich bilden sie aufgrund der Inseln eine baulich getrennte eigene Fahrbahn.

… See full entry