Import av veier fra Elveg: Samle trådene og veien framover

Jeg ønsker å få fart i importering av veidata fra Kartverket (Elveg).

Min motivasjon: En visuell stikkprøve av veier i Bergen viser tidvis stor unøyaktighet (fra Elveg) samt flere (mindre) veier som mangler i OSM. Det var dette som fikk meg inn i OSM til å begynne med, og så fant jeg ut at det er et stort prosjekt på gang om å importere Elveg-data. Da har det jo liten hensitk for meg å gjøre alt manuelt basert på dårlige GPS-data/satellittbilder. Har lest en del på wikien og mailingliste-arkivet fra januar 2014, og informasjonen jeg finner rundt import av Elveg-data virker litt hipp som happ, ufullstendig og opp i luften. Her er et forsøk på å samle trådene - i alle fall i hodet mitt - og tenke konkret videre ut ifra det jeg har sett. Noen får skrike ut om jeg er helt på jordet, jeg er tross alt ny her.

Konvertering av data: Elveg-data konverteres med Geir Oves elveg2osm. En del veldig godt arbeid er gjort, og fartsgrenser og veinavn er allerede dekket. Noen ting gjenstår slik jeg ser det (rød tekst er oppdatert info basert på Geir Oves kommentarer i neste innlegg):

  • Veityper: Skriptet tagger noen veier som highway=trunk og noen som highway=road. Disse bør sjekkes opp mot eksisterende vei i OSM for korrekt veitype. Skriptet tagger alle veier som highway=road. Veier bør tagges med korrekt highway=* basert på denne tabellen. Der hvor veitype ikke kan fastsettes utvetydig (hvor tabellen sier “sett highway=road og endre til xx eller yy”), kan skriptet gi instruks i en fixme=*-tag om å rette til en av de aktuelle veitypene og gjøre dette manuelt basert på veien som evt. allerede finnes i OSM (mer om konkret importmekanisme nedenfor).

  • Tagge turn restrictions basert på XXXXSving.txt (dette er essensielt for routing og jeg betrakter det som viktig), og evt. akselvekt basert på data fra XXXXAksel.txt. Jeg vil anta at sistnevnte kan gjøres delvis automatisk på et senere tidspunkt dersom veiene inneholder nvdb:id-tags (mer om dette nedenfor). Dette kan være enklere å gjøre i etterkant, se neste innlegg.

  • Eventuelle advarsler som kommer fram når skriptet kjøres (har ikke kjørt det selv ennå og har derfor ikke kjennskap til dette).

  • Såvidt jeg vet er “vei” og “veg” sidestilt på bokmål. Skal Elveg2osm da legge til alt_name dersom name matcher “veg\b” eller “vei\b” (regex end-of-word)?

  • Såvidt jeg vet skiller ikke Elveg-data ut hva som er påkjøringsramper (highway=xx_link). Usikker på hvordan det kan ordnes. Kan naturligvis bruke eksisterende tags på veier som allerede finnes, ellers kan satellitt og lokal kunnskap brukes? Dette gjelder jo hovedsakelig godt traffikerte og mappede veier, og man kan da bruke tags fra eksisterende vei.

  • Elveg skiller ut bro og tunnell, men jeg har ikke hørt noe som kan gi level-info hvor det er veier i ulike nivåer som enten ikke er i tunnell/bro eller hvor det er flere nivåer av tunneller/broer. Level bør sjekkes manuelt der veier krysser hverandre.

Avklaring med OSM/DWG: Såvidt jeg har sett ut ifra mailinglisten er ikke import av veier helt avklart ennå. Jeg er imidlertid usikker på hvor relevant det er, for jeg foreslår en ganske manuell prosess nedenfor hvor vi bare tar inn nye veier som ikke er i OSM og erstatter geometri på eksisterende veier (og da fletter tags). Mer om det nedenfor.

Når konvertering er ordnet og ting evt. er avklart med DWG, så kan vi ta inn Elveg-data i OSM. Jeg har gjort meg følgende tanker om denne prosessen:

Replace Geometry: Det virker lurt å kopiere inn veier fra Elveg-data i OSM-layeren i JOSM og bruke Replace Geometry på eksisterende vei. Da beholdes historikken til eksisterende vei, og det er lett å slå sammen tags fra eksisterende OSM-vei (f.eks. highway=*) og Elveg-vei (f.eks. fartsgrense, navn, veinummer). Dessuten blir da en manuell kvalitetskontroll uløselig knyttet til prosessen. Alt bør grovsjekkes med Bing, lokal kunnskap e.l. for å se at veien faktisk finnes og er noenlunde korrekt. Uten en manuell fletting slik som dette er jeg usikker på hvordan man skal kunne kombinere Elveg-data med OSM-data som ikke finnes i Elveg (eksisterende veier og stier som ikke er i Elveg må manuelt kobles på de nye veiene), eller vite hvilke OSM-veier man faktisk skal erstatte/slette/flette med hvilke Elveg-veier.

Jevnlig kontrollsjekk for nye/endrede data: Hvis alle ways tagges med nvdb:id (slik de blir per i dag i elveg2osm), så tror jeg det skal være greit å automatisere sjekk av data med jevne mellomrom med et “kontrollskript”. Uten at jeg vet noe om dette, slår det meg som en løsning at man kan sjekke om alle noder i veier fra nye Elveg-data har tilsvarende noder på samme sted i OSM-data. Da finner man lett nye/slettede veier i ett av datasettene, eller veier som er flyttet/endret. Man kan så gå manuelt gjennom uoverenstemmelsene og finne ut hva som skal gjøres. Jeg tror dette kan være hensiktsmessig, ettersom veier ikke skal endre seg alt for raskt/ofte og det da kan være geit å følge med på endringer. Dette vil for øvrig bare fungere dersom en ikke bruker “Simplify Ways” i JOSM, noe jeg uansett ser liten grunn til å bruke (jeg tror virkelig ikke OSM-databasen blir problematisk stor om vi beholder alle Elveg-noder - og man skal ikke undervurdere signaleffekten for kvalitet det har for nye potensielle OSM-brukere at svinger faktisk ser ut som buer). Om det ved en slik kjøring av skriptet er uoverenstemmelser og det er OSM-dataene er korrekte, så kan vi melde fra til Kartverket og/eller legge til ID-en til veien/nodene i en “ignore”-fil som kontrollskriptet sjekker opp mot neste gang det kjøres.

Praktisk bagatell ang. småskala oppdeling av arbeid: Jeg er ikke sikker på hvordan denne “importen” best kan gjøres stykkevis og delt. Alle veier er koblet sammen med andre veier, og man kan naturligvis ikke erstatte alle veier på én gang. Når man da erstatter geometrien til vei A men ikke vei B som er knyttet til A, så vil ikke A og B være koblet sammen. En løsning kan være å flytte slutt-noden på B inn på A frem til også B erstates med Elveg-data (og da må man huske på å bruke “Merge Nodes”, siden sluttnoden for den nye Elveg-baserte B bare er plassert “oppå” en node fra A, siden de ikke ble importert samtidig).

Sporing av progresjon: Pga det manuelle i dette blir det for mye å ta en hel kommune av gangen (i alle fall for store kommuner med mye vei). Det tar lang tid å få ferdig en kommune, og mye kan ha endret seg på OSM i mellomtiden Jeg har tenkt på om det kan gjøres basert på postnummer. Dersom det går an å importere grenser for postnummer først og dette er en relativt rask jobb, så kan man flette inn Elveg-data i ett postnummerområde av gangen og spore progresjon på den måten. Dette forutsetter at det i det hele tatt er ønskelig å importere områder for postnummer. Andre forslag mottas med takk.

Dette er slik jeg, en historieløs nybegynner, ser saken i dag basert på wiki, mailingliste osv. Si ifra om jeg er på bærtur. Håper på en god diskusjon om dette.

Scriptet gjør det samme som i tabellen, bortsett fra at jeg har tagget VNR=S (skogsbilveg) med highway=track, mens det står highway=unclassified i tabellen. Jeg tror track er mest riktig. En highway=road er allerede en implisitt FIXME, så det bør ikke trengs en egen tag for å fortelle at disse bør klassifiseres.

Svingerestriksjoner er relasjoner, som elveg2osm per i dag ikke lager noen av. Tror ikke det er så vanskelig å få til, men ser for meg at det nok er lettere i ettertid så lenge nvdb:id er med. Da kan relasjonene spesifiseres med faktisk way id i osm og det blir ikke noe krøll når ways kopieres (tror ikke engang jeg vet hvordan jeg kopierer en relasjon fra et lag til et annet i JOSM)

Nei, veier har som regel bare én offisiell skrivemåte. Desverre er det ofte ikke den som står på skiltene. Hvorvidt det brukes vei eller veg bestemmes av kommunen, men i noen tilfeller (som f.eks i Trondheim) var det forskjellige praksiser i kommunene som har blitt slått sammen, og derfor finnes det områder med “veg” og områder med “vei” i Trondheim. Nye veier navngis så vidt jeg vet fortsatt etter de gamle skillelinjene.

Jeg har tenkt at dette gjelder veier med stor trafikk som allerede er godt tagget i OSM i dag. Jeg har ikke brukt noe energi på å gjøre noe smart. En lignende utfordring er at vegene i Elveg er flere type objekter: VegSenterlinje, Kjørebane, Kjørefelt, Svingekonnekteringslinje. Det er ikke alltid sikkert at den beste måten å representere et kryss med flere av disse på i OSM er å ta med alle disse som veier.

I tillegg til bro/tunnel (MEDIUM=L/U) har vi MEDIUM=B som skal gå gjennom bygninger. Denne ser ut til å være noe overrepresentert i Bærum hvor f.eks. Lysakerlokket, vegen under Sandvika Storsenter og det som ser ut som parkeringsgarasjer under Fossum terasse er tagget slik.

Jeg vil tro det er lettere å sjekke for oppdateringer ved å ta forskjellen mellom ny og gammel Elveg-data enn å sammenligne nye Elveg-data med OSM. Det krever selvfølgelig at vi lagrer gamle versjoner av dataene. Ang. “Simplify Ways” i JOSM, så tror jeg det ofte er fornuftig. Det er en del veger der punktene ligger tett i tett på ei rett linje, men de fleste har ei fornuftig tetthet. Avviksparameteren bør settes ned til 0.5-1 m for å holde nøyaktigheten god, men selv med dette kan antall punkter reduseres betraktelig.

Geir Ove, jeg ser motorveier alltid tagges som highway=trunk. Ifølge No:Map Features bør en del av dem tagges som highway=motorway. Noen spesiell grunn til at du har valgt highway=trunk?

Jeg forstår ikke helt. Kan du utdype/gi eksempler?

Poenget mitt var at vi må sørge for å kontrollere/legge til levels når det er flere veier som krysser i ulike nivåer. Er dette korrekt? Dette kan vel uansett plukkes opp av validering.

Høres smart ut dersom vi primært er interessert i endringer i Elveg-data, og ikke ønsker å følge med på om veiene i OSM endres. Og det kan man jo godt argumentere for, jeg har ikke noe sterkt syn på det per nå.

Dersom vi sjekker for endringer mellom gamle og nye Elveg-data slik du beskrev, så høres dette greit ut. Men jeg kom over følgende advarsel: This algorithm is harming the geometry seriously in some cases (narrow curves), because it is not aware of angles but only of differences in position in metres. Lurer også på hvorfor du tror det er fornuftig. Om vi ikke gjør det, øker det størrelsen på databasen til problematisk nivå? Forvansker det noe vedlikehold? For vår del som importerer blir det jo enda et steg som må gjøres for hver eneste vei (ikke automatisert uten sjekk, pga. den nevnte advarselen).

Det er ingen informasjon om hva som er motorvei i Elveg. Grunnen til at de tagges som trunk er fordi de europaveier eller riksveier. På samme veg som *_link har jeg ikke brydd meg spesielt om dette, siden disse har stor trafikk og er lagt inn og tagget allerede. Jeg har først og fremst brydd meg om at det skal være lett å legge inn veier der de mangler i dag.

For eksempel er høyre/venstresvingfelter ofte ei egen linje i geometrien (Kjørefelt) samtidig som feltet er med i felt-spesifikasjonen til VegSenterlinje. Igjen er dette urbane problemer, der jeg ikker har sett for meg at det er så aktuelt å importere. Anbefaler at du sammenligner Elveg-geometrien med OSM-geometrien i kryss i byer.

Det kan sikkert være lurt. Elveg2osm tagger allerede tuneller med layer=-1 og broer med layer=1, men der det er flere høyder kan det være lurt å ta en sjekk.

Det er fullt mulig å følge med på endringer i OSM, f.eks. ved å bruke Overpass API (test det på http://overpass-turbo.eu/). Men jeg tror det i så fall er mer fornuftig å følge utviklingen i OSM for seg og i Elveg for seg.

Ang. simplify ways: Jeg har ikke noe sterkt ønske om det ene eller det andre, men jeg ser ikke noen grunn til at vi skal forby det - vi trenger ikke å ha like noder i de to datasettene. Det bør være tillatt å bruke “Simplify way” (med en liten minsteavstand), men for min del trenger det ikke være et krav. Elveg2osm lager uansett nye noder og deler opp ways der fartsgrenser eller høydebegrensninger endres, så det er ikke et en-til-en-forhold mellom ways i XXXXElveg_default.osm og ways i XXXXElveg.osm. Jeg synes også den advarselen ser noe overdrevet ut. Husk at geometrien er vegsenterlinje og veier er i størrelsesorden 5 m brede. Hvis svingen ikke har noen vesentlig svingradius på innersiden av vegen, synes jeg ikke det er problem om det blir en skarp vinkel.

Ser du for deg et skript som lager relasjoner automatisk basert på XXXXSving.txt? Må ikke i så fall alle veiene i en kommune være importert for at dette skal kunne gå fint? Og er ikke det en litt for stor endring å ta av gangen, jfr. mine kommentarer om dette i første innlegg?

Men ønsker vi ikke at om noen søker på “Torgny Segerstedts veg” i Bergen, så skal de finne veien som heter “Torgny Segerstedts vei”, siden få andre enn lokalkjente har kontroll på om det er vei/veg og derfor vet hva de skal søke etter? Eller er dette et problem som søkemotorene bør løse med “fuzzy matching”?

Neida, det kan gjøres opportunistisk ved at den søker etter OSM-data med riktig nvdb:id, og se om det finnes nøyaktig én vei med hver nvdb:id som deler en node. Hvis en av de to nvdb:id i en svingrestriksjon ikke finnes, så sier den fra om det, og de kan legges inn manuelt. Det kan hende en stor del må legges inn manuelt (hvis det er få veier med svingrestriksjoner som importeres fra Elveg - jeg ser for meg at de fleste av disse veiene finnes fra før). Det er uansett ikke store datamengden. Av 428 kommuner er det bare 132 som har svingrestriksjoner i Elveg, 30 som har mer enn 10 restriksjoner og 15 som har mer enn 20. Jeg ser for meg at datasettet er langt fra komplett, siden Kristiansand og Bergen er de to som har desidert flest restriksjoner.

Det er søkemotorenes oppgave. Det kan godt legges inn i søkemotorene at veg/vei er ekstra nært hverandre for norske adresser, men skal de fungere bra bør de også finne riktig vei om man søker på “Togrny Segerstets veg”.

Det jeg leser ut av dette, er at vi må være obs på svingrestriksjoner på OSM-veiene vi erstatter (JOSM viser skilt ved de aktuelle nodene, så det bør være trivielt) og sørger for å legge disse inn igjen når geometrien er endret (f.eks. med turnrestrictions-plugin til JOSM). Så kan vi senere lage og kjøre et skript som gjør det du beskriver. Dette vil sørge for at vi beholder alle turn restrictions som er lagt inn i OSM, og vi får (når skriptet er laget) lagt inn turn restrictions fra Elveg som mangler i OSM.

Lurer på en ting: Hvor viktig er det at vi holder oss til å oppdatere geometrien til eksisterende veier, fremfor å bare kopiere tags og relations osv. fra gamle veier til nye veier? Spør fordi jeg får problemer bl.a. på Bergens største kryss, Danmarks plass, hvor “Replace geometry” ikke helt vil samarbeide pga. en del relations og ulike veilengder (Elveg-data er delt opp mye mer enn OSM-data pga. ulike nvdb:id, og når jeg setter inn nye noder i OSM-veier og klipper for å kunne erstatte geometrien på tilsvarende veistykker, så får jeg problemer).

Vi må vel også være obs på andre relasjoner, som f.eks. bussruter. Jeg vet ikke hvordan dette fungere hvis man bytter ut geometrien. Jeg kan generelt lite om relasjoner.

Dette kan jeg ikke noe om.

Såvidt jeg ser går det fint å kopiere relasjoner mellom veier med JOSM.

Spørsmål: Hvordan løser man utfordringen med veier som ligger i elveg, men som ikke finnes i virkeligheten? Det finnes en del av dem. Har nevnt dette før men kunne ikke se i farten at det var nevnt noe sted her i forumet.

Skogsbilvei er som regel unclassified. Dette har vi diskutert før og blitt enige om.

Å erstatte geometrien er i praksis umulig på veier fordi lengden i osm og i elveg er forskjellig. Og om man klipper til veiene i osm så de blir like lange først så vil mange teknisk sett bli nye veier og man mister historien. Uansett er det viktig at ikke data forsvinner. Man må være sikker på at alle relasjoner og tagger på noder, veier og relasjoner er intakt etter importen. Man må også være sikker på at ikke polygoner ødelegges der veier er en del av de.

Det er blitt sagt i tidligere diskusjoner at nvdb:id ikke kan brukes som en sikker identifikator over tid og at det derfor ikke er noe poeng i å ta denne med inn i osm.

Min tanke: I områder der det det er generelt dårlig vegdekning i OSM, legg til veiene som finnes i Elveg, så kan heller de(n) som mangler fjernes. For enkeltstående veier som finnes i Elveg men ikke i OSM der det ellers ser ut til å være god OSM-dekning, verifiser med flyfoto eller adressenoder.

Det kan jeg ikke huske at har vært nevnt for Elveg. Mener å huske at det ikke var noen identifikatorer for SSR (Sentralt Stedsnavnregister). I Elveg-spesifikasjonen står det om TRANSID:

Gode tanker og spørsmål, Sverre.

Det beste man kan gjøre er å ha lokal kunnskap. Men om vi skal vente til vi har lokal kunnskap fra hele Norge, så kan dette prosjektet ta “litt” tid. Jeg stiller meg bak det Geir Ove sier: Der hvor det er god dekning i OSM, verifiser nye veier med satellittbilder. Jeg har dessuten en tanke om at det er enklere for OSM-brukere å fjerne veier som ikke finnes i virkeligheten, enn å legge til nøyaktige veier som ikke finnes i OSM. Jeg antar dessuten (helt ut av det blå) at det per nå er et større problem med manglende/unøyaktige veier i OSM enn det er med ikke-eksisterende veier i Elveg.

Da foreslår jeg at “importen” gjøres ved at vi kopierer veier fra Elveg, forsiktig kopierer over alle tags og relasjoner fra eksisterende vei (dette gjøres enkelt i JOSM, men vi må passe på at veien vi kopierer fra stemmer noenlunde overens med veien i kopierer til - dette forenkles av at Elveg-dataene er såpass oppstykket, ettersom det da er lettere å finne tilsvarende veistykker i Elveg-dataene), og fjerner eksisterende vei.

Geir Ove kontrer dette, men dersom det skulle vise seg å stemme, så foreslår jeg at elveg2osm ikke legger til denne taggen, fordi det virker i hovedsak å være denne som deler opp veier (i mye større grad enn fartsgrenser osv.). Det virker i Elveg-dataene som at ethvert kryss i en og samme “vei” gir en ny nvdb:id, og derfor består resultatet av elveg2osm av mange, mange små veistykker mellom kryssene, i stedet for at det finnes én vei med mange kryss. Oppdatering: Oppstykkede Elveg-data er sannsynligvis en fordel, ettersom dette vil gjøre det enklere å kopiere over relasjoner fra tilsvarende OSM-veier. Jeg vet ikke om noen vesentlige ulemper med at OSM-veiene på teknisk nivå er oppstykket mellom kryss.

Ny tanke om å holde styr på progresjon innad i en kommune: Vi kan slette veier fra XXXXElveg.osm etter hvert som vi importerer/forkaster dem. Da kan vi 1) vite nøyaktig hva vi har gjort og ikke gjort, og 2) telle veiene som er igjen maskinelt og ha god og enkel statistikk på hvor mye som er gjort i en kommune.

Geir Ove, jeg mener å ha sett et sted at Elveg-data også inkluderer veier under konstruksjon. Foreslår i så fall at disse tas med i konverteringen, ettersom disse kan legges inn i OSM med passende tagger. Det er for eksempel en stor ny vei/tunnell som åpner i Bergen senere i år, den er allerede lagt inn i OSM (highway=construction og construction=primary) men jeg finner den ikke i Elveg-dataene. Synes det er god info å vite hvor kommende veier skal gå, samt at det er mye raskere å “bytte over” til ny vei når den allerede ligger inne og det eneste som trengs er å bytte tags.

Enig - og det er allerede med kode for dette. Men etter en grep i Elveg-dataene ser jeg at de ikke inneholder noen veger med vegstatus A (konstruksjon) og heller ikke P (vedtatt) eller Q (planlagt). Den første ville bli tagget som highway=construction, construction=, mens de to siste ville blitt slettet.

I den fila du lastet ned ligger også XXXXElveg_default.osm som kan åpnes i JOSM. Det er denne som er input til elveg2osm (output fra sosi2osm), og det som ikke ligger her er det ikke mulig å få scriptet til å putte inn.

Søkte du i originale Elveg-data eller output fra sosi2osm (XXXXElveg_default.osm)? Hvis førstnevnte, så kan det jo hende sosi2osm dropper planlagte veier.

Jeg søkte i de originale Elveg-data (XXXXElveg.SOS). Jeg synes det er lettere å lese og greppe ei SOSI-fil enn ei OSM-fil (som er xml).