Auch JOSM hat seine Probleme, wenn der Bus Schleifen fährt, ... ganz schlimm war es früher mit https://ptna.openstreetmap.de/relation.php?id=9949594&lang=de heute ist's besser

> Die Sinnhaftigkeit ...

Ja, aber es mach es einfacher beim Auswerten der Relation (role)=*, wenn man die member nicht auch noch runter laden muss und deren Tags (public_transport=*, ...) analysieren muss.

Hi santon,

da gibt es leider noch viel zu tun und 'iD' ist nicht gut geeignet um die Probleme zu lösen.

https://ptna.openstreetmap.de/results/DE/BY/DE-BY-MVV-Analysis.html#bus_463

https://ptna.openstreetmap.de/gtfs/compare-routes.php?feed=DE-BY-MVV&release_date=&route_id=mvv-19-463-1&relation=324990

Ich habe leider nicht viel Zeit, hier zu helfen.

Gruß,
Toni

Hi,

das neue Feature "Inject GTFS data into relation using JOSM" dürfte dir hierbei die Arbeit werleichtern

https://community.openstreetmap.org/t/ptna-news-for-public-transport-network-analysis/8383/225

Gruß
Toni

Sorry: https://community.openstreetmap.org/t/ptna-news-for-public-transport-network-analysis/8383/225

Hi Marco,

das neue Feature "Inject GTFS data into relation using JOSM" dürfte dir hierbei die Arbeit werleichtern

https://community.openstreetmap.org/t/ptna-news-for-public-transport-network-analysis/8383/224

Gruß
Toni

Oops! Die Straße heißt "Hohenbrunner Straße"

Kleinste Hausnummer ist tatsächlich "17"

Hmm, im Prinzip:

- einzelne Nodes, wenn mehrere Objekte (shop, office, ...) im Gebäude sind (addr:* Info gerne an jedem Objekt + Gebäude, selbst wenn identisch)

- einzelner Node, wenn im Gebäude ein einzelnes Objekt ist, aber weitere Nutzer (ohne weitere Angaben) im Gebäude sind (z.B. unten Supermarkt, darüber Wohnungen)

- Objektinformationen am Gebäude, wenn der shop, das office, ... der alleinige Nutzer der Gebäudes ist (+ addr:* Info)

- nodes mit entrance=main/yes/exit/delivery/emergency dort wo es Ein-/Ausgänge gibt

Gruß
Toni

Hi, mal neugierig gefragt: warum nicht, wenn doch der Name "halle" enthält?

Gruß
Toni

Nach dem sogenannten public_transport:version=2 Schema (PTv2 = osm.wiki/w/index.php?title=Proposed_features/Public_Transport&oldid=625726 ) wird für jede Richtung und Variante eine eigene Route-Relation erzeugt, bei der die stop, platform, stop, platform, ... way, way, ...in ihrer Reihenfolge erfasst werden. Damit ist dann klar, welche Haltestellen in welcher Reihenfolge angefahren werden und welche Straßen benutzt werden. Beispiel Bus 463 https://ptna.openstreetmap.de/results/DE/BY/DE-BY-MVV-Analysis.html#bus_463

Gerne,

ich überlege gerade, ob ich in PTNA noch eine "Entfernungskontrolle" von "stop_position" und zugehöriger "platform" einbauen soll ("Achtung!" wenn, bei Bus, größer 20 Meter?).

Wobei nicht immer einfach zu ermitteln ist, ob eine "platform" zu einer "stop_position" gehört, wenn 'name' bei einem der beiden fehlt, oder die "stop_position" garnicht gemapped ist (gibt's bei vielen Route-Relationen).

Viele Grüße
Toni

https://ptna.openstreetmap.de/

Ähm, eher zwischen Schlierseer-/Eintrachtstraße im Westen und Balanstraße im Osten.

Servus Marco,

es gibt einen Update der GTFS-Daten vom MVV, den ich gerade aufbereitet habe.

Viele Grüße
Toni

Yeah, I completely agree. Let's let PTNA stop complaining.

Hello,

You've changed here the 'network' tag, I don't want to judge that.

I just want to ask whether I should change PTNA https://ptna.openstreetmap.de so that it does not complain about 'network' != 'PID' ?

Example https://ptna.openstreetmap.de/results/CZ/10/CZ-10-PID-Analysis.html#train_S4

'network' = 'Pražská integrovaná doprava' should be short form

This is just a configuration option for CZ-10-PID inside PTNA and I actually don't know why this option is enabled.

Regards
Toni

Thanks! My bad.

Ähm: Putzbrunn, ...

Servus Manuel,

bei der Umstellung von PTNA (Overpass -> Planet Extrakt) ist hier

https://ptna.openstreetmap.de/results/DE/RP/DE-RP-VRM-Analysis.html#bus_645 aufgefallen, dass in der Relation für den 645er eine public_transport=stop_area als member eingetragen ist. Das ist bei PTv2 nicht korrekt.

Ich werden bezüglich der fehlenden Daten in PTNA nichts weiter unternehmen, die Meldung beruht auf falschem Mapping.

Viele Grüße
Toni

Servus wyk,

ein kurzer Hinweis zu gtfs:ref_trips:VGN

'ref_trips' gibt es bei GTFS nicht.

'ref_trips' ist ein 'key', das vor GTFS in OSM definiert wurde im route-relationen zu identifizieren: z.B.

- ref_trips="031"

wenn die route-relation der Linie (Spalte) '031' im Aushang-/PDF-Fahrplan der Linie entspricht.

- ref_trips="Mo-Fr 07:23; SH off"

wenn die route-relation dem Schulbus um 07:23 entspricht.

'ref_trips' ist also nicht unbedingt notwendig, wenn man GTFS-Daten hat.

Viele Grüße
Toni

Servus wyk,

ein kurzer Hinweis zu gtfs:route_id:*=

PTNA unterstützt das derzeit noch nicht, d.h. unterstützt derzeit z.B. nur

- gtfs:feed=DE-BY-VGN

- gtfs:route_id=xxx

- gtfs:trip_id:sample=yyy

- ...

Das ist keine große Einschränkung, denn der Hauptverantwortliche für eine Buslinie kann nur ein einzelner Verkehrsverbund sein.

Was mit dem GTFS-Taggingvorschlag osm.wiki/GTFS definiert wurde sieht etwas anders aus als du es hier verwendest. Korrekte Alternative (noch nicht unterstützt) wäre

- gtfs:route_id:DE-BY-VGN=xxx

- gtfs_trip_id:sample:DE-BY-VGN=yyy

- und so weiter

ohne Angabe von gtfe:feed= und gtfs:feed:*=

N.B.: gtfs:stop_id:DE-BY-VGN=zzz wird beim Vergleich GTFS vs OSM aber unterstützt, das betrifft aber nur Haltestellen: diese können ja von mehreren Verkehrsverbünden angefahren werden.

Viele Grüße
Toni