Und GraphHopper kann auch access:conditional

osm.org/directions?engine=graphhopper_car&route=48.21905%2C11.68619%3B48.21062%2C11.6955#map=15/48.21074/11.67362

GraphHopper machts richtig.

> Ich habe das routing von openstreetmap.org benutzt.

Dort gibt es OSRM, Valhalla und GraphHopper

> Ich habe es gerade nochmla getestet. routing geht fröhlich durch die Baustelle.

Wie gesagt: das hängt davon ab, wie oft und wann die routing-Software sich Daten aus OSM zieht

*:conditional wirkt dann nicht, wenn das Navi das nicht versteht - Fehler im Navi, das Konzept gibt es schon lange genug. Welches Navi hast du verwendet?

*:conditional wirkt dann noch) nicht, wenn das Navi noch nicht die neuesten Daten von OSM kennt. Hier spielt das Update-Interval eine Rolle (auch beim Löschen der Baustelle).

*:conditional hat den Vorteil, dass schon beim Erfassen der Baustelle in OSM klar ist, wann die Beschränkung endet. Ein Update im Navi braucht's am Ende der Baustellenphase nicht.

> (Nach Vorgabe aus dem Wiki)

Auf welche Stelle im Wiki beziehst du dich? Eventuell sollte dort ein Update des Textes erfolgen.

Z.B. wird OsmAnd am 1.08. Daten aus OSM ziehen (ein paar Tage später zum Download anbieten), danach erst wieder am 1.9. Für OsmAnd-Nutzer (Navi) wird die Straße also mit reinem 'access' bis Anfang September als nicht nutzbar angeboten.

Hi mallok,

wir hatten hier vor ein paar Wochen schon mit "access:conditional=no @(...)" getagged, da die Sperrung nur recht kurz ist.

Jetzt, am 24. Juli ist die Sperrung nur noch 17 Tage, also kürzer als ´die ursprünglichen 6 Wochen.

Ich wir sollten hier wieder auf access:conditional statt access gehen.

Gruß
Toni

soundtrips -> round-trips

Hallo mopfattn,

könntes es sich bei deinem drinking water um den Radlerbrunnen an der selben Stelle handeln, der mit drinking_water=yes gemapped ist.
Oder gibt es dort zwei "Quellen"?

Gruß
Toni

Hallo mallok,

wie lange werden die beiden Spreen jeweils dauern:

Bei der B471, nördlich deiner Änderung dort haben wir statt highway=construction die andere, bessere Methode für kurzzeitige Sperrungen (< 2 Monate) gewählt:

access:conditional = no @ (2025 Jun 30-2025 Aug 10)

das wird von Navis verstanden und ist, bzgl. Update-Intervalle von Navis sicherer.

Bei der B471 wwrde ich da mal anpassen.

Wie steht's in Aschheim mit der Münchner Straße?

Gruß
Toni

Ich habe mir die Lage mal vor Ort angeschaut, einen GPX-Trace erstellt und Fehler korrigiert.

Servus

ja, 6 Wochen ist schon grenzwertig.

OsmAND zum Beispiel zieht sich am 1. eines jeden Monats die Daten aus dem OSM, bereitet sie auf und stellt sie ab 6.-10. eines Monats den Usern zum Download zur Verfügung.

Wer nur gelegentlich updated wird u.U. nicht bemerken, oder lange Zeit nicht wissen, dass gesperrt ist oder lange Zeit eine Sperrung sehen, die schon aufgehoben wurde - oder eine Kombination davon.

Viele Grüße
Toni

Servus,

mmh, ich habe mir die Seite beim StBaFS mal angeschaut. Normalerweise mappen wir so kurzzeitige Sperrungen (bis zu 2 oder 3 Monaten) nicht mittels highway=construction sondern eher mit z.B.

access:conditional=no @ (2025 Jun 30-2025 Aug 10)

Der Grund liegt darin, dass viele Navis nicht täglich ihre Daten aus OSM holen und u.U. die Mapper die Baustelle nicht rechtzeitig wieder entfernen. Jeder der beiden Gründe könnte dazu führen, dass Navis die Straße selbst im September/Oktober noch meiden.

Das Konstrukt access:conditional wird von den meisten und wichtigsten Navis verstanden.

VG
Toni

Die Straße ist auf Esri nicht zu sehen, auch auf keinen anderen Luftbildern außer "BayernAtlas". Der ist leider Tabu. D.h. auch dieser Edit muss rückgängig gemacht werden.

Sorry.

Bzgl. "BayernAtlas": das gilt auch für diese Adresse.

Hallo,

der BayernAtlas ist leider keine zulässige Quelle. Wir haben keine Erlaubnis irgendwelche Daten vom BayernAtlas (nicht einmal mehr die Luftbilder) zu nutzen. Bayern ist, was Open Data angeht, das rückständigste aller 16 Bundesländer.

Diese Änderung/der Edit hier muss daher rückgängig gemacht werden.

Sorry und viele Grüße
Toni

Hi Bluesrock,

die Treppen (highway=steps) werden in OSM nicht als Fläche erfasst, lediglich als Weg. Eine Fläche hat keinen Richtung, somit ist dann incline=up/down, handrail:left/right=yes/no nicht abwendbar.
Siehe hier : osm.wiki/DE:Tag:highway%3Dsteps auf der rechten Seite, auf welche Objekttypen das angewendet werden kann.

Ich bin mir auch nicht sicher, ob man hier osm.org/way/1394376473 den Namen des Restaurants wiederholen sollte, room=restaurant sagt ja auch schon genug.

VG
Toni

> In D ist es recht inkonsistent.

Eigentlich nicht, wenn wir beide von Route-Relationen und nicht von Stop-Area-Relationen reden.

> bei den Nodes für die HPs, die ich erstellt habe, willst du das diese Node nicht Mitglied der Relation ist sondern die Node der halteposition.

Exakt.

> OK, kann ich machen. Wäre aber gut zu wissen, wo das definiert ist, dass man das so machen muss.

Im sogenannte PTv2-Schema, d.h.
"Approved Feature Public Transport (approved Version 625726)" osm.wiki/w/index.php?title=Proposed_features/Public_Transport&oldid=625726 Abschnitt 3.1

Gruß
Toni

Servus,

Hier ist was schief gelaufen.

Besser wäre es gewesen, den (nun) "Station"-Node "Rodewisch (169434022)" dort zu belassen wo er war, als Teil des Gleises und als Member von Route-Relationen.
Besser wäre es gewesen, den "Station"-Node neu zu erstellen und die key-values vom "Stop-Position"-Node auf diesen zu übertragen und anzupassen.

Nun haben wir viele Route-Relationen, die einen public_transport=station abseits des Gleises als member haben, während der neue public_transport=stop_position nicht member der Route-Relationen ist.

Wie auch immer, die Korrektur dürfte etwas umfangreich ausfallen.

Darf ich dich um eine Korrektur dieser fehlerhaften Daten bitten?

Gruß
Toni

Beispiele:

https://ptna.openstreetmap.de/results/DE/DE-Bahnverkehr-Analysis.html#train_RB_1

https://ptna.openstreetmap.de/results/DE/DE-Bahnverkehr-Analysis.html#train_RB_2

https://ptna.openstreetmap.de/results/DE/DE-Bahnverkehr-Analysis.html#train_RB_4

https://ptna.openstreetmap.de/results/DE/DE-Bahnverkehr-Analysis.html#train_RB_5

es gibt u.U. noch mehr davon

"Am Bogen", Ottobrunn

Hall fx99,

die default unit für step:height ist 'm', nicht 'cm' (wie bei vielen anderen Längenangaben auch), d.h. nun sind die Stufen hier und in Herrenberg, ... sehr hoch. osm.wiki/Stairs_modelling#Parameter

Ich habe meine Fehler diesbezüglich an den Bahnhöfen in BW (Fehler als als user "NVBW_edit_ToniE" gemacht) bereits korrigiert.

Gruß
Toni