[NUUG kart] Import av Elveg-data: Veien videre
Sverre Didriksen
sverre.didriksen at usit.uio.no
Mon Jun 8 09:54:55 CEST 2015
Jeg synes ikke det er noe poeng i å slå sammen veier. Eneste unntak må
være en rett vei som er delt opp uten kryss, hvor alle osm-tagger er
like.
Det spiller svært liten rolle hvordan de er delt opp. Jeg synes generelt
at det er fornuftig at hver vei går fra kryss til kryss.
For navigering på GPS (i allefall med Garmin) så spiller dette heller
ingen rolle. Det er i all hovedsak vinkelen i alle kryss som avgjør hva
GPSen forteller deg.
-Sverre
On Sun, 2015-06-07 at 22:54 +0200, Christer van der Meeren wrote:
> Gode innspill.
>
>
> Angående sammenslåing av veier: Er det noen argumenter for/imot dette?
> Vil oppdelte veier for eksempel kunne skape trøbbel for
> navigasjonsprogramvare, som vil ha deg til å ta "til venstre i et
> kryss" når veien egentlig bare følger en venstresving (og det er helt
> tydelig at du er på samme vei gjennom hele svingen) med en sidevei som
> går videre ut til høyre? Har opplevd dette noen ganger og har lurt på
> hva det kommer av.
>
> Jeg vet man ikke skal "tag for the renderer", men om det blir et
> utbredt problem blant alt av navigasjonsprogramvare om veiene deles
> opp i hvert eneste kryss, så bør vi tenke litt gjennom det. Dessuten
> virker den eksisterende praksisen å være at én og samme vei er ett
> veistykke så langt det er mulig, også gjennom kryss. (Kan hende jeg er
> helt ute på viddene nå og oppdeling av veier ikke har noen praktisk
> betydning, men la oss snakke/finne ut av dette.)
>
>
>
> Angående nvdb:id: For meg er dette det samme, i alle fall om veier
> ikke skal slås sammen. Men trenger vi det for noe? Det er et argument
> fra OSM sin side for å ta vekk det som ikke er nødvendig, se her:
> https://wiki.openstreetmap.org/wiki/Import/Guidelines#Use_the_right_tags. Jeg har fjernet det som var nevnt om nvdb:id på wikisiden, siden dette enten beholdes eller tas vekk i preprosesseringen.
>
>
>
> Angående oppdatering 4 ganger i året: Skulle ikke Elveg begynne å
> oppdateres kontinuerlig? Mener dette ble nevnt her for noen måneder
> siden, men jeg kan huske feil.
>
>
> Jeg er enig i at vi kan ha Elveg2osm-filene et sentralt sted. Har
> oppdatert workflow-delen av wikien, kan du ta en titt og evt. rette på
> beskrivelsen av filene?
>
>
>
>
>
>
> 2015-06-07 22:29 GMT+02:00 Geir Ove Myhr <gomyhr at gmail.com>:
> Det er meningsløst å slette nvdb:id manuelt - da lar vi heller
> være å
> legge det inn med elveg2osm. Men jeg synes det gir mening og
> ha med
> koblingen til kildedata der disse kopieres inn som nye veier.
> Jeg
> synes det gir mindre mening å endre strukturen på de
> importerte
> dataene ved å slå sammen vegsegmenter. Man kan like å ha det
> på den
> ene eller andre måten, men jeg ser ikke poenget med å aktivt
> gå inn og
> endre strukturen som datakilden har.
>
> Hvis det blir konsensus om at veiene skal slås sammen så er
> det nok
> informasjon i Elveg til å slå sammen de riktige veiene i kryss
> (men
> det er ikke en liten jobb å skrive den koden). Poenget er å
> slå sammen
> de vegene med samme VNR og parsellnummer (første del av VPA).
> Faktisk
> blir nok dette bedre enn om man skulle slå sammen manuelt
> basert på
> skjønn. Min følelse etter å ha sett på dataene er at vegene
> blir
> hyppig delt opp på grunn av kryss i urbane områder, der vegene
> stort
> sett allerede ligger inne i OSM, men sjeldnere i rurale strøk
> der
> vegene er færre.
>
> Elveg oppdateres forøvrig ikke kontinuerlig, men 4 ganger i
> året (og
> veggeometrien bare to ganger i året om jeg husker rett).
> Forrige uttak
> fra NVDB var 24. mars, så det kommer nok en ny oppdatering mot
> slutten
> av juni.
>
> Jeg tror ikke det er noen grunn til at hver enkelt skal laste
> ned data
> fra kartverket, kjøre sosi2osm etterfulgt av elveg2osm. Det er
> bedre å
> preprossessere alt og legge det ut slik jeg har gjort på
> https://drive.google.com/folderview?id=0BwxPkSBawddGM2djWE9oWjRXdzA&usp=sharing#list.
> Dette er også slik vann- og arealimporten gjøres. Man trenger
> vel
> linux for å kjøre sosi2osm om jeg husker rett, og det vil
> ekskludere
> en del fra å delta.
>
>
> Geir Ove
> (som har skrevet elveg2osm)
>
> 2015-06-07 21:26 GMT+02:00 Espen Oldeman Lund
> <espen at espenpost.com>:
> > For meg var dette ganske greit og forstålig. Mulig det er
> diskutert
> > tidligere, men hadde det ikke vært mulig å koble sammen i
> skriptet
> > vegsegmenter med ulik nvdb:id, men med like OSM tagger? Da
> slipper en å
> > gjøre det manuelt?
> >
> > Og hvorfor kutter vi ikke bare ut nvdb:id i skriptet hvis vi
> ikke skal ha
> > det med videre?
> >
> > Jeg har ikke fulgt med på hele diskusjonen om importen så
> bare si ifra hvis
> > disse tingene har blitt diskutert tidligere.
> >
> > Espen
> >
> >
> >
> > søn. 7. jun. 2015 kl. 16.41 skrev Christer van der Meeren
> > <cmeeren at gmail.com>:
> >>
> >> Hei folkens! Nå har jeg foretatt en større oppdatering av
> importsiden for
> >> å få den til å stemme mer med "Import/Plan_Outline"":
> >>
> https://wiki.openstreetmap.org/wiki/Import/Catalogue/Road_import_%28Norway%29
> >>
> >> Har også laget en fremdriftstabell med alle kommunene:
> >>
> https://wiki.openstreetmap.org/wiki/Import/Catalogue/Road_import_%28Norway%29/Progress
> >>
> >> Setter pris på om flere kan ta et kritisk blikk på dette og
> komme med
> >> tilbakemeldinger eller rette opp/utfylle om nødvendig.
> Spesielt
> >> workflow-avsnittene, som er helt nye.
> >>
> >> Når denne siden er OK gjenstår det vel bare å be DWG ta en
> titt.
> >>
> >> 2015-05-27 14:39 GMT+02:00 Christer van der Meeren
> <cmeeren at gmail.com>:
> >>>
> >>> Hei igjen igjen. Jeg ser at det allerede ligger en del
> inne på wikien:
> >>>
> https://wiki.openstreetmap.org/wiki/Import/Catalogue/Road_import_%28Norway%29
> >>>
> >>> Er det slik at det omtrent bare er å pusse opp denne siden
> litt og
> >>> kontakte DWG? Med oppussing, er følgende tilstrekkelig?
> >>>
> >>> 1) Henvise til Elveg2osm under "Data transformation"
> >>> 2) Oppdatere "Import process" med konkrete tips til
> fremgangsmåte.
> >>> Herunder:
> >>> a) Hvis vei ikke eksisterer fra før, kopier fra Elveg
> og korriger
> >>> tagger
> >>> b) Hvis veier eksisterer fra før, korriger/legg til
> tags fra Elveg.
> >>> For å rette opp i geometrien, bruk "Improve Way
> Accuracy" (ikke "replace
> >>> geometry") slik at historikk, relations, kryss osv.
> beholdes ("replace
> >>> geometry" virker dårlig sammen med relations, og vil
> dessuten frakoble alle
> >>> kryss, som må kobles manuelt på igjen)
> >>>
> >>> "Fremdriftsskjema" (tabell fremdrift per kommune) må
> naturligvis også
> >>> lages, men det er ikke store jobben og det skal jeg
> alltids få ordnet.
> >>>
> >>> - Christer
> >>>
> >>>
> >>> 2015-05-04 13:39 GMT+02:00 Christer van der Meeren
> <cmeeren at gmail.com>:
> >>>>
> >>>> Hei igjen. Livet har tatt meg igjen, og jeg har ikke
> kapasitet til å ta
> >>>> dette videre akkurat nå. Slik jeg ser det gjenstår det å
> si ifra til DWG og
> >>>> lage wiki-side om importen (om man i det hele tatt vil
> kalle det import -
> >>>> det blir jo en veldig manuell prosess). Sikkert ikke så
> mye arbeid, men jeg
> >>>> har aldri gjort det før og har ikke tid til å sette meg
> inn i det for
> >>>> øyeblikket.
> >>>>
> >>>> Noen som kan si ifra til DWG-mailinglisten og lage
> import-wikiside? Det
> >>>> kan for eksempel være greit å få svar på om vi må bruke
> dedikerte
> >>>> import-brukere til dette.
> >>>>
> >>>> 2015-04-22 11:48 GMT+02:00 Christer van der Meeren
> <cmeeren at gmail.com>:
> >>>>>
> >>>>> Tror det har vært nevnt tidligere, men vi kan jo si at
> veier fra
> >>>>> kartverket som ikke finnes i OSM legges bare inn dersom
> lokal kunnskap eller
> >>>>> lignende (Google street view?) faktisk tilsier at de
> eksisterer.
> >>>>>
> >>>>> Jeg vet også at i mitt nærområde (Bergen), selv om
> veinettet er ganske
> >>>>> fullstendig, så er det enkelte steder upresishet i
> geometrien i OSM som er
> >>>>> stor nok tll at navigasjon kan bli forvirret på
> nærliggende veier, og til at
> >>>>> det vil se rart ut om man legger inn nye veier fra Elveg
> - da vil de nye
> >>>>> veiene gjerne være korrekte, men ikke stemme helt
> overens med veinettet de
> >>>>> legges inn i.
> >>>>>
> >>>>> 2015-04-22 11:15 GMT+02:00 Sverre Didriksen
> >>>>> <sverre.didriksen at usit.uio.no>:
> >>>>>>
> >>>>>> Jeg heller nok mest til at vi importerer i områder hvor
> vi manger mye
> >>>>>> data. I områder hvor det er godt med osm-data må man
> være varsom. Det
> >>>>>> er
> >>>>>> mange steder at osm stemmer mer enn kartverkets data,
> og da er det jo
> >>>>>> viktig å ikke ødelegge det. Som jeg har nevnt tidligere
> så har jeg
> >>>>>> mange
> >>>>>> steder i f.eks. Valdres kommet over veier som
> kartverket har som rett
> >>>>>> og
> >>>>>> slett ikke eksisterer mer. De er knapt bra nok for
> stier, og de er det
> >>>>>> jo greit å ikke importere for å si det slik.
> >>>>>>
> >>>>>> -Sverre
> >>>>>>
> >>>>>> On Wed, 2015-04-22 at 11:02 +0200, Christer van der
> Meeren wrote:
> >>>>>> > Det var ikke stormende respons på dette. Spør igjen
> og venter litt
> >>>>>> > til
> >>>>>> > før vi evt. går i gang.
> >>>>>> >
> >>>>>> >
> >>>>>> > 1. Er det OK at elveg2osm i konverteringen tagger
> VEGSTATUS=S som
> >>>>>> > highway=track, og så bruker man eksisterende OSM-tags
> dersom veien
> >>>>>> > eksisterer (eller overstyrer dersom man har lokal
> kunnskap)?
> >>>>>> >
> >>>>>> > 2. Noe jeg bør vite før jeg melder fra om importen
> til OSM/DWG?
> >>>>>> >
> >>>>>> >
> >>>>>> > 3. Bør vi bruke dedikerte import-brukere til dette?
> >>>>>> >
> >>>>>> >
> >>>>>> > 4. Noen som vil se gjennom koden på
> >>>>>> > https://github.com/gomyhr/elveg2osm?
> >>>>>> >
> >>>>>> >
> >>>>>> > 2015-04-05 16:56 GMT+02:00 Geir Ove Myhr
> <gomyhr at gmail.com>:
> >>>>>> > 2015-04-05 14:07 GMT+02:00 Christer van der
> Meeren
> >>>>>> > <cmeeren at gmail.com>:
> >>>>>> > > 1. Forbedre geometri på eksisterende veier
> >>>>>> > > 2. Legge inn manglende data (både hele
> veier og tags på
> >>>>>> > eksisterende veier,
> >>>>>> > > f.eks. fartsgrenser)
> >>>>>> >
> >>>>>> > Jeg synes det er ryddigere å se på det som
> tre forskjellige
> >>>>>> > prosesser:
> >>>>>> > A. Legge inn veger som mangler i OSM
> >>>>>> > B. Forbedring av geometri basert på
> Elveg-geometri
> >>>>>> > C. Oppdatering av tagger i OSM basert på
> tagger i
> >>>>>> > Elveg-settet
> >>>>>> >
> >>>>>> > Selv har jeg mest hatt prosess A i tankene
> når jeg har laget
> >>>>>> > elveg2osm. Derfor er jeg komfortabel med at
> ikke alt blir
> >>>>>> > perfekt der
> >>>>>> > det er mange felt og/eller nivåer og andre
> ting som typisk
> >>>>>> > dukker opp
> >>>>>> > der vi har god dekning i OSM fra før. Når det
> er sagt, har
> >>>>>> > jeg
> >>>>>> > testet
> >>>>>> > konvertering også i mange store byer, og
> forsøkt å få
> >>>>>> > konverteringen
> >>>>>> > til å bli best mulig der også (f.eks. ved å
> legge til
> >>>>>> > trapper,
> >>>>>> > veger
> >>>>>> > gjennom bygninger, de vanligste
> >>>>>> > kollektivfelt-konfigurasjonene,
> >>>>>> > sykkelfelt, fortau, etc.).
> >>>>>> >
> >>>>>> > En ting som mangler er en kritisk gjennomgang
> av
> >>>>>> > konverteringen. Jeg
> >>>>>> > har nå fått lukket det meste av det jeg mener
> må håndteres.
> >>>>>> > Koden
> >>>>>> > ligger på
> https://github.com/gomyhr/elveg2osm. Den bærer
> >>>>>> > preg
> >>>>>> > at jeg
> >>>>>> > verken kjente input-dataene spesielt godt da
> jeg begynte, og
> >>>>>> > heller
> >>>>>> > ikke hadde noen klar idé om hva som skulle
> gjøres, men jeg
> >>>>>> > tror det er
> >>>>>> > mulig å skumme gjennom og få en idé om hva
> som skjer. Ellers
> >>>>>> > har jeg
> >>>>>> > lastet opp kommunevise filer på min google
> drive:
> >>>>>> >
> >>>>>> >
> https://drive.google.com/folderview?id=0BwxPkSBawddGM2djWE9oWjRXdzA&usp=sharing#list.
> >>>>>> > Der ligger:
> >>>>>> > xxxxElveg_default.osm: Resultat av
> konvertering fra SOSI til
> >>>>>> > OSM med
> >>>>>> > sosi2osm (med default.lua)
> >>>>>> > xxxxElveg.osm: Hovedresultat av konvertering
> av
> >>>>>> > xxxxElveg_default.osm
> >>>>>> > til OSM-tagger
> >>>>>> > xxxxdetatched_barriers.osm: Fil med barrierer
> som ikke
> >>>>>> > henger
> >>>>>> > fast i
> >>>>>> > veggeometrien. Enklere å legge inn manuelt
> enn automatisk.
> >>>>>> > xxxxdeleted_elements.osm: Fil med elementer
> som finnes i
> >>>>>> > Elveg_default, men som ikke er tatt over til
> xxxxElveg.osm.
> >>>>>> > xxxxelveg2osm.log: Loggfil med advarsler om
> ting som er
> >>>>>> > uvanlig eller
> >>>>>> > feil. Ikke noe veldig konsistent format.
> >>>>>> >
> >>>>>> > Det er mye som _kan_ endres, men jeg vil
> gjerne vite om det
> >>>>>> > er
> >>>>>> > noe som
> >>>>>> > vil forenkle eller forbedre betydelig - helst
> uten at det er
> >>>>>> > alt for
> >>>>>> > mye jobb.
> >>>>>> >
> >>>>>> > Ellers ser jeg gjerne at noen andre tar seg
> av
> >>>>>> > organiseringen
> >>>>>> > med evt.
> >>>>>> > tracking av progresjon og slikt. Torstein og
> Ruben har jo
> >>>>>> > allerede
> >>>>>> > noen gode verktøy og Christer er vel strengt
> tatt allerede
> >>>>>> > godt i gang
> >>>>>> > med å organisere :-)
> >>>>>> >
> >>>>>> > Geir Ove
> >>>>>> >
> >>>>>> >
> >>>>>> > _______________________________________________
> >>>>>> > kart mailing list
> >>>>>> > kart at nuug.no
> >>>>>> > http://lists.nuug.no/mailman/listinfo/kart
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >> _______________________________________________
> >> kart mailing list
> >> kart at nuug.no
> >> http://lists.nuug.no/mailman/listinfo/kart
> >
> >
> > _______________________________________________
> > kart mailing list
> > kart at nuug.no
> > http://lists.nuug.no/mailman/listinfo/kart
> >
>
>
>
> _______________________________________________
> kart mailing list
> kart at nuug.no
> http://lists.nuug.no/mailman/listinfo/kart
More information about the kart
mailing list