Hej!
Lång historia kort: jag har skapad en privat OSM API server som nu innehåller
samtliga 118 tusen importnoder. Man kan använda den för att ladda ner, jämföra,
redigera, radera flytta och eventuellt ladda upp punkter till den offentliga
OSM-databasen. Man "öppnar" både servrarna som två JOSM:s
Hej,
Om ni är intresserade följer Lantmäteriets svar på mitt ärende om avstavade
ortnamn på GSD-terrängkartan.
Hej
Nu har jag fått svar från den kartingenjör som handlagt ditt ärende.
Tyvärr så saknas de fullständiga namnen
Hej!
Först några uppdateringar i importfilerna. Nu använder jag fuzzy
namnjämförelsen för att
detektera liknande namn mellan gamla och nya noder, vilket skulle röja bort namn
med upp till en felstavelse per tio bokstäver. Detta är i och för sig ett
tveeggat svärd: nu
producerar konflationen
>>>
Hej!
Jag fortsätter förbättra konflationens algorithm. Nu tar den hänsyn till stora
tätorters gränser. Till exempel, hamnar inga "hamlet"-noder inom tätortsgränser.
Istället blir de förvandlade till "neighbourhood"-noder för att stämma mot den
rådande klassificeringen.
Jag använder de
Hej!
Jag ville skicka detta mejl tidigare i fredags, men hann inte. Jag lägger till
ett par kommentar till diskussionen nere.
> Men oavsett om man har lokalkännedom eller inte så tror jag faktiskt inte
> att det BEHÖVS så mycket lokalkännedom, utan det som behövs är helt enkelt
> ett mänskligt
Hej Ture, Andreas, Anders, pangoSE och andra,
Längst ner följer mina kommentarer till dina svar.
> Jag har för mig att LMV publicerade textlagren i två uppsättningar: en
”kart”-uppsättning med snygga avstavningar, radbrytningar och så, och en
”GIS”-uppsättning där namnen sitter ihop. Vilket av
Hej,
Jag fixade ett fel i skriptet. Det upptäcktes att gamla noders
begränsningsramar var för stora (förväxlade latitud och longitud i en plats)
vilket ledde till större antal falska positiva matchningar. Med andra ord,
bestämdes ibland två lika nämnda noder som dubbletter trots att de var
Hej Andreas, stort tack för feedback! Här är mina kommentarer.
> Exempelvis förekommer Hjortseryd två gånger, med en brytlinje mellan två
> kartblad mellan dem båda. Kommer sådana dubbletter kollas av?
Sådan koll kan jag enkelt lägga till i skriptet. Men ditt exempel med Hjortseryd
visar bara
Här är länken till samtliga filer, version 9:
https://drive.google.com/open?id=182NzEuSHM3fuYIVRErp7-GWYhum02UZN
Mappen "regions" innehåller OSM-filer som motsvarar till Lantmäteriets
områdeskoder, i mappen "tiles" blev de delade i mindre rutor.
I versionen 9 åtgärdade jag även ytterligare
Hi Ivana,
A recommended way to get bigger regions of the map is the following.
- Download a data extract covering the country/region you are interested in as
an OSM.BZ2 file. You can get it here, for example for Sweden [1].
- Use osmconvert [2] to clip a desired region from the export file. For
Hej, det ser normalt ut i min webbläsare nu.
Jag märkte liknande visuella artefakter på Vätö för ett par dagar sedan:
https://www.openstreetmap.org/relation/6729361#map=12/59.8199/18.9393 . Då dök
"vattenblått" upp kortvarigt här och där på öns yta. Men det var inget fel på
data i området.
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
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
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.)
>
>Se "merge workflow" som beskrivs här:
>https://wiki.openstreetmap.org/wiki/Import/Catalogue/US/BingBuildings#Data_Merge_Workflow
>
>Mvh
>
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! 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
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
te 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
Hej AndersAndersson,
> Vad hände med befintliga skogsområdet
> https://www.openstreetmap.org/way/194522135/history
Det raderade jag manuellt under importen. Det verkar också att jag samtidigt
raderade det nya datat som skulle ha ersatt det gamla datat. Låt mig korrigera
det nu. Hoppas att det
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å
mmer detta bli ett rejält lyft.
>
>Den ons 24 apr. 2019 kl 07:32 skrev Grigory Rechistov via Talk-se <
>talk-se@openstreetmap.org >:
>>Hej egil och allihop,
>>
>>>Jag har börjat jobba med datan för Härnösands kommun. Det finns så många
>>>konflikt
Hej egil och allihop,
>Jag har börjat jobba med datan för Härnösands kommun. Det finns så många
>konflikter att jag vald att inte importera delar av den (landuse=forest)
Jag ser samma läge med de kommuner som redan är väl kartlagda. Utan att
automatiskt justera polygoners geometri under
Jo, det var inte något gammalt basdata, det var mitt eget misstag. Jag
förväxlade nämligen mellan de mängder filer som hade "Stockholm" i namnet och
laddade upp en tidigare version som hade kvar alla dumma artefakter.
JOSM-valideringen hjälpte inte (det granskar inte att t ex en byggnad korsar
Hej, det var jag som gjorde morgonens import. Förlåt för besväret det skapade.
Antagligen var mitt exportdata för gammalt som användas som areans basskikt.
Låt mig granska lokalt konflikternas natur och återvända med fler detaljer.
>Понедельник, 22 апреля 2019, 10:59 +03:00 от Snusmumriken
>:
möjligt och att få in skogstypen
>(barrskog/lövskog m.m.) så tycker jag att det är bättre att få in ett så
>korrekt område som möjligt.
>Se skogsområdet i mitten här:
>http://www.torsson.se/joel/osmpics/nmd2018-osm-hjo.png
>Mvh
>Joel Grafström
>2019-04-17 11:29 skrev Grigory Re
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
med mycket
>brus och komplicerade genometrier) så är det mycket svårare att förbättra
>efteråt...
>
>mvh
>On Wed, Apr 17, 2019 at 11:30 AM Grigory Rechistov via Talk-se <
>talk-se@openstreetmap.org > wrote:
>>Hej Karl-Johan!
>>Tack för ditt intresse!
>>
&
ttps://wiki.openstreetmap.org/wiki/Import/Catalogue/NMD_2018_Import_Plan/Status_per_subarea
> för de kommuner jag tänker mig ge mig på eller bara på den som jag just nu
>jobbar på? Hur som helst så borde jag nog skapa ett "import account". Jag ska
>se om jag får mer tid
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:
de på
>Carto och i vektorvy, men om vi lär nykomlingar att koncentrera sig
>på annat än markytor i början så kommer det nog att gå alldeles bra.
>
>Det finns mycket att göra som inte är skog på kartan till att vi
>alla kan ha händerna fulla ändå.
>
>On 2019-04-11 19:33,
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
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,
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
10, 2019 at 5:52 PM Grigory Rechistov via Talk-se
>< talk-se@openstreetmap.org > wrote:
>> 4. Konvertera etiketter, gallra datafil.
>
>Är alla delar scripade, detta låter som ett manuellt steg?
С наилучшими пожеланиями,
Григорий Речистов.
Med vänliga hälsningar,
Grigo
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:
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,
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
att behålla
>> den information som ju faktiskt finns i datat, förutom tex väldigt
>> små områden lövskog inuti en barrskog.
>>
>>Mvh Christian
>>Den 2019-04-07 kl. 16:33, skrev Grigory
>> Rechistov via Talk-se:
>>>Hej,
>>>
>>>
Christian
>Den 2019-04-07 kl. 16:33, skrev Grigory
> Rechistov via Talk-se:
>>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 at
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,
>
>>
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
s med gdal_sieve.py, är det så att
om man sparar en ny filnamn tappas färgkartan bort. Däremot om man skriver över
den ursprungliga filen då förblir färgkartan i den och resultatet ser ut
normalt.
>Воскресенье, 7 апреля 2019, 10:55 +03:00 от egil :
>
>Hej
>
>On 2019-04-07 09:08, G
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
älper med redundanta polygoner.
>Суббота, 6 апреля 2019, 21:07 +03:00 от Grigory Rechistov via Talk-se
>:
>
>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 d
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
424890 (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"
> "leaf_type"="broadleaved"
> "source"=&
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
> 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
rivning 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 väl behålla den. Noggr
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ö (
> 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
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
Mitt 140 kbyte TIFF-klipp producerade 2 Mbyte GeoJSON:en, så man bör jobba
endast med lagom stora delområden. Nu är klockan mycket, så planerar jag
fortsätta senare nästa vecka.
>Воскресенье, 31 марта 2019, 14:41 +03:00 от Grigory Rechistov via Talk-se
>:
>
>>Det troliga är väl a
>Det troliga är väl att det är något i JOSM (och pluginet "opendata") som är
>orsaken till problemen.
Kanske är det .shp-filformatet själv som begränsar oss i det fallet. Jag
vandrade genom wiki.openstreetmap.org och stötte på en anmärkning
(https://wiki.openstreetmap.org/wiki/Shapefiles):
Hej,
jag försöker nu reproducera dina resultat med skriptet, men det kommer att ta
en stund p.g.a. att jag aldrig använt GDAL förut. Jag behöver lära mig hur man
kör de verktygen för att t.ex. skära ut en mindre kartyta för testkör.
Mina tankar angående de befintliga problemen:
>att
Fast visas nya ändringar inte på tiles, de har säkert nått databasen. Om man
använder "Vad är här?" knappen och pekar på kartan där ändringarna skulle ha
visats, kan man se nya konturer och egenskaper för nya osynliga ytor.
>Среда, 30 января 2019, 11:17 +03:00 от Grigory Rechisto
Hej, jag märkte det också, det går långsamt för tiles att uppdateras
nuförtiden. Det hände förut med mina ändringar.
>Среда, 30 января 2019, 10:30 +03:00 от Karl-Johan Karlsson <
>karl.johan.karls...@gmail.com >:
>
>Någon annan som märkt av det här? Normalt när jag editerar i JOSM och laddar
66 matches
Mail list logo
