Hey Toni,
Might be a rare case, but since the wiki is kind of down at the moment it might be a good idea in the future to keep the last version of the routes.txt on your server and just update them before your an analysis is triggered. In case the wiki is not reachable, keep your version and use it for the analysis.
GTFS’ ‘platform_code’ is mapped to OSM’s ‘local_ref’ on stops/platforms
the ‘platform_code’ will be shown on the page where details for trips are shown: stop-list. Of course, values depend on GTFS feed data.
If reading CSV-Routes data from the OSM wiki fails, old data (from the day before) will be used avoiding huge ‘diff’ reports (thanks @aighes for the suggestion)
I’m a little bit confused, I can’t find a logic for the identification of twin routes.
E.g. Havelbus
following routes will shown under “x_700”, but “x_3” keeps empty (correctly)
604
route_master + 1 route with gtfs:route_id=x_700
6x route without gtfs:route_id
651
route_master with gtfs:route_id=x_700
2x route with gtfs:route_id=x_700
4x route without gtfs:route_id
671
route_master + routes with gtfs:route_id=x_700
route 652 - shown under “x_700” and “x_3”
route_master with gtfs:route_id=x_700
5x route without gtfs:route_id
following routes are not detected by PTNA
688 - x_3 already disabling needed, although similar mapping like 652
route_master with gtfs:route_id=x_700
route without gtfs:route_id
654 - x_3 already disabling needed, although similar mapping like 671
route_master + routes with gtfs:route_id=x_700
657
route_master mit gtfs:route_id=x_3;x_700
1x route mit gtfs:route_id=x_700 + gtfs:route_id_3=x_3
1x route mit gtfs:route_id=x_3
5x route mit gtfs:route_id=x_700
First of all: gtfs:route_id in the relation and route_id in the CSV are not considered at all for this
If there are two or more entries in the CSV with the same ‘ref’ and ‘type’, then it depends on ‘operator’ and if there is still more than one match it furthermore depends on the ‘to’ and ‘from’ values on both CSV and relation data.
657 has two CSV entries but PTNA could not decide which relation needs to be listed unter which CSV entry - so OSM data is listed unter “Not clearly assigned”
merge both CSV entries into a single one - not implemented by Inject-Code
create a single CSV entry manually, filtering out the automated one
==== Havelbus Verkehrsgesellschaft mbH
===== Eindeutig identifizierbar
- route_id 1924_3 von Bus 654 wird hier rausgefiltert: könnte ein Duplikat von Bus 654 route_id 1924_700 sein
-
- route_id 10685_3 von Bus 688 wird hier rausgefiltert: könnte ein Duplikat von Bus 688 route_id 10685_700 sein
- Bus 657 wird hier ausgeklammert und weiter unten explizit gelistet
@type=bus
@operator~Havelbus
@route_id!=1924_3
@route_id!=10685_3
@ref!=657
@@
===== Mix aus zwei GTFS entries
657;bus;;;;Havelbus Verkehrsgesellschaft mbH;DE-BE-VBB;"???_700;???_3"
will try this, together with 1. filtering out option (both temporarily?!) ok
Is it possible to add the manuell entries at the end of the same table without a separate title, like:
- Bus 657 erscheint am Ende der Liste aus Gründen
@type=bus
@operator~Havelbus
@route_id!=1924_3
@route_id!=10685_3
@ref!=657
@@
657;bus;;;;Havelbus Verkehrsgesellschaft mbH;DE-BE-VBB;"???_700;???_3"
-
or is it faulty?
P.S.
I have identified twin routes only by 4 operators: Havelbus, Oberhavel, prignitzbus and regiobus Potsdam Mittelmark,
further investigations not done
Yes, I had an idea, but that seems to be no longer valid, have to investigate further, seem sto be quite complicated.
I’m also thinking about using ‘operator’ and ‘to’, ‘from’ only after having checked CSV:route_id against OSM:gtfs:route_id to distinguish ???_700 and ???_3 - this way allowing two CSV entries but then also having two route_masters.
Is it worth investigating further assuming ???_3 and ???_700 are bugs in GTFS?