Haltenodes (highway=bus_stop) verwijderen of leeghalen vanwege PTv2

Sinds het begin van Openstreetmap is een node met highway=bus_stop de manier om een bushalte aan te geven. Deze node wordt ook wel de haltenode genoemd. De tag is echter niet opgenomen in het PTv2-taggingsschema voor openbaar vervoer. Daardoor wordt deze haltenode soms verwijderd of leeggehaald bij een strikte interpretatie van PTv2.

Hierover is jarenlang steeds weer een discussie gevoerd in het Algemeen Openbaar Vervoer (NL)-topic. Deze discussie raakt steeds ondergesneeuwd tussen andere OV-onderwerpen. Daarom dit topic.

1 Like

Hierbij mijn argumentatie om de haltenodes intact te laten.

PTv1 vs PTv2
Het taggingsschema PTv2 is lang geleden ingestemd. Daarna is er echter veel kritiek op gekomen en veel renderers ondersteunen het niet. PTv2 is daardoor nauwelijks doorontwikkeld en tekortkomingen zijn nooit opgelost. Hierdoor is een situatie ontstaan waarin PTv1 (highway=bus_stop/platform) en PTv2 (public_transport-tags) naast elkaar worden gebruikt. Omdat de schema’s andere keys gebruiken, is dit ook goed mogelijk. Volgens mij helpt de iD-editor zelfs hierbij, door de tags van het andere schema aan te vullen, bijvoorbeeld public_transport=platform bij highway=bus_stop.

Haltenode: highway=bus_stop
Een grote tekortkoming van PTv2 is dat er geen duidelijk object is voor de bushalte dat kan worden toegevoegd aan de routerelaties. Er zijn stop-posities en perrons, geen halte zelf. De haltenode (met highway=bus_stop) heeft daardoor deze rol behouden. Deze node wordt dus altijd aan de routerelatie toegevoegd en bezit belangrijke algemene informatie over de halte.

In het Algemene OV-topic geeft @Leo_Slager aan dat deze node in de routerelatie hoort en @Gertjan_Idema dat een duidelijk bushalte-object met ref:IFOPT nodig is voor automatische controle met Netex-data.

Perron of perronrand
PTv2 heeft een tag voor het perron: public_transport=platform. Dit is dus het gebied waar de passagiers wachten. Hieraan wordt ook de PTv1-tag highway=platform toegevoegd. Het gebied waar mensen wachten is een area, geen lijn. Het perron als lijn intekenen is goed als eerste mapping met weinig detail. Daarna kan deze worden uitgelijnd naar een area.

Het is dan erg vreemd om perron als ‘rand van het perron’ te interpreteren. De tag is platform, geen platform_edge. Het levert ook nog eens plakwerk op met korte ways vastgeplakt aan het perron zelf.

Ik heb geen zin om de discussie nog eens over te doen.
Het is mij duidelijk, dat de halte node, bij survey zichtbaar, kan worden gemapt en dat daar op die paal veelal ook de gegevens staan.

Ik heb in het andere forumdeel al eens uitgetekend, hoe een locatie te taggen.
Op het platform teken ik ook een highway=platform lijn, dit is een gebruikelijke methode. Veelal waar de tactile_paving lijn ligt.
Sinds de komst van area:highway en dus area:highway=platform kan dat ook worden gezet.

Hoi,

Goede zet om hier een systeemdiscussie over te houden!

Ik zal later even reageren met mijn uitgebreide argumentatie.

Ik heb niet gereageerd omdat ik niet in een ruzie/edit war terecht wil komen.

Ik heb PTv2 wel eens uitgebreid bestudeerd en vond het een knap stuk werk, maar
 voor eenvoudige gevallen veel te ingewikkeld. In mijn omzwervingen kom ik overal OV-zaken tegen, en ik kan er geen duidelijke lijn in ontdekken. Het resultaat: ik doe helemaal niks aan OV mappen, behalve haltenodes en stopnodes naar de goede plek schuiven.

Ik ben daarom voorstander om voor de eenvoudige gevallen de eenvoudigste mapping met een haltenode te houden, en die ook te bewaren als het ingewikkelder moet worden. Entry level duck mapping zeg maar.

Ik had begrepen dat dat hier de afspraak was.

Dus: haltenodes verwijderen: ik stem NEE.

Leeghalen: daar heb ik geen algemeen antwoord op. Maar zie ook het verhaaltje hieronder over platform=yes taggen op de haltenode vs platforms mappen als object.

Platforms:

Mapping van platforms kom ik in alle maten en soorten tegen. De simpelste is platform=yes op een haltenode: “Er is een instapzone of -strook”. Als object zie ik platforms gemapt als node, als way, als area, en als combinatie van area en way. De way kan ook nog een highway=footway zijn met een platformtag erop.

Geen peil op te trekken, dus val ik terug op platform=yes op de haltenode en als er dan een expliciete platform als zelfstandig object gemapt is, dan klopt dat nog steeds. Vergelijk: bridge=yes op een way (“deze weg loopt over een brug”) met man_made=bridge (de brug zelf), gaat ook prima samen.

Meer strategisch/filosofisch:

Op zich sta ik positief tegenover een sluitend allesomvattend systeem van mappen en taggen voor OV, en met wat aanpassingen zou PTv2 dat waarchijnlijk kunnen zijn, maar het is gelanceerd zonder een sluitende uitrol. Het plan was denk ik: we lanceren het, en het is zo goed en vanzelfspreken dat iedereen de oude methodes zal verlaten en de hele installed base prontissimo gaat omzetten. En was er voldoende commitment vooraf van belangrijke data users op dit gebied?
Resultaat in dit soort gevallen is dat het een eindeloos verhaal wordt waarin oude en nieuwe oplossingen door elkaar blijven bestaan, in een soort verlamming.

@A67-A67 Zou je een van je startposts bij kunnen werken met een linkje naar de documentatie van elk?

Ik ben geen ingewijde in deze materie en vermoed het volgende:

  1. Public transport - OpenStreetMap Wiki

  2. Proposal:Public Transport - OpenStreetMap Wiki

PS Iemand anders mag ook hieronder reageren, maar niet allemaal :-)

In deze post zet ik mijn redening uit voor het niet uitgebreid mappen van highway=bus_stop.
Ik volg hierbij de Wiki.

Mijn startpunt is Public Transport:
Daar staat onder het kopje Different tagging schema’s 4 schema’s:

  • The Original Public Transport Schema, sometimes called Public Transport Version 1 (PTv1) is still (2024) widely in use, and most of the tags are more common than newer alternatives. Some mappers discourage using these tags, although none have been deprecated.
  • The Oxomoa Schema was a schema which has large similarities to Public Transport Version 2. It is no longer used for new features. You might sometimes find route relations which were created around 2010 and have not been modified since that time. It is documented on User:Oxomoa/Public transport schema. Don’t use it for new relations and migrate existing relations to the new schema. It is linked here for documentation purposes.
  • The New Public Transport Schema has been called Public Transport Version 2 (PTv2) since 2014. It was approved in 2011. The original wording of its proposal can be found at Proposed features/Public Transport - note that this proposal did not deprecate any existing tags.
  • The Refined Public Transport Schema is a proposal started in 2018 to simplify the current scheme. Details at Proposed features/Refined Public Transport.

Hoewel de twee nieuwere public transport schema (PTv2 en Refined) géén oude tags afkeurt (is er een betere vertaling van deprecate?), is de oude tag zoals highway=bus_stop geen onderdeel van PTv2 of RPT.

Voor mij is van belang dat het PTv2 al sinds 2011 (dus al 15 jaar) goedgekeurd is. Het RPT is sinds 2018 een proposal, en dus wat mij betreft niet actief. Ik vind het in deze discussie wel een belangrijke inspiratiebron, omdat het de tekortkoming van PTv2 (waaronder het dupliceren van informatie) probeert op te lossen. Daarnaast vind ik het lastige van RPT dat het dingen voorstelt die in gaan tegen het PTv2 én OPT (het steld bijvoorbeeld highway=bus_stop óp de weg voor)
RPT gaat diep in op hoe om te gaan met spoor-stations. Dat is een heel andere discussie, laten we die hier buiten laten.

PTv2 (Originele versie | Actuele versie) is dus het, al sinds 2011, goedgekeurde schema voor openbaar vervoer. Uit het doel van het schema komt duidelijk naar voren dat het niet alleen bedoeld is om openbaar vervoer op een kaart te tonen, maar dat het ook bedoeld is voor dataconsumenten, dus als onderdeel van een geografisch informatiesysteem. Ik ben zelf aanhanger van de kerk dat OSM geen kaart maar een GIS is, waar eenieder zelf naar hartelust o.a. kaarten van kan maken.

PTv2 maakt voor haltes onderscheid tussen een stop position (volgens mij hier niet ter discussie) en de platform.

Onder de kop platform staat als eerste zin

The platform is the place where passengers are waiting for the vehicles.

The platform is tagged as way or area where the passengers can wait for the vehicles. If there is no platform in the real world, one can place a node at the pole with public_transport=platform.

(nadrukking mijnerzijds).
Daaruit blijkt volgens mij duidelijk dat het public_transport=platform, bij haltes waar er iets van een perron is, een way (of area) moet zijn.
Op deze haltes kunnen allerlei dingen getagd worden, zoals de name, ref, local_ref, shelter, bench en covered.

Er wordt niets gezegd over de highway=bus_stop, die maakt geen onderdeel uit van het PTv2-schema.

Mijns insziens is, bij het mappen van een modern haltepaar (die bestaan uit een (verhoogde) stoeprand), het voldoende om twee keer een way te taggen met public_transport=platform en alle relevante tags en dan ben je klaar. (De stop_position is optioneel voor haltes waar dit op de dichtstbijzijnde way zou staan.)

Het voor velen grote probleem is dat de bushalte niet toont op de meestgebruikte kaart, OSM_carto (de standaard kaartlaag op openstreetmap). Dat is mijns insziens een fout van de maintainers, die dit niet willen renderen en het destijds al 10-jarig goedgekeurd zijn van public_transport=platform ontkennen, ondanks v e e l requests daarvoor (net als met highway=busway).
Andere kaartlagen (bijv tracetrack_topo) renderen dit prima.
Daarom is er ooit in de Nederlandse (nog oude) forums besloten (en ik kan de precieze discussie niet meer terugvinden, dus ik put uit mijn geheugen) om wel nog een node highway=bus_stop op de plek van de haltepaal te plaatsen met de naam om deze gerenderd te krijgen op osm_carto.

1 Like

Dat is een probleem, maar we zijn volgens mij al lang het stadium gepasseerd waar we als OpenStreetMap-gemeenschap iets moeten laten vanwege Carto. Carto is defect; Carto wordt slechts selectief onderhouden; en Carto’s maintainer gebruikt het project om zijn eigen wil door te drukken en initiatieven waar hij niet achter staat te frustreren (highway=busway!).

De OSMF is op de hoogte van dit probleem, en doet er ook al jaren niets aan. Dus laat er maar gaten valen in de ‘standaard’-laag; misschien dat er dan eens keer iets verandert. Ik steek mijn energie liever in het project waar het impact heeft. Renderers zoals OsmAnd en CoMaps doen het prima, en als daar bugs zijn dan worden die vaak opgelost of worden aangedragen oplossingen geaccepteerd.

Wat mij betreft voeren we deze discussie alsof Carto niet bestaat, want daar gaat toch niets veranderen voorlopig en is momenteel ook al defect voor openbaar vervoer door weglaten van highway=busway.

4 Likes

Dan mijn reactie op de agumentatie van A67-A67:

Ik denk eerder dat het andersom is: Het schema is al 15 jaar geleden aangenomen. Er is veel kritiek op gekomen omdat de bekendste renderer (de OSM-carto-standaardkaartlaag) en de bekendste transportrenderer (Andy Allen’s Public Transport-laag) het niet ondersteunen.
Er zijn zat renderers die het prima ondersteunen, zoals ÖPNVkarte, OsmAND, Tracestrack Topo.
Ik denk dat door het niet-ondersteunen van de bekendste renderer er veel frustratie is ontstaan.

Ik snap de fascinatie met “een duidelijk object voor de bushalte” niet.
Er zijn zat bushaltes die niet eens een paal hebben, zoals bijvoorbeeld de haltes op grote busstations als Utrecht Centraal. Daar is alleen een (aan het plafond hangende) lichtbak met halteletter, een heel klein paaltje met daarop in braille de halteletter en verder de verhoogte stoeprand.
Mijns insziens is een halte “een plek waar mensen wachten op een bus” en dus in veruit de meeste gevallen een stoep, die we in Openstreetmap meestal tekenen als lijn. Maar voor HOV-haltes kan dat ook een area zijn, of voor simpele halte een node.

De haltepaal (of eigenlijk: de sticker met het busicoontje op het bord dat vaak op de haltepaal staat) is juridisch een verkeersbord. Meestal taggen we informatie in OSM (zoals maxspeed=80) niet op de plek van het verkeersbord, maar op de ways of area waar het bord betrekking op heeft.

Dit kan prima met een way op de plek van de verhoogde stoeprand. Die wordt gemapt als public_transport=platform, maar kan gewoon de ref:IFOPT en local_ref hebben en als onderdeel van de routerelatie opgenomen worden. Daarvoor hoeft het geen node te zijn.

Als er een duidelijk perron is, zoals bij een treinperron of de eerder gelinkte HOV-halte, zou ik er een area van maken. Vaak is een bushalte echter onderdeel van de doorgaande stoep en is er geen duidelijke scheiding tussen de oppervlakte van de stoep en halte. Een stoep tekenen we in OSM sowieso al als way. Een “reguliere” halte wmb dus ook, al heb ik geen bezwaar tegen een area als het duidelijk te onderscheiden is van de reguliere loopweg.

Vaak ook als vlak hoor. In FryslĂąn zijn er zelfs 700 als vlak ingetekend en 347 als lijn.

Verreweg de meeste bushaltes die ik inteken zijn duidelijk als vlak herkenbaar. De lengte van een halte is immers goed herkenbaar aan de aangepaste stoeprand en de blindengeleidestrepen, en de breedte volgt daar meestal wel uit. Vaak wordt ook een ander tegelpatroon gebruikt:

De haltes waar een vlak minder exact in te tekenen valt zijn in de minderheid bij mij in de buurt.

1 Like

Voor mij is de halte de haltepaal met het bord erop waar de haltenaam op staat en informatie over welke bussen daar rijden.

Of vergelijkbaar. Het bord mag hangen, het mag een display zijn, of een zuil, of een stoeptegel met opdruk.

De rest is bijkomende voorzieningen.

Een hoge stoeprand is een in-en uitstapvoorziening bij de halte. Kan er zijn maar dat hoeft niet persee.

Wachten doe je in een shelter, op een bankje, of op een perron, als dat er is, en anders heb je gewoon de stoep of een grasveldje met een boomstam.
Stop_position op de weg is eigenlijk dubbelop voor rendering, maar maakt de halte makkelijker beschikbaar voor navigatietoepassingen. Doen we wel vaker, dubbelop mappen voor verschillende toepassingen.

Het nieuwe systeem is een stuk lastiger en wordt, krijg ik de indruk, na 15 jaar nog steeds maar door een deel van de mappers en toepassingen ondersteund. Misschien is het gewoon te hoog gegrepen.

In dit geval zou ik, als ik renderer was, het oude systeem zowizo blijven ondersteunen. Een halte staat dan naast de weg, niet erop. Daarnaast is het een afweging of het nieuwe systeem óók ondersteund moet worden, en welke delen dan, voor de betreffende toepassing.

1 Like

Ik vond deze site in de General Talk die misschien handig is om te noemen in deze discussie

https://gauss.whz.de/ptsa/#8/52.236/4.815

Deze laat o.a. de verdeling zien van haltes met wel/niet haltepaal, stoppositie en platform getagd.
Ik vind het zelf onlogisch om meerdere categorieën dezelfde kleur te geven, dus heb dat in het script aangepast.

Voor Nederland ziet het er op het moment zo uit:


Hier is:
rood - enkel stoppositie
groen - enkel haltepaal
blauw - enkel platform
geel - stoppositie en haltepaal
cyaan - haltepaal en platform
magenta - stoppositie en platform
wit - stoppositie, haltepaal en platform

In landelijk gebied dus vooral groen; alleen de haltepaal.
In Regio Arnhem Nijmegen, Tilburg, Leeuwarden en Groningen daarbij ook nog een platform (cyaan).
In Den Bosch en om de Randstad haltepaal en stoppositie (geel)
In de randsteden zelf wordt vaak wel stoppositie en platform getagd. (magenta en wit)

Dus het lijkt me goed om in deze discussie ervan bewust te zijn dat jouw en andermans idee van wat gebruikelijk is in Nederland heel erg kan afhangen van waar in Nederland je bent.

3 Likes

Er is een nieuwe link: https://ptsa.io.informatik.htw-dresden.de/

1 Like