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.

Die betreffenden Kollegen sind zum Teil wesentlich länger als ich dabei, so dass ich mich damit schwertue, sie überhaupt auf so was anzusprechen. Wenn das Projekt so ist, dann ist es halt so und dann bin ich derjenige, der nicht so recht reinpasst.

Als Kommunikator bin ich zu schlecht – mindestens drei Kollegen habe ich durch offenbar zu plump formulierte inhaltliche Kritik schon ernsthaft und teilweise endgültig angepisst, und mehr solchen Schaden im Projekt will ich nicht anrichten.

Nun sieht es außerdem so aus, dass ich als Mapper zu gut bin. Das präzise Mapping, das ich liebe, wird von zu vielen offenbar nicht verstanden und/oder für unnötig oder gar schädlich gehalten. Und ich habe keine Lust dazu, meine Arbeit, für die ich viele Stunden abends am JOSM gesessen habe, jetzt auch noch ständig verteidigen oder qualitative Verschlechterungen reverten zu müssen, womit ich ja auch wieder andere anpisse.

Damit verabschiedet sich Kreuzschnabel ein wenig gefrustet aus der aktiven Arbeit an OSM. Ich habe das Gefühl, mit meiner pragmatisch-perfektionistischen und sicher manchmal etwas kurz angebundenen Art nicht mehr so richtig in die Community reinzupassen. Und bezüglich der Daten scheint es nicht (mehr?) Konsens zu sein, dass man das Mapping von Kollegen, die sich mehr Mühe geben als man selbst es tut (und das entscheidet jeder für sich), respektiert und stehen lässt, wenn es nichts dran eindeutig zu verbessern gibt. Ein Goldstandard, der auch in grundsätzlichen Stilfragen Klarheit schafft, könnte hier helfen und viele fruchtlose Diskussionen und vieles Gegeneinander-Arbeiten von vornherein vermeiden, aber den sehe ich in OSM nur ganz fern über den Horizont schimmern. Das Wiki wird leider immer unbrauchbarer, je mehr dort Leute undiskutiert ihre persönlichen Vorlieben zur Vorschrift adeln :(

Ich danke allen für die gute Zusammenarbeit in den fünf Jahren. Mir hat es viel Spaß gemacht, allerdings wird bei der derzeitigen Halbwertszeit von meinen Beiträgen in ein paar Jahren nicht mehr viel zu sehen sein.

–ks

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:

1. Ich verwende die App „Bluetooth GPS Provider“, kostenlos (der Autor freut sich aber über eine kleine Spende) und werbefrei. Sollte in allen App-Quellen zu finden sein. Installieren, aber noch nicht öffnen (ist noch zwecklos).

2. Zum Austausch der GPS-Quelle nutzen wir eine Hintertür des Systems: Es gibt Apps, die dem Handy absichtlich eine falsche Position vorgaukeln. So kann man sich auf Balkonien fotografieren, und die Exif-Daten des Bildes sagen Mallorca. Um das aktivieren zu können, musst du in deinem Androiden die „Entwickleroptionen“ freischalten: Öffne in den Einstellungen den Punkt „Über das Telefon“, such dort den Eintrag „Build-Nummer“ und klopf mehrmals darauf, bis die Meldung kommt, dass du Entwickler bist. Sodann gehst du zurück nach Einstellungen → System und findest dort den Menüpunkt „Entwickleroptionen“, der vorher nicht da war. Die öffnest du und suchst den Eintrag „App für simulierte Standorte auswählen“ (Android 9, auf 8 hieß er glaub ich „Falsche-Standorte-App“ oder so). Da tippst du drauf und wählst die in Schritt 1 installierte Provider-App, die sich da auch schon anbietet. Dann kannst du die Einstellungen wieder schließen.

3. Als Bluetooth-Gerät nutze ich das GT-750FL, das es für etwa 40 € gibt. Nach meinen Testläufen arbeitet es sogar präziser als teurere Geräte. Schalt es ein, geh im Handy in die Bluetooth-Einstellungen und kopple die beiden Geräte. Der Zahlencode lautet 0000. Verbinden musst du sie nicht, das macht die Provider-App dann schon. Sie müssen sich nur „kennen“.

4. Öffne jetzt nochmal die Provider-App und geh dort in die Einstellungen (das Dreipunktemenü rechts oben): Ganz oben unter „GPS-Empfänger auswählen“ findest du das eben gekoppelte Gerät und wählst es aus. Unter „GPS Typ“ (ziemlich weit unten) wählst du den Chip deines Gerätes aus. Für das GT-750 ist das SiRF, für Navilock MTK. Die anderen Einstellungen kannst du lassen, wie sie sind.

Verwendung

Schalt das externe GPS ein, warte ein paar Sekunden (bis es bluetooth-bereit ist) und starte dann die Provider-App auf dem Handy. Rechts unten ist ein großer blauer Startknopf, der anfangs ein „Pause“-Zeichen zeigt. Dort tippst du drauf. Ab diesem Moment ist die Provider-App (und damit das externe GPS-Gerät) die GPS-Quelle für das gesamte Handy. In der Statusleiste erscheint ein kreisförmiges Icon mit vier Zacken, das zunächst innen leer ist. Wenn einige Sekunden keine GPS-Daten kommen, wird das Icon durchgestrichen.

Sobald GPS-Daten vorliegen, erscheint eine Balkenanzeige der verfügbaren Satelliten und Signalstärken. Im eben noch leeren Icon erscheint ein fetter Punkt. Das Handy hält jetzt die GPS-Position deines Bluetooth-Gerätes für seine eigene. Die Provider-App kannst du wieder vom Bildschirm wischen, sie läuft im Hintergrund weiter.

Wenn du wieder zurück aufs eingebaute GPS wechseln willst, drück in der Provider-App nochmals auf den Startknopf. Warte, bis das Icon aus der Statusleiste verschwindet (das Symbol im Startknopf ändert sich dabei nicht zwangsläufig, das Icon entscheidet). Ab jetzt ist wieder das eingebaute GPS die systemweite Quelle. So kannst du jederzeit umschalten, du musst dafür nichts in den Einstellungen ändern.

Tipps

• Das GPS-Empfangsmodul sitzt beim GT-750 auf der LED-Seite unter der „leeren Fläche“. Trag das Gerät also am besten mit den LEDs nach oben unter der Mütze.
• Wenn du während einer Trackaufzeichnung die Quelle wechselst, dann halt die Aufzeichnung dafür kurz an. Im Wechsel-Moment kann nämlich alles mögliche passieren. Ich bin schon mal während einer Wanderung in einer Sekunde aus dem Taunus nach Sibirien gesprungen und in der nächsten wieder zurück. Das kann man hinterher rausschneiden, aber bis dahin wird eine Tracklänge von einigen tausend km angezeigt.
• Externe GPSe haben in der Regel keinen eigenen Mobilfunk- oder WLAN-Empfang und können daher die (für maximale Präzision nötigen) aktuellen Korrekturdaten nicht wie das Handy über A-GPS anfordern, sondern müssen sie mühsam aus den GPS-Datenpaketen auslesen. Das geht auch, dauert aber ein paar Minuten. Schalt es für eine genaue Messung am besten 10 Minuten vorher ein.
• In den Einstellungen der Provider-App gibt es die Möglichkeit, bei schlechten Daten (Icon durchgestrichen) einen Warnton auszugeben. Da mein GT-750 manchmal spinnt (man muss es dann aus- und einschalten), finde ich das sehr praktisch, wenn das Handy in der Tasche ist :-)

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).

Nehmen wir weiterhin an, die zwei Gebäude stehen diagonal versetzt. Damit sind in jeder Richtung mindestens vier Fluchtpunkte aufzunehmen, am einfachsten von den umgebenden Straßen aus, wo man einen guten Blick auf die Baustelle hat.

Das heißt: Ich suche im freien Empfangsfeld, möglichst weit von allen Gebäuden entfernt, Punkte auf, die genau in der Verlängerung der Wände stehen. Einfach dort hinstellen, wo der Blick exakt an einer Außenwand entlangläuft. Und dort setze ich einen Wegpunkt in der GPX-Aufzeichnung.

Ich habe mir angewöhnt, parallele Linien gleich zu bezeichnen. Hier heißen die von Nord nach Süd gesehenen „F1“ und die von West nach Ost gesehenen „F2“:

Praktisch ist, dass man bei der Peilung einer Fluchtlinie ein paar Sekunden stillsteht, bevor man den GPX-Wegpunkt setzt. Das gibt dem GPS-Empfänger Gelegenheit, seine aus der Bewegung kommende Messung noch etwas zu präzisieren – in Bewegung macht er das nämlich nicht so gern und geht auch immer etwas „nach“. Fern von störenden Wänden kann man so auch mit Consumergeräten auf 1 m Genauigkeit kommen.

Zu Hause lade ich das GPX in JOSM, mache eine neue Datenebene auf und ziehe von meinen acht Fluchtpunkten Hilfslinien auf die Baustelle. Ganz normale Linien mit der Zeichenfunktion. In welche Richtung die laufen, das muss ich mir freilich merken (z.B. parallel zur Hauptstraße) – oder ich bin so schlau, mindestens eine der Fluchtlinien von beiden Seiten aus zu markieren, so dass ich nur die beiden Markierungen verbinden muss:

Fast fertig. Auf die richtigen Kreuzungspunkte der Hilfslinien (Foto hilft) setze ich meine Gebäude:

… und dann sind nur noch die Hilfslinien wieder zu löschen, damit die nicht mit hochgeladen werden:

Nur noch mit Q rechtwinklig machen, fertig ist der Lack. Die zwei Gebäude stehen jetzt mit genau der Präzision da, die sich von GPS im freien Feld erwarten lässt. Ohne die Baustelle zu betreten oder sonstwas Verbotenes zu machen. Und sehr viel genauer, als wenn ich die Gebäude umlaufen hätte.

Mit etwas Übung lassen sich so auch komplexere Formen erfassen.

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.

Warum das doch nicht so optimal ist, sehen wir, wenn wir mal annehmen, wir kommen von Osten und wollen nach Norden. Für unser Navi sieht der Fahrweg so aus: Erst geht es scharf nach rechts, fünf Meter weiter ebenso scharf nach links. Nach diesem ersten Stunt wird ein erholsamer Bogen nach rechts gefahren, an dessen Ende es wieder scharf nach links und dann – jetzt noch eher und fast rechtwinklig – wieder scharf nach rechts geht. Dann noch eine harte S-Kurve mit zweimal 45° Richtungsänderung, und – puh! – wir können wieder durchatmen.

Sorry, das kann’s nicht sein. Real ist das mitnichten so ein vielkurviges Manöver. Real wird das Lenkrad einmal kurz und leicht nach rechts gedreht und dann wieder zurück. Mehr nicht.

In meinem Mappinstil sieht die Kreuzung so aus (bereits mit hervorgehobenen Fahrweg): Ist das nicht eher das, was auch wirklich gefahren wird? Drei kleine Knicke sind noch drin. Lassen sich kaum vermeiden. Aber insgesamt ist das IMHO so dicht wie möglich an der Wirklichkeit, solange wir Straßen als Linien abbilden, also deren Breite irgendwie vernachlässigen. Jedenfalls wird jetzt in OSM wie auch in echt die ganze Zeit sanft nach rechts gefahren, kein Zickzack. Gefällt mir wesentlich besser.

Das mache ich immer so, wenn ich mit einer Kreuzung fertig bin: Ich gehe alle möglichen Durchfahr- und Abbiegevorgänge durch und achte darauf, ob die so realitätsnah wie möglich abgebildet sind – keine zu spitzen Winkel, keine Linkskurven, wo nach rechts gefahren wird (wie oben, das gilt natürlich auch umgekehrt).

Ich höre schon zwei Einwände, deshalb nehme ich sie vorweg:

Die Ways der Rechtsabbiegerampen sind nicht in der Mitte!

Ja. Und? Müssen sie das? Auf der B 56 ist der Way auf der Mittellinie, da fahren wir auch die ganze Zeit fünf Meter daneben lang, ohne dass das jemanden stört. Warum soll das jetzt auf einmal schlimm sein? Hat dir dein Navi schon mal gesagt „Du fährst fünf Meter neben dem Way, fahr bitte fünf Meter weiter links!“? Quatsch. Dein Navi weiß, dass du auf einer Straße fährst, die eine Breite hat, und nicht auf einer Linie, von der du keinen Meter abweichen dürftest. Dein Navi denkt sich den OSM-Way auf deine seitliche Position.

Normalerweise lassen wir die OSM-Ways in der Straßenmitte laufen, richtig. Das ist auch gut so. Aber bei kurzen Abbiegerampen ist das für mich eine Frage der Kompromisse: Lieber lege ich den Way etwas daneben, als ihn in einer Form anbinden zu müssen, die mit dem tatsächlich gefahrenen Abbiegevorgang nicht mehr viel zu tun hat.

Wir müssen (und können!) gar nicht die geographische Lage des Fahrweges zentimetergenau abbilden. Das ginge nur mit einem Way pro Fahrspur. Wir sollten aber seine Form, seinen Verlauf, realistisch abbilden. Die Position der Abbiegung sollte in Vorne-Hinten-Richtung stimmen, damit das Navi im richtigen Moment „jetzt abbiegen“ sagen kann. Wo sie in Links-Rechts-Richtung sitzt, ist dem Navi dabei ziemlich wurscht. Muss es auch, wenn ein einziger Way eine Straße mit mehreren Spuren repräsentiert.

Deine Rechtsabbiege-Ways fahren über durchgezogene Linien, das darf man nicht!

Der erste Teil stimmt. Der zweite auch. Aber sie haben nichts miteinander zu tun! Der Way bedeutet ja nicht „Fahr exakt hier lang“. Wenn er das bedeutete, dann müssten wir vorher auch auf der Mittellinie fahren. Siehe auch letzte Antwort zum Thema exakte Lage.

Natürlich muss der Abbiegeway in OSM an dem Way ansetzen, auf dem man kommt. Aber man beginnt ja nicht auf dieser geographischen Position (also auf der Mittellinie der Straße) mit dem Rechtsabbiegevorgang, sondern viel weiter rechts, und deshalb muss man auch nicht über die durchgezogene Linie fahren, obwohl der Abbiegeway, der zwangsläufig weiter links ansetzen muss, das tut. Der Abbiegeway ist keine exakt festgelegte Fahrlinie, sondern eine abstrahierende Abbildung des Sachverhalts „hier zweigt die Abbiegerampe ab“, und diese abstrahierende Abbildung darf ohne Weiteres über durchgezogene Linien verlaufen. Nur Fahrzeuge dürfen das nicht, sie tun es aber auch nicht, weil sie sich den Abbiegeknoten einfach zehn Meter nach rechts denken, auf ihre seitliche Position.

TL;DR: Sollte ich dich nicht überzeugt haben, solltest du also weiterhin Abbiegerampen lieber mit kurzen, scharf abbiegenden Verbindungsstücken mappen, dann bitte ich dich, diese kurzen Verbindungsstücke (und nur die) mit placement=transition zu taggen, um maschinenlesbar klarzustellen, dass sie nur der datenlogischen Anbindung dienen und keine tatsächlich gefahrenen Wege darstellen.

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:

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

Das ist etwas weniger elegant, weil die Vormittags-Öffnungszeit in beiden Regeln steht, aber hier überschreibt sich nichts. Das funktioniert auf jeden Fall, und hier ist das Semikolon richtig, es sind ja zwei unabhängige Regelsätze für unterschiedliche Wochentage.

Andererseits kann man sich das Überschreiben durch einen neuen Regelsatz sogar zunutze machen, indem man die geschlossenen Nachmittage aus einer zu reichlichen Angabe nachträglich „ausschneidet“, mit einer off-Regel:

opening_hours = Mo-Fr 08:00-12:00,14:00-18:00; Mo,We,Fr 14:00-18:00 off

funktioniert auch. Hier ist das Semikolon richtig, die off-Regel überschreibt wegen ihrer Zeitangabe nur die Nachmittage.

Es gibt also mehrere richtige Wege, so was einzutragen, leider auch einige falsche.

Ein zweiter beliebter Fehler betrifft die Regelung „oder nach Vereinbarung“, englisch „on appointment“. Das wird hinten dran gesetzt, aber nicht mit Semikolon (dann würde es alle anderen Regeln überschreiben und nur „nach Vereinbarung“ gelten), sondern mit zwei senkrechten Strichen || abgetrennt – das heißt „zu allen anderen Zeiten gilt das hier“.

Es ist nicht ganz einfach, deshalb trifft man mich auch oft noch auf dem evaluation_tool an. Ist keine Schande.

Und denkt bitte immer an die Feiertage – an alles, was feiertags geschlossen ist, gehört ein PH off hinten dran, mit Semikolon :)

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.

Es gibt etliche Tankstellen, die ausschließlich Autogas anbieten (vor allem bei Autohäusern oder Gashändlern). Da hier bei Undichtigkeiten nichts im Boden versickert, sondern alles, was eventuell austritt, sofort verdampft, muss nur ein großer Tank mit Zapfsäule und Bezahlautomat hingestellt werden, fertig ist die Tankstelle, bauliche Maßnahmen am Boden wie z.B. Ölabscheider sind nicht nötig.

Englisch heißt das Zeux „Liquified Petroleum Gas“ (LPG). Die Franzosen verdrehen das bedeutungsgleich zu GPL. Ist dasselbe. In Großbritannien ist die Bezeichnung „autogas“ ebenfalls üblich und wird richtig verstanden.

Erdgas

fuel:cng=yes

Bezeichnungen: Erdgas, CNG, Biogas, Methan …

Erdgas, chemisch hauptsächlich aus Methan bestehend, hat den Vorteil, noch sauberer zu verbrennen als das ohnehin schon sehr saubere Autogas. Allerdings den Nachteil, dass man es nicht mit vertretbaren Mitteln flüssig bekommt. Dazu müsste man es entweder irrsinnig komprimieren oder irrsinnig runterkühlen. Ist beides fürs Auto kaum machbar, deshalb tankt man es gasförmig bei ziemlich hohem Druck – ziemlich hoch, damit viel in den Tank passt und eine annehmbare Reichweite dabei rauskommt. Da kommen im Tank schon mal 200 bar zusammen (deshalb platzen sie auch gern, wenn sie schadhaft sind, was Autogastanks nicht machen). Getankt wird Erdgas über spezielle Druckanschlüsse (komplett andere als LPG) in gasförmigem Zustand, abgerechnet wird nach Kilogramm (Liter wäre bei einem Gas sinnlos, weil’s nichts über die Menge aussagt).

Biogas nennt man es, wenn das Methan nicht als Erdgas aus Bohrlöchern quillt, sondern durch Vergärung von Biomasse gewonnen wird. Auch das Faul- oder Klärgas von Kläranlagen sowie das Deponiegas von Abfalldeponien bestehen im Wesentlichen aus Methan.

Englisch heißt das Zeux „Compressed Natural Gas“ (CNG). Stark gekühlt in flüssigem Zustand gibt es das auch, das heißt dann „Liquified Natural Gas“ (LNG), aber das hab ich in Deutschland noch nicht gesehen.

TL;DR

Ist ein P drin, ist es Autogas. Ist ein N drin, ist es Erdgas.

Bei anderen alternativen Kraftstoffen wie Wasserstoff besteht wahrscheinlich keine Verwechslungsgefahr, oder?

Aber es gibt doch auch fuel:autogas=*!

Ja, leider – das finde ich doof, unnötig und sehr verwirrend. fuel:autogas=* hat nichts mit Flüssiggas zu tun, sondern ist für Flugplatztankstellen gedacht, wenn diese auch normalen Straßensprit anbieten (die einfacheren Motoren von Ultraleichtflugzeugen laufen damit am liebsten). Das Tag ist aber deshalb komplett daneben, weil kein Flieger dazu „Autogas“ sagt. Man sagt international „Mogas“ oder deutsch „Super plus“ (es ist mit dem Super Plus von der Autotankstelle identisch). Am besten wegwerfen (das Tag meine ich, nicht den Sprit). Aber eine Flugplatztankstelle gehört ohnehin aeroway=fuel getaggt, nicht amenity=fuel ;-)

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).

C Dieses Fenster bildet die Verbindung zum Haupt-Editorfenster (in dem du die Karte bearbeitest). Elemente, die im Haupteditor selektiert sind, erscheinen hier. Weiß hinterlegte sind noch nicht in der Relation, grün hinterlegte sind in der Relation, rot hinterlegte sind mehrfach in der Relation (was nicht unbedingt ein Fehler sein muss – wenn es zum Beispiel auf dem Wegstück erst hin und dann wieder zurück geht, ist das korrekt).

Die Schaltflächen ganz links betreffen Aktionen im Member-Fenster (B):

1 Verschieben von Members

2 Löschen von Members

3 Automatisches Sortieren der Members (nach sinnvoller Reihenfolge, so dass sich geschlossene Linienzüge ergeben).

4 Members, die noch nicht in der Arbeitsebene sind, vom Server laden.

Die Schaltflächen zwischen B und C betreffen Interaktionen:

5 Einträge aus C als Member in die Relation nehmen – ganz oben, ganz unten oder vor/hinter der aktuellen Selektion in B

6 Einträge aus C (=Selektion des Haupteditors) in B selektieren (sehr praktisch!)

7 In B selektierte Members im Haupteditor selektieren (erscheinen dann in C)

8 In C eingetragene Member (=Selektion des Haupteditors) aus der Relation entfernen (macht dasselbe wie 6 und 2 hintereinander)

9 (unter B) Allen in B selektierten Members eine bestimmte Role zuweisen

10 Relation neu aus dem Haupteditor in den Relationseditor einlesen. Wichtig, wenn man z.B. bei geöffnetem Relationseditor im Haupteditor einen Weg geteilt hat, so dass ein neuer Member entstanden ist! Sonst sind die Bearbeitungsstände am Ende nicht mehr vereinbar. Änderungen im Relationseditor bleiben natürlich erhalten.

11 Vorgenommene Änderungen im Haupteditorfenster anwenden. Erst nach Druck auf diese Schaltfläche werden Änderungen im Haupteditor wirksam! Immer drücken, bevor man im Haupteditor weiterarbeitet (der Relationseditor kann dafür geöffnet bleiben).

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

Fangen wir damit an, wo ich es schon angeteasert habe. Das kennzeichnet kleine Fahrspuren auf Parkplätzen, auf denen man zu einem bestimmten Abstellplatz gelangt. Aaaber: Zufahrten auf den Parkplatz und Durchfahrtswege über den Parkplatz sowie Verteiler-Fahrspuren, die zu mehreren Parkbereichen führen, sind keine service=parking_aisle, sondern highway=service ohne service=*-Zusatz! Siehe Wiki: The main way(s) on the parking lot, for entering and connecting multiple parking_aisle, should be mapped with highway=service, only. Da gibt’s auch ein sehr schönes Beispiel: Der breitere durchgehende Weg ist highway=service ohne service=parking_aisle. Ich hätte auch den nördlichen Bogen so getaggt, da er als Verteiler funktioniert.

service=driveway

Das wohl meistmissverstandene Tag ever. Ich habe den Eindruck, „driveway“ wird oftmals allzu wörtlich als „Fahrweg“ übersetzt und daraus geschlossen, dies sei das angemessene Tagging für jede Art kleiner Fahrwege. Das trifft aber nicht zu.

„driveway“ bezeichnet im Englischen vielmehr einen speziellen Fall, nämlich eine Ein- oder Auffahrt zu einem Privatgrundstück, also einen (meist sehr kurzen) Fahrweg aus dem öffentlichen Verkehrsraum heraus auf Privatbereich. Führende Online-Wörterbücher sehen das auch so. Und es steht so auch im Wiki: A driveway is a service road leading to a residential or business property, usually with access=private.

Das könnte zwar auch dazu verführen, eine kilometerlange Zufahrt zu einem außenliegenden Forsthaus so zu taggen, aber der letzte Teilsatz spricht dagegen: Das Wiki betrachtet service=driveway implizit als Privatweg, also größtenteils über Privatgrund laufend. Daraus folgt messerscharf, dass ein highway=service, von dem noch irgendwas anderes öffentlich Nutzbares abzweigt, und sei es ein Trampelpfad, in keinem Fall service=driveway ist.

Rendering

Übrigens: Diese beiden, parking_aisle und driveway, werden in Mapnik in Zoomleveln 15 oder kleiner nicht mehr dargestellt. Das hat die Nebenwirkung, dass davon abzweigende hw=track oder hw=path „in der Luft hängen“. Ja, wir mappen nicht für den Renderer, ich weiß. Aber wir mappen auch nicht gegen ihn. Und dieses Verhalten hat ja seinen Grund: Die Maintainer gehen offenbar auch davon aus, dass diese kleinen serviceways als reine Zufahrten unterhalb ZL 15 keine Bedeutung mehr haben (Pfade und Tracks aber sehr wohl!).

service=(gar nichts)

Es ist keinesfalls verboten oder unerwünscht, einen highway=service ganz ohne service=* zu mappen. Im Gegentum: Das Wiki empfiehlt es ja für Zufahrten zu Parkplätzen ausdrücklich so, siehe Link oben!

Ich persönlich mappe jede kleine Zufahrt erstmal highway=service ohne Zusatz und schaue dann, ob einer von den Zusätzen zutrifft:

• Reine Grundstückseinfahrt aus dem öffentlichen Verkehrsraum heraus, ohne weitere Abzweigungen oder Fortsetzungen? Könnte ohne Verluste access=private getaggt werden? Dann service=driveway.

• Durchfahrt über privates Gelände, etwa für eine Tankstelle – hier rein, da raus? Dann service=drive-through.

• Fahrspur auf Parkplatz, die ausschließlich dem Erreichen einer Parkposition dient, nicht der Fahrt zum oder über den Parkplatz? Dann service=parking_aisle.

• Kleine Gasse, die sich zwischen anderen Grundstücken oder Häusern hindurchzwängt? Dann service=alley.

• Nichts davon? Dann bleibt das service=*-Tag ungesetzt. Warum auch nicht?

–ks

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!

Ich kenne diesen Reflex. Aber in diesem Fall widerstehe ich ihm, denn ich kenne auch die Straße persönlich. Und die verläuft da genau so, wie sie gemappt ist – der Bogen nach Osten ist schlicht ein Fehler im Luftbild. Man könnte es anhand der relativ scharfen Knicke an den Enden schon ahnen, kein vernünftiger Mensch baut so was in eine Bundesstraße ein.

Tröstlicherweise ist auch die Vereinigung Hessischer GPX-Tracks mit überwältigender Mehrheit dieser Meinung:

Wie kommt es zu diesen Fehlern? Nun bin ich kein Fachmann im Geoingenieurwesen, aber ich reime es mir etwa so zusammen:

Nicht jeder Punkt des Luftbildes ist senkrecht von oben aufgenommen. Das geht ja gar nicht. Das Luftbild besteht aus vielen Einzelaufnahmen, und alle Punkte, die zufällig am Rand des Bildfeldes einer Einzelaufnahme lagen, wurden schräg fotografiert.

Aber das macht ja nichts – wenn da nicht das Gelände wäre.

Nimm zur Verdeutlichung mal an, rechts außen im Bild steht ein Aussichtsturm auf einem Berg. Dessen Turmspitze sollte einklich mittig über seiner Standfläche sein, von der Geoposition her, alles andere wäre für den Turm gar nicht gut. Ist sie aber nicht, weil der Turm schräg fotografiert wurde, er scheint auf dem Bild zu kippen, die Spitze ist weiter außen als die Grundfläche. Welcher Punkt des Turmes ist jetzt seine „richtige“ Position, wo setzt du den Node hin? Und jetzt kommt’s: Das gilt nicht nur für den Turm, sondern auch für den Berg, auf dem er steht. Auch der wurde schräg fotografiert und kippt deshalb nach außen (das fällt nur nicht so auf wie beim Turm).

Deshalb müssen Luftbilder aufwendig entzerrt werden: Man legt ein Höhenmodell des Geländes darüber, berechnet für ein Raster von Referenzpunkten den seitlichen Versatz, der sich aus Höhe und Aufnahmewinkel ergibt, und verbiegt das Bild entsprechend in die andere Richtung. Hoffentlich halbwegs zutreffend. Denn erstens kann dieses Referenzpunktraster nicht beliebig engmaschig werden, deshalb stimmt die Entzerrung immer nur im Mittel, und zweitens ist auch das Höhenmodell nicht metergenau und löst keine feinen Strukturen auf.

Wenn das klappt, steht das untere Ende unseres Turmes auf der richtigen Geoposition. Aber in einem engen Flusstal wie dem Aartal oben im Bild kann es da schnell passieren, dass entweder das Höhenmodell nicht genau genug ist oder die Referenzpunkte zufällig auf den Hängen statt im Talgrund liegen. Die Punkte dazwischen werden ausgemittelt, und schon haben wir den Salat – eine gerade Struktur wird ans Gelände angepasst. Weil die Software zufällig auf die Hänge korrigierte, nicht aufs Tal.

TL;DR: Auch Bing verkündet kein Evangelium. Die Luftbilder müssen entzerrt werden, um einigermaßen lagegenau zu sein, und diese Entzerrung hat ihre technischen Grenzen. Die genaueste Quelle ist immer noch Ortskenntnis und eine Vielzahl von GPS-Tracks, deren Messfehler sich ausmittelt.

STL;SDR: Bing ist keine Referenz, Bing ist ein Werkzeug.

–ks

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.

Das mag die Realität besser (im Sinne von präziser) wiedergeben. Aber mit den beiden Spuren ist es nicht getan. Jetzt muß man nämlich 1. die Abbiegespuren auf der B8 anpassen (die Rechtsabbiegespuren enden ja dort, wo die Abbiegebahnen beginnen). Dafür muss der Way hier aufgeteilt werden. Als nächstes muß der Kollege bei der Einmündung in die L 3023 das scharfe Linksabbiegen verbieten (Wendeverbot, ergibt sich aus der Sperrfläche) und auch hier den Way aufteilen als „to“ für die Abbiegebeschränkung. Dann muß am „Hauptkreuzungsnode“ das Rechtsabbiegen verboten werden, außerdem das scharfe Linksabbiegen aus der Gegenrichtung in die Rechtsabbiegerbahnen. Und das in beiden Richtungen. Voll ausgebaut sieht unsere Kreuzung so aus: Im Vergleich zu Bild 1 haben wir hier:

• 4 Nodes und 6 Ways mehr (davon 4 durch das Aufteilen der bestehenden Straßen)
• 6 Relationen mehr (Abbiegebeschränkungen).

Aber das ist ja noch nicht alles. Jetzt kommt der übernächste Mapper und teilt die jeweils 12 Meter der L 3023 an den Verkehrsinseln in separate Ways auf (was so nicht OSM-konform ist, dafür gibt es nämlich traffic_calming=island, aber egal). Abgesehen davon, dass dann die separaten Ways gern spitzwinklig gemeinsam auf die B8 geführt werden (oder man hat man beim Wendeverbot ein Stück way in der via-Role), was dazu führt, daß ein Navi, das nach rechts auf die B8 abbiegen will, eine Richtungsänderung von deutlich über 90 Grad sieht (was falsch ist), braucht das nochmal einen Sack Abbiegebeschränkungen und Way-Aufteilungen.

Und da frag ich mich dann wirklich: Ist es das wert? Brauchen wir Kreuzungen so exakt? Die einfache im oberen Bild funktioniert nämlich auch.

Und präzisestes Kreuzungsmappen hat auch einen Nachteil: Der Pflegeaufwand steigt enorm. Immer an den nächsten Mapper denken, du wirst das vermutlich nicht selbst weiterpflegen. Wird in 10 Jahren eine Buslinie einmal umgelegt, muss man hier höllisch aufpassen, auch alle Richtungen richtig in die Busrelationen aufzunehmen – statt einfach die zwei Straßen im oberen Bild.

Mein Appell an alle Kollegen: Keep it simple. Unsere Datenbank ist komplex genug mit den Details, die rein müssen. Und bestimmt gibt es in eurer Nähe noch ein Fleckchen, wo Hausnummern fehlen. Die sind wichtiger, adreßgenaues Routen wird heute erwartet, auch von OSM-basierten Navi-Systemen.

–ks