rik_'s Comments
| Changeset | When | Comment |
|---|---|---|
| 134334744 | over 2 years ago | Hallo Chris, bitte beim Zeichnen auch auf Zugangsbeschränkungen aufpassen, die Ways [1] und [2] sind eingezäunt auf Privatgrund. Die Klassifizierung in `path` und `track` sind noch mal ein anderes Thema, letzterer ist in diesem Fall vermutlich eher `service`, der eingezeichnete `path` ist dagegen auf aktuellen Bildern schon gar nicht mehr zu sehen … Danke und viele Grüße rik [1] way/604456902
|
| 132082817 | almost 3 years ago | Hi felixeee, danke, genau diese Info hat mir gefehlt. Das Problem war hier also mal wieder, dass man die Änderungen an Relationen in den gängigen Tools nicht auf den ersten Blick erkennen kann. Sorry für die Nerverei ;-) Viele Grüße rik |
| 132082817 | almost 3 years ago | Hallo felixeee, ich habe eine kurze Frage zu diesem Changeset: Was genau hast du aktualisiert? Auf den ersten Blick sind das nur gelöschte und sofort wieder neu angelegte Wege mit identischen Eigenschaften. Ich vermute aber, dass ich hier etwas übersehe. Kannst du mir weiterhelfen? Viele Grüße rik |
| 129277874 | about 3 years ago | Hi Günthi, kurze Frage: du hast das `smoothness`-Tag in der Zeesener Straße entfernt, ist das Absicht oder Versehen? Viele Grüße, rik |
| 125727463 | over 3 years ago | Hallo, statt Löschen von zugewachsenen Wegen bietet sich oft die Verwendung eines "Lifecycle"-Tags an. Hier wäre z. B. `abandoned:highway=track` geeignet. So bleibt der zeitliche Verlauf erhalten, ohne dass der ehemalige Weg noch einen Einfluss auf Kartendarstellung, Routing oder sonstige Anwendungen hat. Im Wiki ist alles genau beschrieben, vielleicht ist das ja interessant: osm.wiki/DE:Lifecycle_prefix |
| 121269904 | over 3 years ago | Hi Nico! Ich habe diesen Weg tatsächlich nur einmal angefasst und das ausschließlich um offensichtlich falsche/unvollständige Access-Tags zu berichtigen (abgeleitet aus LWaldG; das habe ich in diesem Changeset für mehrere Wege in der Region gemacht [3]). Positions- und Surface-Tags des Weges habe ich selbst nie erstellt/verändert. In der History [1] kannst du das gut sehen. Bei genauem Hinsehen ist zu erkennen, dass die Position mit dem Changeset [2] vermutlich versehentlich geändert wurde. Darunter gibt es auch schon einen entsprechenden Kommentar, bisher aber ohne Reaktion. Viele Grüße und einen schönen Wochenstart rik [1] https://pewu.github.io/osm-history/#/way/19514481 [2] changeset/119316299#map=14/52.3513/13.7061 [3] https://overpass-api.de/achavi/?changeset=121269904&zoom=14&lat=52.3511&lon=13.7042 |
| 124473073 | over 3 years ago | (Und ja, ich find's eigentlich auch unwichtig an der Stelle, so schön ist das da auch gar nicht ;-)) |
| 124473073 | over 3 years ago | Hi @tordans, das ist das was ich meinte mit „Fass ohne Boden” – ich schätze, dass wir hier den Ball stundenlang hin- und herschieben können, ohne wirklich voranzukommen ;-) Daher vielleicht noch zwei Anmerkungen: Das Nutzen von `access`-Tags für Zwecke außerhalb der üblichen Vorgehensweise (Abbilden rechtlicher Zugangsregeln) mag durchaus hier und da vorkommen, du hast ja Beispiele erwähnt. Das ist aber auf jeden Fall eine Ausnahme, welche IMHO eher auf ein anderes Problem hindeutet (Fehlen passender, dedizierter Tags o. Ä.). Für einen Pfad im Wald, welcher sich mit den üblichen Mitteln bereits komplett beschreiben lässt, sehe ich beim besten Willen keinen Grund, so etwas endgültiges wie `access`-Tags aus dem Werkzeugkasten zu holen. Thema Router: dein Beispiel-Link mit der Graphhopper-Route kann Stand heute noch nicht über diesen Weg routen, da die Änderungen noch nicht in die Routingdaten eingeflossen sind (Stand 2022-08-07 08:00 CEST). Das kann man anhand der neu hinzugefügten Pfade ein paar Meter weiter nördlich leicht verifizieren. Als Argument für kann man das also zumindest jetzt noch nicht heranziehen. Und selbst wenn: Am Ende ist es das Problem der Routing-Engine, die vorhandenen Daten auszuwerten und zu entscheiden, ob eine Route über einen Weg geht oder nicht. Dazu sollte die Beschreibung des Weges möglichst genau der Realität entsprechen. Dabei ist es irrelevant, wie „speziell“ der Router ist. Der Gebrechliche-Leute-Router kann und wird jetzt schon außen herum routen, der Bike-Router ebenso, für den Wanderinnen-Router geht die Strecke eben genau da durch und wenn jemand sagt: „Hey, ein, zwei Bäume auf dem Weg stören mich nicht, da trage ich mein Bike schnell drüber“ – warum sollte man das mit dem `access`-Tag verbieten? Die akutellen Tags reichen für eine Entscheidungsfindung in Routern komplett aus. Mit dem `access`-Tag wird nur für bestimmte Anwendungen optimiert. Und genau hier sehe ich das Problem. Es ist und bleibt Tagging für den Router (was im vorliegenden Fall dazu noch komplett unnötig ist wie die Beispiele zeigen). |
| 124389990 | over 3 years ago | Hi! Ich glaube, dir ist hier ein Fehler unterlaufen - du hast die gesamte Straße mit einer Hausnummer versehen: way/24329832 |
| 124473073 | over 3 years ago | Hi tordans, die Ergebnisse eines Routings sind natürlich auch wieder abhängig davon, welche Routing-Engine mit welchem Profil man nutzt [1][2] und hat das Potenzial zu einem waschechten Fass ohne Boden ;-) Wie auch immer, ich sehe trotzdem an keiner Stelle einen `access`-Tag - da dies rechtliche Zugangsregelungen (durch Beschilderung oder was auch immer) impliziert[3], welche aber definitiv nicht vor Ort verifizierbar sind („Mapping für den Router“). `description` könnte IMHO dran bleiben, denn es ist ja eine Info für Anwenderinnen[4] der Kartendaten und könnte durchaus irgendwo sinnvoll genutzt/angezeigt werden[5]. Was meinst du, übersehe ich hier etwas? Viele Grüße rik [1] Beispiel wo das Fußgängerinnen-Routing nach dem Entfernen von `access` jetzt klappt: https://bikerouter.de/#map=19/52.35228/13.58701/standard&lonlats=13.586572,52.352156;13.586939,52.352672&profile=hiking-beta [2] Routing für Gravelbikes führt auch ohne `access` um den Weg herum (hier wird primär `smoothness` ausgewertet): https://bikerouter.de/#map=19/52.35245/13.58693/standard&lonlats=13.586572,52.352156;13.586939,52.352672&profile=m11n-gravel-pre [4] osm.wiki/DE:Key:description [5] Beispiel wieder bikerouter.de: man kann sich solche Elemente direkt auf der Karte einblenden lassen. Screenshot, da hierfür kein Permalink möglich: https://docs.google.com/uc?id=168MaxHNJmFtY6gkc6xr5K1QUlqStQZ2I |
| 124473073 | over 3 years ago | Hi @tordans, wenn's nur um den Baum geht, dann gibt's ja `barrier=log` (ist bereits vorhanden) und ggf. noch `smoothness`=* (ist ebenfalls vorhanden). Daraus lässt sich ja leicht ableiten, ob und für wen der Weg passierbar ist. Zu Fuß kommt man hier ja sehr leicht durch. Der Baum liegt noch dort, daher habe ich die Note am Weg gelassen. `access=` bezieht sich auf rechtliche Zugangsbeschränkungen. Diese sind hier weit und breit nicht zu sehen, daher habe ich das Tag entfernt. Viele Grüße rik |
| 122893890 | over 3 years ago | Hi Stefan, kurze Antwort auf deine Frage: das ist für den Eintrag der betreffenden Wege in der Datenbank nicht relevant. Ausführlicher: Vor Ort gibt es für die betreffenden Wege keine sichtbaren Nutzungseinschränkungen. Daher sollten auch derer keine in die Datenbank eingetragen werden – es enspricht einfach nicht der beobachtbaren Realität. Es ist ein Fehlschluss, anzunehmen, dass ein nicht vorhandenes `bicycle`-Access-Tag auf diesen Wegen bedeutet, dass eine Routing-Software (sofern sie sich an Access-Tags hält) irgendjemanden dort zu Fuß oder auf dem Rad lang schicken wird. Das wird nämlich bereits durch das, von dir erwähnte, kurze Segment mit DE 254 am südlichen Ende auf der L30 [1] ausgeschlossen. Hält sich eine Routing-Software dagegen nicht an die Access-Tags auf der L30, dann ignoriert sie folglich auch die Access-Tags an den Wegen. Zusammengefasst: Wie man es auch dreht, die Tags haben dort aus den beiden genannten Gründen keinen Platz: (a) sie entsprechen nicht der Situation vor Ort und (b) für (Bike + Fußgänger)-Routing-Software machen sie überhaupt keinen Unterschied (egal ob die Routing-Software Access-Tags respektiert oder ignoriert). Viele Grüße rik [1] way/719026584 |
| 119483941 | over 3 years ago | (Ich bin zwar nicht angesprochen, aber vielleicht als kurzen Einwurf: die Passierbarkeit (physisch, nicht rechtlich) hat nichts mit `access` zu tun, sondern ggf. eher etwas mit `smoothness`, `hazard` o. Ä.) |
| 122509391 | over 3 years ago | Hallo Nico, danke für das Nachfragen und das Update. Die Antwort ändert aber erstmal nichts an der Situation vor Ort. Das Befahren des Weges ist also weiterhin nicht untersagt. Ich bin gespannt, ob hier demnächst entsprechend ausgeschildert wird und daraus folgend das `bicycle`-Tagging angepasst werden muss. Viele Grüße rik |
| 122509391 | over 3 years ago | Hi Nico, vielleicht ist es auch einfach so, dass Fußgängerinnen und Radfahrerinnen hier seit langer Zeit konfliktarm miteinander umgehen und eine Beschilderung daher gar nicht notwendig ist? Viele Grüße rik |
| 122242233 | over 3 years ago | Ah, alles klar. Sieht nach einem Kandidaten fürs jahreszeitliche Zuwachsen aus … |
| 122242233 | over 3 years ago | Hallo Stefan, gibt es auf dem Karl-Metten-Ring eine neue Beschilderung bzw. passiert hier gerade etwas an Bauarbeiten o. Ä.? Vor Kurzem war hier noch nichts ausgeschildert, was auf `private` hingedeutet hat. Viele Grüße rik |
| 121953503 | over 3 years ago | Huhu, ich denke, dass `mtb:scale=0` auch eine Aussage ist, nämlich, dass der Wert auf dem jeweiligen Weg eben nicht `1`, `2` oder sonst etwas ist. Klar, in Brandenburg ist die Situation einfacher als woanders. Eine Routing-Software wird diese Implikation anhand der Ländergrenzen oder sonstiger regionaler Einschränkungen aber im Regelfall nicht herstellen. Ich selbst nehme bei der Tourenplanung hier in der Gegend normalerweise auch `mtb:scale=0` an – es hilft aber beim Planen bestimmter Arten von Touren (Gravelbike) zu *wissen,* dass ein bestimmter Weg `mtb:scale=0` hat. So kann ich sicher sein, dass ich da mit dem Gravelbike auch entlang komme (betrachtet natürlich neben `surface`/`smoothness` und anderen Tags). Nur mal als ein Anwendungsbeispiel. Daher halte ich die Angabe von `mtb:scale=0` absolut für berechtigt, auch in Brandenburg. Die Idee, alles was `mtb:scale` > `0` ist, auf `0` zu setzen halte ich für keinen guten Ansatz. Eine Ausnahme natürlich: es ist vor-Ort-Wissen vorhanden. Es gibt durchaus eine Menge `mtb:scale=1` und auch vereinzelt auch `mtb:scale=2` in Brandenburg, wenngleich die betreffenden Wegsegmente natürlich eher kurz sind und wenige Höhenmeter überbrücken. Aber die Länge ist ja kein Kriterium für `mtb:scale`. |
| 121894363 | over 3 years ago | Hallo, bei der Änderung ist aus Versehen ein Node verrutscht, ich habe ihn wieder zurück geschoben. Vgl. Screenshot: https://fotos.nimms-rad.de/f3/0/1/1410-a4wgsrpcf19x-2022_06_06t072448_kfo0a-large.jpg Viele Grüße rik |
| 121558374 | over 3 years ago | Hallo Nico, der Argumentation kann ich an sich folgen. Ich denke aber, dass es sich hierbei nicht um einen Gehweg handelt, für den die StVO gelten würde. Er ist weder straßenbegleitend, noch hat er eine explizite Widmung durch das entsprechende Verkehrszeichen erhalten. Hier wäre ich froh über die rechtlichen Grundlagen – ich konnte sie auf die Schnelle nicht finden. Vielleicht kann mir irgendwer weiterhelfen. Diese Art Wege gibt es ja immer wieder, das sollte also bereits irgendwann mal definiert worden sein. Wie auch immer, das Tagging ist bzw. war inkonsistent, was mich eigentlich zum ursprünglichen Kommentar veranlasste. Viele Grüße rik |