Buslijnen, halteinfo, OV-routes - overzicht en discussie

Oke Leo… bedankt voor het checken…

Waarom zouden we moeten afwijken van wat de wiki voorschrijft:

Op de rijbaan een node met:
public_transport=stop-position
bus=yes

Naast de rijbaan:

een node met:
public_transport=platform
highway=bus_stop

of
een way, met:
public_transport=platform
highway=platform
op een van de nodes van de way: Highway=bus_stop

De laatste combinatie is dus niet juist volgens de wiki.
Dat zou moeten zijn:
public_transport=platform
highway=platform
en op een van de nodes highway=bus_stop

Leg eens uit waar dat staat?
Ik wil helemaal van welke highway=bus_stop/platform dan ook af, die hoeven namelijk niet in PT V2.

Daar denken de wiki-schrijvers dan wel heel anders over !

https://wiki.openstreetmap.org/wiki/Public_transport

en ook

https://wiki.openstreetmap.org/wiki/Key:public_transport

Voordat de discussie onnavolgbaar wordt: wat is PT V2?

Dat staat voor Public Transport versie 2.

Dat staat hier beschreven: https://wiki.openstreetmap.org/wiki/Public_transport

De bushaltes in mijn dorp heb ik verder verbeterd en volgens gelijke systematiek gemapt:

Op de exacte positie van de haltepaal een node met de tags:
highway=bus_stop
public_transport=platform
name=[naam van de halte]
bus=yes
ref:IFOPT=NL:Q:[8-letterige code van de halte] (in geval van dubbele codering de 8-letterige codes gescheiden door puntkomma)
shelter=yes/no
bench=yes/no
zone=[4-letterige code van de zone] (hier moeten we eigenlijk nog een andere key voor bedenken]

Als er speciale bestrating/verhoging ligt in het trottoir of er ligt een stuk trottoir duidelijk aangelegd voor de bushalte, dan heb ik ook een lijnelement getekend dicht tegen de rand van de weg met de tags:
public_transport=platform
bus=yes
tactile_paving=yes/no
surface=* (meestal paving_stones)

Als er een bushokje is dan heb ik deze als vlak ingetekend met de tags:
amenity=shelter
shelter_type=public_transport
bench=yes/no

Meestal zijn er hierdoor minimaal twee elementen die aangeven dat er een bushalte is en komen bepaalde tags dubbel voor.
Dit is een gevolg van hoe de tagging voor busvervoer zich binnen OSM heeft ontwikkeld en heb gebrek aan aanpassing door de belangrijkste renderer (voor osm.org).

In de routerelaties zitten alleen de nodes en niet de lijnelementen.
Gebruik van public_transport=stop_position ben ik niet zo’n fan van en voeg ik zelf normaal gesproken niet toe.

Het lijnelement public_transport=platform heb ik met de naastgelegen infrastructuur verbonden als er daadwerkelijk een vorm van verbinding is.

In beide gevallen lijkt bus=yes, (in ieder geval volgens de wiki), overbodig.

Verder zie ik geen doorslaggevende argumenten tegen het onderscheiden van de haltepaal en de halte(=plaats waar de reizigers wachten),
hoewel de wiki dat onderscheid niet maakt. De haltepaal bevat dan alle noodzakelijke tags en Highway=bus_stop zorgt er dan voor dat de bushalte wordt gerenderd, dus daar is niets mis mee.

Voor het lijnelement geeft de wiki ook nog Highway=platform. Wat is het effect als je dat weglaat ?

Het opnemen van de stop_position én de halte(paal) in de route relatie is een beetje dubbelop en volgens de wiki is dat ook niet voorgeschreven. Het weglaten van de stop_position kan dus zonder bezwaar en het voorkomt veel extra nodes op de weg.
Anderzijds kom ik nu ook routes tegen waarbij alle gegevens aan de stop_position zijn toegevoegd !

En buslijnen die heen en terug over dezelfde rijbaan van de A2 rijden. (je kunt elkaar wel passeren, maar je blijft wel een spookrijder.)
De bushalte voor de ene richting hangt in de relatie van beide richtingen.
De bushalte voor de andere richting heeft geen enkele relatie.

Het lijkt erop dat niemand de wiki leest.
Kortom, een heerlijke onbeheersbare chaos.

Vriendelijk dank Leo voor het werk aan de busroutes in Enschede.

Bedankt voor je reactie, Leo!

De bus=yes liet ik eerst weg op basis van de wiki over het nieuwe taggingschema. Op andere Wiki-pagina’s, bijv. die over highway=bus_stop, wordt toevoeging van bus=yes wel genoemd. Andere OV-mappers in Nederland voegen bus=yes meestal wel toe. Ik ben daar nu dan maar in meegegaan.

Goed dat je het noemt. Ik zal die tag nog toevoegen aan het lijnelement want dat zorgt ervoor dat het wordt gerenderd.

De ‘chaos’ komt voornamelijk voort uit een gebrek aan actieve mapping. Het is een enorme klus om het busvervoer bij te houden terwijl er een grote achterstand is/was. Maarten Deen heeft zich ermee bezig gehouden door heel Nederland om met name de relaties in orde te maken en gaten in routes op te sporen. Er zullen vast nog regio’s zijn die zijn blijven liggen.

Om een route over de verkeerde rijbaan te constateren is meer handmatige controle nodig.
In Fryslân heb ik het van eind 2016 tot medio 2017 veel van dat werk verricht en daarna wijzigingen in de dienstregeling doorgevoerd. In deze provincie zul je op dit moment weinig fouten kunnen ontdekken. Voor Groningen en een deel van Drenthe is HenkL actief. Noord-Nederland ligt er wat dat betreft goed bij.
En er is Sint E7 die al een tijdje bushaltes bijwerkt en heeft aangegeven zich later ook met de relaties te willen bezighouden.

Het probleem wat betreft richtlijnen en documentatie is dat ‘de wiki’ niet bestaat. Een onderwerp kan verspreid over vele pagina’s worden behandeld. Er zijn meerdere pagina’s over openbaar vervoer, pagina’s over tags, pagina’s over keys, en dat weer in meerdere talen. Tegenstrijdigheden zijn dan onvermijdelijk.

De wiki’s helpen wel om internationaal redelijk op één lijn te blijven en dit topic helpt dan weer om nationaal af te stemmen.

Ik heb in https://wiki.openstreetmap.org/wiki/NL:Public_transport#NDOV een beginnetje gemaakt met informatie over het NDOV, ik denk dat dat daar wel past.

Voor degenen die snel IFOPT refs willen zoeken heb ik een html-pagina gemaakt met een paar velden van het NDOV haltebestand: http://www.maasluip.nl/osm/NDOV.html. Er staat nu de haltenaam, IFOPT code, RD en WGS84 coordinaten en de richting van de route (wat heel handig is om snel te zien of het de halte aan de ene of de andere kant van de straat is).

Ik weet niet of dit op die manier nuttig is, misschien moet ik er de plaats maar bij gaan zetten, want haltes als Centrum zijn natuurlijk lastig.

JAWEL, in PT v2 MOET je juist én de stop_position, én het platform toevoegen! Dat is voor een data consumer juist datgene dat een bushalte (waar passagiers komen) aan een route (waar de bus rijdt) verbind!!!

@Maarten
Gisteren had ik het er per PB nog over met Sint E7 die al veel IFOPT-codes aan bushaltes heeft toegevoegd: bushaltes kunnen meerdere IFOPT-nummeringen hebben. En dan bedoel ik daadwerkelijk meerdere nummers per paal. Niet alle websites vermelden deze extra nummers.

Dit ontdekte ik als eerste bij de halte De Anjen in Kollum.
HalteBeheer geeft alleen -30 en -40: http://haltebeheer.nl/#NL:S:21682230
Zelf gebruik ik vaak OvZoeker, die naar mijn ervaringen het meest betrouwbaar is, en die geeft vier nummers: https://ovzoeker.nl/locatie/53.27806:6.13822:19: -30, -31 en -40, 41.
In het NDOV-overzicht ontbreken deze extra nummers.

De dubbele codering wordt bevestigd in de dienstregeling van Arriva.
Ik heb ontdekt dat dit het geval is als een buslijn in beide richtingen bij exact dezelfde haltepaal stopt.
Bij de Anjen en twee andere haltes in Kollum is dat het geval doordat lijn 62 voor beide richtingen de westelijke invalsweg heen en terug gebruikt en daarbij aan beide kanten een stop maakt (net vóór een ronde door het dorp en net na een ronde door het dorp).

Een andere situatie waarin zoiets gebeurt is wanneer er aan één kant van de weg een lus is waar bussen voor beide richtingen op dezelfde wijze langskomen en er dus maar één bushalte is. Dit is bijv. zo langs de N357 voor de haltes met telkens de naam Provincialeweg te Hallum, Marrum, Ferwert en Blije.

Je hebt gelijk (ik moet ook de laatste regeltjes van zo’n pagina lezen):

  • First a list of all stations in the order: stop_position 1, platform 1, stop_position 2, platform 2, … Stop positions get the role stop, platforms the role platform. It is necessary to add the stops/platforms if they are mapped but it is not necessary to add them if they are missing just to be able to add them to the relation.
    -The list of stops and platforms is followed by a ordered list of the ways which are used by the vehicle from the starting station to the terminal station. Each direction of the route must have its own relation, forks are not permitted. If there are multiple different routes from the starting station to the terminal station, each variant must have its own relation.

Maar een route relatie met alleen de stopposities of alleen de platforms voldoet dus ook aan de regeltjes, mits de ander niet gemapt is.
En ook dat komt voor !

Dat lijkt me inderdaad de meest optimale toepassing. Ik heb het zelf nauwelijks toegepast en gebruikt, behalve bij bijv. busstations, omdat het door de andere mappers verder ook nauwelijks werd gedaan.
Het betekent extra werk en data, zoals (bijna) een verdubbeling van leden in een busrelatie. En waar wel al stop_position is aangebracht is vaak de weg geknipt… maar volgens mij is dat niet nodig.

Er is de suggestie in het nieuwe taggingschema om de halteplaats aan te geven met een node OF een lijn. Ik ben telkens uitgegaan van een node. Op sommige plaatsen was echter (ook) een lijnelement toegepast. Dat is niet per definitie fout dus dat heb ik dan laten staan. Maar om dan de node achterwege te laten zou betekenen dat het bekende blauwe icoontje niet meer op de kaart verschijnt.
In mijn eigen dorp probeer ik compleet te zijn en heb ik ze op beide manieren aangegeven.

En nu dan eventueel de stop_position nog, maar dat zou ik dan eigenlijk in heel Fryslân moeten/willen doen, want ik ben juist tevreden dat het busvervoer voor de gehele provincie met ongeveer gelijke kwaliteit is gemapt.

Dank dat ik hier ook even genoemd wordt. Met bushaltes Centrum of Station, die ontelbare keren voorkomen in Nederland, moet ik zelf namelijk nog het QGis-bestand ernaast hebben om enigszins te kunnen traceren waar deze ligt. Wel vind ik het opvallend dat ik veel haltenodes tegenkom waar de relaties aanhangen en slechts enkele stop_positions die midden op de weg geplaatst zijn.

Die NL:S nummers zijn ook niet de halte nummers (quaycode) maar de stoplaats nummers (stopplacecode).
Neemt niet weg dat NL:Q:21682231 en NL:Q:21682241 inderdaad niet in het CHB haltebestand zitten. Iets wat wel mogelijk moet zijn met de xml structuur die het NDOV tegenwoordig gebruikt. Misschien moeten we ze daar eens op aanspreken.

Het is wel een beetje lastig om dat in OSM op te nemen. Moeten we dan een ref:IFOPT=NL:Q:21682230 en ref:IFOPT:1=NL:Q:21682231 gaan gebruiken o.i.d.?
Of is het eens tijd om over een nieuw datamodel van OSM na te denken. Niet meer de k-v combinatie is uniek, maar elke k-v combinatie krijgt een uniek id waardoor je meerdere gelijke k-v combinaties aan één object kunt hangen.

Ik heb nu ook de plaatsnaam aan de tabel toegevoegd, dat maakt zoeken bij veel voorkomende namen wat sneller.

Heb ook gemerkt dat sommige haltes op de grens van twee zones een dubbel nummer hebben in de dienstregeling van bv. QBuzz.
En sommige haltes hebben voor de ene concessie/busmij een heel ander nummer dan voor een andere concessie.

In het CHB staan ze echter altijd met slechts één nummer, immers fysiek slechts één halte/stopplek.

In de map http://data.ndovloket.nl/haltes/ staat een bestand PassengerStopAssignment… waarin dergelijke ‘dubbele nummers’ weer herleid worden naar dat ene nummer in het CHB.

Deze vraag heb ik al eerder gesteld, maar daar kwam toen geen antwoord op; dus bij deze nogmaals:

Vanuit België komen diverse buslijnen van De Lijn naar ons land toe en bedienen daarbij meerdere haltes op Nederlands grondgebied. Bij het nalopen van deze haltes, blijkt dat deze haltes de volledige naam hebben (bijvoorbeeld: Oostburg, Watertoren of Maastricht, Boschstraat). Gebruikelijk is echter dat hier alleen de naam Watertoren wordt gebruik bij de tag “name=…” en dat eventueel op de stop_position wel de plaatsnaam toegevoegd kan worden.

Is hier een bepaalde oplossing voor?, want vanuit de consistentie gezien zou bij al deze haltes de plaatsnaam eraf gehaald kunnen worden bij de tag “name=…”.