PTNA - News: GTFS-Analyse

ach ja… wenn noch die Attribute/Dateinamen gefüllt haben möchtest… xsd:string xsd:string usw. wäre ein gut :wink:

Edit:
denk da an so:

  • DE-BY-MVV
  • Linie => “262”,
  • Trip-Id => “1.T0.19-262-s20-1.6.H”

Exakt, hatte ich in meinem Code oben u.A. schon erwähnt:

<h2>GTFS Analyse für <span id="network">DE-BY-MVV</span> Linie "<span id="route_short_name">xxx</span>", Trip-ID = "<span id="trip_id">adasasafaf</span>"</h2>

ahhh ok… hab ich übersehen :slight_smile:

Hab ich nicht,… ich schick es dir so… E-Mail ist raus :slight_smile:

Super und Danke, ist integriert.

Warum der Button bei mir im selben Browser (FF unter Linux) trotz identischem CSS mal

  • 'lightgreen" und fett ist, wenn’s von localhost mit lighttpd

  • normal und nicht fett ist, wenn’s vom ptna.openstreetmap.de mit apache

kommt erschließt sich mir nicht. :frowning:

Na ja!

Die Aggregierung kommt voran, die Anzahl der “trip_id” reduziert sich beim MVV von ~37.000 auf ~2.400 repräsentative ‘trip_id’ - das dauert auf meinem PC derzeit 20 Minuten.
Das dürfte die Web-Seite anschließend aber deutlich beschleunigen … ich arbeite noch an den Feinheiten.

sehr schön :slight_smile:

Die Arbeiten an der Aggregierung, dem Reduzieren der Datenmenge sind fertig.

Einige (nicht alle) Abfragen laufen nun um den Faktor 500 schneller, im 0.0x Sekundenbereich :):cool:

Z.B. Suche nach den Varianten des 210er: von ~ 30 Sekunden auf 0.03 - 0,06 Sekunden.

Hier die Details:


* Dauer der Aggregierung auf dem PC                 =       1276 Sekunden ~ 21 Minuten
* Größe der SQLite-DB vorher                        =   56659968 Bytes ~ 54   MBytes
* Größe der SQLite-DB nachher                       =    5660672 Bytes ~  5,4 MBytes
* Anzahl der Linien vorher                          =        623
* Anzahl der Linien nacher                          =        278 (solche, die ab heute oder in der Zukunft gültig sind)
* Anzahl der Fahrten vorher                         =      37236
* Anzahl der Fahrten nachher                        =       2330 (die sich nur durch den Weg, nicht mehr durch die Abfahrtszeiten unterscheiden)

Hallo Rainer,

Stuttgarter S-Bahn ist auch drin.

Und dabei kommt mir die Idee: Ich könnte noch untersuchen:

  • welche Variante Teilroute welcher anderen Variante(n) ist.

  • welche Variante ein merkwürdiges Ende “nimmt”

** Da gibt es beim 210er des MVV eine, wo der Bus an der Endhaltestelle wendet, dabei aber keine Passagiere mitnimmt (zumindest im online-PDF-Fahrplan nicht sichtbar). Das sieht eher aus wie ein Fahranweisung für den Busfahrer.

Das könnte ich versuchen zu erkennen und im Kommentar abzulegen.

GTFS-Aggregation für den VRR läuft und läuft und läuft … seit 2 Stunden. DB ist 6 mal größer als die vom MVV und die hat schon 20 Minuten benötigt.

Gruß,
Toni

Hallo Toni,
sehr schön :slight_smile:

Inzwischen habe ich noch weiteres Futter gefunden, das lizenztechnisch ok sein dürfte:
KVV
VBB

Gruß,
Rainer

Hi Rainer,

sehr gut, das hält mich beschäftigt.

  • KVV ist auch bei PTNA-Analyse noch nicht drin, das kann ich nachholen.

  • VBB ist zwar drin, aber die Liste der erwarteten Linien ist so gut wie leer, d.h. derzeit nur eine IST-Analyse.

  • GTFS ist nicht gleich GTFS ist nicht gleich GTFS … jeder interpretiert den Standard wohl ein wenig anders.

  • GTFS-Aggregation für den VRR (Sqlite-DB 330 MB!) erstmal nach 6 Stunden Laufzeit abgebrochen, ein paar printf() eingebaut um zu sehen, ob der überhaupt was sinnvolles tut, neu gestartet.

  • Miche hat mir ein JavaScript geschickt, mit dem man Routen in GPX ausgeben kann … :slight_smile:

  • Die Liste der existierenden Linien kann man ja für PTNA aus GTFS generieren, das mach’ ich dann auch mal …

Gruß,
Toni

AVV: http://opendata.avv.de/current_GTFS/ (gemeinfrei/CC0)

Danke und prima … jetzt geht’s aber los.

Wie beim VRR sind hier auch shapes.txt dabei - das wird noch einmal ein Kapitel für sich!

SQLite-DB von AVV hat die gleiche Größe wie bei MVV,

D.h. Aggregation sollte in 20 Minuten durch sein, danach noch ein wenig Feintuning, … aber noch ohne shapes.txt :frowning:

Update:

  • AVV ist nun drin, aber ohne SPNV und noch ohne shapes
    ** SPNV scheint in GTFS nicht korrekt abgelegt zu sein, einige route_id in routes.txt gibt es doppelt (sollte UNIQUE sein)

  • VBB ist in Arbeit, Aggregierung wird wohl > 10 Stunden laufen: 1280 Routen, 203701 Trips

  • VRR ist in Arbeit, Aggregierung wird wohl ~ 10 Stunden laufen: 1825 Routen, 139344 Trips

  • KVV macht Probleme, routes.txt und trips.txt scheint mit dem Feld ‘route_id’ nicht zu klappen … ‘no such column’

*** Analyse implementiert: “welche Variante Teilroute welcher anderen Variante(n) ist.**”

Alles in Allem: GTFS ist nicht gleich GTFS ist nicht gleich GTFS … jeder Datensatz eines neuen Verbundes bringt wieder eine Überraschung mit sich.

Update:

GTFS ist nicht wie Klopapier und Trockenhefe, es gibt Nachschub:
GTFS Daten BaWü
:wink:

Ufff :confused: aber das scheinen nicht so dicke Dinger wie VRR und VBB zu sein.

Als Nächstes will ich mich an die Shapes machen, denn die sind für OSM ja wichtig.
Sie beschreiben den exakten Fahrverlauf eines Busses, … mit allen Abzweigungen, Abbiegungen … und nicht nur die Haltestellen.

Ein “GPX-Download” soll draus werden, und evtl. auf einer Karte zeigen, …

Gruß,
Toni

Update:

Wenn shape Daten vorhanden sind, d.h. die Fahrtstrecke ist bekannt, so ist diese als Route in den GPX Daten enthalten. Die Way-Points sind die Haltestellen.

N.B.: Bitte beachten, dass die GTFS-Daten auch Fehler enthalten können, d.h. u.A. Positionen von Haltestellen stimmen nicht mit denen in OSM überein - warum auch immer.

ahh jetzt sieht man auch Teilrouten :slight_smile: Stimmt der 262 hat nur 4 Varianten nicht 6 Varianten :slight_smile:

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

https://ptna.openstreetmap.de/gtfs/DE/trips.php?network=DE-BY-MVV&route_id=19-262-s20-1

Besten Dank für deinen Einsatz.

Den VRS könntest du gelegentlich mal aufnehmen.
https://www.vrs.de/fahren/fahrplanauskunft/opendata-/-openservice
Das öffentlich zugängliche Internetangebot unter vrs.de ist für die Benutzung in osm freigegeben.

Gruß, Axel

In Vorbereitung, wird noch ein paar Stunden dauern mit der Aggregierung.