Ähm, vergessen: Es ist wohl auch ein Zaun drumrum, oder?

Hallo Martin,

access=private wäre hier (statt access=permit) auf den Wegen innerhalb des Geländes korrekter, denn so ohne Weiteres darf man da nicht hin, oder?

access=permit, impliziert, dass man den Weg benutzen kann und dass es einfach ist eine Genehmigung zu bekommen.

access=private würde ich auch statt private=staff mappen.

Gruß,
Toni

Danke,

Dez 2021? Das ist ja mal richtig schnell für eine Brückenbaustelle.

Scheint aber eh nur LVG 40 als Buslinie zu betreffen.

https://ptna.openstreetmap.de/results/DE/SH/DE-SH-NAH.SH-Analysis.html#bus_40

Gruß
Toni

Servus brogo,

der Neubau dauert doch sicherlich eine Weile, oder?

Was ist mit den Busrelationen hier?
Gibt es neue Fahrpläne?

Gruß,
Toni

... ab 17. Mai ...

Na ja, das Tor kann die Feuerwehr öffnen, Zugang also nur für "emergency".

"Wiese mit grass_paver": genau so sehen die Feuerwehrzufahrten hinter die Gebäude aus, kein erkennbarer Weg, aber ein tragfähiger Untergrund für Einsatzfahrzeuge (Drehleiter, ...)
Kombinaion von highway=service und service=emergency_access halt.

Ich mag die Darstellung auf Mapnik nicht, aber was soll man machen.

openfiremap.org mit eigenem Kartenhintergrund wäre geeignet, diese Tags auszuwerten und als Einsatzwege darzustellen.

Servus map per,

highway=service
service=emergency_access
surface=grass_paver

waren schon korrekt, auch wenn das Ergebnis auf Mapnik nicht zufriedenstellend sein mag, aber: wir mappen nicht für die Renderer ;)

Gruß,
Toni

Hab' dir 'ne Message geschickt.

> Das eintragen von Barrierefreiheit klingt echt aufwendig.

40 000 Haltestellen alleine für Bayern, RMS (Rhein-Main-Verbund-Service) und MentzDV arbeiten dran - gerüchteweise ein Umfang von 1 Millionen €

Alle Verbünden müssen bis Ende 2021 sowas bieten (nicht unbedingt in OSM).

> Das mit dem Thema ÖPNV Mapping klingt interessant.

PTv2 ist nicht unumstritten, weil zu aufwändig, ... ohne derzeit einen echten Mehrwert zu bieten?

Dieser Thread im Forum enthält einiges zu dem Thema https://forum.openstreetmap.org/viewtopic.php?id=72607

> also werde ich vermutlich PTv1 priorisieren.

guter Ansatz!

Zunächst einmal die ~ 800 Buslinien in PTv1 erfassen, viele existieren in OSM noch nicht einmal.

Wenn ich Zeit habe könnte ich die Liste der VRM-Linien ( osm.wiki/Verkehrsverbund_Rhein-Mosel/Analyse/DE-RP-VRM-Routes ) für OSM basierend auf dem Online-Fahrplan aktualisieren und somit eine bessere Analyse in PTNA ( https://ptna.openstreetmap.de/results/DE/RP/DE-RP-VRM-Analysis.html ) zeigen.

Eine Bitte noch: keine existierenden PTv2-Relationen rückwärts in das schlechtere PTv1 konvertieren. Bzgl. Karten bietet PTv2 alles was PTv1 kann.

N.B. NVBW (Nahverkehr Baden-Württemberg) und BEG (Bayerische Eisenbahngesellschaft) arbeiten (lassen arbeiten) gerade daran Haltestelleinformationen zur Barrierefreiheit in OSM einzuarbeiten.

BTW: am 6.6.2021 findet bei der FOSSGIS Konferenz 2021 der sogenannte OSM-Sonntag statt.
Dafür habe ich das Thema "ÖPNV-mapping" vorgeschlagen:

osm.wiki/FOSSGIS_2021/OSM-Sonntag

https://forum.openstreetmap.org/viewtopic.php?id=72434

> Bei PTv1 reicht einen einzelne Relation, die alle befahrenen Straßen und angefahrenen Haltestellen beinhaltet - zur Not unsortiert.

Eine Relation pro Buslinie meine ich hier.

Hi, ja das war falsch.

Es gibt zwei Definitionen, wie man ÖPNV in OSM mappen/taggen kann.

PTv2 ist das neuere Schema.

PTv2 erfordert jedoch einiges an Anfangsaufwand für den Mapper, nur die Zahl zu ändern reicht bei Weitem nicht.

Bei PTv1 reicht einen einzelne Relation, die alle befahrenen Straßen und angefahrenen Haltestellen beinhaltet - zur Not unsortiert.

Bei PTv2 muss es zunächst, im einfachsten Fall, eine Route-Master-Relation und jeweils eine Route-Relation für die beiden Richtungen geben (echte Rundkurse mal ausgenommen).

Im Wesentlichen: für jede unterschiedliche Spalte (gemäß Abfahrtszeit) im gedruckten Fahrplan braucht's eine Route-Relation:

Beim 301er sehe ich hier 6 Varianten für die Hinfahrt (5:57, 6:57, 12:37, 13:37, 21:29, 1:00)
und 8 (?) für die Rückfahrt. Varianten im Bezug auf: andere Fahrroute, Haltestellen werden nicht angefahren, ...

Du siehst, der Aufwand (im ländlichen Bereich) ist recht hoch. Wir haben anderswo schon mal ~ 50 Varianten gesehen.

Die Frage für dich ist nun: wie ist der konkrete Auftrag?

- am einfachsten: sollen die Linien und Haltestellen lediglich auf einer Karte zu sehen sein? --> mappen nach PTv1 mit einer Relation pro Buslinie ist ausreichend.

- am ...

- am kompliziertesten: sollen aus OSM-Daten GTFS-Daten generiert werden? D.h. bzw. inkl. "shape". --> dann komplettes, vollständiges mappen nach Ptv2.

Danke, dürfen andere OSMler die Webseite und die Fahrplanauskunft ebenfalls nutzen?

Manche Verbünde erlauben nicht einmal das.
München: MVV für Stadtbusse, betrieben von der MVG.
Für die MVV-Regionalbusse gibt es sogar die ausdrückliche Erlaubnis für OSM auch GTFS zu nutzen.

Für ein Malen von Karten, Darstellung der von Bussen benutzten Straßen reichen PTv1-Realtionen aus. Die Qualitätssicherung ist dabei aber sehr eingeschränkt.

PTv2 ist aufwändiger, erlaubt eine bessere formale Prüfung, ... bringt für Kartendarstellung aber keinen weiteren Nutzen.

Die Tendenz geht aber Richtung PTv2.

BTW: hast du was mit dem VRM zu tun, beruflich, ...?

Weißt du, ob der VRM GTFS-Daten hat, unter welcher Lizenz?

https://ptna.openstreetmap.de/de/gtfs-doc.php#gtfsdata

Viele Grüße,
Toni

Alles klar, Danke für die Info.

Servus vrmuser,

der Bus 101 ist eindeutig noch ein public_transport:version=1 getaggter Bus.

Wenn es eine Linie nach PTv2 wäre, so bestünde der aus ~ 20 Relationen und einem Route-Master - das habe ich mir seinerzeit nicht angetan, das war mir zu aufwändig.

Viele Grüße,
Toni

Wäre interessant, ob und wie sich die Hausnummern "Leeberg x" über die Gemeinde verteilen: historisch gewachsen ohne das jemals "aufgeräumt" wurde?

"leeberg 1" wird von Nominatim (der Suchmaschine von OSM) nun 3 mal (weltweit) gefunden ...

Ist bei OSM also nun alles OK.

1.) Building 1, Leeberg, Tegernsee, Landkreis Miesbach, Bavaria, 83684, Germany
way/692055816

2.) House 1, Leeberg, Veld, Arcen, Venlo, Limburg, Netherlands, 5944EA, Netherlands
node/2890060780

3.) Platform Tegernsee Bahnhof, Leeberg, Tegernsee, Landkreis Miesbach, Bavaria, 83684, Germany
way/474354544

Wobei letzteres wohl eher wegen 'ref' = '1' gefunden wird und weil's nicht weit von Leeberg ist. 'ref' müsste hier sowieso als 'local_ref' getagged werden.

Sorry, sehe gerade, dass der Ortsteil ja "Leeberg" heißt.

Dann wäre dann place=vilage (nicht =hamlet, da zu groß) und addr:place=Leeberg