Buslijnen, halteinfo, OV-routes - overzicht en discussie

Die rotonde te Joure (kruising Geert Knolweg - Sewei) ligt inderdaad vol met buslijnen die ik recent heb bijgewerkt en toegevoegd. Dus pas op hè? :wink:

Voor complexere rotondes met meer dan één rijbaan ben ik wel voorstander van knippen. Voor simpele rotondes (vier aansluitingen, éénbaans) is één sluitende way volgens mij duidelijk genoeg. Je kunt altijd zien welke afslag wordt genomen en dat een draai van meer dan 180 graden nooit nodig is zal iedereen begrijpen. En met ‘iedereen’ bedoel ik dan die enkeling die gebruik maakt van de OV-data in OSM of nog specifieker de kaartweergave van buslijnen… Het is vooral een leuke hobby voor onszelf.
Toegegeven, vanuit esthetisch oogpunt vind ik het verloop van een buslijn over een opgeknipte rotonde wel mooier.

Henk, check deze rotonde eens in JOSM: http://www.openstreetmap.org/#map=19/53.12531/6.08852&layers=N.

Het lijkt erop dat je op 22 januari de rotonde hebt geknipt ten behoeve van lijn 14. Niet in twee of vier delen maar drie. Je hebt blijkbaar wel rekening gehouden met lijn 13 voor de afslag Kletsterlaan maar niet met lijn 12 voor de afslag Folgeralaan. Die route is nu onderbroken. Dit is dus zo’n geval waar ik vanavond over schreef.

Rotonde in Staphorst heb ik voorzien van vrijliggend fietspad er omheen en het fkp daarheen verplaatst, en de rotonde zelf door geknipt voor de bussen en de beide busroutes aangepast.

Ik ben hier inderdaad slordig geweest, zal het aanpassen. En in het vervolg nog zorgvuldiger kijken of alles routes naar/over zo’n rotonde nog OK zijn.

dvdhoven, bedankt voor Staphorst!

Ik ben al wel sinds 2009 lid van OSM, maar pas sinds kort doe ik ook echt aan mappen zelf. Dat is me al op menig kritiek komen te staan, omdat ik daarmee dingen aanpas die of niet nodig zijn, of relaties verpesten. Anderzijds bleek dat ik een keer info aangepast heb aan een halte die al helemaal correct was.

  • Voor een opdracht heb ik recentelijk alle bushaltes vanuit OSM gekopieerd naar een GIS-bestand door middel van QGis en daarin zag ik dat bij diverse haltes de gegevens van zonering, route_ref etc. niet blijken te kloppen. Deze pas ik dan aan, maar dat blijk ik dus weer niet altijd goed te doen.
  • Wat is bijvoorbeeld de standaard om haltes te vermelden? Als puntsymbool naast de weg (platform) of als puntysmbool op een weg (stop_position).
  • Daar bovenop blijken bij diverse haltes de locaties niet helemaal kloppen. Soms een enkele meter, soms wel een 100-tal meter. Omdat ik nog niet zo bedreven ben in OSM pas ik de locaties niet direct overal aan, omdat ik daarmee ook relaties verpest.

Hoe springt men met beide punten om op OSM?

Wat vinden jullie er nu zelf van dat jullie onbeheersbare relaties aan het maken zijn van data die door anderen worden beheerd en voor jullie onbekende momenten worden gemuteerd. Terwijl die data waaruit die informatie bekend is gewoon open data is (CC-0) als themalaag kan worden geladen. De manier hoe relaties in OpenStreetMap zijn verwerkt is zo onbeheersbaar, dat het alleen werkt als je er een dagtaak van maakt om het te repareren.

  1. Waarom wordt er niet gestopt met deze rare queste van handmatig bijhouden van busroutes in OpenStreetMap?
  2. Als iemand echt is geïnteresseerd in relaties van die busroutes van uit OV data naar OSM als relaties: waarom dan? Cartografie? Zo ja waar?
  3. Waarom wordt het gehele proces niet geautomatiseerd, inclusief fix bot, zodat niemand er over hoeft te zeuren?

Stefan, je opmerkingen zijn me uit het hart gegrepen.
Des te meer ik de afgelopen maanden aan mutaties heb doorgevoerd, des te meer begon ik me dat af te vragen. Niet dat ik het met tegenzin deed; ik kwam nog eens in delen van het land die ik niet kende.
Lijkt me prima als het geautomatiseerd kan worden.

Dan wel direct een vraag. Is er een centraal punt waar fouten in de OV data gemeld kunnen worden?

Ik schreef al eerder (#3 en #7) dat ik ook niet begrijp waarom we busroutes moeten gaan bijhouden terwijl anderen dat veel beter en betrouwbaarder doen dan wij ooit kunnen. Al die half afgemaakte routes, met fouten en soms al jaren niet meer relevant, waar dient dat toe? Een historische kaart van het OV in Nederland?

En er is echt geen mens die OSM gebruikt om uit te zoeken waar de bus rijdt. Ik zoek wel eens op waar een halte is, en als ik geluk heb kan ik (met openpoimap) op de haltepaal een link vinden naar de realtime data van de beheerder. Dan krijg ik up2date gegevens over de route, en niet de vertrektijden die iemand 4 jaar geleden (en dus nu allang niet meer geldig) op OSM heeft ingevoerd.

Openstreetmap is een wereldwijd project, 1 portaal, 1 bron.

Gebruikers van data wereld bouwen kaarten en meer, dan zal er ook 1 wereldwijde OV portaal moeten zijn om de data op te vragen.
Zodat niet elke app bouwer, bij elk land elk gebied elk maatschappij moet uitzoeken en verlinken. De data moet dezelfde structuur hebben. Zodat als eenmaal de verlinking is uitgewerkt andere makkelijk bij dezelfde data kunnen komen, met dezelfde key value.

Als ik naar een ander land ga, wil ik mij eigen vertrouwde app gebruiken en geen landapp, maatschappijapp downloaden, die totaal weer anders werkt.

Dat is een vergissing Allroads, we hebben duizenden bronnen…

Toren van Babel vergeten?

We moeten kaarten maken, maar geen dienstregelingen voor het OV. Jij wil toch ook niet de prijzen van citroenen wereldwijd in OSM opnemen? En waar ze worden verhandeld? En welke bestrijdingsmiddelen bij de verbouwing worden gebruikt?

Ik maak wereldwijd gebruik van het OV, en ik heb er geen enkele moeite mee om een app van het ov - waar dan ook - te gebruiken. En die app is er altijd eerder (en ook beter) dan de OSM versie, als die er al is. Heb je de busroutes in Noord-Korea al bekeken?
Probeer eens op 29 maart a.s. met de Greyhound bus van San Antonio naar Los Angeles te gaan door op OSM te zoeken.
Het kostte me op de website van Greyhound 11 seconden.
Op OSM ben ik nog aan het zoeken…

Nou die standaard heet GTFS. Verschillende sites zoals transitfeeds.com of transit.land verzamelen en controleren deze gegevens. Vervolgens kunnen zij, maar ook anderen apps en API’s maken. In herinnering Steve Coast probeerde ooit een transiki te maken, faalt, want het schaalt niet. Deze data komt direct van vervoerders af. Zit er een fout in, dan kun je het altijd melden, en kan het bij de bron verbeterd worden.

Nou zo werkt het dus al, je wist het alleen nog niet :slight_smile:

Gezien het niet alleen voor OV geldt, is ook voor fietsroutenetwerken, wandelroutenetwerken automatische validatie ook van belang.

Wat betreft OV-netwerken: laten we eens goed definiëren hoe we de data van NDOVloket geautomatiseerd willen gaan bijwerken. Als iemand daar eens over wil chatten/praten kunnen we dat maken. Maar dan wil ik ook enorm hard gaan snijden in de huidige datasets: we gaan alles voorzien met de landelijke IDs en iedere wijziging niet door de bot gedaan, wordt ongedaan gemaakt.

In Nederland is dat NDOVloket.nl.

Alleen daarvoor zijn geen gegevens beschikbaar. Voor fietsroutenetwerken is er PDOK gebaseerd op gegevens van het landelijk bureau, die ze weer van de beheerders krijgt. PDOK wordt 1x per half jaar bijgewerkt. Slechte basis om ook maar iets op te baseren.
En voor de fouten in fietsknooppunten en wandelknooppunten is er het overzicht van VMarc. Wordt om de 2 uur bijgewerkt.

Dit meen je toch niet? Dit druist in tegen elk principe van OSM. Dit begint heftig te rieken, beter gezegd te stinken naar mechanical edits en we hebben gezien welke ellende je dan te wachten staat.
Ik ben hier fel tegen. Als je een gemechaniseerde OSM wilt, ga dan je eigen mechanical OSM maar opzetten, maar verknal het huidige OSM niet.

Staan daar ook rariteiten in als bicycle=no op een way die in de relation van het fietsroute netwerk zit?

Inderdaad ik ben groot voorstander van open data hergebruiken en niet doen of je het zelf beter weet. Zeker niet als er vervolgens wordt geklaagd dat mensen wijzigingen doen en andere ‘data’ daardoor kapot wordt gemaakt. Busroutes zijn iets simpels, het is een route over de weg. Niemand weet hier beter waar bushalte is dan het Centrale Halte Bestand. Niemand weet hier beter hoe de bus rijdt dan de dienstregeling. We maken met OpenStreetMap een basiskaart met een stratennetwerk. Alle logische relaties die daar bovenop worden gelegd bestaan niet in het echt. Wat mij betreft zouden dat soort zaken dan ook nooit in OpenStreetMap moeten komen, als er mensen zijn die die data wel willen hebben, omdat dat eenvoudiger is bij het maken van cartografie wil ik ze de beste brongegevens leveren. En er is geen enkele reden waarom handmatig invoeren beter zou zijn dan geautomatiseerd inladen en bijhouden.

Vergissing, een andere uitleg dan ik bedoel.
OSM is 1 bron, waar kaartenmakers gebruik van maken.

Ik bedoel dat, dat het makkelijk voor jan en alleman bereikbaar is over grenzen heen.

Ergens heb ik helaas de indruk dat OVData nog niet goed is uitgekristalliseerd.
USRSTOP moet de fysieke positie van de halte aangeven (in OSM ‘platform’). Maar is in de praktijk gekoppeld aan POOL, de fysieke route (in OSM ‘stop_position’), waar beide dan een het hetzelfde POINT delen.

Transmodel is in de jaren 90 volledig beschreven. Daarnaast is ook van GTFS erg goed bekend hoe het in elkaar zit, en hoe het geïnterpreteerd moet worden.

UserStop is een logische halte. Een concept dat een vervoerder aangeeft waar de bus stop, het heeft een naam. De fysieke locatie ligt op de route die de bus over de weg rijdt. Een quay is de fysieke halte paal, en projecteert zichzelf op de route waarlangs een bus rijdt. Quays worden in het Centraal Halte Bestand bijgehouden. Routes in de KV1 bestanden.

Kan iemand het eens uit tekenen op een plaatje?

BGT plaatje
Hierbij staat de paal op een andere plaats en de abri op een plaats.

Maar nu met OV termen en hoe wij het met OSM termen zouden intekenen (gedetaileerd).

Of neem een ander plaatje.

1: Omdat er nog geen werkbaar alternatief is.

2: Busmaatschappijen (of iig de meesten denk ik) gebruiken momenteel Google om hun routes te visualiseren. Dat kan natuurlijk ook met OSM. Ik heb in het buitenland al eens een interactieve kaart op een groot touchscreen in een trein gezien op basis van OSM. Geweldig dat je dan alle OV routes kunt zien.
Zelf gebruik ik het om te zien hoe een bus rijdt op plekken waar ik niet bekend ben, het is fijn om een standaard methode te hebben om iets op te zoeken, momenteel doet iedere busmaatschappij toch iets anders (als ze al iets doen, in de ons omringende landen is het vaak huilen met de pet op wat betreft het aanbieden van reizigersinformatie).
Heeft het NDOV loket gedetailleerde informatie van busstations waar bussen stoppen? Zie hoe bijvoorbeeld Alkmaar, Arnhem, Den Haag, Den Helder (door mijzelf) zijn gemapt. Vroeger gaf het GVB reisinformatie op welk perron een bus stopte, nu niet meer. Ik vind dat heel handig om van te voren te weten als de overstaptijd naar de bus kort is. Ik heb daar toen bij het GVB over geklaagd (ook omdat ik die informatie in OSM wilde zetten), maar zoals vaker bij bedrijven: “je hebt te accepteren wat we je bieden en verder moet je niet zeuren”.
Als ik naar ovzoeker.nl kijk dan heb ik de indruk dat die data niet echt nauwkeurig is.
Wat gebruikers ook willen is zien welke lijnen er allemaal komen. Bij veel busmaatschappijen kun je dan wel zien hoe lijn 1 rijdt, maar dan zie je bijvoorbeeld niet dat lijn 2 misschien net iets handiger uitkomt. Dan moet je al de PDF kaart erbij pakken (als ze die hebben).

3: Is zeker geen verkeerd idee, maar zet het maar eens om in werkelijkheid.
Ik weet niet wat het NDOV loket precies voor data heeft, maar je hebt meer nodig dan alleen de haltes van de bussen en daar een graafstructuur op te bouwen. Je moet op de weg routeren en daarvoor moet je precies weten waar de bus komt.

Stefan, ik ben het helemaal eens met de intentie van wat je bedoelt. Maar toch, een paar antwoorden.

1a. Omdat er nog niemand een automatisch proces gemaakt heeft. Ik ben hier ooit mee begonnen, maar wegens tijdgebrek en gebrek aan programmeerkennis niet mee verder gegaan. Als iemand anders denkt: “Dit sleur ik in 3 avondjes in elkaar”, dan graag!
1b. Waarom in de OSM-database ipv op themalaag? Voor de haltes vind ik dat deze in OSM horen (maar dat kan natuurlijk geheel geautomatiseerd). Voor de routerelaties is het dubbel. Een routerelatie is niet “on the ground” te zien, maar dat geldt eigenlijk voor wandel- en fietsroutes ook. Feit is wel dat het overal gedaan wordt. Ik zou het een armoede vinden als alle routerelaties in Nederland perfect te zien zijn op een kaart buiten OSM maar niet erbinnen en daardoor voor degenen “niet in the know” onzichtbaar, terwijl in Duitsland alles er wel “redelijk” goed op staat.
2. Ja, ik ben een van dit soort mensen. Onder andere uit genuine interesse, maar ook voor mijn werk om in de auto de buslijnen te kunnen volgen.
3. Zie 1a.