Emblemo de OpenStreetMap OpenStreetMap

Komentoj de ToniE

Ŝanĝaro Kiam Komento
169692617 proksimume antaŭ 14 horoj

Hi,

this was a wrong edit.

There are two steps around there, one is leading from level 0 to level 0.5 (from west to east) and the other (longer one) from level 0 to level -1 (from west to east).

According to your edit, both end on the same level (0.5 != -1), the way from north to the south.

Please be careful with such edits without local knowledge.

Toni

169401784 antaŭ 5 tagoj

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

169401784 antaŭ 5 tagoj

GraphHopper machts richtig.

169401784 antaŭ 5 tagoj

> 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

169401784 antaŭ 5 tagoj

*: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.

169401784 antaŭ 6 tagoj

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.

169401784 antaŭ 6 tagoj

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

168803504 antaŭ 19 tagoj

soundtrips -> round-trips

168556760 antaŭ 24 tagoj

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

168479823 antaŭ 25 tagoj

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

168359354 antaŭ 26 tagoj

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

168385007 antaŭ 26 tagoj

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

168385007 antaŭ 27 tagoj

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

168309079 antaŭ 29 tagoj

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.

168362075 antaŭ 29 tagoj

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

168359354 antaŭ 29 tagoj

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

167515875 proksimume antaŭ 1 monato

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

167070033 proksimume antaŭ 1 monato

> 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

167070033 proksimume antaŭ 1 monato

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

167623163 proksimume antaŭ 2 monatoj

"Am Bogen", Ottobrunn