Relation type=route ein überholtes Model?

AB-inf-x-chg-AB · 2019-08-20T20:21:02.000Z

ToniE:

zumindest was die Fehlererkennung angeht: das war einer der Gründe PTNA [1] zu entwickeln.

[1] https://ptna.openstreetmap.de/

Bezüglich Fehlererkennung beim ÖPNV-PTv2 siehe auch
http://tools.geofabrik.de/osmi/?view=pubtrans_routes&lon=8.95483&lat=51.87340&zoom=13&overlays=ptv2_error_ways

Ich bin auf der Suche nach so einer ähnlichen Ansicht auch für die nicht-ÖPNV-Routenrelationen…

Ansonsten zur Ausgangsfrage,

miche101:

Pflegt ihr noch das Ganze?

Ja, ich entferne ab und an auch Lücken bei Relationen.
Falls die Lücken von OSM-Anfängern kreiert wurden, kann man diese sehr gut benutzen, um bei den beteiligten Objekten auch sonst mal über die Merkmalsliste zu schauen, denn dort findet man häufig weitere interessante Sachen

geow · 2019-08-20T20:28:33.000Z

miche101:

… sag mir eine App die mich an einer OSM route Relation nachführen kann?

Ich weiß nicht genau, was du mit nachführen meinst, aber MapOut zeigt OSM-Routenoverlays u.a. vom Typ ÖVnetz/Velo/MTB/Wandern/Wintersport und exportiert/versendet die bei Bedarf als gpx.

miche101 · 2019-08-21T05:43:07.000Z

GerdP:

Die Router wie Graphhopper oder BRouter werten die Relationen aus. BRouter kann ich so einstellen, das er Fernradwege bevorzugt. Auch für Garmin Karten, die mit mkgmap erstellt werden, können die Daten ähnlich verwendet werden.

Router denk ich werden allerhöchstens mehr Punkte dort vergeben…, weil das ist ja ihr Brot und dann entscheiden. Aber Testen… Was muss man da beim Brouter einstellen? Garmin hab ich nicht, kann ich nix sagen

OSM-Relation:
https://www.openstreetmap.org/relation/37187#map=10/49.0356/11.5542

49Wegpunkte entlang der Strecke:

https://graphhopper.com/maps/?point=49.109507%2C10.753978&point=49.084894%2C10.737987&point=49.044238%2C10.712325&point=49.022705%2C10.781596&point=49.002195%2C10.797835&point=48.969415%2C10.810526&point=48.953463%2C10.864827&point=48.95537%2C10.910971&point=48.94446%2C10.932984&point=48.940115%2C10.962365&point=48.930142%2C10.973353&point=48.905552%2C10.998705&point=48.887507%2C11.017405&point=48.870094%2C11.005292&point=48.865321%2C11.011511&point=48.874096%2C11.03323&point=48.875104%2C11.071861&point=48.898085%2C11.119547&point=48.899034%2C11.15141&point=48.903505%2C11.176201&point=48.892399%2C11.20142&point=48.896383%2C11.252953&point=48.934054%2C11.302598&point=48.936241%2C11.336862&point=48.927869%2C11.373172&point=48.947831%2C11.36625&point=48.951134%2C11.380568&point=48.996615%2C11.374605&point=49.000484%2C11.383305&point=48.98692%2C11.41608&point=49.003763%2C11.450662&point=49.014155%2C11.443052&point=49.038243%2C11.452762&point=49.042088%2C11.469606&point=49.0388%2C11.477062&point=49.029664%2C11.50264&point=49.023186%2C11.560991&point=49.013222%2C11.60344&point=48.985175%2C11.625919&point=48.974925%2C11.662636&point=48.972689%2C11.696158&point=48.957593%2C11.688546&point=48.947418%2C11.733072&point=48.95022%2C11.741768&point=48.941409%2C11.776068&point=48.926405%2C11.794424&point=48.90957%2C11.825535&point=48.916481%2C11.86759&point=48.91552%2C11.87017&locale=de&vehicle=foot&weighting=fastest&elevation=true&use_miles=false&layer=OpenStreetMap

https://maps.openrouteservice.org/directions?n1=48.954072&n2=11.335144&n3=10&a=49.109507,10.753978,49.084894,10.737987,49.044238,10.712325,49.022705,10.781596,49.002195,10.797835,48.969415,10.810526,48.953463,10.864827,48.95537,10.910971,48.94446,10.932984,48.940115,10.962365,48.930142,10.973353,48.905552,10.998705,48.887507,11.017405,48.870094,11.005292,48.865321,11.011511,48.874096,11.03323,48.875104,11.071861,48.898085,11.119547,48.899034,11.15141,48.903505,11.176201,48.892399,11.20142,48.896383,11.252953,48.934054,11.302598,48.936241,11.336862,48.927869,11.373172,48.947831,11.36625,48.951134,11.380568,48.996615,11.374605,49.000484,11.383305,48.98692,11.41608,49.003763,11.450662,49.014155,11.443052,49.038243,11.452762,49.042088,11.469606,49.0388,11.477062,49.029664,11.50264,49.023186,11.560991,49.013222,11.60344,48.985175,11.625919,48.974925,11.662636,48.972689,11.696158,48.957593,11.688546,48.947418,11.733072,48.95022,11.741768,48.941409,11.776068,48.926405,11.794424,48.90957,11.825535,48.916481,11.86759,48.915252,11.870245&b=2b&c=0&k1=de&k2=km

http://brouter.de/brouter-web/#map=10/48.9562/11.3908/osm-mapnik-german_style&lonlats=10.753978,49.109507;10.737987,49.084894;10.712325,49.044238;10.781596,49.022705;10.797835,49.002195;10.810526,48.969415;10.864827,48.953463;10.910971,48.95537;10.932984,48.94446;10.962365,48.940115;10.973353,48.930142;10.998705,48.905552;11.017405,48.887507;11.005292,48.870094;11.011511,48.865321;11.03323,48.874096;11.071861,48.875104;11.119547,48.898085;11.15141,48.899034;11.176201,48.903505;11.20142,48.892399;11.252953,48.896383;11.302598,48.934054;11.336862,48.936241;11.373172,48.927869;11.36625,48.947831;11.380568,48.951134;11.374605,48.996615;11.383305,49.000484;11.41608,48.98692;11.450662,49.003763;11.443052,49.014155;11.452762,49.038243;11.469606,49.042088;11.477062,49.0388;11.50264,49.029664;11.560991,49.023186;11.60344,49.013222;11.625919,48.985175;11.662636,48.974925;11.696158,48.972689;11.688546,48.957593;11.733072,48.947418;11.741768,48.95022;11.776068,48.941409;11.794424,48.926405;11.825535,48.90957;11.86759,48.916481;11.870942,48.915873&profile=hiking-beta

muss sagen openrouteservice.org ist am Anfang zumindest noch dran… dann gibts so viele Abweichungen das dass wohl nicht sehr ins Gewicht das ich so oft genau auf einer Route bin.

miche101 · 2019-08-21T06:54:50.000Z

dieterdreist:

Das ist allerdings nicht nur für OpenStreetMap sondern vermutlich auch für die Fahrgäste ein Graus. Vielleicht müssten da die Fahrplaningenieure auch mal ein bisschen umdenken?

Ja ein Graus, aber auch eine Geldfrage für Netzbetreiber und Gemeinden. Viele Fahren sind oft fahren die in erster für Schüler sind die zu und zurück von der Schule kommen, aber keine “reinen” Schulbuslinien sondern für alle offene Linien.

Galbinus:

Ich denke, es werden hier Äpfel mit Birnen verglichen.

Seh ich jetzt nicht eine Relation type=route mit eim GPX das eine Route beinhaltet zu vergleichen finde ich nicht Äpfel und Birnen.

Galbinus:

Da wäre meine Antwort: Es müsste doch wohl möglich sein, einen speziellen Online-Routen-Editor zu entwickeln, mit denen sich Fehler leicht erkennen und korrigieren ließen und auch Änderungen (wie bei Fahrplänen) ohne großen Aufwand machbar wären.

Eine “WYSIWYG” Editor wäre toll aber gibt es leider nicht …glaub auch nicht so leicht umzusetzen.

Galbinus:

Naja, und wie oft erlebe ich es, dass derjenige, der den GPX-Pfad online angelegt hat, aus Versehen mal an einer Kreuzung den Wegpunkt ein wenig neben die Kreuzung gelegt hat und plötzlich ist dort in der GPX-Route ein Zipfel 100m in einen abzweigenden Weg hinein und dann wieder zurück zur Kreuzung. Das gibt während der Navigation sehr irritierende Anweisenungen: Bitte rechts abbiegen, nach 100 Metern bitte wenden…

So wie es kaputte Relationen gibt kann es auch kaputte GPX Dateien geben… aber statische Dateien gehen wenigsten im nachhinein nicht kaputt.

Galbinus:

Daher: Aus meiner Sicht haben beide Systheme ihre speziellen Einsatzgebiete und die geschilderten Probleme sollten sich meiner Meinung nach lösen lassen, indem endlich ein vernünfter Routen-Editor entwickelt würde.

Ja hat natürlich auch Vorteile… aber auch Nachteile die meiner Meinung überwiegen.

miche101 · 2019-08-21T07:49:24.000Z

geow:

miche101:

… sag mir eine App die mich an einer OSM route Relation nachführen kann?

Ich weiß nicht genau, was du mit nachführen meinst, aber…

Ja das ein Routing-App mich mit Ansagen… z.B. “in 100m links” führen kann…, also an der in Relation eingetragenen Weg entlang navigieren kann.

GerdP · 2019-08-21T08:55:06.000Z

miche101:

Was muss man da beim Brouter einstellen?

Im Profile TrekkingBike z.B.


assign   ignore_cycleroutes   = false   # set to true for better elevation results
assign   stick_to_cycleroutes = true   # set to true to just follow cycleroutes

In der Brouter Datenbank wird dem OSM Way, der Teil einer route=bicycle rel ist, ein spezielles Attribut zugeordnet, z.B. route_bicycle_ncn=yes
Dieses kann man dann im Profile auswerten und damit den Weg bevorzugen. Letzlich beeinflußt man aber tatsächlich nur die Kosten.
Ich nutze das, in dem ich z.B. eine Route von Lichtenstein nach München Hbf berechnen lasse und dann nur noch dort Wegpunkte einfüge, wo mir die berechnete Strecke nicht gefällt. So, komme ich dann z.B. mit nur 11 Wegpunkten auf eine vielversprechende Strecke.

miche101:

Garmin hab ich nicht, kann ich nix sagen

Letztlich ist in mkgmap das gleiche Prinzip implementiert, allerdings muss die OSM Information in ein uraltes Garmin Format gequetscht werden.
Ich habe es aufgegeben, mit den Garmin Programmen lange Touren zu planen, für die Kurzstrecke (< 30 km) funktioniert es, aber dann will ich meist lieber den schnelleren als den schöneren Weg, z.B. wenn ich innerhalb einer Stadt der Weg zum nächsten Hotel berechnen lasse.

ToniE · 2019-08-21T09:43:19.000Z

miche101:

ich finde immer mehr das diese Relations-“bauerei” ein überholtes Model ist, zumindest bei type=route für Fuß, Rad, Auto,(Bus)
…
Was sagt ihr dazu? Pflegt ihr noch das Ganze?

Die Frage ist durchaus berechtigt.

Gelegentlich muss man einen Schritt (“ÖPNV-PTv2”) oder sogar zwei Schritte (“type=route”) zurück machen und sich das Ganze nochmal durch den Kopf gehen lassen:

haben die Konzepte immer noch Bestand und Berechtigung?
welche Alternativen gäbe es, die deren Nachteile beseitigen aber deren Vorteile beibehalten?

miche101 · 2019-08-21T11:22:21.000Z

GerdP:

Im Profile TrekkingBike z.B.

assign ignore_cycleroutes = false # set to true for better elevation results
assign stick_to_cycleroutes = true # set to true to just follow cycleroutes

In der Brouter Datenbank wird dem OSM Way, der Teil einer route=bicycle rel ist, ein spezielles Attribut zugeordnet, z.B. route_bicycle_ncn=yes

das bringt erheblich Verbesserung für Routing ( brouter-Link von mir mit “Wandern (Beta)” Profil und “assign stick_to_hiking_routes 1” ) bis auf ein paar Stellen gleich der Relation. Hat denk ich nur Probleme an stellen wo mehrere Wander-Routen ähnlich bzw. parallel Laufen. Aber das ist jetzt auch nur gut um eine Relation zu einem GPX zu machen

Pluspunkt dafür das man sozusagen über verschiedene offizielle Wanderwege bevorzugt routen lassen kann. Ob das natürlich immer der “bessere” Weg ist bleibt offen… aber man kommt hier mit 49 via Punten zu einem past perfekten GPX-Datei

kleinen Minuspunkte dafür das nicht erkannt wird dann ich die ganze Zeit auf der gleichen Relation bin

Der Pluspunkt würde für das feste Eintragen von Fahrrad/Wander Touren sprechen… für Bus hat das keine Relavanz da kann man dieses nicht ausnutzen, der fährt seinen Fahrplan und nix anderes

kreuzschnabel · 2019-08-21T17:16:09.000Z

Ich habe die Diskussion nach dem OP nur noch überflogen, also bitte nicht schlagen, falls ich einen wesentlichen Aspekt überlesen habe. Aber ein bisschen ging’s mir dabei wie kürzlich der dänischen Krone beim Lesen von Trumps Ansinnen – „meint der das ernst?“

Ich betrachte mal Wanderwege, die sind mir am nächsten (type=route + route=hiking).

Wir möchten in OSM eine möglichst vollständige Beschreibung vorhandener Features in der Datenbank abbilden. Und wenn wir den Sachverhalt „Weg XY geht hier über Track 1 und biegt dort ab auf Pfad 2“ abbilden wollen, dann geht das nicht eleganter als mit einer Relation, die die Beziehung (das heißt Relation wörtlich) zwischen dem (virtuellen) Wanderweg und den (reellen) Tracks und Pfaden digital abbildet. Anhand dieser Relation kann ohne Ortskenntnis, nur aus den Daten, die Aussage getroffen werden, dass Weg xy dort dem Track folgt und dort auf den Pfad abbiegt. Als Folge davon können die gemappten Wegzustände (tracktype, surface, width, smoothness) dem Wanderer mitgeteilt werden, denn man weiß ja, welche Wegabschnitte mit welchen Tags er dabei benutzen muss.

Die Abbildung in einer Relation hat außerdem den Vorteil, dass die Zusammensetzung der Wanderroute in den OSM-Daten selbst enthalten ist. Wer sich, z.B. bei der Geofabrik, einen lokalen Auszug der OSM-Daten runterlädt, hat diese Information frei Haus gleich dabei und muss keine zusätzlichen Quellen anzapfen.

Ein GPX ist eine komplett andere Art von Information, eigentlich nur eine geordnete Abfolge von Koordinatenpaaren mit einigen Metainformationen wie Zeitstempeln oder Namen einzelner Wegpunkte. GPXe sind nicht Teil der OSM-Geodaten, sie würden auf einer separaten Quelle vorgehalten und müssten separat ausgewertet werden. Wobei die Auswertung keine definitive Aussage wie „der Wanderweg verläuft über diesen Track“ mehr machen kann – oder wie sollte das technisch gelöst werden? Sie kann nur sagen, dass der GPX dort lagetechnisch mit dem gemappten Track übereinstimmt und der Wanderweg höchstwahrscheinlich den Track benutzt. Aber das wäre geraten, nicht gewusst wie bei einer Relation, die diese Information hieb- und stichfest kommuniziert.

Jetzt nehmen wir an, Track A ist schnurgerade gemappt, und auch das GPX verläuft dort schnurgerade. Jetzt geht kreuzschnabel diesen Weg ab und stellt fest, dass der schnurgerade Verlauf etwas quick-and-dirty gemacht wurde. Tatsächlich macht der Track dort eine S-Kurve und liegt außerdem 15 Meter weiter westlich. Das ist kein wirkliches Problem, niemand wird sich deshalb verlaufen, aber kreuzschnabel liebt nun mal die Präzision, und der Weg soll in OSM so verlaufen wie in Wirklichkeit. Also setzt sich kreuzschnabel zu Hause sofort an seinen JOSM und verfeinert den Weg anhand seines (meistens ziemlich präzisen) gemessenen GPX. So schön, so gut.

Was macht jetzt der Datennutzer, der sich 15 Minuten später einen Datenbankexport zieht? Er bekommt den verbesserten Track in den OSM-Daten, aber der GPX mit der Wanderroute ist noch der alte – außer kreuzschnabel war so schnell, den gleich mit zu aktualisieren und hochzuladen. Nehmen wir an, er habe das nicht oder noch nicht getan, dann stimmen Track und GPX jetzt nicht mehr überein, und die Zuordnung mit der Aussage „hier ist ein ebener Schotterweg, gut zu laufen“ kann vom Auswerter nicht mehr getroffen werden. Er muss damit rechnen, dass der Wanderweg dort über einen nicht gemappten Pfad quer durch den Wald geht.

Gut, wir könnten einen Automatismus bauen, der bei Bearbeitung eines Wegabschnitts auch alle betroffenen GPXe updatet. Aber wozu? Die Abbildung als Relation sorgt doch schon dafür, dass alles übereinstimmt, denn die muss gar nicht angefasst werden, wenn kreuzschnabel dem Weg ein paar Kurven reinmappt. Der Weg ist nachher wie vorher Member der Relation, der geänderte Verlauf kommt ohne weiteres Zutun in die Relation rein.

Welchen Gewinn böte eine Anlegung als GPXe statt als Relation? Es wäre möglicherweise etwas einfacher herstellbar (wobei mit etwas Übung eine Relation ebenso schnell zusammengeklickt ist wie ein GPX erstellt). Aber die Information wäre nicht mehr in den OSM-Daten enthalten, sondern woanders (und dann können wir gleich die GPXe vom wanderatlas.de nehmen); eine eindeutige Zuordnung von Route und Wegabschnitten (für surface etc.) wäre nicht mehr in den Daten gegeben, sondern könnte nur noch per Lageübereinstimmung geraten werden, und die GPXe müssten separat gespeichert und bei jeder Bearbeitung der Ways mitgepflegt werden.

Es gibt übrigens mehrstöckige Brücken. Spätestens da hätte eine lateral geratene Zuordnung von GPX und OSM-Way verloren

–ks

ikonor · 2019-08-21T19:30:53.000Z

miche101:

das bringt erheblich Verbesserung für Routing ( brouter-Link von mir mit “Wandern (Beta)” Profil und “assign stick_to_hiking_routes 1” ) bis auf ein paar Stellen gleich der Relation. Hat denk ich nur Probleme an stellen wo mehrere Wander-Routen ähnlich bzw. parallel Laufen. Aber das ist jetzt auch nur gut um eine Relation zu einem GPX zu machen

BRouter gibt es auch als Android App. In Verbindung mit Locus oder OsmAnd kann man sich mit einem solchen angepassten Profil auch per Routing führen lassen.

miche101 · 2019-08-22T07:56:14.000Z

Hi kreuzschnabel,

ja so elegant eine Relation ist und technisch vielleicht super ist… so nutzlos ist es. Leider…

Man kann eine Relation nur mit größerem Aufwand mit einer sehr problembehaftete Verarbeitung verarbeiten. Ein “dummes” GPX, kml daraus zu machen das nur ein hat, ist kein Kinderspiel… desweiteren fehlt dem ganzen noch die Höhenangaben welche auch gebraucht werden. Von “höherwertigen” Formaten… ist das dumme Dateiaufbau --Voraussetzung–…

Relationen an sich… als Dateiformat *.osm kann keine Handy App verarbeiten die ich kenne. Man kann auch nicht sagen: “OSMand ich möchte den ‘Sempt Isen Radweg’ nachfahren bitte navigiere mich entlang”. Technisch kann man bisher nur eine Relation als “dumme” mehrstich Darstellung anschauen. Ohne Zusatzinfos über die verwendeten Wege, ohne Höhenprofil, ohne alle aufgezählten vorteile einer Relation… oder in diesem Fall ein kaputtes gpx von https://cycling.waymarkedtrails.org herunterladen das wiederrum dumm ist.

Natürlich kann eine statische Datei veraltern und vom Bestand abweichen. Was meist < 5m sein wird und im Abweichungsbereich des verwendeten GPS-Geräts liegt und darum irrelevat ist. Mit diesen Abweichung der errechneten GPS-Position des GPS-Empfängers muss jeden Navi heute umgehen können. Ansonsten muss man auch wie eine Relation auch mal ein GPX nachgehalten werden bzw. neu generiert werden.

Die großen Nachteile der Relationen:

hohe Aufwand der ersten Erstellung
die Verarbeitung ist sehr aufwendig und Fehlerhaft zu anderen Formaten
fast keine Überstützung durch Programme/Tools/Apps/usw.
Fehler (Lücken, Reihenfolge nicht richtig) im nachhinein entstehen und Jahre lang nicht gefixt werden
Änderungen/Überprüfung kompliziert

Wobei vielleicht der Umfang der Pflege im Wander und Fahrrad sich vielleicht in Grenzen halten würde, aber Bus Bereich ist extrem… mit bis zu 39 Varianten pro Line… im MVV >1000 Relationen notwendig -nur- für Regionalbus. Aber trotzdem bleiben die anderen Nachteile.

Bei mehrstöckige Brücken… hat du immer verloren Also dann wenn das GPS weg ist… sonst stört das ein Navi nicht… das denk du fährst richtig wenn die Position nicht zu weit abweicht…

mfg Miche

kreuzschnabel · 2019-08-22T08:23:16.000Z

miche101:

ja so elegant eine Relation ist und technisch vielleicht super ist… so nutzlos ist es. Leider…

Ich bin schon so oft nach vorhandenen Relationen gewandert, dass ich wirklich nicht weiß, was du hier mit „nutzlos“ meinst.

miche101:

Man kann eine Relation nur mit größerem Aufwand mit einer sehr problembehaftete Verarbeitung verarbeiten. Ein “dummes” GPX, kml daraus zu machen das nur ein hat, ist kein Kinderspiel…

rel2gpx hat mir noch aus jeder Relation ein sinnvolles GPX gezaubert, das überall verarbeitet werden kann, und verarbeitet auch Superrouten tadellos. Zugegeben, es sind mehrere trkseg darin enthalten. Warum muss es ein einziges trkseg sein?

miche101:

Technisch kann man bisher nur eine Relation als “dumme” mehrstich Darstellung anschauen. Ohne Zusatzinfos über die verwendeten Wege, ohne Höhenprofil, ohne alle aufgezählten vorteile einer Relation…

Selbst wenn es entsprechende Auswerter noch nicht gäbe, wäre das kein Argument dafür, auf die Erfassung zu verzichten. Denn wenn wir auf die Erfassung dieser Daten verzichten, wird es auch in Zukunft nie Auswerter dafür geben.

miche101:

desweiteren fehlt dem ganzen noch die Höhenangaben welche auch gebraucht werden.

… die sowieso aus einer Drittquelle kommen müssen, da OSM nur laterale Daten und kein kontinuierliches digitales Höhenmodell hat, nur einige willkürliche ele-Tags, die Dutzende von Metern danebenliegen können, wenn der Erfasser nicht gewusst hat, dass man einen barometrischen Höhenmesser zeitnah kalibrieren muss.

===

Grundsätzlich: Ich bezweifle doch nicht, dass GPXe sinnvoll sind. Wenn ich mir eine eigene Route zurechtgelegt habe, mache ich auch ein GPX draus und lasse mir das in OsmAnd anzeigen. Als Ausgabeformat und Routingvorgabe sind sie natürlich optimal.

Aber sie sind eine komplett andere Baustelle als die Abbildung von Routen direkt im OSM-Material, mit einigen Vorteilen gegenüber dieser, aber auch einigen Nachteilen, und können sie keinesfalls ersetzen.

–ks

chris66 · 2019-08-22T09:46:03.000Z

So ganz verstehe ich die Diskussion nicht. Wer Relationen net mag ist nicht gezwungen diese zu verwenden.

Und wer Vorschläge für eine neue type=super_duper_route Relation hat darf gerne ein Proposal schreiben.

miche101 · 2019-08-22T09:53:30.000Z

kreuzschnabel:

, dass ich wirklich nicht weiß, was du hier mit „nutzlos“ meinst.

Dann zähl einmal auf was du alles damit kannst außer anzeigen?

kreuzschnabel:

rel2gpx

Hab ich auch schon probiert… gibt schon bei einem Kreisverkehr auf…

miche101 · 2019-08-22T09:55:10.000Z

chris66:

So ganz verstehe ich die Diskussion nicht. Wer Relationen net mag ist nicht gezwungen diese zu verwenden.

Ok, bin ich dabei… dann ignoriere ich Relationen. Beim nächsten Kreis an einer Staatsstraße haben >10 Relationen eine Lücke

glglgl · 2019-08-22T10:53:01.000Z

miche101:

Dann zähl einmal auf was du alles damit kannst außer anzeigen?

Man kann mit den geeigneten Tools sich über diese Route führen lassen. Zugegeben, diese Tools könnten auch auf einer gpx arbeiten. Ansonsten ist im Endeffekt natürlich alles irgendwie “anzeigen”.

Aber was viel wichtiger ist, die Konsistenz der Daten wird gewahrt, ohne dass irgendwie geraten werden muss. Wie kreuzschnabel schon schrieb, geht es bei Routen-Relationen darum, den Verlauf eng an den Datenbestand zu koppeln. Wir haben in der Datenbank eine Entität “Feldweg von da über da nach da” (auch Way genannt mit mehreren Nodes). Und eine gegebene Fahrradroute führt, unabhängig davon, ob nun der eine Node einen Meter zu weit links oder zwei Meter zu weit rechts ist, über genau diesen Weg.

Wenn ich nun eine Korrektur an dem Node vornehme, dann ist das eine Positionskorrektur, ändert aber nichts Fundamentales an der Route, die über den Weg führt, dem der Node angehört.

AB-inf-x-chg-AB · 2019-08-22T11:11:03.000Z

miche101:

chris66:

So ganz verstehe ich die Diskussion nicht. Wer Relationen net mag ist nicht gezwungen diese zu verwenden.

Ok, bin ich dabei… dann ignoriere ich Relationen. Beim nächsten Kreis an einer Staatsstraße haben >10 Relationen eine Lücke

Ich denke das ist der richtige Ansatz. Wer neben einfachen Nodes, Ways dann Daten-Strukturen eines höheren Levels (Relationen) anlegt, der sollte nicht davon ausgehen, dass ein Anfänger gezwungen ist sich darum zum Kümmern, und schon gar nicht wenn diese Strukturen auf höheren Level wie bei PTv2 eine sortierte Mitgliederliste besitzen sollen. Alleine weil diese Reihenfolge zu beachten und wiederherzustellen derzeit nicht von allen Editorensoftwares machbar ist, bzw. innerhalb einem gewissen praktikablen Zeitaufwand machbar ist.

D.h. dann für mich, wer eine Route-Relation anlegt, der könnte/sollte dann (von mir aus, sagen wir mal grob nach einem Jahr) auch mal wieder diesbezüglich nach dem Rechten schauen

miche101 · 2019-08-22T13:15:05.000Z

glglgl:

Man kann mit den geeigneten Tools sich über diese Route führen lassen.

Und wie heißt das Tool? bzw. die Tools?

AB-inf-x-chg-AB:

Ich denke das ist der richtige Ansatz. Wer neben einfachen Nodes, Ways dann Daten-Strukturen eines höheren Levels (Relationen) anlegt, der sollte nicht davon ausgehen, dass ein Anfänger gezwungen ist sich darum zum Kümmern, und schon gar nicht wenn diese Strukturen auf höheren Level wie bei PTv2 eine sortierte Mitgliederliste besitzen sollen. Alleine weil diese Reihenfolge zu beachten und wiederherzustellen derzeit nicht von allen Editorensoftwares machbar ist, bzw. innerhalb einem gewissen praktikablen Zeitaufwand machbar ist.

D.h. dann für mich, wer eine Route-Relation anlegt, der könnte/sollte dann (von mir aus, sagen wir mal grob nach einem Jahr) auch mal wieder diesbezüglich nach dem Rechten schauen

Ja vielleicht ist das der einzig richtige Ansatz die links liegen zu lassen… wenn die meisten Relationen kaputt und verweist sind, vielleicht findet dann ein Umdenken statt.

dieterdreist · 2019-08-22T13:29:30.000Z

miche101:

Ja vielleicht ist das der einzig richtige Ansatz die links liegen zu lassen… wenn die meisten Relationen kaputt und verweist sind, vielleicht findet dann ein Umdenken statt.

Mir ist bisher immer noch nicht klar geworden, in welche Richtung du umdenken willst. Was sind die Alternativen zu (z.B.) Wanderrouten in OpenStreetMap?

miche101 · 2019-08-22T14:13:12.000Z

dieterdreist:

Mir ist bisher immer noch nicht klar geworden, in welche Richtung du umdenken willst. Was sind die Alternativen zu (z.B.) Wanderrouten in OpenStreetMap?

Die direkte Bindung am Objekt finde ich überholt… also das man alle Straßen in eine Relation einfügt. Des hat die negative folge das eine Straße z.B. in ganz vielen Relationen Mitglied ist. Erfolg eine Änderung an der Straße müssen im schlimmsten Fall alle Relationen überarbeitet werden, was sehr viel Arbeit bedeutet. Deshalb wäre eine Abstraktion zum Objekt gut… automatisch Routen, Statische Routenverläufe (GPX oder ähnliche Dinge ) usw.

Z.B. hier wäre der Bus die Plage:
https://www.openstreetmap.org/way/449126737#map=18/48.19179/11.84653

Wo man eine Brennpunkt sieht… ob wandern so schlimm ist vielleicht an Knotenpunkten, Bus auf jedenfall
https://taginfo.openstreetmap.org/keys/route#values

Und halt weil mit dem Datenformat “OSM-Relation” schlecht zu arbeiten ist… z.B. GPX draus machen usw.