Sparsamkeitsgebot Way-Splits

Das Problem besteht schon ab einer Straße, die mit zwei Einzelsegmenten gemappt ist. Na klar, je mehr Einzelsegmente, je höher die Gefahr.

Was wären Bearbeitungen bzw. Wartungsarbeiten, wofür man die gesamte Straße auswählt? Taggingschemaänderungen?
Gibt es von Editoren wie JOSM kein Feature, mit dem man alle Teile einer Straße auswählen kann? Mit iD geht es wahrscheinlich bei langen Straßen nicht, weil der nur anwählen kann, was im aktuellen Kartenausschnitt im Browser sichtbar ist.

Lustig will ich mich nicht machen, aber es zeigt halt das dass jetztige System nicht optimal ist. Die Leute machen das ja nicht absichtlich, sondern sie wissen es halt nicht besser… :confused: da kann man keinen Vorwurf machen wenn was kaputt geht.

Und der Anspruch sollte halt auch sein das dass ganze auch ohne JOSM noch bearbeitbar bleibt, alles andere ist eine Entwicklung in die falsche Richtung.

Beispiele wären: Eigenschaften ergänzen (surface, smoothness, lit, maxspeed, name etc.), sich geänderte Eigenschaften updaten (ref, maxspeed, etc.), Typos bei Straßennamen fixen.

Was die konkreten Anwendungsfälle sind hängt davon ab, wie weit die Karte in dem Bereich schon entwickelt ist. Insbesondere wäre das nützlich wenn man bei größeren Straßen Eigenschaften wie lanes ergänzen muss, oder viele Stücke derselben Straße z.B. in eine Route-Relation einfügen will.

Mit Overpass und Filtern ist es kein Problem alle gewünschten Wege in JOSM auszuwählen. Ticket 20809 sollte eine weiter Option bieten.

In meiner Gegend, bin ich die ganze Zeit am entkleben und am Ergänzen von foot=use_sidepath und path=sidewalk und/oder is_sidepath[:*].
Häufig finde ich auch sidewalk=no und foot=no obwohl es ein Trottoir/Seitenweg gibt. Viele dieser Ungenauigkeiten muss ich leider der Fahrrad-Crew anlasten.

Wenn ich Wege aufteile, schaue ich mir immer an, ob ich nicht eine Hälfte/beide Endstücke mit den angrenzenden Wegen vereinigen kann. Hier könnte die Editor-Software mehr Unterstützung anbieten, allerdings braucht es einen genauen Blick auf alle Attribute und Mitgliedschaften.

Und wie wird dort der Zusammenhang zwischen Straße und ihren Seitenwegen in den Daten erfasst?
Gibt es Regelungen wie das Nutzungsgebot für Seitenwege für bestimmte Fortbewegungsarten?

Und wie funktioniert dann das Routing, insbesondere der Wechsel zwischen den beiden Wegen, und wie werden die beiden Wege als eine Einheit dargestellt? Wird ein area:highway als zusätzliches Objekt verwendet?

Muss? Bitte doch die Personen, die diese Konstrukte erstellt haben, sich darum zu kümmern. Das Hauptproblem ist auch hier die Kommunikation und die Software, die nicht entsprechende Warnung gibt bzw. manche Änderungen gar nicht zulässt.

Bitte nicht, damit geht jeder Bezug verloren und es macht kein Spaß erst alles zurückzusetzen, um die Änderungen nachzuvollziehen.

Habe ich kein Problem mit. Wenn das entsprechend im CS steht und eventuell noch per PM oder hier im Forum um Hilfe gebeten wird, um so besser.

ja, mit den Filtern kann man das machen, vor allem bei längeren Straßennamen ist das aber mehr Arbeit als die ways zu klicken (und es lohnt kaum, weil man sie wahrscheinlich nicht wieder braucht), der Vorteil ist, dass man sehr kurze Stücke nicht übersieht.

Vielleicht setzt ja jemand dein oder mein Ticket um, würde mich freuen.

Mmh, vielleicht würde auch eine Verbindungsanzeige in der Auswahlliste (selection panel) analog zum Relation Editor helfen.

Das hätte den Nachtteil, dass damit die Anwendungsfälle, in denen man wissen will, wo Busse herfahren, nicht abgedeckt würden. Ich denke zum Beispiel an Fälle von eher engen Straßen, vielleicht ohne Bürgersteig. Da könnte es dann zu einer starken Konkurrenz zwischen Fußgängern, Bussen und Radfahrern kommen. Wenn man in die Relation alle Straßenabschnitte aufnimmt, wo die Busse fahren, könnte man gegebenenfalls andere Verkehrsteilnehmer da herumrouten, vielleicht sogar abhängig vom Busfahrplan (der aus einer externen Quelle stammt).

Aber gibt es denn von den Verkehrsunternehmen überhaupt eine Zusage über “der Bus fährt diese Haltestelle an” hinaus? Könnten die sich das nicht jeden Tag anders überlegen, wo sie ihren Bus fahren lassen?

Im Prinzip ja, und neue, nicht orts-kundige Fahrer bekommen selbst das: “der Bus fährt diese Haltestelle an” nicht immer hin.

Rein daten-technisch braucht’s weder die Member-ways noch die potentielle Member-Stützpunkte.

Nur wenn man die Fahrstrecke in echt und korrekt auf Karten projizieren will … dann ja, dann braucht’s Unterstützung für die Renderer, oder liege ich da falsch?

Wär jedenfalls komplexer für Renderer, eine Route anzuzeigen.

Aber auf der anderen Seite wären dann route-Relationen sehr einfach zu maintainen. Das ist nicht nur gut für die Mapper, sondern letztlich auch für die Nutzer dieser Daten, die nicht ständig mit kaputten (=lückenhaften) Relationen rechnen müssen.

Ja

Eher nicht. Der Editor muss mir eine Vorschau mit dem gleichen Router erstellen den alle Kartenanbieter auch verwenden. Das könnte noch umsetzbar sein. Änderungen am Router machen diverse Routen kaputt. Sprich der Router muss auf alle Ewigkeit konstant bleiben.
Das größte Problem ist der exakte Verlauf ist nie gespeichert.

Als Anwender möchte ich bei einer Wanderroute/Radroute ihrem Verlauf exakt folgen. Denn da haben sich idR Menschen einen Kopf gemacht und eine schöne Route ausgewählt. Wenn ich ein von Stütpunkt zu Stützpunkt geroutetet Etwas haben möchte, kann ich das auch selber mit jedem Router erstellen.

Bei einer Busroute ist das was anderes. Da bin ich Passagier, da fahre ich mit und als Anwedner ist mir lediglich wichtig, dass ich weiß an welcher Haltestelle mein Bus abfährt, wo ich umsteigen muss und wo ich Aussteigen muss. Da kann das sehr gut mit solchen Konstrukten funktionieren.

Hallo Simon,
es gäbe da noch:

  • man müsste die Geometrie (Nodes, Ways) von den Eigenschaften trennen. Bspw. name=Schulstraße sollte quasi eine collection (=relation) aus den Wegsegmenten sein, die zu dieser Schulstraße gehören. Es ließe sich im aktuellen Datenmodell umetzen, aktuelle Software, die Routenrelationen verwursten kann, kann auch damit umgehen. Per Definition müssen die Mitglieder alle verbunden sein oder nur ein Objekt beinhalten. Sprich vor einem Speichern kann ein Editor oder aber die API das validieren.

Meinst du https://wiki.openstreetmap.org/wiki/Relation:street ? Als Lösung für Probleme aus Relationen scheint eine Relation immer noch das Beste! Sie löst aber auch andere Probleme: In Boston (USA) ist das verbreitet, nicht zuletzt können damit die separat erfassten Bürgersteige wieder an die Straße gebunden werden.

PS: Ob diese regionale Eigenheit mit dem MIT zu tun hat?
PPS: Allerdings sieht es nach Stichproben ein wenig danach aus, dass auch dort die Zusammensammler den Splittern hinterherhinken.

Die type=street bzw. type=associatedStreet Relationen wären schön, wenn sie die einzige Möglichkeit wären, einen Namen anzugeben. So aber sind sie für den Datenverarbeiter eine Quelle für Sonderfälle (z.B. unterschiedliche Namen in den Membern, einzelne Teile, die in der Relation fehlen usw.)

Ich habe diesen Thread mal auf OSM Slack US gepostet.

Ein paar Kommentare von dort:

Max Erickson wies darauf hin, dass es schon ein Proposal gibt um Routen-Relationen zu vereinfachen so wie es Frederick angedeutet hat: https://wiki.openstreetmap.org/wiki/Proposed_features/Simpler_public_transport_route_relations . Offenbar wurde es auch schon auf einer Mailingliste diskutiert (habe jetzt keinen Link)

Bryan Housel warf ein, dass für einige Busrouten, insbesondere solche mit keinen festen Haltestellen bei denen man quasi überall entlang der Route ein- und aussteigen kann wenn man den Busfahrer bescheid gibt die genaue Route eben doch wichtig ist.

Ein längerer Beitrag von Minh Nguyen, hier mal als Zitat aber halbautomatisch ins deutsche übersetzt:

Könnte man auch über Routing machen, Vorschlag war von mir… die Route optimal zu machen. Dann kann der Datenverwerter… die Route aus der Relation nehmen wenn vorhanden und gut… oder Routing anwenden.

Gegenbeispiel: Rufbus/taxi… hier gibt es teilweise überhaupt keine feste Route, was ein hinzufügen einer Route unmöglich macht. Zum Beispiel weil der Bus/Taxi zur gleichen Zeit an zwei verschiedenen Orten sich befindet laut Fahrplan. (MVV Ruftaxi 8000, 8200, 8300, 8400, 8500, 8700, 8800). Routing kann das auch nicht für den Renderer lösen, hier kann man nur die Haltestellen in der Relation sammeln. Wenn aber die stops bekannt werden für diese Fahrt könnte man sich dass dynamisch Routen lassen…

Im Thread of Slack gibt es noch weitere Antworten:

Minh weist darauf hin, dass es einige Renderer gibt, die fest davon ausgehen, dass alle Segmente der Route entsprechend in der Route-Relation vorhanden ist. Neben Transport-Map, ÖPNV-Karte auch z.B. Trufi/OpenTripPlanner.

Erwähnt wird auch ein Projekt der Uni Freiburg https://github.com/ad-freiburg/pfaedle/, das offenbar das Errechnen einer Route aus Stützpunkten zum Ziel hat.

Bei Trufi werden als Nebenprodukt Relationen erstellt… Ziel hier eine GTFS Datei zu erstellen.

Bei OpenTripPlanner arbeit mit GTFS Daten und benötigt keine ÖPNV-Relationen aus OSM.

Bei pfaedle werden Shape Daten für GTFS Dateien erstellen… Benötigt auch keine ÖPNV-Relationen aus OSM.

Dreh- und Angelpunkt sind hier die GTFS-Daten, weil hier auch die Timetable enthalten ist… was Routing mit Bus erst ermöglicht :slight_smile:

Gruß Miche

Ja, so in der Art, aber halt nicht nur auf Straßen begrenzt sondern für alle Eigenschaften. Dann kann ich die Geometrie(=way) beliebig splitten. Idealerweise würde man das Nachführen von splits und mergern der API überlassen und nicht auf den Editor zu hoffen.

Als Auswerter kann ich dann die für mich interessanten Eigenschaften an die Geometrie heften und mergen, was verbunden ist und identisch in durch meine Brille betrachtet identisch ist.

Guillaume Rischard erwähnte, dass er auch genau über das Thema ein Vortrag auf der SotM 2019 gehalten hat. Da der Talk sowieso auf Englisch ist, hier der komplette Kommentar von ihm aus OSM Slack auf Englisch. Das erwähnte Proposal ist ja übrigens auch von ihm:

Wer übrigens mal reinschauen möchte auf OSM Slack, hier ist der Link: https://slack.openstreetmap.us/
OSM Slack ist offen für alle, der Chat-Space wird nur finanziert vom local chapter in den Vereinigten Staaten.