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

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

Ang. veier med bare nvdb:id: Hvorfor skal de slettes?

Ang. “litt bredere tolkning av kjørefeltinfo” - jeg forstår det da slik at dette er noe du sørger for å implementere i koden din.

Ang. skogsbilveg: Ettersom det ikke er tagger i Elveg-dataene som kan si om det skal være track eller annet, så foreslår jeg at vi bruker det tryggeste (track) og legger inn en note=* om andre alternativer, og om å legge inn track. Og der veien eksisterer fra før med en passende tag, så brukes denne dersom lokal kunnskap e.l. ikke tilsier at den bør endres.

Ang. totalvekt og lengde, det finnes OSM-tagger for begge disse to (maxweight og maxlength). Hvis du likevel mener det blir tidkrevende og komplisert så vet nok du best. Jeg tenker at dette kan uansett legges inn manuelt i etterkant.

Det er veier som importen ikke har satt noen fornuftig tag på. Det er ikke så mange av dem igjen nå. Det er bedre at de havner i XXXXdeleted_elements.osm og man kan se at denne veien ikke er blitt importert tilfredsstillende.

Ja, jeg har lagt inn dette nå.

Jeg har endret tilbake til highway=track foreløpig. Det stemmer best med de veiene jeg kjenner til som ligger inne som Skogsbilveg i Elveg. Dette bør diskuteres før import.

Det at de forsvant fra de siste Elveg-datasettene var tungen på vektskålen. Jeg er også usikker på om det som var i Elveg korresponderer med skilting (tungtransport-operatører skal visstnok sjekke andre kilder i tillegg). Mulig det er bedre å plukke ut skilter fra NVDB senere en gang.

Da har jeg tatt dette tilbake til mailinglisten.