<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=iso-8859-1"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span lang=NO-BOK style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hei. Med all og stor respect for den entusiastiske innsatsen i forbindelse med N50 baser masse/bulk editering av OSM, som den visa importen er, la meg få lov å si/legge til noen få kritiske meninger. Jeg spesielt reagerer på uttalelser som «jeg er usikker...», spekulative estimater for eventuelle korreksjoner med mer. Situasjonen er mye, mye, mer alvorlig enn bare det. Det er mange årsaker til det. La meg nevne noen få:<o:p></o:p></span></p><p class=MsoNormal><span lang=NO-BOK style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-Endring av OSM kildedata, spesielt masseendring, uansett hvor kommer den fra, har innvirkning på alle (mange) som lager kart for store ommråder (Skandinavia, Europa, Verden ...). Utfordringen kan være nye feiltyper, mye ekstraarbeide osv.<o:p></o:p></span></p><p class=MsoNormal><span lang=NO-BOK style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-For å vite at noe er feil vi må vite hva er korrekt/riktig. For mange av begrepene, desverre, vi vet ikke hva er korrekt på grunn av mangelfull og vage definisjoner i OSM wiki. Derfor, noe som jeg oppfater som feil andre kan kanskje levemed (fe. ordiner veiseksjon tagget som rundkjøring, eller omvent, replika av konsekutive noder, vektorer, replika av arela grenser/seksjoner, nesten overlappende repliserte arealer, river-line som løper utenfor den tilsvarende river-area osv).<o:p></o:p></span></p><p class=MsoNormal><span lang=NO-BOK style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-Mange av feilene er usynlige for editorer som importerer/laster opp data (de er ikke engang klar over at de lagde feil). Samt, brukere som lager kart må oppdage og reparere slike feil fordi de kan være «show» stoppere og/eller degradere kartets kvalitet. Det er stor mengde (enormt stor) av slike feil i OSM kildedata. Heldigvis de fleste kan programatisk repareres med en robust «data-preparation-tool-chain». Vær obs på at diff filer hjelper veldig lite her (tvert imot, de akumulerer feilmengden i brukerdatabasen), samme med «do-ovracy» (som er veldig treg). Osv.<o:p></o:p></span></p><p class=MsoNormal><span lang=NO-BOK style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Nettopp i nat ble jeg ferdig med «data-preparation-...») på den siste OSM-dumpen (jeg anntar og ser at visa-importen er delvis der). Og det er mange feil der (dog, jeg peker ikke på noen) spesielt den typen som Vidar peker på. For illustrasjon jeg legger til to bilder av feil, relaterte til insjøer i Norge (natural_water, water_lake). Bilde 2 er med lit større skala for sør Norge.<o:p></o:p></span></p><p class=MsoNormal><span lang=NO-BOK style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-De røde markørene viser posisjoner av åpne insjøgrenser som kunne ikke programatisk repareres (som regel, altfor stor brudd eller åpning mellon endepunktene). Disse, som regel, ignoreres i videre arbeide.<o:p></o:p></span></p><p class=MsoNormal><span lang=NO-BOK style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-De magenta markørene viser posisjoner til flere ganger repliserte insjøgrenser/polygoner som er ikke overlappende. Mer presist, en polygon ligger i en tynn korridor langs andre polygonen. I konsekvense, som regel, areal er rendered som union, øyer forvinner, problemer i generalisering... Også, dersom man bruker skan-linje (kontra enkelt areal-per-areal) basert fill algoritme resultat blir fulstendig feil. Det er mange årsak scenarier til dette men som oftest, impotøren ser ikke (eller kan ikke finne ut) at allerede det eksisterer en versjon av grense-polygonen der. Og når mann oppdager (nesten) repliserte, spørsmålet er hvilken versjon skal slettes.<o:p></o:p></span></p><p class=MsoNormal><span lang=NO-BOK style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-De grønne markørene viser posisjoner av eksakt repliserte insjø areal grenser/polygoner (en overlapper den/de andre). Konsekvenser er nesten det samme som i førrige tilfelle men årsakene vrrierer mere. På første blikk ser det ganske enkelt ut å oppdage disse feilene, men det er det ikke. Husk at det er mange tilfeller hvor en av grensepolygonene inhoolder noder ...A,B,B,B,C... eller ...A,B,C,D,C,D,C,D,E... mens den andre har ikke slike replikasjoner. Så, enkelt test av noderekker hjelper veldig lite. <o:p></o:p></span></p><p class=MsoNormal><span lang=NO-BOK style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Så, oppgaven å reparere konsekvensene av den nevnte masseimporten er langt fra «enkelt». Og, i hvert fall, kan ikke gjøres i noen titals timer.<o:p></o:p></span></p><p class=MsoNormal><span lang=NO-BOK style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Derfor, mit forslag er at hele importen reverseres og gjøres en grundig eksperimentering/testing før en endelig import bestemmelse.<o:p></o:p></span></p><p class=MsoNormal><span lang=NO-BOK style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Beklager omfanget, Sandor.<o:p></o:p></span></p><p class=MsoNormal><span lang=NO-BOK style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=NO-BOK style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=NO-BOK style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span lang=NO-BOK style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=NO-BOK style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> kart-bounces@nuug.no [mailto:kart-bounces@nuug.no] <b>On Behalf Of </b>Vidar Gundersen<br><b>Sent:</b> 17 March 2015 07:07<br><b>To:</b> Torstein Ingebrigtsen Bø<br><b>Cc:</b> kart@nuug.no<br><b>Subject:</b> Re: [NUUG kart] Forslag til dugnad: import av vann og arealdekke<o:p></o:p></span></p><p class=MsoNormal><span lang=NO-BOK><o:p> </o:p></span></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Vedlagt et lite uttrekk fra et område med slike duplikater. Linjer i dette datasettet (resultat av JOSM søket: highway=* user:visa-import version:1) som ligger på eller inntil andre ways med nesten samme tagging skal bort. En utfordring er endepunkter som er hektet i ikke-duplikater.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><a href="http://www.vidargundersen.com/uttrekk-visa-import-duplikater.osm.bz2">http://www.vidargundersen.com/uttrekk-visa-import-duplikater.osm.bz2</a><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><o:p> </o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>2015-03-16 22:54 GMT+01:00 Torstein Ingebrigtsen Bø <<a href="mailto:torsteinibo@gmail.com" target="_blank">torsteinibo@gmail.com</a>>:<o:p></o:p></p><div><p class=MsoNormal>Hei, jeg er er usikker. Tror ikke det. Men hvis du gir meg et eksempel så kan jeg se hva jeg får til.<o:p></o:p></p></div><div><p class=MsoNormal><br clear=all><o:p></o:p></p><div><div><p class=MsoNormal>Hilsen<br>Torstein<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>17. mars 2015 kl. 07.24 skrev Vidar Gundersen <<a href="mailto:vibrog+osm@gmail.com" target="_blank">vibrog+osm@gmail.com</a>>:<o:p></o:p></p><div><p class=MsoNormal>Kan verktøyet ditt brukes til å rydde opp i duplikater (og triplikater) i etterkant av import?<o:p></o:p></p><div><p class=MsoNormal>Dvs rydde opp i slurvete importer av Kartverkets data gjort av brukeren visa-import.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div></div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>