OV-Routes

Hallo,

Ten eerste ben ik vrij nieuw in het hele OSM-gebeuren. Wel al enthousiast aan het mappen geslagen, ik doe ongetwijfeld dingen fout, ben nog zoekende en lerende dus spreek me daar gerust op aan!

Ik werk zelf in het OV (Bij Connexxion, tot gisteren als vervoerkundige Provincie Utrecht) en ken daarom (in dat gebied) niet alleen alle routes uit mijn hoofd, ik heb zelfs alle wijzigingen die op 14 december plaats gaan vinden bedacht :slight_smile:

In OSM zitten, voor Nederland, de meeste OV-lijnen. Het viel mij op dat - voor PU (Provincie Utrecht) - de OV-routes uit ongeveer 2010 er in staan.

Nou ben ik graag bereid om de routes in PU-gebied aan te passen, maar om dit voor alle haltes te controleren is een groot klusje, zelfs als ik uit onze systemen een lijst met coordinaten trek. Ik ben echter niet zo bekend met NDOV/GOVI; als ik snel kijk zou in de KV1-data (JOPATILI, TILI, LINK, POINT, POOL) de hele route-opbouw moeten zitten.

Haltes kan je daarmee precies neerleggen. De route is wat lastiger: die zit er in op RD-coordinaten (1m) precies. Hij ligt daarmee echter nog niet op een way op Openstreetmap. Zijn er tools om dit te koppelen?

Is zoā€™n import al eerder (semi)automatisch gedaan?

Ik ben geen groot programmeur, maar wil graag helpen meedenken (met kennis van lijnopbouw van binnenuit het OV) over hoe dit makkelijk en geautomatiseerd in OSM gezet kan worden. En geen werk doen dat automatisch kan :slight_smile:

Tijmen

Beste IIVQ, de in OSM aanwezige data is van ons allen er rust dus geen copright op. Het importeren van gegevens uit een databank (OV Connexxion - Q bus) kan slechts op basis van toestemming onder de, http://wiki.openstreetmap.org/wiki/Open_Database_License , als dat geregeld is kun je met een vertaal slag voor de import aan de gang of eerder maar dan weet je niet waarvoor je werkt. Tot nu toe is het OV in het veld verkend, maar het verandert ieder jaar wel ergens. Je moet dus alles nalopen, arbeidsintensief dus, maar succes.
Trouwens welkom Tijmen.

Data in het NDOV (https://ndovloket.nl/)-Koppelvlak-1 worden beschikbaar gesteld volgens Creative Commons Zero. Zie License.txt op http://data.openov.nl/kv1/ - Dat is dus geen probleem.

Mijn vraag is meer: is er al eerder een OV-import gedaan, en zo nee, hoe zou je zoiets aanpakken? Zijn er mensen die daar ervaring mee hebben?

Er is al eerder OV data geĆÆmporteerd, geen idee wie zich daarmee bezighoudt.
Anders even je vraag droppen op talk-nl daar zit meer deskundigheid wb imports.

Ik weet dat Stefan de Konink verwantschap met een OV-planner kent obv OSM.
Vermoedelijk weet hij wel of er ooit een import heeft plaatsgevonden.

Je zou ook in JOSM op de historie in de tags kijken of er een tag aanwezig is die te herleiden is naar een import.

http://blog.openstreetmap.nl/index.php/2012/09/27/vrienden-worden-met-prorail-kun-jij-ook/

Afgezien of een import beschikbaar wordt gesteld op basis van Creative Commons Zero, heeft OSM zelf een procedure om Ć¼berhaupt een import te laten plaatsvinden.
De DWG ziet hierop toe of deze regels nageleefd worden, mocht dit niet het geval zijn, dan zal de volledige import gerevert gaan worden, en het account vermoedelijk een ban opleveren.
Natuurlijk is op het forum ervaring met imports, en zouden de (spoor)wegen naar een succesvolle verbetering kunnen leiden.

Alvast succes met de communicatie in deze en het verdere traject natuurlijk.

Hoi Tijmen, welkom bij OSM! Het door jou gesignaleerde probleem, te weten data uit 2010 die inmiddels verouderd is, geeft direct het probleem weer met imports. Eigenlijk werken imports alleen goed als er verspreid over Nederland enkele tientallen gebruikers zijn die dit soort data belangrijk genoeg vinden om te onderhouden.

Naast voorgaande nuttige tips van Hendrikklaas, Ligfietser en Commodoortje: op https://groups.google.com/forum/#!forum/openov vind je een gespecialiseerd forum over OV. Stefan is daar ook actief.

Cheers, Johan

Hoi Tijmen,

Ook namen mij welkom bij Open StreetMap.
Zelf heb ik wel eens wat werk gedaan aan de wijziging bij de overgang in Utrecht van Connexxion naar U-OV. Daaruit weet ik dat het aardig wat werk is.
Waar ik erg nieuwsgierig naar ben, is in hoeverre dit probleem door een bestaand routeringsprogramma zou kunnen worden opgelost. Stel dat alle haltes in OSM staan en je voor een route het lijstje met haltes in de juiste volgorde hebt (liefs met een uniek halte id). Dan zou een bestaand routeringsprogramma in staat moeten zijn om de route over OSM wegen en busbanen van halte naar halte te berekenen. Het resultaat zou je kunnen vergelijken met de route uit de KV1 data. Alleen waar de twee routes te veel (= 25m ?) verschillen zou je moeten kijken waar het verschil zit en eventueel een extra routepunt toe kunnen voegen om de routering goed te krijgen.
Een eerste stap zou dan zijn om de haltes uit OSM en uit de KV1 data te vergelijken om te kijken hoe groot de verschillen zijn.
Eigenlijk zou daar nog een stap voor moeten komen. In OSM heb je namelijk een oude en een nieuwe manier om openbaar vervoer te mappen. Op dit moment worden in Nederland beide systemen door elkaar gebruikt. Dit standaardiseren zou bovenstaande taken vereenvoudigen, maar weer een klus op zich zijn.

Gertjan

Polyglot heeft zoiets in Belgie gedaan misschien helpt dit
http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/De_Lijndata
maar dit is duidelijk eerder jaarlijks onderhoud dan een eenmalige import

Groeten Simon

Het is eerder een voortdurende integratie, dan een jaarlijkse import. De data van De Lijn wordt meermaals per week bijgewerkt en gepubliceerd op hun FTP-site. Die van TEC (De Waalse vervoermaatschappij) ongeveer om de 3 maanden.

Als ik merk dat er nieuwe data is, dan laat ik mā€™n scripts die omzetten en ga dan kijken of er haltes zijn bijgekomen of gewijzigd.

De routes heb ik grotendeels manueel ingegeven, daarbij wel geholpen door een script dat me de haltes voor elk van de variantes in de correcte volgorde bezorgt en een ander script dat binnen JOSM draait dat op zoek gaat naar geschikte ways die vlakbij die haltes liggen.

Het opvullen van de ā€˜leemtesā€™ is dan nog een heel karwei. Het zou inderdaad wel gemakkelijker zijn, als je al iets had om op voort te gaan, maar die data kunnen ze ons hier in BelgiĆ« niet bezorgen.

Die routes gaan echter regelmatig stuk, ik werk ook aan een script dat deze naloopt en kijkt waar er onderbrekingen ontstaan zijn door edits van anderen. (Dat heb ik al, ik had het al gedaan voor de fietsroutenetwerken). Een verdere stap is nakijken of alle haltes wel bediend worden (in de juiste volgorde) en of er geen ways in de route zitten die er helemaal niets mee te maken hebben. Daar ben ik nog mee bezig.

Op dit moment ben ik echter met iets anders bezig. Voor het gemak had ik voor elke transportbedrijf aparte nodes gemaakt, maar dat ziet er niet uit en het stoorde me al langer.

Ik ben nu alles aan het omzetten naar 1 node per halte/1 node per stoppositie op de straat, maar dan met tags die specifiek aangeven of een ref/route_ref/zone/name betrekking heeft op De Lijn, TEC, of MIVB/STIB. Er zijn ook een aantal haltes in Tilburg, Maastricht, Sluis en Breskens die ik daarvoor heb gewijzigd in de voorbije dagen. Deze worden door zowel De Lijn als door Veolia bediend.

http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Bus_stops

Polyglot

Nog bijna vergeten om Tijmen welkom te heten bij bij OSM!

Wat ik nog wilde vermelden is dat ik die scripts nog ingrijpend zal moeten wijzigen, nu dat de data er helemaal anders uitziet.

Hoe gaat dat eigenlijk in Nederland? Zijn daar nooit bussen van Connexxion die doorheen een gebied moeten dat hoofdzakelijk door Veolia wordt bediend of andersom?

Polyglot

Hi Poyglot,

, ja dat komt voor bij streekbussen en als trein ingezette lijndiensten over grotere afstanden. Maar ook stadsdiensten HTM, RTM en GVB kennen gastbussen die naar een knoooppunt rijden en soms halteren binnen het gebied. Bij stakingen of acties rijden ze dan met gesloten deuren door naar buiten. In Utrecht is alles nu een consessie Q bus dus geen stadsvervoer meer.

Ha Tijmen,

Het zou erg zinvol werk zijn, laat dat duidelijk zijn. Ik gebruik de transport map regelmatig. Het is inderdaad tijd om de data bij te werken. Buslijnen ontstaan, verdwijnen, veranderen, dus het werk is nooit af.

Ik heb geen ervaring met automatische imports van data. Ik vraag me af of je een relatie wel zo makkelijk automatisch kan genereren. De aanpak van Polyglot klinkt goed.

Ik heb ervaring met het invoeren van wandelpaden. Ik begin met een goed gpx bestand, leg dat over de kaart, en maak handmatig de relaties. Als je dat een paar keer gedaan hebt, gaat het snel. Ik gebruik JOSM; niet makkelijk, wel erg goed. Mijn suggestie zou zijn om de eerste buslijnen handmatig in te voeren / aan te passen, want daarmee leer je het principe kennen.

Relaties worden door andere mappers - vooral Potlach gebruikers - makkelijk kapot gemaakt. Ik check regelmatig mijn eigen data. Heeft iemand zitten knoeien, dan stuur ik die persoon een vriendelijk, opbeurend en instructief mailtje. Daarna zijn het vrienden voor het leven. Ik hoop dat er ooit een oplossing komt voor dit probleem want het is een beetje zinloos werk om iets in OSM te zetten wat na verloop van tijd verdampt is.

Henk

Hallo Henk,

Ik heb ook een script dat wandelroutes kan nalopen en dat je kan komen vertellen, wanneer ze onderbroken zijn geraakt. Om dat te kunnen gebruiken moet je dan wel de scripting plugin installeren in JOSM en Jython op je computer. Ik geef de voorkeur aan Python om te scripten, maar JOSM is natuurlijk een JAVA-programma. Jython maakt de brug tussen beide.

Wie interesse heeft om dat eens in actie te zien, die nodig ik graag uit om eens een Google hangout te houden. Ook voor de OV-bewerkingen geef ik graag eens een demonstructie, hoe ik dat aanpak. Ik automatiseer waar mogelijk en de rest is dan handwerk. Wat de OV-relaties betreft, zou ik graag zien dat we met segmentroutes kunnen beginnen te werken. Zolang we dat niet doen, moeten alle wegen lid zijn van alle routerelaties en er zijn nogal wat variantes per lijn. Daarenboven moet voor elk van die variantes die stukgaan, hetzelfde worden uitgevoerd om ze weer allemaal ononderbroken te krijgen. Dat is nogal zinloos werk. Het lijkt erop dat de Duitsers een nieuw voorstel voor OV-mapping gaan doen en daar zou het opdelen van de routes in segmenten bij zitten.

Polyglot

+1 ik sluit aan bij een Hangout sessie.

Ik doe daar graag aan mee. Goed voorstel!

Heb je een bron?

Heel vele nieuwe informatie voor mij.

Ten eerste zal ik even aanvullende informatie over alle niet-OSM-gerelateerde zaken:

  • In Nederland heb je historisch gezien grofweg 2 soorten bedrijven: stadsvervoer en streekvervoer. In de jaren '90 waren grofweg alle streekvervoerders onderdeel van de VSN-groep (Verenigd Streekvervoer Nederland). Technisch is hier een enorme harmonisatie uit ontstaan. Vrijwel alle streekvervoerders hebben zoā€™n 10 keer per jaar een EOD (equipment operating data), waarmee alle route-informatie intern in de systemen gezet wordt, maar ook extern (9292, GOVI, NDOV). Alle dienstregelingwijzigingen vinden plaats op deze EOD-momenten. Als er een tussentijdse dienstregelingwijziging is, dan staat die vaak al in de EOD van daarvoor, met andere lijngeldigheden. In principe zou een update direct na (of voor, de gegevens zijn vaak een week eerder al op het NDOV-loket beschikbaar) een EOD-update mogelijk zijn. Ik weet niet of de EOD-data ook op elkaar afgestemd zijn.

  • Een ander gevolg vanuit de VSN-tijd is dat de meeste halten een uniek haltenummer hebben, de eerste vier cijfers is gelijk aan het zonenummer, de laatste vier zijn bedacht door de plaatselijke vervoerder. In de interne systemen van de verschillende vervoerders zijn deze halten in de loop der jaren uiteen gaan lopen, reden waarom je op bijv. Google Maps soms twee haltes naast elkaar ziet, een met de Syntus-lijn en een met de Connexxion-lijn (bijv op Veenendaal Station Centrum Stationsplein (lijn 83/80 en 85) of Veenendaal Station Centrum Kerkewijk (lijn 80/81/6XX en 505))
    De stadsvervoerders hebben niet deze systematiek van haltenummers, maar vanuit het NDOV wordt dat binnenkort wel geƫist (waarbij we nog veel vragen hebben - zoals wie verzint dan een haltenummer en wie is voor welke halte verantwoordelijk?)

  • Lijnen in ā€œelkaars gebiedā€ komen regelmatig voor - anders zouden er heel veel bushaltes op de provinciegrens eindigen. Zie ook weer bovenstaande link. Lijn 80 van Connexxion Utrecht komt in zijn route 5 keer de provincie- en dus concessiegrens Utrecht-Gelderland over. En lijn 50 rijdt van Wageningen (Gelderland, Syntus) naar Utrecht (BRU-concessie, QBuzz)

Ik denk dat een automatisch routeplan-algoritme halte-halte niet te doen is, zeker niet op lastigere routes, en zo veel controle vergt dat dat dƔn beter handmatig kan. Maar voor in ieder geval de Connexxion-KV1-data is volgens mij de hƩle route bekend, dus dan kan je deze grotendeels op een way fitten - je bent dan al een stuk dichterbij.
Lastig punt daarbij is het verschil in locatie tussen een halte, een halte en een halte. Welke locatie heeft een halte?

  • De haltepaal (juridisch haltepunt)

  • De instaptegel (voor de passagier het belangrijkste punt)

  • De stopplaats van de bus (een bus is 12x2,55 m, dus dat is niet echt een ā€œpuntā€, maar bij Connexxion zit de GPS-antenne op het dak, ongeveer boven de bestuurder)

  • De plaats op de weg, het dichtstbij de haltepaal, instaptegel of stopplaats.

In de eerste drie gevallen zal de route namelijk niet door de halte heen gaan.

Daarnaast verplaatsen haltes zich ook vrij regelmatig. Ik denk dat in mijn jaar als vervoerkundige van alleen Provincie Utrecht-Oost er al zeker 40 haltes opnieuw ingemeten zijn, omdat ze vanwege een renovatie (verhoogd halteperron) een tiental meters verplaatst zijn. Maar bijvoorbeeld een halte als Kaap Doorn (vroeger: Sandenburg), is dat een verplaatsing? In onze systemen wel, en het is hetzelfde haltenummer gebleven, maar de halte heet anders en ligt zoā€™n 400 meter verderop.

Daarnaast vroeg ik mij filosofisch af wat het nut is van het mappen van busroutes. Voor stads- en streekbussen is dat zeker handig want die hebben een redelijk vaste route, maar voor bijvoorbeeld de bus Parijs-Amsterdam (iDbus) vraag ik mij af of deze een vaste route hebben, of bij file ook af mogen wijken (zo is in tijd in de avondspits via Lille sneller, maar overdag en 's nachts via Brussel en ter hoogte van Breda heb je er niets aan om te weten dat er een buslijn over de snelweg loopt als de dichtstbijzijnde halte 100 km verderop is.

Nouja, veel om over na te denken. Ik ben nu een beetje gaar, maar denk en werk er graag over mee. Polyglot: ik wil dat graag zien in die Hangout.

Hi Tijmen, goed idee. Het levendige deel van de haltes kunnen we dan wel zien, maar t blijft een veranderende databank. Het lijkt mij programmeren, ik beperk me wel tot veld werk.

Hallo,

Hier is een link naar die Duitse discussie: http://forum.openstreetmap.org/viewtopic.php?pid=462910

Bij Openstreetmap voorzien we 2 nodes per halte. De ene (wat mij betreft, belangrijkste) geeft ongeveer de positie van de haltepaal weer:

highway=bus_stop
public_transport=platform
bus=yes

of

railway=tram_stop
public_transport=platform
tram=yes

voor een tramhalte. Ze kunnen ook gecombineerd worden in 1 node. Deze nodes staan naast de weg en geven aan waar de passagier staat te wachten.

De andere node maakt deel uit van de weg en heeft de volgende tags:

public_transport=stop_position
bus=yes

of

public_transport=stop_position
tram=yes

Waarbij de stoppositie voor een tramhalte voorkomt op een way met railway=tram. Die tracht ik zoveel mogelijk als aparte ways in te tekenen.

Ik geef er de voorkeur aan om de stop_position nodes niet toe te voegen aan de routerelaties. Ik heb in eerste instantie de stop_positions ook niet overal toegevoegd. Ze zijn, wat mij betreft, minder belangrijk.

Als ik een stop_area relatie aanmaak, voeg ik de stop_positions dan weer wel toe. Ondertussen heb ik ook een script dat binnen JOSM draait, dat automatisch de stop_area relaties aanmaakt op basis van een search naar

public_transport=platform (als node)
public_transport=stop_position
public_transport=platform (als way)
amenity=shelter/shelter_type=public_transport
amenity=bench
amenity=waste_basket

en nog wat zaken zoals metro-ingangen.

die op dat moment zichtbaar zijn in het JOSM-venster.

Zoā€™n hangout kan voor mij op zaterdag-, zondag-, of maandagavond vanaf 19u00.

Jo

Ik reageer later even op de rest - helaas snap ik altijd weinig van het Duits.

Ik zou dit weekend op za en zo kunnen, volgend weekend allen op zo, en ma 1 december. Maar liever later.

Dit jaar zijn alle haltes in Nederland geinventariseerd en komen er nationale haltenummers aan (onafhankelijk van vervoerder) Dit alles kom in het Centraal Haltebestand terecht wat in de komende maanden vrij komt (via NDOV). Mijn inziens zou dit bestand alle bestaande meuk aan haltes die nu nog in OSM staan moeten vervangen.

Daarnaast is het maken van die relaties nogal arbeidsintensief voor werk dat je nooit gaat bijhouden, die routes staan al in Koppelvlak 1 en GTFSā€™en zoals ik deze exporteer op http://gtfs.ovapi.nl/nl/gtfs-nl.zip 95% van de lijnen hebben daarin ook daadwerkelijk buigpunten