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
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.
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:
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.
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.
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.
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:
Voor Connexxion werkt het nu (en onder voorbehoud dat iemand de moeite heeft genomen om de info in osm te plaatsen):
Opvallend is dan ook weer de vele haltes in osm waar alleen maar staat dát het een halte is…
(Je kunt ook mooi zien dat de marker nu goed geplaatst is met dat puntje… )
Sinds afgelopen december is er een universele standaard voor alle haltes in Nederland. Elke haltepaal heeft een haltecode die bestaat uit 8 cijfers. Voor de streekvervoerbedrijven is dat het 4-cijferige zonenummer haltenummer en dan 4 cijfers voor de halte. Voor de stadsvervoerders GVB, RET en HTM is het “zonenummer” respectievelijk 3000, 3100 of 3200. Officieel hoort voor het 8-cijferige nummer nog ‘NL:Q:’ (volgens de IFOPT/standaard voor Quays, ofwel een halteplaats in één richting). De halte Máximaplein in Leusden ligt in zone 5045 en heeft daarmee haltenummers 50450750 en 50450760. De (leesbare) informatie hiervoor kan je opvragen bij Connexxion, op bijv. http://connexxion.nl/dienstregeling/halte?id=50450760, maar dat werkt alleen met Connexxion-haltes.
Ik weet zo 123 geen webservices die de volledige halteinformatie voor alle haltes in een voor mensen leesbaar formaat tonen. Een voor machines leesbaar formaat is te vinden op de REST-api van OpenOV: http://v0.ovapi.nl/tpc/50450760, of voor beide richtingen: http://v0.ovapi.nl/stopareacode/leumax/
Ik heb de code iets vereenvoudigd om ruimte te winnen, en de code nu nu bij “Stop” staat, staat ook bij iedere regel vooraan. Begrijp ik goed dat die code de code van de haltepaal is?
Soms ontbreekt die (nummerieke) code:
Van zodra ze bij TEC een goed werkend systeem hebben uitgewerkt, zal ik je laten weten hoe dat ook voor het zuiden van het land kan aanbieden. Ze hebben ook real-time informatie, maar de naam van de halte maakt deel uit van de url en ik heb die namen ‘gecorrigeerd’, ‘genormaliseerd’, of hoe je het ook wilt noemen. Zij hadden alles in hoofdletters geschreven, wschl net om problemen met accenten uit de weg te gaan en ik heb dat ‘verbeterd’, naar kleine letters met accenten, wat voor Franse namen zo vreemd niet is.
De haltes hebben ook codes en je kan die zelfs meegeven in de url, maar als je de naam niet meegeeft, werkt het niet. Onbegrijpelijk eigenlijk en nog onbegrijpelijker dat ze er niet in slagen om dat snel op te lossen. Maar goed, c’est la vie.
Yep. Dit moet een paal in zone 6211 zijn, dat klopt ook want dat is de zone van Vught (zie http://www.openov.nl/zones/ )
Dat is vreemd. Elke* halte(paal) heeft een haltenummer, en sommige (maar lang niet alle) halten hebben een placecode. Een placecode bestaat altijd uit de eerste drie letters voor de plaatsnaam (Vgt) en dan 2 of 3 letters (soms cijfers) voor de naam van de halte. Maar een placecode hangt altijd aan een setje haltes (2 of meer)**, het zijn vaak de wat belangrijker haltes. Maar die halte zou nog steeds een haltenummer moeten hebben.
Volgens de standaard van GOVI zou, als er bijv vanwege plaatsgebrek maar 1 haltepaal is voor 2 richtingen (bijv. aan een smalle dijk), er toch 2 haltenummers gebruikt moeten worden. Op bijv. Station Bijlmer gebeurt het omgekeerde, daar zijn 2 haltepalen+perrons met maar 1 nummer. Dit zijn de haltes voor R-net 300, die zo frequent rijdt (in de spits elke 6 minuten) dat die voor het ontladen + buffertijd + inladen niet voldoende heeft aan één perron.
** Een placecode kan zelfs (al zou dat niet moeten) aan meerdere haltes van dezelfde lijn+richting hangen. Zo was bijvoorbeeld Vndnsc (Veenendaal NS Centrum) de placecode voor 4 haltes: Veenendaal Station Centrum Kerkewijk (2x) (40801470 en 80), Veenendaal Station Centrum Stationsplein (40805120), en Veenendaal Station Centrum Bernhardlaan (40501540). Bijv lijn 83 deed na elkaar de Bernhardlaan en het Stationsplein hangen, waardoor de reisinformatie (die aan de placecode hangt) niet goed ging omdat daar die al bij halte Bernhardlaan dacht dat 'ie op z’n eindpunt was.
In Duitsland wordt op OSM gebruik gemaakt van deze tag: http://wiki.openstreetmap.org/wiki/Key:ref:IFOPT
Misschien kunnen we daar op aansluiten. Een dergelijke tag is internationaal en niet gekoppeld aan een OV bedrijf. De meeste haltes in Utrecht hebben een cxx:code tag, terwijl hier inmiddels U-OV zit. De code klopt echter nog wel.
Als de cxx:code=50000030 tag vervangen zou worden door ref:IFOPT=nl:5000:0030, zou je dat probleem niet meer hebben. Als er een operator=Connexxion tag is kan je de halteinformatie op connexxion.nl terugvinden. Maar deze is natuurlijk ook al te vinden op http://v0.ovapi.nl/tpc/50000030. Die paar regels javaScript om van het json resultaat leesbare HTML te maken zijn zo te schrijven. Dat lukt me vanavond misschien nog wel.
Wat doe je in zo’n geval eigenlijk voor dynamische haltes, zoals in Nijmegen, waar een lijn van meerdere perrons van het busstation bij Nijmegen NS kan vertrekken ? Of tag je het hele busstation dan als 1 item ?
(En m’n scherm delen, spannender dan dat wordt het niet)
