Buslijnen, halteinfo, OV-routes - overzicht en discussie

Hier gaat het dan fout, die paal/bord, staat waar hij staat, dat is veelal niet de hierboven omschreven plaats.
Je doet dit niet voor de render, maar omdat het zo is in Nederland.
Gevolg is dat andere deze node gaan loskoppelen en op zijn plaats zetten.

De stop_position is belangrijker dan je in eerste instantie zou denken en is niet voor niets opgenomen in PT_v2. Bijvoorbeeld om softwarematig de volgorde van de haltes in een route te kunnen controleren, of zelfs automatisch de haltes in de goede volgorde te kunnen. Zonder stop_position wordt dit een stuk bewerkelijker en daardoor trager. Dit omdat je eerst geografisch moet uitzoeken welke stukjes weg uit een route in de buurt van een halte liggen. De stop_positions zijn rechtstreeks verbonden met de stukjes weg uit de route. Met stop_positions is het dus een stuk simpeler om softwarematig de route van het beginpunt tot het eindpunt door te lopen en te kijken of de volgorde waarin je stops tegen komt overeen komt met de volgorde in de route relatie.
Als je haltes in de juiste volgorde staan en de REF:IFOPT codes van de haltes overeenkomen met de codes in een NDOV route bestand, kan er redelijk op vertrouwen dat je route klopt en actueel is.

  1. Ik ben hier mee bezig geweest, maar het is nog best een uitdaging. Vooral omdat het niet eenvoudig te bepalen is welke NDOV halte bij welke OSM halte hoort. De NDOV lokatie is te onbetrouwbaar. De windrichting klopt wel vaak ongeveer, maar dan moet je nog de windrichting van de osm halte bepalen. Niet onmogelijk, maar best wat uitzoekwerk.
  2. Mij gaat het er in eerste instantie om, om de REF:IFOPT tags toe te voegen aan bestaande haltes in osm. Als je die hebt, kan je osm routes vergelijken met NDOV routes en kom je er vanzelf achter of er haltes in OSM ontbreken, of in geen enkele route voor komen.

Ik zie steeds een soort ‘primaire node’ waarop in PTv1 de highway=bus_stop op stond en een ‘secundaire node’. In PTv2 is dan de primaire node het platform en de secundaire node de stop_position. De primaire node krijgt voor compatibiliteit nog steeds de highway=bus_stop en hier worden ook de belangrijke haltetags, zoals ref:ifopt aan toegevoegd. Bij het idee om het platform alleen als area te taggen, zit je dus met het probleem waar je die haltetags laat.

Bij trams werken de primaire en secundaire node juist andersom. Daar is de primaire node de stop_position i.p.v. het platform en heeft deze node de railway=tram_stop. Dit lijkt me een onhandig verschil. Waarom zou je dit bij trams omdraaien t.o.v. bussen?

Verder valt me ook de ‘name=plaatsnaam, haltenaam’ vs ‘name=haltenaam’ op. Ik zag dat SintE7 dat in zijn grote opschoonactie (goed werk overigens :)) zo toepast:

  • platform: name=haltenaam (‘primaire node’, die wordt gerenderd)
  • stop_position: name=plaatsnaam, haltenaam (‘secundaire node’)
    Op deze manier zie je dus alleen de haltenaam op de standaardkaart. Ik heb dat overgenomen, maar ik begin er nu toch over te twijfelen. Ten eerste hebben zo de platform en stop_position zo verschillende namen en zijn ze lastig automatisch als onderdeel van dezelfde halte te zien. Ten tweede is dit niet toepasbaar op tramhaltes, waar juist de stop_position de primaire node is. De plaatsnaam, haltenaam die niet overeenkomt met het haltebord, wordt dan gerenderd. De rendering van de tramhaltes is dan ook niet consistent met die van de bushaltes.

Een taggingschema placename=plaatsnaam en name=haltenaam voor zowel platform als stop_position lijkt me een betere tagging. Dat placename=* niet in PTv2 voorkomt, hoeft geen probleem te zijn. We kunnen afspreken dat we de placename-tag op deze manier in Nederland gebruiken.

Wat eventueel ook kan is de stop_position geen naam meer mee te geven en dan verder zoals hierboven genoemd. Dan ben je meteen ook af, van de ongelijkheid tussen haltenaam en stop_position.

Heeft dat een voordeel boven het gebruiken van alleen de haltenaam voor de stop_position? De enige reden dat er verschil is tussen de haltenaam en de naam van de stop_position, is de wens om de plaatsnaam ergens op te nemen. Als je de stop_position geen naam geeft, dan is die reden er niet meer.

Ik zie de volgende redenen om de stop_position in ieder geval met naam te taggen:

  • Het is duidelijker welk platform bij welke stop_position hoort.
  • Het opnemen van plaforms en stop_positions in de routerelatie zorgt ervoor dat de sortering van haltes snel gecontroleerd kan worden, zoals Gertjan Idema aangeeft.
  • Een renderer kan consistenter bushaltes en tramhaltes renderen, bijvoorbeeld bij beide het icoontje op de weg (stop_position, zoals tramhalte in OSM-carto) of beide het icoontje naast de weg (platform, zoals bushalte in OSM-carto)

Heeft de stop_position eigenlijk ook geen ref:ifopt-code, die als tag kan worden toegevoegd?

Het is inderdaad niet altijd 100% duidelijk. De windrichting is een goede hint, maar die klopt niet altijd (95% toch wel). De locatie is ook een goede hint, die klopt ook niet altijd, maar meestal kun je aan de positie van de twee haltes wel zien welke waar hoort (soms zijn ze gewoon allebei verplaatst, maar soms liggen ze ook op elkaar) en als laatste kun je bij veel concessiehouders in de routeinformatie zien bij welke halte met welke ifopt hij stopt.
Bij Connexxion (en al hun dochters) kun je per lijn de haltes zien en als je met de muis over de halte gaat staat onderin de ifopt ref.
Bij Syntus (en al hun dochters) is er een reisplanner (met OSM kaart als achtergrond) waar je ook op halte kunt zoeken en je de ifopt kunt zien.
Ook bij Arriva kun je op lijn zoeken en is in de link van een halte de ifopt ref te vinden.

Als 9292 dit nu ook nog eens zou doen…

Die gedachte zul je toch los moeten laten. De node met highway=bus_stop heeft geen enkele relatie tot de plaats van de paal/bord.
Paal/bord vervult in PTv2 geen enkele rol !
highway=bus_stop duidt slechts de plaats waar de reiziger wacht. (De Engelsen doen dat netjes in de rij, Nederlanders vechten zich een weg naar binnen. :wink:

Aan de andere kant, als die node wordt losgekoppeld, is er in feite niets beschadigd en dan zouden we dat zo kunnen laten.

Ik laat even weten dat ik de hele ombouw van de Amstelveenlijn al voorbereid heb, morgenavond alleen even uploaden.

Dus metro 51 naar Isolatorweg, alle tramsporen ten zuiden van Amstelveen Centrum op construction, het verwijderen van de “station”-node op de tramstation, het toevoegen van buslijnen 55 en 551, en het algemeen opschonen van de stations en lijnen rond Station Zuid.

Ik kwam toevallig bij R-NET bus 397 uit, https://www.openstreetmap.org/relation/906385 en ik heb toch wel een probleem met hoe dit gemapt is. Zo zijn er vrijwel nergens nodes voor de platforms getagd en daardoor zijn haltes op de algemene OSM kaart en op de transport kaart niet terug te vinden. Niet visueel maar ook niet bij de search.
Jaja, niet taggen voor de renderer, ik weet het, maar ik vind dit toch een goed voorbeeld waarom je wel zodanig moet taggen dat iets zichtbaar en vindbaar wordt.
Of is dat een vreemde gedachte?

OSM kent bijvoorbeeld geen halte P+R Getsewoud Zuid terwijl de halte Laan van Berlioz wel gevonden en getoond wordt.

Je hebt volkomen gelijk.
Als je het toevallig tegenkomt, kun je aan alle platforms op een node highway=bus_stop toevoegen.

Met het risico dat de oorspronkelijke mapper het weer weg haalt :frowning:

Als ik in een route een enkele afwijking tegenkom, zal ik het wel veranderen.
Als een route één geheel vormt zoals in de concessie AML en in Zeeland (alleen stop_positions) zal ik er niets aan veranderen.
Als een routerelatie een mengelmoesje is van vier verschillende methodes, krijg ik toch de neiging om het uniform te maken.

  1. Ten eerste is de Laan van Berlioz geen halte voor lijn 397, en komt ze niet in het CHB voor. Volgens mij is de halte voor het laatst op 9 december 2017 door lijn 162 gebruikt. Dus is het voor geen enkele lijn een halte. Ik heb de halte uit de route-relatie 379 gehaald.

  2. de nodes voor de platforms zijn géén concept uit PT_v2 en is écht taggen voor de renderer. Ik heb juist gepoogd de hele concessie AML zo PT_v2-mogelijk te maken. Daarbij heb ik niet expres highway=bus-stop weggehaald, maar waar ik highway=platform als lijnelement heb toegevoegd, heb ik géén highway=bus_stop toegevoegd. Maar op bijv OSMAND worden deze haltes prima getoond!

  3. Het blijkt dat support voor het renderen van public_transport=platform er voorlopig niet komt. Het issue op github is 2 dagen geleden gesloten. https://github.com/gravitystorm/openstreetmap-carto/pull/3232

Kennelijk is de OSM-community niet in staat om met zichzelf een afspraak te maken hoe we iets doen en daar dan mee verder gaan.
Dit is echt een fout in de community, bij Wikipedia was dat véél duidelijker geregeld.
Daar was het mantra “voel je vrij en ga je gang” maar je moest je wél aan de regels houden die we samen hebben opgesteld.
Hier is het “hou je alsjeblieft aan de wiki” maar iedereen, ook niet-beginners, doet maar wat omdat ze het niet eens zijn met de wiki.
(dat gaat niet alleen over OV, ik zie het vaker)

Ik zie AML echt een beetje als mijn “kindje” omdat ik de héle concessie ingetekend heb volgens PT_v2 (een pokkewerk, waar ik dagen aan gezeten heb) en ik heb er alleen maar tegenwerking en negatief commentaar over gehad. En nee, ik ben zéker niet de eigenaar van AML, alles is hier van iedereen op OSM, maar als mensen op basis van inzichten die niet stroken met de wiki een boel werk gaan zitten aanpassen ben ik er klaar mee.

Ter geruststelling:

Daar ben ik het niet mee eens. In het proposal voor PT v2 staat

Toegegeven, hier zal wel een platform zijn, maar zeggen dat een node voor een platform niet in PT v2 thuis hoort is incorrect.
highway=bus_stop wordt daar inderdaad niet genoemd maar is ook geen deprecated tagging.

Maar niet op de osm kaart, niet op de public transport kaart en ze worden niet in nominatim meegenomen. In zoverre heb ik er een probleem mee. Hypercorrect zijn en daarmee een niet-werkende situatie creëeren is ook niet gewenst.

Dat is ook een probleem en ik ga me ook niet vermoeien om dit in de renderer te krijgen. Je kunt die hele draad lezen en er zijn mensen die gewoon het standpunt hebben “ik ben het niet met PT v2 eens dus het gaat niet gebeuren”.

Ik vind de oogkleppenhouding “dit is de wiki en zo moet het” niet constructief als dat er voor zorgt dat op een zeer belangrijke plek bushaltes niet zichtbaar of vindbaar zijn. Dan vind ik dat de praktijk belangrijker is. Ik zie niet waarom het een probleem kan zijn om bijvoorbeeld de node op het eind van een platform way met highway=bus_stop en van verdere noodzakelijke tags te voorzien. Daarmee maak je bushaltes zichtbaar en vindbaar. Of je ze dan wel of niet in de busrelatie opneemt maakt me dan niet uit.

We hebben allebei gelijk, maar ik heb mij ongelukkig uitgedrukt. Volgens PTv2 mag je een public_transport=platform maken en dat mag een node/way/area zijn. Zoals mij eerder in deze discussie werd, voegen sommigen aan de pt=platform way/area nog een node highway=bus_stop aan toe, om de bushalte op osm_carto gerenderd te krijgen. Ik bedoelde dat een (extra) hw=bus_stop node geen onderdeel van PTv2 is.

Tsja, OSM_carto is niet de enige renderer! Op OSMAND werkt het prima, op Openbusmap werkt het prima…
Het is ook niet een obscuur taggingschema’tje dat ik aanhou. Het is iets waar in 2011 over gestemd is en waar 83 tegen 6 vóór gestemd hebben. Bovendien is het ruim 200000 keer gebruikt als way/area en nog eens ruim een miljoen keer als node.

En dat is inderdaad een jammer ding van de community. Ik zie ook weinig bezwaren die objectief waar zijn in die discussie, als we rendering support zouden hebben voor public_transport=platform.
Ik heb helaas zelf niet de skills zelf iets te programmeren hiervoor. Maar ik vind het jammer dat een door de community gesteund iets om zo’n flauwe reden niet in de renderer komt (de tweede reden, tijdgebrek, is uiteraard wel legitiem).

Tsja, de reden is dat je dan voor de renderer tagt én dubbeltagt, iets wat juist zo veel mogelijk voorkomen moet worden.
En een kleine achterliggende reden is dat ik hoop dat zo veel mogelijk volgens PTv2 taggen, voor een beetje druk zorgt om tóch werk te maken van rendering * in osm_carto* :wink:

Merk trouwens op dat in de concessie Noord-Holland Noord, waar ik óók alle lijnen sinds de concessiewissel goed heb gezet, veel minder rigoreus te werk ben gegaan. De opbouw van routes en route_masters is helemaal PTv2, maar de haltes veel minder. Bijgevolg zijn er lijnen (zoals lijn 163 waar haltes in voorkomen volgens PTv2 (bijv Metiusgracht), als highway=bus_stop náást de weg (bijv Kanaalweg) of als public_transport=stop_position óp de weg (bijv N.G. Piersonstraat). Wel heb ik de echt foute tagging (highway=bus_stop óp de weg) overal vervangen door public_transport=stop_position en alle bestaande highway=bus_stop gedubbeltagd met public_transport=platform of stop_position.

Ik ben hier dus veel pragmatischer in gaan zitten, zowel qua hoeveelheid werk als qua hertaggen. De enige haltes die geen highway=bus_stop hebben zijn haltes die helemaal nieuw zijn, daarnaast zullen er een aantal niet gerenderd worden omdat ze op een way of area staan.

Je zegt hier zelf “zo veel mogelijk”. Dat is wat anders dan “ten allen tijde”. Ik vind dat zolang de algemene kaart dergelijke zaken niet rendert en nominatim de zaken niet vindt, je niet richting het “ten allen tijde” standpunt moet gaan en meer pragmatisch er mee om moet gaan. Dat is voor alle toepassingen beter.

Het bovenstaande lezende, durf ik bijna geen buslijn meer in te voeren. :slight_smile:
Voelt iemand zich geroepen om lijn 44 [Vianen-Houten] in te voeren?
https://uov-prod.cdn.prismic.io/uov-prod%2Ff30d5082-b4bf-4a14-a930-db62e520cd41_u043-u044-122018-web.pdf
of
http://wiki.ovinnederland.nl/wiki/Lijn_44_Houten_Station_-_Vianen_Hotel

Veel dank.

Oké, dan ga ik aan de slag met lijn 44.

Ze staan er alle 4 in
(met highway=bus_stop en public_transport=platform
en zonder stop_position en stop_area )
:sunglasses::slight_smile:

Ik zag net bij het mappen in Leeuwarden dat één van de buslijnen die over de Tesselschadestraat loopt verkeerd om lijkt te liggen:

Lijn 170 van Leeuwarden naar Minnertsga

Ziet iemand kans om eens te kijken waarom die net als zijn tegenroute van Minnertsga naar Leeuwarden gaat in plaats van andersom?

De lijn op de website van Arriva.

Jeroen, de route van lijn 170 naar Minnertsga stond inderdaad verkeerd om. Daarnaast klopte de route door Leeuwarden niet, ook voor de andere richting. Lijn 70 gaat via Tesselschadestraat en Heliconweg maar lijn 170 via Snekertrekweg, Marshallweg en Slauerhoffweg, aldus de dienstregeling. Ik heb beide zaken aangepast.