Her er et søtt lite eksempel på hvordan man kan hente bomstasjoner fra NVDB api’et i python og lagre dem som CSV-fil. Koden brukes til oppdatering av bomstasjon-datasettet på difi’s datahotell en gang i døgnet.
Koden burde vært datakatalogdrevet – men er det ikke. Det er altså fullt mulig at koden vil knekke ved fremtidige revisjoner av datakatalogen (såfremt bomstasjonenes egenskaper endres). Koden virker i hvert fall mot versjon 1.97 (gyldig fra mars-2014). (Det er svært lite sannsynlig at de egenskapene vi bruker vil bli endret; men manglende sjekk av datakatalogen er lite robust, og det bør man være klar over).
Koden bruker søkefunksjonen beskrevet her. Zip-fil med kode: bomstasjoner
Men — siden vi ber om ALLE bomstasjonene hadde det mest elegante vært å la være å bruke søkefunksjonen i det hele tatt… I stedet kan vi rett og slett laste ned alle vegobjekter av type 45: https://www.vegvesen.no/nvdb/api/vegobjekter/45/?rows=1500 (obs! nettleseravhengig hva som skjer når du klikker denne lenken- google chrome vil typisk vise en XML-fil i nettleseren; andre nettlesere vil kanskje laste ned geojson eller gi en feilmelding).
Tilføyelse: Denne rutinen bruker shapely-biblioteket for å lese geografiske koordinater formattert som «Well known text«. Shapely avhenger igjen av GEOS, et sett med C-baserte rutiner. Installasjon skal være rett fram for både linux og windows, men sjekk shapely-dokumentasjonen for detaljer. Man er selvsagt ikke avhengig av shapely-biblioteket for å trekke tallverdier ut fra en tekststreng med X og Y koordinater, men det er dårlig stil å finne opp hjulet flere ganger.
Tilføyelse 2014-03-06: Koden måtte modifiseres fordi søkefunksjonen nå kun returnerer ett koordinatsystem. Vi ønsker posisjon med lengde- og breddegrad, og må da eksplisitt angi parameteren &geometri=WGS84 i kallet til søkefunksjonen, ellers får vi kun UTM33-koordinater.
Tilføyelse 2014-04-24: nvdbapi.py sin kontroll av at vi får riktig datatype fra API’et (http header Content-type = application/vnd.vegvesen.nvdb-v1+json) var litt klønete: streng på en litt feil måte, med forvirrende feilmelding. Dette tryna da også på en ufin måte når API’et begynte å føye til charset=utf-8 til denne headeren.