You are not logged in.

#1 2020-05-05 23:21:03

ToniE
Member
From: Ottobrunn, Bayern, Germany
Registered: 2016-06-13
Posts: 412

PTNA - News: ÖPNV-Analyse

Ankündigung

Aus dem Thread "PTNA - News: GTFS-Analyse", Betrag #154 und #155 https://forum.openstreetmap.org/viewtop … 30#p785530


Das habe ich als Anregung genommen, eine neue Prüfung in PTNA einzubauen.

Ein Fahrzeug in einer PTv2 Relation (route=X) kann nur bestimmte Wegtypen benutzen ...

* bus, trolleybus, share_taxi, coach

** highway = motorway, motorway_link, trunk, trunk_link, primary, primary_link, secondary, secondary_link, tertiary, tertiary_link, unclassified, residential, service, track, footway, cycleway, path, pedestrian, living_street, road, construction


* train, light_rail

** railway = rail, light_rail, narrow_gauge, preserved, construction


* subway

** railway = subway, light_rail, tram


* tram

** railway = tram, rail, light_rail, narrow_gauge


... und so weiter ...


Das deckt schon mal so ziemlich alles ab was ich bei einem ersten Durchlauf an einigermaßen plausiblen Dingen gefunden habe.

Es kam auch railway=disused|abandoned|razed, highway=steps und anderes Schreckliches zum Vorschein.

highway=footway|cycleway|path|pedestrian|construction werden in einem anderen Schritt geprüft, ob psv=yes oder bus=yes dran hängt.


Die Meldungen sehen im Wesentlichen so aus:

* PTv2 Route: ein falscher Wegtyp wird benutzt (falscher Wert: 'highway' = 'give_way'): 'Breslauer Straße' 61580672 ( iD , JOSM )

* PTv2 Route: ein falscher Wegtyp wird benutzt (fehlender Schlüssel: 'highway'): 'Cäcilienbrücke' 22981747 ( iD , JOSM )


Was noch fehlt: akzeptieren von "Bus, der eine Fähre nimmt" - d.h. kein highway= aber route=ferry mit motor_vehicle=yes oder so ...


Gruß,
Toni


Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.

Offline

#2 2020-05-06 08:35:53

miche101
Member
Registered: 2008-12-16
Posts: 1,037

Re: PTNA - News: ÖPNV-Analyse

Tool zur Visualisierung.. wären noch toll wink

so wie z.B.:
https://osmrm.openstreetmap.de/relation.jsp?id=11029369
http://ra.osmsurround.org/analyzeMap?re … d=11029369

und eine Map.. die die Platformen.. mit einer Linie in der Reihenfolge verbindet, auf einer Karte.. wie bei der GTFS analyse. Damit lassen sich Fehler auch schnell finden smile

z.B:
https://ptna.openstreetmap.de/gtfs/DE/s … -s20-1.5.H

Gruß Miche

Offline

#3 2020-05-06 08:51:11

ToniE
Member
From: Ottobrunn, Bayern, Germany
Registered: 2016-06-13
Posts: 412

Re: PTNA - News: ÖPNV-Analyse

miche101 wrote:

Tool zur Visualisierung.. wären noch toll wink

so wie z.B.:
https://osmrm.openstreetmap.de/relation.jsp?id=11029369
http://ra.osmsurround.org/analyzeMap?re … d=11029369

und eine Map.. die die Platformen.. mit einer Linie in der Reihenfolge verbindet, auf einer Karte.. wie bei der GTFS analyse. Damit lassen sich Fehler auch schnell finden smile

z.B:
https://ptna.openstreetmap.de/gtfs/DE/s … -s20-1.5.H

Gruß Miche

Hey, gute Idee!

Vor allem das mit den "Platformen" und "Reihenfolge" und ... ist gut und ein wenig "tricky" wenn Platformen 'way' oder 'relation' sind (lat/lon herausfinden).

Lässt sich alles in der Spalte "Relation (=id)" unterbringen.


Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.

Offline

#4 2020-05-06 09:08:48

flohoff
Member
Registered: 2018-08-09
Posts: 116
Website

Re: PTNA - News: ÖPNV-Analyse

ToniE wrote:

Ankündigung

Aus dem Thread "PTNA - News: GTFS-Analyse", Betrag #154 und #155 https://forum.openstreetmap.org/viewtop … 30#p785530


Das habe ich als Anregung genommen, eine neue Prüfung in PTNA einzubauen.

Ein Fahrzeug in einer PTv2 Relation (route=X) kann nur bestimmte Wegtypen benutzen ...

* bus, trolleybus, share_taxi, coach

** highway = motorway, motorway_link, trunk, trunk_link, primary, primary_link, secondary, secondary_link, tertiary, tertiary_link, unclassified, residential, service, track, footway, cycleway, path, pedestrian, living_street, road, construction

Moin,
also track, footway, cycleway und path würde ich ja mal als seltsam ansehen. Das sind ja dinge die nicht für Motorisierte Fahrzeuge bzw keinen normalen Verkehr gedacht sind.


Auch living_street sehe ich noch einigermaßen kritisch. living_street ist für den ruhenden Verkehr nach StVO. D.h. eine Busroute da durch halte ich für äusserst Fragwürdig. Ich weiss das es das in ganz komischen fällen wirklich gibt aber IMHO ist das dann ein Fehler der Straßenverkehrsbehörde die diesen Abschnitt nicht hätte Verkehrsberuhigt erklären dürfen.

Flo

Offline

#5 2020-05-06 10:08:35

PHerison
Member
From: Rhein-Main
Registered: 2008-04-04
Posts: 1,574

Re: PTNA - News: ÖPNV-Analyse

Bei uns fährt der Bus sogar auf dem Fussweg: https://www.openstreetmap.org/way/23128083 big_smile

Offline

#6 2020-05-06 10:15:34

ToniE
Member
From: Ottobrunn, Bayern, Germany
Registered: 2016-06-13
Posts: 412

Re: PTNA - News: ÖPNV-Analyse

flohoff wrote:
ToniE wrote:

Ankündigung

Aus dem Thread "PTNA - News: GTFS-Analyse", Betrag #154 und #155 https://forum.openstreetmap.org/viewtop … 30#p785530


Das habe ich als Anregung genommen, eine neue Prüfung in PTNA einzubauen.

Ein Fahrzeug in einer PTv2 Relation (route=X) kann nur bestimmte Wegtypen benutzen ...

* bus, trolleybus, share_taxi, coach

** highway = motorway, motorway_link, trunk, trunk_link, primary, primary_link, secondary, secondary_link, tertiary, tertiary_link, unclassified, residential, service, track, footway, cycleway, path, pedestrian, living_street, road, construction

Moin,
also track, footway, cycleway und path würde ich ja mal als seltsam ansehen. Das sind ja dinge die nicht für Motorisierte Fahrzeuge bzw keinen normalen Verkehr gedacht sind.


Auch living_street sehe ich noch einigermaßen kritisch. living_street ist für den ruhenden Verkehr nach StVO. D.h. eine Busroute da durch halte ich für äusserst Fragwürdig. Ich weiss das es das in ganz komischen fällen wirklich gibt aber IMHO ist das dann ein Fehler der Straßenverkehrsbehörde die diesen Abschnitt nicht hätte Verkehrsberuhigt erklären dürfen.

Flo

Moin,

ich stimme dir zu.

Diese neue Prüfung behandelt an dieser Stelle zunächst nur den technischen Aspekt - ist der Wegtyp prinzipiell geeignet.

Eine andere, ältere Prüfung behandelt den "rechtlichen" oder "sinnhaften" Aspekt. D.h. an einem 'pedestrian' , 'footway', 'cycleway', 'path' oder 'construction' oder wenn 'access' / 'motor_vehicle' / ... = 'private' / 'no', ...: dann muss zusätzlich ein 'psv = 'yes' oder 'bus' / 'taxi' / 'share_taxi' / ... = 'yes' oder so dranhängen.
So wie es die Schilder in Realität dann auch freigeben würden.

'living_street' ist so eine Sache: in OSM schließt das keinerlei motorisierten Verkehr aus - allenfalls 'hgv'?

Gruß
Toni


Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.

Offline

#7 2020-05-06 15:07:15

Lukas458
Member
From: Wuppertal
Registered: 2017-05-01
Posts: 399

Re: PTNA - News: ÖPNV-Analyse

Ja, living_streets sind seltene Fälle, aber gerade beim share_taxi können die schon vorkommen. Wirklich befahren werden sie dann aber selbst mit dem wohl sehr selten, da deren Route beim "AnrufSammelTaxi" ja immer nur an das "on-demand" angepasst ist.

Auf der anderen Seite wird in die "living_street" in Deutschland (gerade NRW) mittlerweile ja alles Mögliche reingepackt, nur um Verkehrberuhigungen zu "propagieren". In Neubaugebieten ist oft alles living_street, auch die hineinführenden Straßen (auf denen dann eh 30 gefahren wird), damit man keinen Bürgersteig bezahlen muss. Hier gibt es 40 m living_street auf der Hauptverkehrsstraße: https://www.openstreetmap.org/way/683503425/


Viele Grüße!

Offline

#8 2020-05-07 09:41:05

ToniE
Member
From: Ottobrunn, Bayern, Germany
Registered: 2016-06-13
Posts: 412

Re: PTNA - News: ÖPNV-Analyse

Update:

Ein Fahrzeug in einer PTv2 Relation (route=X) kann nur bestimmte Wegtypen benutzen ...

Die im ersten Beitrag beschriebenen Änderungen sind aktiv und werden in der nächsten Nacht das erste Mal angewandt.

Die genaue Belegung, d.h. welches Fahrzeug darf welche Wege benutzen ist unten im Code-Fenster zu sehen (zu aufwändig, das alles anders darzustellen).

Das sieht für 'train', 'subway' und 'tram' noch ein wenig wild aus. Aber diese Kombinationen habe ich massenhaft gefunden. Später mal kann man das gegebenenfalls strenger auswerten, bei Bedarf.

"Bus, der eine Fähre nimmt" ist auch gelöst.

Gruß,
Toni

my %transport_type_uses_way_type = ( 'train'     => { 'railway'   => [ 'rail',   'light_rail', 'tram', 'narrow_gauge', 'preserved',  'construction' ] },
                                     'subway'    => { 'railway'   => [ 'subway', 'light_rail', 'tram' ] },
                                     'tram'      => { 'railway'   => [ 'tram',   'rail',       'light_rail', 'narrow_gauge', 'subway' ] },
                                     'monorail'  => { 'railway'   => [ 'monorail'  ] },
                                     'funicular' => { 'railway'   => [ 'funicular' ] },
                                     'ferry'     => { 'route'     => [ 'ferry'     ] },
                                     'aerialway' => { 'aerialway' => [ 'cable_car',     'gondola',        'mixed_lift',   'chair_lift' ] },
                                     'bus'       => { 'highway'   => [ 'motorway',      'motorway_link',  'trunk',        'trunk_link',    'primary',      'primary_link',
                                                                       'secondary',     'secondary_link', 'tertiary',     'tertiary_link', 'unclassified', 'residential',
                                                                       'service',       'track',          'footway',      'cycleway',      'path',         'pedestrian',
                                                                       'living_street', 'road',           'bus_guideway', 'construction'
                                                                     ]
                                                    },
                                   );
   $transport_type_uses_way_type{'coach'}       = $transport_type_uses_way_type{'bus'};
   $transport_type_uses_way_type{'share_taxi'}  = $transport_type_uses_way_type{'bus'};
   $transport_type_uses_way_type{'trolleybus'}  = $transport_type_uses_way_type{'bus'};
   $transport_type_uses_way_type{'light_rail'}  = $transport_type_uses_way_type{'train'};

Last edited by ToniE (2020-05-07 09:44:05)


Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.

Offline

#9 2020-05-07 16:46:43

axelr
Member
Registered: 2014-03-18
Posts: 243

Re: PTNA - News: ÖPNV-Analyse

ToniE wrote:
miche101 wrote:

Tool zur Visualisierung.. wären noch toll wink

so wie z.B.:
https://osmrm.openstreetmap.de/relation.jsp?id=11029369
http://ra.osmsurround.org/analyzeMap?re … d=11029369

und eine Map.. die die Platformen.. mit einer Linie in der Reihenfolge verbindet, auf einer Karte.. wie bei der GTFS analyse. Damit lassen sich Fehler auch schnell finden smile

z.B:
https://ptna.openstreetmap.de/gtfs/DE/s … -s20-1.5.H

Gruß Miche

Hey, gute Idee!

Vor allem das mit den "Platformen" und "Reihenfolge" und ... ist gut und ein wenig "tricky" wenn Platformen 'way' oder 'relation' sind (lat/lon herausfinden).

Lässt sich alles in der Spalte "Relation (=id)" unterbringen.

Das Problem ist lösbar http://www.roeltgen.com/gpx/ibro_ol4ptu … 4,11029369
Ich würde nicht die geometrische Mitte der Platform sondern den Übergabepunkt als Referenzpunkt der Haltestelle nehmen. Von der stop_position rechtwinklig auf den platform-way. (Bei mir mit rotem Punkt markiert)

Bei den 15 Varianten von Bus 501 wird das aber etwas unübersichtlich http://www.roeltgen.com/gpx/ibro_ol4ptu … dt=4582153 wenn man hier noch die gtfs mit einblendet.

Offline

#10 2020-05-07 19:10:45

ToniE
Member
From: Ottobrunn, Bayern, Germany
Registered: 2016-06-13
Posts: 412

Re: PTNA - News: ÖPNV-Analyse

axelr wrote:
ToniE wrote:
miche101 wrote:

Tool zur Visualisierung.. wären noch toll wink

so wie z.B.:
https://osmrm.openstreetmap.de/relation.jsp?id=11029369
http://ra.osmsurround.org/analyzeMap?re … d=11029369

und eine Map.. die die Platformen.. mit einer Linie in der Reihenfolge verbindet, auf einer Karte.. wie bei der GTFS analyse. Damit lassen sich Fehler auch schnell finden smile

z.B:
https://ptna.openstreetmap.de/gtfs/DE/s … -s20-1.5.H

Gruß Miche

Hey, gute Idee!

Vor allem das mit den "Platformen" und "Reihenfolge" und ... ist gut und ein wenig "tricky" wenn Platformen 'way' oder 'relation' sind (lat/lon herausfinden).

Lässt sich alles in der Spalte "Relation (=id)" unterbringen.

Das Problem ist lösbar http://www.roeltgen.com/gpx/ibro_ol4ptu … 4,11029369
Ich würde nicht die geometrische Mitte der Platform sondern den Übergabepunkt als Referenzpunkt der Haltestelle nehmen. Von der stop_position rechtwinklig auf den platform-way. (Bei mir mit rotem Punkt markiert)

Bei den 15 Varianten von Bus 501 wird das aber etwas unübersichtlich http://www.roeltgen.com/gpx/ibro_ol4ptu … dt=4582153 wenn man hier noch die gtfs mit einblendet.

Danke Axel,

das mit der geometrischen Mitte ist eigentlich nicht so wichtig. Wenn es vornehmlich darum geht, zu beurteilen, ob die Haltestellen in einer "augenscheinlich" richtigen Reihenfolge sind, reicht irgendein Punkt des ways, der relation aus- auch weil ich in PTNA mit lat/lon derzeit überhaupt nicht arbeite und eine stop_position in der Nähe evtl. nicht existiert..

Zum Beispiel: http://www.roeltgen.com/gpx/ibro_ol4ptu … dt=7603199

Wenn man hier die Haltestellen gemäß ihrer Reihenfolge in der Relation nummerieren würde, könnte man recht schnell sehen, ob da was nicht stimmt.

Z.B. ist die selbe Linie https://ptna.openstreetmap.de/gtfs/DE/s … -s20-1.9.H gemäß GTFS völliger Blödsinn - es ist ein Ruftaxi mit flexibler Route (on-demand).

Zumindest hatte ich Miche so verstanden.

Gruß
Toni


Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.

Offline

#11 2020-05-07 20:01:54

axelr
Member
Registered: 2014-03-18
Posts: 243

Re: PTNA - News: ÖPNV-Analyse

ToniE wrote:
axelr wrote:
ToniE wrote:

Hey, gute Idee!

Vor allem das mit den "Platformen" und "Reihenfolge" und ... ist gut und ein wenig "tricky" wenn Platformen 'way' oder 'relation' sind (lat/lon herausfinden).

Lässt sich alles in der Spalte "Relation (=id)" unterbringen.

Das Problem ist lösbar http://www.roeltgen.com/gpx/ibro_ol4ptu … 4,11029369
Ich würde nicht die geometrische Mitte der Platform sondern den Übergabepunkt als Referenzpunkt der Haltestelle nehmen. Von der stop_position rechtwinklig auf den platform-way. (Bei mir mit rotem Punkt markiert)

Bei den 15 Varianten von Bus 501 wird das aber etwas unübersichtlich http://www.roeltgen.com/gpx/ibro_ol4ptu … dt=4582153 wenn man hier noch die gtfs mit einblendet.

Danke Axel,

das mit der geometrischen Mitte ist eigentlich nicht so wichtig. Wenn es vornehmlich darum geht, zu beurteilen, ob die Haltestellen in einer "augenscheinlich" richtigen Reihenfolge sind, reicht irgendein Punkt des ways, der relation aus- auch weil ich in PTNA mit lat/lon derzeit überhaupt nicht arbeite und eine stop_position in der Nähe evtl. nicht existiert..

Zum Beispiel: http://www.roeltgen.com/gpx/ibro_ol4ptu … dt=7603199

Wenn man hier die Haltestellen gemäß ihrer Reihenfolge in der Relation nummerieren würde, könnte man recht schnell sehen, ob da was nicht stimmt.

Z.B. ist die selbe Linie https://ptna.openstreetmap.de/gtfs/DE/s … -s20-1.9.H gemäß GTFS völliger Blödsinn - es ist ein Ruftaxi mit flexibler Route (on-demand).

Zumindest hatte ich Miche so verstanden.

Gruß
Toni

Wenn du ids= statt idt=  nimmst steht die Haltestellenabfolge unter der Karte (Glühbirne anclicken).
http://www.roeltgen.com/gpx/ibro_ol4ptu … ds=7603199

Ich hatte bisher darauf verzichtet die Haltestellennummern in der Karte aufzuführen, da dies bei wenigen Varianten unübersichtlich wird. Ein kleiner Pfeil für Folgehaltestelle ist in dieser Richtung scheint mir praktikabler zu sein.

Zu deinem Beispiel: Bei AST-Routen ist es einfacher nur einen Hauptweg in der Mitte vollständig aufzunehmen und die abgelegenen Haltestellen nur als Platform aufzuführen.

Offline

#12 2020-05-07 21:29:43

ToniE
Member
From: Ottobrunn, Bayern, Germany
Registered: 2016-06-13
Posts: 412

Re: PTNA - News: ÖPNV-Analyse

axelr wrote:
ToniE wrote:
axelr wrote:

Das Problem ist lösbar http://www.roeltgen.com/gpx/ibro_ol4ptu … 4,11029369
Ich würde nicht die geometrische Mitte der Platform sondern den Übergabepunkt als Referenzpunkt der Haltestelle nehmen. Von der stop_position rechtwinklig auf den platform-way. (Bei mir mit rotem Punkt markiert)

Bei den 15 Varianten von Bus 501 wird das aber etwas unübersichtlich http://www.roeltgen.com/gpx/ibro_ol4ptu … dt=4582153 wenn man hier noch die gtfs mit einblendet.

Danke Axel,

das mit der geometrischen Mitte ist eigentlich nicht so wichtig. Wenn es vornehmlich darum geht, zu beurteilen, ob die Haltestellen in einer "augenscheinlich" richtigen Reihenfolge sind, reicht irgendein Punkt des ways, der relation aus- auch weil ich in PTNA mit lat/lon derzeit überhaupt nicht arbeite und eine stop_position in der Nähe evtl. nicht existiert..

Zum Beispiel: http://www.roeltgen.com/gpx/ibro_ol4ptu … dt=7603199

Wenn man hier die Haltestellen gemäß ihrer Reihenfolge in der Relation nummerieren würde, könnte man recht schnell sehen, ob da was nicht stimmt.

Z.B. ist die selbe Linie https://ptna.openstreetmap.de/gtfs/DE/s … -s20-1.9.H gemäß GTFS völliger Blödsinn - es ist ein Ruftaxi mit flexibler Route (on-demand).

Zumindest hatte ich Miche so verstanden.

Gruß
Toni

Wenn du ids= statt idt=  nimmst steht die Haltestellenabfolge unter der Karte (Glühbirne anclicken).
http://www.roeltgen.com/gpx/ibro_ol4ptu … ds=7603199

Ich hatte bisher darauf verzichtet die Haltestellennummern in der Karte aufzuführen, da dies bei wenigen Varianten unübersichtlich wird. Ein kleiner Pfeil für Folgehaltestelle ist in dieser Richtung scheint mir praktikabler zu sein.

Im Gegensatz zu den anderen Darstellungen wollte ich hier ausschließlich die lat/lon der Platforms in der Reihenfolge der Relation darstellen mit Luftlinienverbindung - und nicht die Ways berücksichigen? ...

Oder doch? Die Relation mit Ways darstellen und in anderer Farbe die Luftlinienverbindung zwischen den Platforms.
Wäre es dann möglich, mit den Augen, irgendwelche Abweichungen wahrzunehmen?

@Miche: kommt das deinem Vorschlag am nächsten?


Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.

Offline

#13 2020-05-08 08:11:55

miche101
Member
Registered: 2008-12-16
Posts: 1,037

Re: PTNA - News: ÖPNV-Analyse

ToniE wrote:

wollte ich hier ausschließlich die lat/lon der Platforms in der Reihenfolge der Relation darstellen mit Luftlinienverbindung

Ja das mein ich... ob man die Ways zusätzlich in einer anderen Fahre (eventuell als eigenen Layer) auch noch darstellen kann ist mir einerlei..

Offline

#14 2020-05-08 09:01:20

ToniE
Member
From: Ottobrunn, Bayern, Germany
Registered: 2016-06-13
Posts: 412

Re: PTNA - News: ÖPNV-Analyse

miche101 wrote:
ToniE wrote:

wollte ich hier ausschließlich die lat/lon der Platforms in der Reihenfolge der Relation darstellen mit Luftlinienverbindung

Ja das mein ich... ob man die Ways zusätzlich in einer anderen Fahre (eventuell als eigenen Layer) auch noch darstellen kann ist mir einerlei..

OK, bin noch am überlegen wie ich das am günstigsten hinbekomme:

Button, der JavaScript startet, neues Fenster mit Karte, der Einfachheit halber der JavaScript-Funktion die lat/lon der Platforms als JSON mitgegeben: die Infos habe ich eh schon, und JavaScript muss sich die Infos nicht nochmals per Overpass oder OSP-API besorgen, berechnen, ausfiltern, ...

Schauen wir mal, das muss im Kopf noch reifen ... macht aber nur bei PTv2-Relationen wirklich Sinn.


Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.

Offline

#15 2020-05-08 10:04:18

miche101
Member
Registered: 2008-12-16
Posts: 1,037

Re: PTNA - News: ÖPNV-Analyse

ToniE wrote:

Button, der JavaScript startet,

kannst dir hier abschauen: (von mir wink )
https://greymiche.lima-city.de/bus-rela … n=10981156

Offline

#16 2020-05-08 10:04:40

axelr
Member
Registered: 2014-03-18
Posts: 243

Re: PTNA - News: ÖPNV-Analyse

Klar, alle Daten müssen aus dem ptna-Bestand kommen.

Ich hab mal eine Vergleichsseite mit bestehenden Möglichkeiten hingehuddelt
http://www.roeltgen.com/gpx/ibro_ol4ptg … ids=919808
Bus N47 (VRS) gpx(gtfs) heruntergeladen und festverdrahtet.
Eine derartige Darstellung (mit später mal nummerierten Haltestellen) wäre brauchbar.
Man erkennt die vergessene Haltestelle und die abweichenden EFA-Koordinaten.

Die Handhabung von 15 Varianten wird aber ein Problem bleiben.
Nach meiner Meinung müssen wir aus gtfs per Majoritätswertung eine Variante als Nennlinie ausmachen und Teilrouten-Varianten ausschließen.

Und natürlich nicht blauäugig ans Mappen gehen, denn
- die Koordinaten in osm sind meist besser als in gtfs oder eva und
- die Routen in gtfs haben auch Fehler.

Offline

#17 2020-05-08 10:52:14

ToniE
Member
From: Ottobrunn, Bayern, Germany
Registered: 2016-06-13
Posts: 412

Re: PTNA - News: ÖPNV-Analyse

axelr wrote:

kannst dir hier abschauen: (von mir wink )
https://greymiche.lima-city.de/bus-rela … n=10981156

Genau so und die Reihenfolgenummer der Haltestelle sichtbar: dann kann man grobe Fehler in der Reihenfolge sofort sehen.

axelr wrote:

Ich hab mal eine Vergleichsseite mit bestehenden Möglichkeiten hingehuddelt
http://www.roeltgen.com/gpx/ibro_ol4ptg … ids=919808
Bus N47 (VRS) gpx(gtfs) heruntergeladen und festverdrahtet.
Eine derartige Darstellung (mit später mal nummerierten Haltestellen) wäre brauchbar.

Diese Darstellung wäre optimal, setzt aber GTFS-Daten voraus, und dass ich zur OSM-Relation eine passende Trip-ID gefunden habe - das tag; "gtfs:trip_id=..." in der Relation hilft hier smile

Aber auch ohne GTFS als SOLL-Vorgabe und mit Nummerierung der Haltestellen und die rote dicke Linie auf Basis der lat/lon der OSM-Platforms in der gegebenen Reihenfolge ... würde grobe Fehler sichtbar machen.

Und selbst ohne die rote Linie:

http://www.roeltgen.com/gpx/ibro_ol4ptg … ds=9041933

Hier fehlt im Westen "Dachau (S)" als Haltestelle, das weiß ich.
Oder aber die Frühlingstraße ist die erste Haltestelle und die Ways von Dacheu (S) bis Frühlingstraße davor sind überflüssig (was auch ein Fehler wäre).

Aber beide Ansätze gehen in die richtige Richtung.
Ich hatte auch schon überlegt, brouter mit den Positionen der Platforms zu füttern (kein eigenes JavaScript, ... keine eigene Page, ...) aber irgendwie sollten die OSM-Ways der Relation drunter liegen.

Was mir mittelfristig vorschwebt: die PTNA-Analyse bekommt beim Aufruf die Lage der SQLite-DB (die der GTFS-Analyse) mitgeteilt und kann versuchen eine Routen-Variante (Relation-ID) mit einer Trip-ID zu vergleichen: hinsichtlich Haltestellen-Position, -Name, -Reihenfolge, ... bis hin zu "shapes" (sofern vorhanden).
Aber zu einer Relations-ID eine passende Trip-ID zu finden dürfte nicht einfach sein ... ohne false-positive oder false-negative Match. ...: "gtfs:trip_id=..." in der Relation würde etwas helfen.

Last edited by ToniE (2020-05-08 10:53:18)


Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.

Offline

#18 2020-05-13 21:07:47

ToniE
Member
From: Ottobrunn, Bayern, Germany
Registered: 2016-06-13
Posts: 412

Re: PTNA - News: ÖPNV-Analyse

ToniE wrote:
axelr wrote:

kannst dir hier abschauen: (von mir wink )
https://greymiche.lima-city.de/bus-rela … n=10981156

Genau so und die Reihenfolgenummer der Haltestelle sichtbar: dann kann man grobe Fehler in der Reihenfolge sofort sehen.

axelr wrote:

Ich hab mal eine Vergleichsseite mit bestehenden Möglichkeiten hingehuddelt
http://www.roeltgen.com/gpx/ibro_ol4ptg … ids=919808
Bus N47 (VRS) gpx(gtfs) heruntergeladen und festverdrahtet.
Eine derartige Darstellung (mit später mal nummerierten Haltestellen) wäre brauchbar.

Diese Darstellung wäre optimal, setzt aber GTFS-Daten voraus, und dass ich zur OSM-Relation eine passende Trip-ID gefunden habe - das tag; "gtfs:trip_id=..." in der Relation hilft hier smile

Aber auch ohne GTFS als SOLL-Vorgabe und mit Nummerierung der Haltestellen und die rote dicke Linie auf Basis der lat/lon der OSM-Platforms in der gegebenen Reihenfolge ... würde grobe Fehler sichtbar machen.

Und selbst ohne die rote Linie:

http://www.roeltgen.com/gpx/ibro_ol4ptg … ds=9041933

Hier fehlt im Westen "Dachau (S)" als Haltestelle, das weiß ich.
Oder aber die Frühlingstraße ist die erste Haltestelle und die Ways von Dacheu (S) bis Frühlingstraße davor sind überflüssig (was auch ein Fehler wäre).

Aber beide Ansätze gehen in die richtige Richtung.
Ich hatte auch schon überlegt, brouter mit den Positionen der Platforms zu füttern (kein eigenes JavaScript, ... keine eigene Page, ...) aber irgendwie sollten die OSM-Ways der Relation drunter liegen.

So, für die Anzeige ist schon mal ein erster Versuch verfügbar.

Nicht komplett:
* Platform als MP-Relation werden noch nicht dargestellt (so wie bei osm.org auch nicht), sie müssen 'nachgeladen' werden
* Stop-Positionen sollen noch als gelbe Marker kommen
* zwischen Platforms und auch zw. Stops noch jeweils eine Luftline
* das alles über Layer ein- und ausblendbar
* in der PTNA-Analyse noch nicht verlinkt

https://ptna.openstreetmap.de/relation.php?id=1549762

Gruß
Toni

Last edited by ToniE (2020-05-13 21:47:57)


Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.

Offline

#19 2020-05-14 12:35:20

ToniE
Member
From: Ottobrunn, Bayern, Germany
Registered: 2016-06-13
Posts: 412

Re: PTNA - News: ÖPNV-Analyse

ToniE wrote:
ToniE wrote:
axelr wrote:

kannst dir hier abschauen: (von mir wink )
https://greymiche.lima-city.de/bus-rela … n=10981156

Genau so und die Reihenfolgenummer der Haltestelle sichtbar: dann kann man grobe Fehler in der Reihenfolge sofort sehen.

axelr wrote:

Ich hab mal eine Vergleichsseite mit bestehenden Möglichkeiten hingehuddelt
http://www.roeltgen.com/gpx/ibro_ol4ptg … ids=919808
Bus N47 (VRS) gpx(gtfs) heruntergeladen und festverdrahtet.
Eine derartige Darstellung (mit später mal nummerierten Haltestellen) wäre brauchbar.

Diese Darstellung wäre optimal, setzt aber GTFS-Daten voraus, und dass ich zur OSM-Relation eine passende Trip-ID gefunden habe - das tag; "gtfs:trip_id=..." in der Relation hilft hier smile

Aber auch ohne GTFS als SOLL-Vorgabe und mit Nummerierung der Haltestellen und die rote dicke Linie auf Basis der lat/lon der OSM-Platforms in der gegebenen Reihenfolge ... würde grobe Fehler sichtbar machen.

Und selbst ohne die rote Linie:

http://www.roeltgen.com/gpx/ibro_ol4ptg … ds=9041933

Hier fehlt im Westen "Dachau (S)" als Haltestelle, das weiß ich.
Oder aber die Frühlingstraße ist die erste Haltestelle und die Ways von Dacheu (S) bis Frühlingstraße davor sind überflüssig (was auch ein Fehler wäre).

Aber beide Ansätze gehen in die richtige Richtung.
Ich hatte auch schon überlegt, brouter mit den Positionen der Platforms zu füttern (kein eigenes JavaScript, ... keine eigene Page, ...) aber irgendwie sollten die OSM-Ways der Relation drunter liegen.

So, für die Anzeige ist schon mal ein erster Versuch verfügbar.

Nicht komplett:
* Platform als MP-Relation werden noch nicht dargestellt (so wie bei osm.org auch nicht), sie müssen 'nachgeladen' werden
* Stop-Positionen sollen noch als gelbe Marker kommen
* zwischen Platforms und auch zw. Stops noch jeweils eine Luftline
* das alles über Layer ein- und ausblendbar
* in der PTNA-Analyse noch nicht verlinkt

https://ptna.openstreetmap.de/relation.php?id=1549762

Gruß
Toni

Ein gutes Stück weiter gekommen ...

In der PTNA MVV Analyse bereits verlinkt ('PTNA' in der Spalte "Relation").

Was fehlt?

* Platform als MP-Relation werden noch nicht dargestellt (so wie bei osm.org auch nicht), sie müssen 'nachgeladen' werden
* Stop-Positionen sollen noch als gelbe Marker kommen - da bräuchte ich eine eigenes Icon
* Tooltip ist derzeit die Reihenfolgenummer innerhalb der Relation - ein onClick() kommt noch ...


Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.

Offline

#20 2020-05-14 13:28:30

miche101
Member
Registered: 2008-12-16
Posts: 1,037

Re: PTNA - News: ÖPNV-Analyse

ToniE wrote:

Ein gutes Stück weiter gekommen ...

schön schön, die  "Stop-Position Route" bräuchte ich jetzt nicht. Die Stop-Position sehe ich nur im Zusammenhang mit Routing... als hilfreich an.

Offline

#21 2020-05-14 13:42:13

ToniE
Member
From: Ottobrunn, Bayern, Germany
Registered: 2016-06-13
Posts: 412

Re: PTNA - News: ÖPNV-Analyse

miche101 wrote:
ToniE wrote:

Ein gutes Stück weiter gekommen ...

schön schön, die  "Stop-Position Route" bräuchte ich jetzt nicht. Die Stop-Position sehe ich nur im Zusammenhang mit Routing... als hilfreich an.

Ist dennoch hilfreich, wenn  z.B. bei 52 Haltestellen nur die 1. und letzte eine stop_position haben hmm

Wie hier ...


Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.

Offline

#22 2020-05-15 08:39:06

miche101
Member
Registered: 2008-12-16
Posts: 1,037

Re: PTNA - News: ÖPNV-Analyse

ToniE wrote:

Ist dennoch hilfreich, wenn  z.B. bei 52 Haltestellen nur die 1. und letzte eine stop_position haben hmm

Wie hier ...

..und für was soll das hilfreich sein? Das man allen 52 Haltestellen eine stop_position verpasst? Ich seh diese als praktisch für das Routing.. oder bei Busbahnhöfen.. aber sonst meist rein erfunden/geraten. Ich verstehe nicht wie man diese vor Ort aufnehmen kann.. in den aller meisten Fällen. Deshalb werde ich diese auch nicht fixen, wenn sie von der Lage grob abweichen ( zu großer Aufwand, komplex ). Deshalb kommt in diesem Fall nur eine Löschung in Betracht. Bei Plattformen das gleiche.. da werden Flächen oder Linie gemappt die man vor Ort so nicht aufnehmen kann..., weil die z.B. ein ordinärer Gehweg ist ohne irgendwas. Die erste und letzte nimm ich für dich auf wink

Offline

#23 2020-05-15 11:29:39

ToniE
Member
From: Ottobrunn, Bayern, Germany
Registered: 2016-06-13
Posts: 412

Re: PTNA - News: ÖPNV-Analyse

miche101 wrote:
ToniE wrote:

Ist dennoch hilfreich, wenn  z.B. bei 52 Haltestellen nur die 1. und letzte eine stop_position haben hmm

Wie hier ...

..und für was soll das hilfreich sein? Das man allen 52 Haltestellen eine stop_position verpasst? Ich seh diese als praktisch für das Routing.. oder bei Busbahnhöfen.. aber sonst meist rein erfunden/geraten. Ich verstehe nicht wie man diese vor Ort aufnehmen kann.. in den aller meisten Fällen. Deshalb werde ich diese auch nicht fixen, wenn sie von der Lage grob abweichen ( zu großer Aufwand, komplex ). Deshalb kommt in diesem Fall nur eine Löschung in Betracht. Bei Plattformen das gleiche.. da werden Flächen oder Linie gemappt die man vor Ort so nicht aufnehmen kann..., weil die z.B. ein ordinärer Gehweg ist ohne irgendwas. Die erste und letzte nimm ich für dich auf wink

... hast ja Recht.

Das PTv-irgendwas ist verkorkst. Es definiert ein großes Ziel mit Platform, (Stop-Position?), Stop-Area, Relation, ... mit dem man schon was anfangen könnte.
Auf der anderen Seite läßt es zu viele Freiräume, die, wenn man die Freiräume (konsequent) ausnutzt, eine Relation unbrauchbar zurück läßt.
Mir erschließt sich der Sinn von Stop-Positionen auch nicht so recht, d.h. ich sehen nicht wirklich einen "Abnehmer" (eine App), die diese Daten wirklich benötigt.
Zudem fehlt fast immer eine Kennzeichnung der Stop-Position auf der Straße: "gezackte Linie auf der Straße = hier darf man nicht parken" - die Position ist also, wie du schon sagtest, in der Regel "geraten".
Vermutlich hat die Stop-Position historische, rückwärts-kompatible Gründe Richtung: "highway=bus_stop" muss auf und nicht neben die Straße.

Würde mich nicht wundern, wenn eine Relation: "jede 2. Haltestelle als stop_position und jede andere 2. Haltestelle als platform gemapped" nach PTv2 immer noch "gültig" ist. Nur: ob mit so einem Mischmasch was anzufangen ist?

"Das Beste hoffen, das Schlimmste erwarten" trifft auf PTv2 wirklich zu und "das Schlimmste" findet man häufig vor.

Man muss mehr tun als nur die 'mandatory' oder 'required' Dinge zu tun. Wir hätten heute z.B. keine Smartphones und 3. / 4. / 5. Generation, wenn sich die Hersteller auf Netz- und Handy-Seite (aus Aufwandsgründen; weil man nicht weiß, ob es sich amortisiert) immer nur auf die 'mandatory' Features der Standards beschränkt hätten. Da kam immer der Druck von außen, mehr zu realisieren.

Aber, wie gesagt, bei PTv2 kann man mit den 'mandatory' Features nicht viel (nichts?) anfangen. Und welche 'optionalen' Features zum Ziel (der Brauchbarkeit) führen ist unklar, auch weil es keine Priorisierung und Use-Cases (wenn dieses gemacht wird, dann können wir das daraus machen) gibt.

Das führt, zugegebener Maßen, auf meiner Seite dazu, dass ich alles, so viel wie möglich, auch redundant (was die 'tags' angeht) mappe.

Last edited by ToniE (2020-05-15 11:31:26)


Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.

Offline

#24 2020-05-15 13:08:24

miche101
Member
Registered: 2008-12-16
Posts: 1,037

Re: PTNA - News: ÖPNV-Analyse

ToniE wrote:

"Das Beste hoffen, das Schlimmste erwarten" trifft auf PTv2 wirklich zu und "das Schlimmste" findet man häufig vor.

Ich sag mal.. ptv2 ist nicht das Ende der Reise wink Man sieht ja immer wieder wo man an die Grenzen des darstellbaren kommt, oder mit des nachhaltens.., oder oder oder neutral Und da muss man halt auch einmal was ändern.. um den Daten noch einen Nutzen entziehen zu können und nicht nur veralterte/lückenhafte/falsche Datenbestände zu haben. Ptv2 ist zu viel verlangt da gibt es zu wenig men-power zum erfassen und pflegen.. siehe MVV Bus 600er, 700er, 800er, 900er usw. Da hab ich vor 3 Jahren ganz viel gemacht.. aber seit dem ich auch nicht mehr viel passiert.. sad

Gruß Miche

Offline

#25 2020-05-18 12:21:36

ToniE
Member
From: Ottobrunn, Bayern, Germany
Registered: 2016-06-13
Posts: 412

Re: PTNA - News: ÖPNV-Analyse

Update:

miche101 wrote:

Tool zur Visualisierung.. wären noch toll wink

Aus den Anregungen und Code-Beispielen von miche101 und axelr ist was entstanden ...

Eine grafische Übersicht der Reihenfolge der Platforms und Stops auf einer Karte, mit ausblendbaren Layers ...

Beispiel: https://ptna.openstreetmap.de/relation. … 68&lang=de

Diese Analyse ist direkt aus der normalen PTNA-Analyse erreichbar ("PTNA").

Die Analyse ist hauptsächlich für ÖPNV "route" Relationen gemacht, mag bei anderen Relationen auch irgendwie funktionieren.


* Platforms (blau)
** PTv2: 'role' ist "platform" oder "platform_entry_only" oder "platform_exit_only" oder 'public_transport' = "platform"
** sonst: 'role' enthält 'platform'

* Stops (grün)
** PTv2: 'role' ist "stop" oder "stop_entry_only" oder "stop_exit_only" oder 'public_transport' = "stop_position"
** sonst: 'role' enthält 'stop'

* Ways (rot)
** PTv2: 'role' ist leer
** sonst:  'role' ist leer oder 'role' enthält "forward" oder "backward" (sofern es nicht ein "forward_stop" oder so ist)

* Others (schwarz)
** alles andere (z.b.: Ways mit 'role' "Ende")


Was fehlt (mir) noch?
* Entweder kann man innerhalb von langen (Way-)Tabellen scrollen oder die Karte wandert beim Scrollen mit.
** Scrollbare Tabellen sind nicht einfach, wenn der Inhalt mittels JavaScript gefüllt wird, oder?
* Bei Ways: am rechten Tabellenrand eine Anzeige, ob die Route Lücken hat - so wie im Relationseditor von JOSM auch.
** sofern die Geschwindigkeit des JavaScripts nicht massiv leidet.
* Beim Fahren mit der Maus über Namen von Wegen, Platforms, Stops, ... ein Hervorheben des Objektes auf der Karte?
* Ein Fortschrittsbalken, denn bei langen/großen Relationen kann's schon mal dauern ...

Weitere Ideen, Anmerkungen?

Gruß
Toni


Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.

Offline

Board footer

Powered by FluxBB