We (the Norwegian Road Administration) have received some intriguing questions about the API to the Norwegian Road Data Base. Unfortunately for Non-Norwegian programmers, all documentation is in Norwegian only. Hopefully, this very brief introduction may motivate you to learn a very beautiful language. (It aint that hard – even the children here speak it fluently). Or perhaps we some day should adapt to the other 99.93% of the population and provide documentation in English…
Update 2020: Use version 3 of NVDB api https://nvdbapilesv3.docs.apiary.io/#
Update 2016: Use version 2 of NVDB api http://api.vegdata.no/
Virtually all data in the Norwegian Road Data (NVDB) base are available under the Norwegian Licence for Open Government Data (NLOD), without carge.
There is also some minimum functionality for serving the topological road network (which you can navigate from A to B) through NVDB api, but with some caveats. (You can get the network links, but need to reverse-engineer the nodes and puzzle together the network yourself). If you want road data for navigational purposes you should have a look at the data we use in our own route planner (esri and spatialLite formats).
Besides the road network itself, the NVDB has of lots of data attached to the road network (think of those as anything road related found along the topological network). We have more than 300 different types of objects tied to the road network: Speed limits, toll station, traffic flow, traffic accidents, curvature, … the list goes on. Those objects are all defined in our data catalogue. (The official version is a java program, you’ll find a link to it here, most of you will probably prefer our unofficial web version). And (virtually) all of those data are available through our road database (NDRB) api.
The data structure in the NVDB API may seem a little complex at first, in particular if you expect everything to have a straightforward name – value data structure. Each object has a list of egenskaper (properties, plural), containing any number of the element egenskap (property, singular). Each egenskap (property) has an ID, a name (navn), a value (verdi) and a link to it’s own definition in the data catalogue.
To find what it actually costs to pass the station you’d search through the list of egenskaper for the egenskap with ID = 1820 and inspect that value (verdi). You’d probably expect the value to be in Norwegian Kroner, and you’d be right — which is confirmed by the tag enhet (unit).
And don’t forget the API’s twin companion Vegkart, which is a web application that shows data directly from our API. Seeing the objects location and probing their properties might be helpful to those unfamiliar with our API. Your successful Vegkart-query contains a download-link that takes you directly to NVDB api.
Any results from a successful Vegkart query can be downloaded (as csv or excel), but with some caveats: The excel/csv-dump doesn’t preserve all coordinate information, and no information at all about any relationships between objects.