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@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@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-se
_______________________________________________ Talk-se mailing list Talk-se@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-se
