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.
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.
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.
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.
Ik verwelkomde eerder de intentie van Stefan voor meer automatisering.
Helaas kom ik daar van terug. Ik heb de hele draad nog eens doorgelezen met diverse voorbeelden van waar haltering niet klopt.
Heb nu met wat moeite de complete database met haltes (Centraal Halte Bestand) geprojecteerd in JOSM en ben geschrokken van hoe het volgens het CHB zou moeten zijn.
Heb daartoe het CHB zoals beschikbaar op http://data.ndovloket.nl/haltes/ omgezet in een CSV-bestand met enkel het landelijke quay nummer (nl:q), naam en x- en y-posities volgens RD-coördinaten.
Het bestand is (tijdelijk) te vinden op: wxgr.nl\Tmp\CHB.csv.
Om het CSV-bestand in JOSM te kunnen gebruiken, moet de plugin ‘opendata’ aanwezig zijn (meer info hier).
Open vanuit JOSM het gedownloade CSV-bestand via ‘Bestand, Openen’ en kies als Projectiemethode ‘Rijksdriehoekscoördinaten’. Komt dan in een aparte layer te staan. Laad beschikbare OSM-data in de standaard-laag en vergelijk.
Vooralsnog is mijn conclusie dat de gegevens in het CHB veelal niet overeenkomen met de zichtbare werkelijkheid. Zolang dat niet is opgelost, is een geautomatiseerde aanpak zinloos.
Naar aanleiding van het nalopen van bushaltes kwam ik langs de bushaltes op de A50 tussen Arnhem en Apeldoorn en deze blijken al jaren ontzettend verkeerd te liggen, ook in Centraal Haltebeheer kloppen deze niet. De haltes “Terlet”, “Groenendaal” en “Woeste Hoeve” heb ik inmiddels op de juiste plaats neergezet NAAST de snelweg op zo exact mogelijk de juiste locatie (a.d.h.v ArcMap en Streetview) en de oude bushaltes verwijderd. De wijzigingenset staat hier: https://www.openstreetmap.org/changeset/46924593#map=13/52.0818/5.9468&layers=N
Zou iemand de relatie van lijn 191 (https://www.openstreetmap.org/relation/5828659) aan kunnen passen? Deze rijdt aldus niet over de snelweg, maar via de parallelweg ernaast (de oude Arhemseweg en Apeldoornseweg).
Wat ik bij mij in de buurt vooral aan dat haltebestand zie is gebrek aan onderhoud. Een weg die verlegd is waardoor de haltes verplaatst zijn (onderhand ook al 2 jaar geleden): haltes staan nog op de oude plek. Arriva die een nieuwe routering heeft sinds 11 december: nieuwe haltes zijn zeer onnauwkeurig ingezet.
Terwijl veranderingen van haltenamen wel goed zijn doorgevoerd.
Ik heb begrepen dat je verbeteringen kunt doorsturen, ik heb de indruk dat dat voor een aantal plekken ook gebeurd is. Het aantal en de plaatsing van bushaltes bij station Venlo en Roermond vind ik te toevallig goed matchen met OSM dat dit vanuit de vervoerders of het NDOV loket komt. Op andere plekken (station Maastricht bijvoorbeeld) slaat de halteplaatsing weer nergens op.
Wat misschien een idee is om het quay nummer in de haltepaal op te gaan nemen en daarmee het NDOV loket gaan bestoken met correcties. Het opnemen van het quay nummer kan denk ik tot op hoge mate op correcte wijze automatisch doorgevoerd worden (zoek gelijknamige halte in de buurt), aanpassingen kunnen dan ook weer automatisch doorgestuurd worden.
Een automatische overname van busroutes is misschien nu nog niet mogelijk, maar met kleine stapjes vooruit kan het binnenkort zo maar eens wel mogelijk zijn.
Tijdens het bijwerken van buslijnen heb ik me ook wel eens afgevraagd hoe zinvol het is. Er wordt waarschijnlijk weinig gebruikt van gemaakt en de gegevens kunnen snel verouderen.
Het is in de eerste plaats wél zinvol omdat ik en anderen het leuk vinden om met buslijnen bezig te zijn. En de beste manier om plaatsing en naamgeving van bushaltes bij te houden is door de buslijnen na te lopen.
Ook niet onbelangrijk: tijdens deze werkzaamheden kom ik regelmatig wegen en andere zaken tegen die gecorrigeerd of bijgewerkt moeten worden en daar zorg ik dan meestal voor.
Automatiseren heeft zo zijn eigen haken en ogen. Als bijvoorbeeld ergens het wegennet niet actueel is dan kan een buslijn niet eens de juiste weg vinden. En zoals Maarten terecht opmerkt zijn de gegevens van organisaties niet altijd nauwkeurig.
De kwaliteit van info over buslijnen en -haltes in OSM is de laatste maanden juist een stuk vooruit gegaan. De vergroot de kans dat deze info gebruikt gaan worden.
Net zoals Wikipedia voor- en nadelen heeft ten opzichte van een encyclopedie samengesteld door professionals geldt dat voor OSM ten opzichte van professionele kaarten/databases. Inclusief de info over het openbaar vervoer. Een gebrek of juist overvloed aan ijverige en secuur werkende mappers maakt een enorm verschil. In sommige regio’s zal OSM duidelijk achterlopen op bijv. de BAG en PDOK, terwijl in andere gebieden oplettende mappers ervoor zorgen dat OSM juist voorloopt en beter weergeeft wat de situatie is.
Onbeheersbaarheid… dat is een vaste dreiging voor heel OSM. Ik heb gezien dat in sommige delen van Fryslân weinig is toegevoegd, gecorrigeerd en geactualiseerd sinds de AND-import. Onbeheersbaar door gebrek aan lokale mappers.
Een positievere insteek is dan om meer systematisch samen te werken en zo te zorgen dat elke regio voldoende aandacht krijgt.
Wat betreft de unieke haltenummers volgens Centraal Halte Bestand (CHB), stel ik voor deze als volgt in OSM te gebruiken:
Als tag gebruiken we ref:IFOPT, waarmee we aansluiten bij wat vermeld staat in de Wiki.
Als waarde gebruiken we NL:Q:12345678, NL en Q in hoofdletters en een 8-cijferige unieke code. Hoewel dit dan weer niet aansluit bij bovengenoemde Wiki-pagina, komt dat overeen met de waarden zoals ze in het CHB voorkomen.
Ik had in het noordoosten van het land enkele tientallen haltes reeds van zo’n tag voorzien, hoewel overal met kleine letters in tag en waarde; dat moet ik dan dus nog corrigeren.
HenkL: Eens.
Al staan op de wiki nog een level :dd en quay :ee, die ik niet ken en niet kan plaatsen. Misschien goed om daar eens achteraan gaan voor we hier een lokale afgeleide van het schema verzinnen dat afwijkt van de rest van de wereld.
Ik heb uit jouw bestand alleen even de gegevens gehaald voor mijn woonplaats (herkenbaar aan Q:6211xxxx) en de controle uitgevoerd:
Van de 69 haltes staan er minder dan 10 op de juiste plaats! Sommige haltes staan gewoon in een woonhuis geprojecteerd, anderen in de verkeerde straat enz. Kortom, behoorlijk nutteloze data.
Ik onderschrijf jouw conclusie van harte!
===
Voor diegenen die uit het bestand van Henk ook alleen hun woonplaats willen halen, grep is your friend:
grep NL:Q:xxxx CHB.csv > haltebestand.csv
xxxx zijn de 4 cijfers van de haltecodes voor jouw woonplaats (ik weet niet of dat bij alle woonplaatsen zo is, voor Vught werkte het wel)
Daarna gebruik je haltebestand.csv als input voor JOSM. Wel even de headerregel “nl:q;name;x;y” bovenaan toevoegen.
Edit: Henk heeft het bestand iets aangepast. De grepcode wordt daardoor ook anders.
Voor JOSM maakt het niets uit, voor mensen is het wat inzichtelijker als de haltes gesorteerd in die lijst staan.
Die versie kun je hier vinden en downloaden.
De concessie Noord- en Zuidwest-Fryslân en Schiermonnikoog is inmiddels vrijwel volledig bijgewerkt. Er zijn nog een paar details die ik probeer op te lossen.
Als laatste heb ik de stadsbuslijnen van Leeuwarden gedaan. Deze staan nu nog in een aparte netwerk-relatie en ik had die willen overhevelen naar de netwerk-relatie voor de gehele concessie. Die netwerk-relaties verschenen voorheen bij het in JOSM downloaden van data die buslijnen bevatte maar nu alle lijnen volgens het nieuwe schema zijn getagd is dat niet meer zo. Wie kan me vertellen hoe ik hier alsnog bij kan?
Alle lijnen binnen de concessie die staan vermeld op de lijnennetkaart van Fryslân op de website van Arriva heb ik meegenomen. Dat zijn:
37x streekbus op het vasteland
5x bus op Schiermonnikoog
12x stadsbus in Leeuwarden
5x schoolbus
2x buurtbus
6x Qliner
6x belbus
De meeste bushaltes heb ik goed gecontroleerd op positionering en afwijkingen van de werkelijkheid zullen daarom minimaal zijn.
Bijzonderheden aangaande bushaltes:
In enkele gevallen staat er een paal aan één kant van de weg terwijl de bus aan beide zijden stopt, o.a. op Schiermonnikoog. Ik heb dan de virtuele tweede paal wel aangegeven met soms daarbij een opmerking over de fysieke afwezigheid.
Enkele buslijnen bevatten haltes die fysiek helemaal afwezig zijn. Ik heb dan wel een ‘paal’ aangegeven op de ingeschatte locatie maar daarbij een opmerking. Dit geldt voornamelijk voor buurtbuslijnen 102 en 103.
Op sommige plaatsen staan haltes voor vraagafhankelijk vervoer volgens de formule Opstapper. Deze lijnen zijn niet opgenomen in OSM en daarom deze haltes ook niet.
Ik heb niet zo’n kijk en interesse in OV routes.
Deze OSM gebaseerde site kwam ik tegen, het viel me op dat in Zweden een Openbaar Vervoersbedrijf gebruik maakt van OSM data.
Ook de aankomst- en vertrektijden staan op deze site. Nu weet ik niet of deze tijden van een interne server van het OV bedrijf komen of dat deze in OSM staat?
Ik vond het best interessant om dit in deze topic te plaatsen. http://sl.se/en/#/Realtime/Stockholms%20C/9001
