[NUUG kart] Import av Elveg-data: Veien videre
Christer van der Meeren
cmeeren at gmail.com
Sun Jun 7 22:54:40 CEST 2015
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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.nuug.no/pipermail/kart/attachments/20150607/9e5dd23b/attachment-0001.htm
More information about the kart
mailing list