<HTML><BODY>Hej igen!<br><br>I detta mejl tänker jag beskriva mina försök att lösa tidigare upptäckta problem<br>med sträckors självkorsningar och "knäppning" av nya sträckor till befintliga<br>gränser.<br><br>I ett föregående mejl gav Karl-Johan mig en ny idé som jag också vill utveckla vidare.<br><br>Tidigare skrev jag att vektordatat brukade innehålla flertal självkorsningar på<br>sträckorna. Jag förbättrade mina skript för att hitta och radera små "öglor"<br>som var de vanligaste. Sedan blev läget med korta öglor bättre, men då började<br>närliggande ytor krypa på varandra, typiskt med bara en nod som blev juuuust<br>0,0000001 grader till höger eller vänster till där den borde stanna.<br><br>Inga av sådana problem fanns i GRASS GIS-lagrena som jag använde inför exporteringen<br>till OSM-filer. Alla datarensningar som jag utförde i GRASS GIS rapporterade inga<br>problem.<br><br>Det förvirrade mig omåttligt tills jag märkte att GRASS GIS använde<br>koordinater med 11 siffror efter kommatecken och sparade dem som GML-filer,<br>varpå reducerade JOSM dem till 7 siffror [1]. Den reducerade precisionen<br>ledde till att noder kunde flytta just lite gran men det kunde<br>skapa nya överlappningar och självkorsningar.<br><br>Det betyder att alla fina databearbetningar som GRASS GIS och andra externa<br>verktyg kan göra kan inte hjälpa om det sista steget tappar siffror. Och att<br>de sista turen på datarensningen skulle utföras i JOSM, annars blir allt värdelöst.<br><br>Det andra problemet som pekas ut av flera personer är att nya ytor ofta brukar<br>överlappa med t ex bilvägar eller andra ytor såsom sjöar. Överlappandet är alltid<br>minimalt men ser irriterande ut och får aldrig något godkännande i OSM-smhället.<br>För att hjälpa med lösningen har olika GIS-system passande verktyg, för att<br>knäppa noder till gemensamma gränser, eller att bryta polygoner<br>om de korsar varandra och så vidare. JOSM saknar tyvärr liknande verktyg och<br>dessutom kan inte knäppa noder i hela datalagret, endast enstaka objekt som<br>väldes manuellt.<br><br>Man kan väl utföra datarensningen utanför JOSM?<br>Men då behöver man ladda både baslagret och NMD-datalagret i t ex GRASS GIS så<br>att den kunde känna till både gamla och nya objekt. Detta skulle kräva flertal<br>dataformats konverteringar: från OSM till GRASS databas och tillbaka.<br>De förstår inte varandras filformat.<br><br>Därför bestämde jag mig inte försöka göra några nodersknäppning eller polygonbrytning<br>i mina Python-skript — de är redan för långsamma och gynnar inte återanvändning.<br>Det kräver ett korrekt verktyg i korrekt plats, nämligen ett slags insticksmodul<br>för areors conflation in JOSM.<br><br>För att göra hela uppdraget mer hanterbart vill jag nu dela landets yta i ännu<br>mindre delytor. Samtidigt vill jag vara mer försiktigt med datats automatiska<br>utjämning. Om det ska bli möjligt vill jag även försöka att skapa bättra verktyg<br>för JOSM, istället för de nuvarande kassa Python-skripten som gör för grovt jobb<br>utan människas kontroll.<br><br>Så här är översikten.<br><br>1. Skära landets/kommunernas yta i mindre jämna kvadrater 5x5 km.<br> Borde kvadraters sida vara 1 km? 25 km? dina förslag?<br>2. För varje kvadrat konvertera NMD-rastern till vektor.<br> Släta den sedan med Chaikens filter. Använd inte eller använd sparsamt/varsamt<br> andra typer filter.<br>3. Konvertera vektorn till ett OSM-lager med samma taggningschema som förut.<br>4. För varje kvadrat hämta ett OSM-baslager från Geofabrik.<br>5. Använd inte några Python-skript för att markera några konflikter osv. Gör<br> datasammanblandningen manuellt i JOSM.<br>6. Använd bland annat sunt förnuft och olika JOSM-verktyg för att lösa alla konflikter.<br> * Valideringsknappen för att upptäcka överlappande gamla/nya ytor och övriga problem.<br> * "Contour Merge" samt "Flytta nod till sträcka" och "Slå ihop noder" — för<br> att se till att intilliggande ytor (t ex skog och sjö) inte överlappas.<br> * Radera-knappen - för att radera alla tvivelaktiga noder/sträckor.<br> * "Simplify Way", "Simplify Area" — för att minska antal noder, att släta<br> sträckor<br>7. Ladda upp ändringar till databasen och markera kvadraten som klar.<br><br>Några fördelar som jag ser med denna approach.<br><br>1. Större kontroll under vad som kommer att laddas upp. En människa kan visuellt<br> och manuellt kontrollera en lagom stor kvadrat under en rimligt tidsram.<br> Däremot med hela kommuner som kan vara väldigt stora är det påfrestande.<br> Det kan till och med ske att vissa uppladdningar inte ska<br> klassificeras som "import" alls: om en person sett på var och ett objekt i changeseten.<br><br>2. Mindre irriterande hål och artefakter efter utjämningen. Som jag upplever det<br> ger Chaiken-filtret avsevärt mindre självkorsningar, korsningar och dylikt.<br> Sedan kan man tillämpa andra filter manuellt i enstaka fall till enstaka sträckor<br> vid behov.<br><br>3. JOSM blir mindre belastad med datat. Att öppna ett område lika stort som<br> Kirunas kommun orkar inte varje dator, men de flesta kan hantera 5×5 km.<br><br>4. Problemet med jättemultipolygoner blir mindre sannolikt. Alla sträckor<br> blir sedan begränsade av en kvadrat 25 km².<br> Om hela kvadratens yta är t ex skog reduceras den till fåtal multipolygoner<br> som har deras yttre gränser vid kvadratens kant. Jo, det kan råka illa ändå.<br> I det absolut värsta hypotetiska fallet kan det vika upp till en sträcka med<br> 250 000 noder (antalet pixlar i sådan kvadrat). Men då drabbas bara en kvadrat<br> av det och olika åtgärder kan göras.<br><br>5. Mindre antal konflikter per area som gör det enklare att lösa dem under<br> rimlig tid. JOSM skulle kunna lösa dem relativt snabbt, jämfört med det fall<br> när man öppnar ett större lager.<br><br>Nackdelar och otydliga aspekter som jag ser nu.<br><br>1. Det är svårare att ha koll vem gör vad. För att undvika dubbelarbete behöver man<br> markera tydligt vilka kvadrater redan är klara, så att andra inte försöker<br> bearbeta dem på nytt.<br><br>2. Med kvadrater som är 5×5 km blir det cirka 18000 stycken för att täcka hela Sverige.<br> Men det är svårt att säga om det skapar mer arbete än det skulle behövas om<br> man försöker ta en kommun i taget: större områden leder till fler konflikter<br> och längre bearbetningstider.<br><br>3. Man kan automatiskt uppskatta hur bra en kvadrat i baslagret är kartlagd med<br> "landuse" taggar, och sedan undvika att titta på de kvadrater som redan har<br> gott om skogar, åkermark eller täcks av bostadsområden. Tanken här är samma<br> som med kommuner, men granulariteten ökar.<br><br>4. Nya effekter uppstår vid intilliggande kvadraters kanter. 291 kommuner har<br> ju enklare gränser än 18 tusen kvadrater. Men jämför det med hur vissa människor<br> karterar större skogsområden: de delar dem ut i ungefär rektangulära delar.<br> När man blir trött och slutar med ritningen, blir dessa konstgjorda<br> skogsgränser kvar i kartan tills någon vill fortsätta. Så, ingenting nytt här.<br><br>5. Man behöver fortfarande lösa konflikter t ex mellan befintliga och nya skogar<br> samt mellan intilliggande befintliga sjöar/vägar och nya skogar och åkermark som<br> brukar "krypa" lite över varandra och överlappas. Oavsett hur stort område sysslar<br> man med, för att hjälpa med sådana problem på riktigt, behöver man ha tillgång<br> till verktyg för att sammanblanda areor. Liksom, `v.clean` i GRASS GIS som<br> har `break`, `rmarea`, `rmsa` osv.<br><br>Referenser:<br><br>1. https://gis.stackexchange.com/questions/320919/can-exporting-geodata-to-osm-data-format-with-less-precision-cause-self-intersec<br><br><br>Med vänliga hälsningar,<br>Grigory Rechistov<br>With best regards,<br>Grigory Rechistov<br></BODY></HTML>