Sparsamkeitsgebot Way-Splits

Welches Problem sollen "deine" Regeln denn überhaupt lösen?

Hm. Ich habe vor ein paar Tagen auch eine Straße aufgeteilt > https://www.openstreetmap.org/changeset/102531317. Hätte ich damit gegen das Sparsamkeitsgebot verstoßen?

@abrensch
Grundsätzlich würde ich dir Recht geben, bei manchen Änderungen meint man die wollen die Realität auf den cm abbilden. Aber ich habe noch nirgens gelesen, dass einer deiner Punkte verboten wäre, höchstens vielleicht ein Best-Practice.

Ich kann dich aber verstehen, mittlerweile hat die Openstreetmap ein Level an Detaillierung erreicht, bei dem man mancherorts wirklich suchen muss, um noch etwas zu finden, das nicht gemappt ist. Dass genau dieses auch getan wird, sieht man daran, dass es überhaupt Diskussionen über das Thema gibt.

Ich seh es schon vor mir: Irgendwann in ferner Zukunft braucht es Google Streetview nicht mehr, man braucht sich dann nur OSM in 3D ansehen, dann sieht man fast das Gleiche. 🙄

dooley wrote:

Hm. Ich habe vor ein paar Tagen auch eine Straße aufgeteilt > https://www.openstreetmap.org/changeset/102531317. Hätte ich damit gegen das Sparsamkeitsgebot verstoßen?

Hmm, "splitten ohne jeden Anlass" hab' ich ja garnicht in die Liste geschrieben, aber da steht ja auch "nicht abschliessend", also ja, das war nicht im Sinne des Sparsamkeitsgebots.

Aber worum es wirklich geht siehst Du 30m weiter: https://www.openstreetmap.org/node/3450 … &layers=ND

Ist ein Way-Split für eine Wanderroute, und an der Stelle ändern sich jetzt völlig grundlos die Eigenschaften der Steinhofstrasse.

Aber selbst das wäre nach "meinen" Regeln noch o.k., da steht ja nur, dass man für sowas keine Fernstrasse splitten sollte.

Ziel ist einfach, die Entropie klein zu halten und damit die Wartbarkeit zu erhöhen und die Fehleranfälligkeit zu vermindern.

Also ich sehe es im Prinzip genauso wie Du. Bei einer Datenbank sollte die Qualität der Daten im Vordergrund stehen und beim Erzeugen von Karten findet eine Generalisierung statt, also sollte eine Geodatenbank generalisierungsfreundlich sein und Mikrodetails sind irrelevant (oder auch unrealistisch weil unterhalb der Meßgenauigkeit).

Allerdings sehe ich uns da auch als Minderheit auf verlorenem Posten. Ich sehe hauptsächlich Mikromapping und übertriebenes Mikromapping auf dem Vormarsch, bei dem OSM eher hingebungsvoll wie ein Malbuch mit winzigsten Details ausgemalt oder auch um unpflegbar veränderliche Daten bereichert wird. Einen Blick für Relevanz und Datenqualität geschweige denn Generalisierung nehme ich nur sehr selten war.

Von daher +1 mit einem tiefen Seufzen. :-)

abrensch wrote:

also ja, das war nicht im Sinne des Sparsamkeitsgebots

Wie würde der brouter das handhaben, wenn an diesem Abschnitt https://www.openstreetmap.org/way/92751 … 4&layers=N eine Baustelle wäre und jemand diese eintragen würde (angenommen ich hätte die Straße nicht gesplittet). Wie komme ich von der Calwer Straße zu Im Tann? Ganz außenrum fahren?

PS: Grundsätzlich hast du natürlich recht. Ich finde aber, Wege gehören an Kreuzungen aufgeteilt.

Lücken in Bus- und Wanderrelationen, nur um das Aufsplitten einer Straße zu vermeiden? Halte ich für sehr fragwürdig.

Insgesamt würde eine Anwendung deines Sparsamkeitsgebots meines Erachtens mehr Probleme schaffen als lösen. Sparsamkeit darf nicht zu falschen Eintragungen führen. Wenn eine Routenrelation eine Lücke hat, dann ist das ein Fehler.

Wenn nun einmal ein Wanderweg ein Stück entlang auf einer Fernstraße verläuft, was meines Erachtens von Wanderwegplanern vermieden werden sollte, dann muss halt die Fernstraße hierfür aufgeteilt werden. Es sei denn, es gibt auf diesem kurzen Stück eine begehbare Bankette, die einen parallel eingezeichneten Trampelpfad (surface=grass) neben der Straße rechtfertigen könnte.

dooley wrote:

abrensch wrote:

also ja, das war nicht im Sinne des Sparsamkeitsgebots

Wie würde der brouter das handhaben, wenn an diesem Abschnitt https://www.openstreetmap.org/way/92751 … 4&layers=N eine Baustelle wäre und jemand diese eintragen würde (angenommen ich hätte die Straße nicht gesplittet). Wie komme ich von der Calwer Straße zu Im Tann? Ganz außenrum fahren?

PS: Grundsätzlich hast du natürlich recht. Ich finde aber, Wege gehören an Kreuzungen aufgeteilt.

Unabhängig vom letzten Satz:

Ein Way muss aufgesplittet werden wenn er unterschiedliche Tags hat: hw=residential und hw=construction rechtfertigen allemal einen Split

Aber: der OP hat wohl noch bus_bay, parking:*, sidewalk und weitere Tags vergessen.

Galbinus wrote:

Lücken in Bus- und Wanderrelationen, nur um das Aufsplitten einer Straße zu vermeiden? Halte ich für sehr fragwürdig.

Insgesamt würde eine Anwendung deines Sparsamkeitsgebots meines Erachtens mehr Probleme schaffen als lösen. Sparsamkeit darf nicht zu falschen Eintragungen führen. Wenn eine Routenrelation eine Lücke hat, dann ist das ein Fehler.

+1

Keine Fehler wegen Sparsamkeit.

ToniE wrote:

Aber: der OP hat wohl noch bus_bay, parking:*, sidewalk und wohl noch weitere Tags vergessen.

Das ist ein Grund, wieso ich bei zunehmender Detaildichte immer wieder dafür plädiere, den Haupt-"way" nicht mit Attributen zu überlasten und statt dessen den lediglich durch einen Bordstein von der Straße getrennten Gehsteig als eigene Linie einzutragen oder auch Parkbuchten nicht lediglich als Attribut an die Straße zu pappen sondern neben der Straße einzuzeichnen.

Seperat eingezeichneten Gewege ermöglichen es dann z.B., Wanderrouten nicht der Straße sondern dem Gehweg hinzufügen.

Separat eingezeichnete Parkflächen ermöglichen es dann, auch Zusatzinformationen wie zulässige Parkdauer oder Behindertenstellplätze einzutragen, ohne damit die Straße "zu belasten".

Galbinus wrote:

ToniE wrote:

Aber: der OP hat wohl noch bus_bay, parking:*, sidewalk und wohl noch weitere Tags vergessen.

Das ist ein Grund, wieso ich bei zunehmender Detaildichte immer wieder dafür plädiere, den Haupt-"way" nicht mit Attributen zu überlasten und statt dessen den lediglich durch einen Bordstein von der Straße getrennten Gehsteig als eigene Linie einzutragen oder auch Parkbuchten nicht lediglich als Attribut an die Straße zu pappen sondern neben der Straße einzuzeichnen.

Seperat eingezeichneten Gewege ermöglichen es dann z.B., Wanderrouten nicht der Straße sondern dem Gehweg hinzufügen.

Separat eingezeichnete Parkflächen ermöglichen es dann, auch Zusatzinformationen wie zulässige Parkdauer oder Behindertenstellplätze einzutragen, ohne damit die Straße "zu belasten".

Und über all dem schwebt dann der "Aufpasser": separates Mappen nur bei existierender "baulicher Trennung" ...

Mann kann es niemals nicht allen recht machen.

abrensch wrote:

- Bus-Routen dürfen Lücken und/oder überzählige Wegstücke haben, Kreiselsplits sind tabu!

Lücken finde ich nicht ok. Überzählige Stücke, z. B. in Kreiseln, sind aber in Ordnung, weil man die recht einfach rausrechnen kann: Bei drei Segmenten X, Y, Z geht Y halt nur von dem Schnittpunkt X/Y und Y/Z. Der Rest von Y ist dann nicht Teil der Route.

abrensch wrote:

- maxspeeds: es ist *KEINE* relavante Information, wo genau kurz nach einer Kreuzung ein Temposchild steht, das Tempolimit gilt ab Kreuzung! Stehen bei einem Tempolimit auf freier Strecke die Schilder für beide Fahrtrichtungen 20m auseinander, dann nimmt man halt die Mitte!

Wenn man Langeweile hat, kann man die Schilder separat als Node mappen 🙂
Laut StVO (§41) stehen "Vorschriftzeichen [...] dort, wo oder von wo an die Anordnung zu befolgen ist.". Wenn man kleinlich ist, ist die Position des Verkehrszeichens also relevant. Ich weiß aber nicht, wie eng das vor Gericht ausgelegt wird. Ansonsten gebe ich dir recht, dass man hier bei OSM gerne etwas ungenau sein sollte. Die Realität ist ja auch nicht exakt.

abrensch wrote:

- Brücken-Mapper mappen auch eingerohrte Mini-Bäche, und bei echten Brücken muss die Grenze genau am Widerlager sein, auch wenn 5m weiter ohnehin ein Waysplit ist

Für verrohrte Bäche sollte die Straße gar nicht angefasst werden...

abrensch wrote:

Ziel ist einfach, die Entropie klein zu halten und damit die Wartbarkeit zu erhöhen und die Fehleranfälligkeit zu vermindern.

Vielleicht lässt sich das mit QA-Tools unterstützen. Oder mit irgendeiner Änderung am Datenmodell, die viele Splits unnötig macht?

Bei der Datenauswertung sollte es möglich sein, Splits wieder rauszurechnen? Es ist generell einfacher, überflüssige Daten wegzuschmeißen als fehlende Daten zu erfinden.

abrensch wrote:

Mikro-Mapping-Irrsinn beschreiben, der vom Ansatz her zu einem exponentiellen Wachstum der Way-Splits und damit ins Verderben führt

Ich denke dass sich der Detailgrad einem Maximum annähert. Irgendwann ist einfach alles gemappt, wofür sich noch Leute interessieren. "Exponentiell" ist also der falsche Begriff.
Berlin hat derzeit ca. 68 Kilobyte (komprimiert) pro Quadratkilometer. Das klingt gar nicht mal soviel ;-)

Hat irgendwer Statistiken, wie sich die Datenmenge/Dichte von einzelnen Regionen über die Jahre entwickelt hat?

abrensch wrote:

Also postuliere ich das Sparsamkeitsgebot:
- Bus-Routen dürfen Lücken und/oder überzählige Wegstücke haben, Kreiselsplits sind tabu!
- gleiches für Rad-Wanderrouten: Splits von Fernstrassen sind tabu!

Ohne die Straßen die du rausschmeißen würdest mitzuziehen sehe ich keinen technischen Unterschied zwischen einer Relation mit 'zulässiger' Lücke und einer kaputten Relation. Die Relationen müssten demnach aus meiner Sicht regelmäßig von Mappenden geprüft werden ob noch alles im zulässigen Rahmen und fern von Fernstraßen ist. Halte ich für der Datenqualität nicht unbedingt zuträglich.

Im übrigen bin ich persönlich der Ansicht, dass bauliche Trennung da einsetzen sollte wo es für 'irgendeinen' erlaubten gewöhnlichen Verkehrsteilnehmer nennenswerten Aufwand beim "Spur"-wechsel gibt. Ich denke da hauptsächlich an Rollstuhlfahrer.

Wulf4096 wrote:

Vielleicht lässt sich das mit QA-Tools unterstützen.

Oder zumindest nicht torpedieren? Meckert nicht JOSM eine Kreuzung von waterway=stream und highway != bridge als Fehler an?

Oder mit irgendeiner Änderung am Datenmodell, die viele Splits unnötig macht?

Eine Änderung am Meta-Modell ist eher Science-Fiction (was wurde eigentlich aus dem AREA-Datentyp?)

Aber eine Änderung der Semantik ist viel realistischer, und wenn hier Leute behaupten, sowohl lückenhafte Relationen als auch nicht streng-lineare Relationen seien "kaputt", dann ist das vielleicht ein Fehler im semantischen Modell?

Für so Anwendungen wie waymarkes-trails oder die Berücksichtigung von Rad-Routen bei BRouter sind weder Lücken noch überzählige Abschnitte ein Problem.

Mit den Anwendungsfällen der Busrouten kenne ich mich nicht so aus. Jedenfalls lässt sich in beiden Fällen per Routing die fehlende Information gewinnen. Bei lückenhaften Relationen ist bei einer Kreiselbaustelle dann aber automatisch die Relation kaputt, während bei überzähligen Abschnitten die Relation stabiler ist gegen Fehler im Strassennetz.

Eins von beiden muss die Routen-Fraktion aber schlucken, sie hat nicht das Recht, das Strassennetz beliebig zu zersägen.

Zumal ja in der Praxis sowieso ganz viele Relationen an Kreuzungen kaputt sind, d.h. der Status Quo funktioniert ja auch nicht.

abrensch wrote:

Meckert nicht JOSM eine Kreuzung von waterway=stream und highway != bridge als Fehler an?

Nö. Wenn der waterway einen anderen layer hat, dann nicht. Es wird auch nicht "verlangt", da eine Brücke zu mappen.

Würde man die Sparsamkeitsgebote berücksichtigen, wären Kartendarstellungen von Bus- und Wanderrouten viel umständlicher, weil man erst die Lücken routen muss (ob das immer gut geht?) und dann die Verzeigungen absägen muss. Beim mappen hat man dann auch keinen Überblick, ob die Route ok ist.
Bei OSM geht zwar nicht nur um Karten, aber eben auch.

QS, die auf Vollständigkeit der Routen basiert, wäre komplizierter (Welche Lückengröße ist noch ok, wo fehlt wirklich was?)

Ja, es gibt Splits die tatsächlich unnötig sind (z.B. 1m Asphalt in einem gepflasterten Weg... die Info braucht echt keiner, wobei ich nicht weiß ob es das oft gibt.)

Ein wirkliches Problem ist es auch nicht, denn da wo viel gesplittet wird, ist die Mapperdichte offensichtlich hoch (sonst wär ja nicht viel gesplittet) und dann ist auch genug Arbeitskraft zum Warten da.

(Auch getrennte Fußwege machen Renderen Probleme, so richtig toll ist die Verdrängung bei Carto nicht.)

Na ein erster Anfang wäre erst mal eine Auflösung von Multipolygonen, die zugleich Linien vom Typ highway=* als outer haben...
Da kann man herrlich entsplitten... Ich aber auch sehr aufwendig!

Mal drei Beispiele: Brandenburg, Sachsen, Baden-Württemberg

Sven

abrensch wrote:

Wulf4096 wrote:

Oder mit irgendeiner Änderung am Datenmodell, die viele Splits unnötig macht?

Eine Änderung am Meta-Modell ist eher Science-Fiction (was wurde eigentlich aus dem AREA-Datentyp?)

Also es gibt für API 0.7 immerhin schon eine sehr grobe Idee, irgendwas mit Segmenten zu machen. Ich glaube zwar nicht, dass sowas in überschaubarer Zeit machbar ist, aber das gilt ja so ziemlich für alle Themen in diesem Zusammenhang, insbesondere auch für Areas.

https://wiki.openstreetmap.org/wiki/API … ed_ways.29

Galbinus wrote:

Lücken in Bus- und Wanderrelationen, nur um das Aufsplitten einer Straße zu vermeiden? Halte ich für sehr fragwürdig.
Insgesamt würde eine Anwendung deines Sparsamkeitsgebots meines Erachtens mehr Probleme schaffen als lösen. Sparsamkeit darf nicht zu falschen Eintragungen führen. Wenn eine Routenrelation eine Lücke hat, dann ist das ein Fehler.
Wenn nun einmal ein Wanderweg ein Stück entlang auf einer Fernstraße verläuft, was meines Erachtens von Wanderwegplanern vermieden werden sollte, dann muss halt die Fernstraße hierfür aufgeteilt werden.

ich sehe das auch so, wieso sollte es unwichtig sein, dass die Wanderroute auf der Hauptstraße entlanggeht? Wenn es einen eigenen (Fuß/Geh-)Weg gibt kann man ja den auch mal explizit eintragen und damit die Flüsse „Splittingsparsam“ eintragen und datenmodellkompatibel eintragen (eigentlich mappe ich bei Gehwegen höchstens die fehlenden Verbindungen wenn ein Künstler da mal wieder ein paar Inseln hinterlassen hat), aber im Prinzip führt nichts dran vorbei, dass wir grundsätzlich immer mehr splitten.

Die Datenauswerter müssen damit zurechtkommen und die ways halt wieder zusammensetzen (je nach Interesse bzw. auf welche tags und Relationen man verzichten kann).

Auf Editorseite könnte ich mir vorstellen, dass man die Benutzerfreundlichkeit beibehält indem man es vereinfacht, zusammenhängende ways mit wenigen clicks zu selektieren anhand der Eigenschaften wie Straße mit diesem name oder ref oder maxspeed bzw. jeden tag die das Objekt hat. Sowas wie rechtsclick auf die Straße, daraufhin eine Liste der tags wo man einzelne aktivieren kann, dann ok und es werden alle angrenzenden Straßenstücke auch selektiert bis die ausgewählten Eigenschaften abweichen. Damit würde man auch Lücken in den Eigenschaften sofort erkennen.
Bzw. nicht „ok“ sondern gleich live alles passende selektieren und durch weitere tags schritt für schritt verkleinern.

Galbinus wrote:

Lücken in Bus- und Wanderrelationen, nur um das Aufsplitten einer Straße zu vermeiden? Halte ich für sehr fragwürdig.

Da gab's mal ein Proposal, Streckenrelationen vorzugsweise nur noch mit Waypoints zu definieren. Damit würden Splits unnötiger werden.

Ich oute mich hier mal als so einer, der für das Ändern von Fahrbahnmarkierungen für Fahrstreifen, für unterschiedliche Geschwindigkeitsbegrenzungen, für Busrouten, Wanderrouten u.a. Straßen aufsplittet. Und ja, ich setze die Geschwindigkeitsbegrenzung da hin, wo sie hingehört, an die Stelle des Verkehrsschildes.

Warum mache ich das?
Weil das Datenmodell, das wir verwenden, eine andere Vorgehensweise nicht zulässt.
Weil ich so erzogen wurde, nämlich: genau zu arbeiten. In meinem Beruf wird Pfusch („ach, das passt schon irgendwie“) nicht akzeptiert.

Mir ist auch klar, das eine Zerstückelung der Straßen immer größere Probleme beim routing (Rechenaufwand, Speicherbelegung) hervorrufen werden.

Und es gibt immer noch Mapper, die es cool finden, das alles, was nicht bei drei auf dem Baum ist, mit dem nächstliegenden highway verbunden werden muss.

Meine Schlussfolgerung daraus: das Datenmodell muss den heutigen Erfordernissen angepasst werden.
Als OSM aus der Taufe gehoben wurde, konnte sich wahrscheinlich keiner vorstellen, welche Dimension das annimmt.

Aber wozu haben wir eine OSM-Foundation? Wozu haben wir eine Data Working Group? Das wäre doch mal eine Aufgabe, zu organisieren, dass das Datenmodell weiter entwickelt wird.
Das dümmste, was wir tun könnten, wäre:
- Daten wegwerfen
- Daten nicht erfassen, weil sie im Moment unbequem sind
Damit meine ich nicht, dass wir die Farbe des Schildes, auf dem die Öffnungszeiten des Tante-Emma-Ladens geschrieben stehen, erfassen, sondern die Daten, die dem Namen Open>STREET<Map zugeordnet werden können.

abrensch wrote:

- Wander-Routen-Mappen splitten auch Bundesstrassen, wenn ihre Route mal für 5 Meter darübergeht

Ab welcher Länge würdest du Splitten "erlauben"?

Es kommt oft vor, dass eine Wanderroute von einem Waldweg auf eine Bundesstraße stößt und sie 10 oder 20 m weiter auf der anderen Seite wieder verlässt. Das als Kreuzung zu mappen, um Auftrennen zu vermeiden, hieße Nutzer zu verwirren, weil die Bundesstraße eben nicht einfach nur überquert wird. Gerade an solchen Stellen ist die präzise Abbildung ein großer Vorteil von OSM. Wanderer können die Information, dass es auf der Straße langgeht, schon bei der Vorbereitung gebrauchen - denk mal an eine Tour mit kleinen Kindern. Und das Stück Straße einfach aus der Relation rauslassen? Für menschliche Nutzer geht das, sie sehen ja, wo es weitergeht. Für maschinelle Auswerter ist das nicht so einfach, wenn die Relation Lücken hat.

abrensch wrote:

Oder zumindest nicht torpedieren? Meckert nicht JOSM eine Kreuzung von waterway=stream und highway != bridge als Fehler an?

Da hat JOSM auch recht: Da ist dann entweder Brücke, Durchlass oder Furt. Beim ersten muss man die Straße splitten, beim zweiten das Gewässer, beim dritten keines von beiden.
Und wenn man nichts Genaueres weiß, kann man die Warnung auch ignorieren.

Eine Brücke zu ignorieren, damit ein Router weniger Aufwand hat, halte ich für einen grundfalschen Ansatz und einem Gewässer in der ganzen Länge layer=-1 zu geben, damit JOSM nicht mehr meckert, ebenfalls.

Datensparsamkeit in dem Sinn, dass nicht alles zentimetergenau erfasst werden muss, ist ok, aber dazu absichtlich falsch mappen ist für mich nicht akzeptabel.

Galbinus wrote:

Lücken in Bus- und Wanderrelationen, nur um das Aufsplitten einer Straße zu vermeiden? Halte ich für sehr fragwürdig.

Insgesamt würde eine Anwendung deines Sparsamkeitsgebots meines Erachtens mehr Probleme schaffen als lösen. Sparsamkeit darf nicht zu falschen Eintragungen führen. Wenn eine Routenrelation eine Lücke hat, dann ist das ein Fehler.

+1

Ich überprüfe die Korrektheit einer Route u.a. über deren Lückenlosigkeit. Das ist für mich ein sehr wichtigste Werkzeug zur Datenpflege.

Vielmehr sollten sich die Editoren des Problems annehmen. Wie wäre es z. B., wenn man mit einem Dreifachlick automatisch die gesamte Straße bis zur nächsten abzweigenden Kante markieren könnte.

Oder durch Drücken eines Shortcuts immer die jeweils nächste Kante mit zur Auswahl hinzunehmen, je nach Shortcut in aufsteigender Richtung der zuerst ausgewählten Kante oder in absteigender oder in beiden Richtungen.

Oder gibt es sowas in JOSM schon?

Wulf4096 wrote:

Hat irgendwer Statistiken, wie sich die Datenmenge/Dichte von einzelnen Regionen über die Jahre entwickelt hat?

turn:lanes: https://wiki.openstreetmap.org/wiki/Use … ackward_DE
(da kann man gut abschätzen, wieviele böse Splits dazugekommen sind 😉)

Zum Thema: Ich sehe (auch) kein Problem darin eine Strasse da zu splitten, wo sich eine Eigenschaft ändert.
Wo sich's vermeiden lässt, sollte man vlt. drauf achten. Eine Strasse splitten, weil ein Rohr drunter liegt, ist natürlich Quatsch.

@abrensch: Kannst Du mal beschreiben, wo genau die Stückelungen Probleme bereiten? Ich kenne das nur aus mkgmap (Garmin OSM Karten) Sicht. Dort entscheidet der Style für jeden OSM Weg einzeln, welche Garmin Attribute der Weg in der Karte haben soll. Das sind allerdings nur sehr wenige. So gibt es z.B. nur ein Bit für surface (paved/unpaved) und drei Bits für maxspeed. Nach der Umwandlung werden zuerst mal alle Wege mit gleichen Garmin Attributen wieder zusammen "geklebt" und mit Douglas-Peucker vereinfacht, um die Split-Punkte wieder loszuwerden. Der zusammengeklebte Weg enthält dann während der Verarbeitung noch die Liste der Original-Wege, so dass man nachvollziehen kann, wo die Daten herkommen.
Im Prinzip müssten doch alle Datenverarbeiter ähnlich vorgehen können?

Freu' mich über die breite Diskussion hier, weil zeigt, dass zumindest bei den Forums-Teilnehmern es ein Problembewusstsein bzgl. der Zersplitterung gibt.

Aber eins möchte ich noch klarstellen:

seichter wrote:

Eine Brücke zu ignorieren, damit ein Router weniger Aufwand hat, ...

Protoxenus wrote:

Mir ist auch klar, das eine Zerstückelung der Straßen immer größere Probleme beim routing (Rechenaufwand, Speicherbelegung) hervorrufen werden.

ich spreche hier nicht als (B-) Router-Entwickler, sondern in meiner Rolle bei der Fernstrassen-QS (brouter-suspects). Und da sehe ich es eben immer wieder, dass es die kaputt-gemappten = zersplitterten Ecken sind, wo die Fehler herkommen, z.B. gerade eben:

https://www.openstreetmap.org/changeset/103563087

Der Grund für den Split hier ist unklar, könnte das lane-mapping sein, aber das ist wahrscheinlich auch falsch. Kollegen wie dieser können einfach nicht so genau auf Vespucci schauen, um auch die kleinen Abschnitte noch zu sehen.

Als Router-Entwickler habe ich mit der Zersplitterung garkein Problem - das interne Datenmodell von BRouter splittet zusätzlich noch an jedem nicht-trivialen Node, und trotzdem kommt das Datenvolumen fast ausschliesslich aus der Geometrie, nicht aus dem Tagging.

Wenn es um das Motto geht
"So genau wie nötig, so allgemein wie möglich",
stimme ich zu.

Das kann ein Umdenken bedeuten, z.B. nicht alle straßenbegleitenden Features wie Gehwege an die Straße zu taggen, damit nicht bei jeder Änderung derer Eigenschaften die Straße gesplittet werden muss.

Es gibt aber Eigenschaften wie Zahl der Spuren und Geschwindigkeitsbeschränkungen, wo man mMn in den sauren Apfel des Taggens am way beißen muss und in der Folge das Splitten in Kauf nimmt.

abrensch wrote:

Eins von beiden muss die Routen-Fraktion aber schlucken, sie hat nicht das Recht, das Strassennetz beliebig zu zersägen.

Zumal ja in der Praxis sowieso ganz viele Relationen an Kreuzungen kaputt sind, d.h. der Status Quo funktioniert ja auch nicht.

Da bin ich bei dir. Je mehr man mit kaputte Dinge reparieren beschäftigt ist um so negativer sieht man diese mapping Praxis.

Die Routen Relationen könnte man mehr mit Routing arbeiten bzw. OSM teilweise oder ganz abstrahieren.

Protoxenus wrote:

Und ja, ich setze die Geschwindigkeitsbegrenzung da hin, wo sie hingehört, an die Stelle des Verkehrsschildes.

Warum mache ich das?
Weil das Datenmodell, das wir verwenden, eine andere Vorgehensweise nicht zulässt.
Weil ich so erzogen wurde, nämlich: genau zu arbeiten. In meinem Beruf wird Pfusch („ach, das passt schon irgendwie“) nicht akzeptiert.

Es gibt einen Unterschied zwischen "Pfusch", den sich kein Handwerker nachsagen lässt, und effizientem Arbeiten. Als guter Handwerker muss man wissen, wo es auf die Genauigkeit ankommt, und wo man fünfe gerade lassen sein kann, weil das für alle das Leben einfacher macht. Ein schlechter Handwerker arbeitet ungenau an Stellen, wo es drauf ankommt - oder akribisch genau, wo es eh keine Rolle spielt.

Die unserer Arbeit zugrunde liegenden GPS-Daten oder Luftbilder können leicht mal 10 Meter daneben liegen. Wenn ich ein Ortseingangsschild sehe und drei Meter danach ein Tempolimit 40, mappe ich dann ein 3-Meter-Stück mit Tempolimit 50? Ganz bestimmt nicht - höchstens vielleicht, wenn um die Stelle seit 10 Jahren im Gemeinderat gestritten wird und es tatsächlich signifikant ist, dass es dort die berühmten "drei Meter von Kleinkleckersdorf" mit eigenem Wikipedia-Artikel gibt.

"Genauigkeit" in OSM darf nicht zum Selbstzweck werden. Man muss unterscheiden, wo es drauf ankommt, und wo nicht.

(Edit: Womit ich nicht sagen will, dass Protoxenus einem Handwerk nachgeht, das weiss ich nicht, aber für Programmierer, Ärzte und Piloten gilt das gleiche...)

(Edit: Protoxenus richtig geschrieben...)

woodpeck wrote:

"Genauigkeit" in OSM darf nicht zum Selbstzweck werden. Man muss unterscheiden, wo es drauf ankommt, und wo nicht.

Aber genau das ist ja das Problem: Jeder, der in irgend einer Weise genau arbeitet, wird der Ansicht sein, dass es in diesem Fall drauf ankommt. Denn sonst täte er es ja nicht. Ich finde zum Beispiel weiterhin (wie gestern geschrieben), dass eine Wanderroute, die 10 oder 20 Meter einer Bundesstraße folgt, diese Strecke in der Relation auch enthalten sollte und dass das eine wichtige Information ist. Genau das wird aber im Eingangsposting angeprangert (wenn auch da mit nur 5 Metern).

Dann muss projektweit festgelegt werden, wann Genauigkeit wichtig ist und wann generalisiert werden kann.

woodpeck wrote:

Protonexus

Bei der Schreibweise von Namen scheint es dir nicht drauf anzukommen 😄

FraukeLeo wrote:

woodpeck wrote:

"Genauigkeit" in OSM darf nicht zum Selbstzweck werden. Man muss unterscheiden, wo es drauf ankommt, und wo nicht.

Aber genau das ist ja das Problem: Jeder, der in irgend einer Weise genau arbeitet, wird der Ansicht sein, dass es in diesem Fall drauf ankommt. Denn sonst täte er es ja nicht. Ich finde zum Beispiel weiterhin (wie gestern geschrieben), dass eine Wanderroute, die 10 oder 20 Meter einer Bundesstraße folgt, diese Strecke in der Relation auch enthalten sollte und dass das eine wichtige Information ist. Genau das wird aber im Eingangsposting angeprangert (wenn auch da mit nur 5 Metern).

Da bin ich bei dir. Das drauf ankommen hängt vom betrachtungswinkel ab. Dem Wanderer ist die Wanderrelation wichtig, dem Radfahrer die Radwegrelation und dem Autofahrer die Fernstraße. Ich sehe keinen Grund warum einer dem anderen vorschreiben kann, auf seine Details zu verzichten.

aighes wrote:

Ich sehe keinen Grund warum einer dem anderen vorschreiben kann, auf seine Details zu verzichten.

Ist immer so bei global begrenzten Resourcen (und die Zersplitterung des OSM-Wegenetzes ist auch eine):

Klimawandel: Dem einen sein Auto, Einfamilienhaus, Fleischkonsum, Flugreise, Pendelstrecke, ...

Pandemiebekämpfung: Dem einen sein Fitnesstudio, Kindergarten, Restaurant, Kosmemtikstudio, Schuhgeschäft, Schwimmbad, Kneipe...

immer schwer, bei genau diesem Detail den Grund zu sehen. Der Grund ist Solidarität.

Galbinus wrote:

Lücken in Bus- und Wanderrelationen, nur um das Aufsplitten einer Straße zu vermeiden? Halte ich für sehr fragwürdig.

+1

abrensch wrote:

Der Grund für den Split hier ist unklar, könnte das lane-mapping sein, aber das ist wahrscheinlich auch falsch. Kollegen wie dieser können einfach nicht so genau auf Vespucci schauen, um auch die kleinen Abschnitte noch zu sehen...

Den Grund für den Split müsstest Du beim Mapper nachfragen. Mit Vespucci ist das 24m lange Straßenstück ohne Probleme sichtbar (auch die Oneway-Pfeile).

abrensch wrote:

- Bus-Routen Mapper machen sogar vor Kreiselsplits nicht halt

Das halte ich noch für relativ unproblematisch

abrensch wrote:

- Wander-Routen-Mappen splitten auch Bundesstrassen, wenn ihre Route mal für 5 Meter darübergeht

Je nach Kreuzungsgeometrie finde ich das ok und nicht problematisch.

abrensch wrote:

- Maxspeed-Mapper wollen genau die Schilder-Position abbilden, für jede Richtung einzeln

Das sehe ich so und so. Auf der durchgehenden Landstraße ist die genaue Position schon wichtiger, da gilt ein maxspeed ab dem Schild. Steht das Schild aber nur wenige Meter nach einer Kreuzung, damit ein Abbieger es auch rechtzeitig sehen kann, dann mappe ich das maxspeed ab dem Kreuzungspunkt ohne zusätzliches Splitting. Das Gegenteil habe ich häufig bei 30-Zonen gesehen und finde das unnötig.

abrensch wrote:

- Brücken-Mapper mappen auch eingerohrte Mini-Bäche, und bei echten Brücken muss die Grenze genau am Widerlager sein, auch wenn 5m weiter ohnehin ein Waysplit ist

Natürlich mappt man eingerohrte Minibäche - als tunnel=culvert am stream. Aber hoffentlich keine Mini-Brückle!
Wenn zweifelsfrei erkennbar, mappe ich auch die Brücke möglichst genau ab Widerlager. Nur weil sich 5 m vor der Brücke ein maxspeed befindet, wird die Brücke nicht um 5 m länger.

abrensch wrote:

- traffic-calming=island braucht natürlich 4 zusätzliche Way-Splits (2 je Richtung), und das obwohl die Verkehrsinsel selbst auch noch gemalt ist

Kann man machen, muss man nicht. Aber wenn es so ist, ist es auch nicht falsch. Sehe ich leidenschaftslos.

abrensch wrote:

- TR-Mapper mappen zwanghaft auch "disfunktionale" TRs an Kreuzungen, die also nur Abbiege-Relationen verbieten, die kein intakter Router nehmen würde. Und splitten dann nicht nur am via-point, sondern auch noch woanders, weil sie glauben, TRs brauchen kurze Schenkel. Und noch ganz viele no-u-turns - auch das ein Irrglaube

Das sehe ich anders, habe da an manch Kreuzungen schon sehr seltsame Routings gesehen. Rechtsabbieger spur zu benutzen, an derem Ende die Querstraße queren und dann die andere Rechtsabbiegerspur wieder zurück auf die eigentliche Strecke kostet manchmal möglicherweise weniger Zeitstrafe als geradeaus über die Kreuzung, aber mit zwei Fußgängerüberwegen und Ampel.

abrensch wrote:

- (Turn-) Lane-Mapper wollen es auch ganz genau wissen

Hier habe ich nicht verstanden, was Du meinst. Mir sind aber schon Rechtsabbiegerspuren als gesplittete *_link untergekommen, weil der Mapper offensichtlich der Meinung ist, dass der erste Teil noch zu Straße A und der zweite Teil schon zu Straße B gehört. Das halte ich für übertrieben und meist vereinige ich beide Teile wieder.

Alles in allem sind das aber alles Punkte, die sich je nach Blickwinkel mit einer Änderung der Eigenschaften des Weges begründen lassen.

Viel mehr Sorgen mache ich mich aber um unnötige splittings, die sich eben nicht mit der Änderung von Eigenschaften des Weges selbst begründen lassen. Allen voran ways, die gesplittet werden, weil man sie als outer für neben dem Weg befindliche Flächen (Multipolygon-Relationen) verwendet(siehe Beitrag #18 von streckenkundler). Die unterschiedlichen Eigenschaften angrenzender Flächen haben nichts, so rein gar nichts mit den Eigenschaften des Weges zu tun.

Ebenfalls - wenn auch durchaus gerechtfertigterweise Eigenschaften des Weges beschrieben werden - wenn dann dann die unterschiedlichen Eigenschaften der (turn)lanes, maxspeed (unterschiedlich je Richtung) und sämtliche Eigenschaften der angrenzenden Rad- und Gehwege mit all ihren surface und was weiß ich noch, und natürlich für jede Richtung verschieden, alles an die Straße gehängt wird. Das wird dann einfach unübersichtlich.

streckenkundler wrote:

Da kann man herrlich entsplitten... Ich aber auch sehr aufwendig!

Bis auf zwei, knapp die sächsich -brandenburgische Grenze scheindende Multipolygone gibt es stand jetzt in Brandenburg keine MP's mehr, die ein highway=* als Teil einer outer-Linie eines MP's haben.

Diese persöhliche Mehrjahresaufabe ist erledigt.

Sven

woodpeck wrote:

Die unserer Arbeit zugrunde liegenden GPS-Daten oder Luftbilder können leicht mal 10 Meter daneben liegen. Wenn ich ein Ortseingangsschild sehe und drei Meter danach ein Tempolimit 40, mappe ich dann ein 3-Meter-Stück mit Tempolimit 50? Ganz bestimmt nicht - höchstens vielleicht, wenn um die Stelle seit 10 Jahren im Gemeinderat gestritten wird und es tatsächlich signifikant ist, dass es dort die berühmten "drei Meter von Kleinkleckersdorf" mit eigenem Wikipedia-Artikel gibt.

Das 3 Meter hinter einem Ortseingangschild ein Verkehrszeichen zur Geschwindigkeitsbegrenzung steht, habe ich noch nie gesehen. Und das irgendwelche Streitigkeiten von Gemeinderäten relevant für das Kartieren sind, ist mir auch neu. Aber man kann auf Luftbildern durchaus die Schatten von Ortseingangsschildern und Verkehrsschildern sehen und ich kann relativ gut auf Fotos die Entfernung zwischen zwei Dingen bestimmen. 10m Abweichung bei Luftbildern sind, wenn sie denn auftreten absolut. Nur nach GPS-Daten mappe ich schon lange nicht mehr. Aber 10m zwischen zwei Schildern sind 10m und werden auch durch ein nicht lagegerechtes Luftbild (mal abgesehen von extremen Verzerrungen und Brüchen zwischen zwei Aufnahmen, die aber leicht zu erkennen sind) auch nicht verändert.
Aber das ist nur Nebensache. Und ich verstehe auch die Übertreibung.
Wenn die Daten vorhanden sind, warum sollen sie dann auch nicht gespeichert werden? Und ab welcher Entfernung zwischen Ortseingangsschild und nächstfolgendem Verkehrszeichen sollte die Regel dann gelten? 7m, 10m, 30m, 50m?
Du stellst Pfusch und effizientes Arbeiten gegenüber. Da gibt es ganz andere Baustellen: Verkleben von...

streckenkundler wrote:

Diese persöhliche Mehrjahresaufabe ist erledigt.

Glückwunsch!
BaWü sieht da noch ganz traurig aus. Ich habe hier ein LSG (https://www.openstreetmap.org/relation/5393212), da komme ich immer wieder mal vorbei. Hier ist ein Teil der LSG-Grenze (im Norden) identisch mit der L 1150 (es gibt aber noch weitere Abschnitte). Schon lange vermute ich, dass das nicht stimmen kann, da die L 1150 eine breite, gut ausgebaute Straße ist. Inzwischen weiß ich mit Sicherheit, dass die LSG-Grenze bis auf wenige Ausnahmen südlich neben der Straße verläuft, allerdings aus nicht verwendbaren Quellen (Geoportal, UDO BW). Und nun?

PS: In diesem Fall ist die Stückelung der L 1150 eher nicht auf die Zweitverwendung als outer für das LSG zurückzuführen.

abrensch wrote:

Ist immer so bei global begrenzten Resourcen (und die Zersplitterung des OSM-Wegenetzes ist auch eine)

Wie man an deinen Beispielen leider sehen kann, funktioniert der Aufruf zu freiwilligem Verzicht halt nur bedingt gut. Und im Fall des OSM-Wegenetzes sehe ich mindestens zwei attraktivere Alternativen:

• Es einfacher machen, mit zerstückelten Wegen zu arbeiten.
• Es ermöglichen, das gewünschte Ergebnis zu erzielen, ohne dafür Wege zerstückeln zu müssen.

Beides läuft auf bessere Software hinaus, und du bist ja selbst Softwareentwickler – also könntest du auf dem Weg denke ich einiges bewegen. 😉

Du nennst z.B. Routenrelationen als eine Problemquelle. Nun ist es aber so, dass es derzeit halt für das Ergebnis, das sich manche Mapper wünschen, nötig ist, exakt die richtigen Wegstücke in die Route aufzunehmen. Anders sähe es aus, wenn es eine schicke ÖPNV-Karte gäbe, auf der eine Route, die nur aus den Haltestellen und vielleicht ein paar Stützpunkten besteht, optisch exakt so aussieht wie eine, die jeden einzelnen Way und jedes Kreisverkehr-Segment der Fahrtroute enthält. Ich denke, so könnte man Leute viel effektiver überzeugen, dass der zusätzliche Aufwand bei Erstellung und Pflege gar nicht nötig ist.

OSM und GPS im Gelände kann man nicht mit Mappen nach Luftbild und Laserscan vergleichen: Auf dem Luftbild sind 10m in zoom 25 der halbe Bildschirm, aber in der Satellitenverortung unterwegs sind sie ein Klax: 10 Schritte zu Fuß, 1 Sekunde bei müden 36km/h im Ortsgebiet.

Man könnte doch Routen auch als Folge von (Kreuzungs)Punkten erfassen. Dann müsste man die betroffenen Wege nicht aufsplitten. Ist ein solches Konzept schon mal diskutiert worden und wenn ja, was spricht dagegen (ausser dass es nicht zum derzeitigen Schema kompstibel ist)?

rainerU wrote:

Man könnte doch Routen auch als Folge von (Kreuzungs)Punkten erfassen. Dann müsste man die betroffenen Wege nicht aufsplitten. Ist ein solches Konzept schon mal diskutiert worden und wenn ja, was spricht dagegen (ausser dass es nicht zum derzeitigen Schema kompstibel ist)?

Siehe Seite 1:

mmd wrote:

Also es gibt für API 0.7 immerhin schon eine sehr grobe Idee, irgendwas mit Segmenten zu machen. Ich glaube zwar nicht, dass sowas in überschaubarer Zeit machbar ist, aber das gilt ja so ziemlich für alle Themen in diesem Zusammenhang, insbesondere auch für Areas.

https://wiki.openstreetmap.org/wiki/API … ed_ways.29

jengelh wrote:

Da gab's mal ein Proposal, Streckenrelationen vorzugsweise nur noch mit Waypoints zu definieren. Damit würden Splits unnötiger werden.

Und wo ich diese beiden Ideen gerade lese:

• Segmente könnte man ohne API-Änderung bauen, sondern mit Relations. Members sind way, start-node, end-node. Tags dann nach Geschmack.
  
• Routen könnten statt Ways dann (wenn man mag) über Segment-Relations gehen.
  

Würde das die Probleme lösen, oder nur noch mehr erschaffen?

Edit: Die Idee ist natürlich nicht neu, siehe https://wiki.openstreetmap.org/w/index. … id=1230216

rainerU wrote:

Man könnte doch Routen auch als Folge von (Kreuzungs)Punkten erfassen. Dann müsste man die betroffenen Wege nicht aufsplitten. Ist ein solches Konzept schon mal diskutiert worden und wenn ja, was spricht dagegen (ausser dass es nicht zum derzeitigen Schema kompstibel ist)?

Das ist bzgl. ÖPNV-Routen schon diskutiert worden und entspricht auch dem Ansatz von GTFS-shape-Daten.

Nachteil: alle Renderer müssen eine Routing-Engine anwerfen um die Fahrstrecke zeichnen zu können.

ToniE wrote:

Nachteil: alle Renderer müssen eine Routing-Engine anwerfen um die Fahrstrecke zeichnen zu können.

Das gilt auch für QS, um Unterbrechungen erkennen zu können.
Kreuzungspunkte allein reichen übrigens nicht, es kann ja mehrere ways zwischen Kreuzungspunkten geben. Mit einem weiteren Hilfspunkt in der gewünschten Strecke lässt sich das aber einfach beheben. Das macht das Routen trivial, da es dann nur eine Strecke zwischen zwei aufeinander folgenden Stützpunkten geben kann.
Im Sinne der hier diskutierten "Splittingsparsamkeit" ist das mMn nach schon überlegenswert.

Lücken in Routen können mit diesem Ansatz nur per Routing erkannt werden, andererseits werden die Routen dann unempfindlich gegen Vereinigen von ways (T-Stücke), was ja ein häufiger Grund für "zerschossene" Routen ist, jedenfalls viel häufiger als gelöschte Zwischenstücke.

<edit>Bei den ÖPNV-Routen erinnere ich mich nur an Vorschläge für das Routen von Haltestelle zu Haltestelle, was wegen häufiger Mehrdeutigkeiten auf Ablehnung stieß.
Mit genügend Zwischenpunkten und eben nicht ways ließe sich das mMn mit vertretbarem Aufwand eindeutig realisieren, ohne splitten zu müssen.

Mittlerweile scheint das "Sparsamkeitsgebot" auch auf "Thread-Splits" übergegriffen zu haben. Wenn die verschiedenen Diskussionsstränge zu etwas führen sollen, würde ich empfehlen, diese in eigene Threads auszulagern.

Ich glaube nicht, dass sich durch Stützpunkte für Routen etwas verbessert. Wenn ich an die regional rudimentäre Waldwege-Erfassung denke, dann ist es gut denkbar, dass plötzlich eine Route "selbstständig" auf einen kürzeren - aber erst frisch gemappten - Weg verlagert, weil niemand dran gedacht hat, noch einen Stützpunkt auf den "richtigen" Weg zu setzen. Ganz abgesehen von der Frage, ob man sich bei Bus-Routen darauf verlassen kann, dass die Stützpunkte gelöscht werden, wenn der Bus in Zukunft eine andere Route nimmt.

Ich bin aber voll bei abrensch, wenn er anprangert, dass manche Mapper Durchlässe als "Brücken" mappen. Und ich halte es auch in vielen Fällen für vertretbar, Maxspeed-Sektionen dort zu setzen, wo ohnehin schon ein Bruch ist, zum Beispiel an einer Kreuzung, statt 20 Meter weiter, wo das Schild steht.

Lücken in Routenrelationen fände ich nicht so prickelnd. Wenn ein Wanderweg eine Bundesstraße mit fünf Metern Versatz quert, muss man das sicher nicht abbilden, sondern dann kann der Weg "geradeaus" queren. Aber bei 20 oder 30 Metern ist es schon hilfreich zu wissen, ob es links oder rechts weitergeht.

Könnte man nicht einfach nur die Routen als GPX Dateien irgendwo anders ablegen und dann in der Relation einen Link darauf?
Dann können QA Tools prüfen, on die GPX Route so überhaupt befahrbar ist und wer mag kann dann reparieren. Die meisten Anwender wollen doch letzlich so eine GPX Datei.

GerdP wrote:

Link darauf

Dann hast du Links auf zich verschiedene Server. Die sind mal down, löschen ihre Daten, usw.
Und wenn irgendwas an den OSM-Daten geändert wird, sind die GPX-Dateien automatisch veraltet und werden wohl eher nicht automatisiert aktualisiert.

Mammi71 wrote:

Nur weil sich 5 m vor der Brücke ein maxspeed befindet, wird die Brücke nicht um 5 m länger.

Bei 5 Metern würde ich außerorts dafür die Straße nicht extra splitten sondern die Geschwindigkeitsbegrenzung dort anfagen lassen, wo die Brücke anfängt.

Pfad-Finder wrote:

Ich bin aber voll bei abrensch, wenn er anprangert, dass manche Mapper Durchlässe als "Brücken" mappen.

Ich habe schon viele Brücken entfernt und durch culvert ersetzt. Aber nicht aus Datensparsamkeit sondern weil es tatsächlich keine Brücken waren. Auch manche Unterführung eines Feldwegs oder einer Nebenstraße unter einer Fernstraße hindurch hat sich für mich eher als Tunnel dargestellt (z.B. weil es zwischen Unterführung und Fernstraße noch eine Schicht Erde gibt)

GerdP wrote:

Könnte man nicht einfach nur die Routen als GPX Dateien irgendwo anders ablegen

Das wäre der Abschied von OSM als der universellen Geo-Informations-Datenbank. Das wäre genau die Methode, wie Komoot, Alltrais oder Outdooractive arbeiten. Eine Methode, die für die Zwecke, für die Komoot und Konsorten gedacht sind, auch passt. Aber wir reden hier in OSM von "on-the-Ground" ausgeschilderten Wanderrouten, da ist wirkt sich jeder Änderung einer Straße direkt auf den Routenverlauf aus.

Ich habe aber bereits an anderer Stelle mal angeregt, ob die Entwicklung nicht in Richtung verschiedener Ebenen gehen müsste, die man beim Editieren wahlweise ein- und ausblenden kann. Ich stelle mir dass dann so vor, dass dann eine Wanderroute quasi eine mit der Straße verklebte durchgängige Linie wäre. Die Straßelinie müsste dann für die Route nicht aufgesplittet werden. Und ebenso entfiele auch bei der Wanderroute diese Zerstückelung in viele kleine Abschnitte. Ob das technisch umsetzbar wäre - keine Ahnung.

Aber ich habe mich sehr erschrocken, als ich mir mal die Gegend um den Kölner Dom im Editor angeschaut habe - das ist inzwischen so komplex, wer soll dort noch durchsteigen?

Daher wäre meine Vision, dass man in solchen Fällen verschiedene Ebenen wahlweise ausblenden könnte. Das kann man zwar mit einzelnen Objekten bereits, doch das Problem sind die miteinander verbundenen Objekte. Wenn man z.B. Eisenbahnlinien ausblendete, würde man diese auch verändern, wenn man eine Straße, die diese Eisenbahnlinie kreuzt, mit verschieben. Der iD-Editor verweigert dann auch konsequenterweise jegliches Verschieben von Punkten, die zu Objekten gehören, die ausgeblendet sind. Es müsste also möglich sein, die Straße zu verändern, ohne dabei die Routenlinie in die Finger zu bekommen, diese müsste sich aber wie bei verklebten Linien mitändern, wenn man den Straßenverlauf korrigiert.

Warum verschiedene Server? Warum nicht den OSM Server? Wir sprechen hier doch (auch) über ein API 0.7.
Im Moment sind die Daten automatisch "kaputt", wenn jemand mit den falschen Tools oder Methoden die OSM Daten verändert. Automatisch korrigiert werden sie dann auch nicht. Im besten Fall bemerkt jemand den Fehler und weiss auch noch, wie die Route eigentlich aussehen sollte bzw. wie er das (sehr mühsam) rausfindet.
Das jetzige Model ist ja oft genug nicht mal dazu in der Lage, die GPX Datei zu liefern, weil Reihenfolgen unklar sind bzw. die Interpretation irgendwelcher Rollen.

Du nennst z.B. Routenrelationen als eine Problemquelle. Nun ist es aber so, dass es derzeit halt für das Ergebnis, das sich manche Mapper wünschen, nötig ist, exakt die richtigen Wegstücke in die Route aufzunehmen. Anders sähe es aus, wenn es eine schicke ÖPNV-Karte gäbe, auf der eine Route, die nur aus den Haltestellen und vielleicht ein paar Stützpunkten besteht, optisch exakt so aussieht wie eine, die jeden einzelnen Way und jedes Kreisverkehr-Segment der Fahrtroute enthält. Ich denke, so könnte man Leute viel effektiver überzeugen, dass der zusätzliche Aufwand bei Erstellung und Pflege gar nicht nötig ist.

Das wäre mal richtig cool, Routenrelationen nur anhand von Haltestellen und Stützpunkten zu definieren! Eine riesige Fehlerquelle ("XY hat aus Unwissenheit meine Routenrelation kaputt gemacht!") für dessen Überwachung viele Tools entwickelt wurden und einige Leute viel Zeit reinstecken würde einfach so verschwinden!

Dafuer hast du dann die neue Fehlerquelle: XY hat den Stuetzpunkt geloescht oder verschoben oder YZ hat einen zusaetzlichen Weg hinzugefuegt oder einen entfernt oder ein Maxspeed geaendert oder ein falsches bus=no gesetzt... Wenn das Routen-routing dann umschlaegt viel Spass bei der Fehlersuche. 😉

westnordost wrote:

Du nennst z.B. Routenrelationen als eine Problemquelle. Nun ist es aber so, dass es derzeit halt für das Ergebnis, das sich manche Mapper wünschen, nötig ist, exakt die richtigen Wegstücke in die Route aufzunehmen. Anders sähe es aus, wenn es eine schicke ÖPNV-Karte gäbe, auf der eine Route, die nur aus den Haltestellen und vielleicht ein paar Stützpunkten besteht, optisch exakt so aussieht wie eine, die jeden einzelnen Way und jedes Kreisverkehr-Segment der Fahrtroute enthält. Ich denke, so könnte man Leute viel effektiver überzeugen, dass der zusätzliche Aufwand bei Erstellung und Pflege gar nicht nötig ist.

Das wäre mal richtig cool, Routenrelationen nur anhand von Haltestellen und Stützpunkten zu definieren! Eine riesige Fehlerquelle ("XY hat aus Unwissenheit meine Routenrelation kaputt gemacht!") für dessen Überwachung viele Tools entwickelt wurden und einige Leute viel Zeit reinstecken würde einfach so verschwinden!

Wen hast Du den hier zitiert ? 🙄
Über fehlende Quellenangaben sind ja schon auch Minister gestolpert. 🤣 🤣

abrensch wrote:

aighes wrote:

Ich sehe keinen Grund warum einer dem anderen vorschreiben kann, auf seine Details zu verzichten.

Ist immer so bei global begrenzten Resourcen (und die Zersplitterung des OSM-Wegenetzes ist auch eine):

Klimawandel: Dem einen sein Auto, Einfamilienhaus, Fleischkonsum, Flugreise, Pendelstrecke, ...

Pandemiebekämpfung: Dem einen sein Fitnesstudio, Kindergarten, Restaurant, Kosmemtikstudio, Schuhgeschäft, Schwimmbad, Kneipe...

immer schwer, bei genau diesem Detail den Grund zu sehen. Der Grund ist Solidarität.

Solidarität ist so eine Sache die auf Gegenseitigkeit und auf Werte basiert. Bei deinen Beispielen gibt es in den meisten Kulturen einen Konsens, was schützenswert seinen sollte. Das Leben. In OSM gibt es aber keinen solchen Werte-Konsens. Daher ist es schwer Solidarität einzufordern. Was wir haben ist ein "Minimalkonsens" = On-the-ground.

Das Problem liegt meiner Erfahrung nach aber nicht darin, dass der Rad-routen-Mapper oder der Spur-Mapper aktiv deine Fernstraße zerstören sondern darin, das man bei gesplitteten Wegen schneller mal bei einer Fernstraßenanpassung ein Segment vergisst. Aus meiner Sicht also eher ein Problem, was ein Editor lösen sollte.

GerdP wrote:

Wir sprechen hier doch (auch) über ein API 0.7.

Im Prinzip braucht es ein Datenmodell, was Geometrie und Eigenschaften der Geometrie trennt. Im Prinzip alle Eigenschaften in eine Art Relation verbannen, bei die man flexibel mit Geometrie-Elementen verbinden kann. Quasi wie wir es bei Multipolygonen bereits haben. Dann auch für Multi-"Wege", wo man sagen kann, gilt für den Weg 123 von Knoten 3 bis Ende und für Weg 456 komplett und für Weg 789 von Anfang bis Knoten 4. Von Montags bis Mittwochs außer Feiertag und nur bei Nässe.

Das ganze in Kombination mit einem WYSIWYG-Editor, wo sich der Mapper mit dem Datenmodell nicht rum plagen muss.

aighes wrote:

Multi-"Wege"

Vielleicht kriegt man dann ja auch Fahrbahnen wieder mit Geh- und Radwegen etc. zusammen ...

Einen wichtigen Einschub finde ich die überproportionalen Zusatztags für Seitenweg, aber das gehört wohl in einen eigenen Thread.
Kreisverkehre habe ich aber genau deswegen schon öfter aufgeteilt, egal ob als eigenes Objekt vorhanden oder nicht, da es oft Kreisverkehre gibt, die nur auf einer Seite Rad- und Fußweg haben. Häufig bedeutet das auch wieder die Ein- bzw. Ausfahrtarme auch noch zu Teilen. Letzters gilt auch für etliche `*_link`.

Segment-Relation werden meiner Ansicht zu unrecht abgeschrieben und sie finden sich eigentlich schon in den Daten, oder wie würdet Ihr eine Superroute beschreiben. Ich sehe darin nichts anderes nur mit anderen Bezeichnungen.
Bei Wander- und Fahrrad-Routen ist ein ähnliches Tagging erst neulich mit einem Proposal bestätigt worden, wonach Varianten, Abkürzungen und Verbindungen auch in eigene Relation kommen.
Beim PTv2 fehlt mir bisher allerdings dies Option und so habe ich eben 40 Varianten einer Linie anstatt im optimalen Fall nur jeweils ein Segment in jede Richtung für diese Linie.

aighes wrote:

GerdP wrote:

Wir sprechen hier doch (auch) über ein API 0.7.

Im Prinzip braucht es ein Datenmodell, was Geometrie und Eigenschaften der Geometrie trennt. Im Prinzip alle Eigenschaften in eine Art Relation verbannen, bei die man flexibel mit Geometrie-Elementen verbinden kann. Quasi wie wir es bei Multipolygonen bereits haben. Dann auch für Multi-"Wege", wo man sagen kann, gilt für den Weg 123 von Knoten 3 bis Ende und für Weg 456 komplett und für Weg 789 von Anfang bis Knoten 4. Von Montags bis Mittwochs außer Feiertag und nur bei Nässe.

Das ganze in Kombination mit einem WYSIWYG-Editor, wo sich der Mapper mit dem Datenmodell nicht rum plagen muss.

Das Stichwort heißt multilinestring Relation und es gibt schon ein Proposal, sehe aber nicht, das es hier was hilft, da es um das Zusammenführen von Eigenschaften aus verschiedenen Objekten geht. Habe eventuell auch nicht ganz verstanden wie, Du Dir das vorstellst. Brauche ich dann eine Relation für den Straßennamen und die Klassifizierung eine weiter Relation für `maxspeed` zusätzliche Relation für Spurtagging und so weiter? Das klingt nach API 1.0, aber ich lasse mich gerne Überraschen.

Wenn ich es richtig verstanden habe, ist für Validator gerade ein Plugin geplant, was fehlende Merkmale auf kurzen Teilstücken monieren soll.
Mit Filter und `Strg+W` oder auch den zusätzlichen "Selection" Werkzeugen von utilsplugin2 ist auch schon jetzt die Auswahl von aufeinander folgenden Linien möglich.
Eventuell könnte in JOSM die Such-Funktion nach Objekten mit identischen Merkmalen verbessert werden, da sie bei mir iM nur für ein Merkmal funktioniert.

Ja, im Prinzip so in der Art wie du es beschreibst. Das tut aber nur, wenn man nicht mehr ala josm in den puren Daten arbeitet, sondern. Ich gebe dir aber recht, dass es eher nicht API 0.7, aber es löst das ganze "wahllose" Aufteilen von Geometrie, die an sich nicht nötig ist. Gleichzeitig kann man die Eigenschaften separiert und kann sie in "Layern" anzeigen. Einzig wenn ich an der Geometrie was anpassen, muss ich (oder der Editor im Hintergrund) alle "Layer" haben.

Viele Sachen sind davon irgendwie vorhanden. Nur halt in einer Form ala: Rumdoktern an den Symptomen, nicht korrigieren des Problems.

Ein erster Schritt für API 0.7 könnte ja sein, dass man Relationen aus Teilwegen zusammensetzen kann und nicht nur komplette Wege. Daran kann man probieren, was möglich ist.

Dann könnten Editoren nachziehen. Nicht der Auswerter könnte Routing nutzen, sondern der Editor und damit den Mapper unterstützen. Bspw. ich will eine Radroute eintragen wähle Startpunkt und Zielpunkt und solange Zwischenpunkte, bis das Ergebnis passt. Der Editor trägt mir dann die Route mit Teilwegen ein. Quasi Win-Win. Der Mapper vergisst keine Segmente, er muss keine Wege dafür splitten und der Auswerter hat statische Daten der Route zur Darstellung.

Nur als Hinweis: ihr erfindet gerade neu, was im Oktober 2007 abgeschafft wurde (segments).

aighes wrote:

Das wäre mal richtig cool, Routenrelationen nur anhand von Haltestellen und Stützpunkten zu definieren

Dafuer hast du dann die neue Fehlerquelle: XY hat den Stuetzpunkt geloescht

Wenn jemand ne Node löscht und dabei eine punktbasierte Routenrelation schrottet ist das nicht viel anders als wenn jemand ne Node löscht, die Teil eines 2-nodigen Ways ist, der widerrum Teil einer wegbasierten Routenrelation ist.. Im Übrigen gibt es mit Enforcement Restrictions bereits Relationen, die Nodes als Member (from/to) haben - und damit Erfahrungen, wie sich nodebasierte Busrouten im Editor anfühlen könnten (Tip: JOSM warnt wenn man diese Nodes löscht) und, indirekt, wie häufig solche im Vergleich zu wegbasierten Routen kaputt gehen.

westnordost wrote:

Das wäre mal richtig cool, Routenrelationen nur anhand von Haltestellen und Stützpunkten zu definieren!

geht schon 😉 Stützpunkte gibt es halt noch nicht... nicht definiert/abgestimmt/beschlossen 🤔

https://www.openstreetmap.org/relation/11105612

Tool:

https://greymiche.lima-city.de/ptv2_pla … n=11105612

ergibt:

http://brouter.de/brouter-web/#map=15/4 … le=car-eco

Problem sind halt noch fehlendes Bus-Profil für Router.. und Stützpunkte bzw. Via Punkte sind bisher nicht vorgesehen in Ptv2

Gruß Miche

Bei bus-routen stelle ich mir sowas praktikabel vor, wenn der verlauf nicht 100%ig ist, ist es kein Beinbruch. Aber bei den anderen Routen-Relationen wirds schnell blöd. Wenn der einfache Wanderweg auf einmal über den Klettersteig geht, nur weil irgendwo was im richtigen Weg kaputt ist. Oder die Bundesstraße durch den Ort geht oder die Radroute plötzlich ihren verlauf ändert, nur weil ich irgendwo ein surface=cobblestone ergänzt habe.

Mich würde interessieren, wie die Idee ist, das routing global korrekt hin zu bekommen. Theoretisch brauchst du eigentlich einen dummen router, der alles ignoriert an Eigenchaften und immer das kürzeste nimmt. Alles andere dann per Stützpunkte.

aighes wrote:

Mich würde interessieren, wie die Idee ist, das routing global korrekt hin zu bekommen. Theoretisch brauchst du eigentlich einen dummen router, der alles ignoriert an Eigenchaften und immer das kürzeste nimmt. Alles andere dann per Stützpunkte.

Das Problem wird sein, dass du eigentlich nie genug Stützpunkte hast, außer du setzt alle zehn Meter einen. Wird mal irgendein kürzerer Weg zwischen den Stützpunkten A und B neu angelegt, schon wird die Wanderroute falsch angezeigt. Man kann von einem Newbie, der nur in bester Absicht einen neu erstellten Fußweg einträgt, unmöglich erwarten, die Umgebung nach Wanderrouten abzusuchen, die irrtümlich darüber geroutet werden könnten, und gegebenenfalls neue Routingpunkte in die Relationen einzubauen, um das zu verhindern.

SimonPoole wrote:

Nur als Hinweis: ihr erfindet gerade neu, was im Oktober 2007 abgeschafft wurde (segments).

Hallo Simon, ist aus meiner Sicht jetzt erstmal kein wirkliches Argument. OSM in 2007 und in 2021 kannst du nun wahrlich nicht vergleichen was die Datendichte an geht.

Aber wie gesagt: Mein eigentlicher Punkt ist, dass das Problem nicht daher kommt, dass Objekte zerstückelt werden, sondern dass Menschen beim Editieren fehler machen, Dinge übersehen und man besser da ansetzt, die Fehler zu verhindern. Unser Datenmodel kann (fast) alles abdecken, was man so brauchen kann.

Nur mit zunehmendem Detailreichtum sind aktuelle Editoren für den Gelegenheitsmapper nicht mehr trivial zu bedienen, weil er Sachen beachten muss, von denen er keine Ahnung hat. Bspw. in jOSM muss ich erst manuel die Geometrie erstellen oder anpassen=splitten. Alternativ könnte man statt dem manuellen splitten auch ein simples routing haben. Route von Node A über B und C nach Node D und definiere die Oberfläche als gravel. Intern würde jOSM alle nötigen Daten vom Server laden, dann an meinem Startpunkt A einen Node einfügen und den Weg teilen, inkl. aller Anpassungen, gleiches beim Endweg mit dem Endpunkt D. Entlang der Route trägt er überall surface=gravel ein. Ist irgendwo schon surface=concrete definiert gibts eine Rückfrage.

Der Mapper kommt also nicht mehr mit den Daten in Berührung und kann Fehler wie kurze Wegegmente undefiniert lassen nicht mehr machen. Gleichzeitig muss sich auch nicht jeder Auswerter einen Eigenen Router basteln.

Zufällig grad gesehen:

https://www.openstreetmap.org/#map=19/49.98411/10.84033

schön viele Labels, was? Kommt daher, dass der Weg jedesmal aufgesplittet ist, wenn sich der Straßenbelag am Gehsteig ändert. Führt umgekehrt dann dazu, dass auf https://www.openstreetmap.org/#map=17/49.98489/10.84023 keines der Zipfelchen mehr lang genug ist, um den Straßennamen einzutragen, dann gibts halt keinen mehr.

(Einige Renderer machen daher ein "st_union(geom) group by name", bevor sie die Labels einzeichnen, aber das macht die Sache langsam...)

Weise mapper haben mal gesagt "wir taggen nicht fuer den Renderer" *duckundweg*:D

FraukeLeo wrote:

Das Problem wird sein, dass du eigentlich nie genug Stützpunkte hast, außer du setzt alle zehn Meter einen. Wird mal irgendein kürzerer Weg zwischen den Stützpunkten A und B neu angelegt, schon wird die Wanderroute falsch angezeigt.

Das passiert aber auch ohne Routing.. da werden extra Fußwege angelegt und die Wanderroute führt weiterhin über die Straße.

Bei Routing kann man das Ergebnis mit älteren Ergebnis vergleichen.. um automatisch Abweichung festzustellen und dadurch fehlerhafte Bearbeitungen finden.

In der Praxis.. braucht man Relationen nicht.. man braucht gpx/kml... Dateien. Eine Relation kann als Grundlage dienen ein gpx z.b. zu erstellen. Also eine Relation sollte alle Informationen enthalten um ein Gpx zu erstellen.

Gerade was z.B. Radrouten und Co. anbelangt, sollte man auch mal eine gute Darstellung auf der Karte im Hinterkopf haben. Die sollte fix und verlässlich sein. Ich befürchte, für Radwege und Co. funktioniert eine rein stützpunktbasierte Geschichte nicht. ... Ja und nur gpx... kommt sowas bei raus:https://www.spreewald-biosphaerenreserv … #&g=4&k=26. Wenn ich als Datenverarbeiter das sehe, läuft mir ein kalter Schauer den Rücken hinunter... Auch darstellungstechnisch ist das gruselig... Man sieht übrigens, welcher der Wege mal aus OSM stammte: https://cycling.waymarkedtrails.org/#route?id=2196978.

Da lob ich mir die in OSM als Relationen erfassten Rad-Routen als Relationen... Solche Radrouten sind auch in der Realität in der Ausschilderung recht stabil. Ja und einmal in OSM gut erfasst, ist der Fehlergehalt recht gering (es sei den iD zerwürfelt aus ner Laune heraus die Reihenfolge). Auch ein gutes Radrouting funktioniert, siehe z.B. auch https://cycle.travel/map.

Sven

aighes wrote:

Weise mapper haben mal gesagt "wir taggen nicht fuer den Renderer" *duckundweg*:D

Kommt auf den Renderer an, und darauf, welche der Daten wegen derer der way gesplittet wurde, einen interessieren. Wenn man Abstriche bei der Aktualität macht, man man mit Vektortiles z.B. Straßennamengeometrien machen (die aufwendige Vorberechnung des ST_Union also “vor dem Rendern” machen bzw. beim Vorrendern) und braucht noch nicht so riesige Maschinen wie wenn es live und “sofort” gerendert werden soll, und daraus die Namen rendern.

Ich bin grundsätzlich aber auch schon seit dem Anfang der Meinung, dass man soviel es geht explizit eintragen sollte, anstatt es über properties indirekt auszudrücken, weil das zwar etwas mühseliger ist beim Zeichnen, und auch komplizierter für bestimmte Darstellungen (z.B. fester offset der Linie anhand der Linienstärke einer parallelen Linie, eigentlich braucht man dafür wahrscheinlich zusätzlich die properties), aber dafür einfacher und übersichtlicher ist, lagegetreuer und präziser bei der Form und die Topologie besser abbilden kann. Die Komplexität der realen Welt besteht zwar weiterhin, aber das Modell ist geometrisch näher und die Eigenschaften verteilen sich besser auf die Stellen wo sie auch hingehören, anstatt andere vermeintliche “Haupt”elemente zu überfrachten (insbesondere highways)

miche101 wrote:

Bei Routing kann man das Ergebnis mit älteren Ergebnis vergleichen.. um automatisch Abweichung festzustellen

Klar kann "man". Nur: Wer ist "man"?

Szenario: Auf einem Hügel wird ein Windpark gebaut und zwei neue Anfahrtswege von Norden und von Süden angelegt. Ein noch wenig erfahrener Mapper trägt diese Wege ein, was natürlich gut und richtig ist. Er kann unmöglich auf dem Schirm haben, dass a) eine Wanderroute auf einem alten Schotterweg westlich um den Hügel herumführt, b) diese Wanderroute nur über zwei Stützpunkte definiert ist, einer nördlich, einer südlich, was bislang auch gereicht hat, und c) die zwei neuen Weg eine kürzere Verbindung zwischen den zwei Punkten ermöglichen, eventuell nur indirekt über weitere Wege, so dass die Relation in den heruntergeladenen Daten gar nicht vorhanden ist. Dennoch wird die Relation jetzt über den Hügel geroutet statt außenrum, obwohl sich der markierte Wanderweg gar nicht geändert hat.

Wer macht jetzt den Vorher-Nachher-Vergleich, um das festzustellen? Der Mapperkollege kann es nicht, er weiß ja gar nichts von der Relation, und sie wurde durch seine Neueinträge gar nicht berührt.

Das kannst du, wie oben gesagt, nur zuverlässig verhindern, indem du alle 20 oder spätestens 50 Meter einen Punkt in die Relation setzt, um später versehentlich entstehende Abkürzungen auszuschließen. Gut, kann man machen. Muss dann nur ausgeschlossen werden, dass die Punkte bei irgendeiner Bearbeitung gelöscht werden.

miche101 wrote:

und dadurch fehlerhafte Bearbeitungen finden.

Es geht nicht um fehlerhafte Bearbeitungen, sondern um sinnvolle, die ungewollt das Punkt-zu-Punkt-Routing verändern, indem sie Abkürzungen ermöglichen, die beim Anlegen der Relation nicht berücksichtigt wurden, weil sie noch nicht da waren.

FraukeLeo wrote:

miche101 wrote:

Bei Routing kann man das Ergebnis mit älteren Ergebnis vergleichen.. um automatisch Abweichung festzustellen

Klar kann "man". Nur: Wer ist "man"?

Ja, und wo wird das ältere Ergebnis zwischengespeichert, wie lange, ...?
Und wer sagt, dass das ältere Ergebnis das korrekte, das gewollte widerspiegelt?

FraukeLeo wrote:

Wer macht jetzt den Vorher-Nachher-Vergleich, um das festzustellen? Der Mapperkollege kann es nicht, er weiß ja gar nichts von der Relation, und sie wurde durch seine Neueinträge gar nicht berührt.

Das kannst du, wie oben gesagt, nur zuverlässig verhindern, indem du alle 20 oder spätestens 50 Meter einen Punkt in die Relation setzt, um später versehentlich entstehende Abkürzungen auszuschließen. Gut, kann man machen. Muss dann nur ausgeschlossen werden, dass die Punkte bei irgendeiner Bearbeitung gelöscht werden.

miche101 wrote:

und dadurch fehlerhafte Bearbeitungen finden.

Es geht nicht um fehlerhafte Bearbeitungen, sondern um sinnvolle, die ungewollt das Punkt-zu-Punkt-Routing verändern, indem sie Abkürzungen ermöglichen, die beim Anlegen der Relation nicht berücksichtigt wurden, weil sie noch nicht da waren.

Wer entscheidet, ob das neue Ergebnis ein Fehler oder die Korrektur eines Fehler ist?

Die 'neue' Route wird durch eine Algorithmus ermittelt, nicht durch das Vorhandensein von Ways als Member in einer Relation.

Eine Diskussion der potentiellen neuen Probleme durch Stops und Stützpunkte beim Editieren, bei der QS, beim Rendern, ... ist für mich noch nicht abgeschlossen und sollte mMn neben den Vorschlägen und deren Vorteilen zusammen mal dokumentiert werden.

Die Probleme mit dem PTv2 kennen wir (z.T. = "split-ways" auch durch Tools verursacht), ein Re-Design wird neue Problem mit sich bringen.

dieterdreist wrote:

lagegetreu

Will OSM das GIS vom Amt für Tiefbau sein? Die Brücke also zentimetergenau am Widerlager beginnen lassen und das Tempo 40 Schild dort, wo es am Luftbild erscheint, auch wenn drunter ein Schild, "in 25m" hängt, das am Luftbild aber nicht erkennbar ist, genauso wenig wie die Aufschrift "40 km/h Zone" übrigens… Wozu eigentlich OSM-Carto, wenn es eh 20 oder 80cm Luftbilder gibt? Das geeignete consumer-GPS-handheld das nicht Minuten für eine einzelne Messung braucht, auf dem man sich am Bilschirm dort sieht, wo man laut Luftbild tatsächlich ist, das kommt sicher in den nächsten 20 bis 50 Jahren auf den Markt.

PS: War wirklich tun mit einem Straßenabschnitt, der auf 10m einen Hunderter erlaubt? So schnell beschleunigt kein mir bekanntes Fahrzeug (links 50, rechts 40)! Ich plädiere für "fallen lassen".

Hungerburg wrote:

PS: War wirklich tun mit einem Straßenabschnitt, der auf 10m einen Hunderter erlaubt? So schnell beschleunigt kein mir bekanntes Fahrzeug (links 50, rechts 40)! Ich plädiere für "fallen lassen".

(wie soll man "links 50" verstehen? Aber der Reihe nach...)
Wenn im Wechsel 90-100-90 km/h beschildert ist, dann braucht's nur a≈14.66m/s², und der Tesla S ist mit etwa 10m/s² schon mal nah dran. Bei 50-100-50 sieht's natürlich ganz anders aus, das ist der a-Wert medizinisch nicht mehr vertretbar. ;-)

jengelh wrote:

wie soll man "links 50" verstehen? Aber der Reihe nach...)
Wenn im Wechsel 90-100-90 km/h beschildert ist, dann braucht's nur a≈14.66m/s², und der Tesla S ist mit etwa 10m/s² schon mal nah dran. Bei 50-100-50 sieht's natürlich ganz anders aus, das ist der a-Wert medizinisch nicht mehr vertretbar. ;-)

unbemannte Fahrzeuge...

FraukeLeo wrote:

Das kannst du, wie oben gesagt, nur zuverlässig verhindern, indem du alle 20 oder spätestens 50 Meter einen Punkt in die Relation setzt, um später versehentlich entstehende Abkürzungen auszuschließen. Gut, kann man machen. Muss dann nur ausgeschlossen werden, dass die Punkte bei irgendeiner Bearbeitung gelöscht werden.

Bei Abkürzungen ist es ganz einfach.. dadurch ändert sich die Gesamtlänge der Strecke und kann durch die größe der Veränderung erkannt werden..

Löschen von Punkten... Gegenfragen wie verhindert man das Löschen von Wegstücken bei den jetztigen Relationen?

ToniE wrote:

Und wer sagt, dass das ältere Ergebnis das korrekte, das gewollte widerspiegelt?

Wie weisst du das bei jetztigen Relationen? Ich hab die Relationen im MVV im Bereich von 400-900 die ich erstellt hab alle mit Routing und Raten erstellt... es gibt keine Referenz auf die man sich beziehen könnte ob diese Relationen noch richtig oder überhaupt richtig sind. Kein Gpx, Shape, Routenplan..

ToniE wrote:

Wer entscheidet, ob das neue Ergebnis ein Fehler oder die Korrektur eines Fehler ist?

Wieder Gegenfrage.. wie läuft das jetzt?

Zu Hinterfragen, wieso so viel gesplittet wird, finde ich gut. Sparsamkeit ebenfalls. 🙂

Vielleicht habe ich die bisher 4 Seiten nicht gründlich genug gelesen, frage mich aber, wieso man nicht Konzepte miteinander kombiniert:

jengelh wrote:

Galbinus wrote:

Lücken in Bus- und Wanderrelationen, nur um das Aufsplitten einer Straße zu vermeiden? Halte ich für sehr fragwürdig.

Da gab's mal ein Proposal, Streckenrelationen vorzugsweise nur noch mit Waypoints zu definieren. Damit würden Splits unnötiger werden.

rainerU wrote:

Man könnte doch Routen auch als Folge von (Kreuzungs)Punkten erfassen. Dann müsste man die betroffenen Wege nicht aufsplitten. Ist ein solches Konzept schon mal diskutiert worden und wenn ja, was spricht dagegen (ausser dass es nicht zum derzeitigen Schema kompstibel ist)?

Überwiegend sind Splits, die ich vornehme(n musste), eindeutige Schnittpunkte zwischen zwei Linien. D.h. es braucht da kein Routing, sondern lediglich das Suchen von Punkt-Schnittmengen zwischen zwei Linien, um Splits überflüssig zu machen. Um selbst diesen Aufwand überflüssig zu machen, könnte man neben den Linien die Punkte zum Übergang auf die nächste Linie in eine Routenrelation aufnehmen -- das kann im Prinzip der Editor übernehmen und bei Uneindeutigkeit nachfragen.

Das Datenmodell gibt das (mAn) her; Änderungen wären in Editoren, QA-Tools und Renderern nötig.

Generell: Ein zwei OSMler haben es hier angemerkt. Ich nehme eine Tendenz wahr, dass das zum Erstellen einer Karte aus meiner Sicht notwendige Abstrahieren der Realität in den Hintergrund rückt. Ein bisschen Schade.

miche101 wrote:

Bei Abkürzungen ist es ganz einfach.. dadurch ändert sich die Gesamtlänge der Strecke und kann durch die größe der Veränderung erkannt werden..

Nochmal meine Frage: Von wem wird das erkannt? Wer prüft das nach einer (jeder) Bearbeitung?

Vielleicht mal mit Zeichnung. Hier mein hypothetischer Berggipfel. Der Wanderweg läuft über die Punkte 1, 2, 3, 4 westlich darum herum.

Jetzt wird am Gipfel ein Windrad errichtet und eine Zufahrt neu angelegt, die ein Mapper einzeichnet, wobei die Knoten 5 und 6 neu entstehen:

Ein Router wird den Weg jetzt über 1-2-5-6-3-4 führen. Um das zu unterbinden, muss zwischen 2 und 3 noch ein Stützpunkt 2a eingebaut werden. Wer merkt das und macht das?

Mapper X berührt die Relation überhaupt nicht und fasst weder einen ihrer Punkte noch einen der bislang gerouteten Ways an. Von ihm oder seinem Editor zu erwarten, hier eine Warnung oder gleich eine Reparatur vorzunehmen, dürfte nicht ganz trivial sein.

Der Editor hat die Relation möglicherweise nicht mal in den heruntergeladenen Daten, wenn nur der Bereich zwischen 5 und 6 geladen ist. Das ist der große Unterschied zur jetzigen Routenerfassung, da kann der Editor einfach die Mitgliedschaften der bearbeiteten Objekte abfragen. Im Beispiel oben nützt ihm das nichts.

aighes wrote:

SimonPoole wrote:

Nur als Hinweis: ihr erfindet gerade neu, was im Oktober 2007 abgeschafft wurde (segments).

Hallo Simon, ist aus meiner Sicht jetzt erstmal kein wirkliches Argument. OSM in 2007 und in 2021 kannst du nun wahrlich nicht vergleichen was die Datendichte an geht.

Sicher, aber man hat die Segments nicht einfach so abgeschafft.

Aber wie gesagt: Mein eigentlicher Punkt ist, dass das Problem nicht daher kommt, dass Objekte zerstückelt werden, sondern dass Menschen beim Editieren fehler machen, Dinge übersehen und man besser da ansetzt, die Fehler zu verhindern. Unser Datenmodel kann (fast) alles abdecken, was man so brauchen kann.

Nur mit zunehmendem Detailreichtum sind aktuelle Editoren für den Gelegenheitsmapper nicht mehr trivial zu bedienen, weil er Sachen beachten muss, von denen er keine Ahnung hat. Bspw. in jOSM muss ich erst manuel die Geometrie erstellen oder anpassen=splitten. Alternativ könnte man statt dem manuellen splitten auch ein simples routing haben. Route von Node A über B und C nach Node D und definiere die Oberfläche als gravel. Intern würde jOSM alle nötigen Daten vom Server laden, dann an meinem Startpunkt A einen Node einfügen und den Weg teilen, inkl. aller Anpassungen, gleiches beim Endweg mit dem Endpunkt D. Entlang der Route trägt er überall surface=gravel ein. Ist irgendwo schon surface=concrete definiert gibts eine Rückfrage.

Der Mapper kommt also nicht mehr mit den Daten in Berührung und kann Fehler wie kurze Wegegmente undefiniert lassen nicht mehr machen. Gleichzeitig muss sich auch nicht jeder Auswerter einen Eigenen Router basteln.

Das beliebteste Feature von iD in diesem Forum ist bekanntlich genau so was.

Das andere Problem ist, je grösser der Abstraktionsgrad der Bearbeitungen ist, desto aufwändiger ist die Implementierung, du hast in den 2 Absätzen ein oder zwei Dutzend Fraujahre verbraten.

FraukeLeo wrote:

Nochmal meine Frage: Von wem wird das erkannt? Wer prüft das nach einer (jeder) Bearbeitung?

Von wem wird das jetzt erkannt? Und wer kann das überprüfen?

Ich könnte nicht eine Relation auf OSM Type=Route überprüfen, weil ich keine Route von vorne bis ans Ende kenne. Ich kenne vielleicht Teile.. aber nichts ganz.

Geht eine Relation kaputt kann ich nur raten wie es war.. es gibt keine Unterlagen zu einer Route... Wie z.b. ein gpx das ich dagegen halten könnte... Um eine Relation richten zu können.

OSM ist in dieser Hinsicht das letzte was man gebrauchen kann... In der Praxis holt man sich lieber wo anders ein gpx.. da hat man mehr davon.. weil aus einer kaputten Relation eine fehlerfreie gpx Datei zu bekommen ist zu viel Arbeit.
So sind viele Relationen kaputt und unvollständig die meiste Zeit ihres Bestehens.

Gruß Miche

miche101 wrote:

FraukeLeo wrote:

Nochmal meine Frage: Von wem wird das erkannt? Wer prüft das nach einer (jeder) Bearbeitung?

Von wem wird das jetzt erkannt? Und wer kann das überprüfen?

Die Frage verstehe ich nicht. Das von mir beschriebene Szenario kann nur dann eintreten, wenn man eine (Wander-)Route ausschließlich über eine Folge von Wegpunkten definiert, zwischen denen frei geroutet wird.

So, wie wir Wanderrouten derzeit erfassen, als Folge von Ways, kann es nicht eintreten. Dazu müsste Mapper X bewusst die Relation anfassen.

Genau das tut er oben nicht, trotzdem ist sie betroffen.

FraukeLeo wrote:

So, wie wir Wanderrouten derzeit erfassen, als Folge von Ways, kann es nicht eintreten. Dazu müsste Mapper X bewusst die Relation anfassen.

Das ich nicht Lache.... das passiert regelmässig.. dass Löcher reingerissen werden. Gerade mit ID wird da oft und gern mal an Stück geteilt/gelöscht und dann anders zusammengefügt.

Das ganze ist auch das nächste Problem das Routen Relationen wenn sie groß sind schnell mal > 50 versionen haben. Weil jedes Teilen eines Weges, jedes Reparieren und zerstören eine neue Version erzeugt.

miche101 wrote:

Das ich nicht Lache.... das passiert regelmässig.. dass Löcher reingerissen werden.

Ich weiß. Aber das ist nicht das Szenario, das ich in #79 beschrieben habe, und es lässt sich leicht vermeiden (weil dabei die Relation angefasst wird und der Editor das leicht feststellen kann).

Zum dritten Mal: Wenn wir anfangen, Wanderrouten nicht mehr über Ways, sondern nur noch über Stützpunkte zu erfassen, dann kann der von mir oben beschriebene Fehler zwischen zweien dieser Stützpunkte passieren, ohne dass die Relation berührt wird oder auch nur im Editor geladen ist, und ist damit nicht trivial vermeidbar.

miche101 wrote:

FraukeLeo wrote:

Das kannst du, wie oben gesagt, nur zuverlässig verhindern, indem du alle 20 oder spätestens 50 Meter einen Punkt in die Relation setzt, um später versehentlich entstehende Abkürzungen auszuschließen. Gut, kann man machen. Muss dann nur ausgeschlossen werden, dass die Punkte bei irgendeiner Bearbeitung gelöscht werden.

Bei Abkürzungen ist es ganz einfach.. dadurch ändert sich die Gesamtlänge der Strecke und kann durch die größe der Veränderung erkannt werden..

Dazu musst du dir die (alte, korrekte?) Gesamtlänge irgendwo speichern. Ist dieses "speichern" Aufgabe eines QS-Tools oder wer mach das und wo?

miche101 wrote:

Löschen von Punkten... Gegenfragen wie verhindert man das Löschen von Wegstücken bei den jetztigen Relationen?

Verhindern kann man das nicht, nur bei einem QS-Lauf prüfen. Wegstücke die aus Relationen gelöscht werden hinterlassen eine Lücke.

miche101 wrote:

ToniE wrote:

Und wer sagt, dass das ältere Ergebnis das korrekte, das gewollte widerspiegelt?

Wie weisst du das bei jetztigen Relationen? Ich hab die Relationen im MVV im Bereich von 400-900 die ich erstellt hab alle mit Routing und Raten erstellt... es gibt keine Referenz auf die man sich beziehen könnte ob diese Relationen noch richtig oder überhaupt richtig sind. Kein Gpx, Shape, Routenplan..

Korrekt, aber es gibt Kriterien, wie eine Relation formal korrekt aussehen muss. Die inhaltliche Prüfung muss eigentlich immer ein(e) MapperIn machen.

miche101 wrote:

ToniE wrote:

Wer entscheidet, ob das neue Ergebnis ein Fehler oder die Korrektur eines Fehler ist?

Wieder Gegenfrage.. wie läuft das jetzt?

Wie erwähnt, gibt es formale und inhaltliche Kriterien für Korrektheit.
Derzeit kann man die formale Korrektheit des Fahrweges prüfen:

• sie enthält keine Lücken,
  
• nutzt Einbahnstraßen nicht unerlaubterweise in der Gegenrichtung, bzw. kann darauf hinweisen, dass gegebenenfalls ein oneway:psv=no fehlt
  
• nutzt Straßen nicht, wenn access=no dran steht, bzw. kann darauf hinweisen, dass gegebenenfalls ein psv=yes fehlt
  
• nutzt keine highway=construction, ein Grund, die Relation bzgl. Dauer der Baustelle zu prüfen?
  
• ...
  

wenn man davon ausgeht, dass alle Wege in der Relation wie vom Mapper gewollt genutzt werden sollen.

Das "Problem" mit den stop-position und Stützpunkten und Routing-Engine

+Lücken gibt es damit nicht, sehr gut, wünschenswert
+daher sieht es auf Karten immer OK, weil geschlossen aus
- leitet den Bus um die Einbahnstraße dieses Wegstück herum, ob ein oneway:psv=no am Weg fehlt kann nicht erkannt werden
- leitet den Bus um dieses access=no Wegstück herum, ob ein psv=yes am Weg fehlt kann nicht erkannt werden
- leitet den Bus um die Baustelle herum ... auf welchem (korrektem oder falschem) Weg auch immer
- ...

Mein Problem mit dem Anwerfen einer Routing-Engine?

- Wo wird die korrekte Länge des Fahrweges gespeichert, wer ermittelt sie, wer trägt sie ein? Für spätere QS notwendig? Siehe oben.
- Die Routing-Engine arbeitet im Verborgenen, das Ergebnis müsste für die Mapper visualisiert werden: im Editor, auf einer Karte, selektiv: nur für diese Relation
- Das Ergebnis der Routing-Engine entzieht sich einigen formalen Prüfungen, es sei denn, das Ergebniss der Engine ist eine Liste von benutzten OSM-Ways?
- Das Ergebnis der Routing-Engine routet um Fehler am übrigen Datenbestand herum (access=no mit fehlendem psv=yes, Einbahnstraße falsch herum, ...)
- Was passiert aus einer einfachen Kreuzung (mit exakt einem Punkt als Stützpunk in Relationen) nach Editieren wegen Verkehrsinseln (dann vier Punkte) und Nichtanpassen der Relationen?
- Routing-Chaos?
- Wie erkennen wir das? Mal abgesehen von dem "die Länge der Route ändert sich", für das ich noch keine Lösung (gesehen) habe.
- Die Länge einer (Überland-)Route ändert sich übrigens auch durch Lageverschiebungen von Nodes in Kurven. Ab wie viel Änderung der Meter bzw. Prozent wäre ein QS-Hinweis angebracht?
- Überzeuge die Rendering-Engines davon eine Routing-Engine anzuwerfen

Das Ziel: Haltestellen und Stützpunkten und Routing-Engine ist auch für mich attraktiv. Ich sehe nur noch zu viele ungeklärte Punkte: neue Probleme an neuen Stellen, die uns dem Ziel eines einfacheren ÖPNV-Mapping nicht näher bringen?

Edit: Sorry, beteilige mich hiermit massiv am Kapern des Threads. Wir sollten bzgl. Routen-Relationen einen neuen Thread aufmachen.

Wie wäre es wenn die Personen, die hier so nach Routen-Relationen nur mit Punkten schreien, mal konkrete Beispiele präsentieren. Ich sehe da bisher wenig Verständnis für die angesprochenen Probleme. Insbesondere würden sich etliche ÖPV-Betriebe über einen anständige Routingsoftware für Busse freuen. Was im GTFS aus OSM an Shapes vorhanden ist, ist häufig fehlerhaft bis grottig. Selbst beim Zügen wundere ich mich manchmal, an welcher Stelle die Gleise gewechselt werden.

Ganz besonders interessant finde ich die Frage nach der Darstellung in der Editor-Software , was diese Idee an zusätzlicher Unterstützung von der Editor-Software benötigt und wie das alles Ressourcensparend umgesetzt werden kann. JOSM ist ein Offline-Editor also bitte keine externe Daten nachladen.

jengelh wrote:

aighes wrote:

Das wäre mal richtig cool, Routenrelationen nur anhand von Haltestellen und Stützpunkten zu definieren

Dafuer hast du dann die neue Fehlerquelle: XY hat den Stuetzpunkt geloescht

Wenn jemand ne Node löscht und dabei eine punktbasierte Routenrelation schrottet ist das nicht viel anders als wenn jemand ne Node löscht, die Teil eines 2-nodigen Ways ist, der widerrum Teil einer wegbasierten Routenrelation ist.. Im Übrigen gibt es mit Enforcement Restrictions bereits Relationen, die Nodes als Member (from/to) haben - und damit Erfahrungen, wie sich nodebasierte Busrouten im Editor anfühlen könnten (Tip: JOSM warnt wenn man diese Nodes löscht) und, indirekt, wie häufig solche im Vergleich zu wegbasierten Routen kaputt gehen.

Beim Löschen schon, beim Verschieben oder wenn ich den Knoten aus dem highway trenne nicht mehr. TMC-Point Relation sind z.B. wesentlich stabiler mit Wegen als Mitgliedern, als nur Knoten und nicht zu vergessen, wir reden bei diesen Beispielen von einer Kreuzung aber nicht von einer Route quer durch einen Landkreis oder mehr.

ToniE wrote:

, die uns dem Ziel eines einfacheren ÖPNV-Mapping nicht näher bringen?

Aber so wie es ist... haben immer weniger Bock drauf.. mich eingeschlossen.

z.B. diese Linie "Bus 530" wieder zum x-ten mal zu fixen weil die mal wieder zerschossen wurde.. ganz schön zum reparieren, weil hier der Bus öfters die gleichen Wegstücke nimmt.. und das in 5 Varianten kaputt in dieser Linie.

Ich fix das nicht mehr... könnts euch was überlegen.

miche101 wrote:

ToniE wrote:

, die uns dem Ziel eines einfacheren ÖPNV-Mapping nicht näher bringen?

Aber so wie es ist... haben immer weniger Bock drauf.. mich eingeschlossen.

Woher hast Du diese Information? In meinem Gebiet sind es seit 10 Jahren, zwei aktive Personen, die sich um die Relationen kümmern. Da hat sich bis heute nichts geändert.

miche101 wrote:

z.B. diese Linie "Bus 530" wieder zum x-ten mal zu fixen weil die mal wieder zerschossen wurde.. ganz schön zum reparieren, weil hier der Bus öfters die gleichen Wegstücke nimmt.. und das in 5 Varianten kaputt in dieser Linie.

Ich fix das nicht mehr... könnts euch was überlegen.

Welcher Editor-Software wird denn benutzt? iD kannst Du mindestens seit vier Monaten für das Aufspitten auch ohne Schleifen nicht verwenden und das trotz bezahltem Entwickler, von komplizierteren Fällen mal ganz zu schweigen und auch von den ganzen Route-Relationen welche nicht so gut überwacht werden wie z.B. `route=road`.

Ich gebe den Einwänden von FraukeLeo Recht: Ein Zerschießen, ohne dass ein Element der als Punkte erfassten Relation angefasst wurde. Zudem kann ich nicht erkennen, wieso ein auf Punkten basierendes System weniger anfällig fürs "Zerschießen" sein soll. Wie schnell passiert es, dass jemand beim Verändern von Straßenlinien Kreuzungspunkte löscht und neu setzt... das würde dann - so wie ich es verstanden habe - bei dem Vorschlag mit Punkten die Wanderroute zerschießen.

Galbinus wrote:

Einwänden von FraukeLeo Recht

Ihr müsst mir ja nicht glauben, aber nach 12 Jahren OSM Erfahrung wird das im großen und ganzen.. nix. Vielleicht für euer Dorf oder Stadt vielleicht.. aber durchgängig kann man das vergessen. Nicht mal für ganz Deutschland.

skyper wrote:

miche101 wrote:

ToniE wrote:

, die uns dem Ziel eines einfacheren ÖPNV-Mapping nicht näher bringen?

Aber so wie es ist... haben immer weniger Bock drauf.. mich eingeschlossen.

Woher hast Du diese Information? In meinem Gebiet sind es seit 10 Jahren, zwei aktive Personen, die sich um die Relationen kümmern. Da hat sich bis heute nichts geändert.

Na ja, meine Begeisterung lässt schon mal recht schnell nach und hält sich längere Zeit in Grenzen, wenn ich Buslinien mit 39 Varianten sehe.

skyper wrote:

miche101 wrote:

z.B. diese Linie "Bus 530" wieder zum x-ten mal zu fixen weil die mal wieder zerschossen wurde.. ganz schön zum reparieren, weil hier der Bus öfters die gleichen Wegstücke nimmt.. und das in 5 Varianten kaputt in dieser Linie.

Ich fix das nicht mehr... könnts euch was überlegen.

Welcher Editor-Software wird denn benutzt? iD kannst Du mindestens seit vier Monaten für das Aufspitten auch ohne Schleifen nicht verwenden und das trotz bezahltem Entwickler, von komplizierteren Fällen mal ganz zu schweigen und auch von den ganzen Route-Relationen welche nicht so gut überwacht werden wie z.B. `route=road`.

Es gibt halt Dinge, die ein Editor bitteschön richtig machen sollte (split-of-way mit lokalem Einsortieren) und die er bitteschön lieber nicht machen sollte (globales Sortieren einer nicht linearen Wegereihenfolge: Wege werden mehrfach befahren).

miche101 wrote:

Ihr müsst mir ja nicht glauben, aber nach 12 Jahren OSM Erfahrung wird das im großen und ganzen.. nix.

Ich bezweifele ja gar nicht, dass die aktuelle Relationen-Methode störanfällig ist. Ich gebe allerdings FraukeLeo Recht, indem ich die vorgeschlagene Alternative für mindestens ebenso störanfällig halte. Wenn man schon die Mammutaufgabe angehen wollte, das bisherige System komplett umzustellen, dann sollte damit auch eine tatsächliche und deutliche Verbesserung verbunden sein. Und die kann ich nicht im Ansatz erkennen.

Galbinus wrote:

Wenn man schon die Mammutaufgabe angehen wollte, das bisherige System komplett umzustellen, dann sollte damit auch eine tatsächliche und deutliche Verbesserung verbunden sein. Und die kann ich nicht im Ansatz erkennen.

Die Veränderung muss nicht groß sein...
Bei Bus z.b. nur dass die Wegeliste optional ist. Und eine zusätzlich Role in der Haltestellenliste die Role "via" um den Router Korrektur Infos zu liefern.

Bei anderen Routen vermisst man z.B. bei Themen Routen die POI die zu dem Weg gehören. Hier wird nur der Weg abgebildet.. das Thema wird nicht erfasst in der Relation... Als stops.. oder POI.. Viewpoint.. hier bräuchte man auch noch rollen dann noch mit einzutragen.

Schön wäre es zumindest für jede Relation eine statische gpx Datei zu haben, --egal wie alt-- in der die Route gespeichert wird.. damit wenn die Relation kaputt geht darauf zurück zu greifen zu können.

miche101 wrote:

Schön wäre es zumindest für jede Relation eine statische gpx Datei zu haben, --egal wie alt-- in der die Route gespeichert wird.. damit wenn die Relation kaputt geht darauf zurück zu greifen zu können.

Prinzipiell heute schon machbar: GPX Track nach OSM hochladen, und dann irgendein Tag erfinden, unter dem dieser Track dann abrufbar ist, z.B.

ref:gpx=https://www.openstreetmap.org/user/Operadora/traces/3653624

oder direkt auf das GPX verlinken, was auch immer besser funktioniert: https://www.openstreetmap.org/trace/3653624/data

skyper wrote:

iD kannst Du mindestens seit vier Monaten für das Aufspitten auch ohne Schleifen nicht verwenden und das trotz bezahltem Entwickler,

Weil das hier im Forum noch nicht thematisiert wurde, Quincy hat kürzlich seinen "Ausstand" bekanntgegeben. Es gibt im Moment keinen bezahlten Entwickler mehr.

Galbinus wrote:

Ich gebe den Einwänden von FraukeLeo Recht: Ein Zerschießen, ohne dass ein Element der als Punkte erfassten Relation angefasst wurde. Zudem kann ich nicht erkennen, wieso ein auf Punkten basierendes System weniger anfällig fürs "Zerschießen" sein soll. Wie schnell passiert es, dass jemand beim Verändern von Straßenlinien Kreuzungspunkte löscht und neu setzt... das würde dann - so wie ich es verstanden habe - bei dem Vorschlag mit Punkten die Wanderroute zerschießen.

ich pflichte den beiden ebenfalls bei.

Mal was grundsätzliches.

Bis Samstag dachte ich, die Möglichkeit zur präzisen Abbildung der tatsächlichen Verhältnisse sei eine Stärke von OSM. Eine komplexe Kreuzung wie https://osm.org/go/0Dezov85d-?m= ist auf der Karte 1:25000 halt sternförmig ohne weitere Details. In OSM kann ich so weit reinzoomen, dass ich genau sehe, welche Wege direkt vom Stern abgehen und welche erst 20 Meter später abzweigen und von welchem Weg sie abzweigen, und muss dann gar nicht lange suchen. Wenn ordentlich gemappt wurde versteht sich.

Das andere Beispiel von einem Wanderweg, der 20 Meter weit einer Bundesstraße folgt, hatte ich oben auch schon genannt. Es ist hilfreich, solche Details auf der Karte zu sehen, bevor man hinkommt. In OSM kein Thema, weil man theoretisch beliebig weit zoomen kann. Außerdem kann die Sprachausgabe (ich weiß nicht, wer so was beim wandern benutzt, aber warum nicht) dann sagen "folgen Sie der B 4711 nach links für 20 Meter, dann rechts auf den Schotterweg" statt einfach nur "sehen Sie zu, wie Sie auf die andere Seite kommen, da gehts irgendwo weiter" (mehr kann die gedruckte Karte nicht sagen).

Genaues Arbeiten hat nutzungstechnisch nur Vorteile, mit detailgenauen Daten findet man sich draußen besser und schneller zurecht. Deshalb hab ich mich immer bemüht, präzise zu arbeiten, aber das bedeutet halt auch, hin und wieder aus einer Bundesstraße ein wenige Meter langes Stück rauszuteilen und in die Relation zu packen.

Seit Samstag 13:08 Uhr weiß ich, dass das, womit ich mir so viel Mühe gebe, "Irrsinn" ist, der "ins Verderben" führt. Andere mahnen, dass ich zwar nicht pfuschen soll, aber möglichst viel generalisieren muss (heißt wohl: Details weglassen, zum Beispiel an der Achteck-Kreuzung die späteren Abzweigungen mit auf den Kreuzungs-Node zu ziehen). Und kann zu meiner Entschuldigung nur vorbringen, dass ich, wenn ich mal zwei Way-Abschnitte sehe, die völlig grundlos geteilt sind, diese verbinde und damit Pluspunkte sammle 🙂

Ich verstehe aber immer noch nicht, was am Aufteilen eigentlich so furchtbar ist. Ja, es ist ein bisschen mühsam, wenn man eine gesamte Straße bearbeiten will (zB um die ref zu ändern) und erstmal viele Teilstücke einzeln selektieren muss. (Es nervt allerdings noch viel mehr, wenn Flächen drangeklebt sind.)

Also: Was genau ist denn der Nachteil kurz aufgeteilter Way-Abschnitte, worin besteht das befürchtete Verderben? Sind die Nummern für Ways irgendwie knapp geworden, so dass wir haushalten müssen? Oder was soll das "Sparsamkeitsgebot" im Titel heißen?

FraukeLeo wrote:

Ich verstehe aber immer noch nicht, was am Aufteilen eigentlich so furchtbar ist.

Nun, in der Disskussion hat man sich etwas zu sehr auf Routen-Relationen verrannt... Denn schon muß man bei diesen unterscheiden zwischen solchen, die über 2-3 Jahre hinweg gesehen recht dynamisch sind (=Busrouten) und solchen, die sich in der Regel kaum ändern, und wenn, dann ist es einmal und dann ist mindestens die nächsten 5-10 Jahre Ruhe... Wanderwege und Radrouten gehören dazu. Bei diesen würde ich mir eher ein richtig gutes Fehlerprüftool wünschen, wie es vergleichbar für die Knotenpunktnetze gibt.

Andererseits kann ich die Intention des Ausgangspostings gut verstehen.
Es gibt absolut vermeidbare und unnötige Way-Splits. Siehe mein Beitrag #18
Andererseits denke ich, daß bei vielen Dingen ein adäquater Punkt reichen würde... Da fallen mir viele Dinge ein... Schön ausgebaute Parkbuchten entlang einer Straße, mit 1,3 Stellplätzen in Innenstädten, unterbrochen von bepflanzten Inseln, teilweise mit Bäumen... reicht es da nicht einen Punkt im Verhältnis in der Mitte zu setzen mit der Angabe der Anzahl der Stellplätze und Angabe rechts und/oder links der Wegerichtung, anstelle die Straße zu splitten und parking:lane zu setzen?
Ich denke da auch an den zwanghaften Drang, Radwegattribute möglichst an die Straße zu setzen anstelle eines separaten Weges, wo es in der Realität auch passt... Auch viele traffic_calming fallen für mich darunter. Da ließe sich sicher noch einige mehr finden.

Schlußendlich wird man aber ob eines sinnvollen und verwendbaren Routings und auch einer sauberen verlässlichen Kartendarstellung um einen gewissen Grad an Splitten der Wege nicht drum herum kommen. Für eine gute und sinnvolle Auswertung von Routen sehe ich im Moment keine Alternative, als die, die jetzt angewendet wird.

Vielleicht wird es sich auch als nötig erweisen, Kategorien zu entwickeln, bei welchen Dingen eine Splittung zwingend erforderlich ist... In den Abschnitten https://wiki.openstreetmap.org/wiki/DE: … #Attribute und https://wiki.openstreetmap.org/wiki/DE: … e_Merkmale sind für mich durchaus einige dabei, wo ich ein Trennen als nicht nötig erachte. Mich würde aber auch mal interessieren, wie sehr die im Ausgangsbeitrag genannte Situation real in der Fläche ist...

Sven

Es ist die Liebe zum Detail

FraukeLeo wrote:

Mal was grundsätzliches.

Eine Straße wird mitten im Verlauf zur Einbahn. Der Punkt wo das passiert ist nicht dort gemappt, wo das Schild steht, sondern 12m daneben. Also wird die Nichteinbahnstraße an der Stelle gesplittet und der abgespaltene Teil zur Einbahn erklärt. Voilà, das ginge anders auch. Ich habs mit Bauchweh so belassen; nicht ganz freilich, weil so war es möglich, die Gehsteigsituation korrekt abzubilden. Das geht meist ohne splits, und wenn, dann bleibt eben ein Gehsteig ungemappt.

Hier die 12m Tempo 50-100-40 - https://www.openstreetmap.org/way/548874681 - mapillary gibts nichts, aber google streetview - https://www.google.com/maps/@47.2892819 … 312!8i6656

Tatsache ist: den neuen Teil nun an die bestehende Einbahnstraße zu hängen, das würde die Tempolimits nicht mehr "sauber" abbilden lassen. Wollte man das aber durchziehen, dann müssten man den Nichteinbahnteil noch einmal splitten, denn der 50er steht 10m weiter weg von der Kreuzung in die andere Richtung. Und den Feldweg daneben müsste man auch splitten, weil das Schild "Fahrverbot ausgenommen Landwirtschaft" steht auch 10m weg von der Kreuzung. Auch das Einbahnschild steht nicht mitten auf der Kreuzung sonder 5m in die Straße hinein. Da müssten man den Punkt schieben, an dem der Split stattfindet.

Danw wäre alles schön "lagerichtig", wie das weiter oben im Thread bezeichnet wurde - Ich würde dazu sagen: "digital versiegelt".

FraukeLeo wrote:

Also: Was genau ist denn der Nachteil kurz aufgeteilter Way-Abschnitte, worin besteht das befürchtete Verderben? Sind die Nummern für Ways irgendwie knapp geworden, so dass wir haushalten müssen? Oder was soll das "Sparsamkeitsgebot" im Titel heißen?

Danke, diese Fragen sind für mich seit Beginn des Threads auch noch nicht beantwortet.

Hungerburg wrote:

Und den Feldweg daneben müsste man auch splitten, weil das Schild "Fahrverbot ausgenommen Landwirtschaft" steht auch 10m weg von der Kreuzung. Auch das Einbahnschild steht nicht mitten auf der Kreuzung sonder 5m in die Straße hinein. Da müssten man den Punkt schieben, an dem der Split stattfindet.

Zustimmung! So was ist wirklich Quatsch. Es hat auch keinen Nutzen für niemanden.
Ich hab nur etwas rot gesehen, als präzise Erfassung von Wanderrouten ebenso angeprangert wurde. Und das hat definitiv einen Nutzen.

streckenkundler wrote:

Ich denke da auch an den zwanghaften Drang, Radwegattribute möglichst an die Straße zu setzen anstelle eines separaten Weges, wo es in der Realität auch passt...

Die Polen machen schon seit jeher separate Wege. Fuß- und Radwege werden ganz pragmatisch neben die (Auto-) Straße gesetzt, selbst wenn es keinen trennenden Grünstreifen gibt. Das vereinfacht das Tagging ungemein. Und man kann so die Straße auch von Rad- und Wanderroutenrelationen entlasten. Der Nutzbarkeit der Daten für Routing oder Kartenrendering schadet das nicht, im Gegenteil.

Solche abenteuerlichen Konstruktionen wie hier diskutiert
https://forum.openstreetmap.org/viewtopic.php?id=72542
habe ich in Polen auch noch nicht gesehen. Zwei parallele highways, aus die Maus. Hierzulande scheint in gewissen Teilen der OSM-Szene aber eher der Siemens-Ansatz vorzuherrschen: "Warum macht Ihr das so kompliziert?" "Weil wir es können."

Hungerburg wrote:

Hier die 12m Tempo 50-100-40 - https://www.openstreetmap.org/way/548874681 - mapillary gibts nichts, aber google streetview - https://www.google.com/maps/@47.2892819 … 312!8i6656

Tatsache ist: den neuen Teil nun an die bestehende Einbahnstraße zu hängen, das würde die Tempolimits nicht mehr "sauber" abbilden lassen. Wollte man das aber durchziehen, dann müssten man den Nichteinbahnteil noch einmal splitten, denn der 50er steht 10m weiter weg von der Kreuzung in die andere Richtung. Und den Feldweg daneben müsste man auch splitten, weil das Schild "Fahrverbot ausgenommen Landwirtschaft" steht auch 10m weg von der Kreuzung. Auch das Einbahnschild steht nicht mitten auf der Kreuzung sonder 5m in die Straße hinein. Da müssten man den Punkt schieben, an dem der Split stattfindet.

d.h. man muss da gar nicht von 50 auf 100 beschleunigen, um was von der Splittung zu haben, man kann auch aus dem Feldweg mit 100 kommen und muss erst am Ortsschild bei 40 sein.
Wenn die Behörden die Schilder so aufstellen, dann gelten sie auch so, und wenn man es genau nimmt, dann bildet man so was auch ab. Wenn ein Feldweg die ersten Meter noch befahrbar ist, kann man das auch so abbilden, warum nicht. Vermutlich ist das absichtlich so, dass man noch wenden kann.

FraukeLeo wrote:

....
Also: Was genau ist denn der Nachteil kurz aufgeteilter Way-Abschnitte, worin besteht das befürchtete Verderben? Sind die Nummern für Ways irgendwie knapp geworden, so dass wir haushalten müssen? Oder was soll das "Sparsamkeitsgebot" im Titel heißen?

Das Problem ist, dass man die sich nicht ändernden Tags am gesplitteten Weg wiederholt obwohl die sich nicht geändert haben, sprich unnötige Redundanz, und das tut dem Informatiker seiner Seele weh :-).

Und da ist schon, ohne Zweifel, was dran. Obwohl das Problem nicht die kurzen Segmente an und für sich sind, dass kann einfach kein Argument sein wenn unser Datenbestand hauptsächlich aus Wegen mit 4+1 Nodes besteht. Sondern eher, dass das Tagging von, an und für sich gleichen, Wegteilen auseinander driftet und es auch sonst etwas fehleranfällig ist.

Grundsätzlich gibt es für das Problem 2 mögliche Lösungen:

- Routen so zu modellieren, dass die Wege nicht aufgeteilt werden müssen (also zum Beispiel durch Routen die irgendwie Nodes verwenden)

- Die Geometrie von Wegen von den Eigenschaften/Tags zu separieren, also eben "Segmente" (das würde übrigens das "splitte ich den Weg dort wo die Geschwindigkeitsbegrenzung wirklich anfängt, oder lass es für zusätzlich 10m gelten" Problem nicht lösen).

Eines ist ziemlich klar, der Aufwand das Erstere zu machen ist viel viel viel kleiner als das Zweite.

Simon

Pfad-Finder wrote:

Die Polen machen schon seit jeher separate Wege. Fuß- und Radwege werden ganz pragmatisch neben die (Auto-) Straße gesetzt, selbst wenn es keinen trennenden Grünstreifen gibt. Das vereinfacht das Tagging ungemein. Und man kann so die Straße auch von Rad- und Wanderroutenrelationen entlasten. Der Nutzbarkeit der Daten für Routing oder Kartenrendering schadet das nicht, im Gegenteil.

Solche abenteuerlichen Konstruktionen wie hier diskutiert
https://forum.openstreetmap.org/viewtopic.php?id=72542
habe ich in Polen auch noch nicht gesehen. Zwei parallele highways, aus die Maus. Hierzulande scheint in gewissen Teilen der OSM-Szene aber eher der Siemens-Ansatz vorzuherrschen: "Warum macht Ihr das so kompliziert?" "Weil wir es können."

Ich bin sehr für das separate Erfassen von Geh- und Radwegen. Das Hauptproblem hierbei ist jedoch das Routing, da es noch keine einfache Möglichkeit gibt anzugeben, dass man zwischen zwei parallel verlaufenden Wegen wechseln kann und ob und wenn ja welches Hindernis man dabei überwinden muss (kerb). So muss man bei separaten ways sehr viele Verbindungswege einzeichnen. Das wird leider oft nicht gemacht und macht das Routing kaputt.

OSM_RogerWilco wrote:

Das Hauptproblem hierbei ist jedoch das Routing, da es noch keine einfache Möglichkeit gibt anzugeben, dass man zwischen zwei parallel verlaufenden Wegen wechseln kann und ob und wenn ja welches Hindernis man dabei überwinden muss (kerb). So muss man bei separaten ways sehr viele Verbindungswege einzeichnen.

es gibt ein Proposal, type=area, für genau das, wird aber nicht ausgewertet bisher 😉

Strubbl wrote:

FraukeLeo wrote:

Also: Was genau ist denn der Nachteil kurz aufgeteilter Way-Abschnitte, worin besteht das befürchtete Verderben? Sind die Nummern für Ways irgendwie knapp geworden, so dass wir haushalten müssen? Oder was soll das "Sparsamkeitsgebot" im Titel heißen?

Danke, diese Fragen sind für mich seit Beginn des Threads auch noch nicht beantwortet.

+1
Auch nach 5 Seiten Diskussion hab ich noch kein Problem gesehen, das gelöst werden müsste.

smootheFiets wrote:

hab ich noch kein Problem gesehen, das gelöst werden müsste.

ist ja auch alles kein Problem.. solange man es nicht bearbeiten muss.

Wenn es dann mal kaputt geht.. oder sich stark verändert.. und man muss da ran.

Dann wird es zum Problem.. wenn alles verklebt ist, zerstückelt, "übertaggt" , multipolygonitis ausgebrochen, Wege/Punkte/Relationen in einer Vielzahl an Relationen Mitglied ist. Da hilft dann oft nurnoch die Abrissbirne.. delete 🙄

Ich finde dann die Leute cool die dann solche Edits mit ID machen.. 🤣 dass nennt man dann Mut zur Lücke 😉 Meinen nächsten Kreisel bau ich auch mit ID ein mal schauen wie viel ich kaputt mache 🤣

Gruß Miche

smootheFiets wrote:

Strubbl wrote:

FraukeLeo wrote:

Also: Was genau ist denn der Nachteil kurz aufgeteilter Way-Abschnitte, worin besteht das befürchtete Verderben? Sind die Nummern für Ways irgendwie knapp geworden, so dass wir haushalten müssen? Oder was soll das "Sparsamkeitsgebot" im Titel heißen?

Danke, diese Fragen sind für mich seit Beginn des Threads auch noch nicht beantwortet.

+1
Auch nach 5 Seiten Diskussion hab ich noch kein Problem gesehen, das gelöst werden müsste.

Straßen die aus vielen kurzen Einzelsegmenten bestehen erschweren die Bearbeitung und die Wartbarkeit. Bei der Anpassung einer Straße besteht die Gefahr, dass man ein kurzes Stück übersieht.

Für mich ist das aber kein ausreichender Grund. OSM wird detailreicher und das ist die logische Konsequenz daraus. Es ist Aufgabe der Editoren an dieser Stelle besser zu unterstützen.

miche101 wrote:

Ich finde dann die Leute cool die dann solche Edits mit ID machen.. lol dass nennt man dann Mut zur Lücke wink Meinen nächsten Kreisel bau ich auch mit ID ein mal schauen wie viel ich kaputt mache

Du kannst Dich darüber gerne lustig machen, aber als iD-User wusste ich von der Problematik bis vor Kurzem gar nichts. Woher auch?

OSM_RogerWilco wrote:

Straßen die aus vielen kurzen Einzelsegmenten bestehen erschweren die Bearbeitung und die Wartbarkeit. Bei der Anpassung einer Straße besteht die Gefahr, dass man ein kurzes Stück übersieht.

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.

OSM_RogerWilco wrote:

Du kannst Dich darüber gerne lustig machen, aber als iD-User wusste ich von der Problematik bis vor Kurzem gar nichts. Woher auch?

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

Strubbl wrote:

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.

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.

Pfad-Finder wrote:

streckenkundler wrote:

Ich denke da auch an den zwanghaften Drang, Radwegattribute möglichst an die Straße zu setzen anstelle eines separaten Weges, wo es in der Realität auch passt...

Die Polen machen schon seit jeher separate Wege. Fuß- und Radwege werden ganz pragmatisch neben die (Auto-) Straße gesetzt, selbst wenn es keinen trennenden Grünstreifen gibt. Das vereinfacht das Tagging ungemein. Und man kann so die Straße auch von Rad- und Wanderroutenrelationen entlasten. Der Nutzbarkeit der Daten für Routing oder Kartenrendering schadet das nicht, im Gegenteil.

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?

Pfad-Finder wrote:

Solche abenteuerlichen Konstruktionen wie hier diskutiert
https://forum.openstreetmap.org/viewtopic.php?id=72542
habe ich in Polen auch noch nicht gesehen. Zwei parallele highways, aus die Maus. Hierzulande scheint in gewissen Teilen der OSM-Szene aber eher der Siemens-Ansatz vorzuherrschen: "Warum macht Ihr das so kompliziert?" "Weil wir es können."

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?

miche101 wrote:

smootheFiets wrote:

hab ich noch kein Problem gesehen, das gelöst werden müsste.

ist ja auch alles kein Problem.. solange man es nicht bearbeiten muss.

Wenn es dann mal kaputt geht.. oder sich stark verändert.. und man muss da ran.

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.

miche101 wrote:

Dann wird es zum Problem.. wenn alles verklebt ist, zerstückelt, "übertaggt" , multipolygonitis ausgebrochen, Wege/Punkte/Relationen in einer Vielzahl an Relationen Mitglied ist. Da hilft dann oft nurnoch die Abrissbirne.. delete 🙄

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

miche101 wrote:

Ich finde dann die Leute cool die dann solche Edits mit ID machen.. 🤣 dass nennt man dann Mut zur Lücke 😉 Meinen nächsten Kreisel bau ich auch mit ID ein mal schauen wie viel ich kaputt mache 🤣

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.

skyper wrote:

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

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.

westnordost wrote:

Das wäre mal richtig cool, Routenrelationen nur anhand von Haltestellen und Stützpunkten zu definieren! Eine riesige Fehlerquelle ("XY hat aus Unwissenheit meine Routenrelation kaputt gemacht!") für dessen Überwachung viele Tools entwickelt wurden und einige Leute viel Zeit reinstecken würde einfach so verschwinden!

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

sdicke wrote:

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?

woodpeck wrote:

sdicke wrote:

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?

ToniE wrote:

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.

westnordost wrote:

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

Ja

westnordost wrote:

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.

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.

SimonPoole wrote:

Grundsätzlich gibt es für das Problem 2 mögliche Lösungen:

- Routen so zu modellieren, dass die Wege nicht aufgeteilt werden müssen (also zum Beispiel durch Routen die irgendwie Nodes verwenden)

- Die Geometrie von Wegen von den Eigenschaften/Tags zu separieren, also eben "Segmente" (das würde übrigens das "splitte ich den Weg dort wo die Geschwindigkeitsbegrenzung wirklich anfängt, oder lass es für zusätzlich 10m gelten" Problem nicht lösen).

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.

aighes wrote:

Bspw. name=Schulstraße sollte quasi eine collection (=relation) aus den Wegsegmenten sein, die zu dieser Schulstraße gehören.

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/Pro … _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:

Eine typische Stadtbusroute folgt einer bestimmten Route über bestimmte Straßen. Sie ist möglicherweise nicht zu 100 % zeit- oder entfernungsoptimiert, basierend auf den tagesaktuellen Bedingungen. Solane man keine Insider-Verbindung zum Verkehrsbetrieb hat, weiß man wahrscheinlich nicht genug über die Faktoren und Überlegungen, die in die Planung der Route eingeflossen sind, um den Prozess in einem dynamischen Routing-Profil genau nachzubilden. Das Beste, was man tun kann, ist, die Route zu approximieren, was für die Berechnung der voraussichtlichen Ankunftszeit (ETA) in Ordnung sein mag - die kommen sowieso immer zu spät, oder? - aber für visuelle Zwecke könnte das irreführend sein. Trotzdem kann man die tatsächliche Route persönlich überprüfen, indem man mit dem Bus fährt oder in einigen Orten nach aufgemalten Wegweisern an Telefonmasten Ausschau hält.

Viele ländliche und einige vorstädtische Bus-Firmen haben immer noch die Anweisung, (nur) Mitfahrer auf der Strecke mitzunehmen die den Bus herbeiwinken. Eine Route wird hier tatsächlich durch Straßen und Kreuzungen definiert; es gibt keine festen Haltestellen, von denen man sprechen könnte. Paul Johnson wies darauf hin, dass einige Systeme Routen als unscharfe Korridore behandeln, nicht als scharfe Linien: https://lists.openstreetmap.org/piperma … html#14351. Sollten Datenkonsumenten mit zwei völlig unterschiedlichen Datenmodellen für diese beiden Fälle umgehen müssen?

Intercity-Routen und einige städtische Express-Routen sind durch Haltestellen und nur lose durch Straßen definiert. Eine Expressroute hat zum Beispiel Haltestellen, die weit genug auseinander liegen, dass der Fahrer einen gewissen Spielraum hat, um einen Stau zu umfahren, was auf einer konventionellen Route nicht möglich wäre. Übrigens bin ich in San Francisco manchmal mit einem Expressbus gefahren, der auf einem breiten geschützten Radweg fuhr, um den Berufsverkehr zu umfahren. Yeehaw!

Aber in all diesen Fällen hat die Route immer noch eine formale Definition über bestimmte Straßen, auch wenn der Fahrer ihr nicht zu 100% folgt.

Es ist wirklich einfach für einen Mapper, handwaving darüber zu betreiben, was Router tun sollten, besonders wenn der Mapper sich nicht allzu sehr um Routing kümmert. Map-Matching und Via-Point-Routing sind mächtige Werkzeuge, aber sie sind keine Magie.

Aus dem Forumsthread habe ich den Eindruck gewonnen, dass einige Mapper desillusioniert darüber sind, wie kompliziert es geworden ist, die Karte zu mappen und zu pflegen. Ab und zu ist es gesund, einen Schritt zurückzutreten, den Expertenmodus zu deaktivieren und sich an den Presets und den Arbeitsabläufen für Anfänger zu erfreuen. Die Karte wird schon wieder.

westnordost wrote:

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.

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.

westnordost wrote:

Trufi/OpenTripPlanner.

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.

westnordost wrote:

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 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 🙂

Gruß Miche

Hungerburg wrote:

aighes wrote:

Bspw. name=Schulstraße sollte quasi eine collection (=relation) aus den Wegsegmenten sein, die zu dieser Schulstraße gehören.

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.

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:

Bus relations with ways do break too often. I think we’d be better off mapping stops accurately with gtfs identifiers, and keeping the rest in gtfs, and doing routing on demand. I’ve had decent results with osrm.

But if we do need to keep bus routes in osm, then without ways.

I gave a lightning talk on my work in Heidelberg, https://www.youtube.com/watch?v=SdNu-Mz79xg&t=1057s

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.