unabhängig von der path/footway/cycleway debatte, ist es doch momentan stand der dinge kombinierte geh/radwege mit segregated=yes/no zu taggen. jetzt wo in vielen städten aber hochauflösende bing bilder zur verfügung stehen, stellt sich die frage ob man hier nicht auch anfangen sollte die geh- und radwege als eigenständige ways zu erfassen, sofern sie durch eine bordsteinkante getrennt sind (segregated=yes). es macht aus meiner sicht keinen sinn bei solchen kontstellationen hier den way in der mitte beider wege zu zeichen. das wäre nämlich fast immer an der stelle wo genau die bordsteinkante ist und bei einem potentiellen blinden-routing wäre das alles andere als hilfreich. ausserdem kommt es immer wieder vor, dass sich diese wege kurzfristig mal trennen und dann wieder zusammenführen, wenn zB alte bäume im weg stehen.
ein offener punkt wäre, wie man dann bei kreuzungsbereichen damit umgeht, wo meistens kurzfristig keine physische trennung der beiden wege vorhanden ist und auch oft eine gemeinsame ampel zum einsatz kommt.
Wenn man das Thema ernsthaft angehen will, sollte man sich erstmal damit beschäftigen, wie man es einträgt. Es sollte auf jeden Fall möglich sein, als Renderer zu sagen, ich möchte nur die Straße rendern und nicht die Wegteile separat. Das hat dann zur folge, dass man diese begleitenden Wege von den eigenständigen Wegen abheben muss.
segregated=yes heißt im übrigen nur, dass es zwei Wegteile gibt, nicht das diese baulich getrennt sind. Meist hat man nur zweifarbiges Pflaster oder eine weiße Linie als Trennung.
Auch fuer das Routing ist es wichtig, dass separat erfasste Wege unterschieden werden koennen und vorallem braucht man an der Strasse weiterhin die extra-Tags. Denn auch mit besseren Luftbildern: Fuer das Navi-Routing bleiben die separat erfassten Wege absolut untauglich, da sich an der GPS-Genauigkeit und den mathematischen Grundsaetzen (Nyquist-Shannon-Abtasttheorem) durch die neuen Luftbilder ja nichts aendert.
da die wege vermutlich mindestens 1-2 meter auseinanderliegen und die positionsermittlung in zukunft sowieso genauer wird (galileo), sollte das eigentlich nicht so ein problem sein. ansonsten dürfte man ja auch keine paralellen seitenstraßen zu hauptstraßen erfassen. abgesehen davon sollte ein navi sowieso das aktuell verwendete transportmittel auswerten und dementsprechend wege auf denen es nicht fahren kann, bei der navigation nicht berücksichtigen bzw gar nicht in das offline-kartenmaterial mitaufnehmen.
Das wurde hier schon x-mal durchgekaut. Koennen wir das nicht so lange als erledigt betrachten, bis sich an der Positionsgenauigkeit tatsaechlich massgeblich was geaendert hat?
Und wie willst Du diese Wege per GPS auseinander halten?
Auch Galileo wird für den öffentlichen Bereich AFAIK nicht diese Genauigkeit bieten, mal abgesehen von der Genauigkeit der OSM Daten und der größeren Ungenauigkeit des GPS in dicht bebauten Gebieten.
Ja, selbiges Argument hab ich auch schon vorgebracht und das ist auch richtig, auch wenn es offenbar manche leute nicht verstehen (wollen). Dann kommt noch als echtes Gegenargument, das der potenzielle Router nicht weiß, wo er sinnvoll z.B. links vom Radweg auf eine abgehende Seitenstraße abbiegen kann. Wobei er ja auch nicht weiß, das es an manchen Stellen z.B. über die Wiese mit dem Fahrrad abkürzen könnte. Momentan liegt die GPS-Genauigkeit noch bei ca. 3 m, was etwa einer Fahrspur entspricht (damit kann man den kombinierten Weg von der Straße unterscheiden, aber nicht mehr die einzelnen Wege voneinander), dazu kommen dann noch die geräteabhängigen zusätzlichen Toleranzbereiche. Modelltechnisch wäre natürlich die getrennte Erfassung deutlich besser.
… die vom Blinden nicht zu ertasten sind.
Selbst wenn ausnahmsweise ein Bordstein da ist, ist oft kein oder nur ein geringer Höhenunterschied da zwischen Geh- und Radweg.
Von daher wäre ein way mit segregated=yes/no für Blinde vermutlichdas bessere Mapping und Tagging, da hier deutlich die Botschaft “Du bist hier nicht alleine unterwegs” drin steckt.
Getrenntes Mappen hieße für ihn “Gehweg ertasten, bauliche Lücke, dann Radweg, dann noch mal Lücke oder Bordstein, dann Fahrbahn”, aber schon nach der ersten ertasteten Lücke nach dem vermeintlichen reinen Gehweg stünde er auf der Fahrbahn …
Also ich weiß ja nicht, ob ich mich als Blinder auf OSM verlassen täte bei dem, was meine lieben Mitmapper *) so alles zusammen mappen
Abgesehen von der GPS-Genauigkeit führt allzu detailliertes mappen eher selten zu einer Verbesserung des Routings.
Wer sich nur hin und wieder mal einen Bereich mit osminspector oder keepright vornimmt, sollte schnell begreifen das wir sobald keine Datengrundlage für solch spezielle Routingapplikationen liefern können.
Mit einem Stift mit runder Mine male ich aber keine Kreise, wenn ich einen Strich male…
Die 3 m beziehen sich ja auch schon auf die Schwankungsbreite der Linie in JOSM, wenn ich unter Optimalbedingungen mit aktiviertem EGNOS geradeaus fahre.
Genau…mit deinem GPS “malst” du eine Linie mit einer Breite von 6m. 3m nach links und 3m nach rechts. Um unter diesen Bedingungen sicher sagen zu können, dass du auf einer Fahrbahn bist, muss diese also mindestens 6m breit sein.
highway:area dürfte hier genau das richtig sein. In Kombination mit den irgendwann mal folgenden drive_lanes hätte man am Ende die Teerfläche als Area für die Karten gemappt und die Wege als Way für die Router. In dem Fall die Wege dann getrennt.