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 ?
Maar wat nu het probleem ook nog is: bij veel haltepalen van Arriva (voorheen Veolia) staat nu helemaal geen informatie over zone en halte.
Dat moet dus eerst voor elkaar worden gebracht.
Is het denkbaar dat dat bestand met (met die 32900 haltes) gebruikt gaat worden voor geautomatiseerde invoer? Want dan heb je iets waar je ook wat aan hebt. Als ik een bustijd wil weten (als gewone gebruiker) en ik kan die halte niet eens vinden op OSM dan ga ik natuurlijk weer naar ov9292 waar het wél in staat.
En bovendien maken dergelijke ervaringen met onjuiste/ontbrekende gegevens dat mensen niet gauw terugkomen voor andere zaken (“ja maar die bushalte stond ook niet op OSM, waarom zou dat restaurant er wel op staan?”)
OSM is niet bedoeld voor mappers, OSM moet voor gewone stervelingen zijn die snel iets willen opzoeken op de kaart met zo weining mogelijk drempels op technisch/interface gebied en met maximaal resultaat!
Ik heb nu zelf even met de mogelijkheden van OpenPoiMap zitten spelen als het gaat over het opzoeken van bustijden (ik ben fervent OV gebruiker) en moet zeggen dat het heel handig is om bij een bushalte waar ik straks moet zijn even op te zoeken wáár die halte is (fluitje van een cent) en dan te kunnen klikken op de vertrekstaat van die halte. En dat is bij Connexxion dus ook een fluitje van een cent. Nou die anderen nog…
Helemaal mee eens, maar als je die informatie hebt, moet je wel een afspraak hebben over aan welke tag je de informatie gaat hangen. Overigens hebben we vorig jaar in minder dan een jaar met een relatief kleine groep een paar miljoen panden en adressen in OSM gekregen. Over die 32900 haltes maak ik me niet zo heel erg druk. Het is inderdaad wel goed om het zo compleet mogelijk te hebben voor je het aan het grote publiek bekend maakt.
Voor de haltes met een geldige cxx:code tag (ook in de regio Utrecht, waar nu U-OV zit) heb ik het voor elkaar.
Kijk selecteer op www.gertjanidema.nl/osmlayers de Various->busstop laag aan en klik op een van de bushaltes. Als de halte een geldige cxx:code tag heeft, verschijnt een button met de tekst Bustimes. Hier op klikken geeft een nieuwe Popup met de vertrektijden van de eerstvolgende bussen.
De opmaak laat nog te wensen over en sorteren gaat nog niet goed voor bussen die na middernacht vertrekken, maar dat fix ik binnenkort.
Ziet er goed uit! Ik mis overigens bij de businformatie het lijnnummer van de bus, en dat is soms ook wel eens handig om te weten, zeker als er meerdere bussen bij een halte stoppen. Ik zie dat busnummer overigens ook niet terug in dat databestand. Omdat ik in mijn oplossing een link naar de haltepaal informatie van Connexxion gebruik (bv. http://haltepagina.connexxion.nl/home/index?halte=59570190)) zie ik dat busnummer wel.
Nu ik openpoimap/taglocator op versie 1 heb staan, en er in ieder geval mee te werken valt, kan ik wat meer tijd besteden aan het bestuderen van die widgetoplossing, want die vind ik heel bruikbaar.
(En m’n scherm delen, spannender dan dat wordt het niet)
