<HTML><BODY>Hej!<br><br>> Här finns en annan intressant importstrategi med tasking manager-filer som output.<br>Tack, det ska jag läsa igenom och försöka tillämpa om det är möjligt till var import.<br>Tydligen är vi inte första som sysslar med en import av stängda sträckor<br>(såsom byggnaders avtryck). Men det är svårt att hitta någon med tidigare<br>erfarenhet i detta som vill hjälpa till, och alla inte är vänliga med goda<br>konstruktiva råd på huvudimportlistan.<br><br>Jag skrev i mitt inlägg [0] hur jag fortsatte med databearbetningen. Den nya<br>importenheten blivit en tile (ruta) som är ungefär 0,1 × 0,1 grader stor. En<br>typisk kommun täcks av tiotals sådana rutor. Den nya approachen använder en<br>rastermask skapad från befintliga OSM-vektordatan. Det är betydligt enklare och<br>mer robust att maskera importdatat i rasterformen än att försöka slå ihop onödiga<br>färdiga vektorer som förut. Nu splittrar jag kommuner i rutor som är mindre och<br>smidigare att jobba med.<br><br>Observera att samtliga rutor skapar en större rektangulära begränsningsbox som<br>täcker en kommun, inte just ytan inom kommunens gräns. Det finns därför möjlighet att<br>samma kvadrat hamnar i två olika uppsättningar på intilliggande kommuner.<br><br>Jag fortsätter med Katrineholms kommun. Den kommunen har några passande egenskaper<br>för att testa min nya approach: 1) dess yta är redan ⅔ kartlagd med markanvändning<br>men den har stora "vita" områden kvar; 2) den har flera sjöar och några mindre<br>bostadsområden; 3) den är lagom stor. Jag fick 45 rutor (9×5) av den, och jag<br>förväntar mig att ungefär 10-20 rutor ska kräva uppladdningen i slutet med något<br>nytt data i dem.<br><br>Vänligen inspektera de OSM-filer ([1], [2]) som jag vidare beskriver. Samtliga<br>OSM-filer för rutor inom Katrineholms kommun finns här: [7], så att ni kan<br>redigera och ladda dem upp om ni vill.<br><br>Härnäst kommer beskrivningar på de två rutor som jag nu sysslar med. Jag röjde<br>bort alla varningar som JOSM rapporterade för dem och nu håller jag på att<br>även städa de tillfällen som någon må känna igen som varningar.<br><br>1. En ruta nära Värhulta ö: OSM fil [1], tile 0233-002_005.<br>Den här området har bara 1750 objekt efter importen (det täcks i huvudsak av en<br>stor sjö). Det gick enkelt att manuellt rätta till samtliga JOSM-varningar (runt<br>10 stycken) och olika överlappningar som såg fullt ut.<br>Om det finns inga invändningar vill jag ladda upp datat för den här rutan inom<br>ett par dagar.<br><br>2. En ruta runt Långtvaren: OSM fil [2], tile 0233-001_001.<br>Det här området har ungefär 87.000 objekt varav drygt 2600 sträckor. Det är<br>i princip heltäckt av skog och flera mindre sjöar.<br>Det rapporterades ursprungligt 41 varningar som krävde manuell lösning.<br><br>Jag eftersträvade inte lösa alla varningar som rapporterades för området utan<br>bara de som orsakades av nya importdata. Efter mina ändringar har rutan<br>fortfarande ett par överlappande vattenytor som varit där förut: Stora Onsjön och<br>en våtmark i närheten.<br><br>Mina tankar och observationer på dessa två rutor. De byggs på mina tidigare<br>notiser i [0].<br>1. Importdatats upplösningen stämmer *avsevärt* bättre med flygplansbilder än<br> vissa befintliga polygoner. Jämför Hjälmarens kustlinje i [1] med en skogslinje<br> taggad med "source=NV NMD2018". Den gamla kustlinjen är grov medan de nya<br> skogarna skapar en fin linje.<br> Ett annat exempel var D717 [5] som dåligt stämde med både flygplansbilderna och<br> importdatat. Jag behövde justera dess några noder så att vägen skulle passera<br> genom skogspartier utan någon överlappning.<br> Man behöver därför växla mellan redigeringen på importdatat och justeringen<br> på de befintliga sträckorna. Jag tror att linjära objekt som kustlinjer, bilvägar<br> och dylika inte tillhör importen och därför bör redigeras i sina egna<br> ändringsuppsättningar. Men det är bara min önskan till mig själv.<br><br>2. Importdatat bidrar med nya pyttesmå holmar (som fläckar skogsområde) i sjöar.<br> Som sagt förut borde sådana öar markeras som inre sträckor hos motsvarande<br> sjömultipolygoner. Det ämnar jag göra med ett enskilt redigeringssteg som<br> förekommer efter importdatat för ett ruta har laddats upp, inte samtidigt med<br> första uppladdningen. Att markera holmar som multipolygoners delar är ingen<br> brådska och inget stort fel att behålla dem "simmande" i en sjö för närvarande.<br><br>3. Tomter på landet med byggnader som inte redan är kartlagda på OSM får<br> brokiga små markanvändningspolygoner. Till exempel fylls en typisk bondgård<br> (några bodar, ett hus) av flera små "landuse=grass" eller "landuse=farmland"<br> polygoner som försöker fylla in alla tomma utrymmen mellan byggnader.<br> Huvudsakligen tenderar det att omringa vart och ett träd i ett bostadsområde<br> med "landuse=forest". Det är ingen nytta i detta. Jag föreslår att rensa manuellt<br> sådana tillfällen. Om man vill kan man rita hus som nästa steg oberoende<br> på importen.<br> Observera att importdatat inte brukar krypa på redan kartlagda byggnader eftersom<br> sådana områden var "förbjudna" under vektoriseringstiden.<br><br>4. Jordbruksmarks och skogs sågliknande kanter längs motorvägar. Det är därför<br> att jag inte längre tillämpar några ytterligare filter efter Chaiken. Tanken<br> är att selektivt förenkla få sträckor är snabbare än att kämpa mot<br> självkorsningar som dyker upp överallt.<br><br>5. Dubbla gränser mellan sjöar och skogar. Man ser dem tydligast på [2] där det<br> finns flera sjöar omgivna av skogar. I JOSM sammanfogar man sådana närliggande<br> sträckor med "ContourMerge"-insticksmodulen [6].<br> Jag utvecklar nu ett verktyg "Snap New Nodes" [4] som ska knäppa noder av<br> utvalda sträckor till närliggande sträckor. Jag vill fixa några brister i<br> insticksmodulen och sedan vill jag distribuera den till de som vill använda den.<br> Just nu kan den knäppa noder till polygoner, men den ignorerar multipolygoners<br> gränser och har inte någon progressbar (endast loggmeddelanden). Det kraschar<br> dock inte för mig, som är åtminstone schysst, och jag tycker om JOSM's källkods<br> kvalité.<br><br>Jag ska utforska den approachen som egil tidigare skrev om, men för tillfället<br>för att se till att två personer samtidigt inte redigerar samma kvadrat i<br>Katrineholms kommun, använd gärna den följande kalkylarket: [3].<br><br>Tekniska detaljer om operationssekvensen som används. Nuförtiden använder jag<br>endast ett Chaiken-filtret och mitt egna lilla "trappborttagningsfilter". Det<br>gör att den resulterande vektorn stämmer bäst med flygplansbilder<br>(Bing, DigitalGlobe osv.) och har inga konstiga "genvägar" som orsakar flertal<br>självkorsningar och några överlappningar som nu går att undvika.<br>Antal självkorsningar brukar vara minimalt. Nackdelen är att datafils storlek<br>blir nästan två gånger större samt att man behöver utjämna manuellt vissa artefakter.<br><br><br> sverige.tif sverige-mask.tif<br> + |<br> | |<br> v v<br>make-kommun-tiles.py make-kommun-tiles.py<br> | +<br> | |<br> v v<br> tiles.tif tile|mask.tif<br> + |<br> +----------+ +----+<br> v v<br> gdal-polygonize.py<br><br> v.in.org<br><br> v.generalize filter=chaiken threshold =20<br><br> v.out.ogr<br><br> nmd-gml-to-osm.py<br><br> filter-osm threshold = 12<br> +<br> |<br> v<br> load into JOSM<br> +<br> |<br> v<br> fix warnings<br> +<br> v existing OSM data layer<br> merge layers <-------------+<br> +<br> |<br> |<br> v<br> fix warnings after merge<br> +<br> |<br> |<br> v<br> upload<br><br><br>Källor<br><br>0. https://lists.openstreetmap.org/pipermail/imports/2019-April/005990.html<br>1. https://atakua.org/p/nmd/0233/0233-002_005-work-in-progress.osm.bz2<br>2. https://atakua.org/p/nmd/0233/0233-Katrineholms_001_001-work-in-progress.osm.bz2<br>3. https://docs.google.com/spreadsheets/d/1Qa9n9WiVt_bn5BWMnkUtSviaomAfg5JwGNfCTao6fUY/edit?usp=sharing<br>4. https://github.com/grigory-rechistov/snapnewnodes<br>5. https://www.openstreetmap.org/changeset/69881752<br>6. https://wiki.openstreetmap.org/wiki/JOSM/Plugins/ContourMerge<br>7. https://drive.google.com/open?id=1noQoPTIt3xYafUdXUBCYJd-vU1xoDmzP<br><br><br><br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;">
Пятница, 3 мая 2019, 23:58 +03:00 от egil <egil@riseup.net>:<br>
<br>
<div id="">
<div class="js-helper js-readmsg-msg">
<style type="text/css"></style>
<div>
<div id="style_15569170950744257604_BODY"><div class="class_1557027946">
<p>Hej på er</p>
<p>Här finns en annan intressant importstrategi med tasking
manager-filer som output.
<a rel="noopener noreferrer" href="https://www.openstreetmap.org/user/itsamap!/diary/152909" class="moz-txt-link-freetext_mailru_css_attribute_postfix" target="_blank">https://www.openstreetmap.org/user/itsamap!/diary/152909</a><br>
</p>
Kanske är detta bästa vägen även för denna import?<br>
(det möjliggör att ha denna data som underlag under lång tid
framöver för folk som vill kartlägga landuse genom att utgå från NMD
som grund om dem tycker det är lättare.)<br>
<br>
Se "merge workflow" som beskrivs här:
<a rel="noopener noreferrer" href="https://wiki.openstreetmap.org/wiki/Import/Catalogue/US/BingBuildings#Data_Merge_Workflow" class="moz-txt-link-freetext_mailru_css_attribute_postfix" target="_blank">https://wiki.openstreetmap.org/wiki/Import/Catalogue/US/BingBuildings#Data_Merge_Workflow</a><br>
<br>
Mvh<br><br class="moz-cite-prefix_mailru_css_attribute_postfix"></div></div></div></div></div></blockquote><br>Med vänliga hälsningar,<br>Grigory Rechistov<br>With best regards,<br>Grigory Rechistov<br></BODY></HTML>