OV-Routes

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

Ik heb een screencast gemaakt over hoe ik OV-routes map:

https://www.youtube.com/playlist?list=PLO3wjvbFUESEZ2P-jKzYqtr7HzIs0KXJu

Die hangout zie ik ook nog steeds zitten. De eerste heeft nu ondertitels in het Nederlands en Engels. De anderen, daar moet alles nog aan gebeuren… blijkbaar is het niet mogelijk om daar achteraf ingesproken geluid aan toe te voegen. Ik ben niet intelligent genoeg om tegelijk te praten en te mappen. Die ondertitels hebben ook als voordeel dat ze vlot vertaald kunnen worden.

Jo

Mocht er een hangout gepland worden hou ik me ook aanbevolen, ik kan (meestal) di-do vanaf 19.00uur.
Ik zou voorstellen om een datum te prikken, er zal dan ongetwijfeld reactie komen van personen die willen meedoen aan de sessie.

Met een video edit programma kan dit toevoegen normaal gesproken wel, maar als je zo’n pakket moet kopen is het wel erg prijzig.
Ondertitels werken ook goed toch?

Ik denk dat ondertitels nog de beste oplossing zijn. Er kruipt wat tijd in om ze aan te maken en om ze de juiste timings te geven, maar ze zijn vlot vertaalbaar als dat eenmaal gebeurd is.

Ik heb een blog-artikeltje geschreven over hoe we hier in België OV mappen:

http://osm.be/nl/content/mapping-public-transport-belgium#overlay-context=nl/blog

Voorlopig enkel in het Engels. Ik was er nog niet helemaal klaar mee, maar nu hebben ze dat al vermeld in de Wochennotiz… dus heb ik er wat aan verdergewerkt.

Misschien moeten we maar gewoon volgende week dinsdag prikken voor de hangout. Ik kan wel pas vanaf 20u30.

Ik heb het artikel vertaald naar het Nederlands (en de Engelse versie in mijn dagboek geparkeerd):

http://osm.be/nl/content/mapping-public-transport-belgium

Tijdens een conference call, gisterenavond met Peruaanse mappers, heb ik een nieuw speeltje ontdekt:

https://meet.jit.si/osmbe

Wie weet ga ik daar vanaf nu regelmatig de ‘exhibitionist’ uithangen :slight_smile: (En m’n scherm delen, spannender dan dat wordt het niet)

Zijn er andere geïnteresseerden voor hangout/jitsi conference call dinsdagavond?

Groeten,

Jo

Hallo,

Om 20u vanavond is er een hangout over hoe we het mappen van OV aanpakken in België. Ik zal hier straks de link posten. Sorry dat ik het zo laat aankondig, maar het is lastig voor me om ver vooruit te plannen.

Als het deze keer niet lukt, geen zorgen, er komen zeker nog hangouts.

We hebben dus toegang tot data van 2 van de 3 Belgische transportbedrijven. Ik heb deze data omgezet en dan nog wat scripts geschreven om het toevoegen en bijwerken gemakkelijker te maken.

Zeggen dat het helemaal op punt staat, zou wat overdreven zijn, maar ik denk wel dat het beter is om 's te tonen, wat er al is.

Hier heb ik er een artikeltje over geschreven:

http://osm.be/nl/content/mapping-public-transport-belgium

En dan nog wat posts in mijn dagboek:

http://www.openstreetmap.org/user/Polyglot/diary

Vandaag heb ik daar nog het volgende aan toegevoegd:

http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Public_Transport/Lines

Jo

En hier is de link voor de hangout:

https://plus.google.com/hangouts/_/g523ms3l7mc3nkvgwcyflvgyzea?hl=nl

Goedenavond,

Ik ben recent een weekje op vakantie geweest, in voor Openstreetmap nog geheel OV-maagdelijk gebied (in werkelijkheid rijden er in het gebied 4 bussystemen: de schoolbus, de gratis skibus, de intercommunale bus en Les Autocars des Hautes-Alpes).

Anyway. Druk geweest, dus na Polyglot’s verhelderende en inspirerende hangout heb ik hier weinig meer mee gedaan.

Toevallig kreeg ik vandaag de GOVI-nieuwbrief in de bus én las ik op OVnieuws het bericht dat [de REISinformatiegroep (het bedrijf achter 9292) zijn rol als NDOV-loket nu echt goed ingevuld heeft](http://www.ovpro.nl/management/2015/02/05/nieuwe-site-ndov-loket-voor-ov-brondata-vervoerders/?utm_campaign=0dbddb541c-OVPro_nieuwsbrief_Abellio_wint_in_Limburg2_10_2015&utm_medium=email&utm_source=OVPro&utm_term=0_ba22b85a1a-0dbddb541c-327712325\).
Met name dit laatste is mooi, de data lijkt op het eerste gezicht hier wat actueler en gestructureerder te staan dan op de site van OpenGeo.

Probleem bij de REISInformatieGroep (RIG) zijn de licentievoorwaarden: die lijken wat restrictiever te zijn dan bij OpenGeo*.
Belangrijkste punt uit de licentievoorwaarden is 3.1:
De Datalevering wordt ontwikkeld en is primair geschikt voor het aanbieden van reisinformatie, maar is niet beperkt tot dit gebruik. De Datalevering of een combinatie van Dataleveringen is niet geschikt voor doeleinden met betrekking tot het interpreteren van de prestaties van Vervoerders. De Licentienemer Gebruikt de Datalevering of een combinatie van Dataleveringen niet buiten de reikwijdte en de voorwaarden van de onder deze Datalicentievoorwaarden verleende licentie of aanvullende, specifiek overeengekomen, instructies.
Openstreetmap lijkt mij een vorm van reisinformatie, dus dat mag. Het interpreteren van prestaties van vervoerders berust vooral op het KV6-(actuele data)gebeuren, dat is voor ons niet van belang. Het lijkt er dus op dat we deze data mogen gebruiken voor het beoogde doel.

Maar ik zie geen letterlijke toestemming om de data hiervoor te gebruiken en verderop wordt melding gemaakt dat de data nog steeds onder databankrecht en auteursrecht blijft vallen. Een expliciet verbod op het grootschalig openbaar maken van deze data is er dus ook niet echt.

Is er iemand die goed is in het lezen van licentievoorwaarden en met mij mee kan denken over wat er nou precies wel en niet mag met deze data in relatie tot openstreetmap, volgens de RIS-licentievoorwaarden?

Tijmen

  • Bij OpenGeo vallen de data onder Creative Commons Zero, al vind ik dat vreemd, omdat ik weet dat vanuit mijn bedrijf (Connexxion) ernstige bezwaren zijn tegen het als punctualiteitsdata gebruiken van KV6-data - simpelweg omdat deze data precies genoeg zijn om de reiziger tot op de minuut te informeren, maar niet precies genoeg om secondesgewijze punctualiteiten te berekenen en daar bonus/malus-regelingen aan te hangen.

Ik haak even aan bij deze OV discussie, maar met weer een andere vraag:

Op de bushaltes bij mij in de buurt (Brabant) staat op de haltepaal een QR code. Die kan ik scannen en ik krijg dan direct de actuele bustijden (met. evt. vertragingen) te zien.
Daar heb je dus alleen maar wat aan als je bij die bushalte staat. Je kunt thuis (als je nog je reis aan het plannen bent) natuurlijk ov9292 inschakelen, maar als je snel even de vertrektijden wilt checken, is een andere oplossing handiger.
Je zoekt met taglocator de bus bij jou in de buurt op en klikt op de gewenste halte. Pats! Daar komt dezelfde info tevoorschijn die ook die QR code geeft.
Is het denkbaar dat dat ooit gebeurt?
Welke informatie moet daarvoor door de vervoerder worden gedeeld?
En welke informatie moet er (in OSM) bij die haltepalen worden vastgelegd? (Lijnnummers? Halte-ID?)

Zo’n QR-code is niet anders dan een gecodeerde weergave van een lijn tekst. Gewoonlijk een url. Als je nu het gedeelte dat varieert tussen deze urls toevoegt aan ref of ref:9292, oid, dan kan je ervoor zorgen dat een site als Openlinkmap datgene doet wat jij graag zou zien:

Een voorbeeld met een halte in Vlaanderen:

http://www.openlinkmap.org/?lat=50.88015959999987&lon=4.708434299999976&zoom=18&id=80725474&type=node&lang=nl

Klik op 1 van die blauwe bushaltes, dan realtime vertrektijden: mijnlijn.be https://www.delijn.be/nl/haltes/halte/303059

Het enige wat op de halte staat is ref:De_Lijn=303059

Dat wordt door openlinkmap omgezet in http://mijnlijn.be/303059 en door de website van De Lijn in die lange url.

Jij kan in je taglocator natuurlijk iets gelijkaardigs gaan doen.

Heb je een mapillary foto met zo’n QR-code?

Jo

Daar ga ik een naar kijken.
Ik weet niet of de situatie in NL hetzelfde is, maar voor België kan ik het wel werkend krijgen.

Er is wel iets raars aan de hand, want hier:
http://www.openlinkmap.org/?lat=51.9207&lon=4.45465&zoom=17&id=80725474&type=node&lang=nl&layers=BFTTTTT
zie je een bushalte in Rotterdam en voor de vertrektijden wordt je verwezen naar een Belgische site (die daar geen info over heeft).

En deze is nog komischer:
http://www.openlinkmap.org/?lat=51.9207&lon=4.45465&zoom=17&id=80725474&type=node&lang=nl&layers=BFTTTTT

Dat niet.