Weil das ein Wiedergänger eines toten Schemas ist. Hat nicht funktioniert - und wird nicht funktionieren.
Supposed that the router does know that the space can be crossed by foot, could a router use this to calculate the itinerary?
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).
1 Like
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.
1 Like
Yes, @maxbe already proved 10 years ago that this works.
Ja. Dass das funktioniert, hat @maxbe bereits vor 10 Jahren bewiesen.
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.
2 Likes
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).
Ich hab’ mal surface=tartan ergänzt. 
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.
Wie ich schon schrieb: Fie einzig wirklich 100% richtige Modellierung wäre das Erfassen von Fahrbahn, Geh- und Radwegen als area. Dort, wo sich eine Fußweg- und eine Fahrbahn-Area treffen und keine barrier=* dazwischen ist, kann man theoretisch kreuzen. Aber das wäre einfach Wahnsinn, das zu erfassen und bis dahin halte ich die beiden Kompromisse „Kreuzungsmöglichkeiten explizit erfassen“ oder „davon ausgehen, dass überall gekreuzt werden kann“ gepaart mit (dem unterstellten) gesunden Menschenverstand für gar nicht so schlecht.
3 Likes
Bei dem „davon ausgehen, dass überall gekreuzt werden kann“ müsste man dann aber festlegen, wer/was dort kreuzen kann. Meine Beobachtung ist, dass die meisten gesund und fit sind und das als Maßstab anlegen: “Ich kann hier lang, alles andere interessiert mich nicht!” Finde ich immer etwas schade.
Kam ja sogar schon bei Fahrradrouting diese Aussage: “Ich kann problemlos mit dem Rad über erhöhte Bordsteine fahren.” Tja, und das soll unsere Grundlage für das Mapping sein?
Das wäre für mich Sache des Routers, ob er nur an highway=crossing das Kreuzen anbieten möchte, oder überall. Eine ganz normale Einstellung, so wie eben auch „möchte ich mit dem Fahrrad über erhöhte Bordsteine geroutet werden“. Dass das kein Router so umsetzt ist ja ein ganz anderes Problem.
1 Like
Aber dafür müssen doch die Daten erstmal da sein und deren Bedeutung festgelegt sein.
Was bedeutet ein sidewalk=right/sidewalk:right=yes bezüglich Verbindung zwischen Fahrbahn und Gehweg? Kann ein Bordstein vorhanden sein? Welche Höhe darf er haben? Darf ein gemähter Grasstreifen dazwischen liegen oder eine Grünstreifen mit mehr Vegetation. Ein Wassergraben? Darf ein Leitplanke oder Absperrung dazwischen liegen? Usw. usf…
Aktuell kann sidewalk immer getaggt werden, sobald es ein Gehweg parallel zur Fahrbahn gibt. Was soll ein Router machen? Er weiß aktuell bei sidewalk einfach nicht, ob und wo man die Straße kreuzen kann.
Dafür müsste man festlegen: positives sidewalk-Tagging impliziert, dass ein Mensch ohne Einschränkungen jederzeit (oder mind. alle x Meter) zwischen Fahrbahn und Gehweg wechseln kann. Sollte das nicht der Fall sein, darf sidewalk:*=yes bzw. sidwalk=right/left/both nicht getaggt werden.
1 Like
Meiner Meinung nach müssen wir alle baulich vor Ort vorhanden Verbindung von Straße zu Gehsteig/Pfad usw einzeichnen, ob das nun Pfade, Zufahrten zu Grundstücken, Hofeinfahrten Feldern usw sind. Dazu entsprechend die Randsteine. Nur das hilft dem Blinden, Rollstuhlfahrer usw die Straße vernünftig und einigermaßen sicher zu queren.
Für alle anderen Personen kann man meines Erachtens erwarten die Augen zu benutzen um die Situation vor Ort und die Karte zu betrachten.
1 Like