Algemeen Openbaar Vervoer (NL)-topic

Communities Nederland (Netherlands)
53

I created https://wiki.openstreetmap.org/wiki/NL-OV/PTNA
I used the NL-pp-ccc-format, where
pp=province (even if the province is not the concession giver) or multiple provinces separated by a lower dash if it’s a shared concession like GR_DR for Groningen-Drente
ccc=a self-made abbreviation for the concession (some of them are frequently used, but I’m not aware of all concessions having an abbreviation).

In the table is a column linking to the current concession relation in OSM.
There are four “special” concessions:

  • NL-HRN: the main rail concession, no province
  • NL-FL-ASL: this concession is for a to-be-opened airport, it has no lines at the moment
  • NL-NH-SHL: This concession is the internal transport of Schiphol Airport, both on public grounds and on the “airside”. It is not a public transport concession like others.
  • NL-GR_FR-RSFG: This concession is managed by three bodies, two Dutch provinces and a German body.

Search area can be derived from the province codes.

1 Like
54

Thanks for that, very helpful and it will speed-up the task. Although, from sheer amount it will take a while to complete that.

That’s fine, my interpretation of ‘pp’ is: in which region does this all happen. GR_DR is OK, in similar cases like BE (Berlin) and BB (Brandenburg, surrounding Berlin) I used “BE” only: that’s where the ‘network’ company has its headquarters. I leave it up to you.

I’ll start with two of them

  • NL-HRN as the global, nation-wide analysis
  • NL-GE-AN as this shows symbols of three different vehicle types

Once they’re ready, you can decide whether you want to use the common set of options. Here are the standard analysis options of PTNA with a short description.

55

For the options:

  • allow-coach: In the Netherlands i’d say that “coach” routes translates to long distance operators like
    flixbus. Some of them are mapped, but afaik none included within these concessions
  • check-bus-stop: We don’t have concensus on that within the Dutch community. I personally don’t add highway=bus_stop to new routes, I use public_transport=platform instead, and use a way for that if it’s a longer, raised platform (example), like the majority of Dutch bus platforms. But as this doesn’t render in OSM-carto, some people prefer to keep highway=bus_stop as a separate node.
  • check-name/name-relaxed: I would like to include this. Btw, I’ve always used the “→” unicode arrow instead of “=>”. I don’t understand what the difference between “normal” and “relaxed” mode is.
  • check-platform: please include this
  • check-roundabouts: many roundabouts are used completely in the Netherlands, so please disable this
  • check-route-ref: this is hardly ever used on stops. The “ref” tag is usually used to designate the platform letter, so please don’t use this.
  • check-way-type: In the Netherlands we’ve used a lot of highway=busway. Does that match?

Other options I would keep as you have in the linked IOW.

Does the PTNA check if the ref= of a public_transport=platform match the designated platform letter/number? I beleive for bus, there are a lot of platforms where the ref is not set. In the Netherlands for trains, we have “sectioned platforms” where a platform can be split, i.e. 2a/2b, but some longer trains stop at platform “2” which is 2a and 2b combined.

p.s. your last link is to your localhost, but I assume you mean this.

For NL-GE-AN: I highly doubt whether bus and trolleybus are used as separate vehicle types. Maybe it’s better to use NL-NH-ASD as that has bus, tram and metro in one concession, and is geographically a quite small area. And add NL-NH-NZKV to it, which is technically a separate concession, but is generally seen as the same (it has the same operator GVB). With those three concessions you have covered all modes.

56

Agreed, will not set that.

Agred, will not set that.

Usually, we set --check-name-relaxed. The strict check requires that ‘from’ and ‘to’ (and ‘via’) are exact parts of ‘name’. The more relaxed check uses sub-strings like ‘from’ = 'München Hauptbahnhof" and ‘name’ = ‘ICE 123: München => Berlin’. “→” shouldn’t be a problem though.

same here, a mix can be found.

… and not necessary if all vehicles which stop here are represented by route relations and have this stop as member

yes

No

Oops, thanks for pointing.

No problem.

BTW: “size of search area” → “small is beautiful” is really true at the moment. PTNA suffers here with FR-IDF-*, a large area. Overpass query only once for ~ 50 analysis (re-use of data if not older than 1.5 h). But analysis is started ~ 50 times for the stored data and that currently takes 5 times more time than before per analysis. Some analyses focus on 10 buses in a small sub-area of IDF, so why should PTNA read the 210MB instead of smaller search area of 1.5 MB? I don’t have local knowledge and can’t judge on the best location and best size. Let’s see whether this problem persists.

1 Like
57

Yeah, seems to be caused by 80% server load, did not check the disk load avg. though.
I’ll wait until tomorrow. But “small is beautiful” still be a target.

58

To keep NL-NH-ASD small, you could cover it using the following municipalities: Amsterdam, Diemen and Ouder-Amstel.
Together they are 259 km² instead of 4091,93 km² for North-Holland
image

1 Like
59

Just Amsterdam is enough. All lines that pass trough Diemen or Ouder-Amstel also pass through Amsterdam.

60

The first three are available, kindly see PTNA: news for Public Transport Network Analysis - #103 by ToniE

I’ve configured and added OSM wiki pages for the corresponding CSV lists. PTNA takes them as input as a list of what is expected (exists in reality). Kindly modify the lists to match your needs

61

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
62

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
63

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

64

fixed, can be seen tomorrow

1 Like
65

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

1 Like
66

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

1 Like
67

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?

68

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).

69

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
70

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
71

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)

Screenshot at 2024-05-05 14-16-35
Screenshot at 2024-05-05 14-16-351102×214 31.4 KB

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

72

Dat is inderdaad de juiste methode.