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.