Buslijnen, halteinfo, OV-routes - overzicht en discussie

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.

Nouja, als je met zoiets bezig gaat en er ontbreken fysieke kenmerken dan lijkt me dat de meest logische route verbinden en daarop crossing=unmarked zetten een prima oplossing.

Als je de korste afstand naar de kandidaat OSM halte hebt, wat lukt dan niet?

Andries,

Ik heb alleen stop_position aan de weg toegevoegd (niet in de relatie) aan begin en eind van een route, om niet steeds een klacht te krijgen van de PT_assistant plugin (zwak argument, inderdaad :/). Zie eigenlijk weinig nut in gebruik van stop_positions, de (fysieke/zichtbare) haltes aan de kant van de weg zijn essentieel.

Ik heb een combinatie van alle namen van biede datasets die overeenkomen, dus ook HalteA in Groningen gecombineerd met HalteA in Vaals. Dan heb ik dus twee restultaten, een met een kleine afstand en een met een grote afstand.
Ik kan daarmee wel de kleinste afstand met IFOPT van het CHB krijgen, maar dan mis ik van dat record de link met OSM, omdat als ik dat in de group by zet, ik dan ook de niet gewenste records krijg.

Kan ik sql queries posten?

Stuur maar :slight_smile:

Daar heb ik mijn gedachten over laten gaan en over geschreven in het topic dat je vorige maand hierover was gestart.

Oké, want bij gebruik van stop_position is het de bedoeling om deze samen met de halte toe te voegen aan de relatie (eerst stop_position, dan de halte). Een relatie met alleen al 40 leden om 20 haltes/stops aan te geven lijkt mij ook te veel van het goede.
Wat vind jij ervan Maarten?

Het opknippen van wegen ter hoogte van een halte: doen jullie dit bij alle begin- en eindhaltes of ook bij alle tussenhaltes?