[NUUG kart] Import av Elveg-data: Veien videre
Anders Fougner
anders.fougner at gmail.com
Wed May 27 15:09:43 CEST 2015
Jeg synes at "kvalitetstaggen" i ELVEG, dersom den finnes der på samme
måte som i f.eks. Samferdsel, bør kunne brukes for å definere hva som
kan importeres og hva som bør avmerkes som "dårlige data" (lett sporbart).
Kvalitetstaggen er angitt på et litt rart format, f.eks. "kvalitet=20
1500" der det første tallet ser ut til å si noe om hva slags metode som
er brukt for å innhente data (f.eks. digitalisert ortofoto,
manustegning, håndholdt GPS e.l.), og det andre tallet sier noe om
nøyaktigheten i centimeter (f.eks. 200 = 2m, sikker linje, 1800 = 18m,
svært usikker linje).
Mulig dette kan lagres et sted under source-tagger for å gjøre det lett
å spore opp veger med dårlig nøyaktighet?
F.eks.
source:name = Kartverket N50
source:date = 2015-05-27
source = <Metoden fra kvalitetstaggen>
source:accuracy = <Nøyaktigheten fra kvalitetstaggen>
(den siste der fant jeg på nå...hvis noen har en bedre metode er det
bare å foreslå!)
Anders
--
Anders.Fougner at gmail.com
+47 97158863
Sent from my Commodore 64
Den 27.05.15 14.39, skrev Christer van der Meeren:
> 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
> <mailto: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 <mailto: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
> <mailto: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 <mailto:gomyhr at gmail.com>>:
> > 2015-04-05 14:07 GMT+02:00 Christer van der Meeren
> > <cmeeren at gmail.com <mailto: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 <mailto: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