Based on PM by @mga_geo, I just added analysis support of gtfs feed data to ptna for
Analysis support for osm public-transport data has been added already before
PTNA seems to have problems with executing PHP.
Admins are informed.
All dynamically created pages (ending with *.php) cannot be delivered as usual.
However, analysis reports can be accessed directly:
Example: FR-PAC-Alpes-de-Haute-Provence using
https://ptna.openstreetmap.de/results/FR/PAC/FR-PAC-Alpes-de-Haute-Provence-Analysis.html
i.e. by adding the country FR and region PAC to the path of the page.
This applies for nearly all pages except DE-Bahnverkehr, EU-Flixbus, US-Amtrack, …
where there is no “region” (i.e. no second hyphen ‘-’) in the name.
Sorry for the inconvenience, hope this will be fixed ASAP.
Has been fixed!
We have 100% Disk full on the HW which hosts PTNA and other services.
Some reports cannot be created. We’re working on a fix.
Problem solved for the moment.
Fortunately, only UTC-06, CST, America/Chicago was affected at their 03:00 AM CST time.
Analysis will be restarted in 5 minutes.
2 Likes
There’s a discussion on GitHub on how to improve the GTFS trip vs OSM route comparison in PTNA.
Similar weight of score regardless of the position of error
Maybe you want to share some ideas, either in GitHub (preferred) or here (I’ll copy and paste to GitHub then).
@mcliquid @Patchi @mga_geo @Nielkrokodil @stanton @donmac703 @hlfan @David_Crochet @Jarek and of course all others as well.
1 Like
Public BETA testing is now open for this new feature.
Testing can be achieved be adding “&diff” to the URL of compare-routes.php and compare-trips.php after clicking 
As always: feed-back, comments, suggestions, questions, … appreciated
“I now declare this basar open!” Dinner for One
3 Likes
My first test: looks good. The basic function is there and seems to do what was expected. I had one case where the OSM and GTFS had the same count of stops but the OSM line had one stop more on the middle of the line and further one stop missed. The ‘old’ PTNA comparison kind of displays that problem but shows a greater distance between the stops - here it is an interesting case as the stop nb 8 has indeed a great distance between OSM and GTFS (the GTFS has an quite old position of the stop) but it is not an anomaly! The ‘new’ comparison shows the problems directly.
The only “critic” that I have, I would expect some kind of symbol/colour where there is some kind of anomaly (like the distance in yellow or orange). But as always @ToniE great work !
Thanks.
N.B.: for this analysis the weight of ‘name’ comparison has been set to ZERO: all GTFS ‘stop_name’ are in capital letters, always.
I will implement some changes regarding the detection of “is GTFS stop in same stop_area as OSM platform?”. The decision used for the ‘diff’ bases sorting should be as fuzzy as possible. False positives will be detected during comparison of ‘name’, ‘stop_id’, and position.
Additional tests for ‘diff’ based sorting
- convert names to lower case - “MOUNIER” is the same as “Mounier”
- same name but huge distance (> 100m): not relevant for sorting, relevant for comparison of positions
- what about accent characters then? toLower(“COLLEGE DEBUSSY”) != toLower(“Collège Debussy”)
- swap name parts - “Ottobrunn, Ortsmitte” is the same as “Ortsmitte, Ottobrunn”
- remove parts in brackets - “Yorkstraße (Berlin)” is the same as “Yorkstraße”
- also: swap name parts - “Taufkirchen (bei München), Friedhof” is the same as “Friedhof, Taufkirchen”
- remove blanks around some characters - “Ichostraße/Tegernseer Landstraße” is the same as “Ichostraße / Tegernseer Landstraße”
- can and will be extended
Yeah, I totally agree. You’ve marked “Carrefour de L’Europe” and “DIDEROT” here.
What would be the best way to mark that?
- highlight (light blue) the empty line, the gap
- highlight (??) all fields in the extra line
- …
for the French language, it is not always easy. The old rule is that there are no ‘accent’ or ‘cédille’ on capital letters but that is not true anymore. If you want to compare strings may be the best is to get rid of all ‘accents’, ‘cédilles’ and to lower everything and then compare. The unicode normalisation should do that probably. The only thing that will not work with the unicode normalisation are the chars Œ and Æ. But these are not very common. And if you want to decompose these 2 chars ‘Œ’ is ‘OE’ and ‘Æ’ is ‘AE’. So this maybe the best compromise.
Good question, I’m not the GUI specialist but highlight the line, it should be enough. The colour is not really relevant, it can be the yellow that you are using for the other anomalies.
Yes, thanks for the hint. I included that.
Done, see below
What I also did:
- ‘name’ and ‘ref_name’ comparison for the score has been reworked
- ‘equal after removing some blanks’
- ‘equal after swapping’
- ‘equal as qualified substring’
- “equal after removing all ‘(…)’”
- “equal after removing all ‘(…)’ and swapping”
- “equal after removing all ‘(…)’ as qualified substring”
- for the ‘diff’ based comparison (fuzzy, additionally)
- “equal by lower case after normalize(‘NFD’) plus deleting u0300 … u036f”
- ‘equal after removing all special characters’
These strings (except the ‘fuzzy’ ones) will be shown if you hover the mouse over the ‘name’ and ‘ref_name’ columns
Also: ‘&diff’ added to the URL will enable this.
2 Likes
An interesting side, or is it the expected effect (?) is that you can now more clearly see the different directions of the routes in-bound vs out-bound by their scores and colours.
On the follow picture,
- ‘in-bound’ : the first 4 rows and first 3 colums
- ‘out-bound’ : the last 4 rows and columns
For this route_master, the route members are sorted according to PTNA’s sorting of the GTFS trips. You see the green diagonale.
N.B. GTFS trip #4 has not been mapped in OSM: it’s assumed to be an error in GTFS (regarding platform 9 of trip 3 and 4)
Should not be used for ‘diff’ based sorting
Example: GTFS stop #6 instead of #3 is identical to OSM platform #1
Edit 2026-01-18 16:17 UTC : I fixed this
This is one of the intended side effects 
@ToniE would it be possible to have AU/VIC added to the PTNA Results?
I can see the GTFS feed is present at PTNA - GTFS Analysis but not in the static analysis at PTNA - Results
The source is compatible with OSM as documented at Australian Data Sources - OpenStreetMap Wiki with the CC BY waiver at File:DTP Waiver signed.pdf - OpenStreetMap Wiki
1 Like
I just added analysis support for public-transport data of osm to ptna for
- AU-VIC-All
- Victoria, Australia
- All public transport
- CSV routes data in the OSM wiki (Victoria Routes) has been added as a template, needs to be completed
- gtfs analysis support has been added some time ago for 8 different feeds
2 Likes
I found a (not so severe) bug in the diff based sorting.
The position (lat/lon) of an OSM platform (way or MP) is calculated as the closest (virtual) point of the way/MP to the corresponding GTFS stop (point) … before the diff based sorting. The distance between them is used for the sort if ‘stop_name’ and ‘name’ do not match.
The platform is a rectangle made of 4 points, the closest (virtual) point is on one of the edges.
Underground S-Bahn stop “Isartor, Munich, DE”
After the re-sort, the corresponding GTFS stop might be a different one, the distance might have changed, the lat/lon of the (virtual) point of the OSM way/MP might actually not be the closest point to the GTFS stop.
After re-sort, OSM point #18 is not the closest point to GTFS stop #9. Point #18 has been calculated before as the closest point to the next GTFS stop further to the south-east.
Underground S-Bahn stop “Isartor, Munich, DE”
I.e. after the diff based re-sort of the data, I have to re-calculate the lat/lon of the closest point of OSM platforms (ways/MPs).
I.e. after the diff based re-sort of the data, I have to re-draw the OSM data in the map: markers, circles and route
N.B. I have to make sure that PTNA iterates over all MP members (inner, outer) to find the closest point.
Underground S-Bahn stop “Hauptbahnhof (tief), Munich, DE” (central station (underground))
That’ll be time consuming: coding and on-demand analysis in the browser.
It will give more precise distances values. “GTFS best practices” recommends that lat/lon of GTFS stops must not be more than 4 metres away from real world positions.
1 Like
Good news: the position was always correct, the marker was set to wrong position only
2 Likes
I just released this new feature after some public beta testing.
The following settings have been made:
- weight for “xx differences in visited stop areas” = 15
- distance for “GTFS stop and OSM platform are in same stop area” = 100m
- used in diff based sorting if the names do not match (fuzzy check)
- distances for comparison of positions “GTFS stop vs OSM platform”
- below or equal 10m assumed OK (former: 20, @donmac703 : 4 would be very strict)
- below or equal 20m assumed minor difference (former: 100)
- below or equal 100m assumed major difference (former: 1000)
- above 100m assumed completely wrong
- the settings for the score colours have not been changed
- 48 : ‘#fe4000’ (above or equal 40%)
- 24 : ‘#f17a00’
- 12 : ‘#d7a700’
- 2 : ‘#aecd00’
- 0 : ‘#6aef00’ (above or equal zero)
This feature can be switched off by adding “&nodiff” to the URL of “compare-routes.php” and “compare-trips.php” (2nd one inherits this from the 1st one"
1 Like
Based on PM by @mga_geo I just added support for analysis of public-transport data of osm to ptna for
- FR-BRE-Lineotim
- Arrondissements de Lannion (Côtes-d’Armor) et Morlaix (Finistère)
- Linéotim
- CSV data in OSM wiki has been prepared before by @mga_geo Lignes Linéotim
- analysis support for gtfs data has also been added FR-BRE-Lineotim
Based on discussion PTNA-Tool und GTFS-Daten in Österreich - #70 by Findus23 I also added analysis support of public-transport data of osm to ptna for
- AT-Eisenbahn
- Österreich
- Alle Eisenbahn, Light-Rail und Monorail Linien
- CSV data in OSM wiki has been prepared as a template Bahnlinien in AT