Danke für eure warmen Worte, aber ich habe mich da in eine Vorstellung verrannt, die mir nicht gut tut und die mich unter Stress setzt: die Vorstellung, man könne die Richtigkeitsquote von OSM-Daten verbessern, indem man lokal gute Beispiele liefert oder Kollegen auf Fehler aufmerksam macht. Für letzteres fehlt mir ganz offensichtlich das Fingerspitzengefühl, den richtigen Tonfall zu treffen. Ich versuche es sachlich, und es kommt überheblich und herablassend rüber. Und ersteres unterliegt einer Erosion durch Kollegen, die nicht meinen Ehrgeiz teilen, dass jedes hochgeladene CS eine Verbesserung sein sollte im Sinne einer Exaktheit und Übereinstimmung der Daten mit der Wirklichkeit. Ich werde deshalb immer wieder an meinem Perfektionismus verzweifeln, und das tut weder mir selbst noch dem Projekt auf Dauer gut. Mag sein, dass ich ein verschrobener Sonderling bin, aber dann muss ich mich lockern und nicht noch weiter verkrampfen, und dabei hilft mir OSM leider gar nicht.

Bei mir tut sie’s wie die andere. Haken bei „Enable Mock GPS Provider“ ist gesetzt?

Probier mal „Bluetooth GPS“, das scheint ähnlich zu funktionieren. Die oben angesprochene App gibt’s zum Beispiel bei apkpure (https://apkpure.com/de/bluetooth-gps-provider/de.mobilej.btgps).

Ich hab meinen normal auf dem Armaturenbrett liegen – das war auch eine Zusatzidee, das Handy für mapillary-Aufnahmen möglichst hoch an der WSS zu montieren, wo es keinen guten GPS-Empfang mehr hat, und GPS per Bluetooth einzuspielen. Hat leider einen Haken: So präzise das GT-750 bei langsamen Geschwindigkeiten ist, in gefahrenen Kurven „überschießt“ der Track erstmal und hängt dann für ein paar Dutzend Meter außerhalb der Straße, bevor er sich wieder zurückmogelt. Das geht für mapillary gerade noch, wo es nicht auf die exakte Position ankommt, aber für einen mappingfähigen Track reicht mir das nicht mehr.

Nein, man muss die App auf einen Empfänger festlegen. Zwei Empfänger dicht nebeneinander könnten sogar einander stören (jede Empfangsantenne sendet auch wieder), so dass das Gesamtergebnis eher schlechter wird.

I haven’t done any scientific research on this but I don’t think there is a considerable power saving effect on the phone. The Provider app draws current as well as the bluetooth hardware does, and the external device has to be recharged as well.

Hallo Lokalfuerst! Am einfachsten taggt man die Verkehrsinsel als traffic_calming=island an den Straßenabschnitt. Damit wird es dem Navi überlassen, den Fahrer darauf hinzuweisen, und über die genaue Geometrie wird nichts ausgesagt. Immer häufiger wird der Way an solchen Stellen tatsächlich aufgeteilt und die Geometrie abgebildet. Das ist natürlich in Ordnung, aber wenn man dann die Ways von der Fahrbahnmitte auf die Einzelspurmitten legt, entstehen auch leicht überscharfe Richtungsänderungen – viel Platz hat man ja auch nicht an einer 20 Meter langen Aufteilung. Ich lasse die Einzel-Ways dann gern an der Kante der Insel entlanglaufen, dann stimmt die Geometrie in der Darstellung wieder. Ganz wichtig: Wendeverbote an beide Enden setzen, sonst sieht das für einen Router wie eine willkommene Wendestelle aus.

Ich trau mich kaum, es zu sagen, aber vorher war die Ampel auf dem Hauptkreuzungsnode. Ich finde es aber generell schöner, die Ampeln in etwa an die jeweiligen Haltelinien zu packen und bei Nicht-Einbahn-Ways halt mit direction=* zu versehen (damit ein geradeaus fahrender Router nicht zwei Ampeln sieht, wo nur eine ist). Aber das kann man so oder so machen, inhaltlich ist es kein Unterschied, technisch brauchen fünf Tags auch nicht sooo viel mehr Speicherplatz als eines.

Ellipse: Wenn ich schon aufteile, dann alles, was baulich getrennt ist, keine halben Sachen. (Hab ich mal anders gesehen, siehe unterster Blogeintrag.) Vorteil: Wenn da noch ein Fußgängerüberweg durchgebaut wird, sind alle einzelnen Übergänge gleich separat da.

Wären die von Norden kommenden Rechtsabbieger nicht baulich getrennt, müsste dieser Way natürlich rechtwinklig auftreffen (schiefe Ellipse), um keinen zu steilen Abbiegewinkel nach rechts zu erzeugen. Aber so wie hier geht es symmetrisch-schräg.

Nachbemerkung, falls du die Kreuzung persönlich kennst: Ich habe das Beispiel überspitzt, und es ist auch wirklich nur ein Beispiel. Die Kreuzung war nie so gemappt wie oben (ist jetzt aber so wie unten). Deshalb mache ich auch keinem Vormapper einen konkreten Vorwurf. Aber ich habe in der Gegend Ähnliches gefunden, und wo ich schon mal dabei war …

Einerseits halte ich das für eine ganz schlechte Idee. Was passiert, wenn es gar keine Sperrfläche gibt? Dann läuft der Weg außerhalb der Fahrbahn.

Fände ich zunächst ebenfalls nicht weiter schlimm – zumindest weniger schlimm, als eine einfache runde Abbiegerampe als Zickzacklinie zu mappen, die überhaupt nicht der tatsächlichen Form der gefahrenen Kurve entspricht.

Wenn wir dann noch Fahrbahnflächen erfassen, liegt der Weg somit auch außerhalb der erfassten Fläche und wir bekommen ein Zuordnungsproblem.

Das kann tatsächlich ein Problem sein, wenn die Zuordnung nur über die geospatiale Lage vorgenommen wird (und nicht beispielsweise über Relationen, was die Sache aber wieder verkompliziert).

Mein Vorschlag wäre daher wie Methode III zu verfahren, jedoch den Querschritt rechtwinklig durchzuführen, und durch geignetes Tagging zu kennzeichnen, dass diese erste Kante des abzweigenden Weges rein virtuell ist.

Damit meinst du placement=transition, seit über 5 Jahren proposed. Wenn das wirklich flächendeckend ausgewertet und zuverlässig verwendet wird, kann ich mich dafür erwärmen. Bis dahin ist mir die Geometrie gefahrener Wege wichtiger als deren metergenaue Lage (was sowieso nicht geht, solange wir auch 30 m breite Fahrbahnen als einen einzigen Way mappen, was aber bekanntlich sein muss, um die Spurwechselmöglichkeit abzubilden). Eine gefahrene stetige Rechtskurve ist daher bei mir auch in OSM eine stetige Rechtskurve, die zwar so weit wie möglich mit der Lage der Fahrbahn im kalibrierten Luftbild übereinstimmt, aber an den Enden zugunsten einer sauberen Geometrieabbildung Kompromisse in der Lageexaktheit eingeht.

–ks

Die Nachteile von Methode III entfallen, wenn man den überschrägen „Querschritt“ weglässt und es in Kauf nimmt, dass der abbiegende Way bis zum ersten Node der Rampe über die Sperrfläche verläuft.

Das finde ich überhaupt nicht tragisch, sondern im Gegentum höchst elegant.

Begründung: Die OSM-Ways stellen keineswegs ideale, fest georeferenzierte Fahrlinien dar (dann müssten wir wirklich einzelne Fahrspuren mappen), sondern lediglich eine Abstraktion der Straßenvernetzung. In diesem Fall muss abstrahiert dargestellt werden: HIER zweigt eine eigene Fahrbahn ab, die dann HIER langgeht. Da wird es niemanden verwirren und erst recht niemanden zur vorsätzlichen Fahrt über die durchgezogene Linie verleiten, wenn der OSM-Way da rübergeht. Er muss das nur deshalb machen, weil er notgedrungen auf der lateralen Position des Ausgangs-Ways beginnt (links von mir) statt an meiner aktuellen Fahrposition.

In der Routerdarstellung während der Fahrt sehe ich ja gar nicht „oha, ich bin 5 Meter rechts vom OSM-Way“, sondern der Router stellt den weiteren Fahrweg immer bezüglich meiner aktuellen Position dar. Auch wenn der OSM-Way auf der linken von vier Spuren liegt und ich auf der rechten fahre, sehe ich „geradeaus“ und nicht „die Richtung stimmt zwar, aber ich bin 15 Meter zu weit rechts“.

–ks

Wenn man den Su nochmal extra aufführen will, gehört da ein Komma hin, ja :) oder separate Regeln: Su off; PH off.

Die Vorteile von Methode 3: * Alle Nodes des zu korrigierenden Teilumrisses bleiben mit ID erhalten, keiner wird gelöscht (sie ändern nur die Position) * Es wird kein neues Objekt erzeugt (bei Methode 4 muss man darauf achten, dass das zu löschende Objekt das neue ist, um die ID und damit die History des alten zu erhalten).

Methode 3 und 4 gehen einfacher, wenn man den Hilfsweg nicht Node für Node zeichnet, sondern eine Parallele aus dem Highway zieht (Shift-P in JOSM). Dann geht die Kante des landuse exakt parallel zum Highway, ohne dass man Node für Node auf Position schieben muss. Und für ein so präzises Ergebnis ist das die schnellste Methode.

Voilà: https://de.wikipedia.org/wiki/Fl%C3%BCssiggas-Tankadapter

Halte ich für unnötig, an der Zapfstelle steht’s ja dran. Ich wollte mal einen Wikipädieartikel über die LPG-Adapter verfassen, der ist aber noch nicht übers Rohstadium rausgekommen: https://de.wikipedia.org/wiki/Benutzer:Kreuzschnabel/Flüssiggas-Adapter

Der Zahn der Zeit … jetzt erwische ich mich auch schon beim Kreuzungs-Ausbau!

–ks

JFTR: The European end was in the Netherlands, not in Germany.

Ich fahre alle paar Wochen dort entlang. Mindestens drei der Tracks sind von mir, in einigen Wochen Abstand aufgenommen.

Der letzte Satz war nicht so wörtlich gemeint, mehr eine flapsige Schlussbemerkung. Aber ich hab’s mal geändert.

Danke für deine Ergänzungen – wie gesagt, ich bin da nicht vom Fach. Nun hat allerdings Brandenburg meines Wissens die Angewohnheit, relativ eben zu sein, da kommt man mit minimalen Korrekturmaßnahmen aus. Hier im Mittelgebirge sind nicht nur die Höhenunterschiede größer, sondern vor allem die Gradienten, man braucht für eine gute Entzerrung also deutlich mehr Referenzpunkte.