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