Algemeen Openbaar Vervoer (NL)-topic

Hi, I was a bit distracted from adding more NL-- analysis configs. Hope I can more work on that this week.

Distracted by: thinking about how to compare GTFS routes/trips with OSM route_master/route relations to find out which OSM-route corresponds best to which GTFS-trip. I’ll start a community discussion on that soon “PTNA: compare GTFS with OSM routes …” or so. I need to prepare some charts, … first.

1 Like

I have looked through the Arnhem-Nijmegen concession:

There are a couple of false positives:
trolleybus is not a access tag, instead it should look at bus
barrier=bus_trap implies psv=yes, so should not require a bus=yes tag or similar.

Otherwise I have worked through the errors mentioned and fixed them.

1 Like

Thanks for pointing to the errors. I’ll fix fhem as soon as possible.

fixed, can be seen tomorrow

1 Like

I boldly edited Amsterdam’s feed to include a few more lines, or will this break things?

1 Like

Great, that’s exactly the purpose of this OSM wiki page.

1 Like

I also updated links on NL-OV/PTNA - OpenStreetMap Wiki to the relevant analysis page.

Is there any way to order the lines in a numerical way (order is 1,2,3, 10,11, 20, 99, 100, 101, 200) instead of an alphanumerical way (order is 1, 10, 100, 101, 11, 20, 200, 99)? That’s probably very hard in combination with lines that have alphanumerical characters in them. But those are few between, so maybe you can order them as last (they are usually the night lines and the ferries … but in the case of Rotterdam also the metros)…

In category 3 (Other public transport lines) sometimes lines are included that don’t seem to have any geographical relation to the selected area, how come? The same goes for category 4 and 5.

Also, in category 6 I see some network values that I didn’t consider as they fall outside of the normal concession system. Do these come from the GTFS feed? Some of these are very much public transport (but not for some juridical arcanity) such as TESO (ferries Den Helder-Texel), Hugohopper (local volunteer buses Heerhugowaard), but sometimes not so much, such as EMA (Museum tram), Museumstoomtram Hoorn-Medemblik (museum railway), V&O (A touristical ferry), and sometimes fall outside of the Dutch concession system (Eurostar, Flyxbus).

For the entries with no network value: what should we do with:

  • Local ferries 1 2, operated by a municipality
  • Touristical ferries 1
  • National rail lines that are “open access” (outside of the concession system): 1
  • One that’s included is the “mandatory touringcar route Amsterdam” which shoudl not be mapped as a route=bus in OSM…

Edit: This is really great work, I haven’t had the time to look into it too much - very busy time work- and privatewise, I wish I could give this more attention.

Edit 2: I don’t really understand: is a match made between the GTFS feed and the OSM route and where are mismatches between them shown? Can you give an example?

I guess you refer to section 3 (Other public transport lines)? Well in the ideal world, this section should be empty, empty because

  • you can list all existing lines (existing in real world) of the concession in the CSV list in the OSM wiki. This allows having control on the order of the lines. Benefit: PTNA can and will link route_master and route relations together and make some more check on that: colour, network, operator, … route relations with same name, … PTNA will also complain if there is no relation which matches for a given CSV line - exists in reality, does not yet exist in OSM.
  • you deleted all relations with “good” ‘network’ values, which are artefacts, do no longer exist in reality (and also not in the CSV list) but in OSM
  • you can set ‘network’ in all relations to an appropriate value. PTNA will filter out (positives, negatives) the relevant/irrelevant ‘network’ value(s). Empty ‘network’ values are considered as ‘positive’ ones, belonging to the concession under analysis. PTNA can be configured to assume empty ‘network’ values as ‘negative’ ones though, so they get ignored.
  • you can set ‘ref’ in all reported relations which have no ‘ref’. ‘network’, ‘route’/‘route_master’ and ‘ref’ are important tags for PTNA for the analysis

Ideally, the analysis report will only show those lines listed in the CSV OSM wiki data, in the order you want.
Ideally, all relations have ‘network’ and ‘ref’ set.

Both assumptions allow PTNA to provide best results, listing at the end the ‘considered’ and ‘not considered’ ‘network’ values and let you find typos in ‘network’ values, …

The Overpass API query used will always find all public transport relations in the search area (show in the second column of PTNA - Results.

There is no link between the GTFS data provided unter NL-Nationaal and the PTNA analysis. However, you can

  • add the name of the GTFS feed (=NL-Nationaal) and the GTFS-route_id at the end of each line in the CSV OSM wiki data - currently just for information in the analysis report, a check between GTFS and OSM data is for further study. See the top right corner for my local bus 210
  • use the green button “Download as CSV data for PTNA” on the page PTNA - GTFS Analysis. Unfortunately, for NL, there is only a single GTFS feed, there are no separate GTFS feeds for each concession. This makes it hard to split and shrink the downloaded data and the copy&paste that into the CSV OSM wiki page.

Secondly, you can set ‘gtfs:feed’, ‘gtfs:route_id’ and other tags in each route/route_master relation and PTNA can provide links in the analysis report. See the “GTFS” links in column 3, again for my local bus 210.
See also the Proposal for GTFS-tagging which reflects many tags which have been proposed by me (PTNA) and also a set of proposed tags made by PTNA (for one route of subway ‘A’ in Rotterdam)

Regarding Edit 2: no, there is no check between GTFS and OSM data - currently. I was thinking about that, but found so many GTFS feeds with errors which would produce “false positives” on OSM data (but the error is in GTFS).

Waar is de OPNV-kaartlaag gebleven (https://www.öpnvkarte.de/)? Ik vond deze altijd een veel fijner beeld geven dan de public transit-laag.

1 Like

Deze laag is in januari verwijderd, omdat de laag steeds maandenlang niet werd geupdate.

Ik vond het ook een fijnere laag dan de Transport-laag. Bij die laag is bijvoorbeeld geen ondersteuning voor PTv2-tags en ontbreken routes van tramlijnen en treindiensten met hun nummers. Ik heb bij de Transport- en Fietskaart-lagen het gevoel dat ze de tagging van OSM uit 2010 renderen, i.p.v. de tagging uit 2024.

1 Like

In het kader van de Provincie van de maand (Groningen) heb ik ontbrekende (bus)haltecodes (ref:IFOPT) aangevuld in het netwerk 'Groningen-Drenthe). Nog niet in netwerk ‘Publiek Vervoer Groningen-Drenthe’, omdat ik er pas net achter ben dat die bestaat in osm :wink:

Met de haltecodes is het mogelijk om de routes in osm te vergelijken met de NeTeX data van de OV bedrijven. NeTeX is in Nederland/Europe de opvolger van GTFS en andere verouderde standaarden. Met behulp van het PassengerStopAssignmentExportCHB… bestand in de map haltedata kunnen de haltecodes bij de NeTeX haltes gevonden worden. Intern hanteren de OV bedrijven namelijk hun eigen codering.

De gevonden verschillen zijn vaak subtiel hier een aantal voorbeelden:

  • Op Zernike Noord in Groningen stonden verouderde haltecodes
  • Op Zernikeplein waren de codes voor de 2 haltes omgewisseld.
  • Enkele haltes hadden een dubbele haltecode, die gaven een mismatch.
  • Sommige routevarianten staan niet (meer) in NeTex. Dit werd bevestigd door OVInNederland en de site van de vervoerder. Deze heb ik nog niet meteen weg gegooid. Voorbeelden:
    14116429 - Bus 107: Stadskanaal Busstation => Hoogezand De Hooge Meeren
    13495402 - Bus 109: Assen Station => Groningen P+R Hoogkerk => Groningen Zernike Noord
    16804670 - Bus 4: Groningen Scholen Lewenborg => Roden Kastelenlaan (Alleen omgekeerde richting en nu tijdelijk ook niet)
    Is verwijderen uit de route_master en vervolgens verwijderen van de relatie hier voldoende?
  • Op busstations staat in osm soms een andere vertrekhalte dan in NeTeX. Ik ben ook al een keer tegengekomen dat in de NeTeX data 2 keer de zelfde route staat met alleen een andere vertrekhalte. In zo’n geval vind ik het voldoende als de route in osm overeen komt met 1 van de 2.
  • Soms staan in osm haltes die niet (meer) in NeTeX staan. Zoals hieronder waar Paal 6 en Paal 10 zijn weggevallen. Hopelijk kan iemand de NeTeX data bevestigen, want OVInNederland laat me hier in de steek. (geen opmerking over een wijziging)

Ik ga proberen of het lukt om de routes in Groningen-Drenthe sluitend aan te sluiten op de NeTeX data. Waarschijnlijk zullen er nog wel een paar discussiepuntjes open blijven staan.

Groeten,
Gertjan

Dat is inderdaad de juiste methode.

Even een update met de stand van zaken voor Groningen-Drenthe:
119 routes in OSM sluiten wat betreft de halte codes en de volgorde 100% aan op de Netex data.
Daarnaast sluiten 115 routes aan als je alleen kijkt naar het haltegebied, en niet naar de exacte halte. Hier zijn op 1 of meer plekken de codes van de linker en rechter halte verwisseld, of is een andere halte op een busstation gekozen.
Er blijven nog 20 routes over waar iets mee is. 10 routes lijken niet in de NeTeX data te staan, zoals Route Blauw in Meppel en Route Wolfsbos in Hoogeveen. Bij route 22 Emmen-Assen staat halte Station Beilen 2x achter elkaar in de NeTex gegevens. Weet iemand hoe ik dat kan terugkoppelen?
In grote lijnen was te zien dat veel kleine wijzigingen van de afgelopen jaren nog niet in OSM verwerkt zijn. Zaken als vervallen halte, nieuwe halte, kleine routewijziging, maar ook gesplitste of drastisch ingekorte routes. Voor Groningen-Drenthe heb ik het meeste gecorrigeerd en inmiddels ben ik voorzichtig begonnen met Fryslân.
Best nog veel werk, dus als iemand geïnteresseerd is hoor ik het graag.

network Alle haltes sluiten aan Alle haltegebieden sluiten aan Begin- en eind halte- gebied sluiten aan Geen aansluiting Totaal
Groningen-Drenthe 106 99 5 3 213
Publiek Vervoer Groningen-Drenthe 13 16 2 10 41
Total Result 119 115 7 13 254

NB. Nog niet al mijn aanpassingen van gisteren zijn verwerkt, omdat de dagelijkse updates van GeoFabrik altijd een beetje achter lopen.

1 Like