Om te voorkomen dat het topic dat @Allroads begon wordt gekaapt om een heel andere discussie te gaan voeren, start ik hier een nieuw onderwerp met het verzoek om alle algemene OV-zaken (zoals blijkt uit de titel) hier weer op te pakken.
Lees, om weer even bij te raken, vooral ook deze eerdere discussie en uiteraard de hierboven genoemde, om te weten wat er speelt en welke standpunten er worden ingenomen
Volgens mij hebben we nu twee dingen:
1. in OSM hebben we de routes die het OV rijdt in de vorm van relaties opgeslagen 2. in OSM hebben we de halteplaatsen van de bussen dmv. een highway=bus_stop tag opgeslagen op een node.
Zowel 1 als 2 zijn onvolledig, onbetrouwbaar en verouderd omdat ze op beperkte wijze (of niet) worden ondersteund door de informatie die afkomstig is van de ov-bedrijven. Veel hangt daardoor af van de wijze waarop de individuele mapper in staat is om aan de juiste gegevens te komen en deze op de juiste wijze op te slaan. Dat is op zich al een lastig punt omdat er in feite nog geen duidelijk afspraak is gemaakt over hoe dat dan moet gebeuren.
Bushaltes veranderen van plaats, eens in de zoveel tijd rijdt er weer een andere maatschappij en ook de routes worden regelmatig (soms tijdelijk) veranderd.
Voor een OV gebruiker is OSM daardoor een volstrekt onbruikbaar middel om iets zinnigs over het OV aan de weet te komen. Het is heel goed mogelijk dat de bushalte die je op die kaart ziet staan al twee jaar geleden is opgeheven.
Uit de eerdere discussie is gebleken dat er een bestand bestaat (bij het NDOV loket) waarin alle halteinformatie is opgeslagen en deze informatie is onafhankelijk van de busmaatschappijen. Als ik het goed begrijp betekent dat dus, dat als er een andere busmaatschappij gaat rijden, het haltepaalnummer onveranderd blijft. Busmaatschappijen moeten dus datzelfde haltepaalnummer blijven gebruiken. Dat is een belangrijk gegeven, want dat betekent ook dat we, als we die haltepalen op de juiste wijze invoeren ook de informatie die de busmaatschappijen in real-time over die palen doorgeeft (vertrektijden, vertragingen) altijd kunnen opvragen. Voorbeelden daarvan zijn in die eerdere discussies te zien.
Voor een kaartgebruiker die het OV wil zien op de kaart is het belangrijk dat hij de halte’s weet te vinden. In openpoimap heb ik dat ook standaard opgenomen. En als daarbij ook de detailinformatie van die haltepaal kan worden doorgeven (op veel halte’s zie je nu al een QR code die je kunt scannen voor meer info) dan is dat mooi meegenomen. Het is niet de bedoeling (en ik heb ook niet die illusie) dat OSM een soort routeplanner voor het OV gaat worden. Hier leg ik ook al uit waarom ik daar niet in geloof.
Maar ik vind het wel belangrijk dat die haltepalen dus goed op de kaart staan. En of we dan alsnog die vervolgdata gaan gebruiken is vooral een taak voor de ontwikkelaars van apps en tools.
Mijn vraag is nu dan ook vooral of er concreet mogelijkheden zijn om de beschikbare informatie (over die haltepalen) te gaan importeren in OSM zodat in ieder geval de basis aanwezig is voor verdere ontwikkelingen.
Belangrijk is natuurlijk dat voor deze import duidelijk afspraken worden gemaakt en dat er dan ook vervolgstappen worden gezet.
Ik denk dat ook vermeld moet worden dat er een approved Public Transport Scheme is, zie oa http://wiki.openstreetmap.org/wiki/Public_transport en dat veel of alle haltepalen in Nederland daar niet aan voldoen. Men wil af van highway=busstop
Alleen is dat schema tamelijk uitgebreid en ingewikkeld.
En de vraag is of we daar wat mee moeten
Zeker is het mogelijk om dat te importeren.
Ik heb al redelijk goed in mijn hoofd hoe dat moet. Ik heb het afgelopen half jaar echter nog geen tijd gevonden om dat te doen.
Als iemand die tijd en zin heeft om dat te programmeren maar het concept van de bushaltedata (en andere OV-data) nog niet snapt wil ik daar graag over uitweiden.
Overigens was mijn idee om een soort van script te maken dat de data uit NDOV inleest, de bestaande data van OSM inleest en dan kijkt welke verschillen er zijn, waarna gebruikers handmatig de aanpassingen door moeten voeren - toch veiliger dan ruwe import van data lijkt me.
Ik heb mij bij het NDOV aangemeld en heb vandaag het CHB bestand gedownload. Ik moet eerst even doorgronden wat daar allemaal instaat, en enige hulp en toelichting van jouw kant zou wel helpen!
Wat ik dan als eerste wilde doen is om hier in Vught een vergelijking maken tussen de situatie die er op OSM is en de situatie zoals die in het CHB staat beschreven. Daarna - rekening houdend met nieuwe inzichten op het gebied van OV zoals hier beschreven - aanpassen waar nodig.
Maar enig overleg en discussie hier lijkt me ook voor anderen die deze zaak op willen pakken handig.
Ik zie steeds dat de haltepaal in de ene richting de NL:Q code meekrijgt, en de andere paal de NL:S code.
Zoals ik de discussie tot nu tot heb begrepen zou je voor één halteplaats (met dus per richting één haltepaal) één stopplacecode moeten hebben, én twee haltecodes. Dat blijkt in Vught dus al niet te kloppen.
Ik zou dus de eerste halte (met dus 2 haltepalen) in mijn lijstje zó moeten taggen:
Klopt mijn redenering en het gebruik van de codes op deze manier?
Als ik het zo doe, dan kan ik in iedergeval via die 2 codes de actuele halteinformatie opvragen via deze link.
Maar ik kan ook bij Arriva dit opvragen.
Ik heb inmiddels een script waarmee ik uit het CHB per stad een lijst kan genereren van de aanwezige haltes, dus als iemand voor “zijn/haar” stad zo’n lijst wil…
Na wat onderzoek naar het aantal keer dat we (in Nederland) een bushalte zowel met highway=bus_stop als public_transport=stop_position hebben getagd, zoals hier:
Kom ik uit op 5870 keer:
Duidelijk is dat dat in de randstad het vaakst voorkomt.
Feitelijk zouden deze (minimaal) moeten worden omgetagd naar: public_transport=stop_position bus=yes
Ik zeg “minimaal”, want public_transport=stop_position moet feitelijk op de rijbaan worden geplaatst, daar waar de bus tot stilstand komt.
Daarna zou dan moeten worden toegevoegd public_transport=platform (en eventueel area=yes indien er echt meer is dan alleen een haltepaal). En dit laatste dan voor iedere haltepaal (dwz. in iedere richting een).
Dan zouden we vervolgens alle bushaltes waar alleen maar highway=bus_stop staat ook nog onderhanden moeten nemen.
Er zijn ongeveer 45000 bushaltes in Nederland…
Ik zie nog niet precies welke strategie het beste is om dit probleem te lijf te gaan.
ref Reference The reference by which the platform is known. recommended if no public_transport=stop_area exists or differs, else optional
De IFOPT toevoeging zouden we dus ook gewoon weg kunnen laten. Bij een gemiddelde stop_area met bushaltes in 2 richtingen krijg je dan:
2x: node of way (naast de weg)
Maar zoals je uit mijn voorbeeld kunt zien is er steeds maar één NL:Q code gegeven en ik kan niet twee keer diezelfde code gebruiken. Althans dat wordt in Vught dus niet gedaan. Eén haltepaal heeft de NL:Q code, de andere paal heeft de NL:S code.
Wie doet daar dan iets fout? Of mag die NL:S code ook gebruikt worden als NL:Q code?
Ik heb zelfs plaatsen gezien waar de NL:Q code en de NL:S code identiek zijn. Dan is er klaarblijkelijk maar één haltepaal.
Kunnen meelezers even checken hoe de haltepalen (in je eigen buurt) zijn genummerd en dat hier weer laten weten?
Het verwarrende zit in het feit dat er maar één fysieke lokatie wordt gegeven (rd-x en rd-y) maar dat er twéé haltepalen zijn. Die coordinaten komen ook niet overeen met de werkelijke positie! Eén haltepaal heeft de code die bij de stopplacecode wordt genoemd (de NL:S code) en de andere paal heeft de code die bij haltecode wordt genoemd.
Is er een OV data-expert die dat kan toelichten?
(*) Als deze link niet werkt komt dat omdat je moet inloggen. In dat geval zelf aanmelden bij het NDOV loket.
De twijfel over het nut van de RD-coordinaten neemt toe. Ik heb via deze website van een aantal punten in Vught de plaats opgezocht waar de bushaltes zouden moeten liggen.
Het gaat om deze:
straat : Boslaan
haltenaam : De IJzeren Man
stopplacecode: NL:S:62110300
haltecode : NL:Q:62117110
rd-x : 146169
rd-y : 407301
Op basis van AHN2 hoogtebestand hillshade kan je de haltepalen met enig inzicht precies plaatsen waar ze ook werkelijk staan.
Heb hier via jou link ook een omrekening gedaan, nu nog in vergelijk met de door ons getekende haltepaal op osm map en niet van die site kaart G variant haltepalen, welke niet goed liggen.
De waarschuwing over de routeversie is iets waar inderdaad aan gewerkt moet worden. Het is echter geen garantie dat de lijn wel of niet up-to-date is. In principe zou je nooit public_transport:version=1 ergens aan toe moeten voegen - die versie bestaat namelijk niet. Je hebt “legacy” (oud) en public_trasport:version=2. Dit voeg je toe aan de routes. Waar het “oud” uit bestaat is mij echter niet helemaal duidelijk.
Het “incompleet” betekent alleen dat je niet alle elementen van een busroute hebt gedownload.
Een Stopplace in dit XML-bestand is wat in het OSM Public_transport schema een stop_area is. De code die hieraanhangt is NL:S:xxxxyyyy, waarbij xxxxyyyy willekeurig gekozen is uit een van de onderliggende quays.
Een Quay (vertaald: kade) is wat in het OSM Public_transport schema een platform is. De code die heir aanhangt is NL:Q:xxxxyyyy, waarbij xxxx (meestal) het zonenummer is en yyyy een volgnummer.
De OSM public_transport schema stopplace zit niet in dit bestand. Dat zit wel weer in andere NDOV-bestanden, die van de Vervoerders komen, daar zitten ook alle routes in. Maar over het algemeen kan je de stop_position gewoon neerleggen op de dichtstbijzijnde way naast de stopplace.
Ik heb een aantal haltes (al jaren niet gewijzigde en hagelnieuwe) gecontroleerd, en bij beiden liggen de X/Y-coordinaten strak op de haltepaal. Het zijn wel allemaal GVB- en Connexxionhaltes, en ik weet hoe nauwkeurig zij/wij met hun haltebestand omgaan, omdat het ook de basis is voor heel veel meetinformatie.
De coordinaten in de stopplace horen in Nederland exact op de haltepaal te staan. Maar een quay (perron) is veel meer, en zou je dus ook als line of area in kunnen voeren in OSM - dat is vaak ook al gebeurd.
Elke haltepaal heeft een eigen NL:Q:code. In uitzonderlijke gevallen, bij de zogeheten “dijkhaltes” staat er maar één paal voor 2 richtingen, dan zijn er 2 NL:Q:codes op die ene paal. Waar de coordinaten voor de “verkeerde” richting dan staan weet ik niet.
De gegevens in het Centraal Halte Bestand CHB zijn de verantwoordelijkheid van de Concessieverlener - en die hebben de afgelopen jaren allerlei bedrijfjes op pad gestuurd om alle haltes op te meten, het resultaat daarvan is te zien op haltescan.nl. Behalve de informatie die hier bij staat is er ook de lengte, richting, hoogte van het perron, of deze toegankelijk is voor blinden, rolstoelen en of er een hokje is.
Waarom kan er niet één simpel adres (of organisatie) zijn waar we betrouwbaar terecht kunnen?
Ik begin inmiddels te begrijpen waarom het in OV land zo’n zooitje is…
(*)Edit: link naar bestand verwijderd wegens overtreding van de regels.
Ik had niet gezien dat ik het paswoord had meegestuurd en kreeg een waarschuwing van de beheerder.
Maar dat is een XML-bestand met qua indeling hetzelfde als wat ik toonde. Ik denk dat jouw leesprogramma iets verkeerd doet.
Omdat er niet één organisatie verantwoordelijk is voor het OV én omdat het OV niet simpel is! Zo heb ik wel eens gehoord dat er dagelijks zo’n 2 miljoen “pings” uitgestuurd worden door bussen om aan te geven dat ze op een halte aan zijn gekomen of vertrokken. Dat red je niet met een servertje op zolder.
De gegevens komen van een stuk of 20 concessiebeheerders en een stuk of 10 OV-bedrijven af. Die gegevens zijn beschikbaar via “De NDOV-loketten”. De overheid wil graag dat er meerdere loketten zijn. Nu zijn dat 9292 en Stiching OpenGeo. Dan is er ook nog GOVi, dat de actuele reisinformatie voor een groot deel van Nederland verzamelt (vanuit de OV-bedrijven) en dit verspreidt naar apps en de reisinformatiepanelen op de halte. Maar ook 9292 doet dit in een deel van het land, zoals bijvoorbeeld rond Arnhem.
De CHB is maar een heel klein deel van de beschikbare informatie. Wat er ook in zit zijn alle lijnen inclusief varianten, alle dienstregelingtijden, alle actuele tijden, en in de toekomst ook nog alle omleidingen en verstoringen.
En dan nog je vraag over “wie gebruikt die routes”? Nou, mensen zoals ik. Bijna dagelijks. Om te zien waar de dichtstbijzijnde halte is waar ik ben en waar die lijn dan wel heen gaat - dat vind ik vaak makkelijker dan in 9292 een route plannen, en zeker leuker. Maar ik ben het met je eens dat er een zekere onnodigheid zit in het vastleggen van de route. Als reiziger hoef je namelijk niet te weten waar een bus heen rijdt tussen twee haltes in - je hebt er toch niets aan. Alleen als busspotter is het nuttig.
Ohja, het mag bij ons dan allemaal heel complex zijn qua data, je hebt ook het andere uiterste. In het bergdorp in Frankrijk waar ik vaak kom rijden een aantal buslijnen. De rijtijden zijn alleen te vinden op de site van het departement, als PDF’je, uit 2014. Waar de haltes precies zijn is daar niet uit op te maken. Soms zijn er nette haltebordjes, maar ik weet ook ergens waar de “halte” bestaat uit een gelamineerd A4-tje dat op een plankje naast de vuilniscontainers geniet is.
