Buslijnen, halteinfo, OV-routes - overzicht en discussie

Even over rotondes in een busroute:

Eerder deed ik het ook zo en tekende ik nieuwe rotondes in met geknipte delen tussen elke afslag. Tegenwoordig gaat mijn voorkeur uit naar rotondes in één geheel.
Ik zou zeggen: als je in een rotonde knipt, neem dan meteen de gehele rotonde mee en controleer daarna alle routes.

Stel, je hebt een niet-geknipte rotonde met vier aansluitingen, uit elke windrichting één. Voor de richting noord-zuid en vice versa maak of bewerk je een relatie van een buslijn. Je knipt de rotonde in tweeën. Zo kun je de busroute mooi voor de helft over de rotonde leggen.
Echter, andere buslijnen die de rotonde gebruiken blijven over met twee halve rondjes en missen dan de aansluiting met de rest van de route. Lopen ze ook noord-zuid of andersom dan volstaat het weghalen van het stuk halve rotonde uit de relatie dat niet wordt bereden. Heeft een buslijn een ander verloop over de rotonde (oost-west, west-oost, kwart, driekwart) dan is er extra knipwerk en aanpassing nodig om het terug in orde te maken.

Kost inderdaad een hoop extra werk. Zo heb ik nog even laten liggen de rotonde NW van knooppunt Joure met veel buslijnen aldaar, en een rotonde in Staphorst waar de hele rotonde als één fietsknooppunt geldt.
Neemt niet weg, dat ik van mening ben dat een route over een deel van een rotonde niet de hele rotonde moet bevatten. De route moet volgens mij volstrekt helder en eenduidig zijn.

Hetgeen me deed denken aan een verblijf eind jaren zeventig in Amsterdam. Een trambestuurder maakte een wisselfout, zodat het Weteringcircuit volledig gerond werd. Op de opmerking van een collega ‘Ga ja vreemd, Klaas?’ werd via de mobilofoon gereageerd met ‘Rondje van de zaak!’.

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.