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