<html 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=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=EN-GB link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal><span lang=NO-BOK>Selv om jeg kommer sent, en liten advarsel.<o:p></o:p></span></p><p class=MsoNormal>Relasjoner mellom skog arealer (skog over skog, eksakt-/delvis-pålapp, felles grenser osv.) allerede rimelig godt diskutert i denne tråden. Dog, man kan se noen feiler som blir uungåelige.</p><p class=MsoNormal>Men, masse-opplasting, som denne, innebærer mange andre og enda mer alvorlige feller. Ulike areal typer (land, elver, innsjøer, skog osv.), som rgel, lastes opp i OSM uavhengig, uten kryss-sjekking for anomalier/feiler på grunn av inter-objekttype konflikter. Praktisk, det finnes ingen offentlig verktøy til slike inspeksjoner. I konsekvensen får vi mengder av feil/anomalier i kart som skog over vann, vann over skog, land over vann, grensene løper ut og inn i hverandre osv. Til illustrasjon se på utsnitt i denne lenken <a href="https://osm.org/go/0Tteceq">https://osm.org/go/0Tteceq</a> . I raster rendering brukes det ulike trikser for å minske disse feilene men i vector baserte GIS systemer og map-making slike feiler kan ikke tolereres. Blanding av ulike målestokker gjør ikke problemet lettere (til eksempel, en innskjø eller elv lastet opp fra 1:500 kan forsvinne i N50 på grunn av data-generalisering). Så, i masse-editering man bør være oppmerksom på disse fellene.</p><p class=MsoNormal>Til spesielt interesserte i denne problematikken. Topologi (Bourbaki) og Polygon Algebra kan skaffe nokk robust grunnlag for algoritmer som kunne hjelpe for å unngå di nevnte fellene. Jeg bruker slike algoritmer (programmer) i min data-preparation-tool-chain når jeg behandler OSM Planet data på veien fra kildedata til vektortiler. En illustrasjon av dette du kan finne her <a href="https://lists.openstreetmap.org/pipermail/talk/2017-April/077824.html">https://lists.openstreetmap.org/pipermail/talk/2017-April/077824.html</a>.</p><p class=MsoNormal>Mvh. Sandor</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Sent from <a href="https://go.microsoft.com/fwlink/?LinkId=550986">Mail</a> for Windows 10</p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='border:none;padding:0cm'><b>From: </b><a href="mailto:nkamapper@gmail.com">NKA mapper</a><br><b>Sent: </b>15 September 2018 09:24<br><b>To: </b><a href="mailto:wolfgang.leister@nr.no">Wolfgang Leister</a><br><b>Cc: </b><a href="mailto:kart@nuug.no">NUUGs kartliste</a><br><b>Subject: </b>Re: [NUUG kart] N50 import av skogsområder i Hedmark.</p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Ok, da oppfatter jeg at vi er enige om å slette gammel N50 import og gjøre importen på nytt.</p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Jeg synes ellers listen din er god, dette er fine tips for en import under normale omstendigheter. Er også enig i at N50 gir en litt grov topologi, men den kan være et greit utgangspunkt for videre forbedringer gjennom årene. </p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Jobben nå vil gjøres slik at det først slettes og så importeres på nytt (fordi forskjellige personer er involvert). Det betyr at det vil bli et midlertidig "hull" i noen dager. Praktisk koordinering tar vi på IRC/talk-no. Fint om alle unngår redigering i området til jobben er ferdig.</p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><div><p class=MsoNormal>Den fre. 14. sep. 2018 kl. 21:06 skrev Wolfgang Leister <<a href="mailto:wolfgang.leister@nr.no">wolfgang.leister@nr.no</a>>:</p></div></div></div></div><p class=MsoNormal style='margin-left:4.8pt'>Hei Jan T,<br><br>jeg tror du misforstår meg. Selv om jeg fremdeles mener at det å slette hele vil være litt for drastisk, så vil etter en ny-import 99% være på plass igjen. Johan etterlyste en analyse, og jeg ønsket å peke på at en ny-import burde ta vare på de tingene jeg nevnte (f.eks. det med navn; den gamle importen brydde seg ikke om dette). Som jeg skrev er N50 greit nok på det meste (med de unntakene jeg nevnte).<br>Skal prøve å holde meg unna redigering av data i de fire nevnte kommunene mens ny-importen pågår. <br><br>Wolfgang</p><p class=MsoNormal><o:p> </o:p></p></div></body></html>