Petter Reinholdtsen

I følge Ivar Johansen er det ca ti år siden Finanskomiteen i Oslo kommune vedtok "Byrådet bes legge til rette for at en elektronisk oversikt over alle kommunale eiendommer er tilgjengelig for oppslag på kommunens nettsider." Har ikke klart å finne vedtaket i offisielle nettsider fra kommunen, men i og med at kommunen har publisert oversikt over eiendommer de eier selv, desverre sist oppdatert for fire år siden (juni 2017), så kan det virke som vedtaket i hvert fall for en periode tok effekt.

Oversikten fra kommunen er et regneark med tomter og bygg, med tilhørende metainformasjon om adresse, areal etc. Det er jo et greit datagrunnlag, men ikke spesielt egnet for å få oversikt. Det inspirerte meg til å lage en KML-fil der informasjon fra kommunens liste kombineres med geografisk posisjon og utstrekning fra Matrikkelen slik den vises frem på Kartverkets tjeneste Se Eiendom, og slik få et interaktivt kart som viser komunens eiendommer. I første omgang viser den de 6824 tomtene i listen over eiendommer i Oslo kommune (og ikke utenbys tomter), unntatt de 268 gårds- og bruksnummerene uten informasjon om geografisk posisjon i Matrikkelen og de 346 gårds- og bruksnummerene som mangler helt i Matrikkelen. Det er vanskelig å vite hvilke av de sistenevnte som er feil i datagrunnlaget fra kommunen og hvilke som er et resultat av utdatert informasjon i et fire år gammelt datasett. Mer om det senere.

Hvis du vil se på KML-datasettet, så kan du enten gjøre som meg, bruke Marble på Linux, eller du kan laste ned et av de mange andre verktøyene som leser KML-filer, som Google Earth, JOSM og QGis. Har desverre ikke funnet en nettjeneste som kan vise frem filen i en nettleser, på grunn av filstørrelsen. Fant en OpenstreetMap-basert nettside som håndterte mindre filer, men den ga opp da hele kommunens areal var inkludert i filen.

KML-datasettet kan lastes ned her fra min blogg. Tomter med bygninger i følge matrikkelen er markert i rødt, mens tomter uten bygninger er markert i blått. De få tomtene med posisjon men uten utstrekning (tror alle er under bakken) har kun fått posisjonsmarkører. Jeg har i denne omgang begrenset meg til tomter og ikke tegnet inn hus, da jeg ikke fant noen enkel måte å hente ut geografisk utstrekning for husene basert på informasjonen i kommunens datasett. Konkret mangler jeg sikker måte å identifisere enkeltbygninger basert på kommunens oversikt. Vedlagt er et skjermbilde fra Marble som viser hvordan det kan se ut.

På grunn av oppløsningen viser ikke bildet alle gatene og mindre eiendommer i sentrum som er eid av kommunen. Dette vises når en dykker ned i materialet med en KML-fremviser. Jeg har ikke regnet på det, men visuelt ser det ut som om kommunen eier 25-30% av alt arealet i kommunen, hvilket jeg fant overraskende. Lurer på hvor stor del av arealet i Oslo totalt som er eid av ulike offentlige aktører. Vet jo at ulike departementer, direktorater, fylkeskommuner, kommunale pensjonskasser, og offentlig majoritetseide selskaper også eier en god del av eiendommene i Oslo. Det hadde vært interessant å vise frem, men mistenker innsynsforespørslene for å få tak i det datasettet kommer til å være en kamp i motbakke, både hvis en forsøker hver enkelt offentlig instans eller Matrikkelen.

Fra kartet kan en se at endel tomtearealer er markert flere ganger. Det skjer hvis kommunens oversikt henviser til matrikkel-tomter med overlappende areal. Hvis det finnes to ulike arealer med og uten bygninger så blir fargen lilla, ellers blir fargen sterkere enn hvis det bare et gårds- og bruksnummer for et gitt areal. Jeg antar dette kommer av utdatert informasjon i oversikten fra kommunen kombinert med tilgang på geografisk informasjon om ikke lenger gjeldende tomter i Matrikkelen, for eksempel ved at en eiendom er delt i flere biter, og kommunens oversikt inneholder oppføring av gårds- og bruksnummer før og etter oppdeling. Hver av disse bør undersøkes og korrigeres individuelt, men i og med at jeg ikke har mulighet til å fikse feil hos hverken kommunen eller kartverket har jeg ikke brukt tid på dette.

Det norske eiendomsregisteret, Matrikkelen, endres hele tiden. Det skjer blant annet ved ved fradeling og sammenslåing. Fire år er lang tid i så måte. Jeg antar det kan forklare noen av eiendommene kommunen hevder å eie som mangler informasjon i Matrikkelen, men neppe alle. Noen av dem er nok også feil i kommunens datasett. Utfordringen er å finne hvilke det gjelder. Hvis du har lyst til å se på detaljene, så er lenker til aktuelle gårds- og bruksnummer for de to problematiske kategoriene samlet under.

Et eksempel i så måte er 0301-999/11, som kommunens oversikt forteller er "GULLKROKEN 4M IKKE TINGLYST VEI" med Bymiljøetaten som ansvarlig etat, og kartverket sier er 0 kvadratmeter og uten registrerte teiger. Mitt gjett her er at kommunen ikke har registrert det jeg mistenker kan være veien til husene i lokalområdet i Matrikkelen, det vil si veien er fradelt fra 0301-31/244, og at kommunen så langt ikke har registrert teigen i Matrikkelen, men kan ikke vite sikkert. Det virker litt rart at det ikke er gjort på de fire årene som har gått siden oversikten fra kommunen ble publisert.

Dette er de 268 gårds- og bruksnummerene uten informasjon om geografisk posisjon i Matrikkelen: 2/173, 2/174, 2/384, 2/58, 3/133, 3/164, 3/346, 3/347, 3/348, 3/349, 3/368, 3/635, 5/14, 5/64, 5/78, 6/187, 6/219, 6/25, 6/56, 6/59, 9/147, 9/149, 9/155, 9/156, 9/158, 9/159, 10/385, 10/445, 27/2382, 27/677, 27/716, 27/75, 28/430, 30/47, 31/194, 31/195, 33/1083, 33/11, 33/1194, 33/1195, 33/1196, 33/1197, 33/1198, 33/1199, 33/1239, 33/330, 33/345, 33/346, 33/347, 33/348, 33/458, 33/512, 34/3, 35/435, 35/675, 36/185, 36/38, 37/101, 37/25, 38/203, 38/234, 38/235, 41/193, 41/381, 41/406, 47/19, 47/2, 47/75, 47/76, 49/3, 50/10, 50/11, 50/12, 50/13, 50/233, 50/9, 52/1143, 53/253, 53/35, 54/264, 54/265, 57/279, 57/297, 58/173, 58/196, 58/197, 59/239, 59/66, 64/9, 65/20, 66/15, 66/22, 69/15, 69/20, 69/38, 69/39, 69/40, 69/41, 69/42, 69/43, 70/3, 70/4, 70/6, 72/182, 72/25, 72/26, 72/27, 73/313, 73/638, 73/673, 73/719, 74/8, 77/153, 77/154, 77/155, 77/156, 77/157, 77/22, 79/25, 79/74, 86/50, 86/513, 86/515, 88/209, 88/210, 88/211, 90/536, 93/158, 93/200, 93/204, 93/205, 93/207, 93/208, 93/217, 93/218, 93/351, 93/5, 93/603, 94/531, 94/81, 95/16, 96/180, 97/44, 98/12, 98/13, 98/14, 98/19, 102/424, 102/447, 104/6, 105/188, 105/189, 107/167, 109/3, 112/24, 112/27, 114/23, 120/13, 122/19, 122/25, 122/369, 126/95, 126/96, 126/97, 127/11, 127/67, 131/31, 137/121, 138/16, 140/120, 141/26, 144/692, 146/200, 146/201, 146/202, 146/203, 146/204, 146/205, 146/206, 146/207, 146/208, 146/209, 146/210, 146/211, 146/557, 147/54, 148/503, 149/429, 149/958, 150/107, 151/281, 151/6, 152/162, 152/20, 154/24, 157/214, 162/286, 166/3, 168/31, 168/5, 171/31, 171/6, 174/4, 177/5, 182/109, 182/114, 182/147, 182/344, 182/652, 182/725, 182/727, 182/728, 182/729, 182/744, 182/936, 191/171, 194/49, 196/66, 197/216, 197/218, 197/305, 197/358, 198/16, 208/439, 209/321, 209/322, 209/377, 212/21, 213/33, 213/74, 214/468, 215/248, 215/44, 216/166, 216/82, 219/200, 219/300, 221/276, 221/58, 222/124, 222/6, 224/185, 224/346, 224/93, 225/231, 225/306, 225/32, 225/400, 225/414, 228/22, 228/47, 230/310, 231/142, 231/144, 231/23, 231/521, 233/169, 233/176, 233/178, 233/301, 234/52, 234/53, 236/76, 236/9, 441/1, 480/1, 999/11 og 999/134

Dette er de 346 gårds- og bruksnummerene som mangler i Matrikkelen (Matrikkelen sier "eiendommen er utgått"): 2/559, 2/563, 2/641, 2/642, 3/555, 5/111, 11/598, 11/608, 27/2113, 27/2261, 27/326, 27/405, 27/644, 28/363, 28/446, 28/447, 28/491, 28/492, 28/493, 28/494, 28/495, 28/496, 28/497, 31/218, 31/352, 31/353, 31/356, 31/359, 31/383, 31/384, 31/420, 31/425, 31/427, 31/434, 31/437, 32/433, 32/434, 32/435, 32/436, 32/815, 33/1088, 33/1224, 33/1237, 33/1238, 33/1258, 33/1339, 33/1340, 33/1341, 33/1342, 33/203, 33/302, 33/4, 33/7, 33/8, 33/809, 33/810, 33/813, 33/870, 34/7, 35/469, 35/470, 36/189, 36/191, 36/192, 36/193, 36/194, 44/0, 52/1109, 52/1197, 53/484, 54/181, 54/185, 54/200, 54/201, 54/202, 54/203, 73/135, 73/159, 73/466, 73/614, 73/615, 73/616, 73/617, 73/618, 73/619, 73/620, 73/621, 73/633, 73/672, 73/674, 73/675, 73/676, 73/678, 73/679, 73/687, 73/794, 75/598, 75/599, 75/600, 75/601, 75/602, 75/603, 75/604, 75/605, 75/607, 75/608, 75/610, 75/611, 75/613, 75/616, 75/617, 75/618, 75/619, 75/620, 75/622, 75/734, 75/763, 75/764, 75/765, 75/766, 75/767, 75/768, 75/769, 75/770, 75/771, 75/772, 75/773, 75/774, 75/775, 75/776, 75/777, 75/778, 75/779, 75/780, 75/781, 75/782, 75/783, 76/145, 76/146, 76/147, 76/148, 76/149, 76/150, 76/151, 76/152, 76/153, 76/154, 76/155, 76/156, 76/157, 76/158, 85/23, 86/541, 86/922, 88/222, 91/143, 92/121, 92/171, 92/90, 93/283, 93/284, 93/285, 94/11, 94/436, 94/503, 94/504, 94/6, 95/307, 95/50, 105/380, 105/476, 106/263, 122/103, 122/110, 122/111, 122/309, 122/337, 123/778, 128/116, 129/87, 130/172, 130/192, 132/59, 132/60, 132/61, 132/62, 132/63, 132/64, 132/65, 132/66, 132/67, 133/11, 138/97, 140/154, 141/47, 143/604, 144/1064, 144/1357, 144/150, 144/1895, 144/314, 144/814, 144/870, 144/871, 144/872, 144/873, 144/874, 144/875, 144/876, 144/877, 144/878, 144/969, 146/349, 148/179, 148/180, 148/181, 148/528, 149/986, 150/103, 151/237, 151/240, 151/255, 151/256, 151/268, 151/269, 151/270, 151/273, 151/274, 151/275, 151/277, 151/280, 151/291, 151/293, 151/299, 151/304, 151/338, 157/35, 159/245, 159/323, 159/338, 160/163, 164/247, 164/249, 167/313, 175/6, 176/25, 176/31, 177/7, 180/7, 190/222, 190/223, 190/225, 190/226, 190/227, 190/228, 190/229, 190/230, 190/231, 190/232, 191/69, 197/101, 197/117, 197/138, 197/145, 197/158, 197/159, 197/160, 197/167, 197/183, 197/22, 197/318, 197/68, 207/462, 207/75, 212/0, 223/38, 224/376, 225/178, 225/424, 225/425, 225/47, 229/152, 230/280, 230/282, 230/475, 230/476, 230/477, 230/478, 230/479, 230/94, 230/95, 230/96, 230/98, 232/62, 233/272, 233/273, 233/274, 233/502, 234/48, 235/53, 236/195, 250/41, 385/0, 485/0, 507/0, 509/0, 516/0, 517/0, 518/0, 999/109, 999/170, 999/221, 999/245, 999/25, 999/273, 999/283, 999/317, 999/338, 999/339, 999/349, 999/38, 999/394, 999/417, 999/471, 999/492, 999/58, 999/581, 999/601, 999/612, 999/636, 999/643, 999/646, 999/654, 999/655, 999/676, 999/76, 999/786, 999/788, 999/819, 999/822, 999/825, 999/849, 999/857, 999/862, 999/866 og 999/884

Som vanlig, hvis du bruker Bitcoin og ønsker å vise din støtte til det jeg driver med, setter jeg pris på om du sender Bitcoin-donasjoner til min adresse 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b. Merk, betaling med bitcoin er ikke anonymt. :)

Oppdatering 2020-07-05: Ble tipset om offisielle kilder fra kommunens behandling. Vedtaket var del av sak 133 i protokoll fra finanskomiteens møte onsdag 19. oktober 2011 kl. 16:30, og kom som resultat av følgende utveksling med spørsmål og svar.

Just 15 days ago, I mentioned my submission to IANA to register an official MIME type for the SOSI vector map format. This morning, just an hour ago, I was notified that the MIME type "text/vnd.sosi" is registered for this format. In addition to this registration, my file(1) patch for a pattern matching rule for SOSI files has been accepted into the official source of that program (pending a new release), and I've been told by the team behind PRONOM that the SOSI format will be included in the next release of PRONOM, which they plan to release this summer around July.

I am very happy to see all of this fall into place, for use by the Noark 5 Tjenestegrensesnitt implementations.

As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

As part of my involvement in the work to standardise a REST based API for Noark 5, the Norwegian archiving standard, I spent some time the last few months to try to register a MIME type and PRONOM code for the SOSI file format. The background is that there is a set of formats approved for long term storage and archiving in Norway, and among these formats, SOSI is the only format missing a MIME type and PRONOM code.

What is SOSI, you might ask? To quote Wikipedia: SOSI is short for Samordnet Opplegg for Stedfestet Informasjon (literally "Coordinated Approach for Spatial Information", but more commonly expanded in English to Systematic Organization of Spatial Information). It is a text based file format for geo-spatial vector information used in Norway. Information about the SOSI format can be found in English from Wikipedia. The specification is available in Norwegian from the Norwegian mapping authority. The SOSI standard, which originated in the beginning of nineteen eighties, was the inspiration and formed the basis for the XML based Geography Markup Language.

I have so far written a pattern matching rule for the file(1) unix tool to recognize SOSI files, submitted a request to the PRONOM project to have a PRONOM ID assigned to the format (reference TNA1555078202S60), and today send a request to IANA to register the "text/vnd.sosi" MIME type for this format (referanse IANA #1143144). If all goes well, in a few months, anyone implementing the Noark 5 Tjenestegrensesnitt API spesification should be able to use an official MIME type and PRONOM code for SOSI files. In addition, anyone using SOSI files on Linux should be able to automatically recognise the format and web sites handing out SOSI files can begin providing a more specific MIME type. So far, SOSI files has been handed out from web sites using the "application/octet-stream" MIME type, which is just a nice way of stating "I do not know". Soon, we will know. :)

As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

Did you ever wonder where the web trafic really flow to reach the web servers, and who own the network equipment it is flowing through? It is possible to get a glimpse of this from using traceroute, but it is hard to find all the details. Many years ago, I wrote a system to map the Norwegian Internet (trying to figure out if our plans for a network game service would get low enough latency, and who we needed to talk to about setting up game servers close to the users. Back then I used traceroute output from many locations (I asked my friends to run a script and send me their traceroute output) to create the graph and the map. The output from traceroute typically look like this:

traceroute to www.stortinget.no (85.88.67.10), 30 hops max, 60 byte packets
 1  uio-gw10.uio.no (129.240.202.1)  0.447 ms  0.486 ms  0.621 ms
 2  uio-gw8.uio.no (129.240.24.229)  0.467 ms  0.578 ms  0.675 ms
 3  oslo-gw1.uninett.no (128.39.65.17)  0.385 ms  0.373 ms  0.358 ms
 4  te3-1-2.br1.fn3.as2116.net (193.156.90.3)  1.174 ms  1.172 ms  1.153 ms
 5  he16-1-1.cr1.san110.as2116.net (195.0.244.234)  2.627 ms he16-1-1.cr2.oslosda310.as2116.net (195.0.244.48)  3.172 ms he16-1-1.cr1.san110.as2116.net (195.0.244.234)  2.857 ms
 6  ae1.ar8.oslosda310.as2116.net (195.0.242.39)  0.662 ms  0.637 ms ae0.ar8.oslosda310.as2116.net (195.0.242.23)  0.622 ms
 7  89.191.10.146 (89.191.10.146)  0.931 ms  0.917 ms  0.955 ms
 8  * * *
 9  * * *
[...]

This show the DNS names and IP addresses of (at least some of the) network equipment involved in getting the data traffic from me to the www.stortinget.no server, and how long it took in milliseconds for a package to reach the equipment and return to me. Three packages are sent, and some times the packages do not follow the same path. This is shown for hop 5, where three different IP addresses replied to the traceroute request.

There are many ways to measure trace routes. Other good traceroute implementations I use are traceroute (using ICMP packages) mtr (can do both ICMP, UDP and TCP) and scapy (python library with ICMP, UDP, TCP traceroute and a lot of other capabilities). All of them are easily available in Debian.

This time around, I wanted to know the geographic location of different route points, to visualize how visiting a web page spread information about the visit to a lot of servers around the globe. The background is that a web site today often will ask the browser to get from many servers the parts (for example HTML, JSON, fonts, JavaScript, CSS, video) required to display the content. This will leak information about the visit to those controlling these servers and anyone able to peek at the data traffic passing by (like your ISP, the ISPs backbone provider, FRA, GCHQ, NSA and others).

Lets pick an example, the Norwegian parliament web site www.stortinget.no. It is read daily by all members of parliament and their staff, as well as political journalists, activits and many other citizens of Norway. A visit to the www.stortinget.no web site will ask your browser to contact 8 other servers: ajax.googleapis.com, insights.hotjar.com, script.hotjar.com, static.hotjar.com, stats.g.doubleclick.net, www.google-analytics.com, www.googletagmanager.com and www.netigate.se. I extracted this by asking PhantomJS to visit the Stortinget web page and tell me all the URLs PhantomJS downloaded to render the page (in HAR format using their netsniff example. I am very grateful to Gorm for showing me how to do this). My goal is to visualize network traces to all IP addresses behind these DNS names, do show where visitors personal information is spread when visiting the page.

When I had a look around for options, I could not find any good free software tools to do this, and decided I needed my own traceroute wrapper outputting KML based on locations looked up using GeoIP. KML is easy to work with and easy to generate, and understood by several of the GIS tools I have available. I got good help from by NUUG colleague Anders Einar with this, and the result can be seen in my kmltraceroute git repository. Unfortunately, the quality of the free GeoIP databases I could find (and the for-pay databases my friends had access to) is not up to the task. The IP addresses of central Internet infrastructure would typically be placed near the controlling companies main office, and not where the router is really located, as you can see from the KML file I created using the GeoLite City dataset from MaxMind.

I also had a look at the visual traceroute graph created by the scrapy project, showing IP network ownership (aka AS owner) for the IP address in question. The graph display a lot of useful information about the traceroute in SVG format, and give a good indication on who control the network equipment involved, but it do not include geolocation. This graph make it possible to see the information is made available at least for UNINETT, Catchcom, Stortinget, Nordunet, Google, Amazon, Telia, Level 3 Communications and NetDNA.

In the process, I came across the web service GeoTraceroute by Salim Gasmi. Its methology of combining guesses based on DNS names, various location databases and finally use latecy times to rule out candidate locations seemed to do a very good job of guessing correct geolocation. But it could only do one trace at the time, did not have a sensor in Norway and did not make the geolocations easily available for postprocessing. So I contacted the developer and asked if he would be willing to share the code (he refused until he had time to clean it up), but he was interested in providing the geolocations in a machine readable format, and willing to set up a sensor in Norway. So since yesterday, it is possible to run traces from Norway in this service thanks to a sensor node set up by the NUUG assosiation, and get the trace in KML format for further processing.

Here we can see a lot of trafic passes Sweden on its way to Denmark, Germany, Holland and Ireland. Plenty of places where the Snowden confirmations verified the traffic is read by various actors without your best interest as their top priority.

Combining KML files is trivial using a text editor, so I could loop over all the hosts behind the urls imported by www.stortinget.no and ask for the KML file from GeoTraceroute, and create a combined KML file with all the traces (unfortunately only one of the IP addresses behind the DNS name is traced this time. To get them all, one would have to request traces using IP number instead of DNS names from GeoTraceroute). That might be the next step in this project.

Armed with these tools, I find it a lot easier to figure out where the IP traffic moves and who control the boxes involved in moving it. And every time the link crosses for example the Swedish border, we can be sure Swedish Signal Intelligence (FRA) is listening, as GCHQ do in Britain and NSA in USA and cables around the globe. (Hm, what should we tell them? :) Keep that in mind if you ever send anything unencrypted over the Internet.

PS: KML files are drawn using the KML viewer from Ivan Rublev, as it was less cluttered than the local Linux application Marble. There are heaps of other options too.

As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

Rundt omkring i Oslo og Østlandsområdet henger det bokser over veiene som jeg har lurt på hva gjør. De har ut fra plassering og vinkling sett ut som bokser som sniffer ut et eller annet fra forbipasserende trafikk, men det har vært uklart for meg hva det er de leser av. Her om dagen tok jeg bilde av en slik boks som henger under ei skibru på Sollihøgda:

Boksen er tydelig merket «Kapsch >>>», logoen til det sveitsiske selskapet Kapsch som blant annet lager sensorsystemer for veitrafikk. Men de lager mye forskjellig, og jeg kjente ikke igjen boksen på utseendet etter en kjapp titt på produktlista til selskapet.

I og med at boksen henger over veien E16, en riksvei vedlikeholdt av Statens Vegvesen, så antok jeg at det burde være mulig å bruke REST-API-et som gir tilgang til vegvesenets database over veier, skilter og annet veirelatert til å finne ut hva i alle dager dette kunne være. De har både en datakatalog og et søk, der en kan søke etter ulike typer oppføringer innen for et gitt geografisk område. Jeg laget et enkelt shell-script for å hente ut antall av en gitt type innenfor området skibrua dekker, og listet opp navnet på typene som ble funnet. Orket ikke slå opp hvordan URL-koding av aktuelle strenger kunne gjøres mer generisk, og brukte en stygg sed-linje i stedet.

#!/bin/sh
urlmap() {
    sed \
    -e 's/  / /g'   -e 's/{/%7B/g'  \
    -e 's/}/%7D/g'  -e 's/\[/%5B/g' \
    -e 's/\]/%5D/g' -e 's/ /%20/g'  \
    -e 's/,/%2C/g'  -e 's/\"/%22/g' \
    -e 's/:/%3A/g'
}

lookup() {
    url="$1"
    curl -s -H 'Accept: application/vnd.vegvesen.nvdb-v1+xml' \
       "https://www.vegvesen.no/nvdb/api$url" | xmllint --format -
}

for id in $(seq 1 874) ; do
    search="{
  lokasjon: {
    bbox: \"10.34425,59.96386,10.34458,59.96409\",
    srid: \"WGS84\"
  },
   objektTyper: [{
     id: $id, antall: 10
   }]
}"

    query=/sok?kriterie=$(echo $search | urlmap)
    if lookup "$query" |
    grep -q '<totaltAntallReturnert>0<'
    then
    :
    else
    echo $id
    lookup "/datakatalog/objekttyper/$id" |grep '^  <navn>'
    fi
done

exit 0

Aktuelt ID-område 1-874 var riktig i datakatalogen da jeg laget scriptet. Det vil endre seg over tid. Skriptet listet så opp aktuelle typer i og rundt skibrua:

5
  <navn>Rekkverk</navn>
14
  <navn>Rekkverksende</navn>
47
  <navn>Trafikklomme</navn>
49
  <navn>Trafikkøy</navn>
60
  <navn>Bru</navn>
79
  <navn>Stikkrenne/Kulvert</navn>
80
  <navn>Grøft, åpen</navn>
86
  <navn>Belysningsstrekning</navn>
95
  <navn>Skiltpunkt</navn>
96
  <navn>Skiltplate</navn>
98
  <navn>Referansestolpe</navn>
99
  <navn>Vegoppmerking, langsgående</navn>
105
  <navn>Fartsgrense</navn>
106
  <navn>Vinterdriftsstrategi</navn>
172
  <navn>Trafikkdeler</navn>
241
  <navn>Vegdekke</navn>
293
  <navn>Breddemåling</navn>
301
  <navn>Kantklippareal</navn>
318
  <navn>Snø-/isrydding</navn>
445
  <navn>Skred</navn>
446
  <navn>Dokumentasjon</navn>
452
  <navn>Undergang</navn>
528
  <navn>Tverrprofil</navn>
532
  <navn>Vegreferanse</navn>
534
  <navn>Region</navn>
535
  <navn>Fylke</navn>
536
  <navn>Kommune</navn>
538
  <navn>Gate</navn>
539
  <navn>Transportlenke</navn>
540
  <navn>Trafikkmengde</navn>
570
  <navn>Trafikkulykke</navn>
571
  <navn>Ulykkesinvolvert enhet</navn>
572
  <navn>Ulykkesinvolvert person</navn>
579
  <navn>Politidistrikt</navn>
583
  <navn>Vegbredde</navn>
591
  <navn>Høydebegrensning</navn>
592
  <navn>Nedbøyningsmåling</navn>
597
  <navn>Støy-luft, Strekningsdata</navn>
601
  <navn>Oppgravingsdata</navn>
602
  <navn>Oppgravingslag</navn>
603
  <navn>PMS-parsell</navn>
604
  <navn>Vegnormalstrekning</navn>
605
  <navn>Værrelatert strekning</navn>
616
  <navn>Feltstrekning</navn>
617
  <navn>Adressepunkt</navn>
626
  <navn>Friksjonsmåleserie</navn>
629
  <navn>Vegdekke, flatelapping</navn>
639
  <navn>Kurvatur, horisontalelement</navn>
640
  <navn>Kurvatur, vertikalelement</navn>
642
  <navn>Kurvatur, vertikalpunkt</navn>
643
  <navn>Statistikk, trafikkmengde</navn>
647
  <navn>Statistikk, vegbredde</navn>
774
  <navn>Nedbøyningsmåleserie</navn>
775
  <navn>ATK, influensstrekning</navn>
794
  <navn>Systemobjekt</navn>
810
  <navn>Vinterdriftsklasse</navn>
821
  <navn>Funksjonell vegklasse</navn>
825
  <navn>Kurvatur, stigning</navn>
838
  <navn>Vegbredde, beregnet</navn>
862
  <navn>Reisetidsregistreringspunkt</navn>
871
  <navn>Bruksklasse</navn>

Av disse ser ID 775 og 862 mest relevant ut. ID 775 antar jeg refererer til fotoboksen som står like ved brua, mens «Reisetidsregistreringspunkt» kanskje kan være boksen som henger der. Hvordan finner jeg så ut hva dette kan være for noe. En titt på datakatalogsiden for ID 862/Reisetidsregistreringspunkt viser at det er finnes 53 slike målere i Norge, og hvor de er plassert, men gir ellers få detaljer. Det er plassert 40 på østlandet og 13 i Trondheimsregionen. Men siden nevner «AutoPASS», og hvis en slår opp oppføringen på Sollihøgda nevner den «Ciber AS» som ID for eksternt system. (Kan det være snakk om Ciber Norge AS, et selskap eid av Ciber Europe Bv?) Et nettsøk på «Ciber AS autopass» fører meg til en artikkel fra NRK Trøndelag i 2013 med tittel «Sjekk dette hvis du vil unngå kø». Artikkelen henviser til vegvesenets nettside reisetider.no som har en kartside for Østlandet som viser at det måles mellom Sandvika og Sollihøgda. Det kan dermed se ut til at jeg har funnet ut hva boksene gjør.

Hvis det stemmer, så er dette bokser som leser av AutoPASS-ID-en til alle passerende biler med AutoPASS-brikke, og dermed gjør det mulig for de som kontrollerer boksene å holde rede på hvor en gitt bil er når den passerte et slikt målepunkt. NRK-artikkelen forteller at denne informasjonen i dag kun brukes til å koble to AutoPASS-brikkepasseringer passeringer sammen for å beregne reisetiden, og at bruken er godkjent av Datatilsynet. Det er desverre ikke mulig for en sjåfør som passerer under en slik boks å kontrollere at AutoPASS-ID-en kun brukes til dette i dag og i fremtiden.

I tillegg til denne type AutoPASS-sniffere vet jeg at det også finnes mange automatiske stasjoner som tar betalt pr. passering (aka bomstasjoner), og der lagres informasjon om tid, sted og bilnummer i 10 år. Finnes det andre slike sniffere plassert ut på veiene?

Personlig har jeg valgt å ikke bruke AutoPASS-brikke, for å gjøre det vanskeligere og mer kostbart for de som vil invadere privatsfæren og holde rede på hvor bilen min beveger seg til enhver tid. Jeg håper flere vil gjøre det samme, selv om det gir litt høyere private utgifter (dyrere bompassering). Vern om privatsfæren koster i disse dager.

Takk til Jan Kristian Jensen i Statens Vegvesen for tips om dokumentasjon på vegvesenets REST-API.

Bruksvilkår på bildet er public domain eller CC0 alt etter hva som fungerer best for mottaker.

Oppdatering 2014-12-17: Veldig hyggelig å se at mine notater fikk omtale på vegdata-bloggen.

If you, like me, want an updated a map for your Garmin GPS, there is now a great source of free maps available from Frikart. To download a map, just click on the country you are interested in, and download the map type you want. There are 8 different maps available, using different colours and data selection. Pick one of Roadmap, Topo Summer, Topo Winter, Roadmap II, Topo Summer II, Topo Winter II, "Trails - overlay map" and "Cross country - overlay map" (see the web page for descriptions).

The maps are updated weekly, so if you find something wrong in the map you can just edit the OpenStreetmap map source (anyone can contribute) and fetch a fixed map a week later. :)

Veldig morsomt å se at Naturvernforbundet Oslo og Akershus bruker kart fra OpenStreetmap.org i sine kalendere. Vidar Gundersen i kartgruppa forteller på den norske epostlisten til prosjektet at hvert blad i kalenderen har et turforslag på baksiden, med kart fra OpenStreetmap. Tidligere kjøpte de visst kart fra kartverket, men nå slipper de det.

Denne nyheten synes jeg er fantastisk bra, og jeg håper de får følge av flere, slik at det potensielle og fryktede inntektstapet for kartverket ved frigjøring av kartdata blir mindre, og forhåpentligvis til slutt så lite at frykten for å frigjøre data overvinnes.

I går ble jeg kontaktet på epost av digi.nos Eirik Rossen som lurte på om jeg hadde noen kommentarer til kartverkets pressemelding om Norges tetplassering når det gjelder kart-tilgjengelighet. Jeg svarte følgende, som resulterte i noen sitater i Digis dekning av kartverkets pressemelding.

Takk for muligheten til å kommentere.

Pressemeldingen omhandler tilgjengeligheten av kart for aktører som er medlem i kartellet Norge Digitalt. Det er ingen overraskelse for meg at tilgjengeligheten til kart hos disse medlemmene er god. Men for oss på utsiden av kartellet er tilgjengelighet av det som burde være felleskapets og innbyggernes kart dårlig.

Bruksvilkårene til kartene fra medlemmene i Norge Digital hindrer nyskapning og selv om en er villig til å betale den ublu prisen som forlanges får en fortsatt ikke tilgang til kartdata uten bruksbegresninger. Derfor bruker jeg heller tid på å gjøre fribrukskartet OpenStreetmap bedre. Der fremmer bruksvilkårene nyskapning og lar meg skape nye tjenester uten å måtte søke om tillatelse fra det offentlige.

En annen problemstilling er jo sikkerhet til fjells og til sjøs. Mon tro hvor mange ulykker på sjøen som kunne vært unngått hvis sjøkartdata var tilgjengelig uten bruksbegrensninger, slik at enhver med GPS eller kartplotter tilnærmet kostnadsfritt kunne sikre seg mest mulig oppdaterte sjøkart? Det hjelper jo ikke at offentlige etater har enkel tilgang til sjøkartene når det samme ikke gjelder hver båtkaptein og småbåtfører. Jeg tror samfunnet som helhet hadde tjent på å unngå kostnadene ved disse ulykkene ved å tvinge sjøkartverket til å publisere sine kartdata på Internet uten bruksbegresninger.

På torsdag lanserte kartverket en ny nett-tjeneste kalt Se Eiendom, der en får innsyn i det norske eiendomsregisteret (Matrikkelen) og kan slå opp grunnleggende informasjon om hver eiendom. En kan slå opp et koordinat og finne ut hvilken eiendom punktet befinner se på og så slå opp eiendommen i matrikkelen og finne ut nøkkelinformasjon om eiendommen.

Det slo meg at dette kan brukes til å gjenskape kommunegrenser, ved å slå opp punkter langs grenselinja og dermed bestemme hvor grenselinjen befinner seg. En kan bestemme den vilkårlig nøyaktig ved å gjøre et geometrisk søk.

Sniffet i kveld på trafikken til tjenesten, og det er i korte trekk tre relevante tjenestekall som returnerer JSON-data.

Først en som konverterer mellom koordinater, som i mitt eksempel konverterer fra UTM sone 33 til UTM sone 32:

% GET 'http://www.seeiendom.no/services/geoport.svc/GetTransformJsonp?nord=6648308.4755859&ost=248316.38085938&fromEpsg=EPSG:32633&toEpsg=EPSG:32632'
{"x":583905.90433579613,"y":6640700.79711847}
%

Koordinatene i UTM sone 32 kan så gis til tjenesten som slår opp eiendom basert på koordinat:

% echo | POST 'http://www.seeiendom.no/services/geoport.svc/PerformPropertySearchFromPolygonCoordinatesJsonp?polygonCoordinatesString=583905.9043357961,6640700.79711847'
{"error":"","wfsTeigInfo":{"TeigId":128010625,"Areal":"6128.7","GardsNr":"300","BruksNr":"2384","FesteNr":"0","SeksjonsNr":"0","MatrikkelNr":"300/2384","HovedTeig":true,"KommuneNavn":"Bærum","Adresses":null,"ArealMerknadsKoder":null,"UregistrertJordsameie":false,"AvklartEiere":false,"TeigMedFlereMatrikkelEnheter":false,"Tvist":false,"KommuneNr":"0219"}}
%

Etter dette kallet har en kommunenavn og kommunenummer, noe som er tilstrekkelig til å gjenskape kommunegrenser. Hvis en ønsker å vite detaljene om eiendommen kan en slå opp i selve matrikkelen, og få ut en HTML-side med informasjon:

% GET 'http://www.seeiendom.no/services/Matrikkel.svc/GetDetailPage?type=property&knr=0219&gnr=300&bnr=2384&fnr=0&snr=0&showpwm=false&customer=kartverket'
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <title>Matrikkel informasjon</title>
[...]

Informasjon om hva en kan hente ut ved hjelp av Matrikkel.svc er dokumentert og tilgjengelig på en egen hjelpeside. Hvis en vil ha XML- eller JSON-formattert informasjon kan GetMatrikkelinfo-funksjonen brukes. Hvis en f.eks. bruker den slik får en masse informasjon om en eiendom:

% echo '{"knr": 1601, "gnr": 27, "bnr": 2, "fnr": 0, "snr": 0, "customer": "kartverket"}' | \
  POST -c application/json http://www.seeiendom.no/services/Matrikkel.svc/GetMatrikkelinfo
[...]
%

Dette ser ut som en svært nyttig tjeneste som kan gjøre FiksGataMi mer treffsikker når den skal finne ut hvilken kommune og fylke som skal ha problemrapporter. Da eierinformasjon ikke er tilgjengelig, må vi i så fall bygge opp vår egen database over eiere av eiendommer knyttet til vei for å kunne skille på veinivå om kommune eller vegvesen skal ha beskjed. Har ikke funnet informasjon om hvilke bruksvilkår tjenesten har, så jeg er ennå ikke sikker på om dette er trygt å gjøre. Håper det blir klart etter hvert som tjenesten tar form.

Tillegg 2011-06-24: Har oppdaget at en også kan hente ut geografisk beskrivelse av eiendommen (dvs. et polygon som omkretser eiendommen), ved hjelp av følgende forespørsel.

% echo | POST 'http://www.seeiendom.no/services/geoport.svc/GetPropertyBorderJsonp?kommunenr=1663&gardsnr=4&bruksnr=182&festenr=0&seksjonsnr=0&gateAdresseId=&address=&showPopUp=true'
[...]
%

Da blir det straks veldig nyttig for å klassifisere eierskap på veier og andre offentlige områder. Det er dog en eller annen feil som gjør at oppslag på store eiendommer (som Nordmarka i Oslo og Finnmarksvidda) ikke fungerer. Vet ikke hva det kommer av.

Det er morsomt å følge med hvordan bruken av FiksGataMi sprer seg over det ganske land. Her er lenkene til fylkesoversikt på kart over de (for tiden) 200 siste problemene. Bruker her GeoRSS-kilden i FiksGataMi og presenterer enten via Google Maps eller en GeoRSS-fremviser jeg fant for OpenStreetmap.

• Østfold [ Google Maps ] | [ OpenStreetmap ]
• Akershus [ Google Maps ] | [ OpenStreetmap ]
• Oslo [ Google Maps ] | [ OpenStreetmap ]
• Hedmark [ Google Maps ] | [ OpenStreetmap ]
• Oppland [ Google Maps ] | [ OpenStreetmap ]
• Buskerud [ Google Maps ] | [ OpenStreetmap ]
• Vestfold [ Google Maps ] | [ OpenStreetmap ]
• Telemark [ Google Maps ] | [ OpenStreetmap ]
• Aust-Agder [ Google Maps ] | [ OpenStreetmap ]
• Vest-Agder [ Google Maps ] | [ OpenStreetmap ]
• Rogaland [ Google Maps ] | [ OpenStreetmap ]
• Hordaland [ Google Maps ] | [ OpenStreetmap ]
• Sogn og Fjordane [ Google Maps ] | [ OpenStreetmap ]
• Møre og Romsdal [ Google Maps ] | [ OpenStreetmap ]
• Sør-Trøndelag [ Google Maps ] | [ OpenStreetmap ]
• Nord-Trøndelag [ Google Maps ] | [ OpenStreetmap ]
• Nordland [ Google Maps ] | [ OpenStreetmap ]
• Troms [ Google Maps ] | [ OpenStreetmap ]
• Finnmark [ Google Maps ] | [ OpenStreetmap ]

Antall problemer returnert i GeoRSS-kildene justeres over tid etter hvert som vi får mer erfaring med hvilken belastning det gir på tjenesten.

Oppdatering 2011-04-27: Endret URL til fylker med mellomrom i navnene fra %20 til %2B, slik at de fungerer i flere nettlesere.

Here is a small update for my English readers. Most of my blog posts have been in Norwegian the last few weeks, so here is a short update in English.

The kids still keep me too busy to get much free software work done, but I did manage to organise a project to get a Norwegian port of the British service FixMyStreet up and running, and it has been running for a month now. The entire project has been organised by me and two others. Around Christmas we gathered sponsors to fund the development work. In January I drafted a contract with mySociety on what to develop, and in February the development took place. Most of it involved converting the source to use GPS coordinates instead of British easting/northing, and the resulting code should be a lot easier to get running in any country by now. The Norwegian FiksGataMi is using OpenStreetmap as the map source and the source for administrative borders in Norway, and support for this had to be added/fixed.

The Norwegian version went live March 3th, and we spent the weekend polishing the system before we announced it March 7th. The system is running on a KVM instance of Debian/Squeeze, and has seen almost 3000 problem reports in a few weeks. Soon we hope to announce the Android and iPhone versions making it even easier to report problems with the public infrastructure.

Perhaps something to consider for those of you in countries without such service?

FAD er igang med å publisere et forslag til norsk lisens for offentlige data (NLOD), og jeg fikk i kveld lest igjennom teksten. Jeg la inn to kommentarer på bloggen der forslaget ble lansert som jeg vil dele med mine lesere:

Jeg håper en sikrer at georefererte data som publiseres med bruksvilkår i henhold til denne lisensen kan importeres inn i OpenStreetmap. Jeg har ikke full oversikt over hva dette innebærer av konkrete krav til lisensen, og rekker heller ikke sjekke det opp, men nevner det her for å øke sjansen for at det blir tatt hensyn til.

Etter å ha lest forslag til lisens, er det to ting som slår meg. En forsøker å løse utfordringer relatert til kildekritikk med opphavsrettslige midler, og det tror jeg er en tabbe. I stedet for å kreve navngivelse og at informasjonen ikke skal brukes til å villede, som vil gjøre det problematisk å bruke informasjonen i enkelte sammenhenger, så bør en akseptere at informasjonen kan brukes uten navngivelse og til å villede, og legge opp til at de som vil være sikker på at den informasjonen de har fått en kopi av er den “offisielle” bør hente den fra offisielle kilder med metoder som sikrer at en får den “offisielle” versjonen (dvs. vha. krypto-signaturer).

I kortet er det jeg sier at en bør gjøre lisensen mer i tråd med "public domain", og bruke potensielle mottakeres evne til å sjekke hvor datafiler kommer fra for å sikre at korrekt informasjon kommer frem til de som trenger det. Motivasjonen min for å ikke kreve navngivelse er å unngå de problemer som potensielle prosjekter får hvis det skal kombineres mange kilder som alle krever navngivelse (tenk et kart der flere hundre tusen bidrag skal navngis på kartet). Motivasjonen for å ikke nekte bruk som er “villedende”, er at det åpner for "gummilover" og vilkårlig håndhevelse, og kan gjøre det vanskelig/risikabelt å bruke data gitt ut med denne lisensen til å kritisere de som har gitt ut data. En kritiker kan bli forsøkt kneblet ved å påstå at informasjonen brukes til å villede, og på den bakgrunn trekke bruksretten til datakilden tilbake.

Anbefaler alle å ta en titt på lisensen og gi innspill enten via blogg-kommentarer eller via høringen som snart starter. Lisensen er allerede tatt i bruk av Trafikanten til å publisere ruteinformasjon for Østlandet, og jeg mistenker flere offentlige aktører vil ta den i bruk. Det er dermed viktig å sikre at lisensen muliggjør mest mulig gjenbruk av offentlige data.

Etter mandagens lansering av FiksGataMi har responsen vært enorm, og de første 1000 problemene er allerede rapportert. Noen saker er allerede løst, og responstiden til Bø i Nordland og Melhus imponerer stort. Slikt burde gjøre innbyggerne der stolte. :)

En utfordring for FiksGataMi er håndtering av fylkes- og riksveier som ikke skal til kommunen men til fylket eller staten. Problemet er at vi mangler en datakilde som kan brukes til å identifisere hvilket geografisk område som administreres av fylket og staten (dvs. vei, grøfter, gjerder og slikt). Det vi trenger er maskinlesbare georefererte eiendomsgrenser over eiendommene som hører til fylkes- og riksveier. Når vi har det, kan vi videreutvikle fiksgatami til å håndtere eiendomsgrenser i tillegg til dagens kommune- og fylkesgrenser. Så vi trenger datakilder uten bruksbegrensninger og litt finansiering for å ta dem i bruk.

Men noen kommuner håndterer denne utfordringen elegant likevel og til det beste for innsender ved å sende saken videre til riktig instans og notere dette i FiksGataMi. De første som gjorde dette var så vidt jeg kan se Lørenskog. All kudos til dem!

I morgen tidlig skal Christer på NRK Østlandssendingen og snakke om FiksGataMi. Jeg gleder meg til å høre opptaket og se hvilken respons det fører til på innrapporteringen. Jeg forsøker å holde oversikt over omtalen NUUG og FiksGataMi på NUUGs websider, og responsen så langt har vært veldig god. De fleste kommunene er veldig positive til tjenesten. De som hadde lignende løsninger er ikke så fornøyde, noe jeg kan forstå. På den positive siden får innbyggerne i disse kommunene nå et valg om hvilken løsning de vil benytte seg av, og konkurranse er en fin ting for å dyrke frem de beste løsningene. :)

I går lanserte vi i foreningen NUUG FiksGataMi, med pressemelding på epost til alle NUUGs annonseringsliste, medlemmene, alle landets redaksjoner og alle landets kommuner og fylkeskommuner. Responsen har vært formidabel, og vi har en enorm baklogg av henvendelser å følge opp. Vi jobber oss sakte men sikkert igjennom stabelen. Alt sendes til NUUGs RT-instans slik at ingen blir glemt. Hvis du har kommentarer og spørsmål, bruk kontaktfeltet på FiksGatami, eller send epost til adressen som er oppgitt der.

Pr nå er det kommet inn over 600 problemer som er rapportert videre til kommuner og fylker. Jeg hentet ut fordelingen på kategorier nå nettopp, for å se hva som opptar innbyggerne rundt om i det ganske land. Det er mest aktivitet i Trondheim, fulgt av Oslo og Bergen, men godt over 100 kommuner og fylker har fått meldinger fra innbyggerne via FiksGatami så langt.

count	category
398	Hull i vei
83	Gater/Veier
65	Snøbrøyting
54	Gatelys
46	Annet
30	Fortau/gangstier
17	Tette avløpsrister
10	Trafikkskilter
7	Parkering
7	Forlatte kjøretøy
4	Trafikklys
4	Sykkelveier
4	Forsøpling
3	Buss- og togstopp
3	Vannforsyning
3	Universell utforming
3	Trær
2	Graffiti/tagging
2	Dumpet skrot
1	Park/landskap
1	Ulovlige oppslag
1	Offentlige toaletter

Det gjenstår endel jobb med skalering før vi er fornøyd med ytelsen, og så må vi få skrevet litt mer informasjon til kommunene om hvordan systemet fungerer, slik at de vet mer hvordan de kan bidra til å gjøre brukeropplevelsen for innbyggerne enda bedre.

Til de som synes sitt lokalområde har dårlig kart, så er det bare en ting å si. Bidra til å gjør OpenStreetmap bedre ved å tegne inn ditt lokalområde! Eller få det offentlige til å gi ut bedre kartdata uten bruksbegrensninger. :)

Jeg vil presentere FiksGataMi under Go Open 2011, så vi ses kanskje der?

Det nærmer seg lansering av NUUGs Fiksgatami-tjeneste, og siste finpuss på kategorisering gjøres i disse dager. Jeg har konkludert med at ideen om å ta utgangspunkt i eksisterende kommunale tjenesters kategorisering er en dårlig ide da det er viktigere å kategorisere fra et brukersynspunkt enn å kategorisere ut fra hvordan kommunene er organisert internt. Måtte dermed starte på nytt med kategoriarbeidet.

Nå har jeg kommet opp med følgende forslag til kategorier, basert på de som er i bruk på den britiske originalen, innspill på IRC-kanalen til NUUG og folk rundt meg. Tar gjerne imot innspill på kategoriene til epostlisten for prosjektet, fiksgatami (at) nuug.no.

Av tekniske årsaker kan kun bokmålsoversettelsen av det engelske ordet 'Other' brukes som fellesbetegnelse for andre kategorier, dvs. at også nynorsk-kommuner ender opp med 'Annet' som samlekategori. Oversettelse av applikasjonen til nynorsk og nordsamisk får vente til noen sponser den utviklingen som trengs for å få det til.

Her er så lista med kategorier jeg tror vi går i produksjon med:

• Hull i veien
• Gater/Veier
• Fortau/gangstier
• Veinavn-skilt
• Sykkelvei
• Glatt vei
• Snøbrøyting
• Gatelys
• Dumpet skrot
• Forsøpling
• Parkering
• Grafitti/tagging
• Hundedritt
• Gaterydding
• Trafikkskilter
• Forlatte kjøretøy
• Trær
• Trafikklys
• Park/landskap
• Ulovlige oppslag
• Buss- og togstopp
• Offentlige toalett
• Vannforsyning
• Tett avløpsrist
• Oljesøl
• Annet

Er disse forståelige? Er det noen uforståelige overlapp? Noen kategorier vi mangler som burde skilles ut fra 'Annet'? Er det noen av disse kategoriene som ikke skal varsles til offentlig myndighet? Gi tilbakemelding innen midten av kommende uke hvis du vil ha et ord med i laget når det gjelder kategorisering.

Arbeidet med å få på plass NUUGs Fiksgatami-tjeneste går videre uten stans. Den vil som tidligere nevnt bruke de beste kommunegrensene vi har klart å få tak i, fra OpenStreetmap.org. Ofte vil unøyaktighetene ikke har mye konsekvenser, da kommunegrenser ofte går lagt fra der det bor mye folk, men av og til vil det påvirke flere. Kom over et eksempel i dag, der grensestreken går midt i tettbygd strøk og henvendelser via FiksGataMi nok vil bli feilsendt pga. at det offentlige nekter å fortelle oss på maskinlesbart format hvor kommunegrensa går.

Grensa mellom Tønsberg og Nøtterøy er i dag tegnet opp slik at den går midt igjennom Ollebukta marina og lar Ørsnes ligge i en kommune mens Ørsnesalleen går over to kommuner. Min erfaring med kommuneoppdeling får meg til å tro at dette neppe stemmer.

Vi får bare håpe at noen med lokalkunnskap går inn og korrigerer grensestreken i OpenStreetmap.org slik at den blir mer nøyaktig, eller at det offentlige snur og publiserer i hvert fall kommunegrenseinformasjonen på maskinlesbart format uten bruksbegresninger, slik at FiksGataMi har større sjanse til å sende informasjon til riktig kommune.

Det går mot at det settes hardt mot hardt og en rettsak om temaet, og i går ble det kjent at NUUG Foundation støtter Fri Geo Norge-prosjektet med deler av kostnadene forbundet med en rettsak for å få tilgang til kommunegrensene fra kartverket. Jeg gleder meg til fortsettelsen.

NUUGs Fiksgatami-tjeneste tar sakte form, og den siste uka har vi betalt mySociety i England for å tilpasse kildekoden til deres tjeneste slik at den skal fungere for Norge. I løpet av kommende uke regner jeg at vi skal i gang med testing.

For å forberede testing, har jeg tatt en titt på hva slags informasjon som samles inn av kommuner som har lignende tjeneste for sin kommune allerede på plass. Jeg har tittet på tjenestene til Tromsø, Porsgrunn og Kongsvinger. Jeg tittet også på Askers, som er litt på siden at det jeg skriver om her

Om problemet samles alle tjenestene inn plassering, enten som adresse eller som kartkoordinat. De samler også inn en oppsummering/overskrift og en lengre beskrivelse, og noen av dem tillater bilde og vedlegg lagt ved. Alle problemene tildeles en kategori, og det er stort overlapp i kategoriseringen:

Tromsø	Porsgrunn	Kongsvinger
Vei	Hull i veg	Veg/Vegvedlikehold
		Skilt/Trafikksikkerhet
Gatelys	Gatelys virker ikke	Gatelys
Vann og avløp	Vann og avløp	Vann/Avløp
Park	Park	Park/Grønt
Friluftsliv	Friluft
Renovasjon	Renovasjon	Renovasjon/Avfall
	Grafitti-Tagging	Grafitti/Tagging
		Forsøpling
Annet	Annet	Annet

Om de som rapporterer inn problemet, blir det samlet inn navn, epostadresse, et eller to telefonnummer og for Asker postadresse. Noen vil også vite hvordan tilbakemelding ønskes, dvs. epost, telefon eller via post.

Fiksgatami skulle kunne håndtere innsending til disse kommunene uten større problemer, tror jeg. Kategorier defineres per område, slik at kommunene kan få meldinger inndelt i de kategoriene de trenger. Fiksgatami samler i utgangspunktet kun inn navn og epostadresse for innsender, og det tror jeg vi skal fortsette med.

Tidlig i januar oppdaget vi i OpenStreetmap.org-prosjektet at Oslo kommune har tatt i bruk OpenStreetmap.org for å vise frem hvor piggdekkavgiften gjelder, dvs. kommunegrensa. Årsaken til at denne siden bruker OpenStreetmap.org og ikke kommunens eget kartgrunnlag, er ganske absurd. Kommunens kart vedlikeholdes og styres av Plan og Bygningsetaten, mens det er Samferdselsetaten som styrer med piggdekkavgift og som har laget siden om piggdekkavgiften. I avtalen mellom Samferdselsetatet og Plan og Bygningsetaten om bruk av kommunens kart står det at kartet kun kan brukes internt, og dermed ikke publiseres på Internet. Oslo kommune forbyr altså Oslo kommune å publisere informasjon om sin kommunegrense på Internet. Ironien er upåklagelig, og årsaken er som alltid penger.

Vi i OpenStreetmap.org-prosjektet synes det er veldig gledelig at Oslo kommune vil bruke kartet vårt, men det var et lite problem rundt bruken av kommunegrensen. Den kommer fra kartverkets N5000-kart, som i følge kartverket har nøyaktighet på 2 km. Et kart over hvor piggdekkavgiften gjelder bør ha høyere nøyaktighet enn det for å unngå konflikter, så det var dermed viktig for oss å forbedre nøyaktigheten for Oslogrensa.

For litt over 2 uker siden ringte jeg derfor til Kartverket, for å høre om de kunne bidra. Jeg lurte på om de enten hadde noen datakilder med kommunegrensen i Oslo som vi ikke kjente til, eller om de kunne forklare hvordan vi kunne gjenskape kommunegrensen på bakken ved å følge en beskrivelse av grensen eller finne grensepunkter etc.

For å ta det siste først, så var det beste forslaget der å bruke kartet tilgjengelig fra norgeskart.no til å slå opp gårds- og bruksnummer for eiendommer som grenset til kommunegrensa, og så be om innsyn i matrikkelen for hver av disse eiendommene og gå opp grensen basert på informasjon fra matrikkelen. Det fantes antagelig også noen grensesteiner som var merket på bakken, men de kjente ikke til noen offentlig kilde med informasjon om hvor disse steinene sto. Dette er en ganske arbeidskrevende oppgave, som får vente til en annen gang.

For alternative datakilder vi ikke kjente til, så var det ingen som hadde gode forslag når det gjaldt datakilder fra kartverket. Men en nevnte at det kunne være enklere å få ut data fra veidatabasen til vegvesenet, f.eks. de punktene der veier inn og ut av Oslo byttet kommune. Dette ble jeg forklart var trivielt å hente ut (mindre enn 1 minutts jobb), men vedkommende jeg snakket med kunne ikke avgjøre om vi kunne få disse punktene uten bruksbegrensninger.

Og tilgang uten bruksbegrensninger er viktig for OpenStreetmap.org, da det skal være tillatt å bruke OpenStreetmap.org-data til å lage kommersielle tjenester og kopiere, endre og distribuere OpenStreetmap.org-data uten begrensninger. Jeg gjorde det derfor klart for de jeg snakket med hos Kartverket at jeg kun var interessert i å motta data som kunne legges inn i OpenStreetmap.org uten bindinger. Fikk f.eks. tilbud om å få "test-data" av kommunegrensen for Oslo til internt bruk og måtte takke nei.

Ideen om veidatabasen var interessant, og jeg fulgte den opp videre. Ble satt videre til noen som kanskje kunne avgjøre om jeg fikk disse punktene uten bruksbegresninger, og etter en kort og interessant samtale fikk jeg ja til å få kopi av punktene der Oslogrensa krysser vei. De ble sendt til kart-listen i SOSI-format, og i løpet av noen dager brukt til å justere kommunegrensa for Oslo slik at den nå har nøyaktighet på noen meter der den krysser vei. Har fått tilbakemelding fra noen som har tilgang til Oslo kommunes kart at nøyaktigheten var blitt mye bedre. :)

Det burde ikke være nødvendig å gjøre en slik innsats for å få vite hvor kommunegrensene går. En skulle jo tro dette var offentlig informasjon uten bruksbegrensing, og Gustav Fosseid og Magne Mæhre har et prosjekt gående for å be om innsyn i nettopp denne informasjonen. De har bedt om elektronisk kopi av kartkoordinatene for kommunegrensene i endel kommuner på østlandet i sitt Fri Geo Norge-prosjekt, og har fått avslag i første instans og klagesvar fra fylkesmannen i sin klage på avslaget. Er spent på fortsettelsen, og gir dem all min hjelp og støtte i arbeidet med å få frigjort det som burde vært offentlig informasjon.

Har oppdaget at mange ikke er klar over at OpenStreetmap.org er tilgjengelig i en rekke forskjellige formater. Her er en liste med eksporter jeg kjenner til for Norge, for de som trenger et fribrukskart til sine tjenester:

• Cloudmade tilbyr OSM XML, Garmin Map Files, Osmosis country bounding polygon, Shapefile, Navit maps, GPX POI, TomTom POI og OSM XML feature extracts via sine nedlastingssider.
• Geofabric tilbyr OSM XML, OSM protobuf binærformat og ESRI Shapefile (EPSG:4326) fra sine nedlastingssider.
• Frikart.no tilbyr Garmin-kart i uike varianter for veibruk og turbruk sommer og vinter.

Kartene oppdateres regelmessig, som oftest hver uke. Det skulle dermed være noe for enhver smak.

Jeg ble riktig fascinert av en artikkel i Aftenposten om hvor hardt Navteq jobber for å oppdatere kartene som brukes i navigasjons-GPSer, der det blant annet heter at "på grunn av teknikken tar det alt fra tre til tolv måneder før kartene er oppdatert". Når en kjenner hva slags oppdateringshastighet som er tilgjengelig på OpenStreetmap som oppdateres på dugnad, blir det litt trist å se hva noe av det beste en kan kjøpe for penger får til.

Fra en endrer kartdataene i databasen til OpenStreetmap tar det ca. 15 minutter før endringen er synlig på kartet som alle kan se på web. Dernest overføres det daglig til en kartdump som lastes ned av personen som lager Garmin-kart for Norge ca. en gang i uken. Med OpenStreetmap.org og Frikart.no kan en altså ha korreksjonene på plass i sin Garmin-GPS i løpet av en uke. Det er også av tekniske årsaker at det tar så langt tid. Jobbene som tegner kartene, henter ut kartdumpene og konverterer til Garmin-format tar minutter og timer å gjennomføre, slik at de ikke gjøres kontinuerlig men kun regelmessing.

Thanks to todays opengeodata blog entry, I just discovered that the OpenStreetmap.org site have gotten support for calculating routes. The support is still experimental and only available from the development server, until more experience is gathered on the user interface and any scalability issues.

Earlier, the routing I knew about using the OpenStreetmap.org data was provided by Cloudmade, but having it on the main page is required to make everyone aware of the issue. I've had people reject Openstreetmap.org as a viable alternative for them because the front page lacked routing support, and I hope their needs will be catered for when routing show up on the www.openstreetmap.org front page.

Dagens kartnyhet er at kartverket gir ikke-kommersiell tilgang til en WMS-tjeneste der en til privat bruk kan hente ut bilder av kartutsnitt så lenge disse ikke lagres lokalt, brukes i begrenset oppløsning og ikke skader kartverket og rettighetshavernes omdømme og interesse.

I går publiserte Ivan Sanchez kaketesten som et forslag til en (av forhåpentligvis flere) måter å teste om kart eller kartdata er fritt tilgjengelige på. Testen er enkel, og sier enkelt (oversatt av meg): Et sett med geodata, eller en kart, er kun fritt tilgjengelig hvis noen kan gi deg en kake med det kartet på toppen, som en gave. Kartverkets publisering av kart feiler så vidt jeg kan se denne testen fullstendig. En kan slik jeg leser vilkårene ikke be en konditor om å lage en kake (brudd på kravet om ikke-kommersiell bruk) med kartverkets kart.

De som vil lage karttjenester basert på denne nye tjenesten fra kartverket vil gjøre det på kartverkets nåde og med sterke bindinger og begresninger. Det blir dermed helt uinteressant for meg. Jeg vil nok fortsette å bruke data fra OpenStreetmap.org, der jeg har kontrollen med tilgang til kartdataene, og kan endre på de underliggende dataene som jeg ønsker.

Som et eksempel, så trenger vi til en norsk FixMyStreet-installasjon tilgang til vektorutgaven av kommunegrensene. Denne nye karttjenesten er ubrukelig til dette.

Oppdatering 2011-01-14: Link til kaketesten er forsvunnet, bruk denne nye i stedet.

Sikkerhet til sjøs burde være noe som opptar mange etter den siste oljeutslippsulykken med Full City, som har drept mye liv langs sjøen. En viktig faktor for å bedre sikkerheten til sjøs er at alle som ferdes på sjøen har tilgang til oppdaterte sjøkart som forteller hvor det grunner og annet en må ta hensyn til på sjøen.

Hvis en er enig i at tilgang til oppdaterte sjøkart er viktig for sikkerheten på sjøen, så er det godt å vite at det i dag er teknisk mulig å sikre alle enkel tilgang til oppdaterte digitale kart over Internet. Det trenger heller ikke være spesielt kostbart.

Både ved Rocknes-ulykken i Vatlestraumen, der 18 mennesker mistet livet, og ved Full City-ulykken utenfor Langesund, der mange tonn olje lekket ut i havet, var det registrert problemer relatert til oppdaterte sjøkart. Ved Rocknes-ulykken var de elektroniske kartene som ble brukt ikke oppdatert med informasjon om nyoppdagede grunner og losen kjente visst ikke til disse nye grunnene. Papirkartene var dog oppdaterte. Ved Full City-ulykken hadde en kontroll av skipet noen uker tidligere konstatert manglende sjøkart.

Jeg tror en løsning der digitale sjøkart kunne lastes ned direkte fra sjøkartverket av alle som ønsket oppdaterte sjøkart, uten brukerbetaling og uten bruksbegresninger knyttet til kartene, vil gjøre at flere folk på sjøen vil holde seg med oppdaterte sjøkart, eller sjøkart i det hele tatt. Resultatet av dette vil være økt sikkerhet på sjøen. En undersøkelse gjennomført av Opinion for Gjensidige i 2008 fortalte at halvparten av alle båteierne i landet ikke har sjøkart i båten.

Formatet på de digitale sjøkartene som gjøres tilgjengelig fra sjøkartverket må være i henhold til en fri og åpen standard, slik at en ikke er låst til enkeltaktørers godvilje når datafilene skal tolkes og forstås, men trenger ikke publiseres fra sjøkartverket i alle formatene til verdens skips-GPS-er i tillegg. Hvis det ikke er kostbart for sjøkartverket bør de gjerne gjøre det selv, men slik konvertering kan andre ta seg av hvis det er et marked for det.

Hvis staten mener alvor med å forbedre sikkerheten til sjøs, må de gjøre sitt for at alle båteiere har oppdaterte kart, ikke bare snakke om hvor viktig det er at de har oppdaterte kart. Det bør være viktigere for staten at båtene har oppdaterte kart enn at de er pålagt å ha oppdaterte kart.

Sjøkartene er tilgjengelig på web fra kystverket, men så vidt jeg har klart å finne, uten bruksvilkår som muliggjør gjenbruk uten bruksbegresninger.

OpenStreetmap.org-folk er lei av mangel på sjøkart, og har startet på et dugnadsbasert fribrukskart for havet, OpenSeaMap. Datagrunnlaget er OpenStreetmap, mens framvisningen er tilpasset bruk på sjøen. Det gjenstår mye før en kan bruke dette til å seile sikkert på havet, men det viser at behovet for fribruks-sjøkart er til stedet.