Buslijnen, halteinfo, OV-routes - overzicht en discussie

NEEEE! Laten we alsjeblieft de highway=bus_stop uitroeien door géén nieuwe meer toe te voegen!!!

En voor wat betreft Opstappers, haltetaxi’s e.d. (lijnen die niet op gezette tijden een vaste route rijden maar die van punt naar punt kunnen rijden) zou ik voorstellen om een “normale” routerelatie aan te maken, alleen dan zonder ways erin, maar alleen alle haltes (stop positions en platforms) zodat ook duidelijk is qua relatie welke lijnen daar stoppen. In bijv. OSMand kan je namelijk een halte aanklikken en zien welke lijnen daar stoppen.

Welk key moet er dan in de plaats van highway komen? (als beginneling vraag ik dat maar even)

Dat uitroeien kan alleen door die tag massaal te verwijderen terwijl die nu nog overal aanwezig is. Mogelijk wordt de tag nog benut en dat is wat op de diverse wiki’s wordt aangegeven.
Mocht er consensus zijn dat het tijd is om highway=bus_stop helemaal vaarwel te zeggen dan kan dat beter via een mechanical edit.

De tag public_transport=platform is de vervanger voor highway=bus_stop, maar ik zou ze dus voorlopig nog allebei toepassen.

Dan komen er dus zo’n tweehonderd relaties met twee tot vijf haltes bij. En dan krijgt halte Dokkum Busstation er in één klap 44 lijnen bij (nrs. 701 t/m 744). Dat denk ik: NEEEE! :wink:

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.