PTNA provides GTFS data for selected feeds.
I implemented a new feature allowing a comparison between a GTFS-trip and an OSM-route.
Check it out by clicking on the icon in column 3 of a PTNA report (see image below: example).
More will follow, allowing a comparison between GTFS-route and OSM-route_master (proof-of-concept).
Once this is all done and dusted, a comparison between GTFS and GTFS (routes/trips) can be performed as well, finding out the differences between an old and the new GTFS-feed.
The comparison is based on calculation of the mismatch between some metrics applied on stops
number of stops
positions of stops differ
by more than 20 meters
by more than 100 meters
by more than 1000 meters
GTFS-âstop_nameâ and OSM-ânameâ
GTFS-âstop_nameâ and OSM-âref_nameâ (if tagged in OSM)
GTFS-âstop_idâ and OSM-âgtfs:stop_idâ (if tagged in OSM)
GTFS-âstop_nameâ and OSM-âref:IFOPTâ (if tagged in OSM)
The comparison page can be reached via the PTNA report performed for a ânetworkâ.
A new icon in column 3 of the report
points to the GTFS/OSM comparison for the OSM route.
To get the icon displayed, OSM-route-relations need the following tags:
This concept allows checking OSM versus GTFS if you already have found the right corresponding trip_id - does OSM-route still reflect GTFS-trip. But this task can be tedious and can take some time.
To speed up this task of finding the right GTFS-trip_id and OSM-route-relation a comparison between GTFS-route and GTFS-route_master will be implemented as well. See the proof-of-concept page.
Having done this, the icon will pop-up in the PTNA report at two additional places:
column 3 for the route_master
if gtfs:feed and gtfs:route_id are tagged
in the large image, top right corner in the table header
if feed and route_id are in the CSV data in the OSM-Wiki:
12;bus;"Tewksbury via Rte. 38/Wilmington Train Station";;;Lowell Regional Transit Authority;US-MA-LRTA;3001;
this allows a comparison even before you start tagging the OSM-relations
The concept will later on allow also a comparison between two GTFS-feed versions, their routes and their trips (spoiler: new stop #43). But this is work in progress.
What's next?
I already received some good comments:
add more links to edit OSM-relations in the tables
Is there a possibility to flag false-positives (like in Osmose)?
And there seems to be an issue with special characters. See PTNA - Compare GTFS trip with OSM route stop #9 âGrundlsee Rösslernâ looks the same but is flagged as different stop name.
Hmm, not at the moment. A feed-back channel requires authentication, moderation, âŠ? Iâll have a look at the Osmose solution.
Hard to detect even in JOSM, but OSM Data is actually wrong/differs.
âGrundlsee RoÌsslernâ, the first âsâ in âRösslernâ seems to be a strange UTF-8 character looking like an âsâ but is an âsâ with double points like on top of âöâ
The place where I wait for the bus, in OSM terms the highway=bus_stop â is that part of GTFS? In my home town the bus_stop is mostly mapped at the stop_position, a node of the PT route â which is kind of not useful for me: For one, it is sometimes off quite a couple of meters, second it does not tell me the direction of the bus. Administrative PT router shows that very fine.
Perhaps flagging such difference might make PT mappers aware of that. I mapped some bus_stops where they actually are and constantly fear, PT mappers will just revert them to the stop_positionsâŠ
Yes, and their understanding of a âstopâ is what we call âplatformâ in PTv2 - where the passengers wait. Iâm someone mapping highway=bus_stop where passengers wait. And I see hw=bus_stop as legacy and use it only (sorry: mapping for the renderer Carto) to place the bus icon. So, I donât pay much attention on that.
Sorry for using a legacy app (not OSM-Carto). hw=platform indeed, I see this a legacy too, it should be pt=platform instead, that way PT mappers would not receive a QA issue with hw=footway. But please, PT mappers, put the hw=bus_stop somewhere off the driveway, in the correct location!
The data was already available, so just the evaluation needed to be coded
font-size doubled
font-weight increased
Itâs the number of rides for this particular trip (not: sum-rides)
in this example, #Num 9 is sub-route of #Num 2, but the 306 rides of #2 are not included in the 3595 of #9
BTW: in this example you can see that for == âTrips have identical stop-names but different stop-idsâ, the 4 trips 6,7,8,9 were already sorted descending by âridesâ
From release to release it is easier to check GTFS feeds with OSM relations, thank you.
A small wish/enhancement from my side with the weight for name. An exact match should be the primary goal but I had a lot of places (specially outside cities) where it is essential to put the city name next to the stop name. Why? Because otherwise you will have several âtownhallâ or âcemeteryâ stops and the same line and using the stopsâ names alone you will not know at all the differences between the same name. And most of time the city name is also visible on the pole itself. See this exemple - no name matching although the stops are the right ones - in some cases the name is really different and should be adapt but most of times it is correct. After the exact matching it can be useful to check if the GTFS name is included into the OSM name. Of course it should not be weighted as much as the exact name but can be a good indication if the stop matches.
I know this problem, although it is not that much related for editing the route when this passes several villages where the stop_names are equal.
The former, well accepted but now disabled oepnv-karte.de had the same problem with âFriedhofâ when starting a query (which routes stop here) towards âbahn.deâ. In such cases, âbahn.deâ returned a long list of choices, the one youâre asking for was almost never in the list.
To make the story short: a tag called âref_nameâ is used here which allows keeping the name=âFriedhofâ (on the map), having ref_name=âFriedhof, Ottobrunnâ for queries.
This is already the case, so
stop_name = âGare RoutiĂšreâ and
name = âDigne-les-Bains - Gare RoutiĂšreâ
would be accepted (silently, w/o applying different weighting)
The problem with the given, buggy GTFS feed is:
stop_name = "Gare RoutiĂšre " and
name = âDigne-les-Bains - Gare RoutiĂšreâ
do not match, because of the trailing blank in the stop_name.
PTNA already has a post-processing of stop_names, ⊠for the German language (âstr.â â âstraĂeâ, âŠâR.-Bosch-Str.â â âRobert-Bosch-StraĂeâ, âŠ).
Deleting â â at the begin and end of a name should be done for any language though. Iâll add that before downloading the new and available GTFS for many of the FR-PAC-* feeds.
Could be done, Iâll think about that. But: the current weight of â2â for name comparison is already small.
based on Javascript, not HTML/CSS though. It scrolls cell-by-cell, not smoothly but fast enough. This is the first approach, fine-tuning required (scroll to end, scroll to start, better icons, âŠ).
You might need to refresh you browser's chache : Ctrl-R / Ctrl-F5
Hi Toni,
I just have corrected a bus route whose itinerary had changed with help of the GTFS/OSM comparison and remarked that the route was missing two stops somewhere else, so that I could correct also that. Now I am thinking it would be interesting to see all the routes in the network (Verkehrsverbund) that have a mismatch of number of stops so that I can check whether the OSM route needs to be improved (or of course, the GTFS is incorrect). Is there a way to get a list of the mismatches of the best matches OSM/GTFS?