81

Warum setzt du nicht einfach einen Node irgendwo hin und fügst dann alle sonstigen Informationen die du erfassen willst als Tag hinzu, würde doch OSM total vereifachen, weil man keine Lageinformationen mehr speichern müßte, steht ja alles super in den Tags drin… :wink:

Doch in OSM ist als Geodatenbank doch die Lage und somit auch der Abstand der Wege erfaßt. Wenn der Weg abgesezt ist, läßt man eben den *=sidewalk Tag einfach weg auf dem Stück und gut ist.

Was soll denn der Nutzen von sidewalk=seperate sein? Den Fehler der nur ansatzweise abgebildeten Übergange hast du doch jetzt auch schon, da wird es dur das separat mappen und durchverbinden eher geringfügig besser, als wenn du Wege als Tags an der Straße mappst.

82

Dann hat man aber nur ein Schema, das mit seperaten Kanten. Dieter empfahl, einfach beides zusammen zu mappen. Mir ging es darum, dass beide Schemen zusammen irgendwie Murks sind.

Daher weiß man, dass eine Straße einen Fußweg hat und dieser schon gemappt wurde, halt nur seperat, weil abgesetzt. Ohne sidewalk-Tag ist unklar, ob es bewusst weggelassen hat, weil der Bürgersteig seperat gemappt wurde oder ob - wie bei den meisten Straßen - Fußwege nicht gemappt wurden. sidewalk=no ist falsch, denn es gibt ja einen Gehweg, nur seperat gemappt.

83

Für Straßen/Wege gibt es real mindestens drei Abstraktionsstufen:

  1. Real sind alles in OSM Flächen, die zu mappen ist somit am genausten*).
  2. Ersatzweise zur Fläche werden in OSM Linien gemappt, diese geben zumindest für Straßen/Wege noch ausreichend genau die Lageeigenschaften und die grobe Geometrie wieder.
  3. Die letzte und schlechteste Abstraktionsstufe ohne eigenständige Lage und Geometrieeigenschaften ist die Wege als Tag an der Straße zu mappen.

Daraus ergibt sich, das man nur entweder den Tag an der Straße oder besser, den separaten Weg mappen muß, weil alles andere wäre eine Doppelerfassung. Außerdem ergibt sich, das die Erfassung als Line genauer ist, als die als Tag.

Der Tag sidewalk=seperate ist völlig überflüssig, denn der Router weis ja an hand der separat gemappten Wege, das sie da sind, da braucht er keinen redundanten sidewalk=seperate-Tag an der Straße. Wie oben gesagt, braucht man entweder nur die Fläche, die Line des Weges oder aber den Tag zu mappen.

*) Es geht mir hier nur um die Theorie und nicht um reale DOP- und GPS-Grenzen, die ja auch immer besser werden.

84

Abstrakt finde ich gut, denn du triffst das Problem damit besser.

In Sachen Lage- und Geometriegenauigkeit stimmt deine Reihenfolge. Wenn wir abstrakt bleiben darfst du aber nicht nur einen einzelnen Aspekt beachten. Es gibt aber noch ander Kriterien, da sieht es ggf. anders aus. Ich sehe folgende Kriterien:

  1. Korrektheit der Informationen

  2. Aufwand, den man betreiben muss, um Realität korrekt abzubilden

  3. Wie kommen die häufigsten Anwendungsfälle mit den Daten zurecht

Für mich ist die Reihenfolge der drei Anstriche genau umgekehrt, wobei aber die Anwendbarkeit c) stark von der Korrektheit a) abhängt, aber nicht immer.

Zur Korrektheit in a) gehören neben Lagegenauigkeit auch die Information, ob man von der einen Fläche zur anderen wechseln kann. Diese Information ist beim Getrenntmapping von klassischen Bürgersteigen schlichtweg falsch, weswegen ich das als Fehler sehe, den man i. d. R. ausbessern und damit einen Mehrwert schaffen sollte.

Die geometrische Lage kann man dagegen über width und placement auch bei c) einigermaßen abbilden, wenn auch nicht perfekt. Es bleibt eine Ungenauigkeit, da eine ungeteilte Kante nur eine Breitenangabe haben kann und man wegen b) Kanten nicht zu oft teilen sollte.

Wenn man nur die Lagegenauigkeit als Kriterium nimmt, dann müssten wir Fahrspuren einer Straße immer alle als einzelne Linie mappen. Das wir das nicht machen hat Gründe. Diese Gründe liegen genauso bei “Geh- und Fahrspuren” vor, die anstatt durch einen Strich nur durch eine i. d. R. leicht übewindbare Kante getrennt sind.

Ein Argument für getrenntmapping ist, dass diese Kante für zwar für Fußgänger querbar ist, aber nur schlecht für Rollstühle. Allerdings ist eine durchgezogene weiße Linie für Fahrzeuge auch nicht (legal) überquerbar, für Fußgänger dagegen schon.

“Daraus” m. E. nicht, aber im Fazit stimme ich mit dir überein, Redundanzen sind irgendwie blöd.

Woher soll er wissen, ob die Fußwege in der Nähe der Bürgersteig dieser Straße ist? Im Zweifel routet er den kürzeren Weg an der Straße statt über die Fußwege, die aufgrund ihrer Verschwenkungen länger sind.

Mit sidewalk=seperate kann der Router selber steuern, wie das Ergebnis aussehen soll. Will er Fußgänger über jede Zacke der seperaten Gehwege führen, so kann er die Straßenkante ausschließen.

Will er aber lieber abstrakter routen um Verwirrungen zu vermeiden, so kann er absichtlich die Straßenkante bevorzugen. Durch sidewalk=seperate weiß er ja, dass diese Straße Gehwege hat. Aufgrund des Seperatemappens kennt er dessen Eigenschaften jedoch nicht.

(Edit: inhaltsverstellender Fehler beseitigt: “Bürgersteig” statt “Bordstein”)

85

Dazu gehören aus meiner Sicht alle Aspekte die als Modell der Realität möglichst nahe kommen, womit man dann auch wieder beim Flächenmapping wäre. Das man möglichst alle Attribute der Fläche erfaßt setze ich hier mal vorraus.

Das spricht gegen Flächenmapping (zumindest bis es dafür vernüftige Programmunterstützung gibt), sondern mehr für die Erfassung als Linie, wennn sich die Objekte (Straßen/Wege) dafür eignen.

Das klappt immer, wenn die Daten die Realität ausreichend beschreiben und vernüftig maschinell auswertbar sind.

Beim mappen als Tag am Weg wird die Information über mögliche Wechselmöglichkeiten auch nicht erfaßt, zumindest auch nicht bessser als wenn man den Weg getrennt mappen würde. Um die Übergänge genau zu erfassen muß man möglichst viel als Fläche erfassen und dann die Querungsmöglichkeiten z.B. mit Relationen detailiert erfassen (siehe mein generisches Spurmodell, und klar braucht man das vernüftige Unterstützung durch die Programme, es ist aber abbildbar und lösbar).

Der Hauptgrund warum wir das nicht machen hängt ja eher mit den doch noch beschränkten DOP- und GPS-Genauigkeiten zusammen als mit den Routing, denn mit dem richtigen Modell kann man auch vernüftig über Straßen routen auf der z.B. jede Spur gemappt wurde.

Deswegen muß man ja bei den Querungsangaben/-relationen zwischen physikalischer und gesetzlicher Querung unterscheiden. Und natürlich ist die wie du richtig schreibst, ja auch abhängig von der Forbewegungsart.

Das der Weg neben der Straße verläuft, beschreibt ja *=sidewalk.

Das hängt davon ab, für welche Forbewegungsart geroutet wird:
Füßgänger: 1. Priorität immer Fußwege, zweite Prioriät: die Straße. Der Router würde also wenn es einen Fußweg an der Straße gibt, den Fußgänger nie auf die Fahrbahn schicken.
Auto:1. Priorität immer möglichst gut ausgebaute Straßen, 2. schlechter ausgebaute Straßen; Fuß- und Radwege nie.

Kein Router schickt einen Fußgänger, auch schon wegen der Gefährdung, vielliecht noch auf einer stark befahrenen Straße, auf die Straße, wenn es dort einen Fußweg gibt. Also hat sich die vermeintliche Wahlfreiheit in der Praxis auch schnell erledigt. Das die Straße Gewege hat, weiß der Router im Zweifelsfall auch durch *=sidewalk.

86

das Problem mit unverbundenen Querwegen könnte man dadurch lösen, dass man sie verbindet und dieses Extrastück, das man nicht haben will wenn man Fußwege getrennt betrachten will, auch mit einem Extratag kennzeichnet, z.B.

footway=implicit

das würde man aber erst setzen nachdem oder falls man die expliziten Fußwege mappt. Dann würde man sofern es dort keinen abgesenkten Bordstein gibt den Weg am Schnittpunkt zum Gehweg trennen und das tag auf den Schnipsel Richtung Straße setzen.

87

Naja, genau deswegen macht an das ja so:

  • Straße und Rad-/Gehweg gemeinsam gemappt = Übergang zwischen beiden möglich

  • Straße und Rad-/Gehweg getrennt gemappt = Übergang nicht möglich.

Einfach und verständlich, oder? Entspricht der aktuellen Wiki-Empfehlung.

Um beim gemeinsam gemappten Weg nicht bei der kleinsten Trennung die Wege wieder aufspalten zu müssen, könnte ein Tag an der Kante helfen, das sagt, dass man in diesem Abschnitte eben nicht queren kann, z. B. wegen eines Geländers (crossing_barrier=railing).

Nein, er weiß nur, dass in der Nähe des Fußwegs mit *=sidewalk irgendeine Straße Bürgersteige hat. Welche Straße das ist und welcher Abschnitt genau, kann der Mensch zwar sehen und schlussfolgern. Einer Maschine hilft “sieht man doch” aber nicht.

Das würde bedeuten, Straßen ohne sidewalk-Tag im Fußgängerrouting zu bestrafen oder auzuschließen. Damit wären gefühlt 80% aller Straßen mit Gehwegen ausgeschlossen. Nämlich alle die, wo die Gehwege in OSM nicht erfasst sind. Das wäre ein schlechter Router!

Das sidewalk-Tag kann da helfen:

  • sidewalk=no - Straße hat definitiv keinen Gehweg, bei Hauptstraßen im Fußgängerrouting bestrafen

  • sidewalk=yes - Straße hat definitv einen Gehweg, Kante wird im Fußgängerrouting bevorzugt

  • sidewalk=seperate - Straße hat definitv einen Gehweg, Router entscheidet selber ob er sich auf benachbarte Fußwege zwingt (Straße behandeln wie sidewalk = no) oder die Straßenkante bevorzugt (analog sidewalk=yes).

  • kein sidewalk-Tag - ob Bürgersteig vorhanden ist unbekannt. Kante wird im Fußgängerrouting neutral behandelt

Auch hier, würde das bedeuten, dass man Straßen ohne sidewalk-Tag im Routing bestraft. Also auch alle Straßen, deren Gehwege nich gemappt wurden, was die Mehrheit der Straßen ist.

Dieses Modell wird aber nur funktionieren, wenn es bei c) einfach in der Anwendung ist. Außer dem Taggen der Spurinformationen und Geh/Radwege an der Straßenkante sehe ich keine einfaches Modell. Flächenmapping ist sehr aufwendig und nur mit guten Luftbildern sinnvoll. Relationen zum Zuordnen von Kanten zur Straßenabschnitten sind auch aufwändig und kopmliziert.

88

Entschuldigung, aber das ist etwas zu pauschal und undifferenziert. Was ist ausreichend? Was ist vernünftig? Da setzt subjektives Empfinden ein, mindestens bei letzterem in der Qualität stark abhängig vom Erfahrungslevel im Schreiben von Programmen und dem Verständnis für Datenmodelle für Geoanwendungen.

Die maschinelle Perspektive besteht an einigen Stellen nicht mehr aus Punkten und Linien, die anhand von Koordinaten nett angeordnet sind, sondern aus Ecken und Kanten die einen Graphen darstellen und deren “räumlicher Bezug” für die Maschine wenig “greifbar” ist, bzw. wenig Bedeutung hat.

Zwischen “maschinell Auswertbar” und “Anwendungsfälle”, die ja auch in endlicher Zeit eine Lösung liefern sollten, klafft in deiner These zudem eine Lücke.

Das “wenn die Daten die Realität ausreichend beschreiben” trifft auch auf Sidewalk-Tagging an der Straßenlinie zu.

Für die Interna aller mir bekannten Router ist der zu routende potentielle Verkehrsteilnehmer ohnehin ein “Schrödingers Verkehrsteilnehmer unter Heisenbergscher Unschärferelation” – der Verkehrsteilnehmer befindet sich in einer Richtung überall auf der (jeder) Linie (äh, Kante), solange die Kante die Richtung für den Verkehrsteilnehmer zulässt. Dafür sind erstmal nur sehr wenige Tags relevant (spontan, ohne Anspruch auf Vollständigkeit, exemplarisch: oneway, access (auch die impliziten)).

Der Rest ist nur Penalty-herumgerechne und die Suche nach dem “günstigsten” Weg; für unterschiedliche Verkehrsteilnehmer sind unterschiedliche Straßen unterschiedlich “teuer”. Um ein Gefühl dafür zu bekommen, was Router eigentlich so die ganze Zeit machen, ist brouter prima: Da kann über ein ziemlich offenes Interface die Penalties für Wegstrecken selbst einstellen.

Wenn die Alternative zu 100m stark befahrener Straße (btw. “stark befahren” – welchen Tag meinst du?) ein 5km Umweg ist, ist es nicht so unwahrscheinlich, dass der Router dich auch da entlang schickt – ohne Router würdest du es im Angesicht des Umwegs genau so machen.

p.s. Noch ein kleiner Anhang an Fabi2: Ich finde deine Absolutheitsformen (“kein”, “alle”, “jeder”, “immer”) ja ganz bezaubernd, aber mindestens mir bleibt dann so ein müdes Lächeln im Gesicht hängen wenn mir schon beim Lesen Gegenbeispiele einfallen und ich denke an Asterix und Obelix “Ganz Gallien? Nein…”.

[EDIT: Das p.s. ging mit einer Aufforderung zum Überdenken weiter; Ich wurde darauf hingewiesen, dass das den Ton verschärft, was ich nicht möchte, siehe unten]

89

Schade, dass der Ton auch hier wieder schärfer wird. :frowning:

Edit: Zitat nach Edit gelöscht. Danke, tudacs! :slight_smile:

90

Oh, danke für deine schnelle Reaktion, die mir die Möglichkeit gibt das zu entschärfen; es ist/war humorig gemeint, mit einem Augenzwinkern. Tut mir Leid – ich habe unterschätzt, dass das beim schreiben und sich nicht persönlich kennen/sehen nicht so rüberkommt bzw. rüberkommen kann.

91

In Bezug auf praktikable Darstellung der Beziehung:“dieser Fußweg (sidewalk) gehört mit zur x-Straße” gebe ich dir recht, das anfängertauglich darzustellen ist nicht so einfach, auch wenn es für das Routing an sich ohne Belang ist. Es ist nur schön für die Aufhübschung der Routinganweisungen durch das hinzufügen des Straßennamens: “folgen sie x Meter dem Fußwerg der y-Straße” ist ja schöner als “folgen sie x Meter dem Fußweg an der Straße” (weil die Info hat man ja durch footway=sidewalk). Aber das Problem läßt sich lösen indem man ähnlich dem Ansatz des destination=-Tagging wo man in der Praxis ja auch herausfinden kann welche Orte in der Nähe liegen, einfach z.B. den sidewalk mit street_name= taggt. Das wäre also die äquivalente Krücke um den Verarbeitungsaufwand zu reduzieren bzw. in Einzelfällen (z.B. würde sich ein Rechner schwer damit tun ob man nun den größten Ort mit x Einwohnern oder doch die nahegelegene Toristenattraktion als Ziel angibt) sinnvolle Entscheidungen zu treffen. Das ändert aber nichts an der Tatsache das die Dartellung als getrennter Weg im Zweifelsfall genauer ist.

Das führt aber auf Dauer zu einer totalen Zerhackstükelung der Wege, weil man z.B. auf Teilstück an die barrier=* auf Teilstück b den abgesenkten Bordstein, usw. angeben will, was in Bezug auf die Wartbarkeit der Daten auch nicht toll ist.

Da muß man für die genaue Diskussion unterscheiden zwischen dem Routing an sich und der Vorbereitung der Daten für das Routing, weil nur Letzeteres ist in diesem Falle aufwändiger.

Nein, der Router benuzt ja in diesem Fall (also wenn die Straße keinen sidewalk-Tag hat) den separat gemappten Fußweg (footway=sidewalk)!

Nein, es geht um eine Priorisierung, nicht um eine Verschlechterung der Wertigkeit der Straße, weil die ist ja nicht schlechter, die nehme ich aber nur wenn ich als Router keinen Fußweg finde an dem Knoten, sonst nehme ich erst mal die Fußwege, wenn ich nicht den kürzesten Weg erzwinge in dem Fall die Straße vorgezogen wird, weil sie kürzer ist als der Weg z.B. duirch den Park an dem Knoten.

92

Hallo Fabi,

Ich glaub du hast mich nicht verstanden.

Nicht nur im Routing, auch in der Vorbereitung ist die Zuordnung der seperaten Gehwege zu den Straßenabschnitten nicht eindeutig möglich, nur durch “erraten”, was vermutlich kein Routingprogramm machen wird.

Sowohl Router als auch ein Vorprozess können damit nicht wissen, ob eine Straßenkante ohne sidewalk-tags einen Gehweg hat.

Auch hier hast: Der Router (oder der Vorprozess) kann nicht wissen, ob eine Straßenkante ohne sidewalk-tags einen Gehweg hat.

Um - wie von dir gewünscht - den Router auf seperat gemappte Gehwegkanten zu zwingen, müsste man alle Kanten ohne sidewalk-tags beim Fußgängerrouting bestrafen oder auschließen. So ein Fußgängerrouting wäre aber überall dort unbrauchbar, wo man Gehwege (noch) nicht gemappt hat, egal ob an der Straßenkante oder seperat. Das ist die überwiegende Menge der Straßen in OSM.

Aber das ist auch nur ein Nebenkriegsschauplatz. Das Problem des Seperat-Taggings ist, dass die genauere Lage der Linie erkauft wird mit einem grundlegenden Datenfehler.

Beim Linientaggig sind Lageungenauigkeiten systematisch bedingt, da Breiten - und damit die Lage der Fahrspuren, Rad- und Gehwege - sich fließend ändern können, die widht-Angabe einer Linie aber nicht. Wer Linientagging betreibt (und das ist bei allen Straßen in OSM der Fall) wird mit dieser Ungenauigkeit leben müssen.

Dieser systematische Fehler lässt sich nur durch Flächentagging sauber beheben.

93

Ohne Dir widersprechen zu wollen, das stimmt nicht generell. Gibt reichlich (aber nicht genug) Linien, wo die width kilometerweit vorhanden ist.

94

Hier gibt es auch das “is_sidepath” Proposal https://wiki.openstreetmap.org/wiki/Proposed_features/Key:is_sidepath, welches unabhängig von “highway=footway” funktioniert und schon “is_sidepath:of=[highway_value]” und “is_sidepath:of:name=*” anbietet.

Auch “sidewalk[:left|:right]=separate” an der Straße stehen noch zur Verdeutlichung parat.

Wenn diese Barrieren eingezeichnet werden, ist wohl ein separates Tagging sinnvoll. Sehe ich übrigens schon bei “barrier=kerb” als nützlich an, dann aber bitte auch mit “area:highway” als Flächen zur Komplementierung.

1 Like
95

Ja, aber damit kann man halt nicht bbilden, dass sich die Breite irgendwo kontinuierlich ändert, eine Kante kann nur eine Breite haben und nicht z. B. am Anfang 6m am Ende 9m. Es wird immer Sprünge geben, z.B. wenn eine Abbigespur hinzukommt wird aus 6m plötzlich 9m.

Dadurch springen natürlich auch die Fahrspuren und die Geh- und Radwege, das ist an der Stelle des Sprunges eine Lageungenauigkeit.

96

Dort wird nur ein Straßenname oder eine Nummer angegeben, z. B. “is_sidepath:of:name=Dorfstraße”. Das ist alles andere als eine eindeutige Zurodnung, welcher Straßenabschnitt nun Gehwege hat und welcher nicht. Ich kenne unzählige Dorfstraßen, die mal Gehwege haben mal nicht und wo die Nebenstraßen ohne Gehwege auch Dorfstraße heißen.

Das Beispiel zeigt, dass das Tag sidepath=separate sehr wohl einen Wert hat, denn kann der Fußgängerrouter diese Kante ausschließen weil er sich sicher sein kann, dass der eigentliche Gehweg seperat getaggt ist oder er nimmt sie bewusst, weil er damit weiß, dass die kante einen Gehweg hat, er den Nutzern nicht das Microrouting auf Fußwegen zumuten will (“gehen Sie 3m geradeaus, dann 5m links”)

Das Nutzen von sidewalk=separate schießt aber das gleichzeitige Anwenden von seperaten Gehwegtagging und dem Taggen an der Straße mit sidewalk=* aus.

Das seh ich ja auch so, aber Fabi meinte, der Tag sei nutzlos, was ich ja hier versucht habe zu widerlegen.

97

Das stimmt, ist aber imho kein gutes Argument für oder gegen irgendwas auf DIESER Baustelle.
Wenn auf 3m die Breite und/oder die lanes einer Strasse nicht stimmen, dann sagt das nix über das selbe Tagging auf der Länge aus. Und viel schlimmer noch: es sagt auch nix über anderes “kaputtes” Tagging in vielen anderen themenfremden Bereichen.

98

das könnte man allerdings abbilden, z.B. wenn man die ways so splittet dass jeweils die komplette Änderung von x nach y Breite enthalten ist und man einen tag dafür definiert dass die Breite sich gleichbleibend ändert. Wenn man es noch weitertreiben wollte könnte man Funktionen eingeben die die Breitenänderung beschreiben. Oder auch ohne die ways zu splitten indem man die Breite über Relationen und nodes sowie dem way als membern beschreibt

99

“is_sidepath=yes” ist als Zusatz/Ersatz für “footway=sidewalk” gedacht, aber flexibler und für den separat eingetragenen Gehweg oder sonstigen “Seitenweg”. Als Tag für den “Hauptweg/-straße” ist er nicht gedacht und somit auch nicht als Ersatz für “sidewalk/sidepath=separate” sondern eben die Ergänzung dazu.

Das ist mir neu.

100

du meinst nicht flexibler sondern unspezifischer, man verliert ggf. Informationen, dafür kann man mehrere unterschiedliche Arten von Wegen mit dem gleichen tag taggen.
Das ist natürlich immer eine Abwägung im Tagging, wie allgemein oder spezifisch man die tags gestalten will, aber in diesem Fall, als Zusatztag für highway=footway, finde ich footway=sidewalk genau das, was ich gerne wissen will. Eine weitere Indirektionsebene dazwischenzuschieben halte ich nicht für sinnvoll.
Für seitliche Fahrrad- und Reitwege kann man sich vielleicht trotzdem des tags bedienen