You are not logged in.

#151 2020-05-04 21:08:07

Weide
Member
Registered: 2009-04-05
Posts: 1,404

Re: PTNA - News: GTFS-Analyse

Ich halte jedes Routing der ÖPV-Verkehrsmittel für schädlich:

Wenn eine Brücke wegen irgendwelcher Probleme gesperrt wird und ein Mapper das einträgt, dann ist das völlig in Ordnung. Wenn ein Kartenprogramm dann irgendwelche Phantasierouten für Busse produziert, dann ist das nicht die Schuld des Mappers sondern der Kartensoftware. Ich werde mir solche Karten jedenfalls nicht ansehen. Was wir in so einem Fall brauchen, ist eine Fehlermeldung für die Route. Dann kann jemand ermitteln, wie der Bus jetzt wirklich fährt ... welche Haltestellen ausgelassen werden ... welche Ersatzhaltestellen eingeplant wurden ... welche anderen Routen angepasst wurden um den Bedarf zu decken.

Offline

#152 2020-05-04 21:29:17

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

Re: PTNA - News: GTFS-Analyse

Weide wrote:
miche101 wrote:

Die zweite Fehlermeldung ist eigentlich nicht richtig, weil die Stop-Positionen ist auf dem Weg wink nur der Weg fehlt komplett in der Relation.. was ja auch festgestellt wurde. Also eigentlich kann man sich die Stop-Positionen Prüfung sparen wenn "Route ohne Way(s)" festgestellt wurde smile

PTv2 verlangt, dass die stop_position auf einem für das Verkehrsmittel geeigneten Weg liegt. Ansonsten ist es ein Fehler. Wenn der Weg nicht in der Relation ist, dann ist das kein Fehler ... es ist nur verdächtig falls andere Wege da sind. Da gibt es öfter mal Fehler bei zwei Tram-Ways "auf" einem highway.

Alles klar.

* Wenn es keine Ways in der Relation gibt, dann muss nicht auch noch gemeldet werden, dass eine stop_position nicht auf den Ways liegt - das ist zwangsläufig so.
* Wenn es mindestens einen Way in der Relation gibt, so wird gemeldet, wenn eine stop_position nicht auf einem der Ways liegt.

Den letzten Halbsatz nach ... :
* die Ways sollen eine durchgehende und sortierte Strecke bilden, ohne Lücken
* der erste Way muss mit einer stop_position beginnen, das muss die erste stop_position der Relation sein
* der letzte Way muss mit einer stop_position enden, das muss die letzte stop_position der Relation sein
--> das wird momentan geprüft.
--> die Reihenfolge der stop_position in der Relation vergleichen mit der Reihenfolge, wenn man den Ways folgt: passt nicht immer, vor allem dann nicht, wenn es Schleifen gibt (Haltestelle mit selben Namen in beiden Richtungen,...).

Der letzte Satz: verstehe ich nicht ganz.

Gruß
Toni


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

Offline

#153 2020-05-04 21:53:15

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

Re: PTNA - News: GTFS-Analyse

Weide wrote:

Ich halte jedes Routing der ÖPV-Verkehrsmittel für schädlich:

Ich auch, d.h. die automatisierte Berechnung einer Route an Hand der Haltestellen um daraus eine Karte zu machen.

Weide wrote:

Wenn eine Brücke wegen irgendwelcher Probleme gesperrt wird und ein Mapper das einträgt, dann ist das völlig in Ordnung. Wenn ein Kartenprogramm dann irgendwelche Phantasierouten für Busse produziert, dann ist das nicht die Schuld des Mappers sondern der Kartensoftware. Ich werde mir solche Karten jedenfalls nicht ansehen. Was wir in so einem Fall brauchen, ist eine Fehlermeldung für die Route. Dann kann jemand ermitteln, wie der Bus jetzt wirklich fährt ... welche Haltestellen ausgelassen werden ... welche Ersatzhaltestellen eingeplant wurden ... welche anderen Routen angepasst wurden um den Bedarf zu decken.

Das geht aber nicht ohne eine "Vorgabe": d.h. ein Mapper macht eine PTv2-Relation und gibt an, wie die Route zu dem Zeitpunkt ist.

Eine Fehlermeldung beim Bau einer Brücke, ... (sofern in OSM auch gemapped) meldet PTNA derzeit, weil highway=construction oder access=no (ohne psv=yes) sind.

Eine Abweichende Routenführung eines Busses (mit Auslassen von Haltestellen) wegen Baustellen (kurz-, mittel- oder langfristig?) bekommen wir mit, wenn Mapper "am Ball bleiben" und den Verkehrsverbund "beobachten" (Pressemeldungen, Webseite des Verbundes, ...) - theoretisch (*).

GTFS mit oder ohne shapes bietet zumindest ansatzweise eine Möglichkeit OSM mit (halbwegs) aktuellen Daten der Verbünde zu vergleichen.

Die GTFS-Analysen bei PTNA sind (für mich) eine Vorbereitung dahin gehend, dass PTNA selber die Daten benutzt um sie bei der Analyse mit den OSM-Daten zu vergleichen.
Wie das optimal geht, wie weit das gehen kann, was man "rauskitzeln" kann? Ich weiß es noch nicht ... ist aber spannend.

"Was soll der ganze Aufwand?" Mmh, solange Ptv2 und das ältere noch Bestand haben und kein neueres PTv-irgenwas kommt oder ÖPNV komplett aus OSM verschwindet ist es doch OK an sowas zu arbeiten.

Toni

(*) "In der Theorie gibt es keinen Unterschied zwischen Theorie und Praxis, in der Praxis schon!" (Autor unbekannt)


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

Offline

#154 2020-05-05 06:11:22

Weide
Member
Registered: 2009-04-05
Posts: 1,404

Re: PTNA - News: GTFS-Analyse

ToniE wrote:

* Wenn es keine Ways in der Relation gibt, dann muss nicht auch noch gemeldet werden, dass eine stop_position nicht auf den Ways liegt - das ist zwangsläufig so.

Ja. Aber die stop_position muss auf einem zu den "xxx=yes"-Angaben geeigneten Way liegen ... egal ob der Weg in der Relation ist oder nicht. Natürlich gibt es keine Pflicht, dass zu melden.

ToniE wrote:

* Wenn es mindestens einen Way in der Relation gibt, so wird gemeldet, wenn eine stop_position nicht auf einem der Ways liegt.

Ja. Das ist zwar kein Fehler (Routen dürfen ja unvollständig sein) aber eine interessante Sache.

ToniE wrote:

* der erste Way muss mit einer stop_position beginnen, das muss die erste stop_position der Relation sein
* der letzte Way muss mit einer stop_position enden, das muss die letzte stop_position der Relation sein

Hmm. Wie alle anderen Haltestellen darf die erste und die letzte Haltestelle als "nur platform" oder "nur stop" oder "beides" eingetragen werden. Bei "nur Platform" ist da kein "stop" und das ist völlig OK.

ToniE wrote:

Der letzte Satz: verstehe ich nicht ganz.

Hatte ich auch schlecht formuliert. Bei Gleisen ist ja normalerweise jede Spur ein eigener Way und bei Straßen sind die Spuren in einem Way. Dadurch haben wir oft direkt nebeneinander drei Ways: einen für die Straße in der Mitte und Straßenbahngleise auf beiden Seiten direkt daneben. Der Stop der Straßenbahn (falls vorhanden) muss auf dem Gleis liegen und der Stop des Busses (falls vorhanden) auf der Straße. Beim Splitten der Wege in Straße und Gleise ist oft vergessen worden, auch die "Stops" zu splitten.

Offline

#155 2020-05-05 08:24:29

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

Re: PTNA - News: GTFS-Analyse

Weide wrote:
ToniE wrote:

* Wenn es keine Ways in der Relation gibt, dann muss nicht auch noch gemeldet werden, dass eine stop_position nicht auf den Ways liegt - das ist zwangsläufig so.

Ja. Aber die stop_position muss auf einem zu den "xxx=yes"-Angaben geeigneten Way liegen ... egal ob der Weg in der Relation ist oder nicht. Natürlich gibt es keine Pflicht, dass zu melden.

Interessant, die Prüfung ist noch nicht drin. Ein Bus kann nicht über Trambahngleise (ohne weiteres highway=) fahren und dort seine Haltestelle haben. Ein bus' braucht ein 'highway=' > path|footway|cycleway|... (es sei denn, es steht psv|bus=yes dran), eine 'tram' braucht ein 'railway=tram'

Weide wrote:
ToniE wrote:

* Wenn es mindestens einen Way in der Relation gibt, so wird gemeldet, wenn eine stop_position nicht auf einem der Ways liegt.

Ja. Das ist zwar kein Fehler (Routen dürfen ja unvollständig sein) aber eine interessante Sache.

"Dürfen", ja, sollten aber nicht, denn sonst sind sie irgendwie nutzlos. Aber: wie beurteile ich bei einer sw-technischen Prüfung, ob sie vollständig sind, alle Haltestellen hat, ...?

Weide wrote:
ToniE wrote:

* der erste Way muss mit einer stop_position beginnen, das muss die erste stop_position der Relation sein
* der letzte Way muss mit einer stop_position enden, das muss die letzte stop_position der Relation sein

Hmm. Wie alle anderen Haltestellen darf die erste und die letzte Haltestelle als "nur platform" oder "nur stop" oder "beides" eingetragen werden. Bei "nur Platform" ist da kein "stop" und das ist völlig OK.

Auch wieder wahr. Ideal wäre beides, aber wenn nur 'platform' dann müsste man suchen, ob das Ende / der Anfang der Fahrstrecke "recht nah" bei der letzten / ersten 'platform' liegt. "recht nah" == "< 20 Meter"?
IIRC, bei einer neueren Diskussion über "stop_position ist generell unnötig" wurde bzgl. 1. und letzte stop_position eine Ausnahme gemacht, was wiederum nicht konsequent zu "komplett ohne stop_position" ist - irgendwie braucht's man dann doch mal wieder?

Weide wrote:
ToniE wrote:

Der letzte Satz: verstehe ich nicht ganz.

Hatte ich auch schlecht formuliert. Bei Gleisen ist ja normalerweise jede Spur ein eigener Way und bei Straßen sind die Spuren in einem Way. Dadurch haben wir oft direkt nebeneinander drei Ways: einen für die Straße in der Mitte und Straßenbahngleise auf beiden Seiten direkt daneben. Der Stop der Straßenbahn (falls vorhanden) muss auf dem Gleis liegen und der Stop des Busses (falls vorhanden) auf der Straße. Beim Splitten der Wege in Straße und Gleise ist oft vergessen worden, auch die "Stops" zu splitten.

Verstanden, sehen wir oft in München, wo die Gleise in der Fahrbahn liegen, in OSM aber als zwei railway=tram rechts und links neben dem highway= liegen.
Das wird in PTNA erkannt, sofern bei einer Tram sowohl das "railway=" als auch die "Tram-stops auf dem railway=" in der Relation sind, für den Bus analog. Fehler würde man gemäß 1. Punkt oben heraus finden, 'tram' auf 'highway=' ohne 'railway=' und tram-stop auch auf highway.

Last edited by ToniE (2020-05-05 08:25:36)


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

Offline

#156 2020-05-05 08:58:09

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

Re: PTNA - News: GTFS-Analyse

ToniE wrote:

IIRC, bei einer neueren Diskussion über "stop_position ist generell unnötig" wurde bzgl. 1. und letzte stop_position eine Ausnahme gemacht, was wiederum nicht konsequent zu "komplett ohne stop_position" ist - irgendwie braucht's man dann doch mal wieder?

ich finde die stop-position praktisch, wenn man z.B. Routing betreibt. Weil da kann es sein das die Platform einer anderen Straße näher steht, als der in der der Bus fährt.. dann kann die stop-position die lat/lon der Platform für Routing ersetzen..

Z.B.

http://brouter.de/brouter-web/#map=19/4 … le=car-eco

wenn man stop-position die lat/lon ersetzt würde es so ausfallen smile

http://brouter.de/brouter-web/#map=19/4 … le=car-eco

cool

Last edited by miche101 (2020-05-05 09:10:06)

Offline

#157 2020-05-05 18:22:02

Weide
Member
Registered: 2009-04-05
Posts: 1,404

Re: PTNA - News: GTFS-Analyse

ToniE wrote:

Auch wieder wahr. Ideal wäre beides, aber wenn nur 'platform' dann müsste man suchen, ob das Ende / der Anfang der Fahrstrecke "recht nah" bei der letzten / ersten 'platform' liegt. "recht nah" == "< 20 Meter"?

Na ja. Es kann auch die Haltestelle fehlen und der Weg drin sein oder umgekehrt. Oder jemand mappt die Haltestelle und traut sich nicht an die Relationen. Oder ist mit dem Bus gefahren und hat Haltestellen übersehen.

Beides zu mappen finde ich garnicht ideal. Viele mit einem einzelnen Node für beide Richtungen gut gemappte Haltestellen werden jetzt zu vier Objekten plus einer zusammenfassenden stop_area-Relation ohne dem Informationsgehalt irgendwas hinzuzufügen. Das war damals ein Kompromiss, der die "bus_stop auf die Straße" - und die "bus_stop neben der Straße" - Fraktionen von weiteren Edit-Wars abhalten sollte: "Wenn da schon einer den bus_stop an die für Dich falsche Stelle gemacht hat, dann kannst Du jetzt mit public_transport=xxx das andere Ding auch noch hinzufügen und es kommt dann gleichberechtigt in die Route".

ToniE wrote:

IIRC, bei einer neueren Diskussion über "stop_position ist generell unnötig" wurde bzgl. 1. und letzte stop_position eine Ausnahme gemacht, was wiederum nicht konsequent zu "komplett ohne stop_position" ist - irgendwie braucht's man dann doch mal wieder?

Aber da geht man doch von der Vorstellung immer vollständiger Routen aus. Es gibt bestimmt noch viele Länder, in denen man ganz klassisch ein Stück mit dem Bus fährt und Haltestellen markiert und notiert und diese Teile dann in OSM einträgt. Oder man kommt per Rad oder zufuß an einer Haltestelle vorbei und trägt sie in die Routen ein ohne die Fahrstrecke des Busses gesehen zu haben.

Offline

#158 2020-05-05 22:45:22

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

Re: PTNA - News: GTFS-Analyse

Weide wrote:

Aber da geht man doch von der Vorstellung immer vollständiger Routen aus.

Ja, genau: das sollte das Ziel sein: vollständige Routen mappen.

Warum nicht darauf hinweisen, dass eventuell eine nicht vollständige Route vorliegt?


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

Offline

#159 2020-05-06 06:14:06

Weide
Member
Registered: 2009-04-05
Posts: 1,404

Re: PTNA - News: GTFS-Analyse

ToniE wrote:
Weide wrote:

Aber da geht man doch von der Vorstellung immer vollständiger Routen aus.

Ja, genau: das sollte das Ziel sein: vollständige Routen mappen.

Warum nicht darauf hinweisen, dass eventuell eine nicht vollständige Route vorliegt?

Klar. Sollte man möglichst machen.

Aber eine Zusatzregel zu PTv2, dass die erste und letzte Haltestelle bindend einen PTv2-Stop (oder gar gegen alle anderen PTv2-Regeln ein public_transport=stop_position) haben muss ist m. E. sinnlos. Entweder meint man nur die ersten und letzten Haltestellen der realen Linie ... dann kann man nichts nachprüfen, da das nicht in der Route steht. Oder man meint die erste und letzte Haltestelle der erfassten Route, dann muss man ganz normale Haltestellen anders erfassen solange der Rest einer Route noch unbekannt ist und bei jeder dieser Änderungen alle anderen dort laufenden Routen anpassen. Praktikabel wäre so eine Regel nur, wenn es nur vollständige Routen in OSM gäbe.

Offline

#160 2020-05-06 10:02:52

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

Re: PTNA - News: GTFS-Analyse

Weide wrote:
ToniE wrote:
Weide wrote:

Aber da geht man doch von der Vorstellung immer vollständiger Routen aus.

Ja, genau: das sollte das Ziel sein: vollständige Routen mappen.

Warum nicht darauf hinweisen, dass eventuell eine nicht vollständige Route vorliegt?

Klar. Sollte man möglichst machen.

Aber eine Zusatzregel zu PTv2, dass die erste und letzte Haltestelle bindend einen PTv2-Stop (oder gar gegen alle anderen PTv2-Regeln ein public_transport=stop_position) haben muss ist m. E. sinnlos. Entweder meint man nur die ersten und letzten Haltestellen der realen Linie ... dann kann man nichts nachprüfen, da das nicht in der Route steht. Oder man meint die erste und letzte Haltestelle der erfassten Route, dann muss man ganz normale Haltestellen anders erfassen solange der Rest einer Route noch unbekannt ist und bei jeder dieser Änderungen alle anderen dort laufenden Routen anpassen. Praktikabel wäre so eine Regel nur, wenn es nur vollständige Routen in OSM gäbe.

Mmh, mein Ansatz ist eher:

* eine erfasste Route, die nicht einer realen Route entspricht ist fehlerhaft.
* eine erfasste Route, die nur teilweise einer realen Route entspricht ist unvollständig und somit auch fehlerhaft.

Bei dem konkreten Beispiel: "der erste Punkt des ersten Weges einer Route ist nicht die erste stop_position"

* die erste stop_position ist in der Mitte des ersten Weges und der ist 5 Km lang - bei einem Bus irgendwie nicht passend.
** Der Weg sollte an der stop_position geteilt und der nicht relevante Teil entfernt werden.
** Wo keine Passagiere transportiert werden gehören die Wege nicht in die Relation.

* die erste stop_position ist der Verbindungspunkt zwischen dem erstem und dem zweitem Weg
** Der erste Weg sollte aus der Relation entfernt werden (s.o.)

und so weiter, da gibt es viele verschiedene Aspekt.

Beide Beispiele können vollständig erfasste Routen sein, mit leichten Fehlern.
Beide Beispiele können aber auch unvollständige Routen sein, und vor dem ersten Weg fehlt noch was.

Beide Beispiele sind es in beiden Fällen wert gemeldet zu werden, meiner Meinung nach: es ist was zu tun (korrigieren versus erweitern).


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

Offline

#161 2020-05-06 13:48:12

Weide
Member
Registered: 2009-04-05
Posts: 1,404

Re: PTNA - News: GTFS-Analyse

ToniE wrote:

Bei dem konkreten Beispiel: "der erste Punkt des ersten Weges einer Route ist nicht die erste stop_position"

* die erste stop_position ist in der Mitte des ersten Weges und der ist 5 Km lang - bei einem Bus irgendwie nicht passend.
** Der Weg sollte an der stop_position geteilt und der nicht relevante Teil entfernt werden.

Das sollte man dem Mapper nicht vorschlagen. Vielleicht fehlt nur eine Haltestelle davor und der Mapper teilt dann den Weg (erster Fehler) und löscht den völlig korrekten Teil aus der Relation (zweiter Fehler) und erweckt den Eindruck, die Route sei vollständig (dritter Fehler).

Wir sind uns aber völlig einig, dass da was gemeldet werden sollte.

Offline

#162 2020-05-06 17:16:28

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

Re: PTNA - News: GTFS-Analyse

Weide wrote:
ToniE wrote:

Bei dem konkreten Beispiel: "der erste Punkt des ersten Weges einer Route ist nicht die erste stop_position"

* die erste stop_position ist in der Mitte des ersten Weges und der ist 5 Km lang - bei einem Bus irgendwie nicht passend.
** Der Weg sollte an der stop_position geteilt und der nicht relevante Teil entfernt werden.

Das sollte man dem Mapper nicht vorschlagen. Vielleicht fehlt nur eine Haltestelle davor und der Mapper teilt dann den Weg (erster Fehler) und löscht den völlig korrekten Teil aus der Relation (zweiter Fehler) und erweckt den Eindruck, die Route sei vollständig (dritter Fehler).

Yep, das sollte vermieden werden. In solchen Fällen schaue ich mir 'name' und 'from' und 'to' an und entscheide dann vorsichtig anhand 'name' von erster und letzter Haltestelle.


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

Offline

#163 2020-05-13 15:49:36

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

Re: PTNA - News: GTFS-Analyse

Hi Toni,

hier hat sich ein Fehler eingeschlichen:

https://ptna.openstreetmap.de/gtfs/DE/s … s20-1.10.H

name     Bus 564: Buchbach => Erding, Korbinian-Aigner-Gymnasium sium asium

Gymnasium sium asium big_smile

Offline

#164 2020-05-13 16:52:37

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

Re: PTNA - News: GTFS-Analyse

noch was:

https://ptna.openstreetmap.de/gtfs/DE/s … s20-1.15.R
https://ptna.openstreetmap.de/gtfs/DE/s … s20-1.13.R

die zwei sind gleich... bis auf Haltestelle 18. Trip "26.T0.19-564-s20-1.15.R" hat da einen Fehler smile

Offline

#165 2020-05-13 19:46:28

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

Re: PTNA - News: GTFS-Analyse

miche101 wrote:

Hi Toni,

hier hat sich ein Fehler eingeschlichen:

https://ptna.openstreetmap.de/gtfs/DE/s … s20-1.10.H

name     Bus 564: Buchbach => Erding, Korbinian-Aigner-Gymnasium sium asium

Gymnasium sium asium big_smile

... und nicht nur dort - nur dass es hier aufgefallen ist.

So war's:

            $normalized =~ s/Gym./Gymnasium /g;
            $normalized =~ s/Gymn./Gymnasium /g;

So ist's korrekt:

            $normalized =~ s/Gym\./Gymnasium /g;
            $normalized =~ s/Gymn\./Gymnasium /g;

smile


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

Offline

#166 2020-05-13 20:40:51

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

Re: PTNA - News: GTFS-Analyse

miche101 wrote:

noch was:

https://ptna.openstreetmap.de/gtfs/DE/s … s20-1.15.R
https://ptna.openstreetmap.de/gtfs/DE/s … s20-1.13.R

die zwei sind gleich... bis auf Haltestelle 18. Trip "26.T0.19-564-s20-1.15.R" hat da einen Fehler smile

Mmh, könnte man rausbekommen.

Die Analyse auf "unterschiedliche Trips" geht über die "stop_id" (die hier unterschiedlich sind) und nicht über den stop_name (identische Liste).

Das über "stop_name" zu machen würde auch bei vielen Zuglinien helfen, die an wechselnden Bahnsteigen halten und somit jedes mal eine eigene Variante darstellen.

Hier allerdings sind wohl die Inputdaten falsch (SISO = shit in, shit out). Oder auch GIGO = (garbage in, garbage out).

Ich werde es aber dennoch nicht über "stop_name" zusammenfassen, da ich nicht sicherstellen kann, dass ich als Referenz nicht zufällig die falsche trip-id erwische.

Aber: ich prüfe mal, ob ich für diesen Fall nicht doch eine "Warnung" generieren kann.

Last edited by ToniE (2020-05-13 20:41:51)


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

Offline

#167 2020-05-14 07:47:19

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

Re: PTNA - News: GTFS-Analyse

ToniE wrote:

"Warnung"

Warnung würde auch schon genügen... meine odt-Tabelle hat gleich gemeckert.. "doppelt"... bei genauerem hinschauen hab ich es halt auf der Map gesehen wo die Anweichung ist. Dazu ist die Map perfekt smile wenn man zwischen die Tabs hin und herwechselt

Offline

#168 2020-05-14 08:56:03

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

Re: PTNA - News: GTFS-Analyse

miche101 wrote:
ToniE wrote:

"Warnung"

Warnung würde auch schon genügen... meine odt-Tabelle hat gleich gemeckert.. "doppelt"... bei genauerem hinschauen hab ich es halt auf der Map gesehen wo die Anweichung ist. Dazu ist die Map perfekt smile wenn man zwischen die Tabs hin und herwechselt

Ich werde das so machen: bei gleicher Anzahl von Stops ermittle ich die stop_names und bei identischen stop_names suche ich nach dem/den "Übeltäter(n)" wieder anhand von stop_id.


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

Offline

#169 2020-05-15 08:47:02

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

Re: PTNA - News: GTFS-Analyse

ähh was ich mich schon mal gedacht hab. Kann man die Spalte "Linie" durch "Variante"/"Nr." 1, 2, 3, 4, 5... usw. ersetzen.. fände ich nützlicher wink dann muss ich nicht so zählen um die Gesamtzahl zu ermitteln smile

Also auf der Trip Seite: z.B.
https://ptna.openstreetmap.de/gtfs/DE/t … -210-s20-1

Last edited by miche101 (2020-05-15 08:48:22)

Offline

#170 2020-05-15 10:56:40

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

Re: PTNA - News: GTFS-Analyse

miche101 wrote:

ähh was ich mich schon mal gedacht hab. Kann man die Spalte "Linie" durch "Variante"/"Nr." 1, 2, 3, 4, 5... usw. ersetzen.. fände ich nützlicher wink dann muss ich nicht so zählen um die Gesamtzahl zu ermitteln smile

Da rennst du offene Türen ein.

BTW: es gibt nicht nur Trips mit "eigenartigem" Ende.

Beim VBB (Tram?) habe ich welche gefunden, die am Anfang und am Ende eigenartig sind: jeweils zwei mit selbem Namen, selber Position aber anderer Stop-ID


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

Offline

#171 2020-05-20 16:23:38

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

Re: PTNA - News: GTFS-Analyse

miche101 wrote:

noch was:

https://ptna.openstreetmap.de/gtfs/DE/s … s20-1.15.R
https://ptna.openstreetmap.de/gtfs/DE/s … s20-1.13.R

die zwei sind gleich... bis auf Haltestelle 18. Trip "26.T0.19-564-s20-1.15.R" hat da einen Fehler smile

Habe die Analyse der GTFS-Daten erweitert:

* Prüfung, ob die erste und zweite Haltestelle den selben Namen haben
** für vorletzte und letzte Haltestelle ist's ja schon realisiert

* Prüfung, ob zwei Trips (Fahrten/Varianten) bzgl. Haltestellennamen die selbe Strecke fahren (s.o.)
** ... aber unterschiedliche Stop-IDs (Platforms) anfahren
*** Für MVV:
**** Busse 240, 413, 444, 447, 531, 564, 619, 785 (22 Trips = 11 Paare)

Für MVV ist es gemacht. Für andere auf Anfrage, bzw. beim nächsten Update der GTFS-Daten.


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

Offline

#172 2020-05-20 17:27:22

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

Re: PTNA - News: GTFS-Analyse

ToniE wrote:

* Prüfung, ob zwei Trips (Fahrten/Varianten) bzgl. Haltestellennamen die selbe Strecke fahren (s.o.)
** ... aber unterschiedliche Stop-IDs (Platforms) anfahren
*** Für MVV:
**** Busse 240, 413, 444, 447, 531, 564, 619, 785 (22 Trips = 11 Paare)

Ja cool cool, macht es wieder ein Stück einfacher smile

Offline

#173 2020-05-25 17:11:03

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

Re: PTNA - News: GTFS-Analyse

So ich bin durch smile LK Ebersberg gefixt und update.. und LK Erding auch alle Varianten drin cool ab Bus 540 fehlt immer wieder das "Shape" ... deswegen sind auch die Ptv1 Relationen am Leben geblieben.. die kann man ja rendern wink 600 Freising usw. - 900 darf wer anders machen hmm

Aber die Analyse macht es schon erheblich einfach smile smile

Gruß Miche

PS: den Busbahnhof in Erding, Klinik muss ich mir mal genauer anschauen vor Ort.. da muss so einiges nicht stimmen hmm

Last edited by miche101 (2020-05-25 17:11:32)

Offline

#174 2020-05-26 08:42:17

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

Re: PTNA - News: GTFS-Analyse

miche101 wrote:

Aber die Analyse macht es schon erheblich einfach smile smile

Stimmt, ich habe auch mal wieder angefangen 2xxer zu kontrollieren. Geht schneller und systematischer, wenn man z.B. bei beiden (OSM, GTFS) die Liste der Haltestellen und gegebenenfalls als dritte Liste den PDF-Fahrplan vergleicht.

miche101 wrote:

PS: den Busbahnhof in Erding, Klinik muss ich mir mal genauer anschauen vor Ort.. da muss so einiges nicht stimmen hmm

Ich war letztes Jahr mal dort zum Mappen, aber leider hat's geregnet- schlechte Voraussetzungen um von Pole zu Pole zu marschieren und zu schauen, welcher Bus wo abfährt.

Last edited by ToniE (2020-05-26 09:22:56)


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

Offline

#175 2020-05-26 09:02:35

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

Re: PTNA - News: GTFS-Analyse

Ja bei "Klinik Nord" angesichts dessen das die Bustür ja rechts ist muss der Bus ja bei paar Platformen von der Gegenrichtung anfahren hmm  Das glaub ich hab selbst mal falsch aufgefasst roll Desweitern ist da noch schwierig ob dann ein Bus die Platform link oder rechts anfährt... die Schilder stehen mittig auf der Platform. Eventuell wird auch entgegen gehalten wenn die Platform von der einen Seite gerade belegt ist hmm

Offline

Board footer

Powered by FluxBB