[Talk-se] Naturvårdsverkets nya Nationella MarktäckeData

Sun Apr 28 23:57:23 UTC 2019

Hallå,
Följer tråden med stort intresse.
Kanske ett senare problem men vore det inte möjligt att använda HOTOSM:s tasking manager för att systematisera importen av innehållet av rutorna på 5*5km? Vet dock inte hur aktiv http://tasks2.openstreetmap.se/ är längre. Annars finns ju alltid https://github.com/hotosm/tasking-manager
/Johan

> 28 apr. 2019 kl. 22:56 skrev Grigory Rechistov via Talk-se <talk-se at openstreetmap.org>:
> 
> 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-se/attachments/20190428/f0949978/attachment-0001.html>