Buslijnen, halteinfo, OV-routes - overzicht en discussie

Volgens mij laten we die highway=bus_stop nog altijd staan, omdat er anders geen icoontje met bus op de standaard kaart zichtbaar is (ja, taggen voor de renderer).

Overigens rijden die Opstappers in Friesland standaard wel vaste routes, die te vinden zijn in de data van het NDOV-loket.

Die begrijp ik niet. Je begint zelf met “waarom doen we het niet anders” en als ik daar een reden voor geef dan vraag je je af welke businesscase er is voor dat alternatief terwijl je het zelf anders wil.
Ik dacht dus dat jij het anders wilde, dan zou jij de businesscase ervoor moeten aandragen (ook al vind ik businesscase wel een hele zware term).

De kaart is van Google. Natuurlijk zit die data niet in Google maar ze gebruiken wel die kaart om het te visualiseren.
Welke maatschappijen gebruiken de OSM kaart? Ik zit niet dagelijks bij alle vervoerders op de website dus ik heb geen idee.

Geschouwd door wie? Het lijkt vooral op terugmeldingen van derden te drijven als ik het goed begrijp. Ik weet niet wie initieel de haltedata aanlevert (mijn voorbeeld, bushalte Koningslust, is een nieuwe halte en staat in de CHB data totaal niet op de juiste plek), maar die doet dat al verkeerd.

Je moet het ergens hebben om te kunnen visualiseren.

Wat editen?

Die indruk krijg ik nu ook.
Vanavond een terugmelding gedaan (op advies van Stefan in #93) en ik kreeg zowaar binnen een uur twee antwoorden!!
Daarbij was een lijst met gecorrigeerde haltelocaties die ik gecontroleerd heb en teruggestuurd met mijn aanvullingen.

Het verbazingwekkende is dat de lijst die ik terugkreeg vrij nauwkeurig was, maar die data bevindt zich dus niet in het CHB!

Al met al een uiterst zwak systeem van dataverzamelen. Rijkswaterstaat vraagt toch ook niet aan de burgers of die willen controleren of de coordinaten van de rijkswegen correct zijn? En of de bruggen wel op de juiste plaats op de kaarten zijn getekend omdat ze zelf niet over de coordinaten beschikken?

Er valt nog aardig wat te verbeteren! (En ondertussen toch weer tijd besteed aan iets wat Arriva zou moeten doen).

Meer de algemene businesscase: waarom wordt er in OSM, OV data op 'niet-fysiek-niveau vastgelegd? Wat is het doel ervan? Concreet bedoel ik: ik kan me voorstellen dat je een halte icoontje op een kaart wilt ziet, niet waarom je de route tussen twee halte op zo’n fijnmazig niveau wilt vastleggen. Ik wil dus weten waarom er relaties worden gemaakt van routes, en voor wie dat wordt gedaan. Because we can, is een prima antwoord, maar dan zeg ik ook: daar is specifieke open data voor, dat hoeft niet verweven te zitten in een kaart. Dus: wie heeft de data keuze gemaakt om deze inferieure, hand verzamelde, databron voor OV data te gebruiken voor het publiceren van visualisaties, in plaats van de echte bron te combineren met OSM-kaartmateriaal?

Ik denk hierbij aan in interne systemen van vervoerders. Denk bijvoorbeeld aan een diensten optimalisatie pakket als Giro Hastus. Of het plannen van halte berichten zoals OpenEBS. Of het visualiseren van een omleiding.

Door verschillende bedrijven die door alle decentrale overheden worden ingehuurd om met een GPS apparaat naar een halte te lopen, op te meten onder welke hoek de halte wordt ingereden. Wat de lengte van de halte is etc. etc. Een van die bedrijven is Vitence, ook bekend van hun management applicatie https://haltescan.nl/

Daarnaast worden operationele wijzigingen tussen de verschillende schouwen door vervoerders aan NDOV-CROW gecommuniceerd. Daarmee komen verplaatsingen van haltes in beeld.

Je hebt kaart materiaal van OpenStreetMap en GTFS van vervoerders. Gezien er geen automatische relatie wordt bijgehouden is het dus nogal stupide dat er eenmalig in OpenStreetMap iemand aan de slag gaat met relaties, en in tranen is als iemand anders een aanpassing doet aan een weg, om vervolgens te zien dat de relatie niet meer klopt.

Alle OV-data van Nederland geautomatiseerd in OSM synchroon houden met NDOV. Klopt de bron data niet? Terugmelden aan NDOV.

Op basis waarvan baseer je dat deze data niet in het CHB zou zitten?

Het lijkt dat je maar een bom hebt gelegd onder het Wiki/OpenStreetMap model? Natuurlijk doe overheden dat wel. Daarvoor is de hele Terugmeld infrastructuur opgetuigd. https://www.kadaster.nl/terugmelden

Volgens mij snap je het echt niet. Arriva krijgt een opdracht vanuit de overheid om een busroute te gaan rijden. De informatie waar haltes zouden staan, kennen haar oorsprong in een verkeersbesluit . Dat de geografische werkelijkheid niet klopt met de juridische besluitvorming is iets dat gerepareerd moet worden. Daar hebben tal van partijen belang bij, inclusief kaartmakers, reizigers, busmaatschappijen en overheden. Dat jij vindt dat Arriva dit zou moeten doen, doet niets af dat het niet de taak van Arriva is om dit op orde te houden.

Omdat ik die juiste haltepositie dus niet terugkrijg uit dat CHB:

  • Ik lees op 19-3-2017 het haltebestand in en vergelijk dat met de werkelijkheid die ik voor mijn deur kan controleren

  • Ik meld deze afwijking op het door jou gegeven adres

  • Ik krijg dan (binnen een uur) een nieuwe lijst met halteposities die aanmerkelijk betrouwbaarder zijn

  • Maar die halteposities staan - op dat moment nog niet in het CHB

Na mijn vraag aan het meldpunt hierover kreeg ik bericht dat mijn correcties zouden worden opgenomen in het CHB.
Ik heb na deze discussie niet meer gekeken of het nu wel klopt, want ik vertrouw er maar op dat ze inderdaad doen wat ze zeggen.

Klopt helemaal, en daarom doe ik er ook maar niets meer aan.
Maar misschien kun je dan nog een keer voor de anderen duidelijk uitleggen hoe zij de bushalte posities correct (qua positie) in het CHB kunnen krijgen, zonder verkeersbesluiten te hoeven lezen of te moeten concluderen dat op haltescan de bushaltes nog steeds in de vijver liggen…

Ik schat dat van alle haltes in CHB de meerderheid niet op de juiste positie zit. Dan is het niet onze taak deze stuk voor stuk te melden, maar moet dat ergens structureel worden aangepakt.
De haltebeheerders kunnen toch ook zelf (net als wij) haltes vergelijken met recente luchtfoto’s en dan zien dat er iets niet klopt als bv.

  • haltes voor heen en weer aan dezelfde kant van de weg liggen
  • haltes in panden of water liggen
  • een halte ver verwijderd is van waar zichtbaar een perron is (steeds vaker duidelijk zichtbaar op foto’s door verhoging en deels gemarkeerd oppervlakte)

Stefan,

De mappers die met de data hebben gewerkt geven aan dat de huidige centrale gegevensbronnen niet erg nauwkeurig zijn. Dan kan er wel een theoretische opzet zijn waar je vertrouwen in hebt maar ontken nou niet de weerbarstige praktijk.

Wat Marc volgens mij bedoelt met ‘uiterst zwak systeem van dataverzamelen’ is in relatie tot het centrale gegevensbeheer. Immers, als de nauwkeurigheid afhankelijk is van burgers, van vrijwilligers, van hobbyisten… dan kunnen zij beter zelf een platform opzetten om direct data te bewerken…
Door zo te pleiten voor gecentraliseerde en geinstitutionaliseerde dataverzameling ben jij het toch juist die een bom legt onder het Wiki/OpenStreetMap model?

Het succes van Wiki/OpenStreetmap komt niet voort uit afhankelijkheid van gecentraliseerde data maar uit het benutten van de daadkracht en unieke kennis en vaardigheden van vele vrijwilligers.
De moeilijkheid en onmogelijkheid om OSM (of Wikipedia) perfect betrouwbaar en bij de tijd te houden is iets waar organisaties en zeker de overheid minstens zo erg mee te kampen hebben.

Ik durf te stellen dat een groot deel van de buslijnen en -haltes binnen Fryslân op dit moment gedetailleerder en nauwkeuriger in OSM staan opgeslagen dan waar dan ook.
In theorie zouden overheden en professionele kaartenmakers superieure kaarten moeten kunnen maken t.o.v. OSM maar het gaat om de realiteit en dan scoort OSM gewoon heel goed.

Wat betreft verbroken relaties heb je wel een punt, hoewel bepaald niet subtiel verwoord. Binnen de huidige opzet van OSM hoort het er een beetje bij en is het aan de liefhebber van het type relatie om af en toe controles en reparaties uit te voeren.

Ik weet niet wie je met die “wie heeft die keuze gemaakt” probeert aan te spreken, ik denk ook niet dat er één persoon is die een zeer afgewogen keuze heeft gemaakt om te beginnen met busroutes te mappen. Zoals bijna alles bij OSM gaat: iemand heeft een idee, zet dat in OSM en anderen bouwen daarop. Het komt op mij een beetje over alsof je een zondebok zoekt voor iets wat in jouw ogen een rotzooitje is.
Daarbij was NDOV data voorheen gewoon niet voorhanden. Dus men is begonnen met busroutes met de hand mappen omdat dat de enige mogelijkheid was. In andere landen is een dergelijke open dataset meestal ook niet voorhanden (en is ook het vinden van gegevens op andere manieren vaak lastiger).
Een beetje historisch besef.

Als het gaat om een meta-discussie “waarom moeten we busroutes in OSM hebben” dan moet je die discussie breder trekken dan dit deel van het forum. Dan moet je je ook afvragen “waarom moeten we trein-, fiets-, wandel- omleidingsroutes in OSM hebben”. En niet alleen in Nederland maar ook in andere landen.

Zoals Andries al aangeeft: als dat al gebeurt dan is dat blijkbaar een heel erg traag proces.

En dus? Kom je weer op de vraag “moeten we busroutes in OSM hebben”.
Kijk, het staat eenieder vrij om de NDOV data te downloaden en hun eigen systeem erop te bouwen (9292ov zou een aangewezen organisatie zijn). Zolang niemand dat doet vind ik OSM een goed platform om dergelijke zaken te combineren en te visualiseren.

Enkele opmerkingen/gedachtes:

Gebroken relatie:
Een gebroken relatie is toch wel visueel kloppend te maken door vanaf de breek een kortste routering tot het volgende punt waar de laatste verder te gaat, te berekenen. Dit om de volledige routelijn te kunnen laten zien. De relatiefout is hierbij niet opgelost.

Visualisatie:
Als je gebruikt maakt van een ondergrond kaart, dan verwacht je dat de route relatie precies over de wegen zichtbaar is.
Een kwalitatief goede projectie vanuit de gebruiker bekeken.

Gat:
Als OSM Nederland alle busroutes eruit gooit. Dat ontstaat er een gat in data. OSM is nu een maal een wereldwijde kaart.
Het doel om iedereen wereldwijd openbaar vervoer data te kunnen laten gebruiken, voor hun eigen projectie.

Dus je zegt dat je een melding hebt gedaan van een fout. En vervolgens ben je niet meer geïnteresseerd in het gehele bestand omdat jij eenmalig hebt vastgesteld dat een positie niet voldoet aan de werkelijkheid? Dat klinkt nogal zwart-wit.

Zoals al gemeld een e-mailtje sturen, en door jou bevestigd dat het systeem goed werkt.

Kom eens met feiten. Neem een gebied van 2 vierkante kilometer waar je bekend bent en geef een percentage aan verkeerde locaties aan.

Welk systeem gebruikt die data nu? Oftewel wat is het belang en/of businesscase om het in OpenStreetMap vast te leggen. Ik lijk zelfs niet de eerste te zijn met het idee om het netjes te automatiseren.

http://wiki.openstreetmap.org/wiki/Public_transport#Maps
http://wiki.openstreetmap.org/wiki/GO-Sync

Een beetje historisch besef: ik ben in december 2009 met openOV begonnen om bushaltes in OpenStreetMap te krijgen. De databestanden zijn al jaren beschikbaar in defacto internationale standaarden.

Visualisatie valt buiten de scope van de database. Dus laten we het dan over het combineren aspect hebben. Als we van mening zijn dat er gecombineerd kan worden, waarom geen geautomatiseerd systeem daarvoor gebruiken?

Omdat nog niemand dat gebouwd heeft en omdat de NDOV data ook niet foutloos is.

Begrijp me niet verkeerd, het principe van automatisch OV informatie overnemen vind ik goed. Maar je moet je wel afvragen hoe correct het is en of je niet de ene deels incorrecte data met de andere deels incorrecte data gaat overschrijven.

Zoals ik ook al gezegd heb: misschien moeten we met iets kleins beginnen: maak een connectie tussen de bushaltes in het CHB en in OSM en kijk of we een automatische terugmelding naar NDOV kunnen doen aan de hand daarvan.

Groningen, wijk Beijum, 18 haltes in CHB.
fysiek verdwenen (al minstens een jaar): 2
aan verkeerde kant weg: 6
(vrijwel midden) op de weg i.p.v. op aanwezig perron aan wegkant: 10
op juiste plek: 0

Dit is geen uitzondering, maar in elk geval in heel Groningen en Drenthe schering en inslag, zowel in steden als landelijke gebieden.

Als ik het goed lees dan is de 8-cijferige CHB code hetzelfde als de bbbb:cccc in de wiki. bbbb is de admin area, cccc is de stop place.
Dan zou de juist code voor Nederland zijn, als het CHB 64310190 geeft: nl:6431:0190:2:0. En op busstations kun je de laatste 0 overeen laten komen met het platform (waar A, B, C natuurlijk 1, 2, 3 wordt).

Maarten, ik had al eerder eens over de oostergrens gekeken naar hun gebruik van van het dd:ee stukje aan het eind.

Maar dat dd:ee deel wordt in ons land (nog) niet gebruikt, voor zover mij bekend, in elk geval niet in het CHB. Voorlopig dus maar weglaten.

Inmiddels heb ik alle buslijnen in Leeuwarden aangesloten op het vernieuwde busstation waarbij elke lijn begint en uitkomt bij het juiste perron. Het opknippen van ways en toevoegen van stopposities om precies bij de halte uit te komen heb ik vooralsnog niet toegepast. Buslijnrelaties bevatten ‘gewoon’ de halte van het perron en de rijbaan die langs het perron loopt.

Gisteren was ik in Heerenveen en ik heb daar de koppeling tussen lijnen en perrons van het busstation gecontroleerd. Overigens is het de bedoeling dat dit busstation wordt omgebouwd naar het visgraatmodel maar dat begint op zijn vroegst in 2018.
Op dit moment is het een ovaal met acht perrons. Twee ervan zijn als halte door Henk toegevoegd, de overigen staan als highway=bus_stop en public_transport=stop_position op de rijbaan aangegeven.
In Groningen-stad zijn de haltes op de perrons geplaatst en zijn de meeste van de rijbanen opgeknipt met public_transport=stop_position toegevoegd aan de node (door Henk).
Echter, die nodes zijn niet toegevoegd aan de relatie en dan vraag ik me af of het toevoegen van de tag wel nut heeft.

Verder zijn in Leeuwarden de perrons (door JeroenHoek) als vlak ingetekend en in Groningen als lijn.
En de tag public_transport=station uit het nieuwe OV-schema is aan nog heel weinig busstations in Nederland toegevoegd naast amenity=bus_station.

Het lijkt me goed meer eenheid aan te brengen. Wat betreft de stopposities lijkt het me niet zinvol om die bij alle haltes toe te voegen. Wat is het argument om het ergens wel of niet te gebruiken?
Opzetje: toevoegen langs perrons van busstations en transferia en wanneer er meer dan één halte onder dezelfde naam aan één kant van de weg staan en bij haltes die het begin- of eindpunt zijn van een lijn.

Waarheid uit identifiers halen is nooit verstandig. Het enige wat internationaal uniek wordt gelaten is de landcode. In Nederland is het een unieke identifier, en heeft het geen verdere waarheid. In Duitsland wordt de farezone er aan toegevoegd, die zie ik in de formule niet terugkomen.

Weet je wat voor iedere routeplanner op basis van OSM data echt impact heeft om toe te voegen?

http://wiki.openstreetmap.org/wiki/Tag:highway%3Dcrossing
http://wiki.openstreetmap.org/wiki/Key:tactile_paving

Op die manier wordt de halte gelinked aan het OSM platform, kun je daar te voet ook daadwerkelijk komen, en als het toevallig ook nog toegankelijkheid kenmerken heeft, zijn de mensen van “reizen onder begeleiding” diensten ook weer blij.

Ik heb alle CHB haltes in een database geladen en alle haltes in OSM ook. Ik heb nu een query die per gelijke haltenaam in OSM de afstanden tot de CHB haltes laat zien, ik heb alleen wat moeite om uit die query niet alleen de kortste afstanden per IFOPT te krijgen, maar van die haltes ook de bijbehorende OSM halte.
Misschien moet ik die query eens anders aanpakken. Heeft iemand hints daartoe?

Dat is een aspect dat zeker aandacht verdient. Echter, in werkelijkheid is niet alles verbonden en dan doel ik met name op de perrons ten opzichte van het trottoir aan de overkant van de rijbaan en perrons onderling. Bijvoorbeeld in dit korte filmpje van busstation Groningen zie je een met blauwe verf zichtbaar gemaakte oversteek naar een deel van de bushaltes, maar geen zichtbare verbinding van trottoir naar de perrons van de visgraat.
Het nieuwe busstation van Leeuwarden heeft wel een vorm van geleidestrook van trottoir naar perrons middels een stippellijn.