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