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

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).

Dessverre tar ikke “Paste_relations” vare på medlemmenes rekkefølge i relasjonen, som er viktig for ruter, som bussruter. Istedenfor blir den lagt til som siste medlem av relasjonen. Bussruter må derfor sjekkes manuelt, hvis du skal lage nye veier og overføre alle egenskaper over til den nye veien. Det kan fort bli veldig tidkrevende, da det f.eks går 31 bussruterelasjoner igjennom Dronning Eufemias gate, eller 16 igjennom Danmarks plass.

Kan det tenkes at planlagte veier og veier under konstruksjon er i et annet datasett?

Det virker å være få bussruter generelt som er lagt inn i Bergen, og det er mulig de uansett er gamle (har ikke sjekket ennå). Det kan være en idé akkurat her å fjerne bussrutene og legge inn oppdaterte ruter for Bergen. Men jeg ser problematikken og har ikke en god løsning på det. Noen andre?

Ang. veier med relations: Vi kan bruke “improve way accuracy mode”. Enkelt om man har Elveg-data i lag under til å se etter. Blir ikke “perfekt” geometri, og vi må fremdeles passe på å kopiere over nye tags fra Elveg (f.eks. fart) for korrekte deler av veiene.

Virker for meg å bli mer eller mindre manuelt uansett hvordan man snur og vender på det.

Jeg tviler, men det går an å sjekke Vbase, som er det andre frigitte produktet fra NVDB. Du kan jo sjekke på www.vegvesen.no/vegkart/ om du ser den der - tror den nå er oppdatert live mote NVDB.

Elveg-geometrien er ikke “perfekt”, men den er bedre enn det meste som er lagt inn i OSM. Det oppgis at det tilstrebes at alle veger skal ha maksimal gjennomsnittlig feil på 2 m, men at det i praksis er mye bedre mange steder. For å rette opp geometrien i OSM til å bli mye bedre enn den er, og god nok for alle praktiske formål holder det å flytte på de nodene som definerer vegen i dag, og det er der jeg har sett ganske mange færre enn det som finnes i Elveg. Jeg rettet for ei stund sida opp vegene i området mellom Meyermarken og Fredens Bolig (changeset 29171425), og det tok ikke så lang tid.

Ja, og det er slik det meste av OSM er laget. Elveg gir oss bare enda en datakilde i tillegg til GPS-spor og luftfoto.

Da har jeg et forslag:

  • Endre elveg2osm slik at den ikke legger til nvdb:id. Dette fordi (jeg antar) vi da kan slå sammen mange veistykker som nå er delt opp utelukkende pga. nvdb:id, og det blir da mye enklere å kryssjekke og kopiere tags fra Elveg, når vi ikke trenger å sjekke 10 korte veistykker hvor nvdb:id viser seg gang på gang å være det eneste som varierer mellom veistykkene.

  • Der veier eksisterer og har relations bruker vi “improve way accuracy” for å flytte eksisterende noder og legge til nye, og kopierer deretter relevante tags fra Elveg

  • Der veier eksisterer men det ikke er trøbbel med relations eller annet lignende kan vi etter eget ønske bruke “replace geometry” i stedet for “improve accuracy”, men må da passe på at alle veier henger sammen og vi ikke har duplikatnoder i kryss som beskrevet i OP under “replace geometry”.

  • Der veier ikke eksisterer kan vi kopiere Elveg-data direkte og koble eksisterende veier på disse.

Og jeg kan gjenta det jeg har sagt tidligere om måling av progresjon: 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.

Tanker?

Niks.

Det må være før min tid. Fant bare en mail fra Vidar som nevnte det i forbindelse med Oslomarka. Jeg har endret det lokalt hos meg. Regner med å pushe dette og noen andre forbedringer til github i morgen en gang hvis ikke problemer dukker opp i kjøringen jeg har satt i gang i natt.

Jeg ser ikke poenget med å fjerne nvdb:id. Merker du flere vegstykker etter hverandre i JOSM kommer det opp på de taggene som er forskjellig. Du kan så dem sammen med “Combine” (f.eks. trykke C), og du vil måtte velge en tag for der det er konflikt og “none” er en mulighet. Poenget med å ha nvdb:id der er at hvis noe mer data skal vurderes senere, så vil det være denne som er nøkkelen de andre dataene refererer til. Det kan være akseltrykk, svingrestriksjoner, eller andre data som ligger i NVDB, men ikke i Elveg.

Nå det er sagt, er det litt mer struktur i Elveg-dataene enn bare en samling små vegstykker med hver sin id. Innen hver kommune har hver veg et nummer (paret KOMM og VNR sammen vil være unikt), og denne er delt opp i parseller. Parsellene er første tall i VPA-taggen. De to neste er meterverdiene innenfor denne parsellen. I prinsippet kunne vi slått sammen alle vegbitene i hver vegparsell til én way (så lenge antall noder ikke blir for høyt) for de bitene som ellers har like tagger. Men det er en del ekstra jobb som ikke åpenbart gir et bedre datasett. Jeg tror også at veldig korte vegbiter først og fremst er en utfordring i urbane strøk. Taggene fra Elveg ser du i fila *Elveg_default.osm (som er output fra sosi2osm).

Å klassifisere skogsbilveg som “Unclassified” er alt for høgt. Den er faktisk over “Residential” i veldig mange rute system brukt på GPS. “Unlcassified” er rett under “Tertiary”.
Bør vere maks “Service” og helst “Track” med grade 1.

Det blir likevel en manuell jobb med å slå sammen og sjekke om Elveg-veistykkene har samme tags - og hvis ikke, så må man finne ut hvilke veistykker som har andre tags. Da er det enklere å bare sjekke veistykke for veistykke og kopiere relevante tags til OSM, som forsåvidt er greit nok.

Når du nevner “poenget med å ha nvdb:id”, tenker du da i XXXXElveg.osm eller i OSM? For om vi skal ha inn nvdb:id i OSM så må vi jo splitte omtrent samtlige av de eksisterende veiene for å tilpasse til Elveg-veistykker.

Jeg har vel først og fremst tenkt at filene skal brukes til å legge inn veger som mangler og da er det best å få mest mulig informasjon i tillegg til geometrien.

Når det gjelder veger som ligger inne allerede, kan man sikkert kopiere over noen tags (fartsgrenser, høydebegrensninger, bru, etc), men der ville jeg nok gått fram litt annerledes. F.eks. kan man søke etter søke etter maxspeed=30 i XXXXElveg.osm og så gå over og manuelt legge til maxspeed=30 på samme steder i OSM-laget. Da har det ikke noe å si hvordan vegstykkene er delt opp. Uansett er det viktig å ikke blindt overføre tagger fra Elveg der det ligger tagger fra før. Da kan man heller merke seg stedene det er konflikter og dra ut og se.

Hvis du ser at noe blir enklere hvis en spesiell tag er borte i Elveg-laget (f.eks. nvdb:id) er det forsåvidt bare å merke alt (Ctrl+A) og slette den aktuelle taggen. Men vegstykkene med like tagger blir jo ikke dermed slått sammen.

Jeg tenker det et poeng å ha med nvdb:id når man kopierer inn veger, siden man da har en referanse til kilden de er importert fra. Jeg ser ingen grunn til å legge det inn på eksisterende veger (med mindre geometien byttes ut - og jeg tror manuell justering er bedre).

Da virker det som om vi nærmer oss noe konkret. Med tanke på “import”-aspektet - dette er jo strengt tatt ikke import av data, men helmanuell forbedring av eksisterende data. Jeg vet ikke hvordan OSM-policy er på dette, men man trenger kanskje ikke egne import-brukere eller å melde fra til OSM om slikt?

Det er vel greit å melde fra i alle fall, med henvisning til eksempeldata og prosedyre. De kan fort ha gode forslag til forbedringer.

Vi trenger også en litt mer kritisk gjennomgang av konverteringen til XXXXElveg.osm. Fra hukommelsen kommer jeg på et par ting som bør håndteres:

  • Håndtering av veger med vegstatus U og S (jeg har sendt mail til kartverket om dette)
  • Sletting av veger som ikke har andre tagger enn nvdb:id
  • Litt bredere tolkning av kjørefeltinfo
  • Avgjørelse om OBJTYPE=Skogsbilveg skal være road=unclassified eller road=track
  • Vurdering om akseltrykk skal tas inn, og i så fall hvordan Elveg-data skal mappes til OSM-tags

Høres ut som en quick fix fra din side - eller mente du at det bør diskuteres? Noen grunn til at du mener de bør slettes?

Kan du utdype?

Et Google-søk på skogsbilveg site:lists.nuug.no/pipermail/kart gir treff fra diskusjonen om dette. Jeg kunne ikke ved et raskt overblikk se at det var nådd konsensus om dette. Bør kanskje tas en ny runde på mailinglisten?

Er det noen grunn til ikke å ta det inn? Det finnes en tag for dette, maxaxleload.

Ja , det er en quick fix fra min side. Men jeg oppdaget først nylig at det fantes slike veger. Jeg har en rutine for å slette kurver som ikke har noen tags (dvs. flytte dem over i ei egen fil for slettede objekter), men jeg tenkte ikke på at kurver vil få nvdb:id tag selv om de ikke får noen andre tagger. Ikke vanskelig å fikse - det er bare ikke gjort ennå. Og hvis man gransker konverteringen litt nærmere, blir jeg ikke overrasket om man kommer over flere ting i samme kategori.

Konveringen ser bare på de vanligste feltspesifikasjonene (to felt i hver retning, ett felt i ei retning, to felt i samme retning, og noen til), og legger til en note=* på resten. Det hadde gått an å lage en logisk parser her, som ga ut “riktige” OSM-tags for alle mulige kombinasjoner, men etter å ha sett på eksempler med hvordan høyre/venestrefelt spesifiseres og oppfører seg i forhold til OBJTYPE=Kjørefelt (der feltene er nevnt begge steder), ser jeg at dette ikke blir 100 % riktig uansett. Derfor er de vanligste kombinasjonene hardlinket til OSM-tags. Det tenker jeg å fortsette med, men listed over de hardlinkede kombinasjonene bør utvides litt.

Jeg er også usikker på om den diskusjonen er relevant for denne konverteringen. I konverteringen fra Elveg er spørsmålet hva veger som har VEGSTATUS=S (skogsbilveg) skal tagges som, uavhengig av andre definisjoner av “skogsbilveg”. Av de jeg vegene jeg kjenner til som har VEGSTATUS=S, så kan alt passe som highway=track, med forskjellig tracktype fra grade1/2 (vegen til Estenstadhytta i Trondheim), til grade3/4 (traktorveger med dype spor og høyt gress i midten). Fordelen med track er at det vil være rikitg for de fleste (mulig unntak for fjellveger mellom større veger), og at de kan raffineres utfra lokalkunnskap med tracktype.

Hovedgrunnen til å ikke ta det inn er at det er litt tidkrevende å legge det inn. Kanskje det er bedre å starte å importere ting enn at jeg skal plundre med dette.

Når det gjelder taggingen, er taggingen for aksellast i OSM grei nok, men i Elveg er det mange tall og klasser som kan tolkes (det er også med totalvekt og lengde). Ta en titt på Elveg-spesifikasjonen og se hva som skal være oppgitt i Elveg.

I tillegg ser jeg nå at XXXXAksel.txt ikke lenger finnes i de siste Elveg-datasettene. Jeg oppdaget nå at det ikke finnes i det som er tatt ut 2015-01-28, og lastet akkurat ned det fra 2015-03-24, og det finnnes ikke der heller. For 2014-11-23 og tidligere, er det med. Usikker på om dette er et bevisst valg eller en forglemmelse. Får sende av gårde en mail. Uansett - dette blir en kompliserende faktor.

Alt i alt taler dette for at det ikke er verdt bryet å ta inn aksellaster nå.