Dann müsste man dem Modell doch einfach nur diese Information hinzufügen. Bekannt dazu ist mir das Proposal Separation. Das würde aber bedeuten, dass man auch bei getrennt gemappten Wegen erst mal davon ausgeht, dass man auf die Straße kann.
die Relation “area” behauptet auch dass sie das kann, das Routen geht aber nur wenn es Linien gibt die verbunden sind, d.h. die Router müssten massenhaft solche synthetischen Verbindungen von Gehweg und Straße erzeugen (in einer Frequenz die gut genug ist, also so was wie alle 10-20m vielleicht), das würde den Graphen vermutlich ineffizient machen. Vielleicht könnte man irgendwie in solchen Fällen auf der Straße routen aber die Länge und Hindernisse vom Fußweg übernehmen? Man bräuchte dann trotzdem für alle expliziten Gehwege eine Relation, weil man ja sagen muss zu welcher Straße der Gehweg gehört (zumindest in bestimmten Fällen wo es räumlich sonst nicht klar wäre)
Erstmal davon ausgehen dass man bei getrennt gemappten Wegen trotzdem jederzeit von einem auf den anderen wechseln kann (von den technischen Problemen mal abgesehen) wäre der SuperGAU, weil es unser Datenmodell sozusagen komplett umdrehen würde und nichts mehr funktionieren würde wie es 19 Jahre lang gemappt wurde.
Wenn man schon einfach an allen Straßenkreuzungen Fußgängerquerungen einbaut, ist das Problem doch zu 99,9% gelöst. Es gibt dann nur noch Probleme, wenn jemand von einer Straßenseite derseleben Straße auf die andere routen möchte. Aber das sind sehr konstruierte Fälle und beim echten „Routing“ nicht wirklich relevant. Und wenn jetzt noch der Fußgänger selbst denkt…
Ich denke beim Erfassen oft an Rollstuhlfahrende oder Menschen mit Gehhilfen. Die sind besonders auf Unterstützung angewiesen, wenn es um das Finden einer passierbaren Route geht. Und das betrifft jede Straße. Besonders die kleinen Wohnstraßen und Nebenstraßen sind da ein Alptraum für solche Menschen, da es an abgesenkten Bordsteinen und Überquerungsmöglichkeiten fehlt. Dem Fußgänger ohne Einschränkungen ist es egal, ob er über ein Bordstein geht oder mal kurz über ein Stück Grasfläche abkürzt. Der brauch auch keine Ansage, wo er am besten über die Straße kommt.
Genau das ist eben nicht der Fall. Für Menschen mit Einschränkungen ist das nicht möglich und auch sonst gibt es viele Stellen, an denen ein sidewalk:*=yes getaggt ist, wo man auch ohne Einschränkungen nicht die Fahrbahn erreichen kann.
Ich möchte mal vermuten, dass das Schema gar nicht das Problem ist, sondern eher, dass es halt seit 20 Jahren anders gemacht wurde und die Umstellung einen enormen Aufwand darstellen würde - die Editoren sind nicht drauf ausgelegt, die Nutz-Software nicht und so weiter. Das Ganze so nach und nach umstellen stelle ich mir extrem schwierig vor, weil ja bei jedem Edit einer Straße die Relation wieder auseinanderbricht. Ist ja schon bei Bus-Routen ziemlich schwierig. Alles in allem: Ich denke mal, das ist ein Fehler, den man vor 20 Jahren gemacht hat und den man nicht mehr ausgebügelt bekommt (so wie die Tabs in den make-files, wo der Erfinder nach 8 Tagen bereits gemerkt hat, dass das eine blöde Idee war - war aber zu spät und deswegen müssen wir uns heute, ca. 50 Jahre später, noch damit rumärgern).
OSM ist u.a. so erfolgreich, weil das Datenmodell so simple ist. Jetzt kommt immer mehr Detail rein (Genauigkeiten unter 1 m, Micromapping, 3D), womit das Datenmodell entsprechend an seine Grenzen stößt.
Das Problem sehe ich tatsächlich eher bei den Editoren. Es wäre möglich zu erkennen, ob verbundene Straßen mit demselben Namen in derselben Straßen-Relation sind und wenn nicht, Alarm zu schlagen (oder besser: anbieten hinzuzufügen), aber damit hätte man immer noch nicht die Geh- und Radwege abgefrühstückt. Außerdem ist der Mehrwert in keinem Verhältnis zum Aufwand, weil man viele der Probleme durch ordentliches Preprocessing auch lösen könnte. Deswegen ist der Leidensdruck auch nicht groß genug, dass man diesen Aufwand weiterhin betreibt. “Keep it simple” skaliert bei OSM besser.
Meine persönliche vermutung ist: erst, wenn wir Straßen (bzw. Fahrbahn, Gehweh und Radweg) als Flächen erfassen, wird sich das ganze erledigen, weil man dann die Verbindung verstellen kann. Aber bis dahin ist es noch weit und es ist kein Modell, welches sich kurz durchziehen ließe, sondern wird sicher ein Dauerbrenner, der auch nie fertig wird.
I hope it is ok to continue in English for this issue?
One problem would be that there is no fixed entry point and no fixed exit point.
One thing that makes it easier is that all sorts of wild configurations of the area are not applicable, I think.
Also, the function needs an area to cross. I suppose you could e.g. map a “crossable area” but I don’t see that happening with any consistency any time soon.
Warum ist das bei heute nicht großflächig implementiert?
Skaliert das auch, wenn man einen weltweiten Datensatz aufbereiten will oder geht das nur für kleine Gebiete in vertretbarem Zeitaufwand? Getestet wurde es für (die damals vorhanden) Plätze. Wenn man nun anfängt auch viele Straßen so zu erfassen, dann ist der Rechenaufwand und der Zuwachs des Routinggraphen evtl. nicht mehr vernachlässigbar. Es müsste also noch ein neuer Test her.
Naja, so unrelevant ist das nicht. Denk mal an Zeitungs- oder Postzustellung (private Unternehmen). Da werden Zustellrouten im Office geplant, der “Fußgänger” kann da nicht mitdenken, der bekommt einfach seinen Laufplan.
Dann aber auch bitte an allen möglichen und sinnvollen Stellen ans restliche Netz anbinden. So wie hier ist es einfach “Malen nach Zahlen”, deren Beispiele gibt es so einige.
Seit gut 10 Jahren gibt es die Freizeitkarte-Android. Die Karte wurde entwickelt unter der Pramisse, alle Verkehrsteilnehmer ‘gleich’ zu behandeln (Autofahrer, Radfahrer, Fußgänger). Fußwege werden z.B. nach den Straßen gerendert und somit nie von Straßen überdeckt, Wem dies (noch) nicht reicht, der kann die Fußwege optional noch signifikanter darstellen (sehr gutes Feature z.B. für Wanderer).
Wobei hier immerhin Straße mit sidewalk=both und der Gehweg mit footway=sidewalk sinnvoll getaggt sind. Man könnte das jetzt so interpretieren, dass Straßen-way und footway-way an jeder beliebigen Stelle verbunden sind und ein Router könnte eigene virtuelle Verbindungen an jeder beliebigen Stelle zwischen den ways ergänzen und diese für das Routing nutzen.
Setzt voraus, dass man diese Annahme trifft (Verbindung zwischen Gehweg und Fahrbahn vorhanden). Aber das tun die Router bei sidewalk-Tags für gewöhnlich auch, obwohl diese Information gar nicht im sidewalk-Tag enthalten ist.
Sorry, aber das habe ich so noch nie beobachten können. Wenn die Zusteller geplante Routen fahren würden, dann wären die Fahrräder der Briefzusteller nicht auf dem Gehweg unterwegs. Ich hab da auch mal nachgefragt, ob die da irgendwelche Sonderrechte haben. Haben sie nicht, es interessiert einfach keinen. Und Briefe zu Fuß zustellen, ohne Fahrrad? Habe ich schon ewwig nicht mehr gesehen. Von daher halte ich Routing von Straßenseite A zu B immer noch für einen Spezialfall, den wir nicht mit künstlichen footway=link-Wegen zu lösen versuchen sollten.
