Super, Danke für die schnelle Reaktion.

Gruß
Toni

Hallo Jonas,

ich sehe gerade via PTNA, z.B. https://ptna.openstreetmap.de/results/DE/BY/DE-BY-VGA-Analysis.html#bus_55 dass hier eine Baustelle ist.

Die Dauer scheint mir mit 8 Tagen recht kurz zu sein - auf jeden Fall zu kurz, um es mittels eines einfachen access=no und highway=construction zu machen.

Für kurzfristige Baustellen sollte z.B.:

access:conditional = no @ (2020 Aug 17-2020 Aug 23)

gesetzt und auf highway=construction verzichtet werden.

Hintergrund: Navis, Routing-SW und Karten machen keine regelmäßige, tägliche Updates. OsmAnd z.B. bietet Updates immer so am 10. eines Monats an, die Daten dazu stammen meist vom 1. des selben Monats.

Folge: eine Sperrung vom 20. des Vormonats bis zum 5. diesen Monatgs kommt in die Daten von OsmAand rein, wird dem Nutzer aber erst am 10. bereitgestellt. Die Sperre ist schon wieder weg, der Nutzer "lebt" mit den Daten (der Sperrung) in OsmAnd bis mindestens zum 10. des Folgemonats oder sogar länger - hängt davon ab, wann er den nächsten Update macht.

Das ist nur ein Beispiel, und perfekt kann man sowas nie mappen.

Navis verstehen mittlerweile access:conditional und würden diese Straße hier dann ab 24. August wieder nutzen.

Ein reines access=no ist einfach zu grob um kurzfristige Sperrungen zu mappen.

Das Gesagte gilt auch für Karten-SW, nicht jede Karte reagiert auf Änderungen des OSM-Daten innerhalb von Minuten (wie osm.org) und zeigt durchaus Daten, die eine Woche alt sind (Transport-Layer und Cycle-Layer von osm.org)

Viele Grüße
Toni

Bzgl. GTFS-Daten und aktuelle und ältere:

'skyper' hatte den Vorschlag gemacht, die GTFS-Daten zum Fahrplanwechsel (Mitte Dezember) aufzubewahren und als 'long-term' und auch mit Datum zugänglich zu machen (DE-BY-MVV-long-term als symbolischen Link auf DE-BY-MVV-2020-12-13)

oh ja, auf changeset/89484128?node_page=3#map=20/48.30606/11.90843&layers=TN

noch sichtbar und wohl für 501, 520, 550 und 560 relevant.

Die bekommen wir über die GTFS-Daten wieder an die richtige Position ...

Aber wenn ich so recherchiere: die Haltestelle gibt es beim MVV garnicht mehr, weder im Online-Fahrplan, noch in den aktuellen oder älteren GTFS.

> Die Fahrbahn gibts nicht mehr in diesem Bereich.

Na ja, stimmt nicht ganz, so ganz und komplett ist sie nicht verschwunden. Auf den Plänen gibt es sie noch, im Unterbau, die Kanalisation, ... und es ist ja eine Straßenbaustelle und es ist deutlich einfacher, von highway=construction (was es ja letztendlich ist: "hier wird eine Straße gebaut") wieder auf highway=tertiary|service|... zurückzugehen als alles wieder zu (re-)konstruieren.

Die 14 Ways sind u.A. straßenbegeleitende Fußwege, ... Zufahrten, ... aber auch Kirchgasse, Schrannenplatz, F.-F.-Straße, landshuter Straße, Zollnerstraße.

Alles irgendwie machbar, ich mach' das mal.

Geht es um die Straße beim Schrannenplatz?

Ja, die sollten wir zurückholen und auf highway=construction + construction=* setzten --> gängiges Verfahren bei OSM:

Hallo Wolfgang,

das war Zufall auf einer kleinen Radtour entlang der Grasbrunner Radlrunde. Das Schild ist von Norden kommend sichtbar am Baum befestigt.

Viele Grüße
Toni

Hi, yes, I've noticed the changeset. Sounds reasonable.

We might have the same situation in Haar right and left of Dr.-Mach-Straße osm.org/?mlat=48.11436&mlon=11.71271#map=17/48.11436/11.71271 .
I've been there some days ago and ... maybe we should apply the same settings there.
Br
Toni

Hi,

highway=road

is used if you do not know the exact type of a street.

In this case could those instead be marked as highway=service and service=driveway with appropriate access-tags, or just as highway=path, foot=yes, bicycle=yes and ?=yes?

Best regards,
Toni

Servus Zeusd

bei längeren Baustellen mit Sperrung der Straße (> 1 Monat) wird in der Regel so getagged:

highway=construction

construction=residential

(in diesem Fall, wenn vorher highway=residential war)

Kurzfristige Baustellen werden in der Regel nicht gemapped, das hängt mit der Updatestrategie von Navis, ... zusammen.

Bei Baustellen ohne Sperrung wird auch nichts unternommen.

Bei kurzzeitigen Sperrungen kann man z.B. mit

access:conditional = no @ (2020 Aug 13-2020 Sep 1)

arbeiten, das verstehen die meisten Navis sogar.

Viele Grüße
Toni

Mmh, dann müste ein hgv=destination an die Lederergasse und eine restriction:hgv = no_left_turn von Rotter Straße in die Lederergasse noch hinzu?

Ich vermute mal, dass die Abbiegeverbote wegen der spitzen Winkel beim Abbiegen existieren.

Stimmt, wobei eigentlich nur relation/11498940 notwendig ist.

Die Lederergasse hat ein hgv=no und ein no-u-turn auf sich selbst wird als sinnlos erachtet (*to add a no_u_turn restriction relation seems only useful if from-member and to-member are different way objects).

Hat somit den gleichen Effekt nur mit einem andere Mittel.
Das Straßenschild in der Münchener Straße sagt allerdings "only_right_turn".

Aber, ja mei, wenn's der iD dann korrekt darstellt.

iD sollte man aber trotzdem auf das Bild https://ibb.co/F6XxFzG hinweisen und anmerken, dass restriction:* = only_right_turn wohl fehlerhaft dargestellt wird..

Oops, da hat der wohl only_right_turn mit no_right_turn verwechselt.

Man könnte gegen iD und JOSM jeweils einen Bug aufmachen.

Für JOSM mache ich das mal.
Bei iD weiß ich nicht so genau, was angezeigt wurde / nicht angezeigt wurde, ...

Dann tippe ich mal auf einen Fehler in iD.

Allerdings zeigt es JOSM auch nicht an, wenn es "restriction:hgv" heißt, aber das ist ein Problem von JOSM.

osm.wiki/Relation:restriction

Mmh, 'only_right_rurn' heißt doch "man darf nur nach rechts abbiegen" also nur zum Marktplatz hin fahren - da wird alles andere verwehrt.

Hi, mmh, verstehe ich nicht.

HGV darf hier von Norden kommend weder in die Rotter Straße noch in die Ledergasse fahren. Ist meine Annahme korrekt?

Also darf HGV nur nach rechts Richtung Marktplatz fahren.

Das war das, was die Turn-Restriction aussagte: only_right_turn

Sollte also passen.

Gruß
Toni

Hi,

und da hätten wir noch Fahrplandaten des VRS in maschinen-lesbarer Form als GTFS, die wir in OSM nutzen dürfen.

Datum 2020-06-23 - passt das mit dem Fahrplanwechsel, oder sind die veraltet? Neuere Daten sind noch nicht verfügbar.

* https://ptna.openstreetmap.de/gtfs/DE/routes.php?network=DE-NW-VRS

Und z.B. die Linie 522 mit ihren verschiedenen Fahrstrecken

* https://ptna.openstreetmap.de/gtfs/DE/trips.php?network=DE-NW-VRS&route_id=800522

Und die erste von 11 Fahrstrecken gem. Fahrplan:

* https://ptna.openstreetmap.de/gtfs/DE/single-trip.php?network=DE-NW-VRS&trip_id=18-522-008-1588.2.21%3A052400-39-161_16BE7B42-C750-4167-8BEC-ABC000F4AF10

und im Vergleich dazu die bereits gemappte OSM-Relation

* https://ptna.openstreetmap.de/relation.php?id=3753995&lang=de

VG
Toni

Hallo Wunderspieler,

ob die Linie noch formale Fehler hat kannst du bei verscheidenen Tools prüfen:

* PTNA https://ptna.openstreetmap.de

* OSM Inspector https://tools.geofabrik.de/osmi/?view=pubtrans_routes&lon=11.56600&lat=48.13900&zoom=10&overlays=ptv2_routes_,ptv2_routes_valid,ptv2_routes_invalid,ptv2_error_,ptv2_error_ways,ptv2_error_nodes

* Route-Analyzer http://ra.osmsurround.org/

Viel Spass noch

Toni

Yes, PTv2 route relations include only stop-positions, platforms and ways related to the bus, train, ... represented by the relation.

Stop-Areas usually include stops/platforms where the particular bus, train ... does not stop - for instance the relation representing the itinerary in the opposite direction.

Kindly see here for an overview:

osm.wiki/Public_transport

... and this links to the approves specification of PTv2

osm.wiki/w/index.php?title=Proposed_features/Public_Transport&oldid=625726

Br
Toni