Hej! Låt mig svara på några kommentarer som samlats i tråden under några dagar. Jag ämnar också skicka ett mejl till med mina framsteg/bakslag men databearbetningen. Och jag har fortfarande i planer att hantera den imports@osm listan.
>Jag gjorde nyss en test "import" (Changeset: 69657316) av ett litet område >sydöst om Gistad i Linköpings kommun Vänligen notera det i tabellen här: [1] om det inte redan var gjort. > Att mappa detta område utan NMD datat som grund hade tagit avsevärt längre > tid. Bra att du drar någon nytta av datat! > Jag håller med om att resultatet inte på något sätt är perfekt Som jag skriver vidare i detta mejl, det är lite synd att vi inte har ett enigt sätt att mäta hur dåligt > Slutsatsen är väl att importera hela kommuner känns som ett för stort område Ja, det börjar se ut så. Jag har aldrig uteslutit att vi inte skulle bli tvungna att skära datat i ännu mindre bitar, av en anledning eller annan. Låt mig fundera över detta. Jag hoppas också att vi kan lista ut vilka områden inte behöver någon import alls innan vi fortsätter med mindre bitar. > Jag tittade lite snabbt i västra Härjedalen, men tyckte inte att det var > speciellt bra runt fjällen. Om du misstänker att importdatat för vissa kommuner har några brister som orsakades av felaktiga indata (t ex dålig upplösning, koordinater skiftade, taggar matchar inte verkligheten osv), ber jag dig och alla andra om att kommentera det i motsvarande raden i tabellen på wikisidan: [1]. Då ska det hjälpa till att se vilka områden mest sannolikt skulle gynnas av ett importförsök, och vilka ska vänta till bättre data/algoritmer eller inte ska importeras alls. Vi vet redan att några kommuner är såpass väl täckta av markanvändnings data så att de inte behöver en större import. Och jag trodde från början att data för vissa områden inte skulle stämma vekligheten. Så att vi vill hellre fokusera sig på de resterande områden. > Ja, terrängkartan som vektor er allerede CC0 fra LM og dermed helt åpent. Man > kan laste ned alt her (må bare registrere brukernavn): https://www.lantmateriet.se/sv/Kartor-och-geografisk-information/geodataprodukter/terrangkartan/ Tack för länken, ska kolla dit. >Min erfarenhet är att Terrängkartan stämmer dåligt med verkligheten. En del av >jordbruksmarken är i verkligheten skog numera. Kanske är den kartan för gammal redan? Oavsett det, man skulle kontrollera datat område för område, oavsett om det handlar om Terrängkartan eller NMD-importen. > Kanske är det bättre att kombinera data vid renderingen? Att ha en enskilt lager för t ex skog vore en bra kompromiss. Tyvärr,understöder OSM-projektet inte flera lager. I mitt fall använder jag oftast Garmin-vektorkartor som skapas från OSM-data. Där kan man ha två lager samtidigt, men då måste man väl flytta alla skogsytor som nu finns i OSM till ett enskilt lager? > men jag är lite orolig för att vi får en massa "brötig" komplicerad geometri > som ingen vågar ta i för att fixa (multipolygoner är ju alltid lite > avskräckande). Man kan inte undvika multipolygoner när man beskriver naturen, tyvärr. Och de kan bli långa och komplicerande, det motsvarar dess egenskaper i verkligheten. Du är väl inte förvånad att Mälaren beskrivs med en lång multipolygon, och det är knappast möjligt att förenkla den utan att tappa bort viktiga detaljer. Det är ett särskilt stort problem för de stora obebodda fjällområden men stora ytor skog/buskage som transformeras till enorma multipoygoner. > Nu har jag inte kollat upp 685231007 men, vad är problemet? Det är bara att > fixa. > Det är en åkeryta som överlappar en väg, vilket ser lite mysko ut. > Se t.ex. hur sträcka 685233899 *nästan* passar in i den omgivande polygonen. Jo, samma typ problem i både fallen. Förutom att det glider åkermark lite över/under en väg, finns det fula "trianglar" med två mycket långa sidor och en kort sida i närheten: http://paul7.net/i/2019.04.28/0004bcb8/spectacle.y10384.png Dessa artefakter vill jag gärna röja bort; se nedan om deras ursprung. > Jämför med alternativet att det inte finns någon skog alls. På den internationella importmejllistan dök upp en argument "bad data vs no data at all". Min inställning är att sån diskussion är värdelös ifall man inte kan mäta hur dålig eller hur bra någonting är. Visst är en "bra" sak bättre än en "dålig" sak. Men om man väljer mellan två "dåliga" saker (som förekommer i den verkliga världen) behöver man siffror. Till min överraskning när jag kikar på t.ex. Osmose-sidan som skulle visa alla eventuella problem som Vingåkers import skapade: http://osmose.openstreetmap.fr/en/byuser/Atakua_imports ser jag precis noll problem! Jag vill hellre se en tusen problem där än noll. Jag kan rätta till en tusen problem och förbättra mina verktyg/process för att undvika dem i framtiden, men hur kan jag rätta till noll problem? > Vi kanske har olika inställning till det hela. Jag tänker inte att efter > import så är allt klart och ska inte röras. Det vore bäst om vi kan minska krävande på uppföljningsarbete så mycket som möjligt. Det handlar alltid om signal/brus förhållande. Om jag kan låta bli ett fel kvar per 100 tusen nya objekt i importdata ska jag gärna göra det. Men vad om 2 fel? 3 fel? Man behöver alltid sätta gränsen, avsiktligt högre än noll. Men då behöver man kunde *mäta* felfrekvensen före och efter, och denna möjlighet har man inte för just den typ importen som Vingåkers kommun utsattes för. > Själv har jag spenderat massor med tid med att mappa in skog och åker i norra > och västra delarna av Linköping kommun. Samma sak för mig för Katrineholm, Gnesta, Norrtälje m fl samt områden i andra länder som jag är intresserad av. > Jag har inte räknat hur många timmar jag lagt på det men det är många och det > är ett projekt som pågått över flera års tid. Det tar helt enkelt för mycket > tid. Att få NMD datat som grund kommer spara så mycket tid. Att du, jag och andra behöver offra så mycket sin tid för att manuellt rita skog/åker beror inte minst på att OSM-projektet saknar bra verktyg för att bearbeta ytor. Jag vill återkomma till detta poäng senare. Jag tror fortfarande att NMD-datat är användbart för det ändamål vi vill ha det, men det är nu klart för mig att någon (kanske jag?) behöver skapa bättre insticksmodul för JOSM som t ex skulle underlätta bearbeta gränser mellan nya och gamla ytor, detektera mindre överlappningar mellan vägar och ytor osv. De är inte så stora algoritmiska utmaningar egentligen för att programmera dessa funktioner in i en mjukvarumodul. Och det skulle hjälpa enormt med de vanliga uppgifter man har när man ritar nya skogar eller importerar befintliga ytor som är bara "lite snedda". > Jag tror inte skriptarna kan göras så mycket bättre med tanke på hur låg > kvalitet det är på grundmaterialet (10x10 cm) och en kass? AI på det. Upplösningen är enligt dokumentationen 10×10 meter. Ärligt talat vill jag inte ha en bättre upplösning. Om det vore 1×1 meter blev alla datafiler 100 gånger större, då kunde man knappast bearbeta dem på en personlig dator. Resulterande vektors storlek skulle öka något proportionellt som inte vore bra heller. För en rak bilväg att ha bättre upplösning betyder att ta reda på vägens bättre start- och slutpunkter som två koordinater. För skogar lägger det bara mer data, mer detaljer som någon inte vill ha. Jag som brukar titta på skogskartan när jag står i skogen tycker att en upplösning (vare sig vektor eller raster) 100×100 meter är för låg, 1×1 meter är för fin, däremot brukar 10×10 meter vara nära gyllene medelvärdet. > Jag ogillar att det är skog med en massa vita hål i. Det bliver nog en > ful och kantig karta om detta importeras i större skala. Jag tror att det beror på två faktorer. 1. Borttagning av mindre polygoner för att minska datats storlek. 2. För aggressivt tillämpning av Douglas-Peucker utjämningen som jag använde efter Chaiken-filtret. Låt mig förklara var som hände med rasterdatat tlls det blivit till den karta du ser nu, och vad som kunde ha/ska göras bättre. Efter att man konverterat rastern till vektorn ser samtliga linjer ut som trappor med 90 graders vinklar. För att släta dem ut använder man Chaiken-filter. Filtret gör ett otroligt bra jobb förutom två negativa aspekter: 1. Lagrets storlek ökar (antalet noder ökar) 2. Vissa linjer som skulle vara raka (t ex skogs gräns nära en motorväg) förblir kantiga. Vinklarna är dock inte 90 grader utan ungefär 120 grader. Samtidigt förvandlas dock andra linjer till raka som de skulle. Det är ännu mer irriterande att dessa sågliknande linjer dyker upp vid de platser där man mest sannolikt ska se på kartan (nära vägar). Ingen skulle ju bry sig om en någon konstig kurva djupt i skogen. För att både förminska datats storlek och släta ut dessa såglinjer använder man Douglas-Peucker. Det gör sitt jobb också bra förutom att: 1. Det skapar hål mellan intilliggande ytor 2. Det tar ibland bort för flera noder. Mitt främsta villfarelse som jag uppfattar det nu var att förutsätta att samma filterparameter kan tillämpas till landets hela yta. Därför experimenterade jag med ett slumpvis utvalt kommuns lager, hittade "bästa" filterparameter och sedan lämpade dem till alla andra kommuner. Istället borde man hitta en bäst filterkombination på nytt för varsin kommun/område. Ibland vore det bättra att man inte använder Douglas-Peucker alls, och ibland att det endast tillämpas till större ytor. > Jag skulle hellre importera LMs vektorkartdata (om den nånsin släpps fri) som > ligger till grund för hitta.se Visst vore det att ha en datakälla i vektorformat så mycket bättre. Det skulle ha löst så mycket problem med rasterartefakter mot vilka jag kämpar nu. >Om så händer kan vi ju kanske massradera det här skräpet först. Jag vill vara en av de första som skulle göra det om vi får tillgång till bättre vektordata! På något sätt anser jag att NMD-datat ska ersätta nuvarande fläckar av CORINE2006 data som nu finns här och där. NMD-datat har bättre upplösning och är mer tidsenliga. Samtidigt plågas det av samma problem såsom conflation och (som vissa anser det) taggning. Trevlig fortsatt söndag! 1. https://wiki.openstreetmap.org/w/index.php?title=Import/Catalogue/NMD_2018_Import_Plan/Status_per_subarea >Воскресенье, 28 апреля 2019, 12:00 +03:00 от Karl-Johan Karlsson ><karl.johan.karls...@gmail.com>: > >Jag gjorde nyss en test "import" (Changeset: 69657316) av ett litet område >sydöst om Gistad i Linköpings kommun för att visa på hur användbart det data >som finns nu ändå är. För det första så vet jag inte om man i strikt mening >kan kalla det en import utan mer att jag har använt NMD datat som underlag >(tillsammans med Linköping Orthophoto) för manuell mapping. Att mappa detta >område utan NMD datat som grund hade tagit avsevärt längre tid. Jag håller med >om att resultatet inte på något sätt är perfekt, hade jag gjort det helt >manuellt så hade vissa delar blivit lite bättre mappade än de nu blev. >Slutsatsen är väl att importera hela kommuner känns som ett för stort område >med nuvarande kvalité på det ursprungliga NMD datat. > >MvH >Karl-Johan Karlsson > > >Den tors 25 apr. 2019 kl 16:11 skrev Grigory Rechistov via Talk-se < >talk-se@openstreetmap.org >: >>Hej alla, >>Hinner nu inte besvara alla riktigt fina anmärkningar/feedback som samlades i >>denna tråd, hoppas att göra det sent ikväll. >> >>Så här är nuvarande framsteg som jag känner det. >>1. Ett litet fiasko med Stockholms kommun >>2. Ett experiment med Vingåkers kommun som väckte en stor diskussion på >>imports@osm, >>jag hinner faktiskt inte läsa den igenom, vill hellre lösa befintliga problem >>med andra >>kommuners data så bra som möjligt. >>3. Flera mindre men viktiga förbättringar i skripten är redo, såsom >>borttagning av >>irriterande "trapporna" i sträckor som filtren inte kunde lösa, besparing >>av mindre polygoner under filtreringen om de är viktiga för topologi osv. >>4. Bättre förståelse på vad som behövs att förbättra i importdatat för att >>underlätta manuellt finkammande och lösa några klagomål. >>Nuförtiden känner jag till om två problem som väntar på lösningen innan man >>effektivt kan fortsätta utan att behöva göra alltför mycket handarbete över >>enstaka importdatalager. >> >>1. Rensning på självkorsande sträckor i datat. >>2. Se till att nya polygoner har gemensamma gränser med befintliga polygoner. >>Låt mig illustrera den första uppgiften med några siffror. Det förekommer >>självkorsningar och korsningar mellan t ex skogsområden. Hur många >>självkorsningar >>finns det i ett datalager beror bland annat på hur hårt filtreringen utförts >>och hur stort området är. >>Alla självkorsningar är oundvikliga artefakter och det går visst att fixa dem >>manuellt. Men det tar tid. >>Nuvarande felfrekvens är ungefär 0,0002 fel per objekt. För Vingåkers kommun >>som är lagom stor fanns det runt 100-150 varningar som jag manuellt löste >>före >>uppladdningen. För Bergs kommun som är cirka 10 gånger större finns det drygt >>1000 varningar och fel: >>https://atakua.org/p/nmd/intersections/0085-Bergs-konflikter.png >>Mitt syfte är att minska siffran till 0,00002 fel per objekt. >>Det skulle betyda att en att manuellt lösa alla kvarstående varningar på en >>lagom >>stor kommun skulle ta 10 minuter istället för en timme. För större kommuner >>skulle det förminska manuellt arbete från 10 timmar till en timme. >>Min iakttagelse är att de flesta självkorsningar består av en kort ögla: >>https://atakua.org/p/nmd/intersections/sj%c3%a4lvkorsande-str%c3%a4cka-1.png >>Det finns andra fall som är lite större men i princip är samma sak: >>https://atakua.org/p/nmd/intersections/sj%c3%a4lvkorsande-str%c3%a4cka-2.png >>Det finns dock svårare fall som jag inte ämnar lösa automatiskt, liksom en >>midja i mitten på en lång sträcka: >>https://atakua.org/p/nmd/intersections/sj%c3%a4lvkorsande-str%c3%a4cka-3.png >>Slutligen finns det fall som ser absolut hopplösa ut, men en människa kan >>lösa >>dem genom att helt enkelt ta bort allt krafs: >>https://atakua.org/p/nmd/intersections/sj%c3%a4lvkorsande-str%c3%a4cka-fucked-up.png >>Jag kom på en algorithm som kunde lösa "öglor" genom att lokalt skanna >>sträckor. >>Den skulle ta bort mindre irriterande självkorsningar som är de vanligaste, >>och >>dessutom ska den bli förhållandevis snabb. Nu behöver jag lite tid för att >>förverkliga den i mitt skript `nmd-gml-to-osm.py` som för övrigt >>redan filtrerar "trappor". >>Angående den andra uppgiften om gemensamma gränser, behövs det för att t ex >>ny skog inte hamnar delvis i befintliga sjöar. Det kan göras genom att knäppa >>noder till de noder som redan sitter på en intilliggande sträcka. Tyvärr har >>JOSM inte något bra verktyg för att göra det på ett smidigt sätt >>(Contour Merge passar inte i detta fall). Skog som har glidit in i vattnet >>rapporteras inte heller som en varning av JOSM, det ser fult ut och det >>irriterar mycket folk (inklusive mig själv). >>Det betyder att jag behöver förbättra `conflate.py` att knäppa noder till >>befintliga gränser. Det kommer säkert inte lösa alla tillfällen där problemet >>uppstår, men åtminstone blir dess antal mindre så att man kan rätta dem till. >> >> >> >>>Четверг, 25 апреля 2019, 13:05 +03:00 от Christian Asker < >>>christian.as...@gmail.com >: >>> >>>Min erfarenhet är att Terrängkartan stämmer dåligt med verkligheten. En del >>>av jordbruksmarken är i verkligheten skog numera. >>> >>>Dessutom är geometrierna i Terrängkartan anpassade för rendering och därmed >>>ligger objekt ganska fel ibland. >>>Vidare brukar skog och åkermark vara ganska stora multipolygoner som är >>>jobbiga att hantera. >>> >>>Mvh Christian >>> >>> >>> >>> >>> >>>NKA mapper < nkamap...@gmail.com > skrev: (25 april 2019 10:50:51 CEST) >>>>Ja, terrängkartan som vektor er allerede CC0 fra LM og dermed helt åpent. >>>>Man kan laste ned alt her (må bare registrere brukernavn): >>>>https://www.lantmateriet.se/sv/Kartor-och-geografisk-information/geodataprodukter/terrangkartan/ >>>> >>>>Filene er i shape-format som kan åpnes direkte i JOSM med OpenData plugin, >>>>og kommer inn som ferdige (multi)polygoner uten overlapp. Det ville være >>>>enkelt å konvertere automatisk til ferdig OSM-tagging. Dette er slik vi >>>>gjør import av markdata og vann i Norge. >>>> >>>>/NKA >>>>tor. 25. apr. 2019 kl. 10:59 skrev Ture Pålsson < t...@turepalsson.se >: >>>>>Egil skrev: >>>>> >>>>>> Jag skulle hellre importera LMs vektorkartdata (om den nånsin släpps >>>>>> fri) som ligger till grund för hitta.se - den verkar mycket bättre och >>>>>> snyggare. Om så händer kan vi ju kanske massradera det här skräpet >>>>>> först. >>>>> >>>>>Den *är* väl fri? Ska vara CC0 enligt websidan. Den var CC-nånting-annat >>>>>förr, men de ändrade det för ett tag sedan. >>>>> >>>>> >>>>>_______________________________________________ >>>>>Talk-se mailing list >>>>>Talk-se@openstreetmap.org >>>>>https://lists.openstreetmap.org/listinfo/talk-se >>> >>>-- >>>Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet. >>>_______________________________________________ >>>Talk-se mailing list >>>Talk-se@openstreetmap.org >>>https://lists.openstreetmap.org/listinfo/talk-se >> >> >>С наилучшими пожеланиями, >>Григорий Речистов. >>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 С наилучшими пожеланиями, Григорий Речистов. 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
