Naar aanleiding van deze note over een toen nog te bouwen brug heb ik door steekproefsgewijs te willen checken en info gelezen in de bewuste note dat buslijn 8 van Arriva nu over de bewuste in gebruik genomen brug rijdt.
In een poging om info op te diepen hoe deze buslijn dan nu precies rijdt (waar ik nu nog steeds niet achter ben gekomen) kwam ik wel rare relatie’s (als in: niet meer bestaande buslijnen op een van die bushalte’s tegen die buslijn 8 aan doet) tegen.
Als je de actuele bushalte info kwa buslijnen ziet
dan rijdt daar blijkbaar alleen buslijn 8 & 50 dit terwijl in OSM er relaties aangegeven zijn van buslijn 210 ?
Is er een manier om heel snel te kunnen checken of de buslijn relatie’s nog wel actueel zijn anders dan steekproefsgewijs op bushalte niveau te checken zoals ik gedaan heb middels de key website= ?
Zo ja, is er een automatische manier om de juiste buslijn relatie’s op de halte’s te laten weergeven ?
Graag jullie expertise, tips & op- en aanmerkingen.
Edit: screendump toevoeging ter verduidelijking Edit2: eerste link verwijzing werkte niet goed dit gecorrigeerd
I wrote and maintain the PTNA tool which provides both types information of interest
what is mapped in OSM
what can be seen in reality (by using GTFS data)
… and (since few months now) a (more or less manual) comparison between both.
For the Netherlands, I started configuring the analysis of OSM data for the different “authorities” in the various regions of the Netherlands but did not complete that task. So, maybe your region “Leiden” is or is not yet covered by PTNA for NL.
Kindly let me know whether your region of interest is already covered by PTNA or not. If not, I can configure that within some minutes - just have to increase its priority in my to-do-list.
Lijn 210 is in het corona tijdperk (tijdelijk ? ) opgeheven.
In de verwachting dat na corona de lijnen weer in gebruik zouden worden genomen, werden deze buslijnen voorzien van disused:route.
Die lijnen zijn nog wel aanwezig in de database maar worden door een renderer niet getoond op een kaart.
Als ik bij toeval zo een lijn tegenkom ga ik meestal over tot verwijdering uit de databse. Maar zo een lijn kan nog steeds terugkomen, soms onder een ander lijn nummer en dan kun je de oude route goed gebruiken.
Tja en verder is het een kwestie van teveel buslijnen en te weinig mappers die zich daar mee bezighouden.
Persoonlijk concentreer ik mij meer op het repareren van gebroken route relaties (bus en trein) en het bijhouden van een paar concessies.
Bedankt voor je reactie Leo !
We doen met zijn alle wat we kunnen & misschien vormt het initiatief wat je vermeld in combi met ToniE’s oplossing de definitieve oplossing ?
Ik ga in ieder geval met de links aan de slag, bedankt voor jullie posts !
Ik ben aan het experimenteren met een controle script op basis van de NeTeX gegevens die de meeste OV bedrijven aanleveren. NeTeX is een nieuwe standaard dan GTFS.
Voor bus 8 richting Oegstgeest ontbreekt volgens deze controle de ref:IFOPT code van halte ‘Jachthaven Poelgeest’ in de OSM route. Daarnaast zou de vertrekhalte van Leiden Centraal niet NL:Q:54447310 (E) moeten zijn, maar NL:Q:54447110 (G). Dit wordt bevestigd door qr-arriva.nl en 9292.nl.
Naar de exacte routes tussen de haltes kijkt het controlescript nog niet. Dat wordt een volgende stap als de haltes in de routes kloppen. Als iemand een OSM routing dienst kent die busroutes ondersteunt, houd ik me aanbevolen .
Tot nu toe heb ik Groningen, Drenthe en Friesland grotendeels gecontroleerd en waar nodig hersteld. Nu ook begonnen met de provincie van de maand (Limburg), maar de prioriteit ligt nu even bij het installeren van een snellere computer, waarmee ik beter up-to-date kan blijven met de wijzigingen in OSM, NeTeX en het CHB (Centraal haltebestand). Online beschikbaar stellen van de bevindingen wordt nog een volgende uitdaging.
Ik heb hier ooit ook wel eens naar gekeken (voor Osmose, met de data van NDOV Loket - Data), maar toen viel ik erover dat er vaak nog oude haltes e.d. in stonden (~ruim half jaar geleden opgeheven etc), waardoor ik dat niet live durfde te zetten. (Want dan kijkt iemand met de PDOK foto’s van 2023 en ziet dat dat die data overeenkomt met de luchtfoto’s van een jaar geleden, en loop je dus risico dat de oude situatie teruggezet wordt)
Zo zou er hier nog steeds een bushalte zijn volgens die data: 2600652,,"Nijmegen, Havenweg",51.849418,5.850047,0,,,1,
Maar die is toch al een jaartje weg en de hele wegindeling is tegenwoordig anders.
Ja dat is balen, je kan dat denk ik alleen tegen gaan door infrastructuur wijzigingsprojecten ver voor dat ze plaatsvinden al middels een future note aan te merken, info wijzigingen hier in op te nemen en op het moment dat de infrastructuur wijzigingen hebben plaatsgevonden alle verzamelde info hier in OSM te verwerken.
Daarom kijk ik alleen naar haltes die in een route zijn opgenomen. Alleen haltes die in een route zitten maar ontbreken in OSM voeg ik toe. Haltes die in OSM staan, maar niet in een route zitten verwijder ik niet meteen, omdat de halte fysiek nog wel kan bestaan.
Is het een idee om korte buslijnen als eerste als pilot op te nemen zodat scripts via die lijnen getest kunnen worden op goede werking en dan steeds grotere buslijnen met meer interactie toevoegen om vervolgens daar het script weer mee te testen en te verbeteren ?
Mijn ervaring tot nu toe is dat het het beste werkt om per concessiegebied (network in OSM) te controleren. Een foutje met een halte komt vaak in meerdere routes in het zelfde gebied terug. Ook komen routewijzigingen vaak in meerdere routes in het zelfde gebied terug.
Die vraag is simpel te beantwoorden.
er is maar 1 bron en dat is de vervoersmaatschappij.
OV in Nederland Wiki staat op hetzelfde niveau als OSM :
Goed willende vrijwilligers proberen de wiki en OSM zo goed mogelijk actueel te houden en soms zijn dat zelfs dezelfde personen.
De route van lijn 8 in OSM stemt overeen met de dienstregeling. ArrReisInfo (fis.nl)
De informatie die connexxion laat zien is dus verouderd.
Connexxion dus alleen raadplegen voor haar eigen lijnen net.
En daar maakt lijn 8 geen deel van uit.
Dat is nu juist het punt: de info die Connexxion laat zien is precies het zelfde kwa route als wat Arriva laat zien en gaat kwa route niet over de pas operationeel zijnde Heemparkbrug…
Zie onderstaand screendump kaartje van buslijn8 van Arriva website
En kan daardoor halte Jachthaven Poelgeest nooit bereiken die wel in de dienstregeling van Arriva vermeld staat… zie 2de screendump van Arriva website.
Wat Connexxion dan nog op Arriva voor heeft is live time arrival info en (lerend uit Houtplein Haarlem project) info over uitval van haltes op een route door tijdelijke infrastructuur veranderingsprojecten op een bepaald traject.
Omdat de info van Arriva en Connexxion op deze buslijn 8 kwa route hetzelfde is heb ik daarom de bushalte info die ik bij Connexxion kon opdiepen laten tonen.
Conclusie: de initiatieven die Gertjan_Idema, Famlam & ToniE opgestart hebben zijn zeer nodig & nuttig omdat op halte niveau daar waar op halte’s meerdere vervoersaanbieders reizigers laten overstappen het zo maar kan zijn dat:
overstappen bij die halte niet meer mogelijk is omdat de buslijn kwa route veranderd is. En elke vervoerder zich kwa digitale info voorziening zich alleen bezighoud met zijn scope met als gevolg een grijze mistige infowolk die de reiziger dan maar zelf op moet lossen.
Route info en bushalte info (nog) niet synchroon lopen zie het Arriva voorbeeld wat ik met 2 screendumps heb geprobeerd inzichtelijk te maken.
Gertjan_Idema, Famlam & ToniE is er een mogelijkheid om de koppen bij elkaar te steken en van de initiatieven 1 groot inclusief werkend project te maken ?
Edit: typo correctie synchroom —> synchroon Edit2: tekst toegevoegd: “Gertjan_Idema, Famlam & ToniE is er een mogelijkheid om de koppen bij elkaar te steken en van de initiatieven 1 groot inclusief werkend project te maken ?”
Ik denk dat dit op korte termijn te hoog gegrepen is. ToniE heeft gekozen voor GTFS-data als bron omdat dit in theorie een wereldwijde standaard is. Ik heb gekozen voor NeTeX, omdat ik met GTFS in Nederland tegen te veel beperkingen aan liep. NeTex is een nieuwere Europese standaard die in opzet een stuk krachtiger en uitgebreider is dan GTFS. Het wisselt echter per land hoever men hier mee is. Nederland is behoorlijk ver. Op een paar kleine taxicentrales na is de routeinformatie compleet en actueel. Het zou me niets verbazen als op termijn geen GTFS data meer wordt aangeboden. Voor een wereldwijde oplossing is NeTeX echter niet geschikt.
Op dit moment is mijn oplossing zelfs alleen in Nederland bruikbaar, omdat in Nederland de NeTeX data gekoppeld is met het Centrale haltebestand (CHB) dat voor zover ik weet een specifieke nederlandse contructie is.
Yes, sure, we can do that. I’ll be away from my PC for the rest of June but will read and can write here.
As @Gertjan_Idema mentioned, NeTeX is a newer and a more exhaustive standard than GTFS but a European Standard. I did not yet dig into the details of NeTeX, there are so many other tasks on the to-do-list:
comparison of GTFS with OSM on an interactive basis in the browser is nearly finished, documentation (a How-To) is missing though.
same type of comparison shall be implemented for the daily analysis runs, reporting the “mismatch scores” for the OSM routes.
yeah, and whilst writing this, my PC crashed again: have to buy new HW, assemble that and install the OS again.
So, I keep NeTeX in mind but cannot invest much work on that.
.
