PTNA: news for Public Transport Network Analysis

Just added GTFS feed of

" Ver­kehrs­ver­bund Groß­raum Nürn­berg" (DE-BY-VGN)

to PTNA

3 Likes

Just added GTFS feed of

to PTNA

Problem: as of 2023-02-07 the contents of the GTFS data for Trans’Agglo fits for Avignon only - oops!
So I skip the analysis of that feed.

1 Like

Problem seems to be solved now on provider side.

1 Like

Just added GTFS feed of

to PTNA

In the pipe-line:

  • show number of individual trips for each route variant (how often does the bus, … take this route)

See also: PTNA-Tool und GTFS-Daten in Österreich - #62 by ToniE (german)

2 Likes

Just added

  • show number of individual rides for each route variant (how often does the bus, … take this route) during the validity period.

to PTNA

It is a rough calculation, there might be some rounding errors:

  • number of days in the validity period might not be a multiple of 7
  • number of ‘Fridays’ (a specific day of week) during the validity period might not be calculated 100% correctly

See how it works: PTNA-Tool und GTFS-Daten in Österreich - #62 by ToniE (german)

1 Like

Just added GTFS feed of

to PTNA

In the pipe-line:

GTFS feed data for

1 Like

Just added GTFS feed of

  • FR-ARA-Montelibus
  • FR-PAC-Altigo
  • FR-PAC-Bandol-et-Sanary-sur-mer
  • FR-PAC-Movenbus
  • FR-PAC-TEDbus
  • FR-PAC-TransCoVe

to PTNA

In the pipe-line:

GTFS feed data for

2 Likes

and can even be negative if the GTFS data is wrong or at least “strange”.

Example for correct data: bus rides on every Saturday except if this is a public holiday

Example for wrong data: bus rides on every Saturday except on 2023-01-01, 2023-01-02, 2023-01-03, … (which are Su, Mo, Tu, …)

Well, PTNA does not make any attempts to consider this strange understanding of calendar_dates.txt

No new functions but

  • fellow mapper and coder ‘miche101’ realized a huge performance kick in the analysis part of relation.php (relation.js)

Examples:

You might have to refresh your browser’s cache (Ctrl-R or Ctrl-F5) to see the effect - Analysis progress given now in ‘ms’ rather than ‘%’

1 Like

Ich schreibe mal hier. @ToniE Wenn das ein reiner Neuigkeiten-Thread bleiben soll, bitte einen Moderator das in ein neues Thema aufzuteilen.

Ich habe drei Anregungen für PTNA:

  1. Bei mir im Browser (Firefox) ist bei den Buslinien die Tabelle so breit, dass sie die Bildschirmbreite überschreitet. Dadurch ist es unübersichtlich. Die Spalte Fahrzeug könnte weggelassen werden (100% bus) und die Spalte “Relation (id=)” könnte schmäler sein um das zu verbessern.
  2. Eine Filterfunktion zusätzlich zum Sortieren wäre hilfreich. Manche Fehler kann ich von Remote leicht lösen (z.B. falsch sortierte Routenmitglieder). Manche sind nur mit Ortskenntnis zu lösen (z.B. Zufahrtsbeschränkungen auf Wegen). Diese remote nicht (oder nur schwierig) behebbare Fehler würde ich gerne ausblenden können.
  3. Irgendwelche Statistiken. Zum Beispiel ein Diagramm mit der Anzahl in OSM vorhandener Linien, eingefärbt in den Anteil mit / ohne Fehlern im zeitlichen Verlauf.

Passt schon, ein einzelner PTNA thread ist - glaub’ ich - besser.

  • Normalerweise versuche ich, nicht in das Rendering des Browsers einzugreifen (die Breite einer Tabelle) - geht manchmal komplett nach hinten los. Ich kann natürlich mal “maxwidth=100%” verwenden und wir sehen, was dann passiert. In der Regel geht kleinere Breite auf Kosten größerer Höhe.

  • Die Spalte “Fahrzeug” kann ich tatsächlich bei “Andere ÖPNV Linien” und “ÖPNV Linien ohne ‘ref’-Wert” weg lassen, die Tabellen werden “Fahrzeug”-spezifisch erstellt.
    Bei “Nicht eindeutig zugeordnete Linien” lasse ich die Spalte aber besser drin.

  • Die Spalte “Relation (id=)” ist als “nowrap”, d.h. “zusammenhängend in einer Zeile” gekennzeichnet, das kann ich raus nehmen, dann kann der Browser bzgl. Zeilenumbruch entscheiden.

Gute Idee, aber recht schwierig/aufwändig zu lösen. Die Anzahl der verschiedenen Meldungen ist groß. Ich müsste sie kategorisieren und aus-/einblendbar machen (via Javascript/CSS?) wie beim OSM-Inspector / keepright.at auch.

Habe ich auch schon dran gedacht. Jedem Meldungstyp eine eindeutige Nummer (verborgen) zuweisen und aufsammeln und so weiter. Anzahl train/bus/tram/… Linien/Relationen?

  • zunächst einmal in der betreffenden Auswertung selber, als weiteren Abschnitt am Ende
  • zusätzlich aufgesammelt in einer weiteren Datei über die Zeit/Tage/Wochen, … maximal x Tage zurück (damit die Datei nicht zu groß wird).

No new functions but layout changes:

I did some layout changes, triggered by a suggestion of @Nielkrokodil in this thread, message 10, point #1

  1. The tables in sections “Other Public Transport Lines” and “Public Transport Lines without ‘ref’” will no longer include the column “Vehicle (route_(master)=)”. Instead, the value (bus, train, …) will be given in the section header which leads each table.
  2. I set ‘max-width:100%’ for the tables. But this might not always show the intended effect: in some cases there will still be a horizontal scroll-bar, when the table is simply too wide.
  3. Allow the browser to insert line-feeds whenever appropriate too keep a table small

Change #1 might show up in the ‘diff’ view - tomorrow, after the next analysis run (over night).

2 Likes

I have another idea for a new feature:
On the gtfs page of a line is a table with all “Trip IDs”. It would be nice if one can see if such a Trip ID is already mapped in OSM.
Further, if I click on a specific Trip ID to get to the special trip page, it would be great to see the mapped OSM-route as overlay to the gtfs route.

1 Like

Yeah, good idea. I can do that and give some more information in the section “PTNA analysis data for this route” based on last night’s analysis report - not on up-2-date data retrieved via Overpass. This info is then based on gtfs:trip_id or gtfs:trip_id:sample being tagged in the route relation.

Good idea. I was always asking myself: how can I present GTFS trip and OSM route relation on one page? On the Trips-Page I have all necessary information at hand to show this on a special page.

I again have an idea for the gtfs page:

If a route has (one or more) sub-routes*, additionally (in Brackets?) show the cumulated number of trips, which is the sum of trips of the longest + all sub-routes. As all sub routes and the longest route are representated in OSM by the longest route, this sum shows the total number of trips it is representing.

*By sub-routes I mean routes being part of a longer route.

Yeah, this can be done.

Example: PTNA - GTFS Analysen

  • variant #4 has #1 and #3 as sub-routes, so the output would be: 10776 (sum(10776+170+168))

  • variant #5 has #2 as sub-route, so the output would be: 10235 (sum(10235+709))

  • variant #1, #2, #3: the output will not change

1 Like

But isn’t summing up like this confusing?

Actually, the shortest sub-route should have added the number of trips of the parent routes, 'cause that is what’s interesting to the passengers: how often can I expect a bus to arrive here and take me to a bus stop of this (sub)route?

Passenger’s view differ from Mapper’s view?

Well, I use ptna as a mapper, so I am interested in the biggest parent route.

The osm practice of mapping the longest route even if just one out of many buses goes the long distance is confusing.

  • “parent route” equals to “is not a sub-route of any other route”?

  • “biggest parent route” equals to the route from “A” to “Z” with the most trips when there are multiple routes between “A” and “Z”, some go via “B”, others go via “C”, or “D”, …?

Yeah, that makes sense.

I meant:
Parent route = has one or more sub routes, can be a subroute of another route.

Biggest parent route = has one or more sub routes and is not subroute of another route.

Example:
Route 1: A-B
Route 2: A-B-C
Route 3: A-B-C-D

Route 1 is subroute to 1 and 2
Route 2 is parent to 1 and sub to 3
Route 3 is parent to 1 and 2 and the “biggest parent route”.

1 Like