nvdb:id-taggen har minimal verdi når de ikke står på et veistykke som er (nesten) nøyaktig likt det som ligger i NVDB. Når flere vegstykker slås sammen finnes ikke lenger noe tilsvarende vegstykke i NVDB, så da er det like greit å fjerne dem. Dessuten var det lettere å fjerne taggene og så teste om resterende tagger var like enn å teste for likhet uten å fjerne taggene.
Geir Ove 2015-08-24 11:37 GMT+02:00 Christer van der Meeren <[email protected]>: > Importerte et par nabolag og kan bekrefte at det ble noe enklere når jeg > slipper å slå sammen i like stor grad. Noe sammenslåing/oppsplitting blir > det riktignok uansett. Merker meg at du forkaster nvdb:id og nvdb:date ved > sammenslåing - dette er gjort med vilje? Har disse taggene egentlig minimal > verdi? > > Har ikke kommet over noen feil på det begrensede området jeg har sett på. > > 2015-08-24 8:29 GMT+02:00 Geir Ove Myhr <[email protected]>: >> >> Jeg har laget ei gren av elveg2osm hvor vegstykker blir forsøkt slått >> sammen etter VPA/VNR og tagger. Koden ligger her: >> https://github.com/gomyhr/elveg2osm/tree/longways. Det ligger ikke >> inne noe test for om veier får for mange noder ennå. Jeg har lagt ut >> genererte Elveg-data for Bergen på >> >> >> https://drive.google.com/file/d/0BwxPkSBawddGZVlqbndJVlBLTTg/view?usp=sharing. >> >> Du kan ta en titt på den og se om det hjelper arbeidsflyten og om noe >> eventuelt har blitt feil. >> >> Geir Ove >> >> 2015-08-18 20:29 GMT+02:00 Christer van der Meeren <[email protected]>: >> > Jeg har funnet ut at jeg i hovedsak jobber mest effektivt under >> > Elveg-importen ved å bruke Replace Geometry (jeg fant ut at det var >> > langt >> > fra så problematisk mtp. relasjoner osv. som jeg først trodde). Kanskje >> > flere har gjort dette? >> > >> > Men i denne arbeidsflyten må man ha tilsvarende veistykker i begge >> > datasett, >> > som vil si at man ofte må gjøre en av følgende: >> > >> > A. Splitte opp OSM-veistykker for å tilsvare Elveg >> > B. Slå sammen Elveg-veistykker for å tilsvare det som ligger i OSM (kun >> > sammenslåing der ikke noe annet enn nvdb:id eller nvdb:date er >> > forskjellig, >> > så klart) >> > C. En mellomting >> > >> > Dette har noe å si for hvordan nvdb:id og nvdb:date tas vare på. Dersom >> > man >> > går for B eller C, så kan man enten slette disse, eller man kan slå dem >> > sammen (slik at man får en liste med verdier, f.eks. >> > nvdb:id=450124;450125;450126). Har en slik liste med ID-er (og evt. >> > datoer) >> > en verdi, enten nå eller i fremtiden? Jeg tenker at dato for datafangst >> > er >> > jo gjerne kjekt å vite, så jeg prøvde i går å jobbe ut ifra C, hvor jeg >> > slo >> > sammen veier hvor kun nvdb:id varierte (men lot være oppsplittet når >> > nvdb:date endret seg), og splittet opp OSM-veier til å samsvare med >> > dette. >> > Tok da vare på nvdb:id i en slik liste. >> > >> > OSM har generelt en policy på "one feature, one element", så slik sett >> > er B >> > best (antatt at veiene i OSM er slått sammen noenlunde logisk - det >> > virker >> > de ofte å være, og de er uansett mye mindre oppstykket enn Elveg). >> > >> > Og mens vi er inne på id-taggen: Bør denne fjernes dersom man gjør >> > endringer >> > på veien som ikke ligger i Elveg, f.eks. endrer veiklasse? Jeg vet ikke >> > hva, >> > om noe, som er tenkt ang. fremtidige automatiske oppdateringer... Det >> > beste >> > og mest sikre jeg kan tenke meg, er å skrive et verktøy for å beholde >> > kun >> > det som har endret seg mellom to .osm-filer generert av elveg2osm (eller >> > rådataene fra Elveg, og så kjøre denne diffen gjennom elveg2osm), og så >> > gå >> > gjennom disse endringene manuelt. Det blir jo uansett betraktelig mindre >> > å >> > gjøre enn den første importen som nå pågår. Og hvis det er tilfelle at >> > dette >> > er beste løsning, så har jo nvdb:id nada å si. >> > >> > Tanker? >> > >> > - Christer >> > >> > _______________________________________________ >> > kart mailing list >> > [email protected] >> > http://lists.nuug.no/mailman/listinfo/kart >> > > > _______________________________________________ kart mailing list [email protected] http://lists.nuug.no/mailman/listinfo/kart
