Re: [Talk-se] Map Feedback- Sweden

[pangose]

Hi

Could you post English originals when you post answers or just keep the whole 
conversation in English?

What other sources are you going to use and for what purpose?

I wonder if you misunderstood markku. He said that the data in OSM might be 
more correct than NVDB in some cases.

With that in mind I urge you to start by only adding data from NVDB which do 
not conflict with OSM. How does that sound?

Cheers 

Den 4. april 2023 16.25.46 CEST, Salim Baidoun  skrev:
>Hej Markku,
>
>När det kommer till vägar är NVDB tillräckligt bra, även om vi vet att ingen 
>källa är perfekt. Så använd gärna NVDB som källa för det här syftet.
>För övriga ämnen bör andra relevanta källor användas.
>
>
>Vänliga hälsningar
>
>Salim A. Baidoun| Community & Partnerships
>
>
>From: Markku Siipola via Talk-se 
>Date: Tuesday, 4 April 2023 at 15:32
>To: talk-se@openstreetmap.org 
>Cc: Markku Siipola 
>Subject: Re: [Talk-se] Map Feedback- Sweden
>
>Hej!
>
>Vad menas med trovärdig källa?
>
>För vägar är bästa externa källan NVDB, men även den har fel, och lokala 
>justeringar har gjorts som inte är återförda till NVDB.
>
>/Markku
>Den 2023-04-04 kl. 15:08, skrev Salim Baidoun:
>
>Hej Svenska OSM samfundet!
>
>I TomToms strävan att förbättra OSM planerar vi att utföra redigeringar 
>baserat på er användarinput. Denna aktivitet relaterar till att kontrollera om 
>fel som tas emot för TomTom-kartan också är giltig för OSM-kartan.
>
>Vännligen observera att vi kommer börja med ett litet antal, och vi kommer 
>endast att utföra redigeringar om de tillför värde till OSM-kartan eller inte 
>står i konflikt med några nyligen gjorda redigeringar av communityn samt at 
>dessa redigeringar stöds av en lokal källa. I avsaknad av trovärdigt 
>källmaterial kommer vi att nå ut till lokalsamhället för vägledning.
>Vi börjar med att redigera POI, markanvändning, adresser och vägar under denna 
>aktivitet. Med tiden kommer vi att utvärdera mer feedback och utöka till andra 
>teman. För ytterligare information om typerna av planerade redigeringar, kolla 
>gärna: GitHub
>
>MapRoulette-utmaningen som används för dessa redigeringar kommer endast att 
>vara tillgänglig för vårt redigeringsteam eftersom den kan innehålla 
>konfidentiell information. Tillsammans med #tomtom-hashtaggen som följer med 
>varje TomTom-redigering i OSM, kommer vi också att lägga till #tt_mapfeedback 
>till ändringsuppsättningen för varje redigering som är ett resultat av sådanna 
>användarfeedback.
>
>Vi planerar att börja med Sverige om 2 veckor, tillsammans med ett urval av 
>länder för vilka det finns tillgänglig användarfeedback. Sedan expanderar vi 
>till andra länder. Kontakta mig gärna direkt om du har några frågor eller 
>tankar om den här kommande aktiviteten.
>
>Hälsningar
>Salim A. Baidoun / Community & Partnerships - Global / Community Engagement
>.​
>
>
>
>
>
>___
>
>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] Jag behöver hjälp att göra min öppna-data-specifikation för Badplatser "kompatibel" med OpenStreetMap!

[pangoSE]

Hej Tomas

Stort tack för att du frågar och att du öht jobbar med detta.

Du är den första myndighetsperson som frågar öppet vad jag vet under alla mina 
år i OSM. Kudos!

Det kräver mod att fråga och sticka ut hakan och det verkar du ha 

Jag håller helt med Ture nedan. Skapa en egen databas med CC0 på metadatan och 
CC-licens på bilder. Släpp gärna geojson på badplatsens yta om ni har som CC0 
också. 

När det gäller specifikation så föreslår jag att du skapar ett utkast på github 
eller liknande och frågar WD gemenskapen om återkoppling. Vad vill man veta om 
en badplats?
En vild spåning:
Finns det tillgänglighetsanpassning? Vilken? Finns det dusch? Kostar dusch 
eller är det gratis (som på stränder vid Barcelona)? Finns det toa? 
Rullstolsanpassad? Är sanden fraktad till platsen? Hut ofta fylls den på? När 
fylldes det på med sand senast? Finns det kiosk? Vad är positionen på toan och 
kiosken? Vem driver kiosken? Öppetider? Vilken kornstorlek är det på sanden? 
Vem ansvarar för att mäta badkvaliteten? När mättes den senast? Vad är 
temperaturen? Är stranden långgrund? Går det att mäta lutningen på stranden? Är 
det skugga på stranden? Träd? Position, trädslag och krondiameter på träden? 
Etc. etc.

Se till at databasen har persistenta och unika ID (tex GUID), dela den i ett 
maskinläsbart format eller API och skriv sedan ett uppslag på 
https://m.wikidata.org/wiki/Wikidata:Bybrunnen

Då kommer någon säkert raskt att svara och modellera och importera datan i 
Wikidata.

Nät datan är importerad kan du enkelt lägga till den unika Wikidata QID i eran 
databas om du vill.

Sen kan nån från OSM gå igenom varje WD objekt och se till att det finns en 
relation för badplatsen i OSM som länkas. Då kan man via WD få upp alla 
badplatserna på OSM.

Lycka till med arbetet.


"Ture Pålsson via Talk-se"  skrev: (30 april 2021 
15:19:15 CEST)
>Det här är mest min personliga uppfattning; jag har inget mandat att
>uttala mig för OSM:s räkning (det är f.ö. tveksamt om *någon* har det).
>Och nej, frågan är definitivt inte korkad. Tyvärr är risken att svaret
>blir luddigare än frågan...
>
>Det är lite rörigt att länka mellan OSM och andra databaser.
>
>En företeelse i OSM har inget ID som är stabilt över tid. Till exempel
>kan en badplats börja som en nod, ändras till en ”way” för att någon
>ritar ut konturerna, och sedan bli en relation när någon karterar i
>detalj med sand- och gräsytor, bryggor, omklädningsrum, livbojar,
>glasskiosker, toaletter och hela baletten, och varje gång får den ett
>nytt ID. Det gör det olämpligt att använda OSM-id:t som ”foreign key” i
>andra databaser.
>
>Åt andra hållet kan man naturligtvis lägga in ett ID från en annan
>databas i en tag i OSM. Mitt intryck är att det brukar rynkas lite på
>näsor åt sådana lösningar. ”Vi vill inte skräpa ner databasen med en
>massa nycklar som pekar kors och tvärs!” säger i alla fall en del. För
>svenska badplatser kanske risken inte är så stor, men jag antar att man
>ser en risk att ”populära” objekt, som är intressanta att länka till
>flera databaser, kommer att få en hemskans massa konstiga taggar med
>ID:n. Dessutom finns alltid risken att sådana id:n försvinner i
>redigeringar, eftersom den som redigerar inte begriper vad de är.
>
>Så hur i hela friden *ska* man göra, då?
>
>Möjligen kan det vara en bra plan att länka via wikidata. Att tagga in
>wikidata-id:n på objekt i OSM verkar hyfsat etablerat och accepterat,
>så man skulle kunna använda det för att länka ihop databaserna. Fältet
>ref_osm skulle då alltså inte behövas i badplatsdatabasen eftersom dess
>roll skulle tas över av ref_wikidata. Risken att ett wikidata-id på ett
>OSM-objekt redigeras bort av misstag eller okunskap torde vara mindre
>än att ett badplats-id drabbas av samma öde, eftersom wikidata är
>hyfsat välkänt.
>
>En annan variant är att inte ha någon explicit länk alls. Positionen
>finns ju i badplatsdatabasen, alltså kan man leta upp ett
>badplats-objekt i närheten av den positionen på OSM. Haken med det är
>att OSM-objektet kanske inte ligger på exakt samma position, så man
>måste tillåta en viss ”suddighet”, och då finns det risk att man hittar
>fel objekt. Kanske inte *så* stort problem för badplatser, som väl
>borde ha i alla fall någon kilometers separation från varandra, men ett
>problem om man vill ha en databas över något där separationen mellan
>objekt är i samma storleksordning som objektens storlek (caféer i
>Stockholms innerstad, kanske).
>
>
>
>> 30 apr. 2021 kl. 11:28 skrev Tomas Monsén :
>> 
>> Hej!
>>  
>> Jag arbetar i en arbetsgrupp i ett regionalt projekt för Västra
>Götaland kring Öppna Data.
>> Vi håller på att författa en specifikation för badplatser och önskar
>göra den ”kompatibel” med OpenStreetMap!
>>  
>> I korthet har vi definierat ett antal attribut som kommer att
>beskriva en badplats, främst i de i projektet deltagande kommunerna.
>> Vi önskar göra datamängden så användbar som möjligt och vill länka
>till (och från?) OpenStreetMap på rätt sätt.
>>  

Re: [Talk-se] Reverting undiscussed Lantmäteriet import

[pangoSE]

Big thanks for putting energy into this. ❤

I hope you have good tools to effectively revert the changesets.

Lets continue together making the best map Sweden has ever had 


"Andreas Vilén"  skrev: (7 december 2020 08:36:02 CET)
>Hi,
>
>Big thank you for this!
>
>I believe this situation from earlier this year is connected:
>https://lists.openstreetmap.org/pipermail/talk-se/2020-May/003876.html
>There were hacked accounts importing one locality per changeset from
>bad data sources. Those accounts were also hacked.
>
>I’m not sure if anyone contacted DWG back then though.
>
>Regards
>Andreas
>
>Skickat från min iPhone
>
>> 6 dec. 2020 kl. 23:27 skrev Frederik Ramm :
>> 
>> (cross-post with forum)
>> 
>> Hi,
>> 
>> over the last couple of weeks, over 90.000 changesets have been made
>by
>> 45 different accounts, performing an undiscussed, low-quality
>> Lantmäteriet import (many small bits of tracks or minor roads,
>> unconnected to each other and the rest of the network). Several
>members
>> of the Swedish OSM community have made the DWG aware of this issue.
>> 
>> The worst thing about this is that many of the accounts used have
>been
>> hacked - they are accounts of people normally editing elsewhere on
>the
>> planet, with different editors, in different languages, and certainly
>> not importing Lantmäteriet.
>> 
>> Not only is this a slap in the face for all of our hard working
>> volunteers trying to make the best map in Sweden; it is also a crass
>> violation of trust (and very likely also a violation of Swedish law).
>> 
>> We (at DWG) are still investigating who is behind this. This is more
>> than just the usual bad import, this is someone who has enough
>criminal
>> energy to hack into other accounts in an attempt to fly under the
>radar.
>> 
>> We have blocked the accounts involved (a list of accounts we have
>> identified is below). If you know anything that might help us
>determine
>> the identity of this hacker, please let us know at
>d...@osmfoundation.org.
>> 
>> We're planning to revert the import in the coming days.
>> 
>> Bye
>> Frederik
>> 
>> List of accounts identified (remember, many of these will be innocent
>> users that had their account hacked):
>> 
>> 30d4f4e1ccf24
>> Anggele
>> Beckster55
>> Daly Riandi
>> Gary18
>> IsabelenEvelyn
>> Lana Villa
>> Nicolas59380
>> Projekt-rolli
>> RobertKluijver
>> Ryan Seid
>> SLC
>> Sivia1811
>> TTSS
>> ViktorPurtin1
>> Yesbolaga
>> _underscore_
>> ahateam
>> ankon
>> annedukh
>> arraggonn
>> barbara61
>> couch-potato
>> dbmercer
>> dmitmia
>> estrellaoruro
>> faithace
>> flyup2000
>> franz0078
>> hako0215
>> jeppe2011
>> jojoAdventure
>> jona0918
>> kamilpost
>> mapeditorkepno
>> rohweder
>> thageboelling
>> tomas471
>> tomto1
>> tonypepe
>> ulaB
>> ussifonyll-39
>> uwasescott
>> voodoobaby
>> xcvb
>> xerxes76
>> 
>> -- 
>> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09"
>E008°23'33"
>> 
>> ___
>> 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] Samarbete med Wikidataprojekt om naturcampingplatser

[pangoSE]

Hej!

Tusen tack för ditt meddelande. Jag kände inte till den och gillar
den starkt så jag delade på FB :)

Härnösand där jag bor är ganska tom än så länge, men jag la just till
en bärbuske. 

Du har helt rätt i att Commons Appen kanske inte är rätt verktyg
eftersom en mera specialiserad app skulle vara att föredra för just
detta projekt.

Fruktkartan är väldigt intressant eftersom det säkert hyfsat enkelt
skulle gå att göra en fork som möjliggör skapande av en campsite-item
på WD och lägga till bilder också.

Modellen av hur en campsite ska se ut på WD är inte riktigt fullmogen
än heller faktiskt eftersom att den nuvarande modell har lite brister.

En förbättring av modellen skulle kunna vara:
campsite-item
 -> har del: vindskydd-item

I dagsläget har jag lagt upp ett 40-tal items med denna modell
campsite-item
 -> har facilitet: vindskydd
Se
https://query.wikidata.org/#%23Campsites%20and%20shelters%20in%20Sweden%0ASELECT%20DISTINCT%20%3Fitem%20%3FitemLabel%20%3FadminLabel%20%3Fcoor%20%3Fpic%0AWHERE%20%0A%7B%0A%20%20%3Fitem%20wdt%3AP31%20wd%3AQ832778%3B%20%23campsite%0A%20%20%20%20%20%20%20%20wdt%3AP17%20wd%3AQ34%3B%0A%20%20%20%20%20%20%20%20wdt%3AP625%20%3Fcoor%3B%0A%20%20%20%20%20%20%20%20wdt%3AP131%20%3Fadmin%3B%0A%20%20%0A%20%20OPTIONAL%20%0A%20%20%7B%3Fitem%20wdt%3AP18%20%3Fpic.%7D%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%2Csv%22.%20%7D%0A%7D

Skillnaden med den föreslagna modell är hur lätt det är att lägga till
bilder och area på golv, m.m. vilket är alldeles för krångligt i den
nuvarande modell tycker jag.

Ett bra app eller webb-interface skulle kunna dölja denna komplexitet
och bara skapa alla campsite- och vindskydd-items i bakgrunden och
länka ihop dem, ladda upp bilderna på commons och länka till dem med
lämplig egenskap.

Är du intresserad av att tillsamman med mig skapa en
webb-app baserad på fruktkartan för detta?

Mvh
pangoSE

Den Thu, 24 Sep 2020 10:20:26 +0200
skrev Re: [Talk-se] Samarbete med Wikidataprojekt om
naturcampingplatser:

> Fint initiativ!
> 
> Jag är med och (ny)bygger https://fruktkartan.se och har ibland
> funderat på vad man skulle kunna ha en mer generaliserad variant av
> denna till. OSM och Wikidata har som du säger rätt höga trösklar för
> att man ska komma igång och bidra med information.
> 
> Commons-appen var smidig i sin enkelhet. Men det känns som det skulle
> till något slags läge med templates eller workflows, som gör det mer
> rätt fram beroende på vad man vill göra (eller vill få folk att göra).
> 
> --
> Daniel
> lublin.se
> 
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se



-- 
--
Cheers/Mvh
Egil Priskorn
CEO Egils Verkstad/Egils Consulting
Sweden

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

[Talk-se] Samarbete med Wikidataprojekt om naturcampingplatser

[pangoSE]

Hej

Jag är intresserad av att samla in bra data om våra fantastiska svenska 
naturcampingplatser som i dagsläget är antingen undermåligt dokumenterade eller 
helt saknas i OSM och Wikidata.

Jag har tidigare tagit initiativ till att öppna upp data från facebook gruppen 
Vindskydd i Norden och det har visat sig svårt i praktiken trots att 
majoriteten av användarna gärna VILL dela sin data fritt.

Det saknas bra verktyg för att lätt dela både metadata och bild inom 
frikulturrörelsen i dagsläget och Openstreetmap är alldeles för komplicerad för 
många att vilja ge sig in på. Det samma gäller tyvärr Wikidata där man måste 
lära sig en massa egenskaper, m.m.

Vi behöver enkla och välgjorda verktyg för att engagera och fånga upp data som 
i dag i stället delas via och låsas in i tex Facebook. 

Se och delta gärna på  https://wikidata.org/wiki/Wikidata:WikiProject_Campsites 
för att föra detta arbete framåt.

Fördelen med Wikidata som source of truth över OSM är flera:
1) det är CC0 vilket är mindre restriktivt än OSM
2) bilderna kan kopplas via egenskaper som anger vad bilden föreställer
3) Integration med Wikivoyage listings är på gång
4) bättre och snabbare API än overpass och Sophox. 
5) bättre appstöd tex via Commons Appen 
6) enklare API som redan används av tusentals olika utvecklare inkl. tex 
OsmAnd. ___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

[Talk-dk] Samarbete med Wikidataprojekt om naturcampingplatser

[pangoSE]

Hej

Jag är intresserad av att samla in bra data om våra fantastiska svenska 
naturcampingplatser som i dagsläget är antingen undermåligt dokumenterade eller 
helt saknas i OSM och Wikidata.

Jag har tidigare tagit initiativ till att öppna upp data från facebook gruppen 
Vindskydd i Norden och det har visat sig svårt i praktiken trots att 
majoriteten av användarna gärna VILL dela sin data fritt.

Det saknas bra verktyg för att lätt dela både metadata och bild inom 
frikulturrörelsen i dagsläget och Openstreetmap är alldeles för komplicerad för 
många att vilja ge sig in på. Det samma gäller tyvärr Wikidata där man måste 
lära sig en massa egenskaper, m.m.

Vi behöver enkla och välgjorda verktyg för att engagera och fånga upp data som 
i dag i stället delas via och låsas in i tex Facebook. 

Se och delta gärna på  https://wikidata.org/wiki/Wikidata:WikiProject_Campsites 
för att föra detta arbete framåt.

Fördelen med Wikidata som source of truth över OSM är flera:
1) det är CC0 vilket är mindre restriktivt än OSM
2) bilderna kan kopplas via egenskaper som anger vad bilden föreställer
3) Integration med Wikivoyage listings är på gång
4) bättre och snabbare API än overpass och Sophox. 
5) bättre appstöd tex via Commons Appen 
6) enklare API som redan används av tusentals olika utvecklare inkl. tex 
OsmAnd. ___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

Re: [OSM-talk] Call for verification (Was: Re: VANDALISM !)

[pangoSE]

Hi mmd

mmd  skrev: (23 augusti 2020 21:38:45 CEST)
>On 2020-08-23 18:27, Martin Koppenhoefer wrote:
>> There is a lot of stuff that could be analyzed, immense. All the
>history is still available with all the user information...
>
>What's next? Do we want to invite "unreliable" mappers to an exciting
>two hours training course to improve their railway mapping skills? Upon
>successful completion of the final test, they can earn 5 extra mapping
>days that count towards their 42-day threshold for an OSMF active
>contributor membership.

LOL. I don't believe in punishment or restrictions based on past performance. I 
believe that people do the best they can as much as the time they can. OSMF 
have lowered the bar of entry to people with little money which is good. More 
engaged members in OSMF is a good sign. Of course this new policy could also 
backfire and lead to 42 days of crap edits for all our millions of users in the 
worst case, but I hope not.

>
>That's a pretty dystopian view on the OSM future, if you ask me...

I hope this reliability index will be used for good. I have no intention of 
using it to pick on others. But maybe someone we ill be curious about to he 
results. We could create a page that suggests what a particular user can do to 
get a higher score. E.g. take extra care to avoid integrity errors on your 
multipolygon edits. Read this page x, contact your local mapping community to 
find a mentor ask in a forum for help with reviewing an edit.

We already have a light version here: https://hdyc.neis-one.org/ where you can 
profile any user after login. 

I never used user statistics in conversations with others because they are 
judgements best used to evaluate a whole. 

I dislike judgements about humans. Ranking and competitions are not my 
favorites either, but I love learning with others. So when I write other 
contributors I only refer to facts about a concrete edit and ask what they 
tried to do. I have never seen anyone anywhere in OSM use data to try to 
control others which is a good sign.

Cheers

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

Re: [OSM-talk] Cannot find address ringvegen 45 Sørkjosen in nominatim

[pangoSE]

Hi Sarah

Sarah Hoffmann  skrev: (23 augusti 2020 22:20:35 CEST)
>Hi,
>
>On Sun, Aug 23, 2020 at 09:41:10PM +0200, Maarten Deen wrote:
>> Node 3117603944 was established in 2014 with tags
>> addr:citySørkjosen
>> addr:housenumber 45
>> addr:postcode9152
>> addr:street  Ringvegen
>> 
>> Yet, when I query nominatim for Ringvegen 45 Sørkjosen I get no
>results.
>> 
>> What is going wrong here? Sørkjosen itself is found [2] so the
>problem does
>> not seem to lie in the special character (I wouldn't have thought
>so). Also
>> found is the street which is named Ringveien [3] in OSM. No idea why
>the
>> street is called different than the address node, but does Nominatim
>not
>> index address nodes?
>
>Nominatim only indexes addresses of streets and then searches for
>address nodes based on the address of the street they are attached
>to.
>
>In that particular example, the housenumber got attached to Hovedvegen
>because Nominatim could not find a 'Ringvegen' and used the nearest
>street:
>https://nominatim.openstreetmap.org/ui/details.html?osmtype=N=3117603944
>
>So you get a slightly different address than expected.
>Fix the name of the street and everything sorts itself out.

 thanks for the explanation and link. Are these very useful get parameters 
documented somewhere? 

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

Re: [OSM-talk] Call for verification (Was: Re: VANDALISM !)

[pangoSE]

Hi Martin 

Martin Koppenhoefer  skrev: (23 augusti 2020 18:27:58 
CEST)
>
>
>sent from a phone
>
>> On 23. Aug 2020, at 13:55, pangoSE  wrote:
>> 
>> We could e.g. set a verification-needed
>> flag on objects edited in a changeset with "please review".
>
>
>while you can (already) add a fixme tag, I fear that creating a special
>feature for less reliable information could lead to people being
>encouraged to adding more “guess work” because they “set the unreliable
>flag so what’s the problem?“

Yeah, that's a good point. We are social animals. 

>
>I just had an idea: You could calculate a reliability index for each
>and every object in OpenStreetMap (and maybe for each of their tags, by
>looking at the mapping experience of the person that added it. 

Beautiful idea! I'm gonna try that with a small country. Working on a small 
excerpt of the planet could be problematic because the whole user history will 
not be available. Hmm that means big data is the only viable way forward.

>In a
>more complex iteration, it could also take the reliability of specific
>mappers into account by analyzing whether things they add or modify are
>kept or changed by following mappers (and it would probably have to
>take time into account, because if something is changed after a long
>time it is more probable that it was because of a change in the real
>life and not because of bad representation, and maybe also the kind of
>change). 

I love this idea too. This is what I have done in my head editing in Sweden for 
multiple years. I have a very short list of editors that frequently map in a 
way I don't like or make errors e.g. things showing up in keep right and they 
were the last editor. Usual suspects . I always try communicating with the 
them and most respond and we find a way forward, but some never react to 
changeset comments and just keep on what they are doing.

Not reacting to changesets comments is another red flag.

>It could also be done according to the field of thing (e.g.
>this mapper does reliable work with buildings or this mapper is an
>expert for outdoor routes but does poor work in cities, or is an expert
>for railways, etc. etc.)

Yes this is a good observation. OSM is hard. It takes time to learn all the 
long ropes.

>
>There is a lot of stuff that could be analyzed, immense. All the
>history is still available with all the user information...

I get your point. 

You could also flag changesets with huge BBOXes and filter away those done by 
experienced mappers and those concerning one big relation.

Using to this search https://duckduckgo.com/?q=osm+history+analysis I just 
found 
https://heigit.org/big-spatial-data-analytics-en/ohsome/ which seem very 
promising 

I will contact them and see if I can use and contribute to their platform to 
get the information I want.

A good algorithm for finding and rating experienced mappers is crucial. If 
anyone already has made one or ideas for improvements please share 

Feel free to add to this wikipage 
https://wiki.openstreetmap.org/wiki/Algorithms_for_QA

I just signed up for Fuga cloud and I'm  gonna start playing with the history 
data in python and postgresql to crunch the numbers for a small country if 
ohsome turns out not to be suitable.

Thanks for sharing your ideas 

Cheers
pangoSE

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

Re: [OSM-talk] Call for verification (Was: Re: VANDALISM !)

[pangoSE]

Hi Martin

Den Sat, 22 Aug 2020 19:30:23 +0200 Martin
skrev Re: [OSM-talk] Call for verification (Was: Re:  VANDALISM !):

> sent from a phone
> 
> > On 22. Aug 2020, at 10:15, pangoSE  wrote:
> > 
> > Here is yet another example of bad data in our database:  
> 
> 
> fix it ;-)

Yeah! But to fix "it" (it being the overall low or unknown quality of
the map) we need good tools that encourage reviewing and fixing. 

We
have a discoverability and usability problem IMO in this area. I fixed
loads of errors during my time and I like it, but I have a poor grasp
of the overall quality of the map in the area and OSM is not making it
easy for me to find the less good quality spots with
stale/old/non-reviewed data.

> 
> Of course OpenStreetMap contains errors, just like any other source,
> and probably more, given that most contributors are laymen and have
> very few experience (few total edits, often just 1).
> 
> On the other hand, we may be very fast when something changes, very
> flexible in emergencies (think Haiti), and have interesting niche
> data that commercial and public data providers don’t care for.

Yes, that really nice. I would like to find a middle ground between fast
and poor/unknown and slow and high degree of verification.

> 
> It all depends on the local community in the end. If you have reached
> a critical mass to have locals everywhere, it will work great and
> bugs will wash out. Otherwise the data might get stale just like any
> other data. Also using the data is essential to find the problems,
> for example the 212 story garage is likely fixed now ;-)

Yeah, I agree. Lets make it easy for a local community to keep the map
verified and up to date. We could e.g. set a verification-needed
flag on objects edited in a changeset with "please review". That would make it 
easy create an
overview of all things todo in your local area based on the objects -
not the changesets that touched them (they can easily be found in
todays interface from the object).

/pangoSE

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

Re: [OSM-talk] New API suggestion: Allowing contributors to easily track their OSM-objects over time

[pangoSE]

Hi Martin

I cooked up a suggestion for implementation of permids :) 

Den Sat, 22 Aug 2020 20:56:05 +0200
skrev Re: [OSM-talk] New API suggestion: Allowing contributors to
easily track their OSM-objects over time:

> On 2020-08-22 19:55, Martin Koppenhoefer wrote:
> > What kind of permanent ids do you want? For some more abstract
> > concept like a road with a specific name? A shop? A building? If
> > there’s a way tagged with building=supermarket, shop=supermarket,
> > name=Foo, and you add a permanent id to it. Then the supermarket
> > gets bought by someone else and changes to name=Pango? Or the
> > supermarket closes. Or it gets torn down and rebuilt by the same
> > operator. Or someone detaches the shop tags and adds them to a node
> > inside. What happens with the id?  
> 
> Your comment is spot on. We're discussing technical ideas for
> something that isn't even clear on a semantic level.
> 
> Somehow this whole discussion reminds me of this blog post [1], in
> particular the "Lack of Permanent IDs" section. A "Conceptual Object"
> as it is described in that blog post sounds like a great idea, yet it
> suffers from the same real world semantic issues that Martin already
> pointed out.

Could you give an example of the issues you are talking about? I'm
thinking we have a need to preserve the ids of anything with tags in
OSM (that is what you navigate via or to/from and whats interesting
for the outside world to link to (I have seen very few links ever to
nodes without tags, because they are often part of a way or
relation with tags or useless orphan nodes)). 

This is how it could work:

Say a shop: Mens Wear within a building is represented today as a node
in osm with a permid=Z123. Then someone deletes it erroneously when
the shop closes and we preserve Z123 and the last known position and
node tags (because it has a permid). 

Someone else comes along and
creates a new shop node: on the same spot or close nearby and now the
question arises, should the new node created be linked to the old Z123
or should we create a new permid=124?

We ask the mapper. If they get information about what was
deleted, they can judge whether the Z123 is still conceptually valid
and restore the old shopspace and rename it to the name of the new shop:

(this would preserve the history old->new also from the earlier
deleted node too essentially making it possible to restore nodes
with permids because they are valuable).
 
The permid then no longer represents a shop but the
location of a space where a shop could and now does exist. Someone
making a service cataloguing all shopspaces for hire in a city could
then link to this shopspace FWIW.

External tools like Wikidata might link to it because they want to list
all locations for a particular brand of stores. If the shop moves to
another shop area the permid of the shopspace remains the same,
wikidata will then have to purge the location and could do that either
by looking at the name tag present or if a qid is present. We could
create a special API or egress dump with an entry every time a name or
qid changes of one of our permids, that wikidata could ingest.

This is all just spun up out of the top of my head so it might not be
feasible, but I think it would work. Of course permids should be
handled in the background when users are creating a node and adding a
tag (I never get to select or edit a permid in wikidata but I can merge
two who represent the same physical concept in the same spot and the
earliest one (lowes id) lives on and the other higher id simply refers
to it).

I hope this made sense to you all, if not feel free to ask.

> 
> 
> [1] https://blog.emacsen.net/blog/2018/02/16/osm-is-in-trouble/

Thanks for the link. I read it before and forgot about it. Reading it
again I see 2 years have passed and not much has changed it seems
(besides we have a little more AI stuff going on in HOT and FB and
OSMF has opened for free membership of active mappers). Maybe he is
right that OSM has lived out its time and is unable to adapt, maybe
not. Lets create a high quality database, not just a mediocre
one with unknown quality and an outdated, stale infrastructure. :)

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

Re: [OSM-talk] New API suggestion: Allowing contributors to easily track their OSM-objects over time

[pangoSE]

Hi Andy 

Andy Townsend  skrev: (22 augusti 2020 13:03:56 CEST)
> > How/where was the notes addition proposed and implemented?
>
>If I remember correctly, it was done as a "Google Summer of Code" 
>project - effectively a sponsorship deal.  However, that project 
>requires a clone of the OSM website, which is a much harder job than 
>merely doing something with OSM data as it is updated.

Yeah. We should make it dead simple and easy to spin up a copy of our website 
and demo database for anyone to hack on on their pc or in the cloud. I'm going 
to contact the operations workgroup and start working on that because its 
crucial to making the much nedded improvements I'm interested in.

>
> >  I intended to write it myself it others find it useful.
>
>Great!
>
> > I would prefer that it is an official api so I don't have to cover 
>the hosting costs.
>
>Well if you start writing it locally and start initially with a small 
>extract of OSM data your hosting costs will be zero.  Even if you 
>absolutely need to go for a hosted server it needn't cost more than a 
>Northern European cup of coffee a month to start with (see e.g. 
>https://blog.jochentopf.com/2019-03-07-the-new-osmdata-service.html )

What a valuable writeup! Thats very cheap, interesting.
I just found http://fuga.cloud which is openstack based and also very cheap.

>
>>  Is there anywhere to post an issue to implement this and later pull 
>requests?
>
>I'd suggest creating such a place in a shared code repository such as 
>github (which is where lots of OSM-related stuff already is).  Don't 
>worry that it isn't "official" - very little in OSM is.  If it becomes 
>valuable it can easily be built on or incorporated into osm.org 
>centrally later.

All right, sounds reasonable 

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

[Talk-se] Fwd: [Talk-dk] Gratis medlem af OpenStreetMap Foundation baseret på hvor aktiv du er

[pangoSE]

 Originalmeddelande 
Från: Soren Johannessen 
Skickat: 23 augusti 2020 07:20:11 CEST
Till: OpenStreetMap Denmark 
Ämne: [Talk-dk] Gratis medlem af OpenStreetMap Foundation baseret på hvor aktiv 
du er

Hej alle sammen

Du kan nu blive gratis medlem OpenStreetMap Foundation, hvis du inden
for de sidste 365 dage har været ind og redigere i 42 dage samt din
indsats er frivillig og ikke en del af dit daglige arbejde. Dit
medlemskab vil høre under OSMF "Active Contributor Membership" men læs
selv mere på den lange FAQ side om dette.
https://blog.openstreetmap.org/2020/08/20/active-osm-contributor-membership-program/

Om 1 år hvis du er blevet medlem, så skal medlemsskabet fornyes igen
og så er det igen krav med 42 dage.

Du kan på  "How did you contribute to OpenStreetMap?" værktøjet tjekke
dit profilnavn,  hvor mange dage du har redigeret samt om du kan blive
medlem (ny service) kig under
Active contributor: hvis der står Yes & Yes så opfylder du
betingelserne mht. 42 dage https://hdyc.neis-one.org/

Online blanket til indmeldelse -
https://join.osmfoundation.org/active-contributor-membership/application-form-for-active-contributor-membership-mapping/
Der går lige et par dage eller mere før du er endelig medlem, da du
bliver tjekket og godkendt af nogen fra OSMF bestyrelsen.

Endelig så har OSM Foundation en donation side, du måske kan overveje
at støtte med lidt penge som et engangsbeløb, nu du evt. bliver gratis
medlem
https://donate.openstreetmap.org/

Med venlig hilsen
Søren Johannessen

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

Re: [OSM-talk] Call for verification (Was: Re: VANDALISM !)

[pangoSE]

pangoSE  skrev: (23 augusti 2020 08:38:45 CEST)
>
>Andy Allen (he runs  http://www.thunderforest.com/ which has a nice
>vector map service by the way on a free limited tier) a former member
>of the operations working group and current co-maintainer of the rails
>website posted this a year ago: 
>https://gravitystorm.github.io/osmf-infra-plans/ and this july the OSMF
>and the operations working group announced hiring of a Senior Site
>Reliability Engineer:
>https://mobile.twitter.com/OSM_Tech/status/1287395222847139846
>
>This seems like a good move. We would benefit a lot from being able to
>easily load balance and adjust VMs on our own or someone elses
>openstack infrastructure where we can easily provision new servers for
>development or testing when needed instead of having dedicated physical
>hardware servers that causes availability issues if they break because
>of single point of failures.

Speaking of free software like openstack: here are a few companies that 
contribute to and use openstack:

* the swedish company City Cloud seems to be the only one hosting their cloud 
on free software with multiple re.
They are not the cheapest, but they goe datacenters in many regions and have a 
lot of ISO certifications and are used to dealing with GDPR compliance.
https://citycloudng.com/

* the dutch company Fuga. They do not disclose how many locations they got so 
I'm guessing only one in the Netherlands. They are way cheaper than City Cloud 
it seems and are ISO certified and GDPR compliant.
https://fuga.cloud/about-fuga/

/pangoSE 
-- 
Skickat från min Android-enhet med k9.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Call for verification (Was: Re: VANDALISM !)

[pangoSE]

Hi Shawn

"Shawn K. Quinn"  skrev: (23 augusti 2020 00:31:28 CEST)
>On 8/22/20 03:26, pangoSE wrote:
>> I meant that a verification system does exist in Wikipedia and they
>> now require references on all statements to keep up the quality of
>> the articles which is sane IMO. We have no such system.
>
>The big, huge difference between Wikipedia and OSM is that Wikipedia
>does not allow original research at all, whereas OSM thrives on the
>original research of everyone who contributes and in fact it is the
>stuff that comes from third parties that has to be vetted more closely
>for license compliance and copyright issues.
>
>I agree we could do better in the quality control department but a lot
>of things added to OSM will be added there first before any third
>parties pick them up. That makes references a bit problematic, IMO.

All edits in OSM must be verifyable on the ground if I understood this 
correctly: https://wiki.openstreetmap.org/wiki/Verifiability

Problem is to really make this easy to review without visiting the same spot we 
would in many cases need a good photo or perhaps multiple photos from different 
angles.
Unfortunately we neither encourage nor support image uploading anywhere hosted 
by ourselves or others (we could probably easily integrate mapillary uploading 
in the website and in our mobile tools. I take photos with osmtracker sometimes 
but cannot upload them to mapillary from inside JOSM). I'm not saying it should 
be a demand, but I think we would gain a lot in many changeset discussions if 
adding images to the chat and changesets is made possible or if images in 
mapillary in the area were visible and referencable on the changeset discussion 
page.

Alternatively we could cook our own image storage service if we want. We got 
the money for it now and commercial persistent object storage solutions are 
available from multiple providers releasing the burdon of infrastructure 
maintenance on our operations working group. WDYT?

This and my proposal to mark features as verified at this point in time could 
potentially make it much easier to judge the overall quality of our data and 
map.

We would still be lacking a REAL granular referencing system where every 
statement (tag) is references individually with a date, author and optionally a 
photo. That would be really awesome, but it would require additions to the main 
database model and ruby website to support (this is perhaps a perfect GSoC 
project). Being able to browse to a specific tag on an object and discuss that 
would be a crucial addition to the website because now we are forced to comment 
on the changeset (or sending pms) and I think its really cumbersome to manually 
reference which one of the sometimes hundreds of objects I'm talking about. 

Andy Allen (he runs  http://www.thunderforest.com/ which has a nice vector map 
service by the way on a free limited tier) a former member of the operations 
working group and current co-maintainer of the rails website posted this a year 
ago: 
https://gravitystorm.github.io/osmf-infra-plans/ and this july the OSMF and the 
operations working group announced hiring of a Senior Site Reliability 
Engineer: https://mobile.twitter.com/OSM_Tech/status/1287395222847139846

This seems like a good move. We would benefit a lot from being able to easily 
load balance and adjust VMs on our own or someone elses openstack 
infrastructure where we can easily provision new servers for development or 
testing when needed instead of having dedicated physical hardware servers that 
causes availability issues if they break because of single point of failures.

See also https://operations.osmfoundation.org/ 

BTW osm-fr already made this move and is mostly running VMs now and has moved 
some of their VMs (heavy tile rendering) into the OVH cloud to manage their 
hardware more efficiently. See 
https://wiki.openstreetmap.org/wiki/FR:Serveurs_OpenStreetMap_France

Cheers
PangoSE 

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

Re: [OSM-talk] New API suggestion: Allowing contributors to easily track their OSM-objects over time

[pangoSE]

Hi Martin :)

Den Sat, 22 Aug 2020 19:55:16 +0200
skrev Re: [OSM-talk] New API suggestion: Allowing contributors to
easily track their OSM-objects over time:

> sent from a phone
> 
> > On 22. Aug 2020, at 19:44, pangoSE  wrote:
> > 
> > Maybe we should first add permanent ids (new table) and reference
> > that.  
> 
> 
> we do have permanent ids for nodes, ways and relations. ;-)

Okay I think I understand what you are saying. You are saying that if
I create a node, edit it in another changeset it still has the same
id, right? (same goes for the other 2) The problem is that the rest of
the world talks about physical objects like houses, hospitals and
toilets and not nodes, ways or relations and things relying on OSM break
when mappers enrich the map and e.g. embed nodes in a way and move the
tags to the way. 

> What kind of permanent ids do you want? For some more abstract
> concept like a road with a specific name? A shop? A building? If
> there’s a way tagged with building=supermarket, shop=supermarket,
> name=Foo, and you add a permanent id to it. Then the supermarket gets
> bought by someone else and changes to name=Pango? Or the supermarket
> closes. Or it gets torn down and rebuilt by the same operator. Or
> someone detaches the shop tags and adds them to a node inside. What
> happens with the id?

Our datamodel and tools currently does not support keeping a higher
order view of an object and letting the user modify it using our
internal representations at will. Instead we treat objects as like the
don't belong together or relate at all unless they are part of a
relation.

From what I understand an uploaded way converted in JOSM to a relation
get a new osm_relation_id, (asuming I first upload a
node with changeset A, change it to a way by adding another node to it
in changeset B and finally convert it to a relation in JOSM in changeset
C). But I might be wrong about this.

> 
> You can have this with relations, but it (associated street, street)
> did not find a lot of support from the contributors and most mappers
> have decided for themselves that it does not work for them.

Yeah, that was perhaps not the best way to implement a model (the name
implies that it only relates to streets btw.) that handles human
features well over time.

Cheers
pangoSE

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

Re: [OSM-talk] New API suggestion: Allowing contributors to easily track their OSM-objects over time

[pangoSE]

Hi Simon

Den Sat, 22 Aug 2020 14:22:07 +0200
skrev Re: [OSM-talk] New API suggestion: Allowing contributors to
easily track their OSM-objects over time:

> As, independent of any other concerns, a matter of good form, I would
> want to point out that there is no such thing as ownership of
> OSM-objects, and discussing a concept of "their OSM-objects" is
> starting the discussion on the wrong foot.

I intentionally
avoided the word "own". What I mean is that our users touch a number of
objects by either creating, changing or removing them. Is that correct?

Every time this happens I would like OSM to log that in such a way that
it is possible to track the object (even if the osmid changes). This of
course comes at a cost with every changeset, but I think its worth it
because it makes it possible for users to "follow" an object.

https://wiki.openstreetmap.org/wiki/Database lists our current data
model for anyone interested.

/pangoSE


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

Re: [OSM-talk] New API suggestion: Allowing contributors to easily track their OSM-objects over time

[pangoSE]

Hi mmd 

mmd  skrev: (22 augusti 2020 13:41:00 CEST)
>On 2020-08-22 11:08, pangoSE wrote:
>> The system can then be queried lke this:
>> 
>> IMPLEMENTATION SUGGESTION:
>> 
>> GET Openstreetmap.org/api/userobjects/pangoSE
>> Outputs objects for user pangoSE with the oldest first (outputs 10
>> entries,  can be used to get more,  can be used to output
>up
>> to 300 entries, _date=desc by default)
>
>I don't think this is in any way feasible for the main API (and it
>wouldn't fit its main purpose as editing API due to the analytical
>nature of this request).

But the notes API is not strictly speaking related to editing either is it? It 
could also have been created as a thirdparty feature because it has no 
connections to osm objects anyway.

You could say the same about gpx points and tracks as well.

This is clearly visible in the model: 
https://wiki.openstreetmap.org/wiki/File:OSM_DB_Schema_2016-12-13.svg

>
>OTOH, I know that some people monitor dozens of boundary relations for
>any changes via a single Overpass API queries. If you run your own
>Overpass instance, and feed it with a list of object ids, you already
>have your solution, and we can stop the discussion right here.

What I want as an individual is not relevant here IMO and setting up highly 
technical software is not going to help the average editor. 

I'm interested in discussing the data model and why this is a core OSM feature 
we should work together towards supporting.

>
>Transitions from "I used to be a node, and now live on as way" are more
>complex to deal with. At least you would find out that the node ceases
>to exist at one point.

Yeah I'm guessing this will have to be handled somehow. Maybe we should first 
add permanent ids (new table) and reference that.

>
>By the way, quite a number of people have come up with your suggestion
>before, and those projects always projects fail due to the sheer size
>of
>OSM data. 

Interesting that I'm not the first. I did not hear about any others until 
today. I guess its ahard problem then. I'll take that as a challenge 
I see the table sizes here:
https://wiki.openstreetmap.org/wiki/Database/TableInfoDump

Permanent ids would add some GBs in a new table to represent each one of the 
many nodeids. What is the current rowcount on the current_nodes table?

>OWL (that was one project that was mentioned as GSoC project
>in another thread) never took off exactly for that reason.

Thanks for the pointer. I found https://wiki.openstreetmap.org/wiki/OWL 
unfortunately it is not stated there why the initiative failed. If someone 
could clarify that I would be happy to learn more. It does seem quite different 
from my suggested implementation.

I suggest we add a new tables in the main database instead like we did with 
notes (2 new tables). What exactly they should contain depend on the way 
forward we choose.

The information we need to store on every changeset is:
Link between userid and a new permid that is permanent or link between userid 
and node/way/relation ids

A permanent id is really something that could benefit us in many ways. It could 
make it possible to reliably link to an object over time which is important in 
integrations. 

So one new table for permanent ids that is updated every time:
* a node is created or deleted
* a way is created from scratch or deleted
* a relation is created from scratch or deleted
* a way is converted to a relation and then deleted (retains the ways permanent 
id)
* a node is converted to a way
*...

I'm not sure about all the possible transformations, are they already 
documented somewhere? 

Cheers
PangoSE 

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

Re: [OSM-talk] Call for verification (Was: Re: VANDALISM !)

[pangoSE]

Hi

Jo  skrev: (22 augusti 2020 11:44:49 CEST)
>On Sat, Aug 22, 2020, 11:30 pangoSE  wrote:
>
>> Hi 
>>
>> Mateusz Konieczny  skrev: (22 augusti 2020
>> 10:51:49 CEST)
>> >(1) Wikipedia may strongly encourage or mandate it in theory, but
>there
>> >are
>> >still edits being made without any citations
>>
>> Yeah I know, but the point is its really hard to create a new article
>in
>> WP without references without it being flagged for deletion. So by
>> "threatening" with deletion they raise the bar for inclusion and
>hence
>> hopefully raise the quality too. We have no system to flag for
>deletion,
>> nor to verify an object.
>>
>
>I find this highly annoying on Wikipedia and it is the reason I don't
>contribute there anymore.

Interesting. I guess you are not the only because  
https://en.m.wikipedia.org/wiki/Deletionpedia exist. 
I don't propose we annoy our users the same way, because the downside is fewer 
editors.

I guess its a choice on an continuum between general low quality edits and many 
editors and generally higher quality edits and fewer editors.

Right now OSM accepts almost any crap edit you can throw at it with a big thank 
you and we have no really good way of measuring the quality of what remains 
after our sometimes spotty QA. 

I would like to help change that by providing better tools for verification and 
follow up of things you added/edited in the past.

I would very much love a telegram bot flagging a new user making an edit to an 
object I help curate, but no such tool exist to my knowledge today.

WDYT? Would such a tool be nice to have?

Cheers
pangoSE 

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

Re: [OSM-talk] Let's think about how we use mailing lists (was: Re: Call for verification (Was: Re: VANDALISM !))

[pangoSE]

Thanks for the heads up. Words are really powerful so its wise to weigh them 
carefully before disclosure. 

I have no intentions of highlighting the errors of others just for the sake of 
it. Individual errors are not interesting, but they can give input to a healthy 
discussion. 

I have ideas for improving OSM and raise the quality. I can see that it helps 
to be friendly and diplomatic so I'll try being that.

I will try moderate my criticism and sleep on it when I have something to 
suggest instead of posting right away.

I'm really passionate sometimes and I guess it spills over into my emails.

No harm intended.

Have a nice day.

Cheers 
pangoSE 

Andy Townsend  skrev: (22 augusti 2020 11:23:11 CEST)
>On 22/08/2020 09:12, pangoSE wrote:
>> Here is yet another example of bad data in our database:
>>
>(to "pangoSE", via the list):
>
>Sometimes it helps to think about how we react to things in the spur of
>
>the moment.  Martijn's anecdote was about something that he mapped 9 
>years ago that was _correct at the time_ .
>
>People occasionally claim that open mailing lists are "toxic" or 
>similar, because they allow people to say things quickly without 
>thinking, and anything posted can't later be deleted because it has
>been 
>emailed to everyone.  Posts like the above don't help people who might 
>be reserved about posting here from doing so.
>
>Some of your recent posts (e.g. 
>https://lists.openstreetmap.org/pipermail/talk/2020-August/085281.html
>) 
>look indistinguishable from those that a troll might make to me.  You 
>probably don't think of yourself as a troll - you just thing that you 
>are asking "serious and pertinent questions". You're right that there's
>
>a discussion to be had about exactly how OSM and wikipedia et al are 
>linked, but taking unrelated comments out of context doesn't help your 
>argument - it'll just make it more likely that people will file all of 
>your posts in the "round filing cabinet in the corner of the room" 
>rather than read them.
>
>Best Regards,
>
>Andy (writing in a personal capacity, and not - thankfully - any sort
>of 
>list moderator here)
>
>
>
>___
>talk mailing list
>talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Call for verification (Was: Re: VANDALISM !)

[pangoSE]

Hi 

Mateusz Konieczny  skrev: (22 augusti 2020 10:51:49 
CEST)
>(1) Wikipedia may strongly encourage or mandate it in theory, but there
>are
>still edits being made without any citations

Yeah I know, but the point is its really hard to create a new article in WP 
without references without it being flagged for deletion. So by "threatening" 
with deletion they raise the bar for inclusion and hence hopefully raise the 
quality too. We have no system to flag for deletion, nor to verify an object. 

>
>(2) Wikipedia is explicitly forbidding original research, OSM is
>explicitly encouraging it
>The best edits are where people map things not mapped anywhere else,
>or at least not mapped in any other open data source.

Is this relevant to the discussion?  I proposed a button that makes it easy for 
a user to state
1) I attest this is correct (no proof or anything required)

NOTE: a malicious user could of course mark all objects in the database as 
verified, so we probably need a way to handle vandalism, but my implementation 
is a first draft so feel free to suggest improvements. 

>
>It makes impossible to require citations for everything and requiring
>people
>to contribute to Mapillary or equivalent would be an unreasonable
>burden.

I'm not suggesting requiring that, but we should motivate the user to reference 
a source and make it dead simple to do so. But this is off topic for this 
thread IMO and we probably need a new system for that too because our current 
changeset references does not add much value IMO.

>
>(3) Yes, better verification tools would be likely better.

So what do you think about the proposed system?

>
>(4) Have you seen 
>https://wiki.openstreetmap.org/wiki/Microgrants/Microgrants_2020/Proposal/Map_Maintenance_with_StreetComplete
>(BTW, I really need to finish my resurvey opening hours quest for
>StreetComplete).

No. Thanks for the link 

Cheers
pangoSE 

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

Re: [OSM-talk] [Tagging] Call for verification (Was: Re: VANDALISM !)

[pangoSE]

Thanks for sharing. I have no intention of contacting the user in question. It 
was just an illustrative example.

I don't know why this was posted to the tagging list. I intend to keep this 
discussion on the talk list so please respond there to keep the discussion 
together.


Cj Malone  skrev: (22 augusti 2020 
10:51:10 CEST)
>On Sat, 2020-08-22 at 09:32 +0200, pangoSE wrote:
>> Building upon it can lead to strange things. E.g. 
>>
>https://www.nyteknik.se/popularteknik/mystisk-jatteskrapa-dok-upp-i-flygsimulator-6999771
>>  (building:levels=212 was entered erroneously and committed to the
>> database without any kind of QA follow-up. If someone knows the
>> osmid I would like to know how long this error was present in OSM)
>
>https://www.openstreetmap.org/way/712475718/history
>
>1 - It was introduced by a novice mapper, presumably as a typeo.
>
>2 - Nikolas von Randow fixed it about 9 months later, presumably with
>some kind of QA tool (maybe just a overpass query).
>
>3 - Another local novice mapper also edited it, and fixed another issue
>at the same time. Presumably noticed via a rendered map.
>
>
>Before criticising the mapper, it should be noted that it was a novice
>mapper and the existing building data in the area isn't of great
>quality anyway. This wasn't a regression. And accidents happen anyway,
>I've done a similar thing via StreetComplete where I entered the house
>number in the building levels quest.
>
>The big companies doing QA on OSM data (Mapbox and Facebook) have a
>high focus on vandalism. They are trying to stop "Jewtropolis" from
>ever happening again.
>
>
>
>___
>Tagging mailing list
>tagg...@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] New API suggestion: Allowing contributors to easily track their OSM-objects over time

[pangoSE]

Hi

I would like to track all objects that I ever created or edited.
I suggest we implement a system to make this easy.

I suggest we create a new system that is updated every time a changeset is 
uploaded. The new system tracks userids and osmids and date of last change/edit.

When I create or edit an object an entry is made in this system (if a way is 
converted to relation the relation id is added and so forth). If another user 
converts my way to a relation the system edits the userobjects table of both 
users. This works around the problem of missing permanent ids. If a node, way 
or relation is deleted by anyone the row in my userobjects is deleted)

The system can then be queried lke this:

IMPLEMENTATION SUGGESTION:

GET Openstreetmap.org/api/userobjects/pangoSE
Outputs objects for user pangoSE with the oldest first (outputs 10 entries, 
 can be used to get more,  can be used to output up to 300 entries, 
_date=desc by default)

The osmids of the objects can then be used to query the suggested verification 
endpoint to easily find old userobjects that are stale and need reverification. 
The user can be used to generate maps and gpx exports of all osmids needing 
verification for the user to use during a mapping quest.

This data is privacy sensitive so the endpoint should require permissions from 
the user to make it easy to write a script or service that uses the data on 
behalf of the user.

WDYT?

Cheers 
pangoSE
-- 
Skickat från min Android-enhet med k9.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Call for verification (Was: Re: VANDALISM !)

[pangoSE]

Hi again

Mateusz Konieczny via talk  skrev: (22 augusti 2020 
10:20:51 CEST)
>Nobody claims OpenStreetMap data contains no mistakes.
>
>Are you really expecting that we will be shocked by proof that
>some data somewhere is wrong?

No. Are you shocked by my constructive criticism and constructive suggestions 
for improvement of what I perceive as a problem? 


>Please stop posting about every single inaccurate data in OSM that you
>managed to notice.

You seem to have the impression that I'm going to spam the list with examples 
of errors. Where did you get that idea from? I only included Marjins example 
because it showed 2 things related to my call for verification:

1) people capable of mapping correctly can produce map errors because our 
subject changes over time. This means that what I map today correctly might be 
incorrect next month or next year.

2) Martijn had the intention of producing high quality data but we as a 
community did not help him archive that over time because we have no system 
e.g. that could alert him if an object he created has not been verified/changed 
for the last x years. I would love to have a telegram bot notify me when one of 
my objects has passed a certain threshold of staleness.

Cheers 
pangoSE

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

Re: [OSM-talk] Call for verification (Was: Re: VANDALISM !)

[pangoSE]

Hi 

Mateusz Konieczny  skrev: (22 augusti 2020 09:55:10 
CEST)
>"It a playground with half-ass quality more than an authoritative and
>verified source of information (like e.g. Wikipedia)"
>
>I am not sure whatever you claim that
>Wikipedia is
>"playground with half-ass quality" or
>"authoritative and verified source of information".

I meant that a verification system does exist in Wikipedia and they now require 
references on all statements to keep up the quality of the articles which is 
sane IMO. We have no such system.

>OSM would benefit from better verification
>tools and so on but insult-laden post
>filed with misunderstandings will not
>lead towards them.

Sorry if it came across as harsh, I get your point and will try to moderate my 
criticism a little more. 

I love OSM and have contributed a lot over the years and recommend it to 
everyone I meet who uses maps. 

I just sent a follow up email with a suggestion for implementing such a 
verification system.

I still believe we have data with bad quality in many places (in Sweden). I 
have to fix stuff often when I visit new places apart from all the stuff we are 
missing. We are basically trying to keep up with an ever changing surrounding 
without a good way to indicate our data quality. 

We can do better, but we need a new system that make it easy for contributors 
to verify our precious data (see my previous email).

Cheers
pangoSE

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

Re: [OSM-talk] Call for verification (Was: Re: VANDALISM !)

[pangoSE]

Here is yet another example of bad data in our database:

 Originalmeddelande 
Från: Martijn van Exel 
Skickat: 22 augusti 2020 00:33:24 CEST
Till: talk@openstreetmap.org
Ämne: Re: [OSM-talk] Use of OSM data without attribution

Curious anecdote: some AllTrails user apparently looked up a phone 
number for OSM US and called up Maggie. Turns out the complaint was 
about a trail that I originally mapped *blush*. In my defense, that was 
9 years ago, I haven't been to that part of town much since I moved, and 
nobody else updated the trail, which has since disappeared.

Here is the changeset in case you're interested: 
https://www.openstreetmap.org/changeset/89419938

Martijn
--

Maybe we should have some kind of system flagging objects that has not been 
edited for x number of years and rate all objects in the database according to 
this?

This would mean that a data consumer can decide based on the score if they want 
to include the information or not.

E.g. a high quality map should perhaps not contain objects with a revision 
older than 3 years (and no references or sources)

Or even better: we could implement a verification system with a log that can be 
queried easily.

IMPLEMENTATION SUGGESTION:

GET Openstreetmap.org/api/verifications/
Lists latest added verifications (outputs 10 entries,  can be used to 
get more,  can be used to output up to 300 entries)

GET Openstreetmap.org/api/verifications/1234
Outputs verifications for osmid 1234 with the newest first (outputs 10 entries, 
 can be used to get more,  can be used to output up to 300 entries)

POST Openstreetmap.org/api/verifications/1234
Add a new verification for osmid 1234

On openstreetmap.org we have a new button for every object "Verify this object 
exists and is correct" which stores the date and userid in the database.

In JOSM we could add the possibility to download verification data for all 
selected objects or from a new option in the download dialog.

The latest verification date and count of verifications could be made available 
in a separate dump.

If we had such a system I believe the map data quality could increase 
considerably by making it dead simple to hide hide old unverified data from 
e.g. openstreetmap.org. A high-quality map we can be proud of could also give 
an impetus to local mappers to revisit trails and verify them.

WDYT?

Cheers
pangoSE


pangoSE  skrev: (22 augusti 2020 09:32:09 CEST)
>Hi
>
>80hnhtv4agou--- via talk  skrev: (22 augusti
>2020 03:06:37 CEST)
>
>> 
>>Also there is no wiki on unverified edits.
>> 
>
>In OSM we don't yet have an established system for verification or
>accurate machine readable references for the data to my knowledge.
>
>This means the whole database is basically just a mess of biased data
>that one of our millions of editors thought should be included. Most
>objects have very few revisions and we have no idea about the overall
>quality or correctness. It a playground with half-ass quality more than
>an authoritative and verified source of information (like e.g.
>Wikipedia). Building upon it can lead to strange things. E.g.
>https://www.nyteknik.se/popularteknik/mystisk-jatteskrapa-dok-upp-i-flygsimulator-6999771
>(building:levels=212 was entered erroneously and committed to the
>database without any kind of QA follow-up. If someone knows the osmid I
>would like to know how long this error was present in OSM)
>
>We should really fix this and start a verification effort after
>implementing a sane verification model.
>
>___
>talk mailing list
>talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Call for verification (Was: Re: VANDALISM !)

[pangoSE]

Hi

80hnhtv4agou--- via talk  skrev: (22 augusti 2020 
03:06:37 CEST)

> 
>Also there is no wiki on unverified edits.
> 

In OSM we don't yet have an established system for verification or accurate 
machine readable references for the data to my knowledge.

This means the whole database is basically just a mess of biased data that one 
of our millions of editors thought should be included. Most objects have very 
few revisions and we have no idea about the overall quality or correctness. It 
a playground with half-ass quality more than an authoritative and verified 
source of information (like e.g. Wikipedia). Building upon it can lead to 
strange things. E.g. 
https://www.nyteknik.se/popularteknik/mystisk-jatteskrapa-dok-upp-i-flygsimulator-6999771
 (building:levels=212 was entered erroneously and committed to the database 
without any kind of QA follow-up. If someone knows the osmid I would like to 
know how long this error was present in OSM)

We should really fix this and start a verification effort after implementing a 
sane verification model.

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

Re: [OSM-talk] Roadmap for deprecation of name tags in OSM

[pangoSE]

See below

PangoSE skrev: (20 augusti 2020 15:55:11 CEST)
>It was certainly not a joke. The tags in OSM are IMO broken and cannot
>handle the social complexity it tries to model.
>
>One of the biggest problems is missing references to on the ground
>truth like e.g. images. 
>How would you e.g. state when you recorded a name from a sign and link
>to the image? You could do it in the changeset information but that
>means that anyone looking for the reference has to download/traverse
>the whole history of the object and find the changeset that changed the
>name.
>
>The problem with that is that it is nearly impossible to e.g. create a
>script that e.g. check how many of our millions of names we have are
>properly referenced with either an URL or a link to an image or a good
>source like say the Swedish Geographical Survey Organizaion
>(Lantmäteriet).
>This means that the community is not able to easily judge whether the
>names we have on objects today are actually real or on the ground truth
>and it is also impossible to e.g. create a list of those that are not
>referenced at all in your local area and look up references and add
>them to the database. 
>
>This is really bad IMO and a suboptimal way of designing a world wide
>database handling cultural references and data about human objects
>sourced from millions of individuals. I would go so far as to say that
>ignoring this problem with missing references makes the names in the
>whole database worthless to use and contribute to because it could just
>be random joe next door sitting on a late night and adding/changing a
>lot of crap names wi h a handful of new accounts to the database
>objects and no-one regularly does QA-checks to see if it has any link
>to reality. 
>
>Additionally the tags and their changes over time is really hard to
>follow on openstreetmap.org (it is much better in JOSM though). Thats
>bad because it means less eyeballs to make sure we have correct
>information. A wiki-like interface for all our metadata would solve
>both these examples and for good reasons wikidata is not the right
>place for this data, but a community run wikibase could probably work
>just fine.
>
>WDYT?
>
>Dave F via talk  skrev: (20 augusti 2020
>14:35:21 CEST)
>>Just caught up with this thread, & I'm unsure if it's a joke.
>>
>>If there are any problems/disagreements with names in OSM then surely 
>>the same problem occurs in Wikiland?
>>
>>DaveF.
>>
>>
>>On 09/08/2020 09:25, pangoSE wrote:
>>> I suggest we create a roadmap for deprecating of storing and
>updating
>>
>>> names in OSM for objects with a Wikidata tag.
>>>
>>> The rationale is explained here:
>>> https://josm.openstreetmap.de/ticket/19655
>>>
>>> This of course affects the whole project and data consumers as well.
>
>>> Every OSM user will have to become a Wikidata user as well to edit
>>the 
>>> names or add name references (through the editors)
>>>
>>> Substantial changes will have to be made:
>>> * nominatim will need to support fetching names from wikidata
>>somehow. 
>>> It could probably be done on the fly.
>>> * openstreetmap.org will need to fetch from wikidata when displaying
>
>>> any object.
>>> * rendering the standard map will have to support fetching from
>>wikidata.
>>> * all editors would have to fetch and enable editing of Wikidata
>>objects.
>>> * maybe it no longer makes sense to have 2 separate logins? We
>should
>>
>>> unify the logging in as much as possible. Ideas are welcome on how
>to
>>
>>> do that. Perhaps retire signing up as OSM user on osm.org and ask 
>>> users to create a Wikimedia account instead and log in with that?
>>>
>>> I personally don't see any problems connecting Wikimedia and OSM 
>>> closer than the islands they are today.
>>>
>>> As mentioned in the ticket above data consumers like Mapbox already 
>>> prefer Wikidata names. I'm guessing thats because they are simply 
>>> better quality, better modeled, better referenced and better
>>protected 
>>> against vandalism.
>>>
>>> WDYT?
>>>
>>> Cheers
>>> pangoSE
>>> Ps I choose this list because this not only relates to tagging, but
>>to 
>>> the wider ecosystem.
>>>
>>> ___
>>> talk mailing list
>>> talk@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk

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

Re: [Talk-se] städning av badplatser, import från Havs- och vattenmyndigheten

[pangoSE]

Hej

Trevligt initiativ. Är datan tydligt släppt osm CC0 nånstans?
I så fall föreslår jag följande:
Uppläggning av alla badplatser på Wikidata och sedan länka till Qid
från OSM på relevant objekt (jag kan hjälpa med detta om du vill). I
många fall bliver det då bara natural=sand eftersom att OSM kräver en
del för att badplatsen skal kunna markeras som en sådan (skylt som
absoluta minimum).

I OsmAnd har jag lyckats utmärkt att hitta badplatser på mina resor
genom att söka på "sand" (utöver badplatser) men då får man med lite
annat också såklart.

Jag har i går klargjort ytterliggare på
https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dbathing_place och
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpublic_bath
skillnaden mellan dem och vad som krävs som minimum för att använda
dessa etiketter (en skylt i förre fallet, en man-made byggnad eller
badanläggning i det senare, soptunna räcker inte).

Jag har även ändrat på
https://wiki.openstreetmap.org/wiki/Swimming_and_bathing så det nu
tydligt framgår att ett skylt är minimum pga. regeln om verifikation.

Mvh
pangoSE

Den Fri, 14 Aug 2020 07:34:40 +0200
skrev Re: [Talk-se] städning av badplatser, import från Havs- och
vattenmyndigheten:

> Jag använder sport=swimming, men har också problem med taggen känns
> knepigt utan en natural=beach, och det gör att jag aldrig kommer
> aldrig ihåg hur jag taggar badplatser e.g. vet jag att jag har gillat
> leisure=bathing_place, dokumentationen på wiki hjälper inte. Jag
> tycker egentligen att man också ska försöka tagga ställen som lämpar
> sig för att bada, men risken där är ju att det blir godtyckligt, om
> man inte hittar ett bra sätt att tagga på.
> 
> Vad är det du vill tagga egentligen, är det bara en badplats om det
> har en vägskylt, de som finns med i json filen, eller är det alla som
> finns i OSM?
> 
> Taggen sport=swimming är den enda som är generell, alla de andra är
> alldeles för specifika medans dessa taggarna samtidigt har allmänna
> namn som kan tolkas lite hur som helst.
> 
> På dina punkter 1,2,4 ja. Det är väl bara att publicera geojson?
> 
> Den tors 13 aug. 2020 22:14Tomas Marklund 
> skrev:
> 
> > *leisure=swimming_area *känns ändå som den minst dåliga taggen,
> > bortsett från att den egentligen förutsätter att det ska vara
> > "Enclosed natural water area inside a facility", vilket en vanlig
> > svensk badplats vid en sjö YTTERST sällan är. En svensk badplats är
> > markerade med vägmärke H15, sen gör man lite vad man vill där, inte
> > så uppstyrt :)
> >
> >
> > https://www.transportstyrelsen.se/sv/vagtrafik/Vagmarken/Lokaliseringsmarken-for-upplysning-om-serviceanlaggningar-med-mera/Badplats/
> >
> >
> >
> > *sport=swimming* å andra sidan känns lite för.. fancy. Visst, det
> > kan finnas nån enstaka som simmar, som om det vore sport på
> > riktigt, men de flesta tror jag mest plaskar omkring, kastar bollar
> > till varandra, paddlar på en madrass eller gräver gropar som andra
> > badare snubblar i. Inte så värst "sport" med det liksom.
> >
> > Men det kanske bara är jag som tolkar taggen "sport" lite för
> > bokstavligt? Jag tänker, det är ingen som letar snäckor på en
> > sport=tennis, eller glider omkring på en luftmadrass på en
> > sport=speedway. Men på en sport=swimming är det inte så noga vad
> > man sysslar med egentligen? Jag tycker inte riktigt det är så
> > konsekvent.
> >
> > /Tomas
> >
> > Den tors 13 aug. 2020 kl 14:52 skrev Björn Stenberg :
> >  
> >> Trevligt initiativ, men jag håller inte med dig om taggningen.
> >>
> >> Jag tycker inte att en vanlig brygga eller enkla omklädningsrum
> >> räcker för att det ska vara amenity=public_bath. Wiki-sidan
> >> https://wiki.openstreetmap.org/wiki/Swimming_and_bathing håller
> >> med mig:
> >>
> >> "Public bath
> >> A facility where you can go and take a bath, e.g. an onsen, a hot
> >> spring, a hammam or a thermal bath. It must have something more
> >> than just showers, but it may be anything from bathtubs up to
> >> swimming pools. Large bath houses can have outside baths. A fee
> >> may be charged for entry. If membership is needed, set access to
> >> private. Tag the building, and if present also the outside
> >> premises with pools."
> >>
> >> "It must be more than just showers" tycker jag är ganska tydligt.
> >> De flesta vanliga enkla badplatser vid svenska sjöar har inte
> >> "facilities" i denna bemärkelse och är därför inte sådana
> >> offentliga badhus som amenity=public_bath avser.
> >>
> >> --
> >> Björn
> >> ___
> >> 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: [OSM-talk] Fwd: Re: Roadmap for deprecation of name tags in OSM

[pangoSE]

Could you reply with your arguments in favor of the current one2one tag model 
system in the other thread where I listed the benefits as I see them?

E.g. permanent unique ids, talk pages if we want that for every osmid, SPARQL 
support, standardization benefits "riding the current ride in open data", 
scripting support for botmakers, and above all support for references and 
linking interactively to other data sources.
Bots are very useful e.g. to notify an editor of a possible tagging mistake or 
checking urls of references. Martin could also reference an image in Wikimedia 
commons directly on the statement it relates to.

Unique Qids for every osm object that is decoupled from the underlying osmid 
gives some possibility we don't have today regarding integration with e.g. 
wikidata. 

Cheers

Mateusz Konieczny via talk  skrev: (9 augusti 2020 
20:14:03 CEST)
>It still fails to provide even a single benefit over the current
>situation.
>
>Aug 9, 2020, 20:11 by pang...@riseup.net:
>
>>
>>
>>
>>  Originalmeddelande 
>> Från: pangoSE 
>> Skickat: 9 augusti 2020 15:40:41 CEST
>> Till: talk@openstreetmap.org
>> Ämne: Re: [OSM-talk] Roadmap for deprecation of name tags in OSM
>>
>> This is another good reason to abandon this suggestion in favor of
>our own wikibase instance.
>>
>> Philip Barnes  skrev: (9 augusti 2020 15:12:21
>CEST)
>> >On Sun, 2020-08-09 at 09:04 -0400, James wrote:
>>
>>>> Not to mention if someone wants to add a name for a new
>item/object,
>>>> does the user need to create a wikidata item on top of it? Will the
>>>> editor do it automatically? How does it pick the right one? Does it
>>>> offer a list to the user? This is going to make osm a massive turn
>>>> off to new contributors on the steep learning curve(which is
>already
>>>> pretty high) to contributing to osm.
>>>> This whole idea is really terrible and could just be offered as a
>>>> post-processed data set: wikidata? use that instead of name tag.
>>>>
>> >This leads me to a fairly fundamental question, what if a mapper
>does
>> >not want to be associated with wikidata and refuses to sign up?
>> >Phil (trigpoint)
>>
>> -- 
>> Skickat från min Android-enhet med k9.
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Fwd: Re: Roadmap for deprecation of name tags in OSM

[pangoSE]

 Originalmeddelande 
Från: pangoSE 
Skickat: 9 augusti 2020 15:40:41 CEST
Till: talk@openstreetmap.org
Ämne: Re: [OSM-talk] Roadmap for deprecation of name tags in OSM

This is another good reason to abandon this suggestion in favor of our own 
wikibase instance.

Philip Barnes  skrev: (9 augusti 2020 15:12:21 CEST)
>On Sun, 2020-08-09 at 09:04 -0400, James wrote:
>> Not to mention if someone wants to add a name for a new item/object,
>> does the user need to create a wikidata item on top of it? Will the
>> editor do it automatically? How does it pick the right one? Does it
>> offer a list to the user? This is going to make osm a massive turn
>> off to new contributors on the steep learning curve(which is already
>> pretty high) to contributing to osm.
>> This whole idea is really terrible and could just be offered as a
>> post-processed data set: wikidata? use that instead of name tag.
>> 
>
>This leads me to a fairly fundamental question, what if a mapper does
>not want to be associated with wikidata and refuses to sign up?
>Phil (trigpoint)

-- 
Skickat från min Android-enhet med k9.

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

Re: [OSM-talk] Roadmap for deprecation of name tags in OSM

[pangoSE]

Hi

Martin Koppenhoefer  skrev: (9 augusti 2020 15:00:21 
CEST)
>
>
>sent from a phone
>
>> On 9. Aug 2020, at 10:44, Mateusz Konieczny via talk
> wrote:
>> 
>> tagging name tag is a fundamental  part of OSM tag,
>> offloading it to a third party service is a mistake that will not
>happen
>
>
>+1, names are a fundamental part of OpenStreetMap, we must keep the
>decision and authority in the project, decide on edge cases and
>contested values according to our rules and not based on someone else’s
>rules.

I wholeheartedly agree, integrating into wikidata is I not the best route 
forward, see the other thread about OSMData.

To support and emphasize ground truth I think we should setup a service like 
Wikimedia commons also to host verification images that proves how it looks on 
the ground.

Cheers

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

Re: [OSM-talk] Roadmap for deprecation of name tags in OSM

[pangoSE]

Yes. The data could be downloaded in bulk like osmand does today and can be 
easily parsed. 
We would of course have to split it into region or country sized files just 
like the planet files are today but thats trivial compared to integrating 
seamless support in the editors.

Wikidata dumps to json see 
https://m.wikidata.org/wiki/Wikidata:Database_download

Jeremy Harris  skrev: (9 augusti 2020 14:25:02 CEST)
>On 09/08/2020 09:25, pangoSE wrote:
>> I suggest we create a roadmap for deprecating of storing and updating
>names in OSM for objects with a Wikidata tag.
>
>> Substantial changes will have to be made:
>> * nominatim will need to support fetching names from wikidata
>somehow. It could probably be done on the fly.
>> * openstreetmap.org will need to fetch from wikidata when displaying
>any object. 
>> * rendering the standard map will have to support fetching from
>wikidata.
>
>How would that work for an offline renderer?
>Not everyone has, or wants to have, their phone connected 24/7.
>-- 
>Cheers,
>  Jeremy
>
>___
>talk mailing list
>talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Roadmap for deprecation of name tags in OSM

[pangoSE]

Yeah this is probably not the best route forward, given that wikidata is so big 
and contains a lot of osm unrelated data.

James  skrev: (9 augusti 2020 14:31:57 CEST)
>and if the solution is to download the data then download wikidata,
>it's
>even more clunky than the name tag itself
>
>On Sun., Aug. 9, 2020, 8:29 a.m. Jeremy Harris, 
>wrote:
>
>> On 09/08/2020 09:25, pangoSE wrote:
>> > I suggest we create a roadmap for deprecating of storing and
>updating
>> names in OSM for objects with a Wikidata tag.
>>
>> > Substantial changes will have to be made:
>> > * nominatim will need to support fetching names from wikidata
>somehow.
>> It could probably be done on the fly.
>> > * openstreetmap.org will need to fetch from wikidata when
>displaying
>> any object.
>> > * rendering the standard map will have to support fetching from
>wikidata.
>>
>> How would that work for an offline renderer?
>> Not everyone has, or wants to have, their phone connected 24/7.
>> --
>> Cheers,
>>   Jeremy
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Roadmap for deprecation of name tags in OSM

[pangoSE]

Ok. I agree with that, there is nothing hindering OSM from hosting the wikibase 
instance on the same machine/cluster/whatever as the main osm database which 
btw. seems to lack a name.

James  skrev: (9 augusti 2020 14:49:36 CEST)
>Network calls incur a performance hit. I didn't say it was complicated.
>
>On Sun., Aug. 9, 2020, 8:46 a.m. pangoSE,  wrote:
>
>>
>> I disagree. With (permanent) unique ids is trivial and the overhead
>is IMO
>> neglible.
>>
>> Its not rocket science to query an API endpoint from any programming
>> language. All our data consumers are already doing this.
>>
>> I made a simple map in a few hours that query both overpass and
>wikidata
>> based on the osmid to find links to images of shelters. See
>> https://github.com/pangoSE/sheltermap
>>
>> James  skrev: (9 augusti 2020 13:59:40 CEST)
>>>
>>> Not to mention the additional overhead of conflating two databases
>to get
>>> something essential like a name
>>>
>>> On Sun., Aug. 9, 2020, 7:57 a.m. Alan Mackie, 
>wrote:
>>>
>>>> This seems like a bad idea.
>>>>
>>>> Name tags are generally very easy to verify on the ground. It is
>not
>>>> always as easy to tell if a shop with a certain name belongs to a
>specific
>>>> wikidata entry, especially in jurisdictions that are less litigious
>when it
>>>> comes to trademarks.
>>>>
>>>> We also should not be doing bulk name changes until we have
>verified
>>>> that the signage on the individual locations has actually changed.
>>>> Depending on the brand these could take years to ripple through to
>the
>>>> individual stores, and particularly 'historic' stores may retain
>old
>>>> branding as part of a conscious effort not to irk locals. Branding
>changes
>>>> in the Wikidata would likely be over-applied.
>>>>
>>>> Abandoning the name tags for chains would essentially be
>carte-blanche
>>>> permission for automated edits. As it stands now, a disagreement
>between
>>>> OSM name and Wikidata name may be a useful indicator that resurvey
>is
>>>> needed. If we abandon name tags we open the door to the
>introduction of
>>>> dodgy data that isn't caught by any of our QA tools because it
>doesn't even
>>>> have a changeset.
>>>>
>>>> If "duplication"  is really an issue, I would prefer to remove all
>>>> Wikidata tags than to depreciate names where they exist. Forcing
>>>> contributors to check an independant database before uploading
>survey
>>>> results seems like a lot of extra effort for a volunteer driven
>project.
>>>>
>>>> On Sun, 9 Aug 2020 at 12:11, pangoSE  wrote:
>>>>
>>>>> These are valid concerns. See my response to James.
>>>>> If Wikimedia should become uncooperative we could easily set up
>our own
>>>>> wikibase installation. See https://www.wbstack.com/
>>>>>
>>>>> It takes a few minutes plus some configuration time.
>>>>>
>>>>> It would also be a new and currently unnecessary drain on OSMF's
>>>> resources.
>>>>
>>>> In fact this might be much better than forcing our data into
>wikidata
>>>>> which is very tied to education and does not accept all our
>objects that
>>>>> have names currently.
>>>>>
>>>>> In case we take this route I would recommend having another prefix
>than
>>>>> Q for our unique ids.
>>>>>
>>>>> Cheers
>>>>>
>>>>> Mateusz Konieczny via talk  skrev: (9
>augusti
>>>>> 2020 12:16:33 CEST)
>>>>>>
>>>>>> or has downtime? or deletes data/items used by OSM? or bans OSM
>>>>>> mappers?
>>>>>> or refuses to ban vandal/troll/harasser? or fails to ban them
>quickly?
>>>>>>
>>>>>> Aug 9, 2020, 11:45 by james2...@gmail.com:
>>>>>>
>>>>>> is there a contingency plan if wikipedia/wikimedia ceases to
>exist?
>>>>>>
>>>>>> On Sun., Aug. 9, 2020, 4:29 a.m. pangoSE, 
>wrote:
>>>>>>
>>>>>> I suggest we create a roadmap for deprecating of storing and
>updating
>>>>>> names in OSM for objects with a Wikidata tag.
>>>>>>
>>>>>> The rationale is explained here:
>>>>

Re: [OSM-talk] Roadmap for deprecation of name tags in OSM

[pangoSE]

Thanks 
I actually tried searching for it before posting but did not find it. 
I accept the statement from Lydia closing it:
"I've been thinking a lot about this. The prefixes Q, P, L, F, S, E and M are 
there to represent the concepts of Items, Properties, Lexemes, Forms, Senses, 
Entity Schemas and MediaInfo respectively. They are not intended as an 
indication of a specific Wikibase instance. Each entity type should be 
addressed with the same letter on every Wikibase instance. Distinction between 
individual Wikibase instances needs to happen with prefixes for example."

Our prefix could be "od:" for OSMData.

mmd  skrev: (9 augusti 2020 14:42:42 CEST)
>On 2020-08-09 14:33, pangoSE wrote:
>
>
>>> IIRC, Yuri already tried that when implementing Wikibase on our own
>>> wiki, and it turned out to be massively complicated, not to say not
>>> feasible at all. Didn't you follow that discussion back then?
>> 
>> I was not aware. Link? 
>> Its not a dealbreaker for me but it would be nice to avoid confusion
>for non SPARQL aware users.
>> 
>
>Here we go: https://phabricator.wikimedia.org/T202676
>
>
>-- 
>
>
>
>
>___
>talk mailing list
>talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Roadmap for deprecation of name tags in OSM

[pangoSE]

I disagree. With (permanent) unique ids is trivial and the overhead is IMO 
neglible. 

Its not rocket science to query an API endpoint from any programming language. 
All our data consumers are already doing this. 

I made a simple map in a few hours that query both overpass and wikidata based 
on the osmid to find links to images of shelters. See 
https://github.com/pangoSE/sheltermap

James  skrev: (9 augusti 2020 13:59:40 CEST)
>Not to mention the additional overhead of conflating two databases to
>get
>something essential like a name
>
>On Sun., Aug. 9, 2020, 7:57 a.m. Alan Mackie, 
>wrote:
>
>> This seems like a bad idea.
>>
>> Name tags are generally very easy to verify on the ground. It is not
>> always as easy to tell if a shop with a certain name belongs to a
>specific
>> wikidata entry, especially in jurisdictions that are less litigious
>when it
>> comes to trademarks.
>>
>> We also should not be doing bulk name changes until we have verified
>that
>> the signage on the individual locations has actually changed.
>Depending on
>> the brand these could take years to ripple through to the individual
>> stores, and particularly 'historic' stores may retain old branding as
>part
>> of a conscious effort not to irk locals. Branding changes in the
>Wikidata
>> would likely be over-applied.
>>
>> Abandoning the name tags for chains would essentially be
>carte-blanche
>> permission for automated edits. As it stands now, a disagreement
>between
>> OSM name and Wikidata name may be a useful indicator that resurvey is
>> needed. If we abandon name tags we open the door to the introduction
>of
>> dodgy data that isn't caught by any of our QA tools because it
>doesn't even
>> have a changeset.
>>
>> If "duplication"  is really an issue, I would prefer to remove all
>> Wikidata tags than to depreciate names where they exist. Forcing
>> contributors to check an independant database before uploading survey
>> results seems like a lot of extra effort for a volunteer driven
>project.
>>
>> On Sun, 9 Aug 2020 at 12:11, pangoSE  wrote:
>>
>>> These are valid concerns. See my response to James.
>>> If Wikimedia should become uncooperative we could easily set up our
>own
>>> wikibase installation. See https://www.wbstack.com/
>>>
>>> It takes a few minutes plus some configuration time.
>>>
>>> It would also be a new and currently unnecessary drain on OSMF's
>> resources.
>>
>> In fact this might be much better than forcing our data into wikidata
>>> which is very tied to education and does not accept all our objects
>that
>>> have names currently.
>>>
>>> In case we take this route I would recommend having another prefix
>than Q
>>> for our unique ids.
>>>
>>> Cheers
>>>
>>> Mateusz Konieczny via talk  skrev: (9
>augusti
>>> 2020 12:16:33 CEST)
>>>>
>>>> or has downtime? or deletes data/items used by OSM? or bans OSM
>mappers?
>>>> or refuses to ban vandal/troll/harasser? or fails to ban them
>quickly?
>>>>
>>>> Aug 9, 2020, 11:45 by james2...@gmail.com:
>>>>
>>>> is there a contingency plan if wikipedia/wikimedia ceases to exist?
>>>>
>>>> On Sun., Aug. 9, 2020, 4:29 a.m. pangoSE, 
>wrote:
>>>>
>>>> I suggest we create a roadmap for deprecating of storing and
>updating
>>>> names in OSM for objects with a Wikidata tag.
>>>>
>>>> The rationale is explained here:
>>>> https://josm.openstreetmap.de/ticket/19655
>>>>
>>>> This of course affects the whole project and data consumers as
>well.
>>>> Every OSM user will have to become a Wikidata user as well to edit
>the
>>>> names or add name references (through the editors)
>>>>
>>>> Substantial changes will have to be made:
>>>> * nominatim will need to support fetching names from wikidata
>somehow.
>>>> It could probably be done on the fly.
>>>> * openstreetmap.org will need to fetch from wikidata when
>displaying
>>>> any object.
>>>> * rendering the standard map will have to support fetching from
>wikidata.
>>>> * all editors would have to fetch and enable editing of Wikidata
>>>> objects.
>>>>
>>>> These seems like large burdens to dump on open source developers.
>>
>>> * maybe it no longer makes sense to have 2 separate logins? We
>should
>>

Re: [OSM-talk] Roadmap for deprecation of name tags in OSM

[pangoSE]

Hi

mmd  skrev: (9 augusti 2020 13:47:43 CEST)
>On 2020-08-09 13:05, pangoSE wrote:
>> These are valid concerns. See my response to James.
>> If Wikimedia should become uncooperative we could easily set up our
>own
>> wikibase installation. See https://www.wbstack.com/
>
>Our own Wiki.openstreetmap.org already has a wikibase installed. You're
>not proposing to install another one?

Yes I am.

>
>
>> In case we take this route I would recommend having another prefix
>than
>> Q for our unique ids.
>> 
>
>IIRC, Yuri already tried that when implementing Wikibase on our own
>wiki, and it turned out to be massively complicated, not to say not
>feasible at all. Didn't you follow that discussion back then?

I was not aware. Link? 
Its not a dealbreaker for me but it would be nice to avoid confusion for non 
SPARQL aware users.

Cheers 

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

[OSM-talk] Separating all metadata from coordinates in OSM into a wikibase instance (Was: Re: Roadmap for deprecation of name tags in OSM)

[pangoSE]

Hi

The discussion below spawned the following idea of migrating the whole tags 
system instead.

Remember we OSM contributors are in the "business" of generating high quality 
geo- AND metadata with references ideally for every single change or statement 
and ideally linked to other data sources about the physical world.

The geodata handling in OSM is IMO superb. 

Unfortunately the metadata is handled less nice because they are not linked 
data with a unique id and not individually referencable. 

I really dislike the current osm tags system. Its IMO not the best way anno 
2020 to handle metadata and should be fixed as soon as possible.
I therefore suggest we create a wikibase instance called OSMData and migrate 
all our tags into that system.

Of course this is also a big change which has to be considered carefully.

I believe linked data is the only sane way to go forward when it comes to 
metadata.

What I'm suggesting here is to migrate from our own special purpose legacy tags 
system very specific to osm to a more standardized linked data storage model 
based on unique identifiers instead.

This would make it much easier for others to handle our non-geographic data and 
to create validations on the languages used, tag combination used, etc. It 
could simply link to wikidata when needed e.g. for labels of countries, cities, 
etc.

We would also in get unique ids for all osm objects, which is very very nice.

The js interface of wikibase is unfortunately quite horrible IMO, but I believe 
our editors can easily be adapted to update osmdata in the wikibase via the 
REST API so that most mappers won't have to visit the wikibase UI at all.

I also suggest that we carefully consider what license we want for this 
metadata. I personally suggest CC0.
All the geographic data in OSM remains the current license.

This protects all the hard labor of gathering and verifying coordinates and 
makes it easier to share metadata and for data consumers to integrate osmdata 
and wikidata (except the coordinates).

I have not thought a lot about the implications for this license change for the 
metadata but it really makes no sense to restrict public metadata in general 
IMO. It would help wikidata and the open data movement a lot as you would be 
able to e.g. crosscheck the names of all hospitals in Kenya and add missing 
names in either project without worrying about license restrictions. Or list 
missing hospitals in either project that appears in the other. Or list 
differing names/labels and compare the references, etc.

None of the above examples are easy to do today as the author of the brilliant 
https://github.com/EdwardBetts/osm-wikidata/ can surely testify to. In a SPARQL 
linked data world these would be rather simple queries crafted in a few minutes 
by an experienced SPARQL query editor which we already have in our community.

Cheers
pangoSE
PS: The past introduction of wikibase as an addon to osmwiki is unfortunate 
because it does not seem to have resulted in many benefits and have maybe given 
some osm contributers a negative image of linked data. Its really very 
different from what I propose here.

pangoSE  skrev: (9 augusti 2020 13:05:54 CEST)
>These are valid concerns. See my response to James.
>If Wikimedia should become uncooperative we could easily set up our own
>wikibase installation. See https://www.wbstack.com/
>
>It takes a few minutes plus some configuration time.
>
>In fact this might be much better than forcing our data into wikidata
>which is very tied to education and does not accept all our objects
>that have names currently.
>
>In case we take this route I would recommend having another prefix than
>Q for our unique ids.
>
>Cheers
>
>Mateusz Konieczny via talk  skrev: (9 augusti
>2020 12:16:33 CEST)
>>or has downtime? or deletes data/items used by OSM? or bans OSM
>>mappers?
>>or refuses to ban vandal/troll/harasser? or fails to ban them quickly?
>>
>>Aug 9, 2020, 11:45 by james2...@gmail.com:
>>
>>> is there a contingency plan if wikipedia/wikimedia ceases to exist?
>>>
>>> On Sun., Aug. 9, 2020, 4:29 a.m. pangoSE, <> pang...@riseup.net> >
>>wrote:
>>>
>>>> I suggest we create a roadmap for deprecating of storing and
>>updating names in OSM for objects with a Wikidata tag.
>>>>
>>>> The rationale is explained here:
>>>> https://josm.openstreetmap.de/ticket/19655
>>>>
>>>> This of course affects the whole project and data consumers as
>well.
>>Every OSM user will have to become a Wikidata user as well to edit the
>>names or add name references (through the editors)
>>>>
>>>> Substantial changes will have to be made:
>>>> * nominatim will need to support fetching names from wikidata
>>somehow. It c

Re: [OSM-talk] Roadmap for deprecation of name tags in OSM

[pangoSE]

These are valid concerns. See my response to James.
If Wikimedia should become uncooperative we could easily set up our own 
wikibase installation. See https://www.wbstack.com/

It takes a few minutes plus some configuration time.

In fact this might be much better than forcing our data into wikidata which is 
very tied to education and does not accept all our objects that have names 
currently.

In case we take this route I would recommend having another prefix than Q for 
our unique ids.

Cheers

Mateusz Konieczny via talk  skrev: (9 augusti 2020 
12:16:33 CEST)
>or has downtime? or deletes data/items used by OSM? or bans OSM
>mappers?
>or refuses to ban vandal/troll/harasser? or fails to ban them quickly?
>
>Aug 9, 2020, 11:45 by james2...@gmail.com:
>
>> is there a contingency plan if wikipedia/wikimedia ceases to exist?
>>
>> On Sun., Aug. 9, 2020, 4:29 a.m. pangoSE, <> pang...@riseup.net> >
>wrote:
>>
>>> I suggest we create a roadmap for deprecating of storing and
>updating names in OSM for objects with a Wikidata tag.
>>>
>>> The rationale is explained here:
>>> https://josm.openstreetmap.de/ticket/19655
>>>
>>> This of course affects the whole project and data consumers as well.
>Every OSM user will have to become a Wikidata user as well to edit the
>names or add name references (through the editors)
>>>
>>> Substantial changes will have to be made:
>>> * nominatim will need to support fetching names from wikidata
>somehow. It could probably be done on the fly.
>>> * >> openstreetmap.org <http://openstreetmap.org>>>  will need to
>fetch from wikidata when displaying any object. 
>>> * rendering the standard map will have to support fetching from
>wikidata.
>>> * all editors would have to fetch and enable editing of Wikidata
>objects. 
>>> * maybe it no longer makes sense to have 2 separate logins? We
>should unify the logging in as much as possible. Ideas are welcome on
>how to do that. Perhaps retire signing up as OSM user on >> osm.org
><http://osm.org>>>  and ask users to create a Wikimedia account instead
>and log in with that? 
>>>
>>> I personally don't see any problems connecting Wikimedia and OSM
>closer than the islands they are today.
>>>
>>> As mentioned in the ticket above data consumers like Mapbox already
>prefer Wikidata names. I'm guessing thats because they are simply
>better quality, better modeled, better referenced and better protected
>against vandalism.
>>>
>>> WDYT?
>>>
>>> Cheers
>>> pangoSE
>>> Ps I choose this list because this not only relates to tagging, but
>to the wider ecosystem.___
>>>  talk mailing list
>>>  >> talk@openstreetmap.org
>>>  >> https://lists.openstreetmap.org/listinfo/talk
>>>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Roadmap for deprecation of name tags in OSM

[pangoSE]

Also a valid concern worth pondering. I guess having a local snapshot of 
wikidata on an osm controlled server should fix that. 

Wikibase is free software so we can set up our own in the very unlikely case 
that no-one else does it. 

Note that both Facebook, Microsoft and Google are dependent on wikidata now so 
it is very unlikely that it will cease to exist for the near future. 

If it ever becomes unstable someone is going to fork it rather quickly I think. 


James  skrev: (9 augusti 2020 11:45:02 CEST)
>is there a contingency plan if wikipedia/wikimedia ceases to exist?
>
>On Sun., Aug. 9, 2020, 4:29 a.m. pangoSE,  wrote:
>
>> I suggest we create a roadmap for deprecating of storing and updating
>> names in OSM for objects with a Wikidata tag.
>>
>> The rationale is explained here:
>> https://josm.openstreetmap.de/ticket/19655
>>
>> This of course affects the whole project and data consumers as well.
>Every
>> OSM user will have to become a Wikidata user as well to edit the
>names or
>> add name references (through the editors)
>>
>> Substantial changes will have to be made:
>> * nominatim will need to support fetching names from wikidata
>somehow. It
>> could probably be done on the fly.
>> * openstreetmap.org will need to fetch from wikidata when displaying
>any
>> object.
>> * rendering the standard map will have to support fetching from
>wikidata.
>> * all editors would have to fetch and enable editing of Wikidata
>objects.
>> * maybe it no longer makes sense to have 2 separate logins? We should
>> unify the logging in as much as possible. Ideas are welcome on how to
>do
>> that. Perhaps retire signing up as OSM user on osm.org and ask users
>to
>> create a Wikimedia account instead and log in with that?
>>
>> I personally don't see any problems connecting Wikimedia and OSM
>closer
>> than the islands they are today.
>>
>> As mentioned in the ticket above data consumers like Mapbox already
>prefer
>> Wikidata names. I'm guessing thats because they are simply better
>quality,
>> better modeled, better referenced and better protected against
>vandalism.
>>
>> WDYT?
>>
>> Cheers
>> pangoSE
>> Ps I choose this list because this not only relates to tagging, but
>to the
>> wider ecosystem.___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Fwd: Re: Roadmap for deprecation of name tags in OSM

[pangoSE]

This was meant for the list.


 Originalmeddelande 
Från: pangoSE 
Skickat: 9 augusti 2020 11:09:08 CEST
Till: Mateusz Konieczny 
Ämne: Re: [OSM-talk] Roadmap for deprecation of name tags in OSM

Hi

Thanks for the response. 


Mateusz Konieczny via talk  skrev: (9 augusti 2020 
10:42:21 CEST)
>Aug 9, 2020, 10:25 by pang...@riseup.net:
>
>> I suggest we create a roadmap for deprecating of storing and updating
>names in OSM for objects with a Wikidata tag.
>>
>Absolutely no.
>
>tagging name tag is a fundamental  part of OSM tag,
>offloading it to a third party service is a mistake that will not
>happen

I disagree. Redundancy is a problem waiting to be solved.

>
>https://josm.openstreetmap.de/ticket/19655 contains several misleading,
>wrong, mistaken
>and problematic claims, statements and implications but I have no time
>to process in detail
>as the entire idea is fundamentally bad, mistaken, problematic, broken,
>not workable,
>not acceptable, not going to happen and wrong.

I disagree. The current handling of names in osm is redundant in many cases and 
badly broken when it comes to references.

>
>Some samples:
>
>"there is no such thing as an international name. Names are part of a
>language whih is part of a culture. They are not GIS objects and the 
>osm datamodel does not handle this complexity well at all."
>
>Are you aware that we have other tags beyond name tag?

Yes

>
>loc_name, name:pl and many others?

Yes. This is not a blocker. For loc_name and others a new wikidata property can 
be created.

>
>"No more name vandalism in osm. We export the name handling to
>wikidata which has a much better system for handling vandalism."
>
>Because vandalism in third-party service is superior?
>Are you seriously claiming that Wikidata has less trouble with
>vandalism
>and deals with it better?

Yes. The new york defacement could most probably have been avoided wih this 
approach. I have no statistics to back up this claim though.

If anyone have statistics I would love to read them.

Cheers___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Roadmap for deprecation of name tags in OSM

[pangoSE]

This is a valid concern. What I'm suggesting to solve that is to create a new 
property "OpenStreetMap name" that can hold names in multiple languages and 
every single one can be independently referenced.

Cheers

Simon Poole  skrev: (9 augusti 2020 10:36:34 CEST)
>The "names" in wikidata are mostly the names of WP pages for the object
>in question and have little to do with actually existing names (as per
>the OSM definition) of places.
>
>It would be a massive drop in quality if we would do the proposed
>switch.
>
>Simon
>
>Am 09.08.2020 um 10:25 schrieb pangoSE:
>> I suggest we create a roadmap for deprecating of storing and updating
>> names in OSM for objects with a Wikidata tag.
>>
>> The rationale is explained here:
>> https://josm.openstreetmap.de/ticket/19655
>>
>> This of course affects the whole project and data consumers as well.
>> Every OSM user will have to become a Wikidata user as well to edit
>the
>> names or add name references (through the editors)
>>
>> Substantial changes will have to be made:
>> * nominatim will need to support fetching names from wikidata
>somehow.
>> It could probably be done on the fly.
>> * openstreetmap.org will need to fetch from wikidata when displaying
>> any object.
>> * rendering the standard map will have to support fetching from
>wikidata.
>> * all editors would have to fetch and enable editing of Wikidata
>objects.
>> * maybe it no longer makes sense to have 2 separate logins? We should
>> unify the logging in as much as possible. Ideas are welcome on how to
>> do that. Perhaps retire signing up as OSM user on osm.org and ask
>> users to create a Wikimedia account instead and log in with that?
>>
>> I personally don't see any problems connecting Wikimedia and OSM
>> closer than the islands they are today.
>>
>> As mentioned in the ticket above data consumers like Mapbox already
>> prefer Wikidata names. I'm guessing thats because they are simply
>> better quality, better modeled, better referenced and better
>protected
>> against vandalism.
>>
>> WDYT?
>>
>> Cheers
>> pangoSE
>> Ps I choose this list because this not only relates to tagging, but
>to
>> the wider ecosystem.
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Roadmap for deprecation of name tags in OSM

[pangoSE]

I suggest we create a roadmap for deprecating of storing and updating names in 
OSM for objects with a Wikidata tag.

The rationale is explained here:
https://josm.openstreetmap.de/ticket/19655

This of course affects the whole project and data consumers as well. Every OSM 
user will have to become a Wikidata user as well to edit the names or add name 
references (through the editors)

Substantial changes will have to be made:
* nominatim will need to support fetching names from wikidata somehow. It could 
probably be done on the fly.
* openstreetmap.org will need to fetch from wikidata when displaying any 
object. 
* rendering the standard map will have to support fetching from wikidata.
* all editors would have to fetch and enable editing of Wikidata objects. 
* maybe it no longer makes sense to have 2 separate logins? We should unify the 
logging in as much as possible. Ideas are welcome on how to do that. Perhaps 
retire signing up as OSM user on osm.org and ask users to create a Wikimedia 
account instead and log in with that? 

I personally don't see any problems connecting Wikimedia and OSM closer than 
the islands they are today.

As mentioned in the ticket above data consumers like Mapbox already prefer 
Wikidata names. I'm guessing thats because they are simply better quality, 
better modeled, better referenced and better protected against vandalism.

WDYT?

Cheers
pangoSE
Ps I choose this list because this not only relates to tagging, but to the 
wider ecosystem.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-dk] Åbne data om lejrpladser fra kommuner

[pangoSE]

Jeg har fundet disse datasæt 
https://www.opendata.dk/search?q=shelter=score%3Adesc

Er det noget vi kan bruge til noget?
Er der nogle der ved om naturstyrelsens billeder har fri licens? Fx på siden 
som linkes her: https://www.openstreetmap.org/way/575879617

Jeg skulle vilje at så meget data og beskrivelser og billeder kommer op når jeg 
klikker på en af disse lejrpladser i OsmAnd. OsmAnd støtter nu at vise billeder 
fra lænkede wikidata objekt. Dvs vi kan gemme alle lange beskrivelser og 
grunddata i wikidata og bare lænke til det fra OSM så vi slipper 
dobbeltarbejde. 

I er meget velkomne til at være med i projektet jeg har startet her: 
https://www.wikidata.org/wiki/Wikidata:WikiProject_Shelters

En første udfordring er at opendata.dks licens er inkompatibel med CC0 hvilket 
er rigtig skidt. Vi skulle behøve lave lobbyarbejde med Wikimedia Danmark og få 
opendata.dks medlemmer at ændre til CC0 med et ønske om at kilde til dataen 
angives hvor det er teknisk eller praktisk muligt ligesom Naturskyddsverket i 
Sverige har gjort, se: 
http://gpt.vic-metria.nu/data/land/Leder_och_friluftsanordningar_beskrivning_av_oppna_data.pdf
 og 
https://www.pressmachine.se/pressrelease/view/friluftslivet-som-oppna-data-8264

Når dataen er blevet CC0 kan vi skabe wikidata objekt for hver af disse pladser 
med et python program jeg har skrevet og derefter lænke til dem fra OSM via et 
andet skript som ikke er skrevet endnu men som jævnfør positioner i wikidata 
med lejrpladser og foreslår lænkning af fundne kandidater og skriver til en 
.osm-fil som siden tjekkes i JOSM og lægges op.

På den måde kan vi integrere mynigheders data med wikidata og OSM står på 
skulderne af dette arbejde og lænker bare, hvilket gør det let at hente det man 
behøver fx objektnavn, billede, beskrivelse, ekstern url, bookningsurl, m.m. 
fra wikidata. Det eneste som behøver være i osm er et objekt med koordinater, 
de almindelige osm etiketter som anger typen og wikidata-etikett som resten kan 
hentes fra. 

(JOSM støtter allerede nu at hente navn fra wikidata-etikett hvilket 
overflødiggør at vi også sidder og skriver navne ind på alting. Mapbox anvender 
også wikidata-navne hvor muligt for at undgå de uopdaterede og ofte undermålige 
osm-navne etiketter som vi i mine øjne helt burde skrotte. Det findes ingen 
mening med at have navne to steder for samme objekt.)

Mvh
So9q/pangoSE___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[pangoSE]

Martin Koppenhoefer  skrev: (3 augusti 2020 01:10:09 
CEST)
>
>
>sent from a phone
>
>> On 2. Aug 2020, at 18:11, Guillaume Rischard
> wrote:
>> 
>> As someone who’s listed as having used 9 different editors on
>https://hdyc.neis-one.org/?Stereo (including “unknown”), I know how
>important the variety and richness of editing possibilities is.
>
>
>agreed. Admittedly the stats look pretty bad, user numbers have been
>dropping constantly since 2012, in 2015 there were 24000 PL2 users,
>2016: 14700, 2017 1, 2018 6400, 2019 4900 and 2020 only 2500 so
>far, but I am willing to believe that these are mostly long term and
>hardcore contributors, and 2500 is no big money for the
>OpenStreetMap-Foundation, so it may be worth the effort. At least you
>can be sure that in  these 9,7 million edits no imports are hiding ;-)
>and this number makes it 4th for performed edits.
>
>Cheers Martin 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[pangoSE]

mmd  skrev: (2 augusti 2020 11:31:21 CEST)
>On 2020-08-01 12:42, Richard Fairhurst wrote:
>> Ruffle is showing promise (https://github.com/ruffle-rs/ruffle) and
>is
>> under very active development, but does not yet support AS3 or the
>Flash
>> Player features that P2 needs. I would anticipate that P2 will be
>able
>> to run as WebAssembly when Ruffle reaches feature parity with AIR
>2.6.
>
>Yes, exactly, that's one of the two approaches I had in mind: rewriting
>from scratch preferably also in Rust (which obviously wouldn't fit in
>the proposed budget or timeframe), or use Ruffle with the existing
>code.
>

I suggest we wait for ruffle to be ready and then compile P2 to first wasm and 
then decompile it into C and then translate it into rust.
It can then be cleaned up and shipped to both as a desktop application and a 
wasm binary run in the browser.
See 
https://github.com/wwwg/wasmdec
https://github.com/jameysharp/corrode

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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[pangoSE]

I disagree. For that sum of money I would be willing to start writing a new 
editor in Rust compiled to WebAssembly and desktop and reach a state of basic 
editing useability in 2 months.
See also https://www.youtube.com/watch?v=ohuTy8MmbLc
Cheers

Joseph Eisenberg  skrev: (3 augusti 2020 01:00:49 
CEST)
>While the benefit of making Potlatch 2 on AIR is small, the cost is
>tiny.
>
>2500 Euros is an insignificant price to pay for supporting an editor
>which
>is still used by a couple of thousand long-term users.
>
>I support this expenditure.
>
>– Joseph Eisenberg
>
>On Sun, Aug 2, 2020 at 10:05 AM Alexandre Oliveira
>
>wrote:
>
>> I'd like to share my two cents on the matter of supporting Potlatch
>2,
>> an editor built with (now) dead technology.
>>
>> I don't think it's worth spending money to update P2 to Air. As
>others
>> have stated, Air has been discontinued as well, and it was developed
>> by Adobe, probably with the same amount of security flaws as Flash
>> had, which contributed to its demise. I don't see Air as different
>> even though it's being maintained now by Samsung.
>>
>> Just take a look. The web is different than when P2 released; flash
>is
>> deprecated and a synonym for vulnerable systems, Air tried to take
>off
>> but now it's just another dead technology. What are the benefits of
>> porting P2 to Air? It may be easier because Air may share some code
>> with Flash, which in turn makes it easier to port to.
>>
>> However, I think that the OSMF should find someone familiar with
>Flash
>> and look forward to porting P2 to modern web technologies (please not
>> Electron!), like WebAssembly or Web 2.0. Be it JavaScript,
>> CoffeeScript or TypeScript, React, Angular, Vue.js or any other
>modern
>> web tech, it doesn't matter. I think it's going to be money well
>spent
>> if P2 was ported to a supported web technology and not something that
>> died a few years ago and is on life support, and barely anyone uses
>it
>> nowadays.
>>
>> IMO porting P2 to Air is just a waste of money and time from the
>> developer, and we will reach the same point in the future, be it
>> either for deprecating P2 or looking to port it to newer web
>> technologies. OSMF should prepare for the future and not continue
>> using deprecated technology.
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[pangoSE]

I would recommend you to use another way to archive this. Open OsmAnd on your 
phone and add a POI directly. You can add tags too if you remember them. Then 
upload directly to OSM.
No JOSM or GPX file handling neccesary.

Andy Townsend  skrev: (3 augusti 2020 00:09:44 CEST)
>On 02/08/2020 22:52, Martin Koppenhoefer wrote:
>>
>>
>> sent from a phone
>>
>>> On 2. Aug 2020, at 17:09, Andy Townsend  wrote:
>>>
>>> GPX track waypoint handling is the biggest missing piece of 
>>> functionality for me, so you can start with that one if you wish
>>
>>
>> I guess this is about not handling symbols?
>
>Not really - see 
>https://help.openstreetmap.org/questions/6368/in-josm-is-it-possible-to-see-gpx-track-waypoint-details
>
>for information.
>
>If there's a better answer available now (which is entirely possible -
>I 
>asked that question 9 years ago!) then I'd suggest adding it at that 
>help question.  See also 
>https://help.openstreetmap.org/questions/7675/josm-is-it-possible-to-convert-an-individual-waypoint-in-a-gpx-file-to-a-node
>
>which is somewhat similar.
>
>Best Regards,
>
>Andy
>
>
>
>___
>talk mailing list
>talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[pangoSE]

I agree with this. 

Particularly Rust compiled to WebAssembly look very promising for building 
applications like an editor. Rust is fast and safe and it already has multiple 
OSM related crates. 
See here for an example: https://www.youtube.com/watch?v=YHJjmsw_Sx0

An editor written in Rust and compiled to WebAssembly would probably be a lot 
faster than iD is today. 
Writing something completely in browser JS these days is not the best way 
forward if speed and portability is is important iMO.

Alexandre Oliveira  skrev: (2 augusti 2020 19:01:23 CEST)
>I'd like to share my two cents on the matter of supporting Potlatch 2,
>an editor built with (now) dead technology.
>
>I don't think it's worth spending money to update P2 to Air. As others
>have stated, Air has been discontinued as well, and it was developed
>by Adobe, probably with the same amount of security flaws as Flash
>had, which contributed to its demise. I don't see Air as different
>even though it's being maintained now by Samsung.
>
>Just take a look. The web is different than when P2 released; flash is
>deprecated and a synonym for vulnerable systems, Air tried to take off
>but now it's just another dead technology. What are the benefits of
>porting P2 to Air? It may be easier because Air may share some code
>with Flash, which in turn makes it easier to port to.
>
>However, I think that the OSMF should find someone familiar with Flash
>and look forward to porting P2 to modern web technologies (please not
>Electron!), like WebAssembly or Web 2.0. Be it JavaScript,
>CoffeeScript or TypeScript, React, Angular, Vue.js or any other modern
>web tech, it doesn't matter. I think it's going to be money well spent
>if P2 was ported to a supported web technology and not something that
>died a few years ago and is on life support, and barely anyone uses it
>nowadays.
>
>IMO porting P2 to Air is just a waste of money and time from the
>developer, and we will reach the same point in the future, be it
>either for deprecating P2 or looking to port it to newer web
>technologies. OSMF should prepare for the future and not continue
>using deprecated technology.
>
>___
>talk mailing list
>talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[pangoSE]

Hi

Matthew Woehlke  skrev: (3 augusti 2020 16:14:13 CEST)
>On 02/08/2020 06.05, Simon Poole wrote:
>
>I'm not saying iD is *bad*. It's a very nice editor *for its 
>capabilities*. It's great for making *small* changes or introducing 
>someone to OSM editing... but there are a lot of use cases still where 
>JOSM is just a far superior tool. Maybe in *5-10* years that will 
>change, but I'm not going to hold my breath on it overtaking JOSM in
>1-2.

On older hardware like my 2 core 2ghz laptop iD is slow. Loading while saving 
an edit is slow, while JOSM is always fast and saving does not close the edit 
view so you can continue without waiting for a browser to load the iD editor 
again which is also slow.

>
>(¹ iD can 'square up' individual nodes and does a passable job with 
>*mostly* orthogonal shapes with the odd 45° angle. There are ways to 
>work with those in JOSM, but generally speaking if you try to square a 
>shape with a single 'wild' node, JOSM turns the whole thing into a hot 
>mess.)

This sounds like a bug. Have you reported it?

Cheers 
pangoSE

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

Re: [OSM-talk] Suggestions welcome | Re: Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[pangoSE]

I agree.

Skyler Hawthorne  skrev: (2 augusti 2020 19:30:09 CEST)
>In the absence of other proposals, even splitting it among the other
>two would be a much better use, in my opinion.
>
>--
>Skyler
>
>
>On Sun, Aug 2, 2020, at 13:27, Rory McCann wrote:
>> On 02.08.20 01:03, Skyler Hawthorne wrote:
>> > Sorry if this sounds harsh, but I think using any funds at all to 
>> > continue support for a tool that 1% of editors use would be
>wasteful. 
>> > Flash is, for all intents and purposes, a dead technology. This
>money is 
>> > better spent on other uses.
>> 
>> What would you suggest?
>> 
>> Serious question. We're suggesting spending €2,500 on this. Where
>else 
>> do you suggest spending €2,500 on?
>> 
>> Rory
>> 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[pangoSE]

Is this the platform you are targeting? 
https://en.m.wikipedia.org/wiki/Adobe_AIR

Its proprietary which makes it prone to the same fate as Flash Player. Why even 
consider such a move?

I never use nonfree software like flash so I never tried P2. What is so special 
about it? Is there something hindering adding that specialness (as a plugin 
perhaps) to JOSM?

The JOSM devs seem very helpful, supporting and have a friendly culture.

I suggest letting this code die as it lures people to install nonfree and 
therefore dangerous software. Alternatively that you team up with your 20 mio 
edits-peers and port the code to something that does not require proprietary 
software. 

You did not present a single usecase that is not covered already by one of the 
other free software editors so I'm guessing you will have a hard time 
convincing your peers to team up around yet another editor, but I might be 
wrong.

I don't care about your ROI arguments because they are based on the not 
outspoken premise that economics of software development is more important when 
making decisions than freedom, which is false IMO. 
If you had compared 2 free software projects like iD and JOSM that run without 
any proprietary code, then it might have been relevant.

I suggest declining support of any software project that is or requires 
proprietary software to run.

Cheers 
pangoSE
PS I use 4 different editors to edit in the database: JOSM, OsmAnd, 
StreetComplete and rarely iD.


Richard Fairhurst  skrev: (2 augusti 2020 10:28:22 CEST)
>Skyler Hawthorne wrote:
>> Sorry if this sounds harsh, but I think using any funds at all to
>> continue support for a tool that 1% of editors use would be wasteful.
>> Flash is, for all intents and purposes, a dead technology. This
>> money is better spent on other uses.
>
>The entire point is to move away from a dead technology (Flash Player)
>to a supported one (AIR).
>
>On the percentage stat, it's worth bearing in mind that the P2 project
>is by a long chalk the smallest sum (€2500) of the three that OSMF is
>proposing here. As a point of comparison, iD was initially developed
>with a $575,000 grant from the Knight Foundation in 2012, so roughly
>$646,000 now. Very conservatively estimating the cost of employing 1-2
>developers to code on iD since then, you get a development cost of
>roughly €0.004 per (2020) changeset for iD vs $0.0002 for P2, which is
>kind of fun.
>
>(I'm actually pleasantly surprised that P2 still has so many changesets
>- 20 million last year, and I'm guessing high teens this year - given
>how difficult it is to get Flash Player running in most browsers these
>days. That suggests that P2's users are using it because they want to
>do so, not because they are magically unaware of the existence of other
>editors. I suspect if you could find another way of getting 20 million
>edits for €2500 then we would snap your hand off.)
>
>Looking forward, and continuing the theme of ROI, the other benefit of
>the project is that it enables development work to continue on P2. The
>reason I have bid for funding for this, for the first time in 14 years
>of developing editors for OpenStreetMap, is that it will take a solid
>chunk of sustained work to do the AIR conversion and a bunch of other
>stuff I believe will make P2 more sustainable into the future, and
>there is a hard deadline for that sustained work (i.e. Flash Player
>switch-off at the end of the year). It's not a project that can just be
>done in evenings here and there. That enables further, unfunded
>developments in the future, and in turn I hope the tradition of other
>editors taking inspiration from P2 can continue - it's not for nothing
>that JOSM has a Potlatch 2 style and a "Potlatch mode" for editing.
>
>But you are, of course, welcome to develop and put forward a project to
>OSMF which you believe will have more bang for the buck. "Other uses"
>is easy to type but doesn't actually mean anything until you identify
>what those uses are, and crucially, find someone who is prepared to do
>them.
>
>Richard
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Removing all signposts from relations

[pangoSE]

Hi

Recently it was discussed whether to have signposts in route relations. I 
suggest we delete them from all relations by running a script.
I se no loss of information doing that and a benefit to data consumers wanting 
to sort and calculate the length and height profile of the relation which I 
think should only contain unclosed ways belonging to the route.

What do you think?___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-se] [OFF TOPIC] Ny tjänst från Lantmäteriet

[pangoSE]

On 2020-05-04 12:09, Per Geijer wrote:
Min karta är en ny gratistjänst från LM. Finns på web 
https://minkarta.lantmateriet.se/ och 
för iPad/iPhone https://apps.apple.com/se/app/min-karta/id1495766306 
samt är under utveckling för Android.


Webbtjänsten och appen synkar med GPS och centrerar kartan och kan 
rotera kartan i färdriktningen. Webbtjänsten har en bra sökfunktion. I 
appen finns karta och flygbild. På webben fins även bergochdalkarta och 
äldre flygbilder.


Bra som referens vid kartering. Vilket värde har OSM när det finns ett 
bättre gratisalternativ, förutom att det är kul att kartera? Nu svor jag 
kanske i kyrkan...


Lantmäteriets tjänst är SaaS och således varken öppen eller fri att 
använda eller ladda ner eller göra med som man vill på nya påhittiga sätt.


Se https://www.gnu.org/philosophy/who-does-that-server-really-serve.html

Jag litar inte ett dugg på LMs karta eller deras tjänster. Med OSM kan 
jag enkelt ladda ner det jag behöver och gå ut i naturen och leta flera 
stigar (mha. https://wiki.openstreetmap.org/wiki/OsmAnd & 
https://wiki.openstreetmap.org/wiki/OSMTracker_(Android)). Ingen av dem 
två möjligheter ger Lantmäteriet för bara att ta två exempel.


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

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

[pangoSE]

Hej John

Jag är helt enig. Om detta skal funka då måste vi se till att det är 
busenkelt att koppla på/av källor med olika lager.


Kanske är inte openstreetmap.org rätta stället för detta? Utvecklarna 
verkar väldigt konservativt inställda till ändringar, så det är nog för 
mycket att hoppas på. Att få dem att erbjuda upp till ett tiotal 
WMS-lager där per land ser jag inte som troligt i första laget.


Jag tänker att detta kanske kommer hända på openstreetmap.org samtidigt 
som vi byter från raster tiles till vektor tiles. Vad jag vet är det 
inga bra argument för att fortsätta med raster tiles när nu teknologin 
för vektor tiles finns. OsmAnd är helt vektor, Thunderforest har bytt, 
Mapbox har bytt.


Raster tiles har dem 2 stora nackdelar att dem fyller en massa på disk 
och kräver mycket resurser att generera. Vektor kan serveras direkt från 
en databas (se detaljer https://www.thunderforest.com/blog/)


Ang. OsmAnd så tänker jag mig att tex för Sverige så kommer det finnas 
en extra fil för naturreservat, och extra för skyddsområden (eller båda 
i en fil). Denna data dras från NV regelbundet (källa här 
https://wiki.openstreetmap.org/wiki/Sweden/Open_data/Naturv%C3%A5rdsverket#Boundary). 
Den måste konverteras till först osm/pbf (via ogr2ogr) och därefter 
*.obf format via (https://wiki.openstreetmap.org/wiki/OsmAndMapCreator). 
Vad jag vet kan OsmAnd bara tugga en obf åt gången i dagsläget för ett 
givet område 
(https://android.stackexchange.com/questions/141666/how-to-import-an-obf-map-file-into-osmand) 
vilket betyder att för att få med nationalparker/reservat så måste dem 
flätas in i osm datan först (via osmium) och därefter konverteras 
resultatet till obf.


Om detta ligger flera år ut i framtiden så är frågan om vi ska vänta med 
att radera dem områden vi redan har inne och bara vara tydliga med att 
vi inte uppdaterar dem längre.


WDYT?

On 2020-03-20 10:48, John Bäckstrand wrote:
Jag håller principiellt med, men "discoverability" är så oerhört 
viktigt, så det enda system som "drar in data från flera ställen" som 
duger, i min mening, vore ett centralt system som fungerar auomatiskt 
på openstreetmap.org <http://openstreetmap.org> och de vanliga 
tile:sen. Allt annat kommer ju försämra upplevelsen och jag vet hur 
lat jag själv är, att få allt serverat för sig är en viktig faktor. 
Tar det 5 minuter att få till en vettig karta istället för 10 sekunder 
så räcker det för att gå någon annan stans.


Men det är mitt perspektiv.

/John Bäckstrand

On Fri, Mar 20, 2020 at 10:42 AM <mailto:pang...@riseup.net>> wrote:


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 <mailto: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 author

[Talk-se] Apropå svenska naturreservat i OSM

[pangose]

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 


 Original Message 
From: Tobias Knerr 
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] Ska adresser ha land, stad, postnummer och allt?

[pangose]

Här finns senaste nytt. Tidsfristen har förlängts till 8/5 2020.
https://www.lantmateriet.se/sv/Om-Lantmateriet/diariet-och-informationsredovisning/regeringsuppdrag/
https://www.lantmateriet.se/contentassets/daddf8c4ead1414a89969d345191659d/andring-av-uppdraget-att-analysera-budgetara-konsekvenser-av-myndigheters-tillgangliggorande-av-vardefulla-datamangder.pdf

On March 17, 2020 12:19:35 PM GMT+01:00, Daniel Lublin  wrote:
>pang...@riseup.net , 2019-11-28 20:20:33 (+0100):
>> Därutöver håller Lantmäteriet på att utreda hurvidare dem ska kunna
>frige
>> den resterande data dem i dag säljer dvs laserdata, fastighetskartan
>och
>> adressnoder samt underlag som flygbilder och stereofoton.
>> 
>> Utredningen måste vara klar d. 17/1 och då kommer jag dela den här.
>
>Hur gick det med den?
>
>--
>Daniel
>lublin.se
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-se] Malmö och Örnsköldsvik saknas på vektorkarta

[pangoSE]

On 2020-02-08 13:13, Essin wrote:

Hej!

PangoSE, kan du till att börja med be SCB att uppdatera sin hemsida? För 
närvarande står det visserligen att tätortsgeometrierna är öppna data 
[1] men också att deras öppna data är CC-BY-licensierade [2] vilket inte 
är tillräckligt för OSM [3]. Det är ingen bra idé att ladda upp data med 
oklar licens.


Som jag skrev i min epost:
"LM har släppt alla tätortspolygoner som CC0 så det är bara att importera.
(Se geojson fil här https://www.mediafire.com/folder/dzngn1k5y2xjq/)"




Tätortsavgränsningarna ritas om från grunden vart tredje år. Vem tar 
ansvar för att det hålls uppdaterat någon längre tid? Vi har fortfarande 
kvar mera begränsade tätortsuppgifter som blev inaktuella 2015, t ex 
[4], och eftersom ändringar i tätortsindelningen inte är direkt 
observerbara på marken kan det dröja länge innan någon märker att något 
är fel, om det inte kontrolleras systematiskt. Ett liknande fall är 
naturreservaten, som importerades runt 2010. Jag har under en längre tid 
sysslat med att gå igenom naturreservaten för att slå ihop överlappande 
gränser, och där finns det många fall av gränsförändringar och nyskapade 
reservat som inte har uppdaterats trots att naturreservaten har mer 
stabila gränser än tätorterna.


Va bra! Jag är medveten om att detta är ett stort jobb. Jag föreslår att 
vi automatiserar det som jag skrivit tidigare.




Tätortsavgränsningarna har ingen som helst administrativ funktion och 
det är därmed direkt fel att tagga dem som boundary=administrative. 
Tätbebyggda områden (som kommunerna använder för att avgränsa t ex 
50-begränsningar och tomgångskörningsförbud) har en viss administrativ 
funktion och är indirekt observerbara på marken genom vägskyltar när man 
passerar deras gränser, men det är en annan sak. Möjligtvis skulle 
boundary=census [5] fungera för tätortsavgränsningarna, om de trots alla 
invändningar ska finnas i OSM.




Jag blir ännu mer skeptisk när jag ser hur tätortsavgränsningarna har 
lagts in hittills, som i Malmö [6]. Relationen har note=Tätortsgränsen 
följer inte LMs polygon slaviskt eftersom att denna inte täckte alla 
områden ordentligt. Vad är överhuvudtaget meningen med att rita ut 
tätortsgränser separat på OSM om det inte är de av SCB definierade 
tätorterna? Den dataanvändare som vill använda OSM-data för att få en 
uppfattning om bebyggda områden får ett bättre resultat av att aggregera 
urbana markanvändningstyper som landuse=residential, industrial, retail 
etc, eller i välmappade områden (som Malmö!) genom att analysera building=*.



Jag gillar ditt argument här. Jag la första gång in en 
boundary=administrative när det behövdes för att få 
https://maposmatic.osm-baustelle.de/ att funka som tänkt för svenska 
tätorter. Detta kan ju uppfattas som tagging for the renderer vilket jag 
inte är tillhängare av.
Det går bra för mig att vi ändrar till =census och jag håller med om att 
vi då bör bevara polygonformerna som dem kommer från LM (eller SCB om 
nån lyckas övertycka chefledet om det tokiga med valet CC-BY, se 
https://se.wikimedia.org/wiki/%C3%84mne:Vavz1c9h6p2kc1l5)


Tyvärr innebär detta att maposmatic/myosmatic inte kommer ha med alla 
vägar inom tätorten Malmö som jag som användare skulle förvänta mig om 
jag söker på Malmö och gör en karta över denna stad. Det innebär att 
verktyget kanske måste ändras till att göra den analys du föreslår för 
att själv hitta avgränsningar för tätorter via en algoritm.


Det finns f.ö. över en miljon place=city som är ritad som area i 
databasen, hur ställer du dig till place= på områden?


Mvh
pangoSE



Den tors 23 jan. 2020 kl 14:39 skrev pangoSE <mailto:pang...@riseup.net>>:


Hej.

Jag tycker att vi skal tolka tätortsområden som administrativa
gränser för våra städer. Det är den bästa källa vi har, alternativet
är att göra dem subjektivt själva som jag ser det.

Det är korrekt att dem uppdateras av SCB vart 5-e år. SCB har dock
bara släppt dem som CC-BY varför jag föreslår att vi tar dem från
LM. Jag ser inte det som ett problem att gränserna uppdateras när
byn byggs ut eller stadsdelar rivs.

Dem används inte bara av rendere också av tex
https://maposmatic.osm-baustelle.de
<https://maposmatic.osm-baustelle.de/> där det inte i dagsläget går
att göra en karta över tex Malmö av skälet att staden inte är
definerad som område.

Se skillnaden när du söker här på härnösand vs malmö:
https://maposmatic.osm-baustelle.de/new/#

Vi saknar altså vettiga admin boundaries på våra städer. Alla
svenska städer jag testade utom Härnösand och Umeå kunde inte lätt
hittas.

När man skapar bykartor då är det vettigt att bara ta med gatunamn
inom byområdet och detta gör verktyget om vi har definerad gränserna.

Jag skapade precis denna cykelkarta för Umeå med alla gatunamn i en
bilaga där området utanför tätorten är grått och gator som ligger
utanför byområdet inte tas med

Re: [Talk-dk] I har selvfølgelig set det, men ... :-)

[pangoSE]

Hej Peter

Herligt initiativ!

FYI: Jeg har tegnet med to børn på 8 og 9 år og (2. og 3. klasse) og så 
længe jeg sad med og vejledte (og ansvarede for etiketterne og 
kvaliteten inden upload) så gik det helt fint.


Vi tegnede stiger i de svenske/samiske bjerge :)

Så længe opgaven anpasses så tror jeg det går helt fint at unge helt ned 
til 8 år er med.


Den ene af børnene synes at jeg var lidt sjusket med mine linjer og til 
det svarede jeg: dem som bruger den her sti kan optage et gps spor og 
selv rette den til ud fra virkeligheden. Bedre at ha en grov sti og 
savne 1000 andre stier end at ha en perfekt tegnet sti og mangle 100.000 
stier.


Kvalitet kommer med tiden. Når data helt savnes i et bjergområde fx så 
er det en gave at ha noget som helst som man kan navigere efter.


Om nogle får lyst til at hjælpe så sig til, vi mangler mange km endnu :)

Mvh

pangoSE

On 2020-02-02 08:13, Peter Leth wrote:

Kære alle

Det var min ide at eleverne skulle prøve kræfter med OSM.
Jeg har fået en rigtig god sparring med Søren Johannesen (da vi har 
lavet et tilsvarende projekt for en 5-6 år siden med 30 unger der gik 
i 8. klasse som sad en hel aften mens der var Danmarksindsamling og 
knoklede. Den gang ville DR hellere dække deres event uden vores 
historie).


Det er mig der har stået for projektet, som er en del af de ideer jeg 
har til udbredelse og forståelse for brugen af åbne platforme og 
værktøjer.
Jeg var med til at stifte foreningen OpenDenmark sidste forår, og en 
del af det projekt jeg lavede på Ringkøbing Skole er at teste nogle 
ideer af på eleverne netop i forhold til at forstå at det åbne både 
har noget at give os, men også at vi kan være den der giver noget til 
andre.


Konkret omkring brugen af OpenStreetMap med en femte klasse, så vil 
jeg sige at det er ikke min plan at rulle et projekt ud i den 
aldersgruppe.
Jeg oplevede at mange af eleverne havde fin forståelse for hvad de 
lavede, men jeg oplevede også nogle elever, der var lidt løse kanoner. 
5.klase er derfor de absolut yngste, at redigere sammen med.


Jeg håber virkelig at de bidrag jeg er skyld i, ikke svækker eller 
forringer kortet.


Men jeg håber virkelig også at vi via OSM kan være med til at lave 
aktiviteter der sigter direkte på nogle af de spørgsmål som er 
supervigtige at have med i undervisningen, at åbne licenser, åbne 
platforme og åbent indhold er vigtig at kende, fordi det er 
frisættende for både mennesker og den teknologi vi omgiver os med.


Eleverne lavede også andre ting den dag - og materialerne og 
erfaringerne er på vej til at blive et nyt undervisningsmateriale, som 
forhåbentlig gør at vi kan hjælpe skoler, lærere og elever til at lære 
om at noget er åbent. (Se fx mapillaryproduktionen her 
https://www.mapillary.com/app/?lat=56.096162968244414=8.26761465519428=14.253318058636149=map ) 



Er der personer her i gruppen, der har spørgsmål, kommentarer eller 
ikke mindst forslag til hvad jeg kan gøre i den sammenhæng, skal I 
være velkomne til at kontakte mig.


God søndag.

/ Peter Leth

Den lør. 1. feb. 2020 kl. 19.13 skrev Soren Johannessen 
mailto:soren.johannes...@gmail.com>>:


I kan også høre det som radiointerview på DR4 i går - spol hen på 3
timer og ca. 10 min
https://www.dr.dk/radio/p4vest/p4vest-morgen/p4-morgen-2020-01-31-06-05

Før kommer interview med drengen Daniel , (kommer en sang derefter) så
med underviseren, så går der ca. 15 min (nyheder/musik), hvor dernæst
så hører vi NGO'erne synspunkt vedr. børnenes event i går.




On Sat, Feb 1, 2020 at 6:39 PM Anders Lund mailto:and...@alweb.dk>> wrote:
>
>

https://www.dr.dk/nyheder/regionale/midtvest/11-aarige-daniel-giver-digital-noedhjaelp-finder-veje-og-soeer-til-folk-i
>
>
>
>
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org <mailto:Talk-dk@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-dk

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



--
/Med venlig hilsen /
/
/
/Peter Leth/
/pe...@pluk.dk <mailto:pe...@pluk.dk> /
/l...@creativecommons.dk/ <mailto:l...@creativecommons.dk>
/
/
/T. 5152 2387/
/Skype. peter.leth1/


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

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

[pangoSE]

Hej igen!

Jag tog en tit på v14 både dropped och tx_22.osm som är för Västernorrland.

Jag tyckte det såg väldigt bra ut! Jag är imponerad av att du lyckats så 
bra med att sortera bort dupletter. Av alla 50-tals jag kollade manuellt 
hittade jag bara 1 duplett som jag manuellt skulle fixa till. (Gådeå i 
importen, Gådeå by i osm, troligtvis är Gådeå rätt)


För min del är vi redo för nästa steg, import listan och sedan import.

När det är så bra som jag sett här, då kan vi för min del skippa både 
WMS och MapWithAI och bara importera varje fil i JOSM manuellt.


När vi är klara med denna import skulle jag gärna se en import av 
vattendrag från Fjällkartan


Mvh

pangoSE

On 2020-01-22 01:34, Grigory Rechistov via Talk-se wrote:

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 dem är det du 
tittar på?

Jag använder den "GIS"-uppsättningen, men, som du lagt märke till...
> Sedan misstänker jag att även ”GIS”-uppsättningen lider lite av att vara
> ”en karta i shapefile-format”, snarare än en geodatabas — namnen är 
placerade

> där det blir snyggt på en 50k-karta
...det har jag också märkt. Därför finns olika förkortningar och 
radbrytningar

i källfiler vilka jag har kunnat åtgärda. Jag har i planer att kontakta
Lantmäteriet med en lista på ortnamns korrigeringar som jag samlat. 
Kanske blir

någon intresserad i att uppdatera deras kartinformation för framtiden.
> För herrgårdar kanske man kan passa på att lägga till historic=manor 
samtidigt.
Jag har också tänkt på detta, men vågade inte räkna varje herrgård som 
en plats

av historiskt värde.
Då kanske missförstår jag "historic=manor":s betydelse. Den taggen används
förresten inte mycket i Sverige, enligt detta: 
http://overpass-turbo.eu/s/PY3 .

Endast 77 träffar.
> 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.
Det är precis den ursprungliga meningen bakom "place=locality". Att 
importen
använder den taggen för herrgårdarna var en kompromiss som jag tillät 
eftersom
jag inte kunde hitta ett bättre alternativ för något mindre än 
"isolated_dwelling".
Då ansåg jag att "historic=manor" vore för specifikt. Men att bara 
kasta iväg

noderna ville jag inte heller.
Låt mig tänka på det lite mer, hur det bästa lösningen skulle se ut. 
Kanske skulle
jag omtagga dem till "isolated_dwelling", kanske till "manor", kanske 
kasta bort.


> Stadsdelar bör väl inte vara hamlet, utan neighbourhood?
Nej, "neighbourhood" är visst bättre för dem. För varje kartruta som 
ligger nära
en större stad ska en uppladdare se till att "hamlet" blir till 
"neighbourhood".

Det skulle vara uppenbart att upptäcka visuellt och fixa manuellt.
Det skulle inte finnas många sådana rutor som täcker stora städer. 
Stora städer
brukar dessutom vara mer färdigt kartlagda vilket betyder mindre nya 
noder att

importera runtom dem.
Jag kunde kanske ha löst problemet genom att tagga de noder som finns 
inom städers

gränser på ett annat etikettsschema... Men det skulle ha varit för
beräkningsintensivt, och jag är inte redo att skriva en sådan algoritm 
(ännu).

> även om jag själv hade föredragit en adress-import.
Det skulle jag ha också föredragit, om jag hade tillgång till en öppen 
databas

för ortnamn/adresser.
> Gissar att merparten av de nya namnen inte längre används i vardagen.
Här kan vi endast tro på Lantmäteriets kompetens att hålla sina kartor 
aktuella.
Men det gäller även själva OSM-projektet. Man litar nämligen på att 
andra OSM:s
bidragsgivare har ritat något som stämmer i verkligheten. En gång hade 
jag cyklat

till en skogsväg som visade sig vara ett dike på marken ¯\_(ツ)_/¯
Det är kanske också en ständig fråga för OSM: när blir historiska data
irrelevanta och bör suddas ur OSM-databasen? Jag är till exempel lätt 
irriterad
att man tillåter ha "abandoned=railway" (drygt 256 tusen sträckor 
enligt Taginfo!)

> Vissa platser ser mer ut som "locality" medan några namn har helt klart
> felaktigt blivit "hamlet" fast det bara är en gård, om ens det.
Det finns sådan risk som jag skrivit i importplanen. Jag bedömer att 
ett sådant
fel, om tillåtet vid importen, är av mindre vikt. Man kan väl strida 
om "rätta"
etiketter till världens slut. Att det finns en plats med ett namn 
skulle dock hjälpa
att upptäcka platsen och sedan att bedöma dess storlek och sedan rätta 
till

"place=hamlet" till "locality" eller tvärtom.

> Är det i såna fall möjligt att genereras nya filer efterhand, så man 
ser vad

> som blir till övers på slutet?
Att g

Re: [Talk-se] Malmö och Örnsköldsvik saknas på vektorkarta

[pangoSE]

Hej.

Jag tycker att vi skal tolka tätortsområden som administrativa gränser 
för våra städer. Det är den bästa källa vi har, alternativet är att göra 
dem subjektivt själva som jag ser det.


Det är korrekt att dem uppdateras av SCB vart 5-e år. SCB har dock bara 
släppt dem som CC-BY varför jag föreslår att vi tar dem från LM. Jag ser 
inte det som ett problem att gränserna uppdateras när byn byggs ut eller 
stadsdelar rivs.


Dem används inte bara av rendere också av tex 
https://maposmatic.osm-baustelle.de 
<https://maposmatic.osm-baustelle.de/> där det inte i dagsläget går att 
göra en karta över tex Malmö av skälet att staden inte är definerad som 
område.


Se skillnaden när du söker här på härnösand vs malmö: 
https://maposmatic.osm-baustelle.de/new/#


Vi saknar altså vettiga admin boundaries på våra städer. Alla svenska 
städer jag testade utom Härnösand och Umeå kunde inte lätt hittas.


När man skapar bykartor då är det vettigt att bara ta med gatunamn inom 
byområdet och detta gör verktyget om vi har definerad gränserna.


Jag skapade precis denna cykelkarta för Umeå med alla gatunamn i en 
bilaga där området utanför tätorten är grått och gator som ligger 
utanför byområdet inte tas med i indexet, se: 
https://maposmatic.osm-baustelle.de/maps/100341/qlPljYcLvFQNZKTI 
direktlänk till pdfen: 
https://maposmatic.osm-baustelle.de/results//100342_2020-01-23_14-30_umea.pdf


mvh

pangoSE

On 2020-01-23 13:49, Andreas Vilén wrote:
Tätortspolygoner ändras varje gång det görs en ny uppdatering, ett 
område byggs eller liknande. Det finns ingen etablerad taggning för 
detta och jag tror inte det är lämpligt att lägga in.


Tätorter är inga administrativa enheter och har normalt inga gränser 
mer än rent statistiska.


/Andreas

Skickat från min iPhone

23 jan. 2020 kl. 13:18 skrev pangoSE <mailto:pang...@riseup.net>>:



Hej
Jag testade uMaps vektorkarta med outdoor lagret från thunderforest. 
(se 
https://umap.openstreetmap.fr/en/map/stugor-och-vindskydd_410556#7/55.835/13.964)


På större zoom nivåer saknas städer i SE pga att dem endast är 
inritade som noder. tex 
https://nominatim.openstreetmap.org/details.php?place_id=133125


I Danmark ser det mycket bättre ut...

LM har släppt alla tätortspolygoner som CC0 så det är bara att importera.
(Se geojson fil här https://www.mediafire.com/folder/dzngn1k5y2xjq/)



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

[Talk-se] Malmö och Örnsköldsvik saknas på vektorkarta

[pangoSE]

Hej
Jag testade uMaps vektorkarta med outdoor lagret från thunderforest. (se 
https://umap.openstreetmap.fr/en/map/stugor-och-vindskydd_410556#7/55.835/13.964)


På större zoom nivåer saknas städer i SE pga att dem endast är inritade 
som noder. tex 
https://nominatim.openstreetmap.org/details.php?place_id=133125


I Danmark ser det mycket bättre ut...

LM har släppt alla tätortspolygoner som CC0 så det är bara att importera.
(Se geojson fil här https://www.mediafire.com/folder/dzngn1k5y2xjq/)



___
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

[pangose]

Hej igen 
Tusen tack för dina utförliga svar.
Jag är nu mera positivt inställd till importen. Jag ska titta närmare på en fil 
och återkommer. 
Jag tror det går bra att vi med lokalkännedom laddar upp för ett område vi 
känner. Frågan är hur vi skal göra för dem delar av landet (i norr) där ingen 
av oss har lokalkännedom? 

On January 22, 2020 1:34:35 AM GMT+01:00, Grigory Rechistov via Talk-se 
 wrote:
>
>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 dem är det du
>tittar på?
> 
>Jag använder den "GIS"-uppsättningen, men, som du lagt märke till...
> 
>> Sedan misstänker jag att även ”GIS”-uppsättningen lider lite av att
>vara
>> ”en karta i shapefile-format”, snarare än en geodatabas — namnen är
>placerade
>> där det blir snyggt på en 50k-karta
> 
>...det har jag också märkt. Därför finns olika förkortningar och
>radbrytningar
>i källfiler vilka jag har kunnat åtgärda. Jag har i planer att kontakta
>Lantmäteriet med en lista på ortnamns korrigeringar som jag samlat.
>Kanske blir
>någon intresserad i att uppdatera deras kartinformation för framtiden.
> 
>> För herrgårdar kanske man kan passa på att lägga till historic=manor
>samtidigt.
>Jag har också tänkt på detta, men vågade inte räkna varje herrgård som
>en plats
>av historiskt värde.
>Då kanske missförstår jag "historic=manor":s betydelse. Den taggen
>används
>förresten inte mycket i Sverige, enligt detta:
>http://overpass-turbo.eu/s/PY3 .
>Endast 77 träffar.
> 
>> 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.
>Det är precis den ursprungliga meningen bakom "place=locality". Att
>importen
>använder den taggen för herrgårdarna var en kompromiss som jag tillät
>eftersom
>jag inte kunde hitta ett bättre alternativ för något mindre än
>"isolated_dwelling".
>Då ansåg jag att "historic=manor" vore för specifikt. Men att bara
>kasta iväg
>noderna ville jag inte heller.
>Låt mig tänka på det lite mer, hur det bästa lösningen skulle se ut.
>Kanske skulle
>jag omtagga dem till "isolated_dwelling", kanske till "manor", kanske
>kasta bort.
>
>> Stadsdelar bör väl inte vara hamlet, utan neighbourhood?
>Nej, "neighbourhood" är visst bättre för dem. För varje kartruta som
>ligger nära
>en större stad ska en uppladdare se till att "hamlet" blir till
>"neighbourhood".
>Det skulle vara uppenbart att upptäcka visuellt och fixa manuellt.
>Det skulle inte finnas många sådana rutor som täcker stora städer.
>Stora städer
>brukar dessutom vara mer färdigt kartlagda vilket betyder mindre nya
>noder att
>importera runtom dem.
>Jag kunde kanske ha löst problemet genom att tagga de noder som finns
>inom städers
>gränser på ett annat etikettsschema... Men det skulle ha varit för
>beräkningsintensivt, och jag är inte redo att skriva en sådan algoritm
>(ännu).
> 
>> även om jag själv hade föredragit en adress-import.
>Det skulle jag ha också föredragit, om jag hade tillgång till en öppen
>databas
>för ortnamn/adresser.
> 
>> Gissar att merparten av de nya namnen inte längre används i vardagen.
>Här kan vi endast tro på Lantmäteriets kompetens att hålla sina kartor
>aktuella.
>Men det gäller även själva OSM-projektet. Man litar nämligen på att
>andra OSM:s
>bidragsgivare har ritat något som stämmer i verkligheten. En gång hade
>jag cyklat
>till en skogsväg som visade sig vara ett dike på marken ¯\_(ツ)_/¯
>Det är kanske också en ständig fråga för OSM: när blir historiska data
>irrelevanta och bör suddas ur OSM-databasen? Jag är till exempel lätt
>irriterad
>att man tillåter ha "abandoned=railway" (drygt 256 tusen sträckor
>enligt Taginfo!)
> 
>> Vissa platser ser mer ut som "locality" medan några namn har helt
>klart
>> felaktigt blivit "hamlet" fast det bara är en gård, om ens det.
>Det finns sådan risk som jag skrivit i importplanen. Jag bedömer att
>ett sådant
>fel, om tillåtet vid importen, är av mindre vikt. Man kan väl strida om
>"rätta"
>etiketter till världens slut. Att det finns en plats med ett namn
>skulle dock hjälpa
>att upptäcka platsen och sedan att bedöma dess storlek och sedan rätta
>till
>"place=hamlet" till "locality" eller tvärtom.
>
>> Är det i såna fall möjligt att genereras nya filer efter

Re: [OSM-talk] Teaching cyclists how to contribute to OSM

[pangose]

Same in the north of Sweden. Sometimes they are segregated, sometimes not.
They are made by a stripe of asphalt 2.7 m wide with a white line for 
segregation and painted symbols for walking and cycling and a sign. 
I think this is has been influenced by winter service where a tractor can 
scrape and throw small stones easily. In the winter the segregation is only 
visible on the sign and people are not that rigid about it.

On January 20, 2020 10:16:13 AM GMT+01:00, Maarten Deen  wrote:
>On 2020-01-20 03:15, Paul Johnson wrote:
>> On Sun, Jan 19, 2020 at 6:28 PM john whelan 
>> wrote:
>> 
>>> Locally in Ottawa many paths are multiuse there is a path many
>>> kilometers long along the Ottawa river that has a line marked down
>>> the center and is very much used by cyclists but according to NCC
>>> who own the path it is multi-use not bicycles only so is mapped
>>> highway=path.  Most City of Ottawa paths are the same, bicycles are
>>> permitted but they are not cycleways.
>> 
>> Generally speaking I'd consider that highway=cycleway, foot=yes. 
>Same
>> with the variation that has lanes but no sidewalks and clearly has
>> pedestrians walking on it in the Mapillary.  I'd consider it
>
>Normal practice in Germany is to make all shared cycle/footpaths 
>highway=path + bicycle=designated + foot=designated with an optional 
>segregated=yes/no.
>
>Routers should be able to cope with this.
>
>Regards,
>Maarten
>
>___
>talk mailing list
>talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[pangose]

Hej
När det nu har lyfts så pass allvarlig kritik av importunderlaget så undrar jag 
om vi inte ska byta strategi och i stället sätta upp en server som via 
MapWithAI serverar datan per område för manuel bearbetning? 

Det skulle betyda att grigorys polerade data finns tillgängliga för alla med 
josm.
Då kringgår vi alla problem eftersom att det knappast behövs importeras nånting 
i Malmö, men mycket däremot saknas på Västernorrlands landsbygd och kan hämtas 
eftersom av nån med lokalkunskap.

Om jag förstått teknologin rätt så är den så smart att bara det som saknas i 
området som hämtas ind i mapwithai-lagret.

Mvh
pangoSE 

On January 18, 2020 12:03:27 AM GMT+01:00, Grigory Rechistov via Talk-se 
 wrote:
>
>Hej igen,
>Jag har uppdaterat mina skript för att upptäcka och slå samman
>ytterligare nodpar som borde vara en nod, t ex "Stora" + "mosse" ska
>till "Stora mosse" osv. Det fanns dock bara 5 (fem) noder att
>korrigera; de är nu taggade med ett extra nyckelvärde note="Name is
>merged from parts, recheck it".
> 
>Dessutom fick skripten och data mindre förbättringar att samtliga noder
>nu blir taggade med extra etiketter som dokumenterar vilka
>namnförändringar tillämpats av skriptet.
> 
>Länken till mappen results-v11: 
>https://drive.google.com/open?id=1SuAaC_uNJPzFb3lHquqDD3lQVWP_6iUu .
>Jag kommer även uppdatera importplanen men den feedback som redan
>finns.
> 
>Trevlig helg! Återkommer nästa vecka.
> 
> 
>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: [OSM-talk] Deleting template parameters copied to data items

[pangose]

Hi Christoph
Could you please comment on the wiki instead?
I never saw you on the wiki, so I'm not surprised to see that your opinion is 
not voiced there at all to my knowledge. 

To the casual scroll-by reader who is not familiar with how the wiki works: as 
of now there is a bot who keeps the data items up to date from wiki taginfo 
boxes. This suggestion would not change anything other than grabbing 
information from the item. This would also mean that if someone wants to add 
information it would best be done on the item.
The items are linked on the left from all wikipages and are very similar to how 
wikidata works.
 
Wikidata is BTW very rapidly becoming the most popular wiki with an increasing 
number of editors. It is not that huge an effort to learn how statements work 
and I'm sure we could create a good introduction if anyone needs it. My 
suggestion is to look at the video introduction and perhaps a video about the 
wikidata interface and then just go ahead and be bold on our items 

If you have questions about how data items work see 
https://wiki.openstreetmap.org/wiki/Data_items

Cheers

On January 15, 2020 2:03:29 PM GMT+01:00, Christoph Hormann  
wrote:
>On Wednesday 15 January 2020, Mateusz Konieczny wrote:
>> PangoSE started "Transition to use data items when this can be done
>> without loosing information" discussion at
>> https://wiki.openstreetmap.org/wiki/Talk:Wiki#Transition_to_use_data_
>>items_when_this_can_be_done_without_loosing_information
>> <https://slack-redir.net/link?url=https%3A%2F%2Fwiki.openstreetmap.or
>>g%2Fwiki%2FTalk%3AWiki%23Transition_to_use_data_items_when_this_can_be
>>_done_without_loosing_information=3>
>>
>> It is about whatever it is correct to delete data from the OSM Wiki
>> page after it was copied to data items.
>>
>> Anyone with opinion on that topic is welcomed to comment in this
>> discussion on the OSM Wiki.
>
>This is a move that has been a long time coming as part of a piecemeal 
>effort by some to establish a technocratic rule on the OSM wiki by 
>moving central content out of the control of the mappers into the 
>domain of data items with higher hurdles of participation due to poor 
>ergonomics (the whole concept of requiring human editors to deal with 
>numerical IDs for features that already have a unique identifier in OSM
>
>by design never ceases to amaze me) and with an established ability of 
>the technocrats to control the crowd sourced editing work with bots.
>
>Quite obviously that it is not a good idea.  But it does not matter
>much 
>because the community has plenty of options to work around this should 
>it indeed be implemented against the interests of the mapper community.
> 
>I would for example if something in the info box is wrong and this is 
>not part of the wiki page of a tag as it should be not delve into the 
>awkward interface of some separate database and subject my edits there 
>to the rule of some technicrats with bots but would simply add the 
>information to the wiki page.  We could also add - in addition to the 
>bot managed info boxes - new real human managed info boxes.  All of 
>this would be awkward of course but nothing that could not be done.
>
>The real discussion that needs to be done is how we can get to a better
>
>documentation of the actual use of tags by humans for humans.  We have 
>had some useful discussion on this at SotM last year and in a follow-up
>
>here:
>
>https://lists.openstreetmap.org/pipermail/talk/2019-September/thread.html#83286
>
>Continuing in that direction of a better human curated documentation of
>
>tags is the thing to pursue, not moving towards a bot managed database 
>in replacement of or in control of human contributions.
>
>-- 
>Christoph Hormann
>http://www.imagico.de/
>
>___
>talk mailing list
>talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Too subjective & problematic Re: no-go-areas

[pangoSE]

On 2020-01-01 15:28, Rory McCann wrote:
This topic has come up before, and unfortunately when you think about 
it, there is no objective way to define a "no go area". It's all 
subjective. So it doesn't belong in OSM.


People do live in many of these areas, so software that didn't route 
in/through these areas would be pretty bad for people who need to go there!


Plus, "no go areas" are often correlated with where ethnic minorities or 
different classes live, which is not good.


I agree!

A map cannot solve a lack of general awareness when visiting a 
new/unknown place. Going to the mountains to hike can also be dangerous 
if you are not well prepared. This is of course not marked on the map!


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

Re: [Talk-se] Lokala cykelleder i och omkring Karlstad - definiera ett nytt lcn?

[pangoSE]

Ser bra ut :)

On 2020-01-01 23:42, Lennart Romberg wrote:

Jag jag mjukstartat lite med den här.
https://www.openstreetmap.org/changeset/79082676#map=15/59.3779/13.5176
Tar fler i takt med att jag hinner reka dem.
Lite fundersam på hur jag bäst får till t ex "I2-området" 
(Naturcykelleder i pdf'en), den är ju varken en linje eller eller en ren 
slinga.

/ Lennart

Den ons 1 jan. 2020 kl 23:10 skrev Tomas Marklund 
mailto:tomasmarklun...@gmail.com>>:


Kör på bara. Lämpliga namn kan väl vara typ "Råtorp - Centrum -
Alster".

/Tomas

Den tis 31 dec. 2019 00:10Lennart Romberg mailto:lennart.romb...@gmail.com>> skrev:


Det finns några lokala cykelleder i och omkring Karlstad,
synliga genom speciella skyltar och beskrivna på kartan

https://karlstad.se/globalassets/filer/trafik/trafik_och_gator/cykla/cykelkarta_karlstad_2015.pdf

Funderar på att lägga in dem som nya relationer i OSM. Kan jag
bara skapa ett lcn efter eget huvud och välja ett lämpligt namn
eller skall det förankras / registreras / godkännas nånstans?
Lämpligt att definiera en network-relation för det halvdussin
leder som ingår?

(Skrev in samma fråga på Talk:WikiProject Sweden/Cycle networks)

___
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] NMD 2018 Import delområden Gällivare

[pangose]

Hej Hans
Kul att du vill hjälpa till. Tyvärr är NMD import i dagsläget stoppad eftersom 
underlaget är för dålig kvalitet och innebär mera arbete än det är värt.
Om du vill kartera manuellt rekommenderar jag at du manuellt lägger in LMs 
flygfotolager i josm och kör. 
Mvh
pangoSE 

On December 23, 2019 11:29:19 AM GMT+01:00, Hans K  
wrote:
>Hej!
>
>Jag är från Gällivare och tänkte att det vore roligt om det fanns lite
>bättre bakgrundsdata i området. Det är ju lite tomt här uppe. Jag har
>lyckats att hitta till NMD importen men området för Gällivare är ju
>väldigt stort och det stod att man skulle vända sig till denna listan
>för att fråga om någon kan dela upp området Gällivare i tiles. Det
>skulle uppskattas mycket och göra jobbet like enklare.
>
>Hans
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-se] Slussport som man kan gå över

[pangose]

Det låter som en bugg i JOSMs validator. Öppna en ticket och ta diskussionen 
där.
Lägg gärna till width och surface också. Är cykling förbjudet med skylt? Om 
inte så byta till path. 
Om den är bred då kan du överväga att rita porten som area i stället, då kanske 
validatorn bliver nöjd också. 
Är det nått räcke på sidorna?  Då ritar du in det också genom att ha porten som 
en MP med räcke på dem relevanta sträckorna. 
Gångvägen lägger tvärs över det hela.

On December 21, 2019 12:39:15 AM GMT+01:00, Lennart Romberg 
 wrote:
>Jag har problem att tagga en slussport som man kan passera till fots,
>så
>att olika validatorer blir nöjda.
>
>En variant är att ha en sträcka från kant till kant och tagga den som
>seamark:type=gate och waterway:lock_gate. Sen vill man ju kunna passera
>tvärs över till fots så då lägger jag på highway=footway. JOSM gillar
>inte
>kombinationen highway och waterway.
>
>Då testade jag en punktnod mitt i farleden med seamark och waterway,
>samt
>la en footway från kant till kant via punktnoden. JOSM är nöjd men
>Osmose
>undrar hur man kommer över vattnet utan bro.
>
>Tidigare har jag lagt en slussport och en svängbro på samma ställe men
>det
>känns ju också knas.
>
>Bättre tips, någon?
>
>/ Lennart
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-se] Skapa rad av likadana hus?

[pangose]

Om du tydligt beskriver på engelsk i en feature request på 
josm.openstreetmap.de då kanske nån fixar det?

On December 8, 2019 4:17:21 PM GMT+01:00, Lennart Romberg 
 wrote:
>Jag kollade beskrivningen på terracer men den verkade inte kunna göra
>riktigt det jag ville. Funkar väl om man ska skiva upp en rektangel,
>men
>säg att man har kedjehus med förskjutna garage, det tror jag inte den
>fixar.
>
>Det jag gjorde var att placera ut rätt antal punktnoder med
>"distribute"
>och sen använda dem som guide för att sikta in ett hörn på varje hus.
>Men
>med tanke på hur enkelt det är i Powerpoint eller MS Visio så kändes
>det
>lite meckigt.
>
>Den sön 8 dec. 2019 kl 13:07 skrev :
>
>> Har du testat terracer? Jag brukar rita runt hela ytterväggen och sen
>ange
>> antalet av enheter i radhusblocket.
>>
>> On December 7, 2019 7:23:19 PM GMT+01:00, Lennart Romberg <
>> lennart.romb...@gmail.com> wrote:
>>>
>>> Om man har ritat ett hus och gjort x kopior, kan man få dem utlagda
>i rad
>>> med samma avstånd (på samma sätt som "distribuera noder" men för
>hela
>>> area-objekt?
>>> Har läst igenom listan över josm-plugins men hittar inget som ser ut
>att
>>> göra det jag vill. (Och jag har hittat många rad- och kedjehus med
>lite
>>> oregelbunden placering, så tyder på att inget verktyg finns?).
>>>
>>> / Lennart
>>>
>>> ___
>> 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] Skapa rad av likadana hus?

[pangose]

Har du testat terracer? Jag brukar rita runt hela ytterväggen och sen ange 
antalet av enheter i radhusblocket. 

On December 7, 2019 7:23:19 PM GMT+01:00, Lennart Romberg 
 wrote:
>Om man har ritat ett hus och gjort x kopior, kan man få dem utlagda i
>rad
>med samma avstånd (på samma sätt som "distribuera noder" men för hela
>area-objekt?
>Har läst igenom listan över josm-plugins men hittar inget som ser ut
>att
>göra det jag vill. (Och jag har hittat många rad- och kedjehus med lite
>oregelbunden placering, så tyder på att inget verktyg finns?).
>
>/ Lennart
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [OSM-talk] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych ? names of international objects

[pangoSE]

I agree with Oleksiy.

If you see Qxxx numbers in your editor ONLY it is the editor that should 
be fixed to fetch the label/description in the local language (of the 
browser, JOSM, or whatever tool you access our data through).


I believe that we should deprecate all wikipedia links as they are just 
potentially obsolete cruft that can be inferred from the wikidata item. 
(I am also an editor of Wikidata)


If you really want the Wikipedia link displayed fix your editor to fetch 
the local wikipedia link (if any) for your local language in addition to 
the label and description.


amike salutas

pangoSE

On 2019-12-06 12:27, Oleksiy Muzalyev wrote:
At least in the JOSM editor there is an additional text in English 
near the wikidata code-title.


Since the wikidata title (or name) is usually translated on the 
wikidata page itself in different languages and it is a part of the 
accessible database, this text could be in different languages in a 
map editor.


If there is no translation of the wikidata item in a particular 
language, one can add it, even if there is no Wikipedia article in 
this language. The wikidata also contains the description and the 
alternative name.


So basically having the wikidata code-name, it is possible to display 
the name and even the description in any language of choice in a map 
editor.


So wikidata makes makes it technically possible to implement the 
modern principle stating that the true international language is the 
translation.


Best regards,
Oleksiy

On 06-Dec-19 11:25, Mateusz Konieczny wrote:
Yes, wikidata tag may be useful but it is an alphanumeric gibberish 
not readable by humans.





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

Re: [Talk-se] Ska adresser ha land, stad, postnummer och allt?

[pangose]

Hej Andreas

Tusen tack för alla detaljer. 

Jag hade hoppats att datan var bättre kvalitet än vad du berättar här.

Jag har inte kollat Gävles data än.

Vi får nog ta det väldigt försiktigt om det du beskriver även stämmer på Gävle 
och övriga landets data.

Jag har själv lagt in en del adresser i Härnösand, men det finns mycket kvar 
att göra. Jag  är sugen på att göra nått åt det och att mappa efter ett lager 
med adressdata utan att förstöra dem tiotusentals adresser vi redan har låter 
som en bättre väg fram.

När jag lagt till adresser har jag oftast bara behövt kolla några få hus per 
väg och sedan kunnat räkna ut resten och placera dem effektivt med ett josm 
plugin.
Om ett datalager finns bliver det ju ännu enklare för då ser man kanske hur dem 
ligger vid korsningarna utan att behöva kolla överallt.

Metoden jag här beskriver gör att automatiska uppdateringar bliver omöjliga,  
MEN vi skulle kunna göra difflager så alla adresser från 2019 är gröna och alla 
som ändrades i 2020 är röda. Då är det bara att kolla alla röda vid varje 
datasläpp.

WDYT?

Mvh
pangoSE

On December 3, 2019 8:08:42 PM GMT+01:00, "Andreas Vilén" 
 wrote:
>Hej!
>
>För några år sedan genomförde jag en stor adressimport för Helsingborgs
>kommun. Utöver detta har jag mappat otaliga adresser manuellt, har ett
>intresse för adressättning och jag arbetar även med adresser i
>yrkeslivet.
>Här är några av mina erfarenheter som jag samlat på mig genom åren.
>
>1) Officiella adresser är fler än skyltade adresser
>Med detta menar jag att i officiella register är principen att varje
>entré
>får en adress. Olika kommuner är olika strikta med detta, men i
>kommuner
>som följer detta strikt innebär det att varenda sidoentré, butik,
>miljöhus
>osv får en egen adress. Det innebär även i vissa kommuner att alla
>hörntomter har dubbla adresser, ibland tom tre eller fyra baserat på
>kvarterens utformning. Dessa finns naturligtvis med i officiella
>dataset,
>men är väldigt svåra att bekräfta på marken och inte alltid vettiga att
>ha
>med i OSM-databasen.
>
>2) Officiella adresser stämmer inte alltid överens med skyltade
>adresser
>Även detta är något jag lärt mig inom yrkeslivet framför inom OSM, men
>båda
>har gett mig insikter om detta. Adresser byts av naturen ut då och då.
>Ett
>hus kan ha en adress satt för decennier sedan. Huset kan ha byggts om,
>en
>entré flyttats och plötsligt får huset en ny adress, men de boende
>ändrar
>inte på sin skylt och en mappare som går förbi mappar naturligtvis
>what's
>on the ground, dvs det som står på skylten. Detta är rimligt och så OSM
>ska
>fungera. Här är det närmast en filosofisk fråga om den officiella
>adressen
>ska skriva över vad som faktiskt finns skyltat. Detta är en fråga som
>vi
>även många gånger diskuterat på jobbet och aldrig riktigt kommit till
>en
>ordentlig slutsats.
>
>3) Officiella adresser ligger inte alltid rätt
>För en tid sedan blev jag, även då på jobbet, uppmärksammad om att
>adresserna i det här området var fel:
>https://www.openstreetmap.org/changeset/74756989 Eftersom det ligger i
>närheten av mig gick jag dit och tog en titt. Lo and behold, i princip
>alla
>adresser var felmappade. Jag fick byta plats på nästan alla A och B.
>Jag
>fick också skämmas lite eftersom jag själv mappat detta fel en gång i
>tiden, baserat på Lunds kommuns officiella data som vi hade möjlighet
>att
>kartera av. Utöver att det kan bli så här dramatiskt fel kan det också
>bli
>mindre fel såsom adresser som kommer i fel ordning (det var flera ACB
>och
>liknande i Helsingborg, som jag dubbelkollat IRL. Vissa stämde, andra
>var
>fel). I vissa kommuner har man missat att koordinatsätta adresser
>ordentligt. I Svedala kommun har man exempelvis (av misstag?)
>koordinatsatt
>alla adresser per radhus i ett område på exakt samma position, istället
>för
>där respektive radhus befinner sig. Om man då ersätter redan mappad
>data
>med importerad finns risken att det blir väldigt fel.
>
>4) Det finns udda "nödfallsadresser"
>Olika kommuner har olika policy, men exempelvis Helsingborgs kommun
>adressätter alla lekplatser, Lunds kommun adressätter parker, Vellinge
>kommun adressätter offentliga toaletter, osv. Allt detta är vettigt
>utifrån
>ett perspektiv att en ambulans ska hitta rätt och liknande, men är i
>princip omöjligt att bekräfta on the ground. Dessa adresser är inte
>nödvändigtvis något vi ska undvika (jag har behållit alla
>lekplatsadresser
>i Helsingborg) men kan leda till "clutter" och går som sagt inte att
>kontrollera.
>
>5) Bostadsområden adressätts långt innan de byggs
>Ofta sätter kommuner adresser långt innan ett bostadsområde byggts,
>eller
>ens har beslutat om att det ska byggas. Ett exempel i Vellinge k

Re: [Talk-se] Ska adresser ha land, stad, postnummer och allt?

[pangose]

Helt enig med Björn här. Titta gärna på hur dem gjorde i Danmark runt 
adressimporten i 2017 tror jag det var.
Där var det liknande funderingar.
 
Frågan är varför Gävle lägger ut detta data från LM som CC0 och inte LM själva. 
Jag hoppas LM själva kommer frige adresser för hela landet i 2020 som CC0. 

On December 2, 2019 8:49:30 AM GMT+01:00, "Björn Stenberg"  
wrote:
>On Sun, Dec 1, 2019 at 9:38 AM Snusmumriken
>
>wrote:
>
>> > Att ta bort groud-truth-verifierade adresser och ersätta dem med en
>> import låter som en dålig idé.
>
>Det beror väl på hur mycket manuellt inmatade adresser det finns i
>området
>idag, samt hur mycket fel det är i den importerade datan.
>
>Givet att det ser ut som på de flesta orter, med tämligen låg andel
>adresstaggade byggnader, samt att den officiella databasen har en
>relativt
>låg felhalt, tycker jag det är betydligt mer rimligt att göra importen
>och
>sedan granska och rätta resultatet. Viljan att handknacka tusentals
>adressnoder är liten idag och kommer knappast öka dramatiskt av ett
>hypotetiskt kartlager som man kan manuellt kan skriva av ifrån.
>Dessutom
>kommer de handgjorda taggarna också innehålla fel, kanske till och med
>fler
>fel än importen.
>
>--
>Björn
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-se] Flera skoloperatörer på samma skolområde - hur tagga?

[pangose]

Gör så, det bliver bra. Skriv gärna en not på området om detta. 
Vår tagging av skolor skulle som du märker behöva förbättras. Du är hjärtligt 
välkommen med förslag till tagging listan.
Verkligheten är inte så sällan mera komplex än vår tagging klarar av att 
återspegla.
Vi har en liknande skola här i Härnösand f.ö. där samma problemställning finns.

On December 2, 2019 8:27:04 AM GMT+01:00, Lennart Romberg 
 wrote:
>Hm, två motsägande svar på samma fråga. Men det blir svårt att rita
>olika ytor per skoloperatör, de håller till i olika delar och olika
>våningar i samma byggnad.
>Jag är mer inne på att återställa skolområdet och sätta punktnoder på
>rimliga ställen i byggnaden för de olika operatörerna.
>
>Den mån 2 dec. 2019 kl 07:52 skrev Andreas Vilén
>:
>>
>> Validatorn har rätt. Du kan rita en skolyta per skola och bör inte
>rita en allmän för skolområde och en för varje skola.
>>
>> /Andreas
>>
>> Skickat från min iPhone
>>
>> 2 dec. 2019 kl. 07:26 skrev pang...@riseup.net:
>>
>> Ignorera validatorn denna gång. Den validitetsregel är till för att
>fånga upp tex parkering i parkering, m.m.
>> mvh
>>
>> On December 2, 2019 7:22:59 AM GMT+01:00, Lennart Romberg
> wrote:
>>>
>>> I närheten av där jag bor finns ett skolkomplex där flera olika
>skoloperatörer håller till. Området var taggat amenity=school och sen
>finns noder för olika operatörer, också taggade med amenity=school.
>JOSM varnar för "amenity inside amenity". Testade att ta bort det i
>mitt tycke intetsägande området och bara behålla operatörerna men då
>försvann färgrenderingen av området.
>>>
>>> Tänkte man kunde göra nåt men "landuse" i stället för att både äta
>kakan och ha den kvar, men på wikin om landuse står att skolområden ska
>taggas "amenity".
>>>
>>> Så hur gör man om man har flera skoloperatörer på samma skolområde?
>>
>> ___
>> 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] Flera skoloperatörer på samma skolområde - hur tagga?

[pangose]

Ignorera validatorn denna gång. Den validitetsregel är till för att fånga upp 
tex parkering i parkering, m.m.
mvh

On December 2, 2019 7:22:59 AM GMT+01:00, Lennart Romberg 
 wrote:
>I närheten av där jag bor finns ett skolkomplex där flera olika
>skoloperatörer håller till. Området var taggat amenity=school och sen
>finns
>noder för olika operatörer, också taggade med amenity=school. JOSM
>varnar
>för "amenity inside amenity". Testade att ta bort det i mitt tycke
>intetsägande området och bara behålla operatörerna men då försvann
>färgrenderingen av området.
>
>Tänkte man kunde göra nåt men "landuse" i stället för att både äta
>kakan
>och ha den kvar, men på wikin om landuse står att skolområden ska
>taggas
>"amenity".
>
>Så hur gör man om man har flera skoloperatörer på samma skolområde?
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-se] Ska adresser ha land, stad, postnummer och allt?

[pangoSE]

Licensen står vid själva filen när man klickar på detaljer (pil ner)

I detta fall 
https://www.gavle.se/service-och-information/om-gavle-kommun/oppna-data/datakatalog/data/#esc_entry=45_context=1


CC0! = allt kan importeras mha. nått lämpligt skript.

Jag föreslår att vi skapar en importplan och sen tar bort existerande 
adresser på byggnader i området och ersätter med noder från kommunen.


Det finns även byggnader, flygbilder, sopkorgar, m.m.

Flygbilderna är: CC BY-NC 4.0 (Attribution, Non-Commercial) så där 
skulle vi behöva fråga om vi kan rita utifrån dem.


Är det nån som är sugen på att dra i något av detta?

Mvh

pangoSE

On 2019-11-29 14:39, Lennart Romberg wrote:

Hej!

Som gröngöling så har jag inte bilden riktigt klar för mig. "Frigett"
antar jag innebär att upphovsrätten inte hindrar oss att använda
datat.
Men innebär det också att det kan importeras med nån automatik, eller
bara att man får titta på det / ha det som bakgrundslager när man
editerar?

/ Lennart

Den tors 28 nov. 2019 kl 20:21 skrev :

Hej.

Observera att 1/200 kommuner har frigett adressnoder (Gävle, och Umeå skulle 
säkert frige dem också om nån skulle fråga dem)

Därutöver håller Lantmäteriet på att utreda hurvidare dem ska kunna frige den 
resterande data dem i dag säljer dvs laserdata, fastighetskartan och 
adressnoder samt underlag som flygbilder och stereofoton.

Utredningen måste vara klar d. 17/1 och då kommer jag dela den här.

Tills dess föreslår jag att du lägger energi på nått annat än adressnoder 
eftersom jag anser att dem med 90% sannolikhet kommer vara offentliga inom 
några år, likt dem nu är i DK.

Detta har i tillägg till flygbilder från fugro och sen sds för övrigt lett till 
at DK kartan nått väldigt hög kvalitet på kort tid.

Jag föreslår att alla som kan lobbar på LM och regeringen att som minimum frige 
dessa.

Mvh
pangoSE

On November 28, 2019 12:35:59 AM GMT+01:00, Hartwig Alpers  
wrote:

Jag rekommenderar att fylla i postnummer och stad. Annars går det inte
at hitta adresser som
"Museivägen 6 - 464 72 Håverud" eftersom det finns varken en omgivande
polygon för staden (eller byn) Håverud (bara Melleruds kommun) eller en
polygon för postnummret.

Dessutom får du inte med nån information från omgivande objekt när du
gör en sökning t. ex. via http://overpass-turbo.eu/
/hca

On 27.11.19 23:06, Lennart Romberg wrote:

  På osm-wikin står att land, stad, postnummer oftast är överflödiga
  eftersom de går att härleda från omgivande objekt. Men de ser i
  allmänhet ut att vara ifyllda, i Sverige. Finns någon konsensus om att
  de bör fyllas i? Gissar att postnummer inte utan vidare går att
  härleda från omgivande objekt. / Lennart

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

Re: [Talk-se] Ska adresser ha land, stad, postnummer och allt?

[pangose]

Hej.

Observera att 1/200 kommuner har frigett adressnoder (Gävle, och Umeå skulle 
säkert frige dem också om nån skulle fråga dem)

Därutöver håller Lantmäteriet på att utreda hurvidare dem ska kunna frige den 
resterande data dem i dag säljer dvs laserdata, fastighetskartan och 
adressnoder samt underlag som flygbilder och stereofoton.

Utredningen måste vara klar d. 17/1 och då kommer jag dela den här.

Tills dess föreslår jag att du lägger energi på nått annat än adressnoder 
eftersom jag anser att dem med 90% sannolikhet kommer vara offentliga inom 
några år, likt dem nu är i DK.

Detta har i tillägg till flygbilder från fugro och sen sds för övrigt lett till 
at DK kartan nått väldigt hög kvalitet på kort tid.

Jag föreslår att alla som kan lobbar på LM och regeringen att som minimum frige 
dessa.

Mvh
pangoSE

On November 28, 2019 12:35:59 AM GMT+01:00, Hartwig Alpers  
wrote:
>Jag rekommenderar att fylla i postnummer och stad. Annars går det inte 
>at hitta adresser som
>"Museivägen 6 - 464 72 Håverud" eftersom det finns varken en omgivande 
>polygon för staden (eller byn) Håverud (bara Melleruds kommun) eller en
>
>polygon för postnummret.
>
>Dessutom får du inte med nån information från omgivande objekt när du 
>gör en sökning t. ex. via http://overpass-turbo.eu/
>/hca
>
>On 27.11.19 23:06, Lennart Romberg wrote:
>> På osm-wikin står att land, stad, postnummer oftast är överflödiga
>> eftersom de går att härleda från omgivande objekt. Men de ser i
>> allmänhet ut att vara ifyllda, i Sverige. Finns någon konsensus om
>att
>> de bör fyllas i? Gissar att postnummer inte utan vidare går att
>> härleda från omgivande objekt. / Lennart
>>
>> ___
>> 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] Många nya öppna data från naturvårdsverket

[pangose]

Hej Henrik

Tack for insparket. 

Det går självklart att rita en lika bra karta utifrån ett osm bakgrundslager 
med fria lager från staten uppepå.

OSM är ofta omtalad som en karta, men det är ju inte så.
Vi är en världens största och mest heltäckande geografiska databas.

Vi är dem enda som kan svara på frågor som: 
* hur många km2 naturreservat finns det i % i SE jämfört med Kina per km2 
landyta?
* Hur många km leder finns inom gränserna för våra svenska naturreservat? 1000? 
1? 
** Hur många av dessa har bra synlighet (utesluta baserad på trail_visibility=)
* Hur många km leder finns inom 20 km från härnösands centrum? (via around 
funktionen i overpass)

När data ändrar sig i omgivningen tex via domstolsbeslut så är det fullt 
möjligt för dig, mig och anställda på NV att uppdatera datan direkt i 
databasen. Skulle du vilja ta upp detta på myndighetsnivå att få bidra till OSM 
på din och dina kollegers arbetstid? Om alla GIS anställda i SE/världen skulle 
få bidra under 2h i veckan på betald arbetstid skulle det säkert göra en stor 
skillnad. 

Tidigare har inte OSM funnits så alla stater har likt öar i havet gjort deras 
egna GIS arbete helt eller delvist avskärmade från omvärlden. 

Jag skulle gärna att nån skriver ett skript så att vi likt quickstatements på 
wikidata automatiskt kan uppdatera ett helt gäng reservater med uppdaterade 
koordinater från NV när dessa släppts i nått format.

OSM har pionerad en mängd nya geodata format och verktyg så jag hoppas att 
dessa kan utvecklas vidare. Overpass API kombinerad med efterbehandling i QGIS 
är mycket kraftfulla verktyg. 

I dagsläget funkar det så för alla addressnoderna i Danmark som uppdateras från 
staten då och då. Detta är enklare eftersom det bara är én nod för varje.
Om/när LM kritar skorna och friger addressdatan kan vi göra likadant. 

Mvh
pangoSE

On November 19, 2019 8:19:30 AM GMT+01:00, Henrik Lundqvist 
 wrote:
>Hej, är GIS-samordnare på Länsstyrelsen och har en del insyn. NV mfl
>myndigheter tillgängliggör miljödata som CC0 och publikationer och
>rapporter som CCBY.
>Alla WMS-tjänster brukar även finnas som Rest-tjänster som är klart
>bättre
>att använda för detta syfte. Även shapefiler brukar tillgängliggöras.
>Ang naturreservat så kanske det tillkommer ca 100st per år nationellt
>beroende på anslag och jag har alltid ställer mig frågan varför
>bestämmelser såsom naturreservat ska läggas in i grundkartor, när det
>är så
>föränderligt och dessutom finns som tjänster för alla att konsumera
>uppepå?
>Om tex fastighetsgränser skulle bli öppna data som ändras dagligen,
>skulle
>du då finnas initiativ att föra in dessa?
>Man tar på sig en otrolig förvaltningsuppgift om man har för avsikt att
>alltid ha korrekt grundata.
>Dock tycker jag att topografi och naturtyper NMD passar perfekt.
>
>Hoppas ni förstår mitt tänk.
>
>Mvh Henrik
>
>Den sön 10 nov. 2019 14:29pangoSE  skrev:
>
>> Hej
>>
>> All data från naturvårdsverket är CC0
>>
>>
>>
>https://oppnadata.se/datamangder/#esc_org=base:635/resource/9de761c624866bdca2f2e6ccdeba9815
>>
>> Det finns nu följande som jag tycker vi ska börja med
>(förkortningarna
>> är mina):
>> * kulturreservat, (NVKR)
>> * Naturvårdsavtal, (NVNVA)
>> * satellitbaserad våtmarksövervakning (som kanske kan hjälpa oss få
>in
>> flera våtmarker) (NVVÅ)
>> * Data för leder och anordningar inom skyddade områden samt statliga
>> leder i fjällen finns från och med V17 2018 tillgängliga enligt
>> principen för öppen data. (se detaljer:
>>
>>
>https://gpt.vic-metria.nu/data/land/Leder%20och%20friluftsanordningar%20beskrivning%20av%20%c3%b6ppna%20data.pdf)
>>
>> (NVLED)
>> * Skyddade områden, fågeldirektivet (Natura 2000, SPA) (NVSPA)
>> * Skyddade områden, interimistiska förbud (i väntan på beslut om
>> naturreservat) (NVIF)
>> * Skyddade områden, biosfärsområden (NVBSF)
>> * Skyddade områden, naturvårdsområden (NVNV)
>> * Skyddade områden, biotopskyddsområden (NVBSK)
>> ** AnderAndersson har börjat lägga in några av dessa
>> * Skyddade områden, naturreservat (NVNR)
>> **(se min förre epost, det finns just nu 5026 NR i SE[2] som är
>gällande
>> och vi har[1]:
>> typ rel way total
>> boundary=protected_area 50  0329
>> leisure=nature_reserve  13253546
>> totalt  137538755250[5])
>>
>> Det finns nya WMS tjänster som saknas i JOSM. (många av dessa verkar
>> inte fungera via besök i min webbläsare och jag saknar kunskap om hur
>vi
>> kan få in detta i JOSM - vet nån annan hur vi kan få detta att
>funka?)
>>
>> Vi skulle behöva prata om hur vi bäst gör för att få in all detta i
>nån
>> uppdaterbar ordning och vad som är 

Re: [Talk-se] Talk-se Digest, Vol 139, Issue 10

[pangoSE]

 2019 at 9:56 AM Axel Pettersson
 wrote:

Hej,
I den mån OSM-gemenskapen vill ha det kommer ett glatt hejarop från Wikimedia 
Sverige[1]. Vill ni ha stöd på något sätt hjälper vi gärna till, oavsett om det 
gäller organisatoriska frågor eller en ansökan om bidrag[2] för att kunna 
träffas eller åka på någon konferens.

[1] https://wikimedia.se/om-oss/
[2] https://se.wikimedia.org/wiki/Projekt:St%C3%B6d_till_gemenskapen_2019#Bidrag

Bästa hälsningar,
/axel
--
Axel Pettersson
Projektledare GLAM/Outreach
Wikimedia Sverige

+46 (0)733 96 55 65
axel.petters...@wikimedia.se

Twitter: @Haxpett

Stöd fri kunskap, bli medlem i Wikimedia Sverige.
Läs mer på wikimedia.se/sv/blimedlem



Den sön 10 nov. 2019 kl 12:02 skrev Christian Asker :


Hej. Jag tycker att det är en bra idé, även om jag just nu har för
mycket föreningsengagemang för att själv engagera mig. Några fysiska
träffar vore ju kul!

Mvh Christian




Den 2019-11-10 kl. 09:34, skrev pangoSE:

Hej

Jag skulle vilja stärka vår sammanhållning och ha möjlighet att träffa
nån av er andra som håller på i Sverige. Därutöver skulle jag vilja ha
möjlighet att skicka nån till Advisory Board och att vi tillsammans
tar ställning för sånt som är viktigt för oss som ideella deltagare i
projektet.

Trots att jag varit aktiv i snart 10 år har jag bara träffat en annan
lokalt (Blajo).

Finns det interesse att få igång en förening?
Hur många är vi egentligen här på listan?

Se https://welcome.openstreetmap.org/about-osm-community/local-chapters/

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





--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se


-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openstreetmap.org/pipermail/talk-se/attachments/20191118/a34c43b6/attachment-0001.html>

--

Subject: Digest Footer

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


--

End of Talk-se Digest, Vol 139, Issue 10



___
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] Många nya öppna data från naturvårdsverket

[pangoSE]

Hej!

Ang. NVLED

Jag har nu börjat importera leder manuellt genom att rita av från NVs 
WMS tjänst.

Bakgrundslagret är nu tillagd i JOSM så det är bara att sätta igång :)

Följ vänligen wikin och lägg till etiketterna jag angett där. Se 
https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/Open_data/Naturv%C3%A5rdsverket#.C3.96versikt_.C3.B6ver_relevanta_NV-data


I detta fall: source=Swedish Environmental Agency Trails + fixme=verify

Idén med att använda fixme är att den ska tas bort när nån gått på leden 
och verifierat att den finns i verkligheten.


Följ med via denna sökning i vad som lagts in: 
https://overpass-turbo.eu/s/O9E


Välkommen att delta!


On 2019-11-10 14:28, pangoSE wrote:

Hej

All data från naturvårdsverket är CC0

https://oppnadata.se/datamangder/#esc_org=base:635/resource/9de761c624866bdca2f2e6ccdeba9815 



Det finns nu följande som jag tycker vi ska börja med (förkortningarna 
är mina):

* kulturreservat, (NVKR)
* Naturvårdsavtal, (NVNVA)
* satellitbaserad våtmarksövervakning (som kanske kan hjälpa oss få in 
flera våtmarker) (NVVÅ)
* Data för leder och anordningar inom skyddade områden samt statliga 
leder i fjällen finns från och med V17 2018 tillgängliga enligt 
principen för öppen data. (se detaljer: 
https://gpt.vic-metria.nu/data/land/Leder%20och%20friluftsanordningar%20beskrivning%20av%20%c3%b6ppna%20data.pdf) 
(NVLED)

* Skyddade områden, fågeldirektivet (Natura 2000, SPA) (NVSPA)
* Skyddade områden, interimistiska förbud (i väntan på beslut om 
naturreservat) (NVIF)

* Skyddade områden, biosfärsområden (NVBSF)
* Skyddade områden, naturvårdsområden (NVNV)
* Skyddade områden, biotopskyddsområden (NVBSK)
** AnderAndersson har börjat lägga in några av dessa
* Skyddade områden, naturreservat (NVNR)
**(se min förre epost, det finns just nu 5026 NR i SE[2] som är gällande 
och vi har[1]:

typ    rel    way    total
boundary=protected_area    50    0329
leisure=nature_reserve    1325    3546
totalt    1375    3875    5250[5])

Det finns nya WMS tjänster som saknas i JOSM. (många av dessa verkar 
inte fungera via besök i min webbläsare och jag saknar kunskap om hur vi 
kan få in detta i JOSM - vet nån annan hur vi kan få detta att funka?)


Vi skulle behöva prata om hur vi bäst gör för att få in all detta i nån 
uppdaterbar ordning och vad som är relevant för OSM.


Min uppfattning är att naturreservaten är den största datamängden, men 
många av våra reservat saknar metadatan från källdatan verkar det som. 
(Se 
https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/naturvardsverket_import#Boundary 
för vilka key/value som vi tillämpar.)


När det gäller import så skulle jag mycket hellre lägga våra krafter på 
import av denna högkvalitetsdata ritad av människor framför den 
fullautomatiska NMD data tex som tyvärr håller låg kvalitet och nog inte 
är lämpad alls för import.


Jag har beskrivit här[3] hur jag kan lägga in flera på en gång så det 
behöver inte ta så lång tid alls (5 min per 10 reservat som saknas)


Min uppskattning baserad på NVNR datan och vår NR-data är att ungefär 
100 reservat saknas och minst lika många är större i NVNR än i OSM.


Om du utfrån att ha läst detta vill sätta igång med NR då rekommenderar 
jag att arbeta per län och ladda ner från overpass i JOSM[4] och 
filtrera ut samma län ur NVNR med QGIS[2].


Lycka till!

mvh
pangoSE

[1] jag gjorde följande för att få fram statistik om alla våra NR:
hämtade sweden-latest.osm.pbf på geofabrik.de
$ cat sweden-latest.osm.pbf |osmconvert - -o=swe.o5m
$ osmfilter swe.o5m --keep="leisure=nature_reserve" 
--keep="boundary=protected_area" >swe.nr.osm

valfritt extrasteg som ökar hastigheten i läsning/skrivning:
konvertera från .osm -> .pbf:
$ osmconvert swe.nr.osm -o=swe.nr.osm.pbf
-> sökning i JOSM
[2] jag filtrerade via QGIS, se tidigare epost. Utav datan i NR finns 
följande protect_class=0,1,4

[3] https://www.openstreetmap.org/user/pangoSE/diary/391178
[4] https://josm.openstreetmap.de/wiki/Help/Action/Download och knappa 
in detta i wizard: boundary=protected_area or leisure=nature_reserve in 
"västerbottens län"
[5] Dette betyder inte att vi har med alla. Vissa av våra reservat är 
inte med i NVNR och finns kanske i .


___
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

[OSM-talk] We got permission to trace from Strava

[pangose]

Hi

This is very good news!

I updated the wiki. Lets integrate this in our editors.

Cheers
pangoSE


 Original Message 
From: Rodrigo Davies 
Sent: November 16, 2019 6:59:19 AM GMT+01:00
To: "pang...@riseup.net" 
Subject: Re: Permission to trace from heatmap

Hi pangoSE,

I chatted with our geo team and we don’t currently see a problem with you
continuing this practice. We’re big fans of OSM.

Out of interest, are you aware of this tool?
http://strava.github.io/iD/#background=Bing=17.00/-110.02947/53.27094

Best
Rodrigo


—
Rodrigo Davies
Senior Product Manager, Metro
Strava | San Francisco, USA

-- Forwarded message -
> From: 
> Date: Thu, 14 Nov 2019 at 21:39
> Subject: Permission to trace from heatmap
> To: 
>
>
> Hi 
>
> I would love to improve OSM by tracing missing paths from your heatmap.
> Are you willing to permit this to OSM users?
>
> Currently OSM is the best outdoor map in Sweden but unfortunately a lot of
> paths is still missing in my area.
> I would love to use your heatmap to help me trace and visit new paths and
> add them to the map.
>
> Note that in 2014 we got the permission from Paul Mach, Former Director of
> Strava Labs:
> "https://twitter.com/paulmach/status/455182880306905088
> Guillaume Rischard: «OK to use heatmap in JOSM editor?»
> Paul Mach, Former Director of Strava Labs: «Feel free to use the heatmap
> tiles for any map editing»
> 13 apr 2014"
>
> I believe that this is win-win situation for Strava and OSM. Strava could
> increase their brand recognition and realize better quality maps if this
> were permitted. A lot of OSM-contributors are potential Strava users also.
> There are literally millions of OSM contributors.
>
> I look forward to you response and hope that you will give back to the
> community by allowing this use of the wonderful heatmap.
>
> Cheers
> pangoSE
>
-- 

Rodrigo Davies
Team Lead / Product Manager
San Francisco, CA | U.S.A

metro.strava.com <http://www.metro.strava.com/>

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

[OSM-talk] We got permission to continue tracing from Strava

[pangose]

Good news for OSM!
https://wiki.openstreetmap.org/wiki/Permissions/Strava

Also the Strava fork of iD might still be working. See
http://strava.github.io/iD/#background=Bing=17.00/-110.02947/53.27094

Hooray 

Cheers
pangoSE



--
Sent from: http://gis.19327.n8.nabble.com/General-Discussion-f5171242.html

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

Re: [Talk-se] Många nya öppna data från naturvårdsverket

[pangoSE]

Hej Henrik


On 2019-11-11 09:09, Henrik Larsson wrote:
Alla data är inte CC0 men kartdata verkar vara det. 


Se 
http://www.naturvardsverket.se/upload/miljoarbete-i-samhallet/uppdelat-efter-omrade/oppna-data/policy-naturvardsverkets-datainformation-2017-06-08.pdf 
för detaljer. Alla geodata och attributter är CC0 :D



Skulle vara intressant om vi kunde göra något med marktäckesdatan: 
https://www.naturvardsverket.se/Sa-mar-miljon/Kartor/Nationella-Marktackedata-NMD/
 Den ger oss nationell täckning på markanvändningen ner på 10-metersnivå 
uppdelat på 24 naturtyper.


Tyvärr har detta redan försökts. Se tidigare epost till listan. Jag har 
för nån vecka sedan föreslagit att vi stoppar importen tills vidare i 
väntan på bättre data/nån som är villig att städa upp och höja 
kvaliteten på det från NMD som redan importerats.


Mvh
pangoSE


-Ursprungligt meddelande-
Från: pangoSE 
Skickat: den 10 november 2019 14:28
Till: OpenStreetMap Sverige mailinglista 
Ämne: [Talk-se] Många nya öppna data från naturvårdsverket

Hej

All data från naturvårdsverket är CC0

https://oppnadata.se/datamangder/#esc_org=base:635/resource/9de761c624866bdca2f2e6ccdeba9815

Det finns nu följande som jag tycker vi ska börja med (förkortningarna är mina):
* kulturreservat, (NVKR)
* Naturvårdsavtal, (NVNVA)
* satellitbaserad våtmarksövervakning (som kanske kan hjälpa oss få in flera 
våtmarker) (NVVÅ)
* Data för leder och anordningar inom skyddade områden samt statliga leder i 
fjällen finns från och med V17 2018 tillgängliga enligt principen för öppen 
data. (se detaljer:
https://gpt.vic-metria.nu/data/land/Leder%20och%20friluftsanordningar%20beskrivning%20av%20%c3%b6ppna%20data.pdf)
(NVLED)
* Skyddade områden, fågeldirektivet (Natura 2000, SPA) (NVSPA)
* Skyddade områden, interimistiska förbud (i väntan på beslut om
naturreservat) (NVIF)
* Skyddade områden, biosfärsområden (NVBSF)
* Skyddade områden, naturvårdsområden (NVNV)
* Skyddade områden, biotopskyddsområden (NVBSK)
** AnderAndersson har börjat lägga in några av dessa
* Skyddade områden, naturreservat (NVNR) **(se min förre epost, det finns just 
nu 5026 NR i SE[2] som är gällande och vi har[1]:
typ rel way total
boundary=protected_area 50  0329
leisure=nature_reserve  13253546
totalt  137538755250[5])

Det finns nya WMS tjänster som saknas i JOSM. (många av dessa verkar inte 
fungera via besök i min webbläsare och jag saknar kunskap om hur vi kan få in 
detta i JOSM - vet nån annan hur vi kan få detta att funka?)

Vi skulle behöva prata om hur vi bäst gör för att få in all detta i nån 
uppdaterbar ordning och vad som är relevant för OSM.

Min uppfattning är att naturreservaten är den största datamängden, men många av 
våra reservat saknar metadatan från källdatan verkar det som.
(Se
https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/naturvardsverket_import#Boundary
för vilka key/value som vi tillämpar.)

När det gäller import så skulle jag mycket hellre lägga våra krafter på import 
av denna högkvalitetsdata ritad av människor framför den fullautomatiska NMD 
data tex som tyvärr håller låg kvalitet och nog inte är lämpad alls för import.

Jag har beskrivit här[3] hur jag kan lägga in flera på en gång så det behöver 
inte ta så lång tid alls (5 min per 10 reservat som saknas)

Min uppskattning baserad på NVNR datan och vår NR-data är att ungefär
100 reservat saknas och minst lika många är större i NVNR än i OSM.

Om du utfrån att ha läst detta vill sätta igång med NR då rekommenderar jag att 
arbeta per län och ladda ner från overpass i JOSM[4] och filtrera ut samma län 
ur NVNR med QGIS[2].

Lycka till!

mvh
pangoSE

[1] jag gjorde följande för att få fram statistik om alla våra NR:
hämtade sweden-latest.osm.pbf på geofabrik.de $ cat sweden-latest.osm.pbf |osmconvert - 
-o=swe.o5m $ osmfilter swe.o5m --keep="leisure=nature_reserve"
--keep="boundary=protected_area" >swe.nr.osm valfritt extrasteg som ökar 
hastigheten i läsning/skrivning:
konvertera från .osm -> .pbf:
$ osmconvert swe.nr.osm -o=swe.nr.osm.pbf
-> sökning i JOSM
[2] jag filtrerade via QGIS, se tidigare epost. Utav datan i NR finns följande 
protect_class=0,1,4 [3] https://www.openstreetmap.org/user/pangoSE/diary/391178
[4] https://josm.openstreetmap.de/wiki/Help/Action/Download och knappa in detta i wizard: 
boundary=protected_area or leisure=nature_reserve in "västerbottens län"
[5] Dette betyder inte att vi har med alla. Vissa av våra reservat är inte med 
i NVNR och finns kanske i .

___
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] Många nya öppna data från naturvårdsverket

[pangoSE]

Hej

All data från naturvårdsverket är CC0

https://oppnadata.se/datamangder/#esc_org=base:635/resource/9de761c624866bdca2f2e6ccdeba9815

Det finns nu följande som jag tycker vi ska börja med (förkortningarna 
är mina):

* kulturreservat, (NVKR)
* Naturvårdsavtal, (NVNVA)
* satellitbaserad våtmarksövervakning (som kanske kan hjälpa oss få in 
flera våtmarker) (NVVÅ)
* Data för leder och anordningar inom skyddade områden samt statliga 
leder i fjällen finns från och med V17 2018 tillgängliga enligt 
principen för öppen data. (se detaljer: 
https://gpt.vic-metria.nu/data/land/Leder%20och%20friluftsanordningar%20beskrivning%20av%20%c3%b6ppna%20data.pdf) 
(NVLED)

* Skyddade områden, fågeldirektivet (Natura 2000, SPA) (NVSPA)
* Skyddade områden, interimistiska förbud (i väntan på beslut om 
naturreservat) (NVIF)

* Skyddade områden, biosfärsområden (NVBSF)
* Skyddade områden, naturvårdsområden (NVNV)
* Skyddade områden, biotopskyddsområden (NVBSK)
** AnderAndersson har börjat lägga in några av dessa
* Skyddade områden, naturreservat (NVNR)
**(se min förre epost, det finns just nu 5026 NR i SE[2] som är gällande 
och vi har[1]:

typ rel way total
boundary=protected_area 50  0329
leisure=nature_reserve  13253546
totalt  137538755250[5])

Det finns nya WMS tjänster som saknas i JOSM. (många av dessa verkar 
inte fungera via besök i min webbläsare och jag saknar kunskap om hur vi 
kan få in detta i JOSM - vet nån annan hur vi kan få detta att funka?)


Vi skulle behöva prata om hur vi bäst gör för att få in all detta i nån 
uppdaterbar ordning och vad som är relevant för OSM.


Min uppfattning är att naturreservaten är den största datamängden, men 
många av våra reservat saknar metadatan från källdatan verkar det som. 
(Se 
https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/naturvardsverket_import#Boundary 
för vilka key/value som vi tillämpar.)


När det gäller import så skulle jag mycket hellre lägga våra krafter på 
import av denna högkvalitetsdata ritad av människor framför den 
fullautomatiska NMD data tex som tyvärr håller låg kvalitet och nog inte 
är lämpad alls för import.


Jag har beskrivit här[3] hur jag kan lägga in flera på en gång så det 
behöver inte ta så lång tid alls (5 min per 10 reservat som saknas)


Min uppskattning baserad på NVNR datan och vår NR-data är att ungefär 
100 reservat saknas och minst lika många är större i NVNR än i OSM.


Om du utfrån att ha läst detta vill sätta igång med NR då rekommenderar 
jag att arbeta per län och ladda ner från overpass i JOSM[4] och 
filtrera ut samma län ur NVNR med QGIS[2].


Lycka till!

mvh
pangoSE

[1] jag gjorde följande för att få fram statistik om alla våra NR:
hämtade sweden-latest.osm.pbf på geofabrik.de
$ cat sweden-latest.osm.pbf |osmconvert - -o=swe.o5m
$ osmfilter swe.o5m --keep="leisure=nature_reserve" 
--keep="boundary=protected_area" >swe.nr.osm

valfritt extrasteg som ökar hastigheten i läsning/skrivning:
konvertera från .osm -> .pbf:
$ osmconvert swe.nr.osm -o=swe.nr.osm.pbf
-> sökning i JOSM
[2] jag filtrerade via QGIS, se tidigare epost. Utav datan i NR finns 
följande protect_class=0,1,4

[3] https://www.openstreetmap.org/user/pangoSE/diary/391178
[4] https://josm.openstreetmap.de/wiki/Help/Action/Download och knappa 
in detta i wizard: boundary=protected_area or leisure=nature_reserve in 
"västerbottens län"
[5] Dette betyder inte att vi har med alla. Vissa av våra reservat är 
inte med i NVNR och finns kanske i .


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

[Talk-dk] Fejl på protected_area i DK

[pangoSE]

Hej

CartoOSM støtter bare boundary=protected_area hvor der også findes en 
protect_class=


Disse elementer savner denne klassificering og synes derfor ikke:
https://overpass-turbo.eu/s/NYp

mvh
pangoSE

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

[Talk-se] Finns interesse för att börja en Svensk lokalförening?

[pangoSE]

Hej

Jag skulle vilja stärka vår sammanhållning och ha möjlighet att träffa 
nån av er andra som håller på i Sverige. Därutöver skulle jag vilja ha 
möjlighet att skicka nån till Advisory Board och att vi tillsammans tar 
ställning för sånt som är viktigt för oss som ideella deltagare i projektet.


Trots att jag varit aktiv i snart 10 år har jag bara träffat en annan 
lokalt (Blajo).


Finns det interesse att få igång en förening?
Hur många är vi egentligen här på listan?

Se https://welcome.openstreetmap.org/about-osm-community/local-chapters/

Mvh
pangoSE

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

Re: [Talk-se] Hjälp med naturreservaten

[pangoSE]

För den intresserade skrev jag just en guide till konvertering av 
shapefiler för att förbättra upplevelse i JOSM


https://wiki.openstreetmap.org/wiki/QGIS#Using_QGIS_to_filter_data_from_government_sources_and_convert_it_to_KML

Jag har börjat filtrera på "Gällande" eftersom det inte ger så mycket 
mening att lägga in dem som inte är i effekt.



On 2019-11-09 15:53, pangoSE wrote:

Hej

Jag började jobba igen med naturreservaten i dag efter ett års paus.

Status är som följer:
- OSM ligger efter: Det har tillkommit många nya.
- OSM är fel: vissa NR är fel geometri i OSM jämfört med den öppna data
- 286 av våra boundary=protected_area saknar protect_class=* och syns 
därför inte på osm.org, se https://overpass-turbo.eu/s/NXn


Se 
https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/naturvardsverket_import#Naturreservat 



Välkommen att bidra till att få ordning på reservaten.

Mvh
pangoSE
ps se även https://www.openstreetmap.org/user/pangoSE/diary/391178 där 
jag beskriver hur jag sammanfogar mellan NR-lagret och osm-lagret.


___
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] Hjälp med naturreservaten

[pangoSE]

Hej Christian

On 2019-11-09 16:28, Christian Asker wrote:

Hej. Bra uppmärksammat!

Naturreservaten finns ju som öppna data i shapeformat hos 
Naturvårdsverket. Jag har för mig att den shapefilen släpar efter 
verkligheten lite dessutom. Sen vill man ju helst få med stigar, 
fikabord, informationsskyltar också, men det kräver ju ett fysiskt besök.


Jag försöker hålla naturreservaten uppdaterade i "mitt kvarter".


Toppen



En relaterad grej är områden som är "biotopskydd". Dessa kan karteras i 
OSM också.


Vilka taggar använder du till dem?

/pangoSE


Den 2019-11-09 kl. 15:53, skrev pangoSE:

Hej

Jag började jobba igen med naturreservaten i dag efter ett års paus.

Status är som följer:
- OSM ligger efter: Det har tillkommit många nya.
- OSM är fel: vissa NR är fel geometri i OSM jämfört med den öppna data
- 286 av våra boundary=protected_area saknar protect_class=* och syns 
därför inte på osm.org, se https://overpass-turbo.eu/s/NXn


Se 
https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/naturvardsverket_import#Naturreservat 



Välkommen att bidra till att få ordning på reservaten.

Mvh
pangoSE
ps se även https://www.openstreetmap.org/user/pangoSE/diary/391178 där 
jag beskriver hur jag sammanfogar mellan NR-lagret och osm-lagret.


___
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] Hjälp med naturreservaten

[pangoSE]

Hej

Jag började jobba igen med naturreservaten i dag efter ett års paus.

Status är som följer:
- OSM ligger efter: Det har tillkommit många nya.
- OSM är fel: vissa NR är fel geometri i OSM jämfört med den öppna data
- 286 av våra boundary=protected_area saknar protect_class=* och syns 
därför inte på osm.org, se https://overpass-turbo.eu/s/NXn


Se 
https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/naturvardsverket_import#Naturreservat


Välkommen att bidra till att få ordning på reservaten.

Mvh
pangoSE
ps se även https://www.openstreetmap.org/user/pangoSE/diary/391178 där 
jag beskriver hur jag sammanfogar mellan NR-lagret och osm-lagret.


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

[Talk-se] SCBs öppna geodata är CC-BY :(

[pangoSE]

Hej

Jag skulle vilja rita in polygonen för Sundsvall men den är CC-BY.

Hur gör vi?

Är det nån här som jobbar på SCB eller som är van att förklara för 
myndighetspersoner varför CC-BY inte funkar för oss? Alternativt är det 
nån som har en brevmall liggande jag kan skicka ifall ingen annan vill 
dra i detta?


https://www.scb.se/vara-tjanster/oppna-data/

Mvh

pangoSE



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

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

[pangoSE]

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 områden.

Nån emot?

Mvh

pangoSE


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