Re: [Talk-se] Importera byggnadshöjder där dessa saknas?

2022-03-18 Thread Micke
Förutsatt att _inte_ befintliga height-taggar skrivs över. Skulle det så klart 
stå.

/Anders Andersson


Från: Micke 
Skickat: den 16 mars 2022 22:07
Till: Christian Asker ; OpenStreetMap Sverige 
mailinglista 
Ämne: Re: [Talk-se] Importera byggnadshöjder där dessa saknas?

Hej!

Det låter som en bra idé. Förutsatt att befintliga height-taggar skrivs över. 
Dessa vore kanske bra att gå igenom manuellt. Det är ju ett jobb som går att 
dela upp på flera, att avgöra om den importerade eller den befintliga är mest 
trolig.

/Anders Andersson


Från: Christian Asker 
Skickat: den 15 mars 2022 10:23
Till: OpenStreetMap Sverige mailinglista 
Ämne: [Talk-se] Importera byggnadshöjder där dessa saknas?

Hej kära karterare. Jag vet inte ifall jag ska fråga här eller i
facebook-gruppen för OSM-Sverige, men jag börjar här i alla fall.

Jag heter Christian Asker och karterar en del för OSM på fritiden. I
mitt arbete som forskare i luftmiljö på SMHI använder vi OSM-data både
här och där. Bland annat använder vi byggnader för att modellera
luftmiljön i gaturum i städer. En osäkerhet här är att många byggnader i
OSM saknar byggnadshöjd.

Som ett led i ett projekt kikar vi nu på att plocka byggnadshöjder från
Lantmäteriets Laserdata skog. Än så länge täcks bara delar av Sverige av
denna laserdata, men det är åtminstone bättre än det vi har nu.

Frågan är nu: när vi ändå beräknar byggnadshöjder, ska vi kanske
importera dessa till OSM, för de byggnader som saknar höjd-info idag?
Licensen på datat från LM är CC0, så den ska vara kompatibel med OSM.
Troligen kommer det handla om att plocka höjden i centroid-punkten för
varje byggnad. Troligen får man även filtrera bort små byggnader.

Importen innebär alltså inte att man lägger till byggnader som inte
redan finns i OSM, utan endast "height"-taggen där denna saknas. Så; är
detta intressant för OSM?


Mvh Christian Asker (OSM: ChristianA)




___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se


Re: [Talk-se] Importera byggnadshöjder där dessa saknas?

2022-03-16 Thread Micke
Hej!

Det låter som en bra idé. Förutsatt att befintliga height-taggar skrivs över. 
Dessa vore kanske bra att gå igenom manuellt. Det är ju ett jobb som går att 
dela upp på flera, att avgöra om den importerade eller den befintliga är mest 
trolig.

/Anders Andersson


Från: Christian Asker 
Skickat: den 15 mars 2022 10:23
Till: OpenStreetMap Sverige mailinglista 
Ämne: [Talk-se] Importera byggnadshöjder där dessa saknas?

Hej kära karterare. Jag vet inte ifall jag ska fråga här eller i
facebook-gruppen för OSM-Sverige, men jag börjar här i alla fall.

Jag heter Christian Asker och karterar en del för OSM på fritiden. I
mitt arbete som forskare i luftmiljö på SMHI använder vi OSM-data både
här och där. Bland annat använder vi byggnader för att modellera
luftmiljön i gaturum i städer. En osäkerhet här är att många byggnader i
OSM saknar byggnadshöjd.

Som ett led i ett projekt kikar vi nu på att plocka byggnadshöjder från
Lantmäteriets Laserdata skog. Än så länge täcks bara delar av Sverige av
denna laserdata, men det är åtminstone bättre än det vi har nu.

Frågan är nu: när vi ändå beräknar byggnadshöjder, ska vi kanske
importera dessa till OSM, för de byggnader som saknar höjd-info idag?
Licensen på datat från LM är CC0, så den ska vara kompatibel med OSM.
Troligen kommer det handla om att plocka höjden i centroid-punkten för
varje byggnad. Troligen får man även filtrera bort små byggnader.

Importen innebär alltså inte att man lägger till byggnader som inte
redan finns i OSM, utan endast "height"-taggen där denna saknas. Så; är
detta intressant för OSM?


Mvh Christian Asker (OSM: ChristianA)




___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se


Re: [Talk-se] Problem med ortnamnsimporten

2020-06-02 Thread Micke
Hej!

Nej inga direkta åsikter, mer än att jag inte fått svar av serge_dahlin (som du 
säkert redan sett). Han svarade föredömligt på bra svenska på två av mina 
frågor medans nodimporten pågick.
https://www.openstreetmap.org/changeset/84314486

Sen väcks ju nyfikenheten om vem och varför.
Lite konspiratoriskt kanske, men jag funderar på om SÄPO eller MUST skulle 
kunna tänkas vara intresserade?
Någon lär ju ha fått betalt i och med att det var konstant pågående, från flera 
olika användare, i några veckor.
Känns osannolikt att svenskar fått betalt för att jobba med något sådant utan 
att ge sig till känna. Och framför allt inte med hackade konton.
Vem har då nytta av en karta som kompletterats med svenska småorter?
Tyska turistföreningen eller något liknande? Ja, men inte troligt med hackade 
konton.
Utländsk militär? Långsökt kanske, men kanske ändå det mest troliga utifrån de 
fakta som finns i dagsläget.
Jag skickar ett mail till försvaret så får dom avfärda det. Bättre dom avgör om 
dom har nytta av informationen än att jag gör det.


/AndersAndersson


Från: Andreas Vilén 
Skickat: den 1 juni 2020 23:19
Till: OpenStreetMap Sverige mailinglista 
Ämne: Re: [Talk-se] Problem med ortnamnsimporten

Hej!

Nu har det gått en tid sedan mitt förra mail och jag har inte fått svar från 
något av kontona.

Är det någon som har någon mer åsikt i den här frågan? Annars tänkte jag gå 
vidare med ett mail till DWG och se om vi kommer vidare den vägen.

MVH Andreas

On Mon, May 18, 2020 at 6:50 PM Andreas Vilén 
mailto:andreas.vi...@gmail.com>> wrote:
Det verkar ha varit totalt 14 konton som genomfört denna import. Jag har tagit 
en närmare titt på alla dessa konton för de har många gemensamma nämnare.

master-shake
http://hdyc.neis-one.org/?master-shake
Skapades 19/1. Låg oanvänt till 13/4. Testedits 13-15/4 och sedan drygt 1000 
changesets om dagen varje dag till 26/4. Efter det inga edits. Har deltagit i 
två changesetdiskussioner på engelska: 
https://resultmaps.neis-one.org/osm-discussion-comments?uid=10675834

ap-s
http://hdyc.neis-one.org/?ap-s
Skapades 19/1. Låg oanvänt till 19/4. Testedits 19-29/4 och sedan drygt 1000 
changesets om dagen varje dag till 6/5. Efter det inga edits.

zag_abss
http://hdyc.neis-one.org/?zag_abss
Skapades 19/1. Låg oanvänt till 19/4. Testedits 19-24/4 och sedan drygt 1000 
changesets om dagen varje dag till 1/5. Efter det inga edits.

Stasik1
http://hdyc.neis-one.org/?Stasik1
Skapades 17/5-2016. Genomförde runt 11 changesets då, det första i Ukraina. Låg 
sedan oanvänt fram till 15/2 då några testedits gjordes fram till 17/2. 
Gissningsvis i Indonesien men jag hittar inte detaljer om vilka changesets 
dessa var. Låg igen oanvänt till 24/4. Testedits 24-27/4 och sedan drygt 1000 
changesets om dagen till 1/5. 353 changesets 4/5 sedan åter runt 1000 om dagen 
7-9/5. Efter det inga edits.

tomas471
http://hdyc.neis-one.org/?tomas471
Skapades 19/4-2017. Genomförde runt 11 changesets då, den första i ett 
HOT-projekt hotosm-project-2782 i Mozambique. Låg sedan oanvänt fram till 14/2 
då några testedits gjordes fram till 17/2. Låg igen oanvänt till 23/4. Från det 
datumet gjordes runt 1000 changesets om dagen fram till 30/4. Efter det inga 
edits.

rohweder
http://hdyc.neis-one.org/?rohweder
Skapades 10/10-2009. Genomförde något 20-tal edits i Tyskland runt november 
2010 och framåt. Låg sedan oanvänt till 15/2 då några testedits gjordes fram 
till 17/2. Också dessa i Indonesien verkar det som. Låg igen oanvänt till 24/4. 
Några testedits till 26/4 sedan runt 1000 changesets om dagen varje dag 
27/4-1/5. Åter en massiv mängd changesets 8-9/5. Efter det inga edits.

serge_dahlin
http://hdyc.neis-one.org/?serge%20dahlin
Skapades 19/1. Låg oanvänt till 19/4. Testedits 19-24/4 och sedan drygt 1000 
changesets om dagen varje dag till 30/4. Efter det inga edits. Har deltagit i 
två changesetdiskussioner på svenska: 
https://resultmaps.neis-one.org/osm-discussion-comments?uid=10675882

mustahir
http://hdyc.neis-one.org/?mustahir
Skapades 9/5-2018. Genomförde drygt 10 edits då som en del av HOT-projekt 
hotosmid-project-111 i Indonesien. Låg sedan oanvänt till 15/2 då några 
testedits gjordes fram till 17/2. Också dessa i Indonesien. Låg igen oanvänt 
till 25/4. Testedits 25-30/4 sedan runt 1000 changesets om dagen nästan varje 
dag 1/5-9/5. Efter det inga edits.

arraggonn
http://hdyc.neis-one.org/?arraggonn
Skapades 23/2-2012. Genomförde runt 10 edits då i Ryssland. Låg sedan oanvänt 
till 15/2 då några testedits gjordes fram till 17/2. Även dessa i Indonesien 
vad det verkar. Låg igen oanvänt till 24/4. Testedits 24/4-29/4 sedan runt 1000 
changesets om dagen nästan varje dag 30/4-9/5. Efter det inga edits.

bob_curse_isaac
http://hdyc.neis-one.org/?bob_curse_isaac
Skapades 19/1. Låg oanvänt till 19/4. Testedits 19/4-1/5 och sedan drygt 1000 
changesets om dagen 4-8/5. Efter det inga edits.

Sivia1811
http://hdyc.neis-one.org/?Sivia1811
Skapades 12/8-2018. Genomförde runt 10 edits i Uganda 

Re: [Talk-se] Problem med ortnamnsimporten

2020-05-18 Thread Micke
Hej!

Jag har egentligen inte så mycket att tillägga, men de ändringar jag tittar på 
från flera användare i länen kring Dalarna har varit ok. Högre kvalité än vad 
som är normalt från genomsnittsanvändaren tycker jag.

Jag ställde en fråga och fick bra respons i detta changeset.
https://www.openstreetmap.org/changeset/84314486
Jag kanske tycker att man överdrivit användandet av isolated_dwelling. T.ex. 
kanske det inte ska sitta på en fäbod där ingen bor.
Men generellt tycker jag att OSM är bättre med, än utan, dessa ändringar.

Så ingen revert om jag får rösta.

Sen är det skumt att det dyker upp en massa konton som gör samma sak utan någon 
information om varför och vem som samordnar m.m.
Men det handlar väl egentligen mer om nyfikenhet än något rent praktiskt att ta 
reda på mer om det.


/Anders Andersson

Från: Andreas Vilén 
Skickat: den 16 maj 2020 17:18
Till: OpenStreetMap Sverige mailinglista 
Ämne: Re: [Talk-se] Problem med ortnamnsimporten

Jag har skickat ut ett osm-meddelande till alla dessa användare och bett dem 
uppmärksamma denna diskussion. Har också bett dem om mer info om hur 
ändringarna genomförts.

Har skrivit både på svenska och engelska då åtminstone ett konto verkar vara 
ryskt: https://www.openstreetmap.org/user/30d4f4e1ccf24

MVH Andreas

On Sat, May 16, 2020 at 5:04 PM Andreas Vilén 
mailto:andreas.vi...@gmail.com>> wrote:
Går man till  https://osmstats.neis-one.org/?item=countries=Sweden och 
sorterar efter "created names" får man upp alla konton högst upp i listan. Lätt 
att ta ut för en rapport till DWG.

MVH Andreas

On Sat, May 16, 2020 at 4:58 PM Andreas Vilén 
mailto:andreas.vi...@gmail.com>> wrote:
Hej!

Jag och Essin har diskuterat detta lite under den senaste veckan och jag har 
också tittat på datan här och där. För det mesta ser den väl hyfsad ut på det 
sättet att den lyckats med att kopiera av (ja, vilken källa egentligen, se 
längre ner) rätt så slaviskt (som jag förstått det). Däremot, i tråden som 
föranledde den här importen, varnade jag vid flera tillfällen för att datan 
inte är bra nog för att importera till OSM rakt av, delvis för att den inte 
visar den typ av data som importörerna trodde. Se tråden som Essin länkar till. 
Exempelvis verkar källan ha kopierat Ekonomiska kartan, vilket lett till att 
platser dubblerats vid kartbladsbyten i Ekonomiska kartan, bara för att ta ett 
exempel. Att importera data som en gång redan importerats från en annan databas 
är skit in skit ut skit in skit ut.

Se mina inlägg 
https://lists.openstreetmap.org/pipermail/talk-se/2020-January/003791.html 
https://lists.openstreetmap.org/pipermail/talk-se/2020-January/003793.html 
https://lists.openstreetmap.org/pipermail/talk-se/2020-January/003797.html

Ännu ett konto som verkar ha bidragit till importen, men grupperat sina edits 
lite bättre, är https://www.openstreetmap.org/user/operaman/history.

De invändningar jag hade verkar dessa konton inte ha tagit till sig av. 
Åtminstone är det väldigt svårt att avgöra när datan är så svår att analysera. 
Jag tycker också det är problematiskt att ett antal nya konton utan koppling 
till ordinarie användare på OSM plötsligt dyker upp för att genomföra en import 
som denna. Om det handlar om användare som den som skapade wikisidan 
rekryterat, bör han ha varit öppen med detta och uppmanat dem att skriva något 
på sina användarsidor.

Jag tycker definitivt att detta ska tas till DWG för revert. Vill man titta på 
kartan som importerats kan man titta på den. Jag ser ingen anledning att 
okritiskt importera data från den källan (eller någon annan källa) till OSM.

MVH Andreas

PS: En cliffhanger från högre upp, vilken källa har egentligen använts? Den 
tråd som Essin länkar till, och även importsidan på wikin, handlar om 
Terrängkartan, men i kontonas källhänvisning står det Topografiska kartan.

On Sat, May 16, 2020 at 3:39 PM Ture Pålsson via Talk-se 
mailto:talk-se@openstreetmap.org>> wrote:
Gah, tusentals changesets med en nod per changeset. Och användaren tomas471 har 
en avatar som föreställer Bob Ross.

Är det någon idé att dra in DWG så här långt efteråt? Det är ju frestande att 
säga ”reverta allt av de här användarna” bara för att importen är så illa 
genomförd, även om datat i sig är ok (jag har inte tittat så noga).


16 maj 2020 kl. 12:39 skrev Essin 
mailto:user.es...@gmail.com>>:

Hej!

För några dagar sedan började jag lägga märke till redigeringar som bara bestod 
av place-noder [1]. Efter ett tag insåg jag att de är en del av importen som 
diskuterades här i vintras [2]. Utifrån redigeringarna verkar det som att de är 
gjorda utan större hänsyn till vad som redan finns och utan större kontroll av 
den valda place-taggens rimlighet (place=isolated_dwelling på bondgårdar som 
ligger inne i byar och därför borde ha place=farm eller namnet på en 
landuse=farmyard-yta, dubbletter med befintliga landuse=farmyard- eller 
landuse=residential-objekt, place=hamlet som borde vara place=neighbourhood 
mm). Jag har letat, men 

Re: [Talk-se] Apropå svenska naturreservat i OSM

2020-03-20 Thread Micke
Hej!

Jag håller med om problembeskrivningen.
Det är svårt att hålla uppdaterat, det ändras ibland  av nybörjare som t.ex. 
kopplar skoterleder till gränserna.

Men det är ändå väldigt användbart. Allt på ett ställe är viktigt. Det är inte 
sämre uppdaterat än övriga features i OSM. Dessutom brukar dom , i alla fall i 
Sverige, vara utmärkta med målade ”blommor” på träd och/eller skyltar. Så nog 
vore det möjligt att kontrollera på marken. Men det är ju myndigheternas data 
som är de officiella koordinaterna. Administrativa gränser är ju en av de 
viktigare informationerna på en karta.

Tills det finns en färdig lösning som automatuppdateras (och kan läggas in på 
den karta man önskar med ett enkelt klick) så tycker jag att det är bättre att, 
så gott det går, vårda NR inom OSM:s data som idag.
Det kanske skulle gå att göra en årlig import som lägger till nya svenska NR. 
Det kanske går att göra något script som körs på OSM.se som jämför gamla och 
nya NR och någon person sen bara laddar upp en färdig fil till databasen.


/Anders Andersson

Från: pang...@riseup.net 
Skickat: den 20 mars 2020 10:42
Till: talk-se@openstreetmap.org
Ämne: [Talk-se] Apropå svenska naturreservat i OSM

Hej på er.

Är det nån här som håller med Tobias?

Finns det konsensus för att radera våra undermåliga naturreservat och i stället 
skapa et centralt ställe där det beskrivs hur datat från NV kan läggas till en 
karta?

Problemet med detta som jag ser det är att vi tappar kopplingen till tex 
wikidata (WD). Dock går det ju att lägga till alla naturreservat i WD med ett 
NV namn id som man kan slå upp på i stället för ett Qid från en OSM etikett. WD 
är mycket lättare att uppdatera eftersom datan förändras än OSM objekt som inte 
meningsfullt kan observeras på marken eftersom dem definieras av människor 
genom en rättsprocess och gränserna märks sällan ut ordentligt tex vid 
vattenskyddsområden.

Några andra nackdelar?

Detta frigör kraft till annat, tex mera kärlek till vandringsleder som helt än 
inte finns i ett auktoritativt statligt dataset. Vandringsleder är också 
synliga via skylter, m.m. och mera komplexa än Naturreservat pga etapper, länk 
till externa webbsidor och kartor. Detta data skulle iofs lika väl kunna sparas 
i Wikidata också och dras in på kartan. I dagsläget finns redan vandringsleder 
på WD, men många tex på Kungsleden https://www.wikidata.org/wiki/Q59780 saknar 
etapper.

Mvh
pangoSE

From: Tobias Knerr mailto:o...@tobias-knerr.de>>
Sent: March 19, 2020 7:44:34 PM GMT+01:00
To: t...@openstreetmap.org
Subject: Re: [OSM-talk] OSM is not the place for dissemination of authoritative 
data sets


On 19.03.20 17:54, Jóhannes Birgir Jensson wrote:

So - why are authoritative data sets an unwelcome addition?

At its core, OSM is a platform for collaboratively editing geodata. So
the following would be strong reasons not to import a dataset:

- other mappers should not edit it (because the dataset is the official
source and changing it would just make it wrong)
- other mappers cannot meaningfully edit it (because we cannot see the
object in the real world and don't have access to useful sources).

The way you describe it, collaborative editing doesn't seem to be a net
benefit to your scenario, and in fact makes it harder to sync updates
with the authoritative source.

So as a thought experiment: Why not just convert your dataset to the OSM
format to make it compatible with the OSM ecosystem, but skip the import
into the main OSM database?

In practice, I guess part of the answer for that is discoverability: Who
wants to hunt down datasets scattered across various servers and
portals? So it's tempting to put it all into a single big database. And
I guess that's ok as long as it doesn't get in the way of the main
purpose of that database too much – which is collaborative editing, not
data distribution. But surely, with a decent implementation of
compatible data layers tracked in some central repository, authoritative
data could be used *with* OSM without being *in* OSM.

Tobias



talk mailing list
t...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se


Re: [Talk-se] Ortnamnsimport från Lantmäteriets GSD-Terrängkartan

2020-01-17 Thread Micke via Talk-se
Hej!

För herrgårdar kanske man kan passa på att lägga till historic=manor samtidigt.
Det finns nog en del sådana herrgårdar inlagda redan. Men då ligger nog taggen 
på huset eller på gården, inte på en nod. Bara så att det inte blir dubbletter 
där.

Vi har ju även en hel del ställen som har ett namn, men där det är ödehus eller 
sommarstugor eller fäbodar. Dessa borde även de klassas som locality.

Stadsdelar bör väl inte vara hamlet, utan neighbourhood?


Mvh

Anders Andersson

Från: Grigory Rechistov 
Skickat: den 16 januari 2020 18:19
Till: talk-se 
Ämne: [Talk-se] Ortnamnsimport från Lantmäteriets GSD-Terrängkartan

Hej!
Jag har extraherat de ortnamn som nu saknas på Sveriges OSM-karta ifrån 
Lantmäteriets öppna data, daterade januari 2020. Det finns ungefär 95 tusen nya 
noder med namn och "place=*"-etiketter vilka jag så småningom hoppas ladda upp 
till OSM.

En såpass stor mängd nya data kräver att man följer vissa procedurer och 
förbereder vissa dokument. Jag hoppas att få er feedback och eventuell hjälp 
med valideringen, uppladdningen och med andra eventuella uppdrag.

Här finns importplan för projektet [1] på OSM-wikin. Den beskriver 
informationens härkomst, licens och format. Sedan beskriver jag hur de 
ursprungliga filerna bearbetas, hur nya punkter filtreras mot den befintliga 
OSM-databasen, hur ortnamn rensas och jämföras, vilka skript och program 
används vid alla steg osv. Till sist uppger jag vilka problem kvarstår att lösa 
under manuell bearbetning.

Importplanens bitar med viktigaste sektioner bifogar jag längst ner. Här är 
också en mindre bit av hela datasetet om du vill se hur det ska se ut: [2] [3]. 
Andra länkar till Lantmäteriets dokumentation, mina utvecklade skript, samtliga 
OSM-filer, kalkylblad osv finns på importplanens sida.

Tack!

[1] 
https://wiki.openstreetmap.org/wiki/Import/Catalogue/Lantm%C3%A4teriet_GSD-Terr%C3%A4ngkartans_ortnamnsimport
[2] https://drive.google.com/open?id=1np1TEDlEBWx1kt-u7A4Z_ZpkMOwOp80l
[3] https://drive.google.com/open?id=1pERx-U4rdOjhXmePoSxcbKRZsr-preh8

Importplanens utdrag följer.

===Goal===
To improve OSM completeness for toponymical dataset on territory Sweden using
an official map supplied by Swedish mapping, cadastral and land registration 
authority.
This import considers OSM data representable as nodes tagged with usual
key/value pairs: "place=city", "place=town", "place=village", "place=hamlet",
"place=isolated_dwelling", and "place=locality". However, it is not planned
(but not fully excluded either) to add/modify any nodes with "city" and "town"
values. They are expected to be already fully mapped.

 Data processing diagram 
See the diagram below. The conflation stage is described later in more details.
+---++--+
|   ||  |
|Lantmäteriet's SHP ||Geofabrik country |
|files  ||extract   |
|   ||  |
+-+-+++-+
  |   |
  |ogr2osm|osmconvert
  |   |osmfilter
  v   v
 ++-+ +---+-+
 |  | | |
 |OSM file with | |OSM fiele with   |
 |settlements   | |settlements  |
 |  | | |
 +-++ +---+-+
   |  |
   |  |
   | conflate-places.py   |
   +<--
   v
  +++
  | |
  |OSM file with|
  |only ready nodes |
  | |
  +++
   |
   | Manual corrections
   |
   v
Upload to JOSM


The employed algorithm operates on a set of old nodes marked with "place=*"
(from the OSM-extract, around 68 000 nodes for the country) and new nodes
(from SHP-extract). It produces ready nodes — a strict subset of new nodes.
No old nodes are modified in any way during the process. This means that 
existing
data has absolute priority, even in cases it is likely of lower quality than
new data.
The sequence of steps is as following.
1. Create a spatial index structure with old nodes to have fast spatial lookup.
2. For all new nodes validation/correction of the "name" tag is performed.
3. For each new node, find old nodes close enough to it to be candidate for 
duplicates.
4. For each candidate node, compare its name against the current new node name.
   Comparison is fuzzy to allow for some text variation typical for names.
   Alternative old names are also checked if present.
5. If a name match is found, the current new node is marked as "duplicate" and
   is excluded from further analysis and results.
6. An OSM file with ready data is generated.
7. The OSM file is 

Re: [Talk-se] Changeset 69441387

2019-04-24 Thread Micke
Hej Grigory!

Vad hände med befintliga skogsområdet 
https://www.openstreetmap.org/way/194522135/history

I övrigt tycker jag Vingåker ser bra ut.


Mvh

AndersAndersson

Från: Grigory Rechistov 
Skickat: den 24 april 2019 07:32
Till: OpenStreetMap Sverige mailinglista 
Ämne: Re: [Talk-se] Changeset 69441387

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 conflation-tiden är det omöjligt 
att undvika manuellt arbete för sådana areor, tyvärr. Jag har ideér för att 
förbättra mitt conflation.py skript så att mindre manuellt arbete skulle 
krävas, tills dess vänta med redigeringen om ni tycker att det vore för 
jobbigt. Och det lär vara jobbigt för större kommunen, men helt möjligt för 
lagom stora kommuner.

Just nu behöver jag svara på imports@osm:s diskussion också. Återkommer med 
dagens läge i den NMD-data mejtråden.

Вторник, 23 апреля 2019, 0:05 +03:00 от egil 
mailto:e...@riseup.net>>:
Tack för heads up här.

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)
som redan täcker 95% av all skog i kommunen och bara ta scrub och annat med.

Återstår att se om detta resterande går lätt att importera

On 2019-04-22 09:57, Snusmumriken wrote:
> Hej listan
>
> Jag tog och reverterade importen som gjordes i morse
> https://www.openstreetmap.org/changeset/69441387
>
> Orsaken var de omfattande konflikter som uppstod med befintlig data.
>
>
> ___
> 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


С наилучшими пожеланиями,
Григорий Речистов.
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


Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData

2019-04-09 Thread Micke
Hej!

Hur många överlappande polygoner blir det i en kommun?

Är det enklare och säkrare om dessa hanteras av en människa som tar beslut om 
vilken polygon som är bäst? Förutsatt att det inte blir för stor mängd så 
tycker jag det låter säkrare. Det är lätt att missa något scenario man inte 
tänkt 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 idén. Beskrivningen nedan 
finns  även i importplanen.

It's algorithm is roughly as follows.

  1.  Detect real and potential intersections between "new" polygons and "old" 
polygons.
  2.  For each pair of detected polygons, an automatic decision which polygon 
to keep is made.
 *   Criteria for this decision: number of nodes in a way, area covered by 
the polygon, tags used on the polygon etc. Generally, priority is given to an 
already existing polygon.
 *   If no good automatic decision can be made for a pair, keep both ways 
but mark the polygons with a special tag requesting human attention to solving 
conflict between them before uploading.
  3.  Delete one of two polygons in every conflicting pair, or keep both 
(tagged for future manual resolution)

The strategy here is to prevent leaving undetected overlapping closed ways (new 
and old ones) at all costs, even if it means deleting some of new data and 
leaving some of earth surface, previously not mapped, still not mapped by new 
polygons. Value of individual conflicting polygons is estimated before deciding 
which one of two to keep.

The proposed conflation strategy is meant to be faster than existing algorithms 
that try to merge geometries of polygons and have to deal with complexity of 
multipolygons. It allows for false negatives (removing new objects that could 
have otherwise bear useful value on the map) as a trade-off for speed and 
simplicity.

Vad tycker ni?

På tal om importplanen finns nu den på följande länken: 
https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/NMD_2018_Import_Plan . 
Er feedback behövs för den, för att jag vill snart kontakta 
impo...@openstreetmap.org med den planen och 
tillkännage NMD-dataimporten för att få tillstånd för den.


Понедельник, 8 апреля 2019, 14:42 +03:00 от Grigory Rechistov 
:

[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 problem som redan 
finns i databasen: https://atakua.org/p/nmd/vingaker-merged.png . Men nu 
uppstår ärendet med sammanblandning på gamla och nya data, conflation. Om man 
ser på kartans nordöstliga hörn (nära Äsköping) finns det en tidigare befintlig 
jättemultipolygon. Den täcker delvis eller helt de nya mindre skogspolygonerna. 
Jag hoppades att det skulle meddelas av JOSM som en varning, men det blev det 
inte. Tydligen förekommer fler sådana konflikter på den kartan, men det är 
svårt att hitta dem med ögonen. Ett programverktyg behövs.

Det finns några sidor gällande conflation på OSM-wikin, men än så länge hittar 
jag främst information om hur man blandar samman icke-förslutna vägar (t ex 
gator) eller enkla noder, inte stängda vägar det vill säga ytor.

Jag har några idéer om hur man kan närma sig till lösningen, åtminstone hur man 
kan upptäcka polygoner som kräver uppmärksamhet.
Om det finns personer med erfarenhet på conflation vore jag mycket tacksam att 
man hjälper till. Dina kommentarer och tankar är mycket välkomna!

Arkivet med mitt lager, OSM-lagret och dess kombination som OSM XML filar: 
https://atakua.org/p/nmd/vingaker-conflation.tar.bz2


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


Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData

2019-04-04 Thread Micke
Angående polygoners storlek så var det precis det jag menade. För stora är inte 
bra och för små kan också bli lite jobbigt. Optimala storleken för 
skogspolygoner är ju att det inte är en massa onödiga streck i vägen där man 
editerar, men att ändå ytterpolygonen finns i närheten utan att man behöver 
zooma och panorera jättemycket för att hitta den.

Polygoner med lövtyp bör inte bli speciellt små. Kanske att man får splitta 
några av de största.


/Anders Andersson


Från: Ture Pålsson 
Skickat: den 4 april 2019 12:55
Till: OpenStreetMap Sverige 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.
>

+1!

>
> Områden med stora polygoner är svårare att jobba med än områden med
> flera små (så länge det inte blir överdrivet smått).

Fast *för* stort är inte heller så lättarbetat... 70 km breda
multipolygoner som https://www.openstreetmap.org/relation/1901035 blir
nog ingen glad av. =)


___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se


Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData

2019-04-04 Thread 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.

Områden med stora polygoner är svårare att jobba med än områden med flera små 
(så länge det inte blir överdrivet smått).

Jag är gärna med och hjälper till när detta ska implementeras, men fram tills 
dess nöjer jag mig med glada tillrop över ert arbete med datakonverteringen.


Mvh

Anders Andersson


Från: Christian Asker 
Skickat: den 3 april 2019 22:39
Till: Grigory Rechistov; 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 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. Noggrannheten är nog 
inte sämre än vad som kan åstadkommas med andra metoder.

Mvh Christian




Grigory Rechistov via Talk-se  skrev: (3 april 2019 
22:22:14 CEST)
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ö (https://osm.org/go/0aUFbLO0-?m=) ser ut: 
https://atakua.org/nc/index.php/s/2kiEafMdYGQDyk6 
 . Någorlunda 
bättre men visst inte perfekt.

Nu kämpar jag med flera mindre irriterande problem såsom:
1. Att filtrera mindre krafspolygoner. gdal_sieve förvandlar den ursprungliga 
TIFF-filen till svartvitt, av någon anledning

2. Att komma runt buggar i GeoJSON import 
(https://github.com/JOSM/geojson/issues/29#issuecomment-479502069). Det saknas 
också "type=multipolygon" taggen efter importen.

Det verkar att jag verkligen vill slå samman olika typer skogar för att minska 
det brus de skapar. Då behöver ja ett kommandoradsverktyg eller en QGIS-plugin 
som kan redigera raster och slå olika pixelfärger till en färg.


Med vänliga hälsningar,
Grigory Rechistov
With best regards,
Grigory Rechistov

--
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


Re: [Talk-se] Kartan på https://www.openstreetmap.org/ har inte uppdateras på ett tag

2019-02-11 Thread Micke
Samma för mig. Igår tror jag det började att fungera som vanligt.

Lite underligt tycker jag dock att det var. Style changes har vi haft förut 
utan att det märkts alls på snabbheten. Detta höll i sig nästan en månad.

Från: Karl-Johan Karlsson 
Skickat: den 10 februari 2019 22:04
Till: OpenStreetMap Sverige mailinglista 
Ämne: Re: [Talk-se] Kartan på https://www.openstreetmap.org/ har inte 
uppdateras på ett tag

Nu tycker jag att de problem jag upplevde när jag startade den här tråden är 
lösta. Jag ser uppdateringar som jag gör relativt snabb och tiles på mer 
utzoomade nivåer uppdateras precis som innan.

Den lör 2 feb. 2019 kl 10:23 skrev NKA mapper 
mailto:nkamap...@gmail.com>>:
Rapporter gjerne dine observasjoner her:
https://github.com/openstreetmap/operations/issues/268


Den lør. 2. feb. 2019 kl. 09:36 skrev Christian Asker 
mailto:christian.as...@gmail.com>>:

Jag kan ju ha fel, men jag har upplevt att tiles från OSM laddas långsamt sedan 
någon dryg vecka.  Det har hänt både hemma och på jobbet (där jag har 
supersnabb lina). Men det kanske är något annat eller bara något temporärt 
problem.

Men ifall det är något problem borde det väl finnas dokumenterat någonstans?



Mvh Christian




Den 2019-02-02 kl. 09:22, skrev Karl-Johan Karlsson:
Jag ser bara mina ändringar på de 2 mest inzoomade "Zoom levels" (nivå 18 och 
19). Tidigare har jag för mig att jag kunde se mina ändringar i princip 
omgående på ett par nivåer högre (mer utzoomade) om jag bara gjorde 
shift-reload i Firefox så att tiles laddas om. Så, det behöver inte betyda att 
det är något fel utan kanske bara att de ändrat hur ofta tiles på mer utzoomade 
nivåer renderas om.



Den fre 1 feb. 2019 kl 21:10 skrev Micke 
mailto:mia...@hotmail.com>>:
Jag ritade lite skog för en vecka sen ungefär och bara delar av den syns än, 
trots att jag under flera dagar markerat den som "dirty" på 
https://www.sammyshp.de/fsmap/#17/60.65902/15.20492
Annars brukar det gå på under en minut när man gör det.

Så något fel är det.


/AndersAndersson

-Ursprungligt meddelande-
Från: Andreas Vilén mailto:andreas.vi...@gmail.com>>
Skickat: den 31 januari 2019 22:35
Till: OpenStreetMap Sverige mailinglista 
mailto:talk-se@openstreetmap.org>>
Ämne: Re: [Talk-se] Kartan på https://www.openstreetmap.org/ har inte 
uppdateras på ett tag

Jag har sett uppdateringar utan problem, däremot kan det ta längre tid i 
områden med många mappade objekt. Tror inte detta är ett problem för då hade 
nog någon tagit upp det i den internationella maillistan redan.

/Andreas

Skickat från min iPhone

> 30 jan. 2019 kl. 09:39 skrev Aron Bergman 
> mailto:bathing...@gmail.com>>:
>
> Jaha, så era uppdateringar har inte ens nått databasen?
>
> / Aron Bergman
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org<mailto:Talk-se@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-se


___
Talk-se mailing list
Talk-se@openstreetmap.org<mailto:Talk-se@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-se


___

Talk-se mailing list

Talk-se@openstreetmap.org<mailto:Talk-se@openstreetmap.org>

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


Re: [Talk-se] Kartan på https://www.openstreetmap.org/ har inte uppdateras på ett tag

2019-02-01 Thread Micke
Jag ritade lite skog för en vecka sen ungefär och bara delar av den syns än, 
trots att jag under flera dagar markerat den som "dirty" på 
https://www.sammyshp.de/fsmap/#17/60.65902/15.20492
Annars brukar det gå på under en minut när man gör det.

Så något fel är det.


/AndersAndersson

-Ursprungligt meddelande-
Från: Andreas Vilén  
Skickat: den 31 januari 2019 22:35
Till: OpenStreetMap Sverige mailinglista 
Ämne: Re: [Talk-se] Kartan på https://www.openstreetmap.org/ har inte 
uppdateras på ett tag

Jag har sett uppdateringar utan problem, däremot kan det ta längre tid i 
områden med många mappade objekt. Tror inte detta är ett problem för då hade 
nog någon tagit upp det i den internationella maillistan redan.

/Andreas

Skickat från min iPhone

> 30 jan. 2019 kl. 09:39 skrev Aron Bergman :
> 
> Jaha, så era uppdateringar har inte ens nått databasen?
> 
> / Aron Bergman
> ___
> 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


Re: [Talk-se] Trying to locate actual fire locations for mapping projects

2018-07-26 Thread Micke
The fire SW and S of Sveg seem to be managed now. No flames according to this 
map.
https://kartor.skogsstyrelsen.se/kartorapp/?startapp=skogligagrunddata

I mapped a lot of roads at Älvdalens skjutfält/Trängslet before I started the 
HOT-work E of Sveg. There are however a lot left to map at Trängslet.
The area S of Sveg was already well mapped by a tourist a year ago, so I only 
needed to add a couple of small lakes.

SW of Sveg I don’t know, but there are no flames there.

But I think we could use a combined effort at Trängslet (If the Polish 
firefighters are going there).


Regards

AndersAndersson


-Ursprungligt meddelande-
Från: Karl Wettin  
Skickat: den 26 juli 2018 05:15
Till: OpenStreetMap Sverige mailinglista 
Ämne: Re: [Talk-se] Trying to locate actual fire locations for mapping projects

I think I have figured it out!

Interview from yesterday with the Polish lead on site in Sveg:

https://www.youtube.com/watch?v=NHPUYdkyfjY=youtu.be=141

Paraphrased:

"
We are working on two sites that are 20km, more or less, from our base of 
operations.

On the first site we are replacing the Swedish firefighters.

We are trying to control the fire in a close proximity of the bigger fire which 
is south west of Sveg.
"

So, the second site is the one SW of Sveg at Älvdalens skjutfält.
There are however three larger fires in that area according to  VIIRS.

"In proximity of the bigger fire", does that mean around the larger fire, or 
does it mean a smaller fire close to the larger fire?

There is a smaller fire around 61.60, 13.50.
There is a larger fire at around 61.64, 13.57.

The third one, at least as large as the large one mentiond above is, if I 
figured it out right, the one located within the area they withdrew all 
firefighters from as it's a military training ground with risks of explosion. 
The one they bombed with fighter jets yesterday.



kalle

2018-07-26 0:40 GMT+02:00 Karl Wettin :
>
> The press contact is open 24/7, so I called them.
>
> MSB knows nothing more than that they are placed in Gävleborg and Jämtlands 
> län. It is up to each län to decide where they will be deployed. Our best 
> shot is probably getting a hold of someone in the actual team of firefighters 
> that can let us know when and where they are deployed.
>
>
> kalle
>
> 2018-07-26 0:25 GMT+02:00 Karl Wettin :
>>
>> +1
>>
>> I’ll try to get in touch the MSB press contact tomorrow (the least invasive 
>> point of contact I can think of) to see if they have any information 
>> regarding the whereabout of the polish brigades.
>>
>> 25 juli 2018 kl. 22:06 skrev Christoffer Holmstedt 
>> :
>>
>>> The new project 4912 covers the other project's area is this wise?
>>>
>>> I think it would be more wise to cover the areas south and south west of 
>>> Sveg but do _not_ include "Älvdalens Skjutfält"/Trängslet [3] as there are 
>>> undetonated ammunition in that area so no firefighters are allowed to go in 
>>> there. One or more HOT OSM project(s) covering Strandasmyrvallen [1] and 
>>> Lillhärdal [2] would be my best suggestions for mapping efforts without any 
>>> proper communication with the Polish firefighters.
>>>
>>> [1] 
>>> http://emergency.copernicus.eu/mapping/ems-product-component/EMSR298
>>> _05STRANDASMYRVALLEN_01DELINEATION_MONIT01/2
>>> [2] 
>>> http://emergency.copernicus.eu/mapping/ems-product-component/EMSR298
>>> _04LILLHARDAL_01DELINEATION_MAP/1 [3] 
>>> http://emergency.copernicus.eu/mapping/ems-product-component/EMSR298
>>> _03TRANGSLET_01DELINEATION_MONIT01/1
>>> --
>>> Christoffer Holmstedt
>>>
>>> 2018-07-25 21:49 GMT+02:00 Blake Girardot :

 Greetings,

 I created a 2nd project for the area SE of Sveg (I left out the SW 
 area based on Mattias's comments)

 https://tasks.hotosm.org/contribute?difficulty=ALL=OSM
 -SE

 Respectfully,
 blake

 On Wed, Jul 25, 2018 at 8:52 PM, Mattias Lindblad  wrote:
 > Unfortunately that map marks everything, from small 
 > wastebasket-fires that are already extinguished to huge  wildfires.
 >
 > http://effis.jrc.ec.europa.eu/static/effis_current_situation/publ
 > ic/index.html is a bit less detailed, but can be zoomed and use 
 > an OSM layer.
 >
 > The area that Blake referred to as being SW of Sveg is probably 
 > the fire in the military area Trängslet, which is very 
 > problematic in many aspects. I would think that the Polish force is not 
 > deployed there.
 >
 > /Mattias
 >
 > ons 25 juli 2018 kl. 20:40 skrev Björn Stenberg :
 >>
 >> SOS Alarm keeps an updated map here:
 >> https://www.sosalarm.se/lagesbild-brand
 >>
 >> This map is referred to by government agency sites so it is 
 >> probably the best publicly available. Unfortunately it is rather 
 >> zoomed out so I'm not sure it is good enough for our purpose.
 >>
 >> --
 >> Björn
 >> On 25 July 2018 8:24:05 pm Blake Girardot  wrote:
 >>
 >> 

Re: [Talk-se] Trying to locate actual fire locations for mapping projects

2018-07-25 Thread Micke
Hello,



That is the same area as the already existing HOT project.



I think this link is good to see the fires. I didn't see anyone mention it.

https://kartor.skogsstyrelsen.se/kartorapp/?startapp=skogligagrunddata



The fire near "Österdalälven and "Skjufält" is the military shooting area, 
"Trängslet".



There seem to be 4 fires close to Sveg and Ljusdal. I guess the two largest are 
of most interest. The one closest to Ljusdal already has and active HOT project.

https://tasks.hotosm.org/project/4904





I hope this was helpful, not making things more complicated. 





Regards



AndersAndersson





-Ursprungligt meddelande-
Från: Blake Girardot 
Skickat: den 25 juli 2018 21:49
Till: OpenStreetMap Sverige mailinglista 
Ämne: Re: [Talk-se] Trying to locate actual fire locations for mapping projects



Greetings,



I created a 2nd project for the area SE of Sveg (I left out the SW area based 
on Mattias's comments)



https://tasks.hotosm.org/contribute?difficulty=ALL=OSM-SE



Respectfully,

blake



On Wed, Jul 25, 2018 at 8:52 PM, Mattias Lindblad 
mailto:o...@matli.net>> wrote:

> Unfortunately that map marks everything, from small wastebasket-fires

> that are already extinguished to huge  wildfires.

>

> http://effis.jrc.ec.europa.eu/static/effis_current_situation/public/in

> dex.html is a bit less detailed, but can be zoomed and use an OSM

> layer.

>

> The area that Blake referred to as being SW of Sveg is probably the

> fire in the military area Trängslet, which is very problematic in many

> aspects. I would think that the Polish force is not deployed there.

>

> /Mattias

>

> ons 25 juli 2018 kl. 20:40 skrev Björn Stenberg 
> mailto:bj...@haxx.se>>:

>>

>> SOS Alarm keeps an updated map here:

>> https://www.sosalarm.se/lagesbild-brand

>>

>> This map is referred to by government agency sites so it is probably

>> the best publicly available. Unfortunately it is rather zoomed out so

>> I'm not sure it is good enough for our purpose.

>>

>> --

>> Björn

>> On 25 July 2018 8:24:05 pm Blake Girardot 
>> mailto:bgirar...@gmail.com>> wrote:

>>

>> > whoops I spoke to soon, that is very similar to the web map service

>> > for modis viiris data.

>> >

>> > ( Still very glad to have it as a wms rather than a web map )

>> >

>> > I do not see any hot spots near Sveg.

>> >

>> > I was hoping Swedish new reports might help locate the actual fire

>> > sites.

>> >

>> >

>> >

>> > On Wed, Jul 25, 2018 at 8:05 PM, NKA mapper 
>> > mailto:nkamap...@gmail.com>> wrote:

>> >> This WMS will show the actual fire areas:

>> >>

>> >> https://firms.modaps.eosdis.nasa.gov/wms/?FORMAT=image/PNG

>> >> =1.1.1=WMS=GetMap=fires_modis_7,fires_viirs

>> >> _7=={proj}={width}={height}={bbox}

>> >>

>> >>

>> >> Den ons. 25. jul. 2018 kl. 18:42 skrev Blake Girardot

>> >> mailto:bgirar...@gmail.com>>:

>> >>>

>> >>> Hi all,

>> >>>

>> >>> Can someone help me locate the actual locations of the fires for

>> >>> these two general areas?

>> >>>

>> >>> the polish crew will be placed in Ljusdalen and the other half

>> >>> around Sveg

>> >>>

>> >>> I can not locate the actual fire locations around those two areas.

>> >>>

>> >>> Could someone locate those fire areas and send me a geojson or

>> >>> .osm file so I can create projects around them please?

>> >>>

>> >>> Respectfully,

>> >>> blake

>> >>>

>> >>>

>> >>>

>> >>> --

>> >>> 

>> >>> Blake Girardot

>> >>> OSM Wiki - https://wiki.openstreetmap.org/wiki/User:Bgirardot

>> >>> HOTOSM Member - https://hotosm.org/users/blake_girardot

>> >>> skype: jblakegirardot

>> >>>

>> >>> ___

>> >>> 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

>> >>

>> >

>> >

>> >

>> > --

>> > 

>> > Blake Girardot

>> > OSM Wiki - https://wiki.openstreetmap.org/wiki/User:Bgirardot

>> > HOTOSM Member - https://hotosm.org/users/blake_girardot

>> > skype: jblakegirardot

>> >

>> > ___

>> > 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

>

>

> ___

> Talk-se mailing list

> Talk-se@openstreetmap.org

> https://lists.openstreetmap.org/listinfo/talk-se

>








Re: [Talk-se] Bing kalibrering

2018-06-25 Thread Micke
Flygbilder är väldigt användbart. Men ett av de vanligaste nybörjarmisstagen är 
att flytta vägar efter flygbilder, som i bergiga områden oftast ligger väldigt 
fel. Så någon sorts varningsruta tycker jag vore en bra idé. Det finns en sådan 
i Potlatch 2 när man raderar data.

/Anders

Från: Andreas Vilén 
Skickat: den 24 juni 2018 16:53
Till: OpenStreetMap Sverige mailinglista 
Ämne: Re: [Talk-se] Bing kalibrering

Flygbilderna är ett hjälpmedel, som allt annat. Problem med offset är något som 
kommer med alla former av flygbilder, oavsett källa. Vill man inte mappa efter 
fel, får man justera bilderna. Det går att göra även med id. Att ta bort en 
resurs för samtliga, för att ett fåtal inte kan använda den på rätt sätt, är en 
väldigt dålig idé.

När jag började med osm hade vi inga flygbilder utan fick kolla allt på plats. 
Att ta gps-spår själv är också fortsatt det bästa sättet att kalibrera 
flygbilderna.

/Andreas, som uttrycker sig något rakare än han tänkt men som blir något 
ofrivilligt kränkt av snack om att ta bort den bästa resurs osm någonsin 
förlänats för att ett fåtal inte kan använda den på rätt sätt.

Skickat från min iPhone

23 juni 2018 kl. 00:45 skrev M Branting 
mailto:mikael.brant...@gmail.com>>:
Tja, bara en del av brukarna använder Josm. Använder man webbgränssnittet för 
redigering, så ligger satellitbilderna på plats, och tillhör så att säga 
programmet. Varför skulle en oerfaren användare över huvud taget tro att 
satellitbilden är fel. Man kan ju lika gärna tro att vägar, stigar och annat 
ligger slarvigt inlagda. Det är nog överoptimistiskt att tro att "varje 
mappare" ska kalibrera centralt inlagda satellitbilder. Om det är just Bing som 
brukar orsaka problem, så kanske man skulle ta bort detta alternativ helt.
Men det betyder inte att det finns någon central resurs som löser problemet - 
vad vi får är felaktigt inlagd information när folk använder dåligt kalibrerade 
bilder som underlag.

Den 23 juni 2018 00:31 skrev Andreas Vilén 
mailto:andreas.vi...@gmail.com>>:
Hej!

Detta är ingenting som går att ändra på centralt och det är vanligare att 
bilderna ligger lite fel än att de inte gör det. Det är varje mappares ansvar 
att själva se till att kalibrera bilderna efter verkligheten.

Använder man josm kan man lagra ett offset på servern som andra sedan kan 
använda men det bygger på att andra laddar ner detta offset.

/Andreas
Skickat från min iPhone

22 juni 2018 kl. 20:32 skrev M Branting 
mailto:mikael.brant...@gmail.com>>:
Hej
I Gnestatraktem i Södermanland, och kanske på andra ställen också verkar Bing 
bakgrundsfoto felkalibrerat. De inlagda vägarna stämmer inte med vägnätet på 
bilden, och gps spår verkar mer överensstämma med de ilagda vägarna än med 
bakgrundsbilden.

Exempel: https://www.openstreetmap.org/edit#map=16/59.0463/17.1589 Notera också 
att andra satellitbildsalternativ inte har detta fel.

Vore tacksam om något kartproffs i mailinglistan tog sig en titt och räåttade 
till felet. Görs inget finns risken att folk lägger inte saker i kartan på 
basis av bing, och då får vi en blandning av riktiga och felaktiga positioner.
___
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

___
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


Re: [Talk-se] Naturreservat

2017-05-22 Thread Micke
Jag såg att T-udden i Gävle saknades. Är inte det ett naturreservat? Har för 
mig jag sett sådana skyltar när jag varit där.


Jag har manuellt lagt till saker i vissa naturreservat. T.ex. snowmobile=no där 
det gäller i hela reservatet. Hur blir det med dom taggarna?


För övrigt, se mina svar nedan i lila färg.



Mvh


Anders Andersson



Från: Mattias Dalkvist 
Skickat: den 20 maj 2017 11:31
Till: OpenStreetMap Sverige mailinglista
Ämne: Re: [Talk-se] Naturreservat



2017-04-04 13:08 GMT+02:00 Mattias Dalkvist 
>:
Jag snubblade över ett nytt naturreservat som inte vi hade med. Efter lite 
efterforskande så är det många reservat som inte är med och flera som ändrats 
sedan importerna gjordes 2009-2011 (enligt wikin).

Vidare så har länsstyrelserna överlåtit ansvaret till naturvårdsverket och 
naturligtvis så har de inte samma fält och id:n som länsstyrelserna hade 
tidigare =/

Jag har gjort ett första utkast för omvandling från NVV till protected_area: 
https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/Nature_conservation#Nytt_initiativ_2017


--
Dalkvist

Det har inte kommit några fler synpunkter så jag gjorde ett litet test :
http://www.openstreetmap.org/changeset/48469000
http://overpass-api.de/achavi/?changeset=48469000


För befintliga reservat har jag använt josms replace geometry, eftersom det 
inte är ovanligt att några noder från tidigare import har ändrats av misstag.

I testet så har jag inte tagit bort någon meta data från föregående importer, 
vad tycker ni ska de vara kvar eller inte?
Det spelar ingen roll för mig. Jag tror inte all data används, men så mycket 
skada gör den knappast heller.

Där flera reservat har gemensam gräns så stämmer det aldrig 100% eftersom de 
oftast är manuellt digitaliserade från LMs kartor, ibland med olika 
detaljnivåer.
Oftast är det ~1m diff men jag hittade ett exempel i Dalarna där två reservat 
överlappar med ca 10m och i broschyren om området är bägge gränserna med ;)

Så med tanke på att källmaterialet inte är så exakt har jag bara tagit 
informationen från en av reservaten och använt den i alla relationerna ex 
https://osm.org/way/491868993

I flera fall går reservatgränserna på administrativagränser (län/kommun) så har 
jag inte gjort någon harmoniseringen utan tänker att det kan jag/vi göra i ett 
andra pass.
Låter vettigt.

Har sätt på flera ställen att gränser delar noder/vägsegment med andra saker 
som markanvändning, vägar, bäckar etc (inget i testet dok). Jag tycket att 
gränser borde var skilt från allt annat, för som jag förstår det så även om en 
gräns sätts efter ett vattendrag så är det i Sverige bara koordinaterna som 
gäller om vattendraget ändrar sig så ändras inte gränsen automatiskt.
Jag håller med. Jag skulle önska att administrativa gränser var dolda som 
standard i alla redigerare. Vanligaste nybörjarfelet efter att flytta vägar 
efter flygbilder utan tanke på offset är nog att sätta ihop diverse saker med 
administrativa gränser och flytta runt noderna.

--
Dalkvist
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se


Re: [Talk-se] Import av markanvändning (natura 2000)

2017-04-09 Thread Micke
Hej!


Jag hjälper gärna till med importen. Överlåter dock helst det administrativa 
till någon annan, men kan hjälpa till att manuellt granska det som importeras.



Anders Andersson



Från: Mattias Dalkvist 
Skickat: den 9 april 2017 10:04
Till: OpenStreetMap Sverige mailinglista
Ämne: [Talk-se] Import av markanvändning (natura 2000)

Hej

Naturvårdsverket har mycket mer info än naturreservats gränser under CC0 licens.

Jag har tittat på natura 2000 datat, kvaliteten varierar kraftigt mellan 
områdena, många är mycket bra med data från ortofoton och fält inventeringar 
men stora för områden i fjällen är det dåligt, tydliga pixlar i klass med 
corine.

Så det är ingen ide att köra någon automatisk import men att ha ett skript som 
gör majoriteten av taggarna och vi sedan manuellt granskar och integrerar 
befintligt data bör funka bra. Speciellt om man tar ett litet område åt gången.

Har börjat fylla i en import mall på wikin 
https://wiki.openstreetmap.org/wiki/User:Dalkvist/natura2000 har också gjort en 
översättningstabell från natura 2000 koder till osm taggar 
https://wiki.openstreetmap.org/wiki/User:Dalkvist/natura2000/codetable

Ett exempel finns på 
https://drive.google.com/open?id=0B4nKYf6PMyjFLTk5c3FIblFnalU med rå datat shp, 
ogr2osm transformations skriptet, ett par mellan steg samt slutprodukten efter 
manuellt job.


--
Dalkvist
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se


Re: [Talk-se] Gamla tågspår - Ska de mappas?

2017-01-21 Thread Micke
Inne i Västerås stad kanske det inte tillför så mycket. Men ute på landsbygden 
så säger railway=abandoned att det är en längre sträcka utan tvära kurvor och 
backar. En banvall är dessutom något som oftast syns ganska tydligt och kan 
vara svår att ta sig tvärs över. Bra att veta för t.ex. cyklister, skoteråkare 
m.m.


Även om man själv inte förstår vad en tag används till så finns det andra som 
har nytta av den.


Det blir en ökad komplexitet, absolut. Men ska man ta hänsyn till att nybörjare 
kan göra fel så ska vi inte ha redigerbar data alls. Finns många exempel på 
helt tokiga redigeringar.


Mvh

Anders


Från: Ture Pålsson 
Skickat: den 21 januari 2017 10:36
Till: OpenStreetMap Sverige mailinglista
Ämne: Re: [Talk-se] Gamla tågspår - Ska de mappas?

Tittar man på wikin (http://wiki.openstreetmap.org/wiki/Railways#Life-cycle) 
verkar det ju som om 'abandoned' ska användas då det finns tydliga tecken kvar 
(kanske en banvall men inget spår) och 'razed' eller 'dismatled' om den är helt 
borta (verkar lite överdrivet att ha två olika taggar för något som inte 
finns...).
[http://wiki.openstreetmap.org/w/images/thumb/6/64/Railway_tracks.jpg/240px-Railway_tracks.jpg]

Railways - OpenStreetMap 
Wiki
wiki.openstreetmap.org
There is considerable information about railways, including mainline services, 
subways, heritage lines and trams in OpenStreetMap, together with details of 
railway ...


Det har varit en massa snack på de internationella mailinglistorna om det där 
med nedlagda järnvägar, det går säkert att hitta om man rotar i arkiven. En del 
järnvägsälskare (ferroviofiler? :-) ) vill kartlägga precis allt, andra tycker 
att det är onödigt att mappa saker som de facto är omöjliga att upptäcka i 
terrängen. Själv lutar jag nog åt det senare hållet (kartdatat är tillräckligt 
rörigt ändå, det blir bara jobbigt att redigera om man har en massa extra ways 
att ta hänsyn till), men andra har uppenbart andra åsikter. En del säger "Om en 
banvall finns kvar men har gjorts om till cykelväg är det historiskt intressant 
att ha kvar dess identitet som banvall", och de har förstås en poäng i att det 
är (teknik)historiskt intressant, men jag säger "Om det kvackar som en cykelväg 
så är det en cykelväg, även om det var en banvall 1920. Den nuvarande 
datastrukturen pallar knappt för att representera vad saker *är*, låt oss inte 
dra in vad de *var* också!".



___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se


Re: [Talk-se] Riksettan

2013-12-15 Thread Micke
Jag skapade en relation för drygt ett år sedan.

http://www.openstreetmap.org/relation/2307312

 

Ni får gärna komplettera den med det som saknas eller rätta eventuella
felaktigheter.

 

 

/Anders

 

 

 

 

  _  

Från: Jonas Hogstrom [mailto:jonas.hogst...@pobox.com] 
Skickat: den 13 december 2013 14:28
Till: Talk-se@openstreetmap.org openstreetmap
Ämne: Re: [Talk-se] Riksettan

 

En relation kanske vore bättre än att döpa om vägsegmenten? 

/jonas

-- Skickat från en mobil devajs med ett pyttelitet tangentbord.. . Det kan
nog förklara både eventuella stavfwl och det lite korthuggna språket i
mailet.

On Dec 13, 2013 2:18 PM, Lars Aronsson l...@aronsson.se wrote:

Det finns olika böcker om k-märkta byggnader och
andra företeelser. En del av uppmärksamheten har
riktats mot Riksettan, gamla riksväg 1, innan den
blev E4:an och motorväg, alltså cirka 1940-1960.

Men det verkar (?) saknas kartor som visar vilka
delar av gamla Riksettan som man kan åka på
idag. Vägarna har ju fått nya nummer och delvis
dragits om.

Borde vi i OpenStreetMap sätta name=Riksettan
på de vägsegment som utgör en lämplig turistled,
som så långt som möjligt följer gamla Riksettan?


-- 
  Lars Aronsson (l...@aronsson.se)
  Aronsson Datateknik - http://aronsson.se



___
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


Re: [Talk-se] Kartlägga Skärgården eller kustområden

2013-05-17 Thread Micke
Skriver några förslag direkt från huvudet nedan. Säger inte att dom
nödvändigtvis är rätt.

/AndersAndersson

-Ursprungligt meddelande-
Från: Erik Johansson [mailto:erjo...@gmail.com] 
Skickat: den 17 maj 2013 12:09
Till: talk-se@openstreetmap.org
Ämne: [Talk-se] Kartlägga Skärgården eller kustområden

Jag undrar om man verkligen måste kartlägga öar i Stockholmsskärgård
som natural=coastline, räcker det inte med natural=island?

Någon som vet vad det är för uppdateringsfrekvens på kustlinjer och
öar, för att komma in på Mapnik?


Sedan sist är det någon som har bra termer och taggar för att namnge

 uddar  place=locality
 vikar  natural=bay
 berg (inte höga men över 10m)  natural=peak (fast det avses nog egentligen
högre berg)
 kobbar place=islet
 holmar place=islet
 hamnar leisure=marina
 ängar  landuse=meadow

-- 
/emj




___
Talk-se mailing list
Talk-se@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-se


Re: [Talk-se] Motionsspårskarta

2012-07-27 Thread Micke
Hej!

Ser riktigt bra ut! Gillar att man hyfsat tydligt ser hur en slinga går även
där flera går tillsammans. Även streckade spår var trevligt! Borde detta
dokumenteras i Wikin på något sätt?

Som jag sa tidigare så skulle jag nog vilja ändra till distance då det känns
dumt att introducera en till tag med snartlik betydelse. Men använder du
length under utvecklingen nu och ändrar sen så har jag inget emot det.

Det finns en liknande karta för skidspår som jag tycker är bra.
http://osm.virtuelle-loipe.de/loipemap/?zoom=14lat=60.39174lon=15.60135la
yers=B000TTF

Det jag gillar med den är höjdskuggning, samt att man kan klicka på ett spår
och få upp beskrivning av spåret, belysning, spåravgift, stil (klassisk
eller skate), samt uppgiven längd (=distance) plus beräknad längd i OSM. För
löpning skulle kanske surface istället för stil passa bättre.

Jag har lagt in en massa skidspår och de flesta av dem är ju spår för
löpning på sommaren. Vet någon om man enkelt kan kopiera skidrelationen och
bara byta ut route=ski till route=running?


Mvh

Anders

-Ursprungligt meddelande-
Från: Tobias Johansson [mailto:t...@mensa.se] 
Skickat: den 26 juli 2012 21:05
Till: Magnus Österlund
Kopia: talk-se
Ämne: Re: [Talk-se] Motionsspårskarta

Hej

Dags för ver. 0.2 av min motionsspårsrenderare. Ser ganska lik ut men
är väldigt anorlunda hur jag gör allt (den gör det lättare för mig än
ver 0.1).

Ändringa
1. Den största ändringen är att den nu renderar det längsta spåret
längst ner och sedan kortare längre upp. Detta sköts med length-taggen
och måste vara i meter änsålänge. Efter att jag lagt in length på de
flesta spår i Sverige för att testa så var en vaken människa snäll nog
att nämna att det finns en tagg distace på routes. Kommer nog
använda den längre fram men för tillfället length.
2. Tjockleken sätts av length olika intervaller får olika tjocklek
enligt en tabell.
3. Man kan nu lägga in två färger i colour-taggen såsom
#FF;#00 så renderas den streckat.
http://minkarta.no-ip.org/?zoom=14lat=57.69803lon=12.06913layers=B0FTF0
4. Den använder automatiskt de färger som står i colour-taggen
(tidigare var jag tvungen att manuellt lägga in en färg första gången
jag såg den användas).
5. Har nu registrerat en no-ip-domän för att slippa ip-addressen
http://minkarta.no-ip.org .

Saker jag skulle vilja fixa
1. Att kunna använda vilken enhet på längden som helst (nästan iaf.)
Tror jag nog kan lösa det med att pre-processera sweden.osm med sed på
nåt sätt...
2. Lägga in namn på sträckorna. Funderar på att försöka rendera en
svart blob med text på för att berätta vilket spår som är vilket, har
lite idéer men vet inte om det kommer funka.
3. Rendera spåren sida vid sida istället för ovanpå varandra. Ingen
aning om hur jag kan göra detta förslag motages gärna.

MvH Tobias

Den 2 juli 2012 23:11 skrev Magnus Österlund magnusolsso...@gmail.com:
 Förstår ditt argument att slippa omärkta leder.
 Problemet är t.ex. mindre elljusspår på mindre orter där det bara finns en
 led att följa. Det är mycket tydligt var leden finns, så det behövs inte
 olika färger för att märka upp leden. Colour är i dessa fall oralevent,
och
 det är officiella tydliga leder.
 Men om det blir problem med för många omärkta inofficiella leder kanske
man
 får sätta attributet colour ändå för att det ska synas, men det känns lite
 fel.

 Den 2 juli 2012 17:47 skrev Tobias Johansson t...@mensa.se:

 Hej igen

 Själv programmerare från länge sedan (länge sen jag gjorde nåt
 allvarligt dock) så jag vet vad du menar. colour verkar användas
 mycket mer än color i osm. Dock så använder JOSM color som standard,
 vilket förgrymmar mig lite...

 Att rendera spår utan färg har jag funderat på. Lägger nog in det
 ikväll.. Anledningen att det inte fanns är att jag är rädd att andra
 kommer lägga in omärkta löpspår, och jag vill egentligen på min karta
 bara ha skyltade löpspår. Så att man som turist kan se vart det finns
 löpspår man kan springa utan att behöva karta och kompass :).

 MvH Tobias

 Den 2 juli 2012 15:14 skrev Magnus Österlund magnusolsso...@gmail.com:
  aaa, en sådan lite detalj som påverka så mycket. Jag tittade flera
  gånger
  och kunde inte se felstavningen. Lite frustrerande med att den
  stavningen
  används, som programmerare är jag van att det alltid är color som
  används.
  Så jag har gjort det felet själv några gånger, och vi är nog inte de
  enda
  som gör det felet heller. Bra att du lägger in lite feltolerans.
  Men kan du inte även lägg in rutter som inte har någon colour inlagd
  (antingen för att det inte finns eller för att mapparen inte känner
till
  färgen). Även sådana löpaspår är intressanta att rendera.
 
  //Magnus
 
  Den 2 juli 2012 14:19 skrev Tobias Johansson t...@mensa.se:
 
  Hej
 
  Skatåsspåren som var inlagda (av mig också händelsevis) hade jag
taggat
  color istället för colour. Detta har jag åtgärdat nu, och ikväll skall
  jag
  nog köra en uppdatering av min postgre-databas så de förhoppningsvis
  dyker
  upp.