date:20200809

> L'occasion d'améliorer quelques name:fr !

Les postes de transformation électrique : leur libellé est affiché 2 fois en 
zoom 19 et 20.
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.58154/5.74565
 

https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.57432/5.75581
 

https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.57469/5.75619
 


Il n'a pas de logo au moins en 20, ce qui aiderait à savoir ce que c'est ;)

Afficher le nom (et un logo ?) des postes de transformation électrique sur 
poteaux (power=pole et pas power=substation)
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.59908/5.62577
 

https://www.openstreetmap.org/node/6322890596 



Ici, un accueil de loisir avec un libellé en double en zoom 20 :
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.57512/5.75540
 


Idem pour la déchèterie :
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.58608/5.73638
 



Les DAEs ne sont pas affichés : Seulement en septembre pour le projet du mois ? 
:D
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.57439/5.75571
 

https://www.openstreetmap.org/node/6323423304 

https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.59250/5.73438
 

https://www.openstreetmap.org/node/6287232229 


Zone de rencontre : rendu "bizarre" (arrondi en bout de way) et pas très 
parlant.
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.59250/5.73407
 

https://www.openstreetmap.org/way/580345876 


Libellé violet "Boissia" qui tombe du ciel en zoom 19 et 20 :
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.59265/5.73319
 


Est-ce le landuse=residential ?
https://www.openstreetmap.org/way/187972711#map=17/46.59229/5.73382 



Les conteneurs des PAVs (points d'apport volontaire) sont regroupés en zoom ≤ 
18 :)
Eventuellement rajouter un logo journaux, verre, détritus… en zoom 20 (mais pas 
évident car les données ne sont pas homogènes en France ?)
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.58183/5.74556
 

Ici il y en fait 3 conteneurs (1 x verre, 2 x vêtements)

Libellés des limites communales : je les mettrais de la même couleur que le 
trait de limite
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.58825/5.69348
 



Panneaux de randonnée (PDIPR) le rendu OSM est plus parlant (libellé, altitude 
et logo guidepost)
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.65332/5.68375
 

https://www.openstreetmap.org/node/6336132998#map=19/46.65338/5.68380 


Monuments aux mort : mettre un logo spécifique ?
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.65515/5.67978
 

https://www.openstreetmap.org/node/6066480460 


Boite à livre par rendue
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.66565/5.64801
 

https://www.openstreetmap.org/node/4999163702 


Il n'y a que le nom ici :
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.65498/5.59869

[Talk-dk] Ja rekordforsøget lykkes i går 9/8

2020-08-09 Thread Soren Johannessen

Hej alle sammen

Hele 85 forskellige deltagere  var inde og redigere i Danmarks området i
går og dermed blev en gammel rekord fra 2012 på 44 personer i den grad
slået. Det er for vildt at  så mange trodsede varmen i går og var med at få
rekorden i hus. Tak alle sammen.

[image: rekordhjemme.JPG]
Kilde OsmStats http://osmstats.neis-one.org/?item=countries=Denmark


Og mere godt nyt vi slog også vores nabolande Finland (84), Sverige (71) og
Norge (55).

Der skal også rettes en kæmpestor tak til Septima, OpenDenmark og mit firma
for at have været sponsor for 50 kr til en  is eller andet køligt i går
under den troppehede vi var udsat for.

Bedste hilsner
Søren Johannessen
___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

[OSM-talk] Twitch MapRoulette session Tuesday

2020-08-09 Thread Martijn van Exel

Hi all,

I've been doing some informal Twitch streaming sessions just doing some JOSM 
mapping, and it was quite fun. I will do another one this Tuesday specifically 
about creating a MapRoulette Challenge. I will be starting at 19:00 US Mountain 
Time[1].

If you have an idea for a MapRoulette Challenge that you'd like me to cover, 
let me know and I'll do my best.

My Twitch channel is here: https://www.twitch.tv/mvexel 

Hope to see some of you then;

[1] 
https://www.timeanddate.com/countdown/generic?iso=20200811T19=220=Twitch+%23OpenStreetMap+MapRoulette+Session=cursive
 

-- 
  Martijn van Exel
  m...@rtijn.org

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

[Talk-us] Twitch MapRoulette session Tuesday

2020-08-09 Thread Martijn van Exel

Hi all,

I've been doing some informal Twitch streaming sessions just doing some JOSM 
mapping, and it was quite fun. I will do another one this Tuesday specifically 
about creating a MapRoulette Challenge. I will be starting at 19:00 US Mountain 
Time[1].

If you have an idea for a MapRoulette Challenge that you'd like me to cover, 
let me know and I'll do my best.

My Twitch channel is here: https://www.twitch.tv/mvexel 

Hope to see some of you then;

[1] 
https://www.timeanddate.com/countdown/generic?iso=20200811T19=220=Twitch+%23OpenStreetMap+MapRoulette+Session=cursive
 

-- 
  Martijn van Exel
  m...@rtijn.org

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

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

2020-08-09 Thread Clifford Snow

As I read your proposal, it sounds like you have a solution but haven't
defined the problem. If you could focus on the problem and describe exactly
what is wrong with the current arrangement, and what will happen if we do
nothing, that might help. Otherwise I can not see the merits of your
proposal. From what I've read for the feedback you've received, you haven't
convinced anyone that there is a problem.

Best,
Clifford


-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

2020-08-09 Thread stevea

On Aug 9, 2020, at 5:29 AM, pangoSE  wrote:
> The discussion below spawned the following idea of migrating the whole tags 
> system instead.
(an over engineered proposal largely, as Frederick says and I agree with, 
goosed by the "hype of linked data.")

I politely vote "No."  I don't see the merit (again echoing Frederick).  While 
I'm only one person and one vote and perhaps a bit more vocal than most, I feel 
it important to express the opinion of "very strongly against."

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

Re: [Talk-at] Regionen mappen

2020-08-09 Thread Kevin Kofler

Florian Kratochwil wrote:
> * In Wien gibts das nicht

Also prinzipiell gibt es in Wien schon Gruppen von Bezirken, die in 
verschiedenen Kontexten Sinn machen, z.B.:
* die 18 Wahlkreise der Gemeinderatswahl (von denen aber 16 nur aus jeweils
  einem Bezirk bestehen, die restlichen 7 Bezirke sind zu 2 Wahlkreisen
  zusammengefaßt (1,4-6 sowie 7-9)),
* Cisdanubien (1-20,23) vs. Transdanubien (21-22),
* Innenbezirke (1-9,20) vs. Außenbezirke (10-19,21-23)
usw. Aber wir verwenden halt in verschiedenen Kontexten verschiedene 
Unterteilungen, daher ist es wohl wenig sinnvoll, eine davon als 
admin_level=5 zu mappen, da gebe ich dir schon recht.

Kevin Kofler


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

Re: [Talk-us] Potential Import of Addresses for Thurston County, WA, USA

2020-08-09 Thread Mark Wagner

On Sun, 09 Aug 2020 03:53:55 -0700
Raven King  wrote:

> Hello:
> 
> I discovered that Thurston County, WA publishes a database of
> addresses stored as gps pins inside a shape file. 
> The data can be found here:
> https://gisdata-thurston.opendata.arcgis.com/datasets/thurston-address-points-tcomm?geometry=-122.915%2C47.023%2C-122.914%2C47.023
> 
> The license can be seen where it has a link labeled "Custom License"
> next to a picture of a lock. I didn't see anything in there that would
> prohibit our use of this, but extra eyes are needed. 

The most interesting clauses in the license is:

"Users are not authorized to license, re-license, assign, release
publish, transfer, sell or otherwise make available any portion of
these Data, or any information from GIS data derived from these
Datasets, to a third party in any format revealing Thurston County as
the source of the data."

This solves the attribution issue quite nicely: we're *forbidden* to
credit this data to Thurston County. 

> The database has 128,639 addresses. My goal would be to import the
> entirety of it into OSM, as Thurston county has very few addresses in
> OSM. They would be imported as points, since the database has them
> stored as points.
> 
> The caveats I see are as follows:
> * The database probably has some addresses that are wrong. While
> everything I could verify has been correct, I only checked about 100
> addresses. 

A quick look at the data in JOSM doesn't reveal any large-scale
problems.  Some observations: 

* Almost every point corresponds to a building or some other object
  (eg. a parking lot) that would reasonably be expected to have an
  address.  There are a few oddities, such as a wetland.

* There are a few multi-story apartment buildings where the address
  points don't correspond to the actual locations of the units.

* I think you'll want to build street names off the "StreetName",
  "St_PreMod", "St_PreDir", "St_PreType", "St_PosDir", and "St_PosType"
  fields rather than any of the other fields.

* There are seven duplicate addresses in the data.

-- 
Mark

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

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

2020-08-09 Thread Andy Mabbett

On Sun, 9 Aug 2020 at 19:05, Imre Samu  wrote:

> Wikidata is a graph database .. and there is a "known" scalability problem
> https://lists.wikimedia.org/pipermail/wikidata/2019-June/013124.html

That post discusses the SPARQL front end (the "Wikidata Query
Service") specifically, and not Wikidata (a Wikibase instance)
itself.

--
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk-fr] Chantiers d'été pour OSM-FR ;)

2020-08-09 Thread Christian Quest


Le 05/08/2020 à 19:42, Jérôme Amagat a écrit :


Les mers, baies et détroits (place=sea, natural=bay, natural=strait) 
en surfacique pourraient avoir leur nom qui apparaissent pour les 
mer et détroit et plus tôt lorsqu'ils sont très grands pour les 
baies qui sont déjà rendu.
exemple : le golfe du lion 
https://www.openstreetmap.org/relation/9287303 
http://tile.openstreetmap.fr/?zoom=11=42.99137=4.17341=B






Voilà les océans, mers, baies, détroits maintenant visibles sur le rendu 
FR :)


L'occasion de découvrir le tag sqkm=* qui indique sur un objet ponctuel 
sa superficie approximative en km².


Ceci permet de prioriser ces objets et c'est bien pratique !

Tag documenté sur le wiki en 2016.


Vous pouvez voir ce que ça donne (avec les améliorations précédentes) sur:

https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#2/0/0

C'est un accès direct au rendu en cours de dev (chez moi, pas dispo H24 
et recalculs non continus).



L'occasion d'améliorer quelques name:fr !

--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk] Cyclofix project

2020-08-09 Thread Morten Lange via talk

Hi,
Congratulations on a nice project and a useful one !
For a long time I have wished for a user-friendly bicycle repair specific map, 
including bicycle cafés.

You were soliciting constructive feedback, so here is mine:  What I miss in the 
Cyclofix project is an easy-to find definition of how you classify the nodes 
that are to be included in the different map "layers".  Which search is it that 
produces the bicycle cafés. (And what takes precedence if two or more criteria 
are fulfilled?)
Do you make a distinction between "pure" bicycle shops  and general sport shops 
that offer bicycles or  repair of bicycles? 
If you do, the way Cyclofix has decided to differentiate is not self-evident to 
me, after briefly checking your documentation. I must admit that I did not 
really consider looking at the source-code  ;-) 
The same goes for bicycle cafés (And public bookcases). In true collaborative 
fashion and in the spirit of open data, nodes that are to apear on your map 
should be editable (and addable) also in other tools with predictable results.

I enjoyed testing your solution, and I would have liked to announce it to 
others.  
But I suppose continued operation of the current site is uncertain?
That fact(?) holds me back a bit.   
Ideally The European Cyclists Federation or even UNEP or some other big 
organisation would offer to support operations for large traffic loads and 
continued development for, say, a 10 year period  :-)  

P.S.Digging for some minutes into the code I found this, which does give me 
clues for how you search for and create bicycle cafés (or pubs really):    
https://github.com/pietervdvn/MapComplete/blob/master/Customizations/Layers/BikeCafes.ts



-- Regards / Kveðja / Kila la heri / Hilsen Morten Lange 

 On Wednesday, 29 July 2020, 19:43:38 CEST, Pieter Fiers 
 wrote:  
 
  Dear OSM community, 
  My name is Pierre Barban. A team composed of three very motivated students, 
including myself, and lead by two active members of the OSMbe, have been 
mandated by the region of Brussels, Belgium, to create a map gathering all kind 
of data related to cycling. Without a doubt, OpenStreetMap was the perfect tool 
for us to create a powerful platform that would sustain over the years.  
  In the framework of month-long online code camp organized by the non-profit 
Open Knowledge Belgium, we have been able to establish the first version of the 
tool, organized a mapathon to collect data, and create a complete website to 
document the entire making process.  
  In accordance with the OSM core values, it would be very valuable for our 
project as well as our individual learning process to receive as many 
constructive comments from the community as possible. If you're interested in 
more details about the project, we will be giving an online presentation 
tomorrow July 30, 2020 at 1pm CEST. We will be available to directly discuss 
after the presentation to receive feedback in order to keep improving our 
project. Other related project from our program, Open Summer of Code, like the 
Bike Data Project - which aims to collect and share cyclist commute data in an 
opened way - will also be presented to you.  
  Please do not hesitate to contact me for further information, 
  thank you for your time and help. 
  Sincerely, 
  Pierre Barban, from the Cyclofix project.
 
 Sent by Pieter Fiers , another student of the team.
  
Pierre Barban 
 University Panthéon-Sorbonne Paris I – Class of 2020
 Masters in Economics of Sustainable Development
 pierre.bar...@gmail.com | +33 7 68 72 92 54
 
   ___
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] Fwd: Re: Roadmap for deprecation of name tags in OSM



sent from a phone

> On 9. Aug 2020, at 21:16, john whelan  wrote:
> 
> And different features really are called difference things in different 
> countries.


+1, moreover, the „same“ features are different in different countries and 
cultures, and it is part of our work to define when we consider them still the 
same and where they start to be so different that another tag is required.

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

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

sent from a phone

> On 9. Aug 2020, at 21:04, pangoSE  wrote:
> 
> 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"

somehow you can have this already through the integration of wikidata: just add 
a wikidata reference to an object and you could decide to ignore all 
OpenStreetMap tags and rely only on wikidata (although it would not be 
advisable IMHO, looking at where wikidata is currently, you would loose lots of 
relevant information).

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

Re: [talk-cz] Rozcestníky - Fotky z terénu

2020-08-09 Thread vop

Na desktopu to funguje bezchybně, mobilní verze občas zazlobí (tak na to
hned nezanevři, když to nebude dělat, co má) - momentálně zcela bez problémů
via Chrome na Androidu 9.

Může tě pozlobit přihlášení do Fody, které se možná nebude chtít otvírat ve
stejném okně či prohlížeči - v takovém případě si přihlašovací odkaz
zkopíruj (podrž prst déle a pak z kontextové nabídky vyber "Zkopírovat
adresu odkazu") a vlož ji do adresního řádku stejného panelu manuálně.

Celé vkládání je pak velmi easy a rychlá věc - z úložiště, nebo rovnou
foťákem na místě.

VOP


-- Původní zpráva --
Od: Miroslav Suchy
Datum: 9. 8. 2020 v 16:39:15
Předmět: Re: [talk-cz] Rozcestníky - Fotky z terénu

Dne 09. 08. 20 v 14:08 Petr Schönmann napsal(a):
> Otázka je teda, máme nějakou takovou aplikaci ? Web rozhraní které by mi
dovolilo nahrát fotku rovnou k rozcestníku skrz
> optimalizované rozhraní pro mobilní zařízení ?
>

https://openstreetmap.cz/ -> vrstvy (více vrstev ve skupinách - taková ta
ikona tabulky v pravém sloupci) -> Fotky Fody
-> pak se vpravo nahoře objeví ikona rozcestníku a po přihlášení je možné
nahrát fotku.
V terénu to normálně na smartfounu používám.

Mirek

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-us] Anyone familiar with Rocky Mountain National Park (RMNP)?

2020-08-09 Thread Mike Thompson

Mateusz, Kevin, Thanks for the advice.  I will probably reach out to the
original mapper again, and if no source is provided, delete the names.

Mike

On Sun, Aug 9, 2020 at 11:27 AM Kevin Kenny  wrote:

> The 'names' look like someone's field notes: 'Tarn A', 'Tarn B', 'Tarn C',
> 'Tarn Off the Map', 'Tarn Off the Trail', rather than something that the
> locals would call them.
>
> Of course, people's field notes leak into imported data sources all the
> time.
>
> For the sake of not firing the first shot in an edit war, since the mapper
> is responsive, ask if there's any objection to removing the questionable
> names?
>
> On Sat, Aug 8, 2020 at 3:15 PM Mike Thompson  wrote:
>
>> I thought the names of these water bodies[0] in RMNP were suspect because:
>> 1) The names do not appear in the GNIS,
>> 2) The names do not appear on the USGS topo
>> 3) The names do not appear in the NHD
>> 4) The names do not appear on the RMNP map that is handed out to visitors
>> 5) I have hiked past here several times but have never seen signs naming
>> these bodies of water.
>> 6) I asked the mapper that added the names what their source was, and
>> they said they didn't remember.
>> 7) I have several hiking books covering RMNP and none mention these water
>> bodies using these names.
>>
>> Mike
>>
>> [0]
>> https://www.openstreetmap.org/way/429681825
>> https://www.openstreetmap.org/way/429451427
>> https://www.openstreetmap.org/way/429681824
>> https://www.openstreetmap.org/way/429681823
>> https://www.openstreetmap.org/way/429451428
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>
>
> --
> 73 de ke9tv/2, Kevin
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

"riding the current ride in open data" - I am confused what is the meaning of 
that

"scripting support for botmakers" - as a bot operator and a bot author I am 
confused what is
supposed to be missing

"support for references and linking interactively to other data sources" - we 
have that,
see wikidata tag for example

"talk pages if we want that for every osmid" - changeset comments and notes
seem sufficient

"SPARQL support" - we have already some wikidata/OSM query engine and overpass 
turbo
And frankly Overpass is much nicer that SPARQL (this may be just me).

"Bots are very useful" - maybe, but it is 100% possible to have bots already so 
I am 
confused why it is mentioned

"possibility we don't have today regarding integration with e.g. wikidata." - 
given
what kind of ideas appear thanks to current wikidata integration (like 
deprecating name tag)
I prefer reducing wikidata integration rather than deepening it (or, the best 
solution - keep it as is)

Aug 9, 2020, 21:01 by pang...@riseup.net:

> 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

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

2020-08-09 Thread john whelan

I honestly can't see any benefit.  Splitting the data into two places adds
the danger of it getting out of sync.

Standard naming conventions would be nice but defining the standard name is
practically impossible.  Compare taginfo to the map features wiki page.
One problem with map features is what is written is often one person's idea
of what the standard name should be.

And different features really are called difference things in different
countries.  It can be difficult to stretch a "standard" name to cover many
things.

For example in Canada many highways have wide shoulders to dump snow on in
winter.  In summer they are often used by cyclists but they aren't cycle
lanes by any stretch of imagination even though some are paved.

Cheerio John

On Sun, Aug 9, 2020, 15:04 pangoSE  wrote:

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

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

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

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

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




 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

2020-08-09 Thread Imre Samu

some info for the planning :

>  Wikidata names. I'm guessing thats because they are simply better
quality,

most of  the labels /names generated/transliterated  by bots ..
or imported from other databases ( GeoNames !! )

> better modeled, better referenced

Wikidata:  The Cathedral style ... top-bottom
OpenStreetMap:  Bazaar style data model:  ... bottom-up

in the OSM .. There are a lot of name tags :
https://taginfo.openstreetmap.org/search?q=name
and it is not easy  to map everything to the wikidata model.

Wikidata is a graph database .. and there is a "known" scalability problem
https://lists.wikimedia.org/pipermail/wikidata/2019-June/013124.html

*"Scaling graph databases is a "known hard problem", and we are reaching*
*a scale where there are no obvious easy solutions to address all the*
*above constraints. At this point, just "throwing hardware at the*
*problem" is not an option anymore."*



can't protect against bad import ..  no strict  community rules ...
for example -  the cebwiki  re-imported the full GeoNames database ...
https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2018/06#A_proposed_course_of_action_for_dealing_with_cebwiki/svwiki_geographic_duplicates
https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2018/07#Another_cebwiki_flood%3F
https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2017/10#Cebuano

> and better protected against vandalism.

anyone can modify the wikidata - without registration.
in the wikidata JSON dump - no user info .. so it is hard to detect the
modifications type ( from logged or unlogged users )


Best,
 Imre

pangoSE  ezt írta (időpont: 2020. aug. 9., V, 10:29):

> 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-us] Anyone familiar with Rocky Mountain National Park (RMNP)?

2020-08-09 Thread Kevin Kenny

The 'names' look like someone's field notes: 'Tarn A', 'Tarn B', 'Tarn C',
'Tarn Off the Map', 'Tarn Off the Trail', rather than something that the
locals would call them.

Of course, people's field notes leak into imported data sources all the
time.

For the sake of not firing the first shot in an edit war, since the mapper
is responsive, ask if there's any objection to removing the questionable
names?

On Sat, Aug 8, 2020 at 3:15 PM Mike Thompson  wrote:

> I thought the names of these water bodies[0] in RMNP were suspect because:
> 1) The names do not appear in the GNIS,
> 2) The names do not appear on the USGS topo
> 3) The names do not appear in the NHD
> 4) The names do not appear on the RMNP map that is handed out to visitors
> 5) I have hiked past here several times but have never seen signs naming
> these bodies of water.
> 6) I asked the mapper that added the names what their source was, and they
> said they didn't remember.
> 7) I have several hiking books covering RMNP and none mention these water
> bodies using these names.
>
> Mike
>
> [0]
> https://www.openstreetmap.org/way/429681825
> https://www.openstreetmap.org/way/429451427
> https://www.openstreetmap.org/way/429681824
> https://www.openstreetmap.org/way/429681823
> https://www.openstreetmap.org/way/429451428
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


-- 
73 de ke9tv/2, Kevin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Défibrillateur et tag name=*

> Comment as-tu pu positionner le DAE depuis une orthophoto ? ;-)
> 
Je suis rentré dans le collège comme un voleur ;)

> J'ai corrigé les horaires d'ouvertures : SH pour School Holidays.
> 
> 
Merci, mais pour le moment ce n'est pas gérer dans le code (En France on a des 
zones à la con).

> OSM est une base de données géographiques. Si là il y a un collège c'est 
> l'infirmerie du collège.
> 
Oui :)

J'ai tenté d'expliquer que ces données ne sont pas forcément utilisées par une 
appli d'un smartphone disposant d'un GPS (qui capte - au sens propre).
Elles peuvent servir à faire une simple liste papier ;)

> N. B. : ça fait aussi que les horaires d'ouvertures sont relatifs : s'il y 
> aune sonnette, je suppose que tu essayeras même en dehors des horaires 
> d'ouvertures de récupérer le DAE.
> 
> Pour revenir au access=, vous parlez de l'accès au collège, c'est à mon avis 
> hors sujet. Si lors d'une journée porte ouverte un parent fait un arrêt 
> cardiaque vous n'allez pas le traîner en dehors du collège pour vous ramener 
> au cas précédent !
> 
C'est bien sûr l'accès au DAE (ou ses horaires d'accès).
Comme il est dans l'enceinte du bâtiment, on recopie les horaires d'ouverture 
du collège.

J'ai regardé le tag access des DAE ayant une ref:FR:geoDAE :
yes 113
permissive  5
private 2

Pour les 2 privés, 1 est dans l'école primaire 
, l'autre dans une salle du 
COSEC  (complexe omnisports 
évolutif couvert)
Je mettrais plutôt ça en permissif ;)

Pour les permissifs, il y en a 2 dans la même entreprise, 1 dans un ciné, 1 
dans un cinéma et le dernier à la mairie.
Il me semble que l'accès private soit être exceptionnel en France (dans quel 
cas ?)

> Par contre dans des piscines par exemple j'ai vu des DAE accessibles 
> uniquement au personnel : donc il faut trouver du personnel et non le DAE. 
> Dans ce cas access= permet de le savoir (et si besoin de guider le personnel).
> 
Plutôt une note ? Et encore, ces établissement on un accueil ;)
> SaveLife ? Une application spécialisée qui fera du rendu intérieur quand le 
> DAE est décrit comme étant à l'intérieur ?
> 
Oups, SAUV life  :

Une organisation de médecin urgentistes qui collabore avec de nombreux SAMU 
 pour envoyer sur place des 
volontaires munis de l'application.
(Et bien avant que les pompiers aient démarré leur VSAV - du moins à la 
cambrousse)

__
Yves

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

Re: [OSM-talk-fr] Photos > archiver les image=* ?

> J'avais commencé un fichier MapCSS pour faire de la validation dans JOSM sur 
> les images, ça peut être complété pour être plus exhaustif : 
> https://josm.openstreetmap.de/wiki/Rules/Pictures 
> 
Super mais il y a plusieurs problèmes :
de mémoire il faut explicitement charger cette règle
JOSM n'est pas le seul "éditeur" de données
on réinvente la roue (les contraintes sont déjà décrites dans wikidata).

Je pense qu'il faut pousser l'utilisation des dataitems (nos wikidatas) pour 
décrire une fois pour toutes les règles de validation des données (pour tous 
les logiciels).
Et/ou intégrer ça directement dans l'API, comme ça même si l'éditeur ne fait 
pas son boulot, le nettoyage est fait de toute façon.

> Si pour les DAE on veut deux images distinctes à but distinct (vue large
> et vue proche), faut-il un ou deux tags ?
> 
> Jean-Louis nous avait fait un mapillary:wide.
> 
> Donc image, mapillary, ... : vue proche. En général quand on a une photo
> d'un objet on a la photo... de l'objet, pas de son environnement.
> 
> Donc image:wide, mapillary:wide, ... : vue large (surroundings est
> peut-être moins ambigu : wide pourrait signifier le format de photo
> landscape/paysage).
> 
> Et non Yves je ne suis pas pour mettre des ; : ces photos doivent être
> "uniques". Si entre deux photos pour le même but tu ne sais laquelle
> choisir c'est sans doute qu'aucune n'est assez bonne.

Le problème est que — peut-être— le modèle de données OSM est à bout de souffle 
?

mapillary:wide=*
image_2=*
image_3=*
Et pourquoi pas mapillary_wide_portrait=* ? :D

Comment un logiciel (et même un humain) va savoir quoi faire de ces variantes 
de tag ?

Dans wikidata, c'est "simple" :)

La propriété image décrit… une image :)
Si tu veux préciser que c'est un plan serré, large… il suffit de rajouter un 
qualificatif.

Dans tous les cas une requête qui affiche les images par exemple des mégalithes 
fonctionnera sans rien changer.

Quelqu'un crée une sous-classe de mégalithe, ça marche aussi :
https://w.wiki/ZA5 

Un élément peut avoir 0 ou plusieurs images, des photos de nuits, des logos… 
qui sont tous des images.

On peut avoir une image en version française, allemande… (pour un logo, une 
copie d'écran…)
En pratique, c'est une image avec le qualificatif "langue de l'œuvre, du nom ou 
du terme" en français.

> Comme Christian j'ai des doutes sur la tolérance à long terme de Wiki
> d'héberger les photos des bornes incendie, des DAE (demain des boîtes
> aux lettres histoire de vérifier les horaires de levée ? Des bouées de
> sauvetage en vue large pour la même raison ?).
ça fait un moment qu'il y a des photos de fontaines, bornes fontaines, 
hélicoptères, lavoirs…
En fait ça provient des listes de wikipedia.

J'ai relu Commons:Objectifs du projet 
 et Commons:Ce que 
Commons n'est pas 
.
Le caractère éducatif des listes de DAE est limite, mais pas exclu.

Mettre aussi des tonnes de DAE et autre objets de la vie réelle peut permettre 
à des chercheurs de travailler dans les domaines de l'IA, de la sociologie, 
l'histoire…

Un échange entre la fondation OSM et la fondation Wikimedia peut clarifier ces 
usages une fois pour toute ?

__
Yves

On peut aussi faire tourner notre propre instance (serveur) de Commons mais on 
perd le "Commun" ;)___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Défibrillateur et tag name=*

2020-08-09 Thread osm . sanspourriel


Le 09/08/2020 à 08:46, Yves P. - yves.prat...@gmail.com a écrit :

Un exemple réel : "À gauche au fond du couloir, devant l'infirmerie"
https://www.openstreetmap.org/node/6323423304


Faire de l'indoor mapping à partir d'une photo aérienne n'est pas
facile ;)
Peu d'applications font un rendu intérieur.

Avoir un POI d'infirmerie sur OSM ne va pas indiquer comment y aller
(rapidement).


De deux choses l'une : soit la personne est dans l'établissement et
collégiens comme professeurs et autres savent où est l'infirmerie. Soit
elle est à l'extérieur. Et là voir ci-dessous.

Comment as-tu pu positionner le DAE depuis une orthophoto ? ;-)

J'ai corrigé les horaires d'ouvertures : SH pour School Holidays.

Mo-Fr 07:30-18:00; Sa 07:30-12:00; PH off; SH off



Pourquoi pas "Infirmerie" ?


De quoi, de l'entreprise de BTP ou de la maison de retraite du coin ?


OSM est une base de données géographiques. Si là il y a un collège c'est
l'infirmerie du collège. Quand tu ajoutes en cartographie intérieure du
collège un POI infirmerie, tu ajoutes en name "infirmerie du collège des
Lacs, 2B rue du Village Neuf, Clairvaux-les-Lacs
, France" ?


Si il est à la machine à café, je met quoi ;D


Cafétéria, Espace pause... par exemple. Et si les gens disent qu'ils se
retrouvent à la "machine à café", "machine à café".

Et si l'entreprise a fléché ça "espace de restauration légère interdit
pour la pause méridienne", tu mets "espace de restauration légère
interdit pour la pause méridienne" : tu mets ce qui permet de trouver
rapidement. Si c'est une description à la con qui est fléchée, tu mes ce
nom à la con. Sinon tu mets ce qui permettra aux gens du voisinage de te
guider. J'appelle ça du bon sens.


Je connais pas ce collège, mais à ma connaissance en général ils ne
laissent pas rentrer le public, donc le DAE n'est pas vraiment
accessible au public


En cas d'arrêt cardiaque chez le voisin, faut-il donner sa carte de
sécu, sa carte bancaire, sa carte de collégien… pour prendre le DAE ?


/En France ou aux États-Unis ? Là, carte bancaire et pièce d'identité et
en plus tu dois demander à l'ambulance de conduire la personne à
l'hôpital :-(. Hélas je suis sérieux, c'est du vécu, heureusement
seulement comme témoin-traducteur et pour une perte de connaissance.
Mais le problème c'était d'expliquer au conjoint de la victime pourquoi
l'ambulancier voulait savoir que faire de la personne - en Europe on
fait confiance au personnel pour faire au mieux - et pourquoi il avait
confisqué leurs pièces d'identité - carrément un vol pour un Allemand.
Et oui en Allemagne comme en France nécessité fait loi. Et le personnel
d'Air France devait aussi rassurer pour la gestion des bagages ! Là,
version française/européenne : "ça on sait faire, l'ordre de débarquer
vos bagages a déjà été donné et on les met en consigne mais pour le
moment l'important c'est votre mari". Ce n'était pas une demande de
carte bancaire pour facturer les frais de débarquement, de consigne et
de retard de l'avion. Ça s'appelle du savoir-vivre./

Ceci dit effectivement entrer dans l'enceinte de l'établissement pourra
entrainer même en France une certaine négociation.

N. B. : ça fait aussi que les horaires d'ouvertures sont relatifs : s'il
y aune sonnette, je suppose que tu essayeras même en dehors des horaires
d'ouvertures de récupérer le DAE.

Pour revenir au access=, vous parlez de l'accès au collège, c'est à mon
avis hors sujet. Si lors d'une journée porte ouverte un parent fait un
arrêt cardiaque vous n'allez pas le traîner en dehors du collège pour
vous ramener au cas précédent !

Par contre dans des piscines par exemple j'ai vu des DAE accessibles
uniquement au personnel : donc il faut trouver du personnel et non le
DAE. Dans ce cas access= permet de le savoir (et si besoin de guider le
personnel).


Ce qui serait bien c'est que SaveLife appel l'accueil du collège pour
demander de préparer le DAE car quelqu'un arrive en courant pour une
URGENCE VITALE :)


Dans ce cas il faut cartographier les personnes ayant un arrêt cardiaque
pas les DAE (humour).

J'ai tagué un DAE dans une entreprise où personne ne rentre sans laisser
son identité. Sans access=. J'espère que les gens témoins d'un accident
cardiaque à côté sauront sonner et qu'à l'accueil ils sauront soit faire
une exception soit demander à un secouriste de l'entreprise d'intervenir.

Marqué indoor et sans horaires : si l'accueil est fermé et s'il reste
quelqu'un à portée de voix, ça doit suffire.

SaveLife ? Une application spécialisée qui fera du rendu intérieur quand
le DAE est décrit comme étant à l'intérieur ?

Jean-Yvon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-dk] SDFE grunddata på Datafordeleren

2020-08-09 Thread osm

Her kan du orientere dig om hvad der flyttes, og hvad der ikke flyttes til den 
nye platform.
https://sdfe.dk/hent-data/datafordeleren/


-- 


> Sent: Sunday, August 09, 2020 at 2:13 PM
> From: "Flemming Bruun" 
> To: "talk-dk@openstreetmap.org" 
> Subject: [Talk-dk] SDFE grunddata på Datafordeleren
>
> Hej,
> 
> Blot lidt info om at grunddata fra SDFE flyttes til et nyt site.
> 
> Se mere her:
> https://kortforsyningen.dk/indhold/geografiske-grunddata-pa-datafordeleren
> 
> Jeg har ingen ide om SDFE-linkene forsvinder med tiden, men det er nok 
> noget man skal være opmærksom på.
> 
> Mvh
> Flemming
> 
> ___
> 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-cz] Rozcestníky - Fotky z terénu

2020-08-09 Thread Miroslav Suchy

Dne 09. 08. 20 v 14:08 Petr Schönmann napsal(a):
> Otázka je teda, máme nějakou takovou aplikaci ? Web rozhraní které by mi 
> dovolilo nahrát fotku rovnou k rozcestníku skrz
> optimalizované rozhraní pro mobilní zařízení ?
> 

https://openstreetmap.cz/ -> vrstvy (více vrstev ve skupinách - taková ta ikona 
tabulky v pravém sloupci) -> Fotky Fody
-> pak se vpravo nahoře objeví ikona rozcestníku a po přihlášení je možné 
nahrát fotku.
V terénu to normálně na smartfounu používám.

Mirek

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

Re: [OSM-talk] Cyclofix project

2020-08-09 Thread Pieter Fiers

> Congratulations on a nice project and a useful one !
> For a long time I have wished for a user-friendly bicycle repair specific 
> map, including bicycle cafés.
Thanks, us as well ;)

> What I miss in the Cyclofix project is an easy-to find definition of how you 
> classify the nodes that are to be included in the different map "layers".
> Which search is it that produces the bicycle cafés. (And what takes 
> precedence if two or more criteria are fulfilled?)

An excellent question, and something we want to improve in a future version 
(the discoverability and ease-of-use of the "layer" definitions).

To answer the bicycle cafés question in the context of the current version:
Take a look at 
https://github.com/pietervdvn/MapComplete/blob/master/Customizations/Layers/BikeCafes.ts#L23.
 That overpass filter/query can basically be written as: "a pub/bar/cafe with 
pub=cycling or any bicycle:service" (https://overpass-turbo.eu/s/WSU).

With regards to precedence, both POI's would be shown (not ideal). With the 
current definitions this might happen if there's an overlap on shop=bicycle, 
amenity=pub/bar/cafe, amenity=bicycle_parking or amenity=bicycle_repair_station.

> I agree with making a distinction between "pure" bicycle shops and general 
> sport shops that offer bicycles or repair of bicycles.

For "pure" bicycle shops we use shop=bicycle, for "other" shops (general sports 
equipment stores) we use shop=* + any bicycle:service:* tag.

We're excited for the future and we're continuing work on making the project 
more user-friendly and approachable!

Thanks for the kind words and with kind regards,
Pieter Fiers

On 05/08/2020 00:39, Morten Lange wrote:

> Congratulations on a nice project and a useful one !
>
> For a long time I have wished for a user-friendly bicycle repair specific 
> map, including bicycle cafés.
>
> What I miss in the Cyclofix project is an easy-to find definition of how you 
> classify the nodes that are to be included in the differewnt map "layers". 
> Which search is it that produces the bicycle cafés. (And what takes 
> precedence if two or more criteria are fulfilled?)
>
> I agree with making a distinction between "pure" bicycle shops and general 
> sport shops that offer bicycles or repair of bicycles.
> However, the way Cyclofix has decided to differentiate is not self-evident to 
> me, after briefly checking your documentation. I must admit that I did not 
> really consider looking at the source-code ;-)
>
> --
> Regards / Kveðja / Kila la heri / Hilsen
> Morten Lange
>
> On Wednesday, 29 July 2020, 19:43:38 CEST, Pieter Fiers 
> [](mailto:pie...@pfiers.net) wrote:
>
> Dear OSM community,
>
> My name is Pierre Barban. A team composed of three very motivated students, 
> including myself, and lead by two active members of the OSMbe, have been 
> mandated by the region of Brussels, Belgium, to create a map gathering all 
> kind of data related to cycling. Without a doubt, OpenStreetMap was the 
> perfect tool for us to create a powerful platform that would sustain over the 
> years.
>
> In the framework of month-long online code camp organized by the non-profit 
> [Open Knowledge Belgium](https://be.okfn.org/), we have been able to 
> establish the first version of the [tool](https://cyclofix.osm.be/map/), 
> organized a [mapathon](https://www.youtube.com/watch?v=C5dVjDt5QAE) to 
> collect data, and create a complete [website](https://cyclofix.osm.be/) to 
> document the entire making process.
>
> In accordance with the OSM core values, it would be very valuable for our 
> project as well as our individual learning process to receive as many 
> constructive comments from the community as possible. If you're interested in 
> more details about the project, we will be giving an [online 
> presentation](https://www.eventbrite.be/e/open-summer-of-code-2020-demo-day-live-streaming-registration-112787885602)
>  tomorrow July 30, 2020 at 1pm CEST. We will be available to directly discuss 
> after the presentation to receive feedback in order to keep improving our 
> project. Other related project from our program, [Open Summer of 
> Code](https://osoc.be/), like the Bike Data Project - which aims to collect 
> and share cyclist commute data in an opened way - will also be presented to 
> you.
>
> Please do not hesitate to contact me for further information,
>
> thank you for your time and help.
>
> Sincerely,
>
> Pierre Barban, from the Cyclofix project.
>
> Sent by Pieter Fiers [](mailto:pie...@pfiers.net), another 
> student of the team.
>
> Pierre Barban
>
> University Panthéon-Sorbonne Paris I – Class of 2020
> Masters in Economics of Sustainable Development
> pierre.bar...@gmail.com | +33 7 68 72 92 54
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-us] Potential Import of Addresses for Thurston County, WA, USA

2020-08-09 Thread Raven King

Hello:

I discovered that Thurston County, WA publishes a database of addresses
stored as gps pins inside a shape file. 
The data can be found here:
https://gisdata-thurston.opendata.arcgis.com/datasets/thurston-address-points-tcomm?geometry=-122.915%2C47.023%2C-122.914%2C47.023

The license can be seen where it has a link labeled "Custom License"
next to a picture of a lock. I didn't see anything in there that would
prohibit our use of this, but extra eyes are needed. 

The database has 128,639 addresses. My goal would be to import the
entirety of it into OSM, as Thurston county has very few addresses in
OSM. They would be imported as points, since the database has them
stored as points.

The caveats I see are as follows:
* The database probably has some addresses that are wrong. While
everything I could verify has been correct, I only checked about 100
addresses. 
* There may be some overlap with buildings that already had addresses
entered. Since Thurston County has very few addresses in OSM, I don't
see this being a huge issue.

I have never done an import, and I do not know what the process for
both consensus and the actual import would be.

Sincerely,
Raven King


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

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

2020-08-09 Thread Rory McCann


On 09.08.20 10:25, pangoSE wrote:
I suggest we create a roadmap for deprecating of storing and updating 
names in OSM for objects with a Wikidata tag.


Get rid of the “name” tag(s) in OSM? Absolutely not.

It makes everything massively more complicated, there is very little 
benefit, and Wikidata's CC0 licence allows data to be privatised, unless 
the commons nature of OSM's ODbL.


Why not get rid of the `wikidata` tag and instead merge all wikidata 
attributes into OSM tags instead? Then things become easier to deal with.


Rory

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

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

2020-08-09 Thread Michael Andersen

Min erfaring er at indsættelse af billeder kan være særdeles nyttige i forhold 
til at kunne kontrollere kvaliteten af vores data. Også som bruger af vores 
data har jeg generelt væsentlig større tiltro til vores data i de tilfælde 
hvor der er anvendelige fotos tilknyttet, der måske viser andre objekter i 
nærheden der kan genkendes på luftfotos.
På samme måde kan Wikidata etc. være meget nyttig til at efterprøve kvaliteten 
af vores data.

OSM har iøvrigt altid i høj grad været anvendt og redigeret af turister. Det 
har altid været et "turistprojekt". 

Mvh Hjart

søndag den 9. august 2020 12.19.47 CEST skrev Sonny B. Andersen:
> Jeg synes, det er fint at man får shelterne med på kortet, men så ville jeg
> nok bruge Friluftsrådet som kilde. Men jeg synes ikke der er nogen grund
> til at samarbejde med wiki-data, som man jo altid er nødt til at
> efterkontrollere. Jeg synes heller ikke, at der er nogen grund til at
> indsætte billeder af pladserne. Billeder har en tendens til at blive
> forældede, og i øvrigt er de en unødig belastning af serverne.
> 
> Det her er vel egentlig en principiel diskussion om man vil lave OSM om til
> et turistprojekt eller ej. Så jeg er slet ikke enig i din plan. Det ville
> være langt bedre at starte et samarbejde med kommunerne om at lave gode og
> informative digitale friluftskort.
> 
> Hilsen,
> Sonny B. Andersen
> www.bukhmark.dk
> tlf.: +45 2091 3901
> 
> Fra: pangoSE
> Sendt: 9. august 2020 08:30
> Til: talk-dk@openstreetmap.org
> Emne: [Talk-dk] Åbne data om lejrpladser fra kommuner
> 
> 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_beskrivnin
> g_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: [Talk-GB] OSMUK Instagram ideas

2020-08-09 Thread Robert Skedgell

On 09/08/2020 14:31, Jez Nicholson wrote:
> I've been posting to the OSMUK
> Instagram https://www.instagram.com/openstreetmapuk/ account recently.
> We are currently focusing on potential new mappers, so i'm thinking
> quirky and topical.
> 
> So,
> 
> a) Do you know of an interesting looking feature in the UK?
> 
> b) Do you know of something topical (and visual)?
> 
> c) After this thread has finished, how best could/would you get in
> contact to tell me? Twitter? A thread on Loomio? Here?
> 
> Regards,
>               Jez
> 

Some of the COVID-19 related highway changes, e.g. modal filters
implemented with planters might be worth including. There's an obvious
visual and routing impact in real life, as rendered by OSM Carto and for
routing engines.

-- 
Robert Skedgell (rskedgell)


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

Re: [OSM-talk-fr] Photos > archiver les image=* ?

2020-08-09 Thread PanierAvide

J'avais commencé un fichier MapCSS pour faire de la validation dans JOSM 
sur les images, ça peut être complété pour être plus exhaustif : 
https://josm.openstreetmap.de/wiki/Rules/Pictures


Adrien P.

Le 09/08/2020 à 15:31, Yves P. a écrit :

Pour la France, il y a 46000 tags uniques.

N'oublie pas les valeurs multiples ;)

D'après taginfo, nombre de valeurs contenant ";"

*Clé*   *Nombre**Commentaire*
mapillary   272 
wikimedia_commons   270 Attention : il y a des noms contenants  !
image   78  
flickr  0   


Et ça devrait augmenter si on importe dans OSM les 2 photos de chaque 
DAE );



Je vais démarrer par les image=* car c'est là en principe où il 
devrait y avoir de la perte car j'imagine que Mapillary est plutôt 
stable et fiable.


Il y a plusieurs syntaxes pour wikimedia_commons, mapillary et leurs 
valeurs stockées dans la clé image.


Je pense qu'un formatage (nettoyage) s'impose. Il faudrait d'ailleurs 
le faire au niveau éditeurs, voir carrément au niveau de l'API ;)


Exemples :

Commons

  * 
https://commons.wikimedia.org/wiki/File%3AA4221-Rathaus-Steyregg_10-2013_005.jpg


  * File%3AA4221-Rathaus-Steyregg_10-2013_005.jpg
  * File:A4221-Rathaus-Steyregg 10-2013 005.jpg
  * 
https://upload.wikimedia.org/wikipedia/commons/1/15/A4221-Rathaus-Steyregg_10-2013_005.jpg
  * 
https://upload.wikimedia.org/wikipedia/commons/thumb/1/15/A4221-Rathaus-Steyregg_10-2013_005.jpg/100px-A4221-Rathaus-Steyregg_10-2013_005.jpg
  * …


Mapillary

  * https://www.mapillary.com/map/im/zvHQ3g83K0Wj1yeO_oh6qw
  * zvHQ3g83K0Wj1yeO_oh6qw

  * https://images.mapillary.com/zvHQ3g83K0Wj1yeO_oh6qw/thumb-640.jpg
  * … ?



Que fait-on des valeurs foireuses (ici du tag mapillary) :D

  * name:en=Elephant␣terrace␣tourism=attraction␣url=

https://youtu.be/ZnJBngOUk2w␣wikidata=Q767080␣wikipedia=en:Terrace␣of␣the␣Elephants


  * mapillary=

https://www.mapillary.com/map/im/rmgaoubjKQabLe34FQHurQ␣image=https://images.mapillary.com/rmgaoubjKQabLe34FQHurQ/thumb-2048.jpg


  * https://www.youtube.com/watch?v=8RFaSbBkCXI
  * 
https://www.symphonyseniorliving.com/wp-content/uploads/2017/06/manor_gal_1.jpg
  * https://www.openstreetmap.org/user/km2bp/traces/2992415
  * …



Je ne pense pas à un cache (temporaire), mais à une copie d'archive, 
comme wikipédia le fait sur les sources qui peuvent disparaître, 
changer d'adresse ou autre.



J'avais bien compris ça :)

J'ai un peu réfléchit au problème... le plus simple me semble de 
calculer un hash à partir du tag au contenu à archiver


image=http://site.com/a.jpg -> 
http://archive.osm.org/ce7442f69a6ad43fb972724c1a8cdc05


mapillary=APQ8H32KnIwG3lKIaMY7HA 
->http://archive.osm.org/eaaee35521d34a3cb74965cb50dcb500



Excellente idée :)
(Je rappel les cas de valeurs et syntaxes multiples)

Je verrai bien quelques métadonnées sur l'image, sa date de 
récupération ou autre, ajoutées dans les données EXIF.



Modifier l'image, bof.
Et être obligé d'utiliser une API pour décortiquer l'EXIF peut-être 
parfois lourd.


Des données JSON ?
http://archive.osm.org/eaaee35521d34a3cb74965cb50dcb500.json

__
Yves

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

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

sent from a phone

> On 9. Aug 2020, at 15:08, pangoSE  wrote:
> 
> 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.

I agree photos from the current on the ground situation are a very useful 
addition. I only recently started to add image tags in a systematic way, and am 
quite satisfied with these first steps. I’m currently using wikimedia commons, 
which after a few experiments now works sufficiently well for me, and while I 
also agree that a tighter integration of an image store into the system (avoids 
having to copy the names, might avoid having to type descriptions and adding 
categories) would make my life easier, I also acknowledge that the resources 
needed to make such a system working and keeping it online are significant 
(think data storage, network traffic and computing power for image scaling), so 
I’m not holding my breath for this to come any soon.

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

[Talk-GB] OSMUK Instagram ideas

2020-08-09 Thread Jez Nicholson

I've been posting to the OSMUK Instagram
https://www.instagram.com/openstreetmapuk/ account recently. We are
currently focusing on potential new mappers, so i'm thinking quirky and
topical.

So,

a) Do you know of an interesting looking feature in the UK?

b) Do you know of something topical (and visual)?

c) After this thread has finished, how best could/would you get in contact
to tell me? Twitter? A thread on Loomio? Here?

Regards,
  Jez
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Photos > archiver les image=* ?

> Pour la France, il y a 46000 tags uniques.
N'oublie pas les valeurs multiples ;)

D'après taginfo, nombre de valeurs contenant ";"

Clé Nombre  Commentaire
mapillary   272 
wikimedia_commons   270 Attention : il y a des noms contenants  !
image   78  
flickr  0   

Et ça devrait augmenter si on importe dans OSM les 2 photos de chaque DAE );


> Je vais démarrer par les image=* car c'est là en principe où il devrait y 
> avoir de la perte car j'imagine que Mapillary est plutôt stable et fiable.

Il y a plusieurs syntaxes pour wikimedia_commons, mapillary et leurs valeurs 
stockées dans la clé image.

Je pense qu'un formatage (nettoyage) s'impose. Il faudrait d'ailleurs le faire 
au niveau éditeurs, voir carrément au niveau de l'API ;)

Exemples :

Commons
https://commons.wikimedia.org/wiki/File%3AA4221-Rathaus-Steyregg_10-2013_005.jpg
 

File%3AA4221-Rathaus-Steyregg_10-2013_005.jpg
File:A4221-Rathaus-Steyregg 10-2013 005.jpg
https://upload.wikimedia.org/wikipedia/commons/1/15/A4221-Rathaus-Steyregg_10-2013_005.jpg
 

https://upload.wikimedia.org/wikipedia/commons/thumb/1/15/A4221-Rathaus-Steyregg_10-2013_005.jpg/100px-A4221-Rathaus-Steyregg_10-2013_005.jpg
 

…

Mapillary
https://www.mapillary.com/map/im/zvHQ3g83K0Wj1yeO_oh6qw 

zvHQ3g83K0Wj1yeO_oh6qw 
https://images.mapillary.com/zvHQ3g83K0Wj1yeO_oh6qw/thumb-640.jpg 

… ?


Que fait-on des valeurs foireuses (ici du tag mapillary) :D
name:en=Elephant␣terrace␣tourism=attraction␣url= 
https://youtu.be/ZnJBngOUk2w␣wikidata=Q767080␣wikipedia=en:Terrace␣of␣the␣Elephants
 

mapillary= 
https://www.mapillary.com/map/im/rmgaoubjKQabLe34FQHurQ␣image=https://images.mapillary.com/rmgaoubjKQabLe34FQHurQ/thumb-2048.jpg
 

https://www.youtube.com/watch?v=8RFaSbBkCXI 

https://www.symphonyseniorliving.com/wp-content/uploads/2017/06/manor_gal_1.jpg 

https://www.openstreetmap.org/user/km2bp/traces/2992415 

…


> Je ne pense pas à un cache (temporaire), mais à une copie d'archive, comme 
> wikipédia le fait sur les sources qui peuvent disparaître, changer d'adresse 
> ou autre.
> 
J'avais bien compris ça :)

> J'ai un peu réfléchit au problème... le plus simple me semble de calculer un 
> hash à partir du tag au contenu à archiver
> 
> image=http://site.com/a.jpg  -> 
> http://archive.osm.org/ce7442f69a6ad43fb972724c1a8cdc05 
> 
> mapillary=APQ8H32KnIwG3lKIaMY7HA 
> ->http://archive.osm.org/eaaee35521d34a3cb74965cb50dcb500 
> Excellente idée :)
(Je rappel les cas de valeurs et syntaxes multiples)

> Je verrai bien quelques métadonnées sur l'image, sa date de récupération ou 
> autre, ajoutées dans les données EXIF.
> 
Modifier l'image, bof.
Et être obligé d'utiliser une API pour décortiquer l'EXIF peut-être parfois 
lourd.

Des données JSON ?
http://archive.osm.org/eaaee35521d34a3cb74965cb50dcb500.json 


__
Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2020-08-09 Thread Frederik Ramm

Hi,

On 8/9/20 14:29, pangoSE wrote:
> I therefore suggest we create a wikibase instance called OSMData and
> migrate all our tags into that system.

I don't see the merit, and your idea of putting that database under CC0
is not feasible as it would amount to a license change. I think that
"linked data" is a hype that you are succumbing to. I also think that
your use of the term "metadata" is wrong - in my mind, metadata would be
data about the survey process (like e.g. a source tag), not qualities of
objects we survey.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-talk-fr] Photos — Re: Projet du mois de septembre (en préparation) : défibrillateurs !

2020-08-09 Thread osm . sanspourriel


Le 09/08/2020 à 13:10, Christian Quest - cqu...@openstreetmap.fr a écrit :

j'imagine que Mapillary est plutôt stable et fiable.


Tu imagines sans doute bien.

Par contre Yves nous a déjà remonté des URL ésotériques. C'est plus là
qu'il va y avoir de la perte. Et probablement là l'archive n'y
changerait rien.

Si pour les DAE on veut deux images distinctes à but distinct (vue large
et vue proche), faut-il un ou deux tags ?

Jean-Louis nous avait fait un mapillary:wide.

Donc image, mapillary, ... : vue proche. En général quand on a une photo
d'un objet on a la photo... de l'objet, pas de son environnement.

Donc image:wide, mapillary:wide, ... : vue large (surroundings est
peut-être moins ambigu : wide pourrait signifier le format de photo
landscape/paysage).

Et non Yves je ne suis pas pour mettre des ; : ces photos doivent être
"uniques". Si entre deux photos pour le même but tu ne sais laquelle
choisir c'est sans doute qu'aucune n'est assez bonne.

Comme Christian j'ai des doutes sur la tolérance à long terme de Wiki
d'héberger les photos des bornes incendie, des DAE (demain des boîtes
aux lettres histoire de vérifier les horaires de levée ? Des bouées de
sauvetage en vue large pour la même raison ?).

N. B. : je mets peu de bouées de sauvetage dans OSM car elles sont bien
visibles. Si on ne voit pas une bouée de sauvetage en avoir une sur OSM
plus loin c'est sans doute trop tard.

Jean-Yvon



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

Re: [Talk-dk] Er I klar til at sætte dansk deltagerrekord i morgen?

2020-08-09 Thread Finn Hansen via Talk-dk

Tak for det, skal også love for det er varmt i Odense med 32 grader og ingen 
vind at rende rundt i gaderne i centrum. Jeg og min kone har på forhånd købt 
noget koldt på vores tur tidligere på dagen og er lige vendt hjem. Så nu er jeg 
ved at notere de ændringer jeg er stødt på i selve centrum ud fra de nuværende 
oplysninger på kortet. Mange butikker skal ændres, og nogle steder med 
ensretning som ikke er på kortet.

God dag alle sammen!

MvH
Finn Hansen
@Lytter1
(MP hvis der er lidt tilovers  40552448)

-Oprindelig meddelelse-
Fra: Soren Johannessen  
Sendt: 8. august 2020 17:15
Til: OpenStreetMap Denmark 
Emne: [Talk-dk] Er I klar til at sætte dansk deltagerrekord i morgen?

Hej alle sammen

Så går det løs i morgen søndag 9/8 og er I klar og fit for fight? Det er dagen 
hvor vi i OpenStreetMap vil forsøge at slå rekorden fra 2012 med over 44 
daglige deltagere. Derudover så fejrer vi OpenStreetMaps
16 års fødselsdag. Så hop ind i morgen og kortlæg et eller andet i Danmark. Om 
du bruger 5 min eller flere timer i morgen er ligemeget, det er antallet af 
forskellige OSM brugere vi går efter.

DMI lover også hedebølge i morgen, så der er stadigvæk mulighed for at få  50 
kr til en is eller andet køligt. Septima er sponsor med 2000 kr, OpenDenmark 
foreningen med 500 kr og mit eget firma med 500 kr.

Så vi har 60 personer som kan få lidt forplejning til ovenstående event. Så 
hold jer endelig ikke tilbage med at skrive til soren.johannessen Snabel a  
gmail.com med dit Mobilpay nummer samt OSM brugernavn, og jeg vil overføre 
pengene, så hurtigt som muligt. Først til mølle princip.

Har du ingen Mobilpay, så skriv banknummer med regnr. og kontonummer og jeg kan 
også overføre penge ad den vej til jer.

Spreder du billeder, videoer eller tekst via sociale medier om ovenstående 
event, så brug hashtag #osmdkrekord

I kan se hvad der er skrevet på Twitter indtil videre med dette hashtag 
https://twitter.com/search?q=osmdkrekord=typed_query=live

Velmødt der ude i cyberspace og ha en god OSM kortlægnings søndag.

Med venlig hilsen
Søren Johannessen

NB vores nordiske naboer dags rekorder er hhv,  Finland  84, Sverige
71 og Norge med 55, så dem kan vi også om vi kan slå.

___
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: [OSM-talk] Roadmap for deprecation of name tags in OSM

2020-08-09 Thread Philip Barnes

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

Re: [OSM-talk-be] Mapping disapPeared vicinal paths

2020-08-09 Thread Jo

Meerdaalwoud is mapped quite well. I think we are at least 3 experienced
mappers doing so. Not always easy with aerial imagery alone and GPX gets
distorted, although that has improved a lot over the past 10 years.

I'm afraid there is not much chance to still find this person alive now,
after more than 2 weeks of intensive searching.

Jo

On Sun, Aug 9, 2020, 14:27 Philippe Casteleyn 
wrote:

> Recently I was searching for a disappeared  person in the woods.
>
> Looking at OSMAnd I advised the group leader that we could split a search
> parcel in two because the small  path went to the next wider path.
>
> I was happy that I was luckily correct.
>
> In my region (Mechelen) I have seen that not all ditches are mapped.  I
> find them difficult to map.
>
> Neither are fences.
>
>
>
> The person is still missing.
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

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

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

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.

On Sun., Aug. 9, 2020, 8:58 a.m. pangoSE,  wrote:

> 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

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.

In particular, regarding wikidata, we are focusing on ground truth, while 
wikidata is mostly a mixture of different sources, often imported without even 
having a human looking at it. I also agree with Simon that this would be an 
enormous drop in quality.

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

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

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

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:
>> 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
>> 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'm not sure if I

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

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

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:
> 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
> 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'm not sure if I have a Wikidata account so this is a non-issue for
>>> me.
>>>

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

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


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
 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'm not sure if I have a Wikidata account so this is a non-issue
>for
>> me.
>>
>>>
 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

Re: [Talk-at] Regionen mappen

2020-08-09 Thread Florian Kratochwil

Danke fr diese zwei Inputs. Hier gibts jetzt zwei Themen:

  1) Bundesland-Aufteilungen als boundary=administrative und admin_level=5 
taggen, (zusammen mit place=region oder kann das dann entfallen?)
  Wenn wir das jetzt sterreichweit durchspielen:
* In Wien gibts das nicht
* In N gibt es die klassischen vier Viertel, die man anhand der 
folgenden Karte und den textlichen Beschreibungen im Wikipedia zeichnen kann. 
https://de.wikipedia.org/wiki/Waldviertel#/media/Datei:Karte_Aut_Noe_Bezirke.png
* In O gibt es die vier Viertel, ebenfalls mit guter 
Wikipedia-Beschreibung
* In Salzburg gibt es die 5 Gaue, die bis auf Salzburg-Stadt eh schon 
durch einzelne Bezirke definiert sind. Pongau, Lungau und Flachgau (exkl. Stadt 
Salzburg) sind bereits in OSM. Pinzgau, Tennengau fehlt. --> Alt-Names 
ergnzen und keine admin_level 5 in Salzburg
* In Tirol kenne ich mich nicht so gut aus. Oberland und Unterland, 
Auerfern und Osttirol gibt es offenbar --> wre da was geeingetes 
als admin_level 5?
* In Vorarlberg bin ich auch nicht sehr kundig. Als place=region (exkl. 
region:type=mountain_area) gibt es derzeit den Bregenzerwald und das 
Kleinwalsertal. Hier meine Abfrage: https://overpass-turbo.eu/s/WSB --> Ich 
glaube, es gibt hier keine admin_level 5 Kandidaten.
* In Krnten gibt es Oberkrnten und Unterkrnten. Bei 
der Einteilung nach NUTS 3-Gebieten kommt noch die Region Klagenfurt-Villach 
dazu. In OSM sind diese 3 Gebiete schon gemappt als admin_level 5, aber als 
boundary=region statt administrative (das ist ein Fehler, oder?) 3-Teilung 
lassen oder in Ober- und Unterkrnten zusammenfhren? Wer kennt sich 
aus in Krnten? Ich kanns nicht beurteilen und werde es nicht 
anrhren.
* In der Steiermark gibt es die Obersteiermark und die Mittelsteiermark 
bzw. wrde ich die Mittelsteiermark aufteilen und Ost- und Weststeiermark, 
weil ich den Begriff Mittelsteiermark glaub ich noch nicht gehrt habe, 
die anderen aber schon. Ich bin aber nicht von dort. Also knnte man 3 
Regionen aus der Steiermark machen.
* Burgenland: Es gibt das Nord- Mittel und Sdburgenland, wobei 
laut Wikipedia das Mittelburgenland manchmal dem Sdburgenland zugerechnet 
wird. Das Mittelburgenland ist schon gemappt, da es deckunggleich mit dem 
Bezirk Oberpullendorf ist (als alt_name). --> Nord- und (erweitertes?) 
Sdburgenland als admin_level=5 mappen?
  2) Sonstige Regionen
  Wann passt natural? Meistens. Das mit basin knnte man klren 
versuchen, ich mchte mich hier aber nicht vertiefen. Plain heit 
laut Wrterbuch "Flachland", und das stimmt jedenfalls. Obs jetzt am Rand 
rauf geht (Becken) oder runter geht (Plateau) bzw. wie das ganze im Lauf der 
Zeit entstanden ist (Verdunstung eines Meeres, Anschwemmung durch Fluss, ...) 
wird halt nicht beschrieben.
  Wann wre place=region besser? Nur sehr selten. Meist haben starke 
kulturelle Verbindungen den Namen entstehen lassen. Beim Bregenzerwald zB, oder 
dem Salzkammergut passt das aus meiner Sicht gut.
  Sollen place und natural tags kombiniert werden oder soll man sich auf eines 
einigen? Eher zweiteres, oder? Gibts nicht den Grundsatz 1 Element 1 Tag?

  Liebe Gre
  Florian

  - Ursprngliche Nachricht -
  Von: Stefan Tauner 
  Datum: 07.08.2020 17:27
  An: talk-at@openstreetmap.org
  Betreff: Re: [Talk-at] Regionen mappen
   > Friedrich kriegt oft (zu Recht) heftige Kritik ob seines Umgangstons
>  und seiner Kompromisslosigkeit. Auch wenn die Mail nicht ganz frei von
>  Seitenhieben war :), mchte ich sie als positives Beispiel f
> r einen
>  fundierten Diskussionsbeitrag hervorheben und mich dafr bedanken.
>
>  Dieses "Daumenhoch" wre mein Posting alleine aber nicht
> Wert. Ich will
>  auch meine Zustimmung zu den vorgebrachten Vorschlgen ausdr
> cken;
>  insbesondere admin_level=5 fr die sehr "unnatural"
> "Viertel" und das
>  grundstzliche Behandeln von Regionen - das geht wirklich ab.
>
>  Anekdote dazu: Ich plane gerade Urlaub im Kaiserwinkl (sic! siehe
>  https://www.kaiserwinkl.com) in Tirol. Das Suchergebnis dazu ist...
>  seht selbst: https://www.openstreetmap.org/search?query=kaiserwinkl
>
>  --
>  Kind regards/Mit freundlichen Gren, Stefan Tauner
>
>  ___
>  Talk-at mailing list
>  Talk-at@openstreetmap.org
>  https://lists.openstreetmap.org/listinfo/talk-at
>  
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

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

2020-08-09 Thread mmd

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

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

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

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)

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

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

2020-08-09 Thread Jeremy Harris

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

[OSM-talk-be] Mapping disapPeared vicinal paths

2020-08-09 Thread Philippe Casteleyn

Recently I was searching for a disappeared  person in the woods.
Looking at OSMAnd I advised the group leader that we could split a search 
parcel in two because the small  path went to the next wider path.
I was happy that I was luckily correct.
In my region (Mechelen) I have seen that not all ditches are mapped.  I find 
them difficult to map.
Neither are fences.

The person is still missing.

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

Re: [Talk-dk] Er I klar til at sætte dansk deltagerrekord i morgen?

2020-08-09 Thread Peter Leth

Hej Søren

Jeg har solgt ideen om is og osm til sønnik. Så vi er pt to der deltager:
Do Osm 1 og peterleth

Mobilepay 51522387 ( bare for den ene)

God dag

/ Peter

lør. 8. aug. 2020 kl. 17.16 skrev Soren Johannessen <
soren.johannes...@gmail.com>:

> Hej alle sammen
>
> Så går det løs i morgen søndag 9/8 og er I klar og fit for fight? Det
> er dagen hvor vi i OpenStreetMap vil forsøge at slå rekorden fra 2012
> med over 44 daglige deltagere. Derudover så fejrer vi OpenStreetMaps
> 16 års fødselsdag. Så hop ind i morgen og kortlæg et eller andet i
> Danmark. Om du bruger 5 min eller flere timer i morgen er ligemeget,
> det er antallet af forskellige OSM brugere vi går efter.
>
> DMI lover også hedebølge i morgen, så der er stadigvæk mulighed for at
> få  50 kr til en is eller andet køligt. Septima er sponsor med 2000
> kr, OpenDenmark foreningen med 500 kr og mit eget firma med 500 kr.
>
> Så vi har 60 personer som kan få lidt forplejning til ovenstående
> event. Så hold jer endelig ikke tilbage med at skrive til
> soren.johannessen Snabel a  gmail.com med dit Mobilpay nummer samt OSM
> brugernavn, og jeg vil overføre pengene, så hurtigt som muligt. Først
> til mølle princip.
>
> Har du ingen Mobilpay, så skriv banknummer med regnr. og kontonummer
> og jeg kan også overføre penge ad den vej til jer.
>
> Spreder du billeder, videoer eller tekst via sociale medier om
> ovenstående event, så brug hashtag #osmdkrekord
>
> I kan se hvad der er skrevet på Twitter indtil videre med dette hashtag
> https://twitter.com/search?q=osmdkrekord=typed_query=live
>
> Velmødt der ude i cyberspace og ha en god OSM kortlægnings søndag.
>
> Med venlig hilsen
> Søren Johannessen
>
> NB vores nordiske naboer dags rekorder er hhv,  Finland  84, Sverige
> 71 og Norge med 55, så dem kan vi også om vi kan slå.
>
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-dk
>
-- 
*Med venlig hilsen *

*Peter Leth*
*pe...@pluk.dk  *
*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] SDFE grunddata på Datafordeleren

2020-08-09 Thread Flemming Bruun


Hej,

Blot lidt info om at grunddata fra SDFE flyttes til et nyt site.

Se mere her:
https://kortforsyningen.dk/indhold/geografiske-grunddata-pa-datafordeleren

Jeg har ingen ide om SDFE-linkene forsvinder med tiden, men det er nok 
noget man skal være opmærksom på.


Mvh
Flemming

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

[talk-cz] Rozcestníky - Fotky z terénu

2020-08-09 Thread Petr Schönmann

Ahoj, když rozcestníky spravoval walley, byla k tomu nějaká velmi
minimalistická aplikace,nahrávátko,  kde šli nahrávat fotky přímo z
androidí aplikace. Máme stále takovou možnost ?
Přiznám se že jakmile bych to nenahrál hned tak už to po pár dnech zapadne
a to mi přijde škoda.

Mám flow takové, že mám GPX v navigaci/locusu a varovným bodem se nechám
upozornit když jdu kolem. Vyfotím fotku a až doma ji musím nahrát. Snažím
se vždycky udělat maximálně nejkvalitnější a co nejvypovídající obrázek.
Uvítal bych proto nahrávání rovnou z terénu.

Otázka je teda, máme nějakou takovou aplikaci ? Web rozhraní které by mi
dovolilo nahrát fotku rovnou k rozcestníku skrz optimalizované rozhraní pro
mobilní zařízení ?
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

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

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
>>> 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'm not sure if I have a Wikidata account so this is a non-issue for
> me.
>
>>
>>> 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
>>
> ___
> 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

2020-08-09 Thread Alan Mackie

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
>> 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'm not sure if I have a Wikidata account so this is a non-issue for me.

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

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

2020-08-09 Thread mmd

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?

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

-- 

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

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

2020-08-09 Thread Stefano

More than deprecating name=* to replace with Wikidata, it would be needed
deprecating it in favour of name:=* and leaving to the client the
decision of what language to render.
It would partially solve the multilanguage issue...

Stefano

On Sun, 9 Aug 2020, 13: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.
>
> 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.
>> * 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
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

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 >>  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: [OSM-talk-fr] Photos > archiver les image=* ?

2020-08-09 Thread Christian Quest


Le 09/08/2020 à 12:45, PanierAvide a écrit :


Question bateau mais a-t'on une idée du nombre d'attributs image=* en 
base pour lesquels la photo n'est plus actuellement disponible ? 
Clairement un système d'archivage de photos a tout son sens, mais 
probablement pas le même degré d'urgence à mettre en place selon si on 
a 1% de pertes ou 80%.


Cordialement,



Je suis en train de regarder ça justement ;)

Extraction en cours de tous les tags image=* et mapillary=* du fichier 
planet (merci osmium).


Pour la France, il y a 46000 tags uniques.

Je vais démarrer par les image=* car c'est là en principe où il devrait 
y avoir de la perte car j'imagine que Mapillary est plutôt stable et fiable.



--
Christian Quest - OpenStreetMap France


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

[talk-cz] Suspicious relations ("XYZ in Czech Republic")

2020-08-09 Thread Mateusz Konieczny via talk-cz

OSM objects are inherently recording their position.

If one maps say cave entrance and country borders,
then one may already answer the question
"is cave XYZ inside area of country ABC".

As result it is not necessary to create relations
"caves in country X", "caves on continent Y",
"caves in region Z".

It seems to me that
https://www.openstreetmap.org/relation/2216406 and its child relations
are violating 
https://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories
and should be deleted, but I decided to not make edit itself.
Maybe something would be missed and some tags should be added to objects
gathered in this relations

I already deleted such relations and previously deleted some
"motorways in country X" relations that had no chance of adding any useful info
and required no edit to rescue anything.

Two recent edits:
https://www.openstreetmap.org/changeset/89149625
https://www.openstreetmap.org/changeset/89149792

Can you delete this relations if 
https://www.openstreetmap.org/relation/2216406 and its subsequent category 
relations
should be deleted?
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

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

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

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-fr] Photos — Re: Projet du mois de septembre (en préparation) : défibrillateurs !

2020-08-09 Thread PanierAvide

Question bateau mais a-t'on une idée du nombre d'attributs image=* en 
base pour lesquels la photo n'est plus actuellement disponible ? 
Clairement un système d'archivage de photos a tout son sens, mais 
probablement pas le même degré d'urgence à mettre en place selon si on a 
1% de pertes ou 80%.


Cordialement,

Adrien P.

Le 09/08/2020 à 12:06, Christian Quest a écrit :

Le 09/08/2020 à 10:14, Yves P. a écrit :

de Christian


Pour le stockage des photos ou autres sources externes, wikipedia 
garde une copie d'archive.
Je pense que ce serait bénéfique de faire pareil pour OSM, car tout 
lien externe est potentiellement instable


Tu suggères de mettre un système de cache au niveau de l'API OSM ? ;)

Un contributeur OSM édite un objet avec les tags suivant et l'API 
fait automatiquement un copie :


  * image=http://site.com/a.jpg
  * mapillary=APQ8H32KnIwG3lKIaMY7HA
  * wikimedia_commons=File:Defibrillator am Hafenbüro Kappeln.jpg
  * une combinaison de tout ça dans le tag image
  * avec des valeurs multiples ;)


Comment retrouve-t-on les photos ?


Je ne pense pas à un cache (temporaire), mais à une copie d'archive, 
comme wikipédia le fait sur les sources qui peuvent disparaître, 
changer d'adresse ou autre.


J'ai un peu réfléchit au problème... le plus simple me semble de 
calculer un hash à partir du tag au contenu à archiver. Ceci évite de 
devoir rajouter un tag avec le lien de l'archive dans la base OSM.


Exemple (avec du md5)

image=http://site.com/a.jpg -> 
http://archive.osm.org/ce7442f69a6ad43fb972724c1a8cdc05


mapillary=APQ8H32KnIwG3lKIaMY7HA -> 
http://archive.osm.org/eaaee35521d34a3cb74965cb50dcb500


etc...


A charge pour le script d'archivage de récupérer la photo en elle 
même, ce qui d'ailleurs rendra son accès universel car aujourd'hui il 
faut faire cela avec les différents tags si on veut accéder à l'image 
et par à une page web ou autre.


Je verrai bien quelques métadonnées sur l'image, sa date de 
récupération ou autre, ajoutées dans les données EXIF.



Avantages:

- aucun changement pour les contributeurs

- facile à implémenter pour accéder à une archive


Inconvénients: je vous laisse compléter ;)


D'après taginfo, image=* + mapillary=* ça ne va par bien loin... ça 
sent le POC ;)



PS: je ne pense pas que Wikimédia Commons soit destiné à ce genre de 
contenu, ce n'est pas un stockage cloud fourre-tout. La 1ème photo 
de DAE y apportera quoi ?


--
Christian Quest - OpenStreetMap France

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

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

2020-08-09 Thread Sonny B. Andersen

Jeg synes, det er fint at man får shelterne med på kortet, men så ville jeg nok
bruge Friluftsrådet som kilde. Men jeg synes ikke der er nogen grund til at
samarbejde med wiki-data, som man jo altid er nødt til at efterkontrollere. Jeg
synes heller ikke, at der er nogen grund til at indsætte billeder af pladserne.
Billeder har en tendens til at blive forældede, og i øvrigt er de en unødig
belastning af serverne.

Det her er vel egentlig en principiel diskussion om man vil lave OSM om til et
turistprojekt eller ej. Så jeg er slet ikke enig i din plan. Det ville være
langt bedre at starte et samarbejde med kommunerne om at lave gode og
informative digitale friluftskort.

Hilsen,
Sonny B. Andersen
www.bukhmark.dk
tlf.: +45 2091 3901

Fra: pangoSE
Sendt: 9. august 2020 08:30
Til: talk-dk@openstreetmap.org
Emne: [Talk-dk] Åbne data om lejrpladser fra kommuner

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] Roadmap for deprecation of name tags in OSM

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 >>  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: [OSM-talk-fr] Photos — Re: Projet du mois de septembre (en préparation) : défibrillateurs !

2020-08-09 Thread Christian Quest


Le 09/08/2020 à 10:14, Yves P. a écrit :

de Christian


Pour le stockage des photos ou autres sources externes, wikipedia 
garde une copie d'archive.
Je pense que ce serait bénéfique de faire pareil pour OSM, car tout 
lien externe est potentiellement instable


Tu suggères de mettre un système de cache au niveau de l'API OSM ? ;)

Un contributeur OSM édite un objet avec les tags suivant et l'API fait 
automatiquement un copie :


  * image=http://site.com/a.jpg
  * mapillary=APQ8H32KnIwG3lKIaMY7HA
  * wikimedia_commons=File:Defibrillator am Hafenbüro Kappeln.jpg
  * une combinaison de tout ça dans le tag image
  * avec des valeurs multiples ;)


Comment retrouve-t-on les photos ?


Je ne pense pas à un cache (temporaire), mais à une copie d'archive, 
comme wikipédia le fait sur les sources qui peuvent disparaître, changer 
d'adresse ou autre.


J'ai un peu réfléchit au problème... le plus simple me semble de 
calculer un hash à partir du tag au contenu à archiver. Ceci évite de 
devoir rajouter un tag avec le lien de l'archive dans la base OSM.


Exemple (avec du md5)

image=http://site.com/a.jpg -> 
http://archive.osm.org/ce7442f69a6ad43fb972724c1a8cdc05


mapillary=APQ8H32KnIwG3lKIaMY7HA -> 
http://archive.osm.org/eaaee35521d34a3cb74965cb50dcb500


etc...


A charge pour le script d'archivage de récupérer la photo en elle même, 
ce qui d'ailleurs rendra son accès universel car aujourd'hui il faut 
faire cela avec les différents tags si on veut accéder à l'image et par 
à une page web ou autre.


Je verrai bien quelques métadonnées sur l'image, sa date de récupération 
ou autre, ajoutées dans les données EXIF.



Avantages:

- aucun changement pour les contributeurs

- facile à implémenter pour accéder à une archive


Inconvénients: je vous laisse compléter ;)


D'après taginfo, image=* + mapillary=* ça ne va par bien loin... ça sent 
le POC ;)



PS: je ne pense pas que Wikimédia Commons soit destiné à ce genre de 
contenu, ce n'est pas un stockage cloud fourre-tout. La 1ème photo 
de DAE y apportera quoi ?


--
Christian Quest - OpenStreetMap France

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

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

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

[Talk-GB] weeklyOSM #524 2020-07-28-2020-08-03

The weekly round-up of OSM news, issue # 524,
is now available online in English, giving as always a summary of a lot of 
things happening in the openstreetmap world:

 https://www.weeklyosm.eu/en/archives/13472/

Enjoy! 

Did you know that you can also submit messages for the weeklyOSM? Just log in 
to https://osmbc.openstreetmap.de/login with your OSM account. Read more about 
how to write a post here: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[OSM-talk-ie] weeklyOSM #524 2020-07-28-2020-08-03

The weekly round-up of OSM news, issue # 524,
is now available online in English, giving as always a summary of a lot of 
things happening in the openstreetmap world:

 https://www.weeklyosm.eu/en/archives/13472/

Enjoy! 

Did you know that you can also submit messages for the weeklyOSM? Just log in 
to https://osmbc.openstreetmap.de/login with your OSM account. Read more about 
how to write a post here: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

[Talk-ca] weeklyOSM #524 2020-07-28-2020-08-03

The weekly round-up of OSM news, issue # 524,
is now available online in English, giving as always a summary of a lot of 
things happening in the openstreetmap world:

 https://www.weeklyosm.eu/en/archives/13472/

Enjoy! 

Did you know that you can also submit messages for the weeklyOSM? Just log in 
to https://osmbc.openstreetmap.de/login with your OSM account. Read more about 
how to write a post here: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-in] weeklyOSM #524 2020-07-28-2020-08-03

The weekly round-up of OSM news, issue # 524,
is now available online in English, giving as always a summary of a lot of 
things happening in the openstreetmap world:

 https://www.weeklyosm.eu/en/archives/13472/

Enjoy! 

Did you know that you can also submit messages for the weeklyOSM? Just log in 
to https://osmbc.openstreetmap.de/login with your OSM account. Read more about 
how to write a post here: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

[Talk-us] weeklyOSM #524 2020-07-28-2020-08-03

The weekly round-up of OSM news, issue # 524,
is now available online in English, giving as always a summary of a lot of 
things happening in the openstreetmap world:

 https://www.weeklyosm.eu/en/archives/13472/

Enjoy! 

Did you know that you can also submit messages for the weeklyOSM? Just log in 
to https://osmbc.openstreetmap.de/login with your OSM account. Read more about 
how to write a post here: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[OSM-talk] weeklyOSM #524 2020-07-28-2020-08-03

The weekly round-up of OSM news, issue # 524,
is now available online in English, giving as always a summary of a lot of 
things happening in the openstreetmap world:

 https://www.weeklyosm.eu/en/archives/13472/

Enjoy! 

Did you know that you can also submit messages for the weeklyOSM? Just log in 
to https://osmbc.openstreetmap.de/login with your OSM account. Read more about 
how to write a post here: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-africa] weeklyOSM #524 2020-07-28-2020-08-03

The weekly round-up of OSM news, issue # 524,
is now available online in English, giving as always a summary of a lot of 
things happening in the openstreetmap world:

 https://www.weeklyosm.eu/en/archives/13472/

Enjoy! 

Did you know that you can also submit messages for the weeklyOSM? Just log in 
to https://osmbc.openstreetmap.de/login with your OSM account. Read more about 
how to write a post here: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa

[talk-ph] weeklyOSM #524 2020-07-28-2020-08-03

The weekly round-up of OSM news, issue # 524,
is now available online in English, giving as always a summary of a lot of 
things happening in the openstreetmap world:

 https://www.weeklyosm.eu/en/archives/13472/

Enjoy! 

Did you know that you can also submit messages for the weeklyOSM? Just log in 
to https://osmbc.openstreetmap.de/login with your OSM account. Read more about 
how to write a post here: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

[Talk-es] semanarioOSM Nº 524 2020-07-28-2020-08-03

Hola, el semanario Nº 524, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

https://www.weeklyosm.eu/es/archives/13472/

¡Disfruta!

¿Sabías que también puedes enviar mensajes para la nota semanal sin ser 
miembro? Simplemente ingresa a https://osmbc.openstreetmap.de/login con tu 
cuenta de OSM. Lee más sobre cómo escribir una publicación aquí: 
http://www.weeklyosm.eu/es/this-news-should-be-in-weeklyosm 

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

[Talk-cl] semanarioOSM Nº 524 2020-07-28-2020-08-03

Hola, el semanario Nº 524, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

https://www.weeklyosm.eu/es/archives/13472/

¡Disfruta!

¿Sabías que también puedes enviar mensajes para la nota semanal sin ser 
miembro? Simplemente ingresa a https://osmbc.openstreetmap.de/login con tu 
cuenta de OSM. Lee más sobre cómo escribir una publicación aquí: 
http://www.weeklyosm.eu/es/this-news-should-be-in-weeklyosm 

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-cl mailing list
Talk-cl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cl

[OSM-co] semanarioOSM Nº 524 2020-07-28-2020-08-03

Hola, el semanario Nº 524, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

https://www.weeklyosm.eu/es/archives/13472/

¡Disfruta!

¿Sabías que también puedes enviar mensajes para la nota semanal sin ser 
miembro? Simplemente ingresa a https://osmbc.openstreetmap.de/login con tu 
cuenta de OSM. Lee más sobre cómo escribir una publicación aquí: 
http://www.weeklyosm.eu/es/this-news-should-be-in-weeklyosm 

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-co mailing list
Talk-co@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-co

[Talk-cu] semanarioOSM Nº 524 2020-07-28-2020-08-03

Hola, el semanario Nº 524, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

https://www.weeklyosm.eu/es/archives/13472/

¡Disfruta!

¿Sabías que también puedes enviar mensajes para la nota semanal sin ser 
miembro? Simplemente ingresa a https://osmbc.openstreetmap.de/login con tu 
cuenta de OSM. Lee más sobre cómo escribir una publicación aquí: 
http://www.weeklyosm.eu/es/this-news-should-be-in-weeklyosm 

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-cu mailing list
Talk-cu@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cu

[OSM-talk-fr] hebdoOSM Nº 524 2020-07-28-2020-08-03

Bonjour,

Le résumé hebdomadaire n° 524 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

https://www.weeklyosm.eu/fr/archives/13472/

Bonne lecture !

Saviez-vous que vous pouvez vous aussi soumettre des messages pour la note 
hebdomadaire sans être membre ? Il vous suffit de vous connecter sur 
https://osmbc.openstreetmap.de/login avec votre compte OSM. Pour en savoir plus 
sur la rédaction d'un article, cliquez ici: 
http://www.weeklyosm.eu/fr/this-news-should-be-in-weeklyosm

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[talk-latam] semanarioOSM Nº 524 2020-07-28-2020-08-03

Hola, el semanario Nº 524, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

https://www.weeklyosm.eu/es/archives/13472/

¡Disfruta!

¿Sabías que también puedes enviar mensajes para la nota semanal sin ser 
miembro? Simplemente ingresa a https://osmbc.openstreetmap.de/login con tu 
cuenta de OSM. Lee más sobre cómo escribir una publicación aquí: 
http://www.weeklyosm.eu/es/this-news-should-be-in-weeklyosm 

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk-latam mailing list
talk-latam@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-latam

[Talk-ca] hebdoOSM Nº 524 2020-07-28-2020-08-03

Bonjour,

Le résumé hebdomadaire n° 524 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

https://www.weeklyosm.eu/fr/archives/13472/

Bonne lecture !

Saviez-vous que vous pouvez vous aussi soumettre des messages pour la note 
hebdomadaire sans être membre ? Il vous suffit de vous connecter sur 
https://osmbc.openstreetmap.de/login avec votre compte OSM. Pour en savoir plus 
sur la rédaction d'un article, cliquez ici: 
http://www.weeklyosm.eu/fr/this-news-should-be-in-weeklyosm

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-africa] hebdoOSM Nº 524 2020-07-28-2020-08-03

Bonjour,

Le résumé hebdomadaire n° 524 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

https://www.weeklyosm.eu/fr/archives/13472/

Bonne lecture !

Saviez-vous que vous pouvez vous aussi soumettre des messages pour la note 
hebdomadaire sans être membre ? Il vous suffit de vous connecter sur 
https://osmbc.openstreetmap.de/login avec votre compte OSM. Pour en savoir plus 
sur la rédaction d'un article, cliquez ici: 
http://www.weeklyosm.eu/fr/this-news-should-be-in-weeklyosm

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa

[Talk-it] weeklyOSM #524 2020-07-28-2020-08-03

Il settimanale di notizie su OSM, numero # 524, è ora disponibile online in 
italiano, 
fornendo come sempre un riassunto di molte cose che accadono nel mondo 
OpenStreetMap: 

https://www.weeklyosm.eu/it/archives/13472/

Buona lettura! 

Sai che possono anche inviare messaggi per il weeklyOSM? Basta effettuare il 
login 
su https://osmbc.openstreetmap.de/login con il tuo account OSM. 

Per saperne di più su come scrivere un messaggio, leggi qui: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 
weeklyOSM? 

chi: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
dove?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-ht] hebdoOSM Nº 524 2020-07-28-2020-08-03

Bonjour,

Le résumé hebdomadaire n° 524 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

https://www.weeklyosm.eu/fr/archives/13472/

Bonne lecture !

Saviez-vous que vous pouvez vous aussi soumettre des messages pour la note 
hebdomadaire sans être membre ? Il vous suffit de vous connecter sur 
https://osmbc.openstreetmap.de/login avec votre compte OSM. Pour en savoir plus 
sur la rédaction d'un article, cliquez ici: 
http://www.weeklyosm.eu/fr/this-news-should-be-in-weeklyosm

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ht mailing list
Talk-ht@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ht
Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour 
traduire les messages.

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

Aug 9, 2020, 11:09 by pang...@riseup.net:

> >"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
>
Then what kind of complexity is not handled by OSM?

> >loc_name, name:pl and many others?
>
That is not handled by already existing tags?
If there is some actual problem then it should be solved.


> >"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. 
>
How it would be avoided? 
How pulling data from Wikidata would change anything in such case?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-br] semanárioOSM Nº 524 2020-07-28-2020-08-03

Bom dia,

O semanárioOSM Nº 524, o resumo de tudo o que acontece no mundo OpenStreetMap, 
está publicado *em português* : 

https://www.weeklyosm.eu/pb/archives/13472/

Aproveite!

Você sabia que também pode enviar mensagens para o OSM semanal/semanárioOSMſ 
sem ser membro? Basta fazer login em https://osmbc.openstreetmap.de/login com 
sua conta OSM e usar a conta de convidado. Leia mais sobre como escrever um 
post aqui: http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm

semanarioOSM? 
Quem?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Onde?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-de] weeklyOSM #524 2020-07-28-2020-08-03

Die Wochennotiz Ausgabe Nr. # 524, ist nun verfügbar - 
wie immer mit vielen Nachrichten aus dem OSM-Universium:

https://www.weeklyosm.eu/de/archives/13472/

Viel Spaß beim Lesen.  

Euer Wochennotizteam

Wusstet ihr, dass ihr auch selbst Meldungen für die Wochennotiz
einreichen könnt? Einfach auf https://osmbc.openstreetmap.de/ 
mit eurem OSM-Benutzerkonto anmelden und dann den Gastzugang benutzen. 

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[OSM-talk-fr] Anniversaire OSM et défibrillateurs

> Anniversaire OSM
> 
> Que pouvons-nous faire ?
> 
> Organiser une carto partie avec partage d'un gâteau d'anniversaire OSM 
>  ?
> Avec à l'issue, une photo : bravo aux Kabouliennes et Kabouliens 
> 

Et pourquoi pas des carto-parties pour recenser les DAE ?
Des présentations (vidéos) pour montrer les applis OSM pour les trouver et les 
cartographier ?

Pour les plus pointus, le travail d'assurance qualité fait Osmose…

__
Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Photos — Re: Projet du mois de septembre (en préparation) : défibrillateurs !