Det är bättre att säga att all kartdata ska hålla hög standard.
Många av de manuellt mappade områden av speciellt skogar håller inte någon
hög kvalitet alls. Ofta är det mycket stora områden som bara är markerade
skog rakt över. Det har inte gjorts "hål" i skogen för åkrar, gläntor,
byggnader och
On Fri, 2019-11-08 at 17:46 +0100, pangoSE wrote:
> Hej
>
> Håller helt med Essin. Se min kommentar här
> https://www.openstreetmap.org/changeset/70936570
>
> Jag förslår att vi sätter stop för import tills att vi sett att nån
> tagit åt sig den enorma uppgift att städa upp det som redan
>
Hej
Håller helt med Essin. Se min kommentar här
https://www.openstreetmap.org/changeset/70936570
Jag förslår att vi sätter stop för import tills att vi sett att nån
tagit åt sig den enorma uppgift att städa upp det som redan importerats.
Tills dess får vi leva med en "vit" karta i några
Hej!
Åre kommun blev inte heller så bra, åtminstone inte den del jag känner till
i detalj, se min changesetkommentar [1]. Jag tror att en del av problemet
är att NMD är just marktäckedata (landcover), medan OSM i första hand
innehåller markanvändning (landuse). Distinktionen mellan markanvändning
Hej!
Jag läste mailet nedan från Grigory. Angående gräsmarker: Vet ni att det
finns tilläggskikt till NMD med markanvändning? Se här:
https://gpt.vic-metria.nu/data/land/NMD/NMD_Produktbeskrivning_tillaggsskikt_Markanvandning_v1_2.pdf
Där finns golfbanor, koloniområden, kyrkogårdar osv som kan
Hallå,
Finns det någon uppdatering att ge kring importen?
Hojta om det finns behov av hjälp. Kan tänka mig att samköra någon av de
större kommunerna kring Åre.
/Johan
On Thu, 13 Jun 2019 at 12:54, Grigory Rechistov via Talk-se <
talk-se@openstreetmap.org> wrote:
> Hej på er alla!
>
> Förlåt
Hej på er alla!
Förlåt mig för längre tystnad på den här listan, var upptagen med livet/jobbet
och orkade bidra till OSM endast sent på kvällarna då var det inte bästa
tillfällen
att kolla/svara mejl.
Låt mig svara på alla förfrågor/kommentarer som nyligen samlades i tråden.
> Jag såg att
Tack! Det var där skon klämde.
/Johan
On Wed, 12 Jun 2019 at 11:01, Snusmumriken
wrote:
> On Wed, 2019-06-12 at 10:50 +0200, Johan Emilsson wrote:
> > Hallå,
> >
> > Kollar på importerat material för Åre.Noterade att relationen
> > https://www.openstreetmap.org/relation/9623607 inte renderar.
On Wed, 2019-06-12 at 10:50 +0200, Johan Emilsson wrote:
> Hallå,
>
> Kollar på importerat material för Åre.Noterade att relationen
> https://www.openstreetmap.org/relation/9623607 inte renderar. Blir
> dock inte klok på varför inte.
Kan bero på att den korsar sig själv i denna punkt
Hallå,
Kollar på importerat material för Åre.Noterade att relationen
https://www.openstreetmap.org/relation/9623607 inte renderar. Blir dock
inte klok på varför inte. Någon med hög level i osm-fu får gärna ta sig en
titt.
/Johan
On Fri, 24 May 2019 at 16:28, Grigory Rechistov via Talk-se <
Hej!
Jag såg att Åstorps kommun laddades upp. Det blev inte så bra:
http://grillo.users.openstreetmap.se/a1dd1280bc521ca2725f8b8daaee11f993800871.jpg
http://grillo.users.openstreetmap.se/b353786731daa0679d8bed94907e465b2ce70029.jpg
Jag håller på att städa och önskar att du kunde låta bli att
Hej!
Jag har bläddrat igenom samtliga kommuner för att uppskatta vilka områden inte
behöver någon dataimport eftersom de redan är helt kartlagda eller av en annan
anledning. Jag har fyllt i detta in i tabellen:
Hej,
Jag är nu klar med Katrineholms kommuns rutor. Det blev 10 nya rutor av 45 som
täcker kommunens begränsningsbox eftersom kommunen redan var väl kartlagd.
Jag tror att den fick data av bättre kvalité än mitt första försök med Vingåkers
kommun. Jag håller dessutom på att rätta till några
Hej!
Några uppdateringar.
1. `plow-roads.py` skriptet [1] är färdig och kan användas för att ta bort de
nya noder som sitter för nära till vägar. Det gör att nya ytor inte får ha
några "midjor" över vägar. Jag kommer att använda den för alla kommande
rutor.
2. Som förväntat blir
Hej!
Här är vad som händer med importens förlopp och verktyg.
1. Jag har skapat en insticksmodul SnapNewNodes [1] som möjliggör att förena
två
sträckors närliggande gränser. Modulen liknar i syftet ContourMerge men
kräver mindre musrörelser och musklick. Jag testade dess JAR-fil på två
Hej!
> Här finns en annan intressant importstrategi med tasking manager-filer som
> output.
Tack, det ska jag läsa igenom och försöka tillämpa om det är möjligt till var
import.
Tydligen är vi inte första som sysslar med en import av stängda sträckor
(såsom byggnaders avtryck). Men det är svårt
Hej på er
Här finns en annan intressant importstrategi med tasking manager-filer
som output. https://www.openstreetmap.org/user/itsamap!/diary/152909
Kanske är detta bästa vägen även för denna import?
(det möjliggör att ha denna data som underlag under lång tid framöver
för folk som vill
Hej! Kolla imports-listan där jag beskriver min nuvarande approach med masker:
https://lists.openstreetmap.org/pipermail/imports/2019-April/005990.html
Återkommer till talk-se-listan med fler filer, detaljer för de som vill pröva
med nya vektor efter helgen. Trevlig helg!
Med vänliga
Hej Johan,
Jag känner inte till HOTOSM:s nu, behöver lära mig lite om det, men det låter
lovande!
>Понедельник, 29 апреля 2019, 2:57 +03:00 от Johan Emilsson
>:
>
>Hallå,
>Följer tråden med stort intresse.
>Kanske ett senare problem men vore det inte möjligt att använda HOTOSM:s
>tasking
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
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
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
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
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å
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
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
2019-04-25 07:35 skrev Karl-Johan Karlsson:
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. I
närheten finns även flera mer eller mindre urartade polygoner, med
konstiga inbuktningar och
Den ons 24 apr. 2019 kl 22:41 skrev egil :
> Hej
>
> On 2019-04-24 15:00, Mattias Dalkvist wrote:
> >
> > kollade lite kring Vingåker och det ser ur att vara ganska stor
> > variation på data kvalitén. det ser okej ut på håll men när man zoomar
> > in så är det massa små saker som ingen karterare
Hej
On 2019-04-24 15:00, Mattias Dalkvist wrote:
kollade lite kring Vingåker och det ser ur att vara ganska stor
variation på data kvalitén. det ser okej ut på håll men när man zoomar
in så är det massa små saker som ingen karterare skulle göra. tex way
685231007.
Enig den var illa.
om
Hej!
Jag tittade lite snabbt i västra Härjedalen, men tyckte inte att det var
speciellt bra runt fjällen.
Finns nog brister i grundmaterialet där.
/Johnny
Den ons 24 apr. 2019 kl 15:01 skrev Mattias Dalkvist :
> kul initiativ Grigory!
>
> kollade lite kring Vingåker och det ser ur att vara
kul initiativ Grigory!
kollade lite kring Vingåker och det ser ur att vara ganska stor variation
på data kvalitén. det ser okej ut på håll men när man zoomar in så är det
massa små saker som ingen karterare skulle göra. tex way 685231007.
om Vingåker är representativt för importen så skulle jag
Hej Joel!
>Antagligen endast på grund av att skogstypen ändras.
>Frågan är om algoritmen fungerar bättre om man behandlar all skog lika?
Ja, det verkar vara den mest sannolika anledningen. Din bild bevisar det också.
De filer som ligger nu uppladdade hade jag filtrerat för att slänga bort alla
Hej!
Angående den observationen att det kan vara för mycket flera detaljer i data:
Det nya skriptet är här:
https://github.com/grigory-rechistov/nmd-osm-tools/blob/master/filter-osm.py
Man kan använda det för att ta bort alla (multi)polygoner som har färre noder
än angiven gräns. Till
Hej!
Tack för ditt engagemang Grigory!
Jag provade att ladda ned Hjo kommun i version 2. Det som slog mig
ganska direkt var att det skapas hål i skogsområden, samt att
skogsområden utelämnas. Antagligen endast på grund av att skogstypen
ändras. Frågan är om algoritmen fungerar bättre om man
Hej Peter,
>Jag har laddat ner Linköping (i morse) och det ser ut som väldigt mycket
>konflikter.
Som jag skrev förut är det förväntat för Linköpings kommun. Som ett annat
exempel blev nästan alla objekt i subarean 0022 placerade där några polygoner
redan fanns.
>En del vägar har väldigt
Jag har laddat ner Linköping (i morse) och det ser ut som väldigt mycket
konflikter. Nya skogspolygoner i befintliga och nya skogspolygoner som skär
befintliga skogspolygoner. En del vägar har väldigt mycket "trappform" med
vägar i 90 räta graders vinklar norr/syd/öster/väster där det kanske
Hej Karl-Johan!
Tack för ditt intresse!
>Jag har laddat ner filerna och för Linköpings kommun och det är ganska mycket
>konflikter
Hur stort antal konflikter du ser? Handlar det om hundratals eller tusentals
problem? Linköpings kommun är redan väl kartlagd:
Hej,
Nu är den första varianten på nastän uppladdningsfärdiga OSM-filer för 288 av
291 kommuner tillgängliga. Länken till ziparkiven finns i tabellen här:
https://wiki.openstreetmap.org/wiki/Import/Catalogue/NMD_2018_Import_Plan/Status_per_subarea
. Om ni har tid, vänligen ladda ner någon
Nu kommer discussionen på Imports mejllista:
https://lists.openstreetmap.org/pipermail/imports/2019-April/005958.html
Med vänliga hälsningar,
Grigory Rechistov
With best regards,
Grigory Rechistov
___
Talk-se mailing list
Talk-se@openstreetmap.org
Hej,
Här kommer resultatet på mitt experiment med en av de minsta kommunfilerna,
nämligen 0022-Staffantorps (jo, jag vet att samtliga filnamn i uppsättningen
har ett extra "-s" på ändelser):
https://atakua.org/p/nmd/0022-Staffanstorps.tar.gz . Arkivet innehåller både
den OSM-filen efter
Hej!
Bra nyheter, jag lyckades lösa alla mina befintliga svårigheter med
automatiseringen/datakonverteringen, och nu håller på att producera första
OSM-filer som undergick hela bearbetningskedjan fram till conflation. Jag
kommer att publicera länkar till filerna i en tabell här:
Hej,
>NKA föreslog i tråden ovan att vid import av samma data överskrivs allt som
>inte ändrats i OSM mellan importerna
Det är enkelt genomförbart, tror jag. Varje objekt har changesetsnummer som
attribut som är synlig i OSM-filen. Man ska kunna veta vilka changesetsnummer
använts vid
Hej igen
Bra jobbat Grigory!
Ang. större import kontinuerligt se tex:
https://forum.openstreetmap.org/viewtopic.php?id=65563
Jag har lagt in en del skog runt Härnösand och datat som nu är
tillgängligt väsentligt bättre än vad jag lagt in.
Jag undrar om vi likt bussstoppen i Norge har mera
Hej Erik!
De är rimliga farhågor.
>10GB för Kiruna är rätt stor mängd data
Det är faktiskt 1,7 GB, jag mindes fel. Tänk på att a) det är rå vektordata,
jag ämnar gallra det ordentligt som beskrevs tidigare, b) Kirunaområdet är
undantaget, 82% av de 291 kommuner har GML-filer mindre än 250 MB
Detta var min poäng med att inte importera för mycket terräng typer och för
små polygoner, 10GB för Kiruna är rätt stor mängd data och kommer höja
ribban rejält för att handskas med Sveriges osm data.
Jobbet med att jämka det som finns och det som läggs in kommer behöva göras
igen när låt oss
Hej Christian, tack!
>Det kan vara svårt att få många att sätta upp hela kedjan av script och
>program som behövs.
Jo, det är sant. Jag kunde inte föreställa mig att jag skulle behöva så flera
verktyg och skriva så många nya skript innan jag hade börjat arbeta med datat.
Det blir väl jobbigt
Hej. Bra jobbat! Jag tar gärna på mig min hemkommun och ett par andra.
Jag vet att du har lagt ned massa arbete redan, men frågan är ifall det inte
vore lättast att en person kör igenom scripten för alla kommuner? Det kan vara
svårt att få många att sätta upp hela kedjan av script och program
Hej,
Här är en liten rapport på sammanblandningsprocessen. Mitt skript visar
någonting intressant, men det kräver några förbättringar innan det blir
brukbart på riktigt. Vad är bra är att skriptet är väldigt snabbt. Som förut
använder jag Vingåkers kommun som ett exempel där mycket skogsyta
>Är alla delar scripade, detta låter som ett manuellt steg?
Att konvertera etiketter och gallra datafil är skripterade. Det är
konverteringen mellan olika vektorfilformat som fortfarande kräver manuellt
arbete. Anledningar till detta:
1. Chaiken-filtern är tillgänglig endast i QGIS/GRASS. Och
On Wed, Apr 10, 2019 at 5:52 PM Grigory Rechistov via Talk-se
wrote:
> 4. Konvertera etiketter, gallra datafil.
Är alla delar scripade, detta låter som ett manuellt steg?
___
Talk-se mailing list
Talk-se@openstreetmap.org
Hej,
Nu har jag skurit Sverige i bitar :-)! Här
https://drive.google.com/open?id=1JfAidyqIdelsRj1tjrpG-OR6IkJuHxWE (400 MB)
finns en arkivfil med 291 GeoTIFF-filer motsvarande till samtliga kommuner.
Kommunernas gränser hittar man här som SHP-filer:
On 2019-04-07 17:47, Grigory Rechistov via Talk-se wrote:
> Hej,
>
> >En särskild användare bör skapas.
> Sant, det är enligt guidelinjerna:
> https://wiki.openstreetmap.org/wiki/Import/Guidelines#Use_a_dedicated_user_account
>
> >Hur vi ska identifiera områden vet jag ej.
> > ska man identifiera
Hej egil,
>Informationen om hur detta data tagits fram skulle jag vilja anges tydligt i
>planen/var det nu passar bäst.
Det håller jag med, ska göras.
>Вторник, 9 апреля 2019, 23:39 +03:00 от egil :
>
>Hej Grigory
>Tusen tack för ditt utförliga svar.
>Jag är inte längre lika skeptisk längre.
Hej Anders,
> Hur många överlappande polygoner blir det i en kommun?
Bra fråga. För de kommuner som redan är väl kartlagda misstänker jag att
antalet blir stort, liksom tusentals befintliga polygoner mot tiotusentals nya
polygoner från importen.
> Det är lätt att missa något scenario man inte
Hej Grigory
Tusen tack för ditt utförliga svar.
Jag är inte längre lika skeptisk längre. Vi får lita på att dem på
naturvårdsverket har koll på sina infraröda bilder och AI.
Informationen om hur detta data tagits fram skulle jag vilja anges
tydligt i planen/var det nu passar bäst.
Kul att du
på i en algoritm.
/Anders Andersson
Från: Grigory Rechistov
Skickat: den 9 april 2019 10:22
Till: OpenStreetMap Sverige mailinglista
Ämne: Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData
Hej,
Angående datas conflation vill jag pröva den följande
Hej,
Angående datas conflation vill jag pröva den följande idén. Beskrivningen nedan
finns även i importplanen.
It's algorithm is roughly as follows.
* Detect real and potential intersections between "new" polygons and "old"
polygons.
* For each pair of detected polygons, an automatic
[förra mejlet skickats av misstag] Hej,
Här fortsätter jag mina experiment över Vingåkers kommun. Laddade ner OSM-data
på kommunen som ett lager i JOSM och slog ihop mitt lager med det för att se
hur dåligt konflikter hade blivit.
Det finns inte några särskilda fel utan flera varningar för
Hej
>Воскресенье, 7 апреля 2019, 21:00 +03:00 от Christian Asker
>:
>
>Hej. Vad gäller skillnaden mellan löv- och barrskog tror jag att
> infraröda bilder och bildbehandling lär vara lika pålitligt som
> att bege sig ut i skogen själv. Det finns ju ingen exakt gräns för
> när
Hej. Vad gäller skillnaden mellan löv- och barrskog tror jag att
infraröda bilder och bildbehandling lär vara lika pålitligt som att bege
sig ut i skogen själv. Det finns ju ingen exakt gräns för när en skog är
det ena eller det andra och vi har ingen chans att göra det manuellt.
Jag tycker
En självkorrigering till mitt föregående mejl: det är osmconvert som kan klippa
data, inte osmfilter:
https://wiki.openstreetmap.org/wiki/Osmconvert#Clipping_based_on_a_Polygon
>Воскресенье, 7 апреля 2019, 18:47 +03:00 от Grigory Rechistov via Talk-se
>:
>
>Hej,
>
>>En särskild användare
Hej,
>En särskild användare bör skapas.
Sant, det är enligt guidelinjerna:
https://wiki.openstreetmap.org/wiki/Import/Guidelines#Use_a_dedicated_user_account
>Hur vi ska identifiera områden vet jag ej.
> ska man identifiera områden manuellt för import, eller kan man göra en enda
> import för
Hej,
>dem verkar vara skapad via AI och flygfoto/sattelitbilder .
I ett PDF-dokument som kom med marktäckedatan (den ZIP-arkiv som går att ladda
ner) nämndes det att man också hade tillgång till infraröda bilder. De bör
hjälpa till att skilja på skogstyper i tillägg till de vanliga bilderna i
On 2019-04-06 09:00, Christian Asker wrote:
Hej. Jag tycker att planen ser bra ut, även om jag själv inte har några
erfarenheter av att skriva sådana planer.
En fråga bara: hur går själva importen till rent tekniskt sedan? Vi vill
ju lägga in marktäckedata bara där detta redan saknas; ska man
Hej
On 2019-04-07 09:08, Grigory Rechistov via Talk-se wrote:
Hej,
Nyss körde jag mina nya skript på samma Vinön-area som tidigare. Med nya
`remap-raster.py` skriptet finns det inte längre några redundanta
intilliggande skogsvägar, de är nu sammanslagna.
Efter Chaikens utjämningsalgoritm
Hej,
Nyss körde jag mina nya skript på samma Vinön-area som tidigare. Med nya
`remap-raster.py` skriptet finns det inte längre några redundanta intilliggande
skogsvägar, de är nu sammanslagna.
Efter Chaikens utjämningsalgoritm (med 20 meter som tröskel värde) körde jag
dessutom
Hej,
> Som tidigare sagt beror det troligen på att stil-beskrivningen tappas bort av
> någon anledning när jag försöker transformera rastern, vare sig mellan
> gdal_sieve eller QGIS-kalkylatorn.
Eftersom några befintliga verktyg inte verkar skriva korrekt färgtabell för
singelband GeoTiff var
Hej Christian,
>Jag tror som sagt att man kan fixa till detta med QGIS Raster Calculator.
>Annars kan man skriva ett python-script som använder GDAL för att fixa det
>manuellt, men jag tror att det blir mer jobb.
Jo, det är möjligt att formulera ett matematiskt yttryck som gör det jobbet.
Men
Hej. Jag tycker att planen ser bra ut, även om jag själv inte har några
erfarenheter av att skriva sådana planer.
En fråga bara: hur går själva importen till rent tekniskt sedan? Vi vill
ju lägga in marktäckedata bara där detta redan saknas; ska man
identifiera områden manuellt för import,
Hej. Jag tror som sagt att man kan fixa till detta med QGIS Raster
Calculator. Annars kan man skriva ett python-script som använder GDAL
för att fixa det manuellt, men jag tror att det blir mer jobb. Sen finns
det säkert fler sätt som jag inte känner till... :)
Jag håller med om att de pixlar
Hej Peter,
Jo, jag har också märkt det och tycker att det är konstigt. Det härstammar
troligen från att olika rasterpixelsvärden motsvarar till samma
etikettsuppsättning. Till exempel, GeoTiffs värden 115, 116 och 117 blir till
samma taggar:
## 115 Triviallövskog utanför våtmark
## 116
Jag har tittat på https://atakua.org/p/nmd/vinon-3.osm.gz och har en fråga:
Om man tittar på områdena kring nod -1424890 (59.18809091653,
15.73068800312) så har området öster om (way -1434062), samt väster om (way
-1434100) denna nod exakt samma uppsättning tags:
"landuse"="forest"
Och samtidigt fortsätter jag förbättra mina skript. Skriptet finns här
https://gist.github.com/grigory-rechistov/39c7e329cb1f9b42a97ca5960377173d och
det tar in en OSM fil som är direkt konvertering av en GeoJSON-fil. Den
sistnämnda filen kommer med de ursprungliga "DN"-taggarna. Sedan
Hej!
>Finns informationen ser jag ingen anledning att inte ta med den. Skogstyp ser
>jag ett värde med att veta.
Angående skogstyp blir läget bättre än jag fruktade förut. Den skapar inte så
mycket visuell- och databrus. Men hittills prövade jag det bara på en ö. Vi får
se hur läget blir i
mailinglista
Ämne: Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData
2019-04-04 12:13 skrev Micke:
> Hej!
>
> Jag vill bara komma med synpunkter angående skogstyper. Finns
> informationen ser jag ingen anledning att inte ta med den. Skogstyp ser
> jag ett värde med att veta.
>
2019-04-04 12:13 skrev Micke:
Hej!
Jag vill bara komma med synpunkter angående skogstyper. Finns
informationen ser jag ingen anledning att inte ta med den. Skogstyp ser
jag ett värde med att veta.
+1!
Områden med stora polygoner är svårare att jobba med än områden med
flera små (så
; OpenStreetMap Sverige mailinglista; Grigory Rechistov
via Talk-se
Ämne: Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData
Hej.
1. Detta beror nog på att stil-beskrivning inte kommer med. Det är med andra
ord inget fel på datat.
Du kan nog slå ihop flera olika värden med Raster Calculator i
Hej!
Det ser ut som att det finns många noder som ligger precis i linje, eller
nära nog i linje. Verkar som att vägarna är genererade med ett påtvingat
maximalt avstånd till nästa nod. De mellanliggande noderna skulle man kunna
reducera. Man får väl labba fram någon lämplig toleransgräns, såsom
> Självkorsningarna är de mest påfrestande typen problem: JOSM kan inte rätta
> till dem automatiskt. Jag behöver antingen radera den punkt som står i
> självkorsningen, eller radera den hela "öglan".
Jag har nu en idé om hur jag kan lösa självkorsningarna automatiskt i detta
fall. De är
Hej,
> Detta beror nog på att stil-beskrivning inte kommer med. Det är med andra ord
> inget fel på datat.
Jaha. Jag var nämligen för lat att felsöka det och därför valde att filtrera
mindre polygoner vid GeoJSON -> GeoJSON transformeringen i min egen skript.
Jag är nu mycket nöjd med det
Hej.
1. Detta beror nog på att stil-beskrivning inte kommer med. Det är med andra
ord inget fel på datat.
Du kan nog slå ihop flera olika värden med Raster Calculator i QGIS.
Personligen är jag dock inte övertygad om att det är rätt väg att gå. Har vi
detaljerad information om skogstyp kan vi
Hej,
För att fixa "trapporna" som kvarstår efter gdal_polygonize försökte jag
använda en insticksmodul v.generalize av GRASS-verktyg (se frågan här:
https://gis.stackexchange.com/questions/3/how-to-smooth-large-vector-polygons-from-raster
).
Här är hur linjerna på Gränsö (
Jag gjorde en jämförelse i mina gamla hemtrakter, för att få lite
Norrbottens-terräng:
http://lab3.turepalsson.se/~ture/tmp/vidsel-20190403/
En karta med bara OSM-data, en med OSM+NMD (helt ofiltrerad så därför
hiskeligt stor fil), en med bara LMV öppna data.
Hm, undrar vad 17 som hände med
Utterström
>
>________
>Från: Christian Asker
>Skickat: den 1 april 2019 21:36
>Till: talk-se@openstreetmap.org
>Ämne: Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData
>
>
>Hej kära karterare.
>
>Jag provade med "ogr2osm.py&
Det ser ju inte så pjåkigt ut! Jag ska testa gdal_contour för att snygga till
kantigheten. Återkommer med resultat när jag hunnit med detta.
Mvh Christian
"Ture Pålsson" skrev: (3 april 2019 07:25:55 CEST)
>
>Jag tror inte det här kom igenom på första försöket. p.g.a. för stort
>attachment,
Jag tror inte det här kom igenom på första försöket. p.g.a. för stort
attachment, så jag testar med en länk i stället. :-)
Jag tog Christians översättningstabell och gjorde ett snabbhack för
att dra in datat i min kartrenderare. "Polygoniseringen" är gjort med
ST_DumpAsPolygons i PostGIS.
On Tue, Apr 2, 2019 at 10:38 PM Grigory Rechistov via Talk-se
wrote:
> >ifall det finns detaljerad information om skogstyp är väl det bra?
> Det beror på det resulterande signal-brusförhållandet, tror jag. Det blir
> dåligt om skogstypen ändras vid varje 10-20 meter, då blir det bättre att
>
I skriptet jag visade i början tar jag bort mindre features med hjälp av
gdal_sieve. Det går att justera hur små objekt som ska filtreras bort genom
kommandoradsparametrarna. Så det gäller bara att prova sig fram till ett bra
värde.
Mvh Christian
Grigory Rechistov via Talk-se skrev: (2
> F.ö. är Terrängkartan, NMD och terrängen själv inte alls överens om var det
> är blött.
Jag misstänker att naturen själv sällan är överens om var det är blött :-)
Åtminstone på jordens norra breddgrader där jag råkar vandra.
Jag brukar läsa "våtmark" antingen som "detta område ska sannolikt
>Jag tänker att det vi ska importera är de områden där det saknas data, och det
>gäller framförallt områden utanför tätorter.
Det håller jag med om. I min erfarenhet råkar man rita tätorterna manuellt
förr och senare i alla fall; det är skogar och jordbruksmark som är "tråkiga"
att spåra och
F.ö. är Terrängkartan, NMD och terrängen själv inte alls överens om var det är
blött. Jag var ute i helgen och rekade i skogen söder om "scrub"-ytan uppe till
höger på kartan (det är ett område som brandhärjades för runt 20 år sedan) och
hittade en del sankmarker som finns på TK men inte i
och fjällinformation för att uppnå full täckning
> för hela landet. Om det är möjligt erhålla vettig vektordata från
> Marktäckesdatat så vore det därför rätt trevligt.
>
> Mvh Jimmy Utterström
>
> ------
> *Från:* Christian Asker
> *Skickat:* den 1
62 81
www.havochvatten.se<http://www.havochvatten.se>
[cid:image001.png@01D3C4EF.2260BF70]
Levande hav, sjöar och vattendrag
till glädje och nytta för alla.
Från: Christian Asker
Skickat: den 1 april 2019 21:36
Till: talk-se@openstreetmap.org
Ämne: Re: [Talk-se] Naturvårdsverkets ny
sdatat så vore det
>därför rätt trevligt.
>>
>> Mvh Jimmy Utterström
>>
>> ____
>> Från: Christian Asker
>> Skickat: den 1 april 2019 21:36
>> Till: talk-se@openstreetmap.org
>> Ämne: Re: [Talk-se] Naturvårdsverkets nya
Hej. Jag håller helt med vad gäller byggnader samt sjöar och delvis vad gäller
industriområden.
Jag tänker mig att datatillbehör används för att få täckning utanför
tätbefolkade områden där det idag saknas data. Där är byggnader inte lika
viktiga att få med.
Industriområden kan man kanske ta
vektordata från Marktäckesdatat så vore det därför
> rätt trevligt.
>
> Mvh Jimmy Utterström
>
> ____
> Från: Christian Asker
> Skickat: den 1 april 2019 21:36
> Till: talk-se@openstreetmap.org
> Ämne: Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData
>
&g
Hej Christian,
>Det som jag gärna vill ha lite feedback på nu är mappningen, så att den är så
>bra som möjligt. Nedanstående är vad jag har hittills.
Jag tycker om ditt taggutval. Men jag tror att vi inte ska använda den
NMD-datan för byggnader, industriområden och vatten. Det vill säga borde
@openstreetmap.org
Ämne: Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData
Hej kära karterare.
Jag provade med "ogr2osm.py" och nu får jag .osm filer med attribut som JOSM
kan läsa. Jag vet inte hur bra det funkar med stora filer, men jag får väl
prova.
Det som jag gär
Hej kära karterare.
Jag provade med "ogr2osm.py" och nu får jag .osm filer med attribut som
JOSM kan läsa. Jag vet inte hur bra det funkar med stora filer, men jag
får väl prova.
Det som jag gärna vill ha lite feedback på nu är mappningen, så att den
är så bra som möjligt. Nedanstående är
Det låter lovande, bra jobbat!
Mvh Christian
Grigory Rechistov via Talk-se skrev: (1 april 2019
00:17:11 CEST)
>Hej, ikväll hade jag mer framgång med QGIS som hjälpverktyg och GeoJSON
>som vektorformat som QGIS kan skriva och JOSM kan läsa. Då lyckades jag
>se mutipolygoner med etiketter i
1 - 100 av 108 matches
Mail list logo
