Also ein gescheiter Fahrradrouter verlässt nicht wegen 2m Abkürzung einen Fahrradweg und routet dann plötzlich über highway=service. Das nur mal zu Beginn.
Wenn es auf dem Tankstellengelände keine Zufahrtsbeschränkung gibt, dann hat der access-tag da auch erstmal nichts zu suchen. Wobei man hier argumentieren könnte, dass jeder davon ausgehen kann, dass ein Tankstellengelände nicht zur Abkürzung zwischen zwei Straßen gedacht ist und daher schon rein rechtlich implizit zumindest ein vehicle=customers hat.
Damit kommen wir wieder zu meiner Einleitung: Auch ein guter Auto-Router verlässt nicht für 2m Abkürzung den highway=xy und routet über einen service-Way.
Ein service Way sollte generell mit so hohen Mali belegt sein, dass er von Routern nur für die ersten/letzten Meter genutzt wird.
Beim Fahrradrouting mag das noch ein wenig offener sein, da service-Ways mitunter in einer Route vorkommen können, z.B. wenn der Radweg in einem Parkplatz mündet.
Zu guter Letzt:
Nein.
Wir mappen zunächst nach der on-the-ground Regel.
Dann mappen wir so, dass wir es den Routern nicht verbauen.
Die Renderer sind uns im Endeffekt herzlich egal - die haben sich nach uns zu richten.
Nebenbei: Es gibt kein Hauptprodukt von OSM. Auch kann nicht gesagt werden, welches Produkt am häufigsten verwendet wird.
Einer der häufigsten Fehler, die gemacht werden, ist, etwas so zu mappen, dass es für die Karte auf osm.org passt. Dabei ist diese Karte nur ein einzelner Vorschlag, wie man die Daten von OSM umsetzen kann.
Auch werden viele Angebote, die wir häufig nutzen vom Ottonormalverbraucher gar nicht wargenommen.
Ich sehe im Endeffekt keinen Handlungsbedarf. Das hier ist ne Sache, die ein Router selbst können sollte.
Das letztere war der hehre Anspruch, mit dem OSM ursprünglich gestartet war. Inzwischen hat sich schon mehrfach gezeigt, dass das so nicht funktioniert. Ich erinnere beispielsweise an die Diskussion, ob der Straßenname an straßenbegleitende Fahrradwege drangeschrieben werden soll oder nicht. Ergebnis war, dass nicht, weil es viel mehr Probleme für die vielen Renderer macht, den wieder heraus zu löschen, als ihn aus den Namen der KFZ-Straße zu produzieren für die wenigen Anwendungen, die ihn brauchen.
Für 3-D Renderer gibt es Anleitungen, wie man am sinnvollsten mappt. Das Gleiche gilt für Feuerwehr-Anwendungen und andere. Für den ÖPNV versucht man schon seit Jahren (erfolglos) ein Modell zu finden, das den Bedürfnissen aller derzeit gewünschten Anwendungen gerecht wird und gleichzeitig für Otto Normalmapper handhabbar bleibt. Da gab es vor Jahren sogar schon einen großen Workshop zusammen mit Verkehrsverbünden.
Das Alles widerspricht aber nicht der “on-the-ground Regel”, die bei einer gewaltigen Mehrheit unumstritten ist. Aber auch da gibt es schon aus der Praxis geborene Ausnahmen. Da sind beispielsweise die Grenzen der Gebietskörperschaften, die vor Ort nicht feststellbar sind, wenn man denn nicht die Grenzsteine ausbuddeln möchte. Das Gleiche gilt für die zwar umstrittenen aber bisher zumindest in Deutschland enthaltenen überbauten historischen Eisenbahnrouten. Eine letzte beispielhafte Ausnahme sind die nicht zu mappenden Naturdenkmale, denen die Zerstörung droht, wenn deren Lage verbreitet bekannt wird.
Zusammenfassend wäre zu sagen, dass schon gewisse Zugeständnisse an die Zwänge der Anwendungen in der Vergangenheit von einer Mehrheit als sinnvoll erachtet wurden. Und deswegen bleibe ich dabei: Wir mappen für die Anwendungen. Ohne diese macht OSM keinen Sinn und kaum jemand von uns wäre dabei.
Ich glaube du meinst das richtige, sagst es aber falsch:
Doch klar funktioniert das! Und das behaupte ich als ein Mapper der wahrscheinlich schon viel mehr Buchstaben ins Forum gehackt hat, als nodes in die DB
Du sagst es… ein Ergebnis - wie wir mappen wollen. Es ist ja auch unsinning einem Radweg einen Straßennamen zu geben Wenn überhaupt könnte man darüber nachdenken einem Radweg einen Radwegnamen zu geben (das aber nur nebenbei).
Falsch… Es gibt für das 3-D Mappen Anleitungen, wie man es am sinnvollsten macht. Das ist ein sehr großer Unterschied.
Das sind aber alles keine Top-Down Verfahren, sondern Bottom-Up wie man so schön sagt. Erstmal definieren wir (die Datenlieferanten) wie wir die Daten in der abstrakten “Map” ablegen wollen. Nimm nur mal die Straßen… Die werden als “Lines” eingefügt obwohl es in Echt gar keine infinitisimal schmalen Straßen gibt… Aber wir Erfasser haben uns damals (als noch nichts da war) mal darauf geeinigt, dass es so (zu diesem Zeitpunkt) am besten ist. In 10 Jahren haben wir Straßen vieleicht flächedeckend als Flächen (uhh der war ein Bodenkriecher:D) gemappt und die Router müssen sich dann ums Flächenrouting den Kopf zerbrechen während die Renderer jubelnd in die Hände klatschen weil Straßen endlich überall so (breit) gerendert könne, wie sie auch in echt sind! (meiner Meinung nach dürfen auch beide Arten zu mappen nebenher bestehen, solange sie konsistent sind)
Es spricht aber übehaupt nichts dagegen all deine Beispiele anders zu machen… Du kannst sofort Höhlen mit seltenen Fledermäusen erfassen, du kannst Eisenbahnrouten die nicht mehr On-The-Ground sind in die OHM verschieben, du kannst Grenzsteine ausbuddeln… Das sind alles keine hoheitlich festgelegten Prinzipien, sondern nur “best practice”. Wenn du Vorschläge hast wie man es besser machen kann ist ja keiner abgeneigt!
Zugeständnisse ist das falsche Wort - es sind eher Symbiosen in meinen Augen - Also Mappingvarianten die unseren Prinzipien nicht schaden, aber anderen eben auch nützen. So wie es hsimpson schon beschrieben hat.
Aber das Thema driftet ab… Die Frage ist ja nicht mehr ob wir Sinnvolles ergänzen wollen (OT) sondern ob wir für andere unsinnige Dinge in die OSM aufnehmen… Ich denke es wäre besser wenn wir wieder zu OT kommen, oder?
Ein eigenes spezifizierendes Tag für einen highway=service an Tankstellen würde zwar Sinn machen, da die Wege Eigenheiten aufweisen, die es sonst in dieser Form nicht gibt. Ihr habt mich jedoch davon überzeugt, dass es keine Anwendung gibt, die davon profitiert. Das Vermeiden der Benutzung von Tankstellen-Wegen lässt sich statt eines Malus für dieses eine Tag mit Malus für solche service darstellen, die kein spezifizierendes Tag aus einer Positivliste aufweisen. Positiv bedeutet hier, dass ein Weg mit diesen Tags zur Abkürzung einer Route zugelassen ist. Da keine Anwendung profitiert und wir IMHO für die Anwendungen mappen, werde ich die Idee nicht mehr weiter verfolgen.
Wenn überhaupt könnte man darüber nachdenken einem Radweg einen Radwegnamen zu geben (das aber nur nebenbei).
