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.
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.
Å 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:
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.
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.
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.