Re: [OSM-talk] Proposed bulk removal of service=driveway2

[Yves via talk]

That would be again discussing with the proponent, as Brian started.
Taginfo chronology already show one mass edit and revert, best to make sure 
there's not another waste of energy beforehand.
Yves 

Le 27 juin 2023 12:46:50 GMT+02:00, Marc_marc  a écrit :
>Le 27.06.23 à 12:27, Yves via talk a écrit :
>> 
>> 
>> Le 25 juin 2023 01:02:04 GMT+02:00, "Brian M. Sperlongano" 
>>  a écrit :
>> 
>>> 
>>> And indeed, nine months later, we see that not only has the work not gotten
>>> done, but while we all squabbled away with our pet views about automated
>>> editing, we find that we agreed to nothing, and the mapper has quietly
>>> continued to add this nonsense tag to the database unabated:
>>> https://taginfo.openstreetmap.org/tags/service=driveway2#chronology
>>> 
>> 
>> An automated edit or a Maproulette challenge makes no sense in these 
>> conditions.
>
>Could you explain what you think?
>And what solution will you use if neither a mass edition nor an 
>object-by-object edition is suitable in your opinion?
>
>
>
>___
>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] Proposed bulk removal of service=driveway2

[Yves via talk]

Le 25 juin 2023 01:02:04 GMT+02:00, "Brian M. Sperlongano" 
 a écrit :

>
>And indeed, nine months later, we see that not only has the work not gotten
>done, but while we all squabbled away with our pet views about automated
>editing, we find that we agreed to nothing, and the mapper has quietly
>continued to add this nonsense tag to the database unabated:
>https://taginfo.openstreetmap.org/tags/service=driveway2#chronology
>

An automated edit or a Maproulette challenge makes no sense in these conditions.
Yves 

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

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Yves via talk]

Le 10 janvier 2023 08:12:43 GMT+01:00, Snusmumriken 
 a écrit :
>On Mon, 2023-01-09 at 23:06 +, Andy Townsend wrote:
>> On 09/01/2023 20:17, Snusmumriken wrote:
>> > On Mon, 2023-01-09 at 08:21 -0500, Greg Troxel wrote:
>> > > You seem unwilling to understand that defining a way to refer to
>> > > ids
>> > > will cause social pressure not to change ids,
>> > Is there actually evidence that would corroborate this claim?
>> 
>> There have definitely been complaints to the DWG when people
>> "resurrect" 
>> old long-deleted nodes, or exhibit "unusual mapping behaviour" such
>> as 
>> never deleting any nodes, and always re-using them in some other 
>> feature.  There have also been complaints about changes to objects
>> that 
>> people consider "special" such as
>> https://osm.mapki.com/history/node/1 
>> and, er,
>> https://www.openstreetmap.org/node/69#map=17/48.06733/12.86258 .
>
>Right, I guess one could say that when it comes to retaining existing
>osm ids there is bad practice and good practice, and a grey area. Any
>proof or indications that creating a URI scheme would increase the bad
>practice?
>
No, adding such a URI scheme wouldn't change at all the way contributors 
contribute.

However it would further degrade the impact of the "bad practice". 

I put "bad practice" between quotes because if it is considered good practice 
to try to keep IDs when editing because it's easier to retrieve history when 
trying to understand each other edits, it's not mandatory. 

Yves

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

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Yves via talk]

Le 9 janvier 2023 16:19:14 GMT+01:00, Niels Elgaard Larsen  a 
écrit :
>
>I sometimes do get annoyed at especially new mappers that often
>excessively delete and recreates objects. Because it obscures the
>history.
>
If it is a trend for new mappers, which I understand well because sometimes it 
is easier to re-create from scratch, then you shouldn't be annoyed by it. The 
good news here is that a new mapper tries to improve the map!
A new mapper that could be put off by the slightest social pressure.
Yves 

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

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Yves via talk]

Le 6 janvier 2023 15:49:53 GMT+01:00, "Sören Reinecke"  a 
écrit :
>
>Better would be to have a separate FOSS platform for storing POI information 
>using a permanent identifier connected to OSM somehow e.g. by a key 
>"somepoiplatformid". But no one created such a platform yet.
>
Probably because it is slightly complicated to do and ressource-intensive?
For this reason, data consumers creating geo:id would not be likely to do it 
either.
Yves 

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

Re: [OSM-talk] Making GPS tracks in Android

[Yves via talk]

Gps logger was perfect, unfortunately : 
https://github.com/mendhak/gpslogger/issues/849
Yves 

Le 20 décembre 2020 19:43:00 GMT+01:00, Martijn van Exel  a 
écrit :
>Andy, 
>
>If you would like something lightweight that just does GPS track recording, I 
>would recommend GPS Logger 
>https://wiki.openstreetmap.org/wiki/GPS_Logger_for_Android 
><https://wiki.openstreetmap.org/wiki/GPS_Logger_for_Android> . A nice bonus is 
>that you can have the app automatically upload your tracks to OSM in whatever 
>privacy mode you choose. It can also sync with Nextcloud, Dropbox etc.
>
>OSMTracker offers a little more functionality like recording waypoints with 
>specific, configurable notes, and recording audio notes. 
>https://wiki.openstreetmap.org/wiki/OSMTracker_(Android) 
><https://wiki.openstreetmap.org/wiki/OSMTracker_(Android)> 
>
>I’m not on Android right now but I’ve used both these OSS apps for years.
>
>Martijn
>
>> On Dec 20, 2020, at 5:36 AM, Andy Mabbett  wrote:
>> 
>> Father Christmas came early this year, and has delivered to me a smart
>> new Android phone, whose GPS is much better than on my old one.
>> 
>> I want to use it to trace some tracks on a local nature reserve. What
>> app(s) do you recommend for this?
>> 
>> -- 
>> Andy Mabbett
>> @pigsonthewing
>> http://pigsonthewing.org.uk
>> 
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Call to Take Action and Confront Systemic Offensive Behavior in the OSM Community

[Yves via talk]

Niels, Arnalielsewhere post wasn't about mapping, the map is used to illustrate 
something. 
I agree with others comments pledging for more time to be taken to read someone 
else's lines. 
Yves___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Sophox server down

[Yves P.]

Hi,

The sophox.org server is down from several weeks. It's impossible to query data 
items 😢
Does anybody have news ?

Best regards,

—
Yves

Keywords: SPARQL, OSM Wikibase, Data Item, Sophox

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

Re: [OSM-talk] Find actively browsed undermapped regions and other gaps in OSM

[Yves via talk]

Really fun to see usernames where your brain expect places, I love it!
Makes me want to check on neighborhood, so it's a good work. 
Yves

Le 20 octobre 2020 15:31:15 GMT+02:00, Darafei Praliaskouski via talk 
 a écrit :
>Hi,
>
>Fixed links:
>
>Kontur OpenStreetMap Antiquity:
>https://disaster.ninja/live/#id=GDACS_EQ_1240102_1338684;position=7.92,45.59;zoom=4.4;overlays=bivariate-custom_kontur_openstreetmap_antiquity
>
>Kontur OpenStreetMap Building Quantity:
>https://disaster.ninja/live/#id=GDACS_EQ_1240102_1338684;position=-75.17,40.144086257217054;zoom=8.56;overlays=bivariate-custom_kontur_openstreetmap_building_quantity
>
>The other layers are available in the right Overlay panel.
>
>Have a good day.
>
>On Tue, Oct 20, 2020 at 3:46 PM Darafei Praliaskouski  
>wrote:
>>
>> Hi mappers,
>>
>> We’ve polished our visualization of the need for OpenStreetMap data,
>> and its quality. We’ve been building Disaster.Ninja tool to assist HOT
>> in their activation process, but believe it’s also useful for the
>> general mapping community.
>>
>> Kontur OpenStreetMap Antiquity layer lets you see where people look at
>> the map tiles versus when the map was last edited. Good way to see
>> undermapped regions that are explored by the users in search of data.
>> We base the layer on tile views information, thanks Operations Working
>> group for making it available for such analysis.
>>
>> https://disaster.ninja/live/#position=7.92,45.59;zoom=4.4;overlays=bivariate-custom_kontur_openstreetmap_antiquity
>>
>> Kontur OpenStreetMap Building Quantity is now pointing to a lot more
>> missed buildings. This became possible thanks to Copernicus releasing
>> a high resolution global landcover classification raster, and
>> Microsoft providing the computer vision detected buildings for Canada,
>> USA, Uganda and Tanzania. Look at the gaps here:
>>
>> https://disaster.ninja/live/#position=-75.17,40.144086257217054;zoom=8.56;overlays=bivariate-custom_kontur_openstreetmap_building_quantity
>>
>> I know this layer was used to plan some mapping parties in Ukraine already.
>>
>> Check out the other layers if you haven’t seen them, too. :)
>>
>> To support this visualization we combined all the available public
>> datasets (Facebook Population, OpenStreetMap, Microsoft buildings,
>> Copernicus) into a single world population dataset. If you need it for
>> your analysis, get it here:
>> https://data.humdata.org/dataset/kontur-population-dataset
>>
>> Hope to hear your thoughts on this update.
>>
>> Darafei
>
>___
>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] Idea for improving mapping system

[Yves via talk]

Out of topic content. There is discussions about being more welcoming on this 
list, along with being open to other communications channels. Even with that in 
mind, I must admit I hadn't logged in or subscribed to slack to check on the 
discussion while the topic may be of interest.
By any means, this does not mean that the idea or discussion is not worth it, 
especially if volunteers are involved in such a project, and I would not 
request anything that would refrain them to go forward. 
I'm sure I will hear about it sooner or later. 
Yves 



Le 18 octobre 2020 08:38:16 GMT+02:00, Maarten Deen  a écrit :
>+1
>
>I'm sorry if I sound a little paranoid, but somone with an email address 
>of little.banana.peel and calling him TheAdventurer64 and asking people 
>to read something for which they have to log in to with a google account 
>does not give the feel for a solid foundation for a discussion.
>
>Regards,
>Maarten
>
>On 2020-10-18 06:02, Joseph Eisenberg wrote:
>> Would you mind describing the proposed system here, in a concise form?
>> 
>> On Sat, Oct 17, 2020 at 7:36 PM TheAdventurer64
>>  wrote:
>> 
>>> Hello everyone,
>>> 
>>> A user and I were talking about implementing a system for better
>>> mapping, as described here:
>>> https://osmus.slack.com/archives/C029HV951/p1602968516431900
>>> This addition would have many benefits, including:
>>> * More mapping. We have tons of new mappers each day, as well as a
>>> great editor for them. However, many of these new mappers leave
>>> after just a few edits. Examples:
>>> https://www.openstreetmap.org/user/lukastheg03
>>> 
>>> https://www.openstreetmap.org/user/Th3Roomi3
>>> ___
>>> 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] Proper use of route relations?

[Yves via talk]

Operator or network tags are often quoted for this kind of network. However I 
find it difficult not to wish for putting 'name=Boulder Valley Ranch Trails' 
somewhere, and a relation seems a good candidate.
  network:name=Boulder Valley Ranch Trails? But the network tag and its 
acronyms values make it quite technical at first sight.
Yves ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Proper use of route relations?

[Yves via talk]

Le 1 août 2020 22:08:17 GMT+02:00, Martin Koppenhoefer  
a écrit :
>
>
>sent from a phone
>
>> On 1. Aug 2020, at 20:48, Yves via talk  wrote:
>> 
>> This would be better joined in a site relation.
>
>
>why should it? What’s the benefit? How is this different to adding all roads 
>of a village into a site relation?
>

If the set of trail is at least well known under a name, why not?
In your counter example, a village probably has an administrative boundary of 
some sort, so I don't think we could add relevant information in doing so. 
Yves 

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

Re: [OSM-talk] Proper use of route relations?

[Yves via talk]

This would be better joined in a site relation.
Yves 

Le 1 août 2020 18:20:27 GMT+02:00, Mike Thompson  a écrit :
>I have come across a number of examples[0] of route relations where all the
>trails in a given park have been put into a single relation.  Is this a
>recommended use for route relations?
>
>Mike
>
>[0]
>https://www.openstreetmap.org/relation/10962561
>https://www.openstreetmap.org/relation/8409089

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Heresy - pure discussion

[Yves]

But face it, philosophy is now also part of the discussion. And that's 
important.
Yves 

Le 24 juillet 2020 20:50:22 GMT+02:00, john whelan  a 
écrit :
>If the database was smaller and less infrastructure was reliant on it
>working I would agree with you that philosophically open source software
>makes a lot of sense.
>
>However your argument is philosophical rather than logical.
>
>Note I'm merely requesting that the idea be examined.  I am not saying I
>know what is best and all the things that need to be considered.
>
>Cheerio John
>
>On Fri, Jul 24, 2020, 14:35 Yves  wrote:
>
>> You're probably have some very good points when it comes to database
>> management, but running an open map on open source software makes a lot of
>> sense.
>>
>> Yves
>>
>> Le 24 juillet 2020 20:11:46 GMT+02:00, john whelan 
>> a écrit :
>>>
>>> All this talk about databases and servers and sysadmins makes me wonder
>>> if we should reconsider our choice of operating systems and databases.
>>>
>>> At one time in the past I ran a Database support group that covered
>>> Sybase, Oracle, Microsoft SQL server, ingres and half a dozen other
>>> database systems.
>>>
>>> The UNIX side, some twenty or so servers ran software that in theory
>>> monitored the databases.  In practise it never really was upto date.
>>> Microsoft also had a very nice monitoring tool that monitored and suggested
>>> solutions.  I've dropped an example report below.
>>>
>>> We ran probably fifty SQL server database servers and I spent quite a lot
>>> of time maxing the memory on a server then consolidating servers.  Towards
>>> the end we had far more data running on SQL server than we did on the UNIX
>>> side.  The servers were cheaper for the same performance for a start.
>>>
>>> Many of the UNIX based servers had default passwords set which made
>>> security a problem.  Fortunately they were protected by an air gap from the
>>> Internet.
>>>
>>> We had an IBM mainframe in the mix with an old database on it.  The
>>> programmers gradually retired.  I was lucky and identified another
>>> government department that was switching away from it and we managed to
>>> grab a handful of programmers etc from them.  Then a couple of years later
>>> that DBA retired.  You need to think of the future.  Will I be able to get
>>> knowledgeable staff if I need to?  We had to pay the company to run a
>>> special course in Ottawa and that was not cheap by the time we put the
>>> trainer up in a hotel and paid his airfare from the states.
>>>
>>> Initially the Microsoft side suffered from lack of security but they
>>> hardened the operating system and SQL server to a point where it was the
>>> most secure combination.  Microsoft SQL server was originally Sybase but
>>> got completely rewritten over time.
>>>
>>> On the support side my staff found that once we had set the permissions
>>> to an operating system group we just had to add people to the group.  For
>>> other databases each person had to be given permissions individually which
>>> made for finger problems.  The classic was one secure database that was
>>> supposed to be accessed operationally by 300 people. The problem was there
>>> were 600 accounts and no one knew which ones were needed or which could be
>>> deleted to reduce the surface area for attack.
>>>
>>> The integrated Microsoft monitoring system made reliability much better.
>>> There were far fewer problems on the Microsoft SQL side than on the UNIX /
>>> other database side and they were easier to fix.  One of my less expert
>>> database admins was shocked by the ease of which he caught the problem and
>>> corrected it by himself after an alert.  It gave him a bit of confidence as
>>> well.
>>>
>>> We changed to PostgreSQL in 2009.  The size of the database was much
>>> smaller then.
>>>
>>> One thing we noticed was on the database tuning side.  SQL server worked
>>> better if you just left it alone and didn't try to tune it.  It would check
>>> what was in memory rather than go out to the disk drives and that made a
>>> big difference to performance.  We measure disk access in milliseconds and
>>> memory access in nanoseconds.  One is ten thousand times smaller than the
>>> other.
>>>
>>> On the reliability side there is a set of guidelines that are basically
>>> common sense.  I

Re: [OSM-talk] Heresy - pure discussion

[Yves]

You're probably have some very good points when it comes to database 
management, but running an open map on open source software makes a lot of 
sense.

Yves 

Le 24 juillet 2020 20:11:46 GMT+02:00, john whelan  a 
écrit :
>All this talk about databases and servers and sysadmins makes me wonder if
>we should reconsider our choice of operating systems and databases.
>
>At one time in the past I ran a Database support group that covered Sybase,
>Oracle, Microsoft SQL server, ingres and half a dozen other database
>systems.
>
>The UNIX side, some twenty or so servers ran software that in theory
>monitored the databases.  In practise it never really was upto date.
>Microsoft also had a very nice monitoring tool that monitored and suggested
>solutions.  I've dropped an example report below.
>
>We ran probably fifty SQL server database servers and I spent quite a lot
>of time maxing the memory on a server then consolidating servers.  Towards
>the end we had far more data running on SQL server than we did on the UNIX
>side.  The servers were cheaper for the same performance for a start.
>
>Many of the UNIX based servers had default passwords set which made
>security a problem.  Fortunately they were protected by an air gap from the
>Internet.
>
>We had an IBM mainframe in the mix with an old database on it.  The
>programmers gradually retired.  I was lucky and identified another
>government department that was switching away from it and we managed to
>grab a handful of programmers etc from them.  Then a couple of years later
>that DBA retired.  You need to think of the future.  Will I be able to get
>knowledgeable staff if I need to?  We had to pay the company to run a
>special course in Ottawa and that was not cheap by the time we put the
>trainer up in a hotel and paid his airfare from the states.
>
>Initially the Microsoft side suffered from lack of security but they
>hardened the operating system and SQL server to a point where it was the
>most secure combination.  Microsoft SQL server was originally Sybase but
>got completely rewritten over time.
>
>On the support side my staff found that once we had set the permissions to
>an operating system group we just had to add people to the group.  For
>other databases each person had to be given permissions individually which
>made for finger problems.  The classic was one secure database that was
>supposed to be accessed operationally by 300 people. The problem was there
>were 600 accounts and no one knew which ones were needed or which could be
>deleted to reduce the surface area for attack.
>
>The integrated Microsoft monitoring system made reliability much better.
>There were far fewer problems on the Microsoft SQL side than on the UNIX /
>other database side and they were easier to fix.  One of my less expert
>database admins was shocked by the ease of which he caught the problem and
>corrected it by himself after an alert.  It gave him a bit of confidence as
>well.
>
>We changed to PostgreSQL in 2009.  The size of the database was much
>smaller then.
>
>One thing we noticed was on the database tuning side.  SQL server worked
>better if you just left it alone and didn't try to tune it.  It would check
>what was in memory rather than go out to the disk drives and that made a
>big difference to performance.  We measure disk access in milliseconds and
>memory access in nanoseconds.  One is ten thousand times smaller than the
>other.
>
>On the reliability side there is a set of guidelines that are basically
>common sense.  I forget the formal (ISO?) name but many organisations have
>seen considerable savings in money and in reliability by using them.  I met
>the English guy who originated them at a Microsoft presentation.  They can
>be applied to any environment.
>
>I think we either run the largest PostgreSQL database there is or it is
>close to it.  From a reliability point of view my professional hat says
>this is not where you want to be. You want to be more mainstream with
>someone else being on the bleeding edge.
>
>So the heresy would be look at the implications of changing to Microsoft
>SQL server in the cloud.  There is lots of documentation and given that
>Microsoft has worked closely with us in the past the cost might not be too
>bad.  I do understand that we have a large investment in our current set up
>both as an organisation and personally and many will consider this as
>heresy but now is probably the time to think about it.
>
>Cheerio John
>
>
>
>
>
>
>
>
>
>Your message to rolland.desroc...@motioncares.ca couldn't be delivered.
>Rolland.desrocher wasn't found at motioncares.ca.
>jwhelan0112 Office 365 Rolland.desrocher
>*Action Required*
>Recipie

Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?

[Yves]

Le 12 juin 2020 14:14:15 GMT+02:00, Mateusz Konieczny via talk 
 a écrit :
>
>
>
>Jun 12, 2020, 13:59 by f...@zz.de:
>
>> Changeset envelopes which span more than 100s of km² are broken.
>>
>Except cases where you edit/delete already created huge objects or you
>create
>huge object that actually should be created.

The time to acknowledge the warning is small compared to the potential harm, so 
I guess you would not really bother.
Yves 

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

Re: [OSM-talk] Quality and the Openstreetmap value chain

[Yves]

Given that, at this time, we are thousands... 

Le 12 mai 2020 15:50:17 GMT+02:00, "Sören Reinecke via talk" 
 a écrit :
>___
>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] Let's talk Attribution

[Yves]

I was thinking of a, b, c,... as different use cases of attribution. 

Le 2 mai 2020 17:35:47 GMT+02:00, Mario Frasca  a écrit :
>On 02/05/2020 09:54, Yves wrote:
>> IMHO, a a/b/c/d kind of vote like for the last Article of Association
>change would be preferable to really have a more representative idea of
>the contributor feelings. Could the OSMF set up such a process?
>
>only related to the voting method, what method is used currently?  when
>
>you offer more than two options, and you want to choose one, there's 
>criteria to consider, and "first past the post" is a bad strategy.
>
>if you like reading things in latin, there's the original literature 
>/Ars notandi/, /Ars eleccionis/, and /Alia ars eleccionis/ by 
>https://en.wikipedia.org/wiki/Ramon_Llull/
>/
>
>I think this is a very clear example: 
>https://en.wikipedia.org/wiki/Condorcet_method#Example:_Voting_on_the_location_of_Tennessee's_capital
>
>and otherwise a more detailed description here:
>
>https://en.wikipedia.org/wiki/Schulze_method (this is used by Debian).
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Let's talk Attribution

[Yves]

Le 2 mai 2020 16:21:33 GMT+02:00, "Rory McCann (OSMF Board)" 
 a écrit :
>On 02.05.20 14:01, Yves wrote:
>> Could somebody enlight me about the new Attribution Guidelines
>process? 
>> How it is envisioned to adopt the document that is currently worked 
>> upon? A vote, a decision for the board, or else?
>
>The OSMF Board to vote on it/something, making it “The Attribution 
>Guidelines of the OSM Foundation”.
>
>Rory

IMHO, a a/b/c/d kind of vote like for the last Article of Association change 
would be preferable to really have a more representative idea of the 
contributor feelings. Could the OSMF set up such a process?
Some of the attributions cases are certainly simple enough to obtain a 
momentum, while others (multiple sources, small maps,...) are more complicated 
and could be subject to another round. 

Yves 

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

Re: [OSM-talk] Let's talk Attribution

[Yves]

With Christoph adding a counterpoint to the draft guideline from February, the 
LWG minutes evoking a topic about relicencing, I'm a bit lost.

Could somebody enlight me about the new Attribution Guidelines process? How it 
is envisioned to adopt the document that is currently worked upon? A vote, a 
decision for the board, or else? 

Wherever this goes, it takes time and we sure don't want the people thinking 
hard and putting work on the attribution guideline text to face the wall 
described by Christoph, this is why I wonder about the process. 

Also, what is this relicencing mentioned in the LWG minutes? 
Yves ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Changeset Governance [was: Announcing Daylight Map Distribution]

[Yves]

I always put survey+imagery in the last 3 cases. 
Yves 


Le 23 mars 2020 18:43:23 GMT+01:00, Greg Troxel  a écrit :
>> Subject: Re: [OSM-talk] Changeset Governance [was: Announcing
>Daylight Map Distribution]
>> From: Frederik Ramm 
>>
>>> Nothing against the idea but what happened to the good old source
>tag
>>> where source=survey would point to mappers on the ground, and
>>> source=XYZ
>>> aerial imagery would point to armchairing?
>
>I'm very sympathetic to knowing the on-ground-ness of a change.  But I
>think it's shades of gray.  This list illustrates what I mean:
>
>* armchair
>
>a place I have never been to, and which is so far away that I am not
>familiar with the customs.  An example would be me (US) editing in
>Africa.
>
>* country-armchair
>
>as above, but I know the country norms.  Me editing in Glacier National
>Park.
>
>* local-armchair
>
>as above, but I know the region norms.   If I edited some town in MA
>that I haven't visited (perhaps because I was going to visit), but I
>generally know how things are.
>
>* visited but mapping done by imagery
>
>Here, I am editing a place where I've been at some point reasonably
>recently and have some clue, but my edits are based on imagery.
>However, my recollection is good enough to avoid most of the armchair
>issues.   An example is me fixing up crosswalks and sidewalks two towns
>away, but not from field mapping notes.   I don't consider this
>armchair, but it's iffy.
>
>* editing soon after a visit
>
>I got someplace, maybe make notes, maybe remember, and edit based on
>some combination of imagery, gpx tracks, notes and memory.   I think
>this is squarely not armchair.
>
>* editing while there
>
>Actually using an editor while being in the place being edited.
>
>
>
>I would basically split this into three armchair and three not
>armchair.
>
>
>
>
>So basically I think source including imagery does not really imply
>"armchairing", in that the use of imagery is not the point, but a lack
>of familiarity with what's on the ground.  I almost always load and
>look
>at imagery when editing after being in the field.  I line up ways from
>imagery when that works, becuase I have come to believe from experience
>(with specific imagery sources) that this is more accurate than my gps
>tracks.
>
>(I have been experimenting with raw GPS data and post-processed PPP
>solutions, and those I think are close to good imagery.)
>
>
>
>
>___
>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] #AttributionIsNotOptional experiment on OSM France tile servers

[Yves]

If the terms of use is sufficiently clear, and a couple of warnings have been 
issued beforehand, then what can possibly happen? 
This is a rhetorical question. 
Yves 

Le 11 mars 2020 16:10:55 GMT+01:00, Simon Poole  a écrit :
>
>Am 11.03.2020 um 15:48 schrieb Mateusz Konieczny via talk:
>> Mar 11, 2020, 15:37 by si...@poole.ch:
>>
>> As I wrote (conveniently ignored in the noise of the vigilante
>> rampage): "
>>
>> I guess that people were irritated by describing gentle reminder
>about
>> license requirements
>> using pejorative terms ("deface") where their applicability was
>dubious.
>Sorry, but that is exactly the appropriate term, and anything that will
>inevitably get you on the wrong end of being sued if you do it often
>enough, is not a "gentle reminder".
>>
>> The safe, I admit also the less fun, option, is to simply block
>> access after giving any required notice."
>>
>> And note that in case of OSMF-served tiles no notice is required.
>>
>I'm not sure why you feel it necessary to tell me about terms that I'm
>completely aware off (and in some cases that I actually co-wrote), the
>subject matter in this thread is not -just- about the OSMF operated
>servers, but of those of OSM-FR and others.
>
>Simon
>
>> See https://operations.osmfoundation.org/policies/tiles/
>>
>> "Clearly display license attribution." is in explicit requirements,
>> and given overloaded servers
>>
>> "should any users or patterns of usage nevertheless cause problems to
>> the service, access may still be blocked without prior notice."
>>
>> applies anyway.
>>
>> "access may be withdrawn at any point" is later repeated.
>>
>>
>> ___
>> 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] #AttributionIsNotOptional experiment on OSM France tile servers

[Yves]

To me, the most important in attribution is to make potential contributors 
aware of the project. So the overlap is not that small in this regard. 

Yves 

Le 8 mars 2020 12:12:48 GMT+01:00, Simon Poole  a écrit :
>Just for the record:
>
>Enforcing attribution for services that you are providing directly (aka
>tiles in some form) only has a small overlap with the goals of the
>attribution guideline, and the avenues open to you depend on your ToUs
>/
>contracts with your users and the legal situation in the countries you
>are providing the service in.
>
>I would be very very wary of doing anything that deliberately defaces a
>web site without consulting with a local (to the country the web site
>is
>in) lawyer, particularly if the message implies wrong doing. The safe,
>I
>admit also the less fun, option, is to simply block access after giving
>any required notice.
>
>Simon 
>
>Am 08.03.2020 um 11:04 schrieb Yves:
>> This looks at first as a nuisance that could be perceived as a bad
>> move, but the feedback you're receiving rather prove the contrary.
>> Well done!
>> Ps: would you share your nginx partial redirect, I may consider it
>for
>> Opensnowmap tiles policy?
>>
>> Le 8 mars 2020 10:14:58 GMT+01:00, Christian Quest
>>  a écrit :
>>
>> Here is a hort report on this experiment...
>>
>> I started a week ago by searching OSM France tile server logs for
>> referer and checked manually if the map on the refering page was
>> correctly attributed.
>>
>> This allowed me to create a short list of 20 entries of sites
>> using the french styled tiles and the humanitarian tiles (yes, it
>> is made by OSM France).
>>
>>
>> I then modified our nginx based proxy_cache configuration, to
>> redirect some tiles to an "attribution tile" only for the domain
>> in the list.
>>
>> For two of them, I tweeted about it... the most visible one is
>the
>> moroco yellow page service, generating a little less than a
>> million daily tile requests on our servers.
>>
>> https://twitter.com/cq94/status/1234516075695525888
>>
>> In less than 24 hours, the attribution appeared and I removed
>them
>> from the list.
>>
>> https://twitter.com/cq94/status/1234779931537739776
>>
>>
>> Then I included an email address in the attribution reminder
>> tile... and got emails back within a few hours.
>>
>> Some were asking how to do the attribution, others telling me the
>> attribution was now ok and asking how to remove the reminder
>tiles.
>>
>> In my answers, I also remind that our tile service made by
>> volunteers on donated hardware is not unlimited and inviting them
>> to have a look at switch2osm to setup their own tile server or
>use
>> a commercial provider.
>>
>> Up to now, nobody complained :)
>>
>>
>> Yesterday, I've started automating attribution checking using
>> selenium. For each referer, a python script loads the page,
>> searches for tiles, then looks for attribution text or link. The
>> result is stored in a postgresql database which allows to group
>> referers by url, hostname and ip.
>>
>> The attribution percentage I currently see is around 70-80% which
>> is not that bad.
>>
>> My next major step is to use the same technique to remind about
>> tile usage policy...
>>
>>
>> To do something similar on osm.org, a first step is to extract
>> referers from the cache logs, then use the automated attribution
>> check to evaluate the situation.
>>
>>
>> Le 08/03/2020 à 01:52, Nuno Caldeira a écrit :
>>> That would be a good option for those that use third party
>>> providers of OSM. But to be honest, from my experience I highly
>>> doubt that even corporate members of OSMF, like Mapbox would do
>>> it, when their client Facebook (also corporate member of OSMF)
>>> after one year and half, still has maps with lack of attribution
>>> or attributed to HERE, when it's clearly OSM. 
>>>
>>> On Sun, 8 Mar 2020, 00:46 Phil Wyatt, >> <mailto:p...@wyatt-family.com>> wrote:
>>>
>>> I am sure others may have seen this 'blacklist'
>>> implementation for showing a reminder about attribution.
>>>
>>> https://twitter.com/cq94/status/1234528717604577282
>>>
>>> Worthy of consideration for openstreetmap.org
>>> <http://openstreetmap.org>?
>>>
>>> Cheers - Phil
>>>
>> -- 
>> Christian Quest - OpenStreetMap France
>>
>>
>> ___
>> 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] #AttributionIsNotOptional experiment on OSM France tile servers

[Yves]

This looks at first as a nuisance that could be perceived as a bad move, but 
the feedback you're receiving rather prove the contrary.
Well done!
Ps: would you share your nginx partial redirect, I may consider it for 
Opensnowmap tiles policy? 

Le 8 mars 2020 10:14:58 GMT+01:00, Christian Quest  a 
écrit :
>Here is a hort report on this experiment...
>
>I started a week ago by searching OSM France tile server logs for 
>referer and checked manually if the map on the refering page was 
>correctly attributed.
>
>This allowed me to create a short list of 20 entries of sites using the
>
>french styled tiles and the humanitarian tiles (yes, it is made by OSM 
>France).
>
>
>I then modified our nginx based proxy_cache configuration, to redirect 
>some tiles to an "attribution tile" only for the domain in the list.
>
>For two of them, I tweeted about it... the most visible one is the 
>moroco yellow page service, generating a little less than a million 
>daily tile requests on our servers.
>
>https://twitter.com/cq94/status/1234516075695525888
>
>In less than 24 hours, the attribution appeared and I removed them from
>
>the list.
>
>https://twitter.com/cq94/status/1234779931537739776
>
>
>Then I included an email address in the attribution reminder tile...
>and 
>got emails back within a few hours.
>
>Some were asking how to do the attribution, others telling me the 
>attribution was now ok and asking how to remove the reminder tiles.
>
>In my answers, I also remind that our tile service made by volunteers
>on 
>donated hardware is not unlimited and inviting them to have a look at 
>switch2osm to setup their own tile server or use a commercial provider.
>
>Up to now, nobody complained :)
>
>
>Yesterday, I've started automating attribution checking using selenium.
>
>For each referer, a python script loads the page, searches for tiles, 
>then looks for attribution text or link. The result is stored in a 
>postgresql database which allows to group referers by url, hostname and
>ip.
>
>The attribution percentage I currently see is around 70-80% which is
>not 
>that bad.
>
>My next major step is to use the same technique to remind about tile 
>usage policy...
>
>
>To do something similar on osm.org, a first step is to extract referers
>
>from the cache logs, then use the automated attribution check to 
>evaluate the situation.
>
>
>Le 08/03/2020 à 01:52, Nuno Caldeira a écrit :
>> That would be a good option for those that use third party providers 
>> of OSM. But to be honest, from my experience I highly doubt that even
>
>> corporate members of OSMF, like Mapbox would do it, when their client
>
>> Facebook (also corporate member of OSMF) after one year and half, 
>> still has maps with lack of attribution or attributed to HERE, when 
>> it's clearly OSM.
>>
>> On Sun, 8 Mar 2020, 00:46 Phil Wyatt, > > wrote:
>>
>> I am sure others may have seen this 'blacklist' implementation
>for
>> showing a reminder about attribution.
>>
>> https://twitter.com/cq94/status/1234528717604577282
>>
>> Worthy of consideration for openstreetmap.org
>> ?
>>
>> Cheers - Phil
>>
>-- 
>Christian Quest - OpenStreetMap France
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Yves]

I think one should not put a particular separator in the tag in the hope to 
have a label drawn as such on a map.
If a separator like ; is used, it's easy enough for the renderer to concatenate 
values with a '-' , a ' ', write each name on a separate line or whatever.
Otherwise, don't use a 'name' tag, but rather a 'label' tag, the intent will be 
more clear.
Yves 

Le 29 février 2020 14:03:36 GMT+01:00, Jo  a écrit :
>'-' might be used in the name itself, ' - ' never will be. I think
>readability is better with ' - ' than with ' / ', but I guess it's a
>matter
>of taste.
>
>Jo
>
>On Sat, Feb 29, 2020 at 1:46 PM Yves  wrote:
>
>> The wiki description is clear enough:
>> name: in general, the most prominent signposted name or the most
>common
>> name in the local language(s)
>>
>> No plural is used, and for a point in the middle of the sea, one may
>have
>> a hard time to find locals.
>> I'd say that puri-lingual name(s) with a separator makes sense, but
>in
>> another tag. That way, people using the data hoping that the name tag
>> follows the definition won't be misleaded.
>> In the absence of the tag name, they can use whatever fallback they
>choose
>> to. Be it name:xx or this new tag for several bordering languages.
>> And yes, the complete absence of the name tag does not bother me at
>all.
>> Yves
>> ___
>> 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] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

[Yves]

The wiki description is clear enough:
name: in general, the most prominent signposted name or the most common name in 
the local language(s)

No plural is used, and for a point in the middle of the sea, one may have a 
hard time to find locals.
I'd say that puri-lingual name(s) with a separator makes sense, but in another 
tag. That way, people using the data hoping that the name tag follows the 
definition won't be misleaded.
In the absence of the tag name, they can use whatever fallback they choose to. 
Be it name:xx or this new tag for several bordering languages.
And yes, the complete absence of the name tag does not bother me at all. 
Yves 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Yves]

I think that getting rid of the name tag in those cases is the best way to 
avoid breaking things on the data consumers side, as clever consumers already 
using name:xx would not be affected, and those relying on a name tag to display 
local language wouldn't be mistaken.
Yves 

Le 26 février 2020 13:23:31 GMT+01:00, Frederik Ramm  a 
écrit :
>Hi,
>
>On 26.02.20 13:13, Maarten Deen wrote:
>> Will it be nothing in the name tag and are we then going to complain
>> that the opencarto style falls back to name:en?
>
>Increasingly, I think the absence of a name tag wouldn't even be
>noticed. JOSM already shows the name tags in the editing user's
>language; other editors might do that too. If a fallback to name:en
>were
>added to OSM Carto (or more precisely, a fallback to a configurable
>language which would be configured to be English on openstreetmap.org)
>then you could probably remove the name tag from oceans with hardly
>anyone noticing a change.
>
>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
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Yves]

Florimond is right, putting anything in the name tag that is not in the local 
language is wrong and one should not expect data consumers to detect it.
Name:xx is the only way to go for international places.
Yves 

Le 26 février 2020 12:34:04 GMT+01:00, Florimond Berthoux 
 a écrit :
> The problem is not the OSM "default" (there is no default) map.
>OSM is *not* a map !
>The problem is the data put in name tag of some objects, which are not
>respectful with the international idea of the project.
>
>Le mar. 25 févr. 2020 à 22:57, Mario Frasca  a écrit :
>
>> I'm afraid that the conclusion you summarize here is not at all
>reached.
>>
>> we have reached the conclusion on the pointless point: "we discuss in
>> English".
>>
>> as for the values of the `name` tag:
>>
>> I prefer to see "Adriatic Sea" rather than nothing.
>>
>> I prefer "Mare Adriatico" to "Adriatic Sea".
>>
>> I definitely question the choice of the editor who wrote "Gulf of
>Trieste"
>> for a piece of sea that borders with Italy (in an area where Friuls
>is a
>> recognized language), and Slovenia.
>>
>> and I have suggested that the problem would vaporize if we added a
>> language identifier to the tile request.
>>
>> I'm very much interested in reading reactions to this.
>>
>> MF
>> On 25/02/2020 16:10, Tomek wrote:
>>
>> W dniu 20-02-25 o 21:52, stevea pisze:
>>
>> I believe I speak for many, most, or even all of us here (except
>Tomek) that "this is a settled matter."
>> SteveA
>>
>>
>> Sprawa rozwiązana, każdy mówi w jakim języku chce, a znacznik “name”
>z
>> obiektów międzynarodowych zostanie usunięty, z wyjątkiem mórz
>> graniczących z państwami.
>> Dziękuję za dyskusję
>>
>> La problemo estas solvita, ĉiu povas paroli en iu ajn lingvo; kaj la
>> etikedo “name” el internaciaj objektoj estos forigita, escepte de
>maroj
>> apudaj al landoj.
>> Dankon por diskuto
>>
>> The problem is solved, everyone can speak in any language; and the
>tag
>> “name” from international objects will be deleted, except of seas
>> adjacent to the countries.
>> Thank you for discussion
>>
>>
>> ___
>> talk mailing
>listtalk@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
>
>-- 
>Florimond Berthoux
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Yves]

This discussion is hopeless, and 90% off topic.
The only outcome of discussing languages here is that the status quo of using 
an English name for oceans remains. Given the amount of words spent off of this 
matter, this status quo is slowly reaching consensus, keep on!
Yves ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Is there some existing detailed tutorial directed at complete newbies? Describing how to add various features?

[Yves]

I tried to do that from a corner case: begginer guide for cross-country skier:
http://www.opensnowmap.org/iframes/how-to-fra.html
It reminds me I still have to translate it in English.
This is not exactly what you are looking for, but it can give some ideas.
Yves 

Le 22 février 2020 09:23:35 GMT+01:00, Mateusz Konieczny via talk 
 a écrit :
>
>
>
>22 Feb 2020, 08:09 by r...@technomancy.org:
>
>> Isn't this the job of the editing software (incl it's presets)? If
>there's a search box and the user can type in (eg) "path" and draw the
>path, then that's how you teach newbies? 
>>
>Yes, but complete newbie needs to
>be taught this steps.
>
>It is not obvious.
>
>And for mobile editing one needs 
>instructions for Vespucci that is a bit
>less obvious.
>>
>> Has this user tried to use iD (the best new user friendly editor
>today) to do this? Does that do the job? If not, I'm sure everyone,
>incl id devs, would like to know. 🙂 
>>
>No, he was unaware that it can be done this way and that it is
>relatively simple.
>(I hope that it is relatively simple)
>>
>> On 22 February 2020 05:37:13 CET, Mateusz Konieczny via talk
> wrote:
>>
>>> Is there some automatically generated website 
>>> describing in excruciating detail how to map various features?
>>>
>>> Something directed to a potential mappers, 
>>> explicitly describing every single smallest step,
>>> for every single mappable feature.
>>>
>>> I ask as I had again a friend asking me 
>>> "how to add aconstruction area/path/... to OSM".
>>>
>>> And it seems to me that automatically generated 
>>> set of such tutorials is both feasible and potentially useful.
>>>
>>
>> -- 
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Attribution guideline update

[Yves]

For the sake of the discussion about 'small map' size, a mockup on the wiki 
would certainly help.
The 500dpi and 25% size seems quite big to me, there's room for (c) 
Openstreetmap there.
Yves Cainaud ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] For the sake of peace | Re: Cease use of OpenStreetMap/Antifa logo

[Yves]

Le 17 février 2020 23:10:55 GMT+01:00, Simon Poole  a écrit 
>misusing the OpenStreetMap brand and marks by so
>many other organisations with the goal of  profiting from OSMs
>popularity.

... or worse, not using the brand at all on their maps for the same goal! 
Yves 
 

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

Re: [OSM-talk] Forests are mappable - was: Re: OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Yves]

While I second Mateusz, the obvious solution for data users who may want to get 
rid of them in OSM is to filter them out.
Yves ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] weeklyOSM #497 2020-01-21-2020-01-27

[Yves]

While keeping a planet file up to date is really easy, it is probably not the 
first idea that comes to mind when you first plan to do something with the data.
This service looks like a good idea, but filtering abusers must be kept in mind 
anyway.
Yves ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Tag:man_made=embankment

[Yves]

You should have read "right side of way" : it's the side on your right when you 
follow the way in its direction.
Yves 

Le 15 janvier 2020 17:59:42 GMT+01:00, Paul Johnson  a 
écrit :
>On Wed, Jan 15, 2020 at 10:28 AM 80hnhtv4agou--- via talk <
>talk@openstreetmap.org> wrote:
>
>> What does this mean ?
>>
>> “should be tagged on a way drawn with the *lower side on right side*
>of
>> way direction”
>>
>
>The downhill side of the embankment is to the right of the way.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Proposal process Wikipage - Adding note about the use of seperators for values

[Yves]

The semicolon is one information out of many, I'm not sure we should add this 
in the already long 'proposal process' page.
Especially considering that semicolons are discouraged but we do use them, this 
is not ideal for clarity. 

Le 4 décembre 2019 17:35:57 GMT+01:00, "Sören Reinecke via talk" 
 a écrit :
>___
>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] Addressing SIG

[Yves]

Wait,. .. when was the 'noname' layer gone?
Yves

Le 7 novembre 2019 08:06:27 GMT+01:00, Christian Quest 
 a écrit :
>We've been "addressing the address topic" for more than 5 years in
>France
>with our BANO project.
>
>Here is an overlay I created back then to show existing and missing
>address
>data in OSM compared to available OSM compatible sources.
>
>http://osm13.openstreetmap.fr/~cquest/leaflet/bano.html#16/48.7908/2.6542
>
>Green: the address is in OSM (and the named road too)
>Blue: address is missing but the road name exist in OSM
>Red: address missing and we found no road with that name nearby
>
>If you want to make missing data obvious, you should no dimm the
>shapes,
>but make them highly visible.
>The goal with the above rendering became "dégommer du rouge" (get rid
>of
>red).
>
>
>Le mar. 5 nov. 2019 à 19:43, Steve Coast  a écrit
>:
>
>> Hello
>>
>>
>>
>> Maps have three basic components: Display (does it look nice?),
>Routing
>> (Can I get from a to b?) and Geocoding (Where is this address?).
>>
>>
>>
>> OSM is extremely good at the first one, and pretty good at the second
>one.
>> But it’s pretty deficient in the third area: address data.
>>
>>
>>
>> The question is, how can we fix this? Addresses are a big, big
>problem in
>> terms of how much data we need to go collect. There are a few ways
>forward
>> with outside commercial or government data, but they tend to be
>difficult
>> because the data is patchy or licensed in ways that aren’t very
>compatible
>> with OSM.
>>
>>
>>
>> It seems like it would be a good idea to think about this from the
>bottom
>> up in a community way, and this doesn’t really exist in OSM right
>now. It
>> seems like we need better feedback loops to:
>>
>>
>>
>>1. Community can see where the address data is (and isn’t),
>because
>>it’s not very obvious today when using osm.org
>>2. Make the tools to add address data better so that it’s easier
>to
>>fix.
>>
>>
>>
>> To that end, here’s a tile server that highlights address data:
>>
>>
>>
>>
>>
>http://ec2-52-50-19-165.eu-west-1.compute.amazonaws.com/#10/39.7561/-104.9574
>>
>>
>>
>> It shows roads with address data normally and kind-of hides other
>roads,
>> to make it obvious that “something is wrong with this map”. We could
>have a
>> tag (maybe it exists already) that says “this road doesn’t have
>addresses”
>> and/or a tag that says “this road is complete”. (right now it’s just
>got
>> Colorado and Utah in it).
>>
>>
>>
>> When OSM started, the map looked very broken and incomplete because
>there
>> was missing data all over the place. This created a large incentive
>to go
>> fix the map. The idea with this tileserver is to do the same thing
>and make
>> the map look broken to create a large incentive to fix it. If we, one
>day,
>> switched the main osm.org site to using this rendering then it would
>> create an urgent need to find all the addresses in the places where
>they
>> exist. It could also be done on a temporary basis for a few weeks, or
>on a
>> per-country basis or some other slow introduction to see if it
>worked. It’s
>> just an idea.
>>
>>
>>
>> On the tools side, there’s much that can be done to make collecting
>and
>> entering addresses easier. I’ve been collecting UI/UX changes to
>tools
>> (e.g. iD or Go Map!) that would make addresses better:
>>
>>
>>
>> https://wiki.openstreetmap.org/wiki/Address_SIG
>>
>>
>>
>> It also seems worthwhile to create a group of people interested in
>> addressing in OSM (an address special interest group or working
>group) to
>> push these ideas forward so that we can “finish” OSM by getting all
>the
>> addresses done.
>>
>>
>>
>> What do you think?
>>
>>
>>
>> Best
>>
>>
>>
>> Steve
>>
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
>
>-- 
>Christian Quest - OpenStreetMap France
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Osmf-talk] Attribution guideline status update

[Yves]

To be complete, ABC warns XYZ about its obligations toward attribution in a 
page like this one:
https://docs.mapbox.com/vector-tiles/reference/mapbox-streets-v8/#data-sources--updates
Yves ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] MS GitHub? | Re: Tagging Governance

[Yves]

Le 13 septembre 2019 11:33:10 GMT+02:00, Eugene Alvin Villar  
a écrit :

>it's
>not as if we are introducing a markup language that is unknown for the
>experienced OSM user.

It's not as if we introduce anything: the subject is about if and how we could 
establish a process to better document tagging and tagging governance. 
The syntax comes later, this markup language digression is distracting. 
Yves 

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

Re: [OSM-talk] Abuse of natural=cliff tag

[Yves]

Vladimir, I see around https://www.openstreetmap.org/#map=15/50.9610/14.0724 an 
incredible work of micromapping, it can also look ugly in other context.
But OSM is glad to have climbing enthusiast in its ranks too! 
Probably worth opening an issue at 
https://github.com/gravitystorm/openstreetmap-carto the cliff pattern really 
looks messy.
Yves 

Le 11 septembre 2019 19:26:42 GMT+02:00, Vladimir Vyskocil 
 a écrit :
>Hi ! 
>
>> On 11 Sep 2019, at 15:33, Vladimir Vyskocil
> wrote:
>> 
>> A even crazier area regarding the abuse of the cliff tag ! 
>> 
>> https://www.openstreetmap.org/#map=15/50.9610/14.0724
><https://www.openstreetmap.org/#map=15/50.9610/14.0724>
>What I see there is far from reasonable and far for common sens, it is
>just wrong and mad...
>All this bad information about cliffs in that area ie what common sens
>think is a real cliff and what is explained in the openstreetmap wiki
>page about this tag impact the usability of the data and I even don’t
>talk about the rendering, we are not tagging for the renderer but we
>easily could see that this tag was not designed for this mess !
>
>Now have a look please at the Grand Canyon in USA, for example :
>
>https://www.openstreetmap.org/#map=14/36.0765/-112.1345
><https://www.openstreetmap.org/#map=14/36.0765/-112.1345>
>
>This is useful information ! How do you think It had looked if every
>little stones or slopes were mapped as a cliff like it is in the area
>we are talking about ?
>
>Vladimir.
>
>> 
>> Vladimir.
>> 
>>> Le 11 sept. 2019 à 15:27, Vladimir Vyskocil
>mailto:vladimir.vysko...@gmail.com>> a
>écrit :
>>> 
>>> Hello Sarah,
>>> 
>>> I read carefully your response and looked at the picture. I didn't
>travelled exactly at this place but will go there in October ! However
>I've already been in Český ráj
><http://www.cesky-raj.info/en/contacts/bohemian-paradise-association/>
>that is not too far from there and where the terrain is similar in many
>aspects.
>>> I still think that the usage of the tag is abused in this area…
>>> You may read the description of this tag here :
>>> 
>>> https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcliff
><https://wiki.openstreetmap.org/wiki/Tag:natural=cliff>
>>> 
>>> «  A cliff <http://en.wikipedia.org/wiki/en:cliff> is a vertical or
>almost vertical natural drop in terrain topography as it occurs for
>example in form of coastal cliffs or escarpments. The face of the cliff
>usually consists of bare solid rock but can occasionally also consist
>of clay, compacted sand, ice or other solid materials.» 
>>> 
>>> 
>>> « 
>>> When not to use
>>> natural <https://wiki.openstreetmap.org/wiki/Key:natural>=cliff <>
>should not be used for ridges, i.e. crests where there is a significant
>drop in terrain to both sides and neither of them is close to vertical.
>Use natural <https://wiki.openstreetmap.org/wiki/Key:natural>=ridge
><https://wiki.openstreetmap.org/wiki/Tag:natural%3Dridge> or natural
><https://wiki.openstreetmap.org/wiki/Key:natural>=arete
><https://wiki.openstreetmap.org/wiki/Tag:natural%3Darete> instead. Also
>do not usenatural
><https://wiki.openstreetmap.org/wiki/Key:natural>=cliff <> just for
>mapping an inclined bare rock surface, use natural
><https://wiki.openstreetmap.org/wiki/Key:natural>=bare_rock
><https://wiki.openstreetmap.org/wiki/Tag:natural%3Dbare_rock> instead.
>>> 
>>> " 
>>> 
>>> This is not what I see when I look at this mapped area, I agree that
>some mapped cliffs here are really what should be considered a cliff
>but they are lost in lots of wrongly mapped and not relevant ones. 
>>> 
>>> You might look at this as a example in many many more :
>>> 
>>> https://www.openstreetmap.org/#map=19/50.89893/14.28319
><https://www.openstreetmap.org/#map=19/50.89893/14.28319>
>>> 
>>> We are seeing it at level 19 and the density of cliffs is still
>crazy ! 
>>> 
>>> Or here : https://www.openstreetmap.org/#map=15/50.8791/14.3647
><https://www.openstreetmap.org/#map=15/50.8791/14.3647>
>>> 
>>> Could you tell me that all theses mapped cliffs really exists ? Or
>aren’t they just « a significant drop in terrain and neither of them
>are close to vertical » mapped as cliffs only looking at terrain model
>and that are completely disconnected from the reality of the terrain ?
>>> 
>>> Regards,
>>> Vladimir
>>> 
>>> 
>>> 
>>>> Le 11 

Re: [OSM-talk] [Osmf-talk] Attribution guideline status update

[Yves]

How about:
You display OSM data, you attribute, and you attribute on the map view.

If that's what we want, I would be OK for a short attribution like (c)OSM&co. 

Yves 

Le 8 septembre 2019 19:39:55 GMT+02:00, Christoph Hormann  a 
écrit :
>On Sunday 08 September 2019, Simon Poole wrote:
>>
>> /If OpenStreetMap is not the largest data provider for the visible
>> map rendering, attribution with other sources on a separate page that
>> is visible after user interaction is acceptable./
>>
>> [...]
>
>For understanding the practical function of such a rule (and the
>efforts 
>necessary to circumvent it of course) - how do you measure the fraction
>
>OSM accounts for as data provider for a map, especially if several 
>different data types are involved.  If you go by data volume (which can
>
>be easily changed by several orders of magnitude through geometry 
>compression and expansion methods of course) i would probably say i 
>have never seen a map with relief depiction (like shading or countour 
>lines) where the majority of the data is from OSM.  Any satellite image
>
>layer with annotation labels and lines (boundaries, roads etc.) from 
>OSM would equally be exempt from visible attribution under such rule.
>
>Practically i think everyone should be aware that such rule is a clear 
>invitation how to avoid the need for attribution for map producers.  I 
>would go as far as saying that no matter how you answer my question as 
>to how data fractions are measured any map could be easily modified by 
>adding sufficient other data to get the OSM fraction below the 50 
>percent limit and this way get off the hook.
>
>As already said i don't see how such a recommendation could in any way 
>be considered compatible with the ODbL attribution requirements.
>
>-- 
>Christoph Hormann
>http://www.imagico.de/
>
>___
>talk mailing list
>talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Carto release v4.22.0

[Yves]

Oleksiy,
Those two changes are indeed very technical and are not related to mapping.
https://postgis.net/docs/ST_PointOnSurface.html

https://github.com/gravitystorm/openstreetmap-carto/issues/3756

Yves

Le 28 août 2019 08:13:13 GMT+02:00, Oleksiy Muzalyev 
 a écrit :
>Good morning,
>
>Thank you for the information.
>
>I did not understand these two changes. I would like to see an example 
>on the map or/and read a wiki article about the building label, the
>shop 
>label, and the ST_PointOnSurface.
>
>In the two following articles:
>
>https://wiki.openstreetmap.org/wiki/Key:shop
>https://wiki.openstreetmap.org/wiki/Shops
>https://wiki.openstreetmap.org/wiki/Key:building
>
>there is neither word "label", nor "ST_PointOnSurface". I would like to
>
>learn about it and, probably, use it.
>
>As for layers with attachments, - I guess it does not concern mapping 
>itself, but it's something related to a technical side of rendering. 
>Probably, a layer has got some PNG image files, which are used in icons
>
>or displaying certain areas, and they will be cached in the visitors' 
>browsers.
>
>Best regards,
>Oleksiy (Alex-7 @ OSM)
>
>On 8/28/19 06:57, Paul Norman via talk wrote:
>>
>> Changes include
>>
>> - Shop label fixes and use ST_PointOnSurface for building label
>placement
>>
>>   This fixes some bugs and makes building label placement consistent 
>> with shop
>>   label placement.
>>
>> - Use `cache-feature: true` to improve performance of layers with 
>> attachments
>> ...
>
>
>___
>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] sending location from a smart phone.

[Yves]

This does exist, of course, ans open source:
https://play.google.com/store/apps/details?id=ru.perm.trubnikov.gps2sms&hl=en_US&referrer=utm_source%3Dgoogle%26utm_medium%3Dorganic%26utm_term%3Dgps+to+sms&pcampaignid=APPU_1_meRYXYf3HYqJrwSTj73oDQ


Le 18 août 2019 05:26:02 GMT+02:00, stevea  a écrit :
>This feels like an interesting side project for OSM to keep its hands
>warm, rubbing over the campfire, ready to toss in a shoulder of help if
>needed.  Warin (below) says "a few years" yet I think with some good
>communication, coordination among countries, 112 / E911 / 999
>communities, mutual aid / volunteer fire departments, writers / coders
>of iOS and Android apps, this could really turn into something
>reasonably effective in a year or less.  A 1.0 that works worldwide and
>is extensible to any country (depending on phone / cellular / G3-G4-G5
>tech, whether the call center can handle SMS, whether the helicopter
>pilot and rescue team have data delivery systems that show them a map
>or visually / aurally read a string of lat-lon digits — not helpful, a
>visual map is usually immediately human-parsable) seems quite feasible
>to me.
>
>By 2020.  Nice discussion.  Thank you for introducing the topic, John. 
>May it continue and blossom.
>
>SteveA
>
>> On Aug 17, 2019, at 8:19 PM, Warin <61sundow...@gmail.com> wrote:
>> 
>> On the SMS front, it is not a question of an app but the receiving
>organisation
>> 
>> Internationally 112 is the single number that is allocated to
>emergency services from cell phones.
>> In some countries that gets you a call centre that then sends you off
>to the police, fire or ambulance. in other countries you may end up
>with only the police.
>> 
>> Having them all contactable by SMS would be nice... but I don't think
>it is going to work world wide for many years.
>
>
>___
>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] Using OSM as database for nature park hiking routes?

[Yves]

If these routes are endorsed in any way by a nature park, they're no longer 
completely informal or subjective...
Yves 

Le 14 août 2019 05:19:56 GMT+02:00, Andrew Harvey  a 
écrit :
>The hiking routes
>https://wiki.openstreetmap.org/wiki/Hiking#Tagging_walking_and_hiking_Route_Networks
>added
>to OSM should be verifiable
>https://wiki.openstreetmap.org/wiki/Verifiability.
>
>Talking from my experience, there are a lot of hiking paths, but only
>some
>are signposted routes, so only some can be actual routes in OSM.
>Because of
>that you would need to maintain all the other informal or subjective
>routes
>outside OSM, if there are any.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Attribution guideline status update

[Yves]

Hi Simon,
This guideline is a great piece of work, thanks a lot to all the participants.
Inevitably, this will be too much or not enough for anybody, however I find the 
content reasonable and in line with what I understood from current written 
expectations.
A few more mockups, notably for minimaps and apps would be great.
After all the text is clear enough and I would find the "yes, but we want to 
let the designer some freedom" argument a bit hypocritical.
Yves 

Le 9 août 2019 09:41:25 GMT+02:00, Simon Poole  a écrit :
>As we've mentioned multiple times over the last months, the LWG decided
>last year to consolidate all attribution guidance in to one document
>and
>address some of the use cases that have become common over the last 7
>years that previously had none. Particularly in the light of the
>parallel discussions about attribution on larger social media platforms
>we need to make up our minds what we actually want, and define concrete
>minimum requirements for acceptable attribution. To not do this just
>provides the excuse of pointing to the cacophony of voices all saying
>something different. 
>
>We've been working on and off on the document for a while, and are now
>largely finished. Going forward we intend to wikify the document and
>make it available for public comment together with a BoF session at
>SotM
>next month (which probably means that we'll have to appropriate a
>coffee
>break). You can have a glimpse at the text here
>https://docs.google.com/document/d/1e_IQYHtqVivGRw4O4EOn6__-LGMuzPlWz6XKEdAkwW0/edit?usp=sharing
>the few things that are not nailed down belong to those that we would
>appreciate feedback on.
>
>Simon
>
>PS: the number of coffee breaks permitting we might want to appropriate
>another one for the discussion of a tile licence change.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Facebook mapping highways using AI in collaboration with OpenStreetMap

[Yves]

John, Kathleen, thank you for this perspective I did not have.
Yves 

Le 29 juillet 2019 19:25:34 GMT+02:00, john whelan  a 
écrit :
>I agree with Kathleen.  Given that smartphones are more common than
>internet connected computers and it is easier to add or change tags on
>a
>smartphone than add a long highway at least the locals stand more
>chance
>this way.
>
>Cheerio John
>
>On Mon, Jul 29, 2019, 1:00 PM Kathleen Lu via talk,
>
>wrote:
>
>> On the other hand, if the map of your area is completely blank, it
>looks
>> very daunting to a new mapper, who may be discouraged and abandon OSM
>> (either as too difficult to improve and as too poor quality to use).
>> The map is constantly changing because roads and other things on the
>map
>> are changing in the real world. A city might close off a road and
>then it
>> will become a "bad" street. It's easier to delete a bad street than
>to add
>> a bunch of streets, especially when you are surveying on foot and
>don't
>> have a mouse.
>> I personally would much rather have a 101% map than a 1% map.
>>
>> On Mon, Jul 29, 2019 at 9:21 AM Joseph Eisenberg <
>> joseph.eisenb...@gmail.com> wrote:
>>
>>> Re: "OSM map with a one percent of roads is far worse than having
>101%
>>> of the roads mapped with the help of AI with 1% of extras, because
>>> fixing that 1% is far less work than adding 99% by hand"
>>>
>>> I'm not certain this is true. It might be very difficult to find the
>>> 1% of incorrectly mapped roads; you don't know where to look, and
>you
>>> must survey on the ground with GPS, and check each road segment to
>>> find the 1% that actually are blocked by a fence or gate or don't
>>> really go through that clump of trees.
>>>
>>> In contrast, when 99% are missing it's very obvious when looking at
>>> the map data. You still have to survey and add the streets, but it
>may
>>> actually be faster to get to a complete map of your home
>neighborhood,
>>> than trying to find 10 bad streets out of 1000 segments in your
>>> neighborhood.
>>>
>>> Finally, when you look at the map and it looks 100% complete, you
>>> won't see the need to start mapping and become a totally addicted
>>> OSMer like you will if your village is only 1% mapped, so we may not
>>> get the new contributors that we need to actual maintain the data
>that
>>> our robot mappers have added.
>>>
>>> Joseph
>>>
>>> ___
>>> 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] Facebook mapping highways using AI in collaboration with OpenStreetMap

[Yves]

No need to argue that much about it:
I think everyone will agree that we should not, at any case, add a track in OSM 
that doesn't exist.
It can be dangerous in any emergency situation anywhere in the world.
Yves ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Reordering and rewriting Good Practice wiki page

[Yves]

Hmm... I would be all in favor of extending the See also... section and shorten 
drastically the page to keep it simple.
Some of the good practices there are second order, don't you think?
Keeping history compared to Tag for the renderer, for example.
Yves 

Le 4 juillet 2019 05:53:23 GMT+02:00, Joseph Eisenberg 
 a écrit :
>I've reordered and reworded several sections of the Good practice
>page: https://wiki.openstreetmap.org/wiki/Good_practice
>
>The page had grown over the years from 6 or 7 initial sections:
>(First verion of page in 2008
>https://wiki.openstreetmap.org/w/index.php?title=Good_practice&oldid=86242)
>
>1) Don't map for the renderer
>2) One feature, one OSM-object
>3) Keep straight ways straight
>4) Map what's on the ground
>5)a) Don't remove tags you don't understand
>   b) Document your custom-tags
>6) Do correct errors
>
>Now there were 22 different sections, several added this past year
>without discussion, and they were not organized:
>https://wiki.openstreetmap.org/w/index.php?title=Good_practice&oldid=1861565
>
>I've reordered and categorized these sections under 7 main headings:
>
>1  Do correct errors
>2  Verifiability (+Map what's on the ground, Don't map: historic
>events, temporary features, local legislation etc)
>3  Don't map for the renderer (+ Don't misuse name tag)
>4  Good changeset comments (+Keep the history)
>5  One feature, one OSM element
>6  Editing Standards: (Align aerial imagery before tracing, Do not
>trace from outdated imagery... Keep straight ways straight ... Mark
>estimations with FIXME ... etc.)
>7  Document your custom-tags (Don't remove tags that you don't
>understand...
>
>I've made some wording changes for more consistent and concise style,
>and removed some examples (eg abandoned railways)
>
>I've removed 2 sections added in the past year:
>
>"Don't map insignificant, perishable and mobile objects"
>- this section duplicated information in the exiting heading about
>temporary features
>
>"Don't censor anything existing in reality for any reason. Avoid
>interpolations if there is sufficient imagery."
>- This seems redundant and the part about censoring data isn't
>completely correct. We don't add personal info about who lives in a
>private house, for example.
>
>While I haven't done this yet, I would also recommend moving the long
>details about "Keep the history", involving how to use specific
>editors and checking history in certain editors, along with the
>section "Check the history of important objects" which duplicates
>advice in the Aerial Imagery section, to a new page, with a link:
>https://wiki.openstreetmap.org/wiki/Keep_the_history
>
>Joseph Eisenberg, User:Jeisenbe
>
>___
>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] landuse=reservoir vs water=reservoir

[Yves]

Don't worry about data consumers, they have a long habit of using concurrent 
tagging schemes and make extensive use of 'OR'.
Yves 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Proposed mechanical edit - remove blatant duplicates (sustenance=fast_food on amenity=fast_food, atm=yes on amenity=atm etc.)

[Yves]

It isn't worth it, I'm afraid you're loosing your time. 
Given that the two tags aren't the same (amenity=atm is an atm, atm=yes 
contains an atm) you'll soon have this one art piece that definitely deserves 
amenity=atm + atm=no. Or not.
If you're not ready to consume OSM data using NOT, AND or OR, don't even start 
:)
Not to say that OSM should be a joyful mess, but to me such apparent redundancy 
does no harm. A matter of point of view on the best way to describe the same 
things, that's all. 
Yves 

Le 14 juin 2019 08:57:22 GMT+02:00, Mateusz Konieczny  
a écrit :
>Recently in mapping I encountered amenity=atm with atm=yes
>
>I manually removed atm=yes, but it turns that there is more of such
>objects.
>I propose to run an automatic edit that will remove atm=yes from all
>such objects.
>In addition I propose to remove also some other blatant and unnecessary
>duplicates.
>
>So in total I propose to remove
>
>atm=yes from amenity=atm http://overpass-turbo.eu/s/JW8
><http://overpass-turbo.eu/s/JW8>
>transportation=fuel from amenity=fuel http://overpass-turbo.eu/s/JWe
><http://overpass-turbo.eu/s/JWe>
>sustenance=restaurant from amenity=restaurant
>http://overpass-turbo.eu/s/JWh
>sustenance=fast_food from amenity=fast_food
>http://overpass-turbo.eu/s/JWc
>service=post_office from amenity=post_office
>http://overpass-turbo.eu/s/JWa <http://overpass-turbo.eu/s/JWa>
>
>as this duplicated tags are unnecessary, unwanted, confusing and
>undesirable.
>Edits would be split to not create overly large bounding boxes.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Terminate Facebook rights under ODbL

[Yves]

I had to read the 2013 (wow!) thread again. '(c)OSM' on small devices would 
have legal issues as well, I guess, but maybe not as many.
Anyway, speaking of legal issues, I don't think this is like if we ever took a 
lot of legal actions concerning attribution...
Yves 

Le 10 juin 2019 21:56:14 GMT+02:00, Simon Poole  a écrit :
>
>Am 10.06.2019 um 21:05 schrieb Jean-Marc Liotier:
>> On 6/10/19 5:28 PM, Eugene Alvin Villar wrote:
>>> On Mon, Jun 10, 2019 at 4:47 PM Yves >> <mailto:yve...@mailbox.org>> wrote:
>>>
>>> I think a small '(c)OSM' for small screen web or app could be
>>> suggested as OK, what do you think?
>>>
>>>
>>> Why not revive this dormant proposal for a small attribution logo
>>> that was proposed 6 years
>>> ago:https://wiki.openstreetmap.org/wiki/RFC_Attribution_Mark
>>> <https://wiki.openstreetmap.org/wiki/RFC_Attribution_Mark>
>> I have always wondered why it did not get more attention... 
>
>Because of legal issues with both the proposed logo and using it as a
>replacement for "OpenStreetMap" for attribution purposes that have been
>mentioned more than once (it should be noted by the way that neither
>the
>goog or Mapbox use anything else than their full name for attribution).
>
>Simon
>
>> But I'm not the target audience. So, do we have feedback from web
>> designers - the population who this proposal aims to convince to
>> attribute properly ?
>>
>> ___
>> 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] Terminate Facebook rights under ODbL

[Yves]

Would that be a first step to remove their logo or shame them a (little bit) on 
the pages they are mentioned as sponsors? That should be a call from the Sotm 
WG, though.
In any case, not being a fb user, I miss a proper case with a few screenshots 
being build on the wiki.
Yves ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Terminate Facebook rights under ODbL

[Yves]

I think a small '(c)OSM' for small screen web or app could be suggested as OK, 
what do you think?
Yves ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Documenting controversial iD decisions

[Yves]

To avoid hurting any sensibilities, I'd say this is maybe not the best way to 
go in its form.
Why not organizing a kind of audit with a review process that would be 
coordinated? 
Otherwise I fear this page could just end up being a list for everybody pet 
rant. 
Yves 


Le 29 mai 2019 00:46:42 GMT+02:00, Michael Reichert  a 
écrit :
>Hi,
>
>I started documenting controversial decisions by the maintainers of iD
>at https://wiki.openstreetmap.org/wiki/ID/Controversial_Decisions
>
>Currently, only the highway=footway and the nonsquare=yes issue are
>mentioned.
>
>Please feel free to add other issues which have proofed controversial
>so
>far. Don't forget to summarise the opinion of the maintainer as well to
>aim at least some neutrality as far as it is possible for those
>involved
>in the disputes. Please add links to relevant discussions as well.
>
>Best regards
>
>Michael
>
>
>-- 
>Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
>ausgenommen)
>I prefer GPG encryption of emails. (does not apply on mailing lists)
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD invents nosquare=yes for buildings which should not be squared

[Yves]

Some validation tools, like Osmose, make great efforts to maintain a 'false 
positive' database.
Also, I don't think such validation of building orthogonality should take place 
at editing stage. A hint to the squaring tool or shortcut when someone is 
mapping almost square buildings is probably a better user experience.
Yves 

Le 10 mai 2019 19:57:17 GMT+02:00, Stefan Keller  a écrit :
>Hi,
>
>Trying to get focus back on the thread topic.
>
>Storing hints like nosquare=yes (or square=no) is not best practice of
>data curation on w worldwide level.
>
>At Thu., 9. Mai 2019 23:56 Simon Poole  wrote:
>> The question was not about validating square or not square buildings,
>it
>> is about storing a hint for iDs validation mechanism permanently in
>OSMs
>> data. There is some precedent for doing so, as was mentioned in the
>github
>> issue, still it is a bit controversial and discussion when adding
>such a
>> feature should be expected.
>...
>> I believe the issue is more about the unwillingness to take community
>> feedback seriously ...
>
>This attitude needs to be changed. I expect a discussion on tags like
>this on a broader level (i.e. outside issue trackers) _before_ it's
>being implement in an editor like iD.
>
>> Which brings us back full circle to the discussion of the privileged
>position
>> of the default editor on openstreetmap.org and the related
>transparency ...
>
>Currently the OSMF Board is doing a community survey about topics and
>issues that matter to us (https://osmf.limequery.org/489698?lang=en ).
>I think this issue becomes one of my inputs.
>
>:Stefan
>
>Am Fr., 10. Mai 2019 um 15:47 Uhr schrieb Mikel Maron
>:
>>
>> > I believe the issue is more about the unwillingness to take
>community feedback seriously at all when it doesn't coincide with the
>opinions already held by the developers. Which brings us back full
>circle to the discussion of the privileged position of the default
>editor on openstreetmap.org and the related transparency (aka who is
>holding the purse strings) and the non-existent community control or
>even just control by the OSMF.
>>
>> This is a very interesting paragraph, dense with deep topics for the
>OSM project. These topics should separate this from the particulars of
>individual situations, because the dynamics are not unique to any
>single component of the OSM data and software ecosystem. OSM has always
>been a muddle and arguably one of the reasons for its success. In OSM
>people disagree, there's strong points of view and discussion,
>sometimes it resolves, often times we continue to muddle through. Yes,
>the OSMF has ultimately legal authority over all aspects of the project
>but by design and history, exercises it very selectively. And community
>is a very amorphous concept, with disagreements over what that means
>and how it functions.
>>
>> Certainly the shape of the OSM project has outgrown the systems we
>haphazardly put in place for governance and community back in 2007.
>It's worth stepping back from many of the recent heated issues in the
>community, and look at how they are the result of growth without
>intentional adaptation, and consider what kind of approach we can take
>to imagine what OSM is like in the next 15 years.
>>
>> -Mikel
>>
>> * Mikel Maron * +14152835207 @mikel s:mikelmaron
>>
>>
>> On Thursday, May 9, 2019, 5:56:14 PM EDT, Simon Poole
> wrote:
>>
>>
>>
>> Am 09.05.2019 um 23:14 schrieb Mikel Maron:
>>
>> > What do you think? Should the next version of iD be deployed on
>www.openstreetmap.org?
>>
>> Absolutely. My understanding is this feature will greatly improve
>data quality in OSM. I think it's fair to validate squareness of
>existing buildings. Appreciate the great work of the iD team.
>>
>> The question was not about validating square or not square buildings,
>it is about storing a hint for iDs validation mechanism permanently in
>OSMs data. There is some precedent for doing so, as was mentioned in
>the github issue, still it is a bit controversial and discussion when
>adding such a feature should be expected.
>>
>> [Rant on the massively overrated concern for buildings in the first
>place and the background why people think that such a validation is
>necessary omitted]
>>
>> Also commend your attention to tagging issues Michael. There's
>certainly a broader issue with how tags are managed in OSM. In short
>it's a mess all around and is in need of a rethink. I don't think this
>minor issue is a "hill to die on" however.
>>
>> I believe the is

Re: [OSM-talk] iD invents nosquare=yes for buildings which should not be squared

[Yves]

Not the first time tagging is bent to editor's will, but this one is gross.
Yves 

Le 9 mai 2019 22:14:31 GMT+02:00, Michael Reichert  a 
écrit :
>Hi,
>
>this could be seen as a tagging discussion but I think that it is a
>discussion on governance and power. That's why this email goes to the
>Talk mailing list.
>
>Quincy Morgan, one of the maintainers of iD, invented a new tag called
>nosquare=yes today which should be added to buildings which are not
>square and should not be flagged by iD's validator. I (and later Paul
>Norman) pointed out issues with the tag. I asked Quincy to discuss the
>addition with the wider community beforehand.
>
>https://github.com/openstreetmap/iD/issues/6332
>
>Here are the issues I pointed out in the bugtracker. At the beginning
>he
>planned to use square=no which he later changed to nosquare=yes but
>this
>change does not make things better:
>> Although noname=yes is common, it is not that common that it can
>serve as an argument in favour of introducing unsquare=yes. In
>difference to noexit=yes, unsquare=yes and noname=yes only serve as a
>workaround for quality assurance tools. noexit=yes also conveys
>information for map users: There road ends here.
>> 
>> Some people prefer to tag as complete as possible and add oneway=no,
>cycleway=no, lit=no etc. to any way. However, such a practice is not
>base on a broad consensus and if you dig deep enough in the history of
>user blocks in OSM, you might find blocks set due to an excessive use
>of negative binary tags.
>> 
>> I think that iD does not need this tag and should only validate
>buildings if they have been added or modified in the current session.
>If doing so, they will be reported once which does not bother that
>much.
>> 
>> Adding such a tag is not a simple change as it might seem to be and I
>ask you to discuss it with the broader community on the Tagging mailing
>list.
>
>What do you think? Should the next version of iD be deployed on
>www.openstreetmap.org?
>
>Best regards
>
>Michael
>
>
>-- 
>Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
>ausgenommen)
>I prefer GPG encryption of emails. (does not apply on mailing lists)
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Minutely update server slow?

[Yves]

No problem on my server, I don't use Osmosis though.
Yves 

Le 20 avril 2019 20:03:48 GMT+02:00, "Lynn W. Deffenbaugh (Mr)" 
 a écrit :
>I run a personal tile server for the entire planet and have it 
>configured with minutely updates downloaded by osmosis.  Over the past 
>few days, I've noticed that my updates are falling behind and 
>subsequently noticed in the osmosis.log file that it is taking a LONG 
>time to download 4-6 hours of minutely diffs.  This usually took 5-10 
>minutes, but recently it takes 45 minutes to an hour. And sometimes 
>osmosis times out completely.
>
>Here's my osmosis configuration.txt file if that helps.
>
>> # The URL of the directory containing change files.
>> baseUrl=https://planet.openstreetmap.org/replication/minute
>>
>> # Defines the maximum time interval in seconds to download in a
>single 
>> invocation.
>> # Setting to 0 disables this feature.
>> maxInterval = 21600
>
>Anyone else seeing slow minutely diff downloads?
>
>Lynn (D)
>
>PS.  Here's the munin rdnerd Data import lag daily and weekly graphs:
>
>Data import lag
>
>Data import lag
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] An Archive namespace for the OSM wiki?

[Yves]

Is there a way to decrease the rank of some pages in the search results in 
MediaWiki?
Yves ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Bank of India (and other) Wikidata tags

[Yves]

If I follow Michael here, the mechanical edit you can do for sure is a revert 
of the mechanical edit that added the tag in the first place.
Yves___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD influencing tagging

[yves]

The iD editor team has made a tremendous job so far, and it's probably 
because some people working together tightly have come up with good 
ideas, and this is good.
However, when such an idea become controversial, it would be good 
practice  to reach out openly with the wider community and other editors 
developers, and take the time to do so. But in the end, it's up to them. 
I don't see an 'Editor software rules working group' be a big success.


On another side, and when it comes to tagging (because it also comes to 
that), I do understand that somebody wanting to have things done feel 
irritated by the too few people discussing the matter at length on the 
tagging list and the wiki. However, these are  communication channels we 
have, and the people dedicated to it. For a maintainer of iD, to despise 
these channel for advice or discussion is not helping to gain trust in 
the development team, a very good way to make these channels worse, and 
everybody's frustration high.


Yves


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

Re: [OSM-talk] Dialects of English | Re: iD influencing tagging

[Yves]

Please note that ID make a pretty good job in localization. I'd say that to 
influence tags meaning, the Transifex tasks, open to any contributors, is a 
more powerful tool than iD code and pressets.
Yves___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] How to get an overview of multiple gpx on OSM map?

[Yves]

Drag and drop your gpx in Qgis?
Yves 

Le 3 novembre 2018 15:09:12 GMT+01:00, _ dikkeknodel  
a écrit :
>Hi all,
>
>Ever since I moved to Switzerland over a year ago I’ve been both hiking
>in the mountains and updating OSM details a lot. Since I hike at least
>20 km every weekend, it must have totaled to about 1200 km by now all
>across the country. I would love to get an overview of where I have
>been so far.
>
>Since I’ve got a GPX file of almost every hike, the data is there. I am
>now looking for a nice graphical way to plot all of these files at once
>on a nice OSM map, OpenTopoMap as a base layer would be great.
>I’ve been searching for a while how to arrange this (without much
>programming knowledge), but I am kind of lost at the moment.
>
>Does anybody have a hint?
>
>Cheers,
>dikkeknodel
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Mobile Application for optimizing OSM ski area data

[Yves]

A middle ground could be that your users upload a gpx file with osm-compatible 
information so that more skilled OSM contributors can use them to edit the map.
It relieve your app from the burden of being a map editor.
However, information will probably be lost in the process, we prefer first hand 
contributions.
Yves - (Opensnowmap) 

Le 26 octobre 2018 14:54:05 GMT+02:00, Frederik Ramm  a 
écrit :
>Hi,
>
>On 26.10.2018 14:22, Valentina Böhm wrote:
>> What would you recommend regarding authentication? Is it ok if users
>of
>> my app are committing data on my behalf or should all users have
>their
>> own OSM account?
>
>Using a central account for aggregated user contributions is
>discouraged; if some of your users commit vandalism or add data from
>illegal sources, it becomes very difficult to separate the good from
>the
>bad. Also, other OSM mappers might want to contact the user who has
>added or changed something.
>
>> If users have their own account, is it possible and ok if I prepare
>the
>> data with my algorithm and commit the data on their behalf?
>
>This is possible with OAuth authentication, and other programs like
>wheelmap or StreetComplete already do something similar. Although I am
>a
>little worried when you say "prepare the data with your algorithm" -
>you
>should always make sure the user has full control over what they
>submit,
>you should not submit something that might come as a surprise to the
>user later.
>
>> I’m also interested in feedback about the idea. Are there similar
>> projects? What do you think of my idea?
>
>"Topical" editors - software that allows specialist contributions in
>niche areas - can be a valuable addition to the OSM editing landscape,
>so in general I think it sounds like a good idea!
>
>Best
>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
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] As Google Maps Renames Neighborhoods, Residents Fume - The New York Times

[Yves]

Time to choose a name of your choice for your own neighborhood in OSM, after 
all we are or close to be  the next authoritative source :) 
Yves 

Le 16 août 2018 16:40:06 GMT+02:00, Martin Koppenhoefer 
 a écrit :
>
>
>sent from a phone
>
>> On 16. Aug 2018, at 16:25, Maarten Deen  wrote:
>> 
>> This has been pointed out to Google many, many times (through their
>inadequate feedback tool and via Google employees) and has long been
>ignored. It has now been corrected
>
>
>don’t help them. The worse their errors are, the better for OSM. Let’s
>point people to OSM rather than help the Goog fix their data.
>
>Cheers,
>Martin 
>___
>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] Barrier=block areas

[Yves]

Being a closed way with area=yes does not mean they aren't connected to the 
underlying ways: I don't think router be bothered by this.
Yves 

Le 16 août 2018 02:14:49 GMT+02:00, David Fox  a 
écrit :
>Barriers, by definition, provide some level of restriction. Without
>attaching them in some form it becomes hard for routers to account for
>them.
>Hedges and walls are linear in nature, not an area.
>
>On 15 August 2018, at 19:51, Tomasz Wójcik  wrote:
>
>
>
>Currently, barrier=block is not allowed to be mapped as an area. As
>blocks can be big enough to map them as areas, I think it should be
>allowed, the same as in barrier=wall or barrier=hedge. Anyway,
>currently we have 3,9k of barrier=block areas in database.
>
>
>https://wiki.openstreetmap.org/wiki/Tag%3Abarrier%3Dblock
>
>
>Block examples:
>
>http://www.concrete-barriers-blocks.co.uk/up/concrete-barrier-type-m-block-photo.gif
>
>http://cdn1.codziennypoznan.pl/201606241325/pub/img/full/71/1c58d-a9.jpg
>
>
>Barriers with mapping as area allowed
>
>https://wiki.openstreetmap.org/wiki/Tag:barrier=wall 
>
>https://wiki.openstreetmap.org/wiki/Tag%3Abarrier%3Dhedge
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Yves]

If those codes can be encoded and decoded offline, it should be dealt with 
offline by the client, not a server-side application like Nominatim.
Yves 

Le 10 août 2018 00:04:56 GMT+02:00, Vao Matua  a écrit :
>I use Plus Codes with OSMand offline and it works well. If we are
>worried
>about the number of tags we should remove all tags and convince
>everyone to
>just use lat/long.
>The ability to verbally tell someone a location like 47RP+XG
>Dar-es-Salaam
>is much easier than -6.85748/39.28613
>Suspend disbelief, sometimes new things are better.
>
>On Thu, Aug 9, 2018 at 2:57 PM, john whelan 
>wrote:
>
>> So if OSMand or some such could handle them in a search off line that
>> would be acceptable?  They are generated from long and lat after all.
>>
>> My feeling is adding them to Nominatim is not a perfect solution as
>it
>> implies OpenStreetMap supports them rather than something else but
>from a
>> practical point of view it would solve a lot of problems.  Not least
>the
>> idea that tags get added to every building with some sort of address
>code.
>> How many different codes for buildings are we going to see?
>>
>> Currently locally addr: has number, postcode and street name so its
>> difficult to logically say its one rule for one country and another
>for a
>> different one.
>>
>> Cheerio John
>>
>> On 9 August 2018 at 17:40, Vao Matua  wrote:
>>
>>> It is a good idea for the unconnected part of the world. If you have
>>> access to a website you might as well use three-silly-words.
>>> If you have a stand-alone app with the Plus Codes on the buildings
>then
>>> someone can easily communicate that information.
>>> Internet connectivity is not world wide.
>>>
>>> On Thu, Aug 9, 2018 at 2:27 PM, Frederik Ramm 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> On 08/09/2018 10:48 PM, Vao Matua wrote:
>>>> > The Tanzania Development trust has calculated the Plus Code
>addresses
>>>> > for 17 million building points in Tanzania and have added a
>sample
>>>> > village (1800 points) as a test.
>>>>
>>>> This is not a good idea. Please don't do it. It does not make
>sense! If
>>>> someone searches for a plus code on a web site, the site can
>compute the
>>>> lat/lon and take you there, WITHOUT having to add billions of plus
>code
>>>> points all over the word.
>>>>
>>>> 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
>>>>
>>>
>>>
>>> ___
>>> 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] proposed mechanical edit - moving FIXME=* to fixme=*

[Yves]

I second Tom and Mikael, maybe a kind of rédaction to keep the date could be 
done? Not sure it's worth the effort though.
Yves ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] WMF: "Interactive maps, now in your language"

[Yves]

While there is a lot of things said here in this thread, I notice that:
1 there is very little advice in the article on how to enter names in OSM. 
2 there no comment on the blog that would give advice on how to enter names in 
OSM. 

It would be the right time if OSM people would take the time to synthetise to 
WMF contributors what names are acceptable in OSM.
Do we have a good wiki page on the matter?
Yves___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Using Wikipedia to add names in other languages

[Yves]

Le 7 mai 2018 07:19:24 GMT+02:00, Michael Kugelmann  a 
écrit :
>On 05.05.2018 at 17:08 Mateusz Konieczny wrote:
>>
>> For start, for OSM mapping we are supposed to use data compatible
>with 
>> ODBL,
>>
>> rather than "everything, no matter copyright, as long as we think
>that 
>> we will not be sued".
>>
>And there is nothing to add to this statement! We have always been a 
>project that was very carefull about it's data sources. This was always
>
>one of the strengthes of the project, I request that this stays the
>same.
>

It doesn't harm to add my strong agreement here. 
Yves

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

Re: [OSM-talk] weeklyOSM #403 2018-04-03-2018-04-09

[Yves]

Apparently, it's the Spanish version :) 
Yves 

Le 13 avril 2018 19:51:33 GMT+02:00, weeklyteam  a 
écrit :
>The weekly round-up of OSM news, issue # 403,
>is now available online in English, giving as always a summary of all
>things happening in the openstreetmap world:
>
>http://www.weeklyosm.eu/en/archives/10227/
>
>Enjoy!
>
>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

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

Re: [OSM-talk] Please do not re-use old node IDs

[Yves]

Hi Frederik, 
For my curiosity, is it a feature of the API to:
_ allow users to choose an ID? 
_ not re-assign an old ID? 
Yves 

Le 6 mars 2018 11:26:55 GMT+01:00, Frederik Ramm  a écrit :
>Hi,
>
>we're all concerned about the environment these days. "Reduce, Reuse,
>Recycle" is certainly something to strive for in the real world out
>there.
>
>However, for the second time now I've encountered a user who thought it
>was a good idea to reclaim old node IDs for new edits. A couple of
>long-deleted TIGER nodes were raised from the dead, and put to use in
>mapping some new roads on the other side of the planet.
>
>This sounds like a funny/quirky thing to do, and looks harmless enough
>on the surface. But anyone who ever looks at the history of things
>*will* be totally confused. Nobody who works with historic data will
>expect that a U.S. bus stop could become a tree in Romania. People are
>bound to interpret this in any number of wrong ways. It also messes up
>my full history extracts, where you'll now find the occasional German
>hiking route in the California data extract because a node that used to
>be in California is now part of a path that belongs to the hiking
>route.
>
>Long story short, please don't do it - let the API assign you new node
>IDs to your stuff instead of building ingenious contraptions to recycle
>old nodes.
>
>Thanks
>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

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

Re: [OSM-talk] opensnowmap.org down?

[Yves]

It's back online. 
Yves 

Le 5 décembre 2017 16:57:33 GMT+01:00, Wolfram Schneider  a 
écrit :
>Hi,
>
>it seems that http://www.opensnowmap.org is down. Does anybody knows
>whats happens to the site?
>
>-Wolfram
>
>-- 
>Planet.osm extracts: https://extract.bbbike.org
>BBBike Map Compare: https://mc.bbbike.org/mc
>
>___
>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] opensnowmap.org down?

[Yves]

Apparently yes, thanks for the info. 
I'll have a look in a couple of hours and keep you inform. 
Yves 

Le 5 décembre 2017 16:57:33 GMT+01:00, Wolfram Schneider  a 
écrit :
>Hi,
>
>it seems that http://www.opensnowmap.org is down. Does anybody knows
>whats happens to the site?
>
>-Wolfram
>
>-- 
>Planet.osm extracts: https://extract.bbbike.org
>BBBike Map Compare: https://mc.bbbike.org/mc
>
>___
>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] Wiki Proposals: An OSM Echo Chamber?

[Yves]

I like the idea of voting to praise a good documentation. 
The tools are available in the wiki, so why not try it out on a non debatable 
tagging scheme (maybe landcover wouldn't be a good idea for a try). 
Yves 

Le 4 décembre 2017 18:47:00 GMT+01:00, Tobias Knerr  a 
écrit :
>Hi Roland,
>
>On 04.12.2017 09:42, Roland Olbricht wrote:
>> We recently had an experienced and productive community member, Ilya,
>> putting a lot of time in a Wiki Proposal just to see the whole
>process
>> fail.
>
>there's an important distinction here: It's Ilya's proposal that has
>failed (for now at least), not the proposal process. That proposals are
>sometimes rejected is an inherent part of that process.
>
>I've written several proposals over the years, and while some of them
>have been accepted, I've always learned something from the ones that
>weren't. Just because I'm an experienced contributor doesn't mean all
>my
>ideas are great – and the proposal process is a way to weed out those
>of
>my ideas that aren't.
>
>I'm not trying to suggest that the proposal system cannot possibly be
>improved upon. However, Ilya's proposal was pretty unusual as far as
>proposals go: It had a couple specific flaws which you already hinted
>at
>(such as trying to do too much at once and writing in a "documentation
>page" format instead of describing the changes to be voted on), so it's
>likely not the best basis for generalizing observations to the proposal
>process as a whole.
>
>> I suggest to replace the Proposal process by three more specialized
>> and therefore much simpler processes. They are structured by what
>they
>> can affect.
>[...]
>> === Distinguished Documentation === [...]
>> === Wiki Cleanup === [...]
>> === Tag Disambiguation ===
>
>At the moment, the proposal process isn't really intended for things
>that _only_ affect the wiki, it's always an attempt to come to an
>agreement on how to tag things in the database. So most of these items
>seem to be outside the scope of what proposals are suitable for.
>Generally, I don't believe a democratic process is the best way to
>produce well-written documentation.
>
>Tobias
>
>___
>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] Tagging/rendering relations

[Yves]

Le 3 décembre 2017 19:07:24 GMT+01:00, "Daniel Koć"  a 
écrit :

W dniu 03.12.2017 o 18:43, Yves pisze:

I do agree with Christoph here, tag depreciation should be discussed 
outside of the scope of osm-carto.


It would be interesting for me to hear the exact reasons why do you 
think that?

Because the discussion can be heated by the fear of seeing something 
'disappear' from the map overnight.
I don't have a particular idea concerning the orthogonals tags mentioned here. 
But it seems to me they could be discussed better as tags in a more general 
way, then the maintainers of osm-carto could propose with their own rendering 
choice.
Yves 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Planned rendering changes of protected areas

[Yves]

I do agree with Christoph here, tag depreciation should be discussed outside of 
the scope of osm-carto. 
Daniel, this all thread looks like you want to promote a tagging scheme for the 
primary reason you can't make it look nice on the slippy map. That's really not 
helping tagging discussions! 
You should restart this all thread on tagging@ without osm-carto in mind. 
Yves 

Le 3 décembre 2017 04:05:52 GMT+01:00, "Daniel Koć"  a 
écrit :
>Thanks for the comments! They help me to get the bigger picture, which 
>is not visible from just the tag names and definitions.
>
>TL;DR summary: I think that for now we should render all the existing 
>tags with osm-carto, but make some of them appear earlier to encourage 
>smooth migration to a more precise scheme.
>
>W dniu 01.12.2017 o 01:55, Martin Koppenhoefer pisze:
>
>> there is no problem with 2 different tags fitting for the same kind
>of 
>> thing. These are also different in scope, leisure=nature_reserve is 
>> for all kind of natural protected areas, while
>boundary=protected_area 
>> is for all kind of protected areas.
>
>My general findings are:
>
>1. As I currently understand it, nature reserve is _always_ a type of 
>protected area, to begin with.
>
>We were talking on osm-carto ticket with some people about private 
>reserves and even when someone told me "it's not about protection!"
>this 
>term was used immediately in the same sentence (or in the next one). =}
>
>I guess they meant "it's voluntary and not formal", but still it's 
>intended as a protection of nature, so it's just a special, weak type
>of 
>protection.
>
>2. The problem seems to be for a mapper to be more precise, since a 
>typical survey can reveal a sign with a name "XYZ nature reserve". 
>However this is not about just a name.
>
>Boundaries are not visible on the ground easily, so a mapper who draw 
>them have to use some other sources and I believe there are more 
>informations available. Otherwise the area shape is probably not 
>verifiable, which would be bad anyway. And I think all of them are 
>areas, not the points (node would mean probably "here is the protection
>
>area, but exact shape is not shown at the moment"), so boundary is also
>
>a sure thing.
>
>3. The name tag leisure=nature_reserve states that it's about leisure 
>(which of course might be for a given object), but it's always about 
>protection. So even if the value have merits, this key assumption is 
>wrong in general and misses more important property 
>(boundary=nature_reserve has only 35 uses).
>
>4. Another problem is lack of coherent definition of protection other 
>than numbers and high-level classes.
>
>The numbers seems to be derived from IUCN scheme ( 
>https://en.wikipedia.org/wiki/IUCN_protected_area_categories ), but 
>wider: only categories 1-6 is IUCN-based and I don't know about the
>rest.
>
>Especially class 7 is interesting for us: "*nature-feature area*: 
>similar to 4. but /without/ IUCN-level.", so i guess it's for all the 
>non-IUCN classified nature reserves. Probably most of the time this 
>should be clear from the boundary shape source.
>
>It would be good to have more standardized subtags for common features:
>- "nature" - protection_object=* is the same mess as numbers, when 
>talking about hierarchy levels, so maybe some subtag like 
>"nature_reserve=yes" would be useful
>- "private" owner type (not the access type) - 
>governance_type=private_landowner would be great (if really used...)
>- "voluntary" - but that might be clear from the lack of government or 
>international authorities influence
>
>What about the solutions?
>
>> My suggestion for osm carto is to look at both tagging schemes for 
>> nature reserves. I wouldn’t drop support for leisure =nature reserve
>
>In summary, we have 3 popular but overlapping types now:
>
>1. leisure=nature_reserve (77 264)
>2. boundary=national_park (16 583)
>3. boundary=protected_area (62 016)
>
>Their general properties and relations:
>
>1. has a wrong key, but nice value name, and is a subtype of 3.
>2. has a nice value name and a proper key, it's also subtype of 3.
>3. is very broad with precise, but not so common name, it also has 
>subtypes, which are useful for official classification, but are not 
>clear for all the other types of conservation
>
>Therefore I would advice to:
>
>1. Discourage leisure=nature_reserve and make it a subtag of 
>boundary=protected_area, like:
>     a) nature_reserve=yes - 2 uses
>     b) protected_area=nature_reserve - 22 uses
>     c) protected

Re: [OSM-talk] weeklyOSM #382 2017-11-07-2017-11-13

[Yves]

Le 17 novembre 2017 17:27:05 GMT+01:00, Mikel Maron  a 
écrit :

>> Yuri Astrakhan re-started the discussion on the Talk mailing list
>about the tool now called Sophox. The discussion continues to be quite
>contentious.
>* Mikel Maron * +14152835207 @mikel s:mikelmaron 
>
>On Friday, November 17, 2017, 11:23:23 AM EST, Martin Koppenhoefer
> wrote:  
> 
> 2017-11-17 16:53 GMT+01:00 Mikel Maron :
>
>Now try this version...
>> Yuri Astrakhan re-started the discussion on the Talk mailing list
>about the tool to do mechanical edits (it is now called Sophox). The
>discussion continues to be quite contentious.
>
Ok, now it's completely hollow. 
But this is interesting, and I *do* find the original from Weekly a bit harsh. 
Please, Mikel, do you want to try now to add some content on the actual thread? 
Yves 

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

Re: [OSM-talk] weeklyOSM #382 2017-11-07-2017-11-13

[Yves]

Good exercise Mikel, but using only 'contentious' you don't mention the issues 
raised in the discussion. 
Yves ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Woods vs Forests

[Yves]

This discussion looks like a chance to write proposals that could be voted by 
more than 15 people. 
Yves ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] DWG survey on organised editing

[Yves]

That's a good point, starting with an OSMF guideline, then after a while, a 
policy if needed. 
Or do you mean a wiki community written guideline? 
Yves 

Le 18 octobre 2017 03:05:28 GMT+02:00, john whelan  a 
écrit :
>Probably what we could do with is a set of guidelines for people
>organising
>mapping groups.  This is not policy so much as best practices.
>
>Could this be done before we thrash out a policy?
>
>Thanks John
>
>On 17 Oct 2017 8:27 pm, "Frederik Ramm"  wrote:
>
>> Hi,
>>
>> the results are in!
>>
>> https://wiki.osmfoundation.org/wiki/Data_Working_Group/
>> Results_of_Organised_Editing_Survey_2017
>>
>> Thank you everyone who participated.
>>
>> 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
>>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] A thought on bot edits

[Yves]

@JB, I understood the bot=no tag like the add=no sticker on your physical 
mailbox. 

Yves 

Le 6 octobre 2017 05:37:37 GMT+02:00, JB  a écrit :
>
>Le 05/10/2017 à 22:50, Yuri Astrakhan a écrit :
>> I like the "bot=no" flag, or a more specific one for a given field - 
>
>> "name:en:bot=no" - as long as those flags are not added by a bot :)
>Ho…
>We are now manually contributing one more tag to say it was contributed
>
>manually…
>So many people seem to think one geodatabase can be created only
>through 
>bots, imports, etc… why not go create it?
>JB.
>
>___
>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] Overlapping brands (was "Fixing wiki* -> brand:wiki*")

[Yves]

Any contributor interested in these Netto shops can edit the name, add an 
operator tag or else to distinguish them. 
If they are not interested or do not know better, then the should not do 
anything. 
If they are interested but not contributors, they can contribute. 
Yves 


Le 3 octobre 2017 12:46:10 GMT+02:00, Michael Reichert  
a écrit :
>Hi Andy,
>
>Am 2017-09-27 um 17:57 schrieb Andy Townsend:
>> On 27/09/2017 15:35, John F. Eldredge wrote:
>>> The spatial information will tell you where each business location
>is;
>>> it is not sufficient to tell you whether these are multiple
>locations
>>> of the same brand, or two unrelated brands that share the same name
>>> and category of business.
>> 
>> Can anyone think of an example where two unrelated brands share the
>same
>> name and category of business in the same geographical area?
>
>Netto in Germany. Both companies have shops in some German states.
>Officially, one of them is called "Netto Marken-Discount" and the other
>one just "Netto". But people call them both "Netto" and there are
>multiple towns and cities which have both Netto and Netto shops.
>Because
>you cannot expect any OSM mapper to add more than name=* and
>shop=supermarket, you cannot decided without additional sources which
>brand a Netto supermarket belongs to.
>
>Best regards
>
>Michael
>
>-- 
>Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
>ausgenommen)
>I prefer GPG encryption of emails. (does not apply on mailing lists)
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] A thought on bot edits

[Yves]

Actually, if you find the way to keep a db handling a property (or tag) of OSM 
element in sync with OSM, you have solved the need for UID. And if you happen 
to do so without UID or API change , it's very nice ! 


Le 2 octobre 2017 15:59:48 GMT+02:00, Christoph Hormann  a 
écrit :
>
>With all the recent endeavors to push more automated edits in OSM and 
>with the related rules and policies clearly failing (just look at 
>https://wiki.openstreetmap.org/wiki/Category:Automated_edits_log and 
>compare that to what is actually taking place in terms of automated 
>edits these days) i just had the idea that it might be a lot easier and
>
>better if we replace all current regulations of automated edits with a 
>simple rule:
>
>Automated edits of any kind may freely add or edit tags with keys 
>starting with 'bot:' but may not under any circumstances touch any 
>other tags.
>
>This way people could go crazy bot editing whatever they want in that 
>namespace but would not interfere with manual mapping activity and data
>
>consumers could choose freely if the want bot edited information and if
>
>they do if they want to give it priority over manually verified data.  
>And mappers could configure their editors to hide the bot tags if they 
>are not interested in them.
>
>Of course considering the big volume of editing activity that would 
>likely take place in the 'bot:' namespace in that scenario it might be 
>a good idea to put those tags into a separate database for efficiency 
>reasons.
>
>-- 
>Christoph Hormann
>http://www.imagico.de/
>
>___
>talk mailing list
>talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] # with color code

[Yves]

The value is defined as an hexadecimal rgb code, starting with a #. 
I think most data consumers try to decode it with or without a #, its an easy 
to fix typo.
Yves 

Le 28 septembre 2017 18:59:15 GMT+02:00, James  a écrit :
>usually # specifies that it's a hexidecimal number vs a base 10 number.
>When you have letters A-F it's obvious that it's hexidecimal and can be
>implecitely converted.
>
>The issue is when you don't have letters:
>255
>
>in hexadecimal 255 is
>2*16^2
>+
>5*16^1
>+
>5*16^0
>= 512+80+5=597
>
>255 base 10 would be represented by ff in hex.
>
>On Sep 28, 2017 12:08 PM, "Jack Armstrong dan...@sprynet.com" <
>jacknst...@sprynet.com> wrote:
>
>> It's been my experience that colors render just fine without a '#'
>before
>> the code number. Is usage of a # prefix really necessary? What
>problems
>> will occur if it isn't attached? Thanks :)
>>
>> ___
>> 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] Fixing wiki* -> brand:wiki*

[Yves]

I add a look at http://wiki.openstreetmap.org/wiki/Key:brand:wikidata
Wow. 
So, this tag is about adding an external reference that explains what the tag 
is? Really? This is not a joke? 

OSM is sick, please somebody call a doctor. 
Yves 

Le 27 septembre 2017 19:14:53 GMT+02:00, Mark Wagner  a 
écrit :
>On Wed, 27 Sep 2017 06:49:40 -0500 (CDT)
>Richard Fairhurst  wrote:
>
>> Andy Mabbett wrote:
>> > in different parts of the world  
>> 
>> IIRC OSM stores spatial information. I might be wrong.
>> 
>
>Two examples that can't be resolved by a spatial query:
>
>1) There is a business near me named "Maxwell House".  It is entirely
>unrelated to the coffee brand of that name, despite both companies
>operating in the same country.
>
>2) Until recently, there was a burger joint in town called "Sonic's"
>that was entirely unrelated to the chain of drive-in eateries.  (When
>the national chain opened up a location in town, they paid the existing
>restaurant to re-brand.)
>
>-- 
>Mark
>
>___
>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] Adding wikidata tags to the remaining objects with only wikipedia tag

[Yves]

I think that the underlying issue in wikidata tags is that they are external 
IDs. Not human readable, they cannot be entered 'by hand' nor verified on the 
ground. 
Once you accept them in OSM, you can't really complain about bots. 

Yves (who still think such UIDs are only needed for the lack of good query 
tools).


Le 26 septembre 2017 19:08:33 GMT+02:00, Yuri Astrakhan 
 a écrit :
>>
>> > p.s. OSM is a community project, not a programmers project, it's
>about
>> > people, not software :-)
>>
>> It's both.  OSM is first and foremost is a community, but the result
>of
>our effort is a machine-readable database.  We are not creating an
>encyclopedia that will be casually flipped through by humans. We
>produce
>data that gets interpreted by software, so that it can render maps and
>be
>searchable.  For example, if every person uses their own tag names and
>ways
>to record things, the data will have nearly zero value.  We must agree
>on
>conventions so that software can understand our results - which is
>exactly
>what we have been doing on wiki and in email channels. Any tag and
>value
>that cannot be recognized and processed by software is effectively
>ignored.
>
>
>>   Totally agree. If some script can automatically add new tag
>> (wikidata) without any actual WORK needed, then it is pointless,
>> anybody can run an auto-update script.
>
>  When ordinary (non geek) mappers do ACTUAL WORK - add wikipedia
>> data, they add wikipedia link, not wikidata "stuff".
>>
>
>While sand castles may look nice, they don't last very long. When
>ordinary
>people add just the Wikipedia article, that link quickly gets stale and
>become irrelevant and often incorrect. The wikipedia article titles are
>not
>stable. They get renamed all the time - there are tens of thousands of
>them
>in OSM already that I found.  Often, community renames wp articles
>because
>there are more than one meaning, so they create a new article with the
>same
>name in its place - a disambig page.  There is no easy way to analyse
>wikipedia links for content - you cannot easily determine if the
>wikipedia
>article is about a person, a country, or a house, which makes it
>impossible
>to check for correctness.
>
>When I spend half an hour of my time researching which WP article is
>best
>for an object, I do not want that effort to be wasted just because
>someone
>else puts a disambig page in its place, and I have to redo all my work.
>
>  When data consumers want to get a link to corresponding wikipedia
>> article, doing that with wikipedia[:xx] tags is straightforward.
>Doing
>> the same with wikidata requires additional pointless and time
>> consuming abrakadabra.
>>
>
>no, you clearly haven't worked with any data consumers recently. Data
>consumers want Wikidata, much more than wikipedia tags - please talk to
>them. Wikidata gives you the list of wikipedia articles in all
>available
>languages, it lets you get multi-lingual names when they are not
>specified
>in OSM, it allows much more intelligent searches based on types of
>objects,
>it allows quality controls.  The abrakadabra is exactly what one has to
>do
>when parsing non-standardized data.
>
>>
>>   Validation of wikipedia tag values can and IS already done using
>osm
>> data versus wikipedia-geolocated data extracts/dumps.
>>
>> Sure, it can be via dump parsing, but it is a much more complicated
>than
>querying.  Would you rather use Overpass turbo to do a quick search for
>some weird thing that you noticed, or download and parse the dump? 
>Most
>people would rather do the former. Here is the same thing - you *could*
>do
>validation via a dump, but that barrier of entry is so high, most
>people
>wouldn't.  With the new OSM+Wikidata tool, which is already getting
>hundreds of thousands requests (!!!) , it is possible to get just the
>data
>you need, and fix the problems that have been always present, but
>hidden.
>And all that is possible because of a single tag.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Label language on the Default stylesheet

[Yves]

If the OSMF tile servers were to be used to provide webmaps for a vast 
audience, I would understand double labeling in English. 
That not the primary purpose, though. 
Yves 

Le 24 septembre 2017 23:01:00 GMT+02:00, Matthijs Melissen 
 a écrit :
>Hi all,
>
>I would like to ask for your opinion on the choice of language used in
>the Default map on openstreetmap.org.
>
>This map (based on the openstreetmap-carto style) currently displays
>all labels in their native language (as defined in the 'name' tag).
>For example, we have a label 北京市 for Beijing, a label موريتانيا for
>Mauritania, and a label Magyarország for Hungary.
>
>The openstreetmap-carto team quite frequently receives requests to
>(additionally) display labels in English (or in any case the
>Latin-alphabet). The people making these requests state that the map
>is currently not very usable for an international audience, as many
>people are not able to read labels in for example Arabic or Mandarin.
>Some areas where this problem is particularly visible:
>https://github.com/gravitystorm/openstreetmap-carto/issues/803#issuecomment-330782700
>A prominent case of such a request is from the Gnome Maps team, who
>decided not to use the Default style for this reason:
>https://bugzilla.gnome.org/show_bug.cgi?id=764841#c35
>
>From an ideologic viewpoint, I am very much in favour of not giving
>preferential treatment to any particular language. Using the local
>language seems fair in this respect. On the other hand, from a
>pragmatic point of view I can also see that using English (in
>addition) would significantly increase the usefulness of the map to
>many people.
>
>I would be interested to know what others think about this. An option,
>for example, would be to display countries names, and perhaps the
>names of big cities, in English as well as in the local language.
>
>Note: making the map available in multiple language versions is
>something we like to do in the future, however, this requires quite
>significant technical changes. Therefore, this is out of scope for
>now.
>
>More information on this issue can be found on Github:
>https://github.com/gravitystorm/openstreetmap-carto/issues/803
>
>I'm looking forward to your opinions.
>
>Kind regards,
>Matthijs Melissen
>
>___
>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] Trademark policy

[Yves]

Sorry for breaking the thread.
I understand the reasoning and the need for this policy, Simon, but can't help 
seeing the disappearance of such naive (somebody said infamous? ) names a bit 
sad. 
But it's time to grow up, I guess. 
Cheers, 
Yves 

Le 17 septembre 2017 23:10:40 GMT+02:00, Simon Poole  a écrit :
>I believe there is a slight misunderstanding, while remixing
>OpenStreetMap/OSM/etc in various ways may result in cutesy copycat
>domain names they simply do not jibe well with reality.
>
>Not only does every single one of them weaken the standing of the marks
>themselves and make is increasingly difficult to take action against
>misuse, they are further uncontrollable liabilities for the whole
>community. I gave the example of OpenWeatherMap, but there are others
>that would be really painful if they ended up in the hands of your fav
>giant tech corp.
>
>That said, I'm not sure why you believe the policy has broken
>something,
>with the exception of a few local chapters, to my knowledge, the OSMF
>has never granted a licence to anybody to use the marks in a domain
>name. As outlined in the FAQ we will be operating a grandfathering
>scheme to legalize such use after the fact so actually making such use
>legit for the first time.
>
>And yes: WoQ would be a wonderful name for Yuris service and shows that
>it is completely possible to break out of the old schema of simply
>copying OSM.
>
>Simon
>
>
>Am 17.09.2017 um 15:57 schrieb Yves:
>> So, no OpenSparqlMap, then? :(
>> Sad, this policy definitely broke something.
>> Yves
>>
>> Le 17 septembre 2017 12:58:12 GMT+02:00, Blake Girardot
>>  a écrit :
>>
>> Hi,
>>
>> How does this relate to the new draft trademark policy?
>>
>> I can't tell from the draft policy, but I believe that OSM at
>least is
>> a protected mark, not sure about osm.
>>
>> But I do think Simone Poole asked the community to stop naming
>things
>> with osm trademarks in them or variations on openstreetmap
>phrase.
>>
>> Cheers
>> blake
>>
>> On Sat, Sep 16, 2017 at 5:11 PM, Yuri Astrakhan
> wrote:
>>
>> The new service is getting more and more usage, but it lacks
>> the most important thing - a good name. So far my two choices
>> are: * wikosm * wikidosm Suggestions? Votes? The service
>> combines Wikidata and OpenStreetMap databases, and uses
>SPARQL
>> (query language) to search it, so might be good to reflect
>> that in the name.
>>
>https://wiki.openstreetmap.org/wiki/Wikidata%2BOSM_SPARQL_query_service
>> P.S. I know this is the hardest problem after off-by-one and
>> caching...
>>
>
>> 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] Name challenge - what to call the new OSM+Wikidata service?

[Yves]

So, no OpenSparqlMap, then? :(
Sad, this policy definitely broke something. 
Yves 

Le 17 septembre 2017 12:58:12 GMT+02:00, Blake Girardot  a 
écrit :
>Hi,
>
>How does this relate to the new draft trademark policy?
>
>I can't tell from the draft policy, but I believe that OSM at least is
>a protected mark, not sure about osm.
>
>But I do think Simone Poole asked the community to stop naming things
>with osm trademarks in them or variations on openstreetmap phrase.
>
>Cheers
>blake
>
>On Sat, Sep 16, 2017 at 5:11 PM, Yuri Astrakhan
> wrote:
>> The new service is getting more and more usage, but it lacks the most
>> important thing - a good name.  So far my two choices are:
>>
>> * wikosm
>> * wikidosm
>>
>> Suggestions?  Votes?  The service combines Wikidata and OpenStreetMap
>> databases, and uses SPARQL (query language) to search it, so might be
>good
>> to reflect that in the name.
>>
>>
>https://wiki.openstreetmap.org/wiki/Wikidata%2BOSM_SPARQL_query_service
>>
>> P.S.  I know this is the hardest problem after off-by-one and
>caching...
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
>
>
>-- 
>
>Blake Girardot
>OSM Wiki - https://wiki.openstreetmap.org/wiki/User:Bgirardot
>HOTOSM Member - https://hotosm.org/users/blake_girardot
>skype: jblakegirardot
>Live OSM Mapper-Support channel - https://hotosm-slack.herokuapp.com/
>
>___
>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] DWG redaction and Autometed edits code of conduct

[Yves]

Le 27 août 2017 20:37:18 GMT+02:00, Greg Morgan  a 
écrit :
>On Sun, Aug 27, 2017 at 10:29 AM, Ian Dees  wrote:
>
>>
>>
>> On Aug 27, 2017 11:58, "Yves"  wrote:
>>
>>  a écrit :
>>
>>
>> Frederik,
>>
>>
>> Thanks for notifying us about this. I hope that you treat this as an
>> import or automated edit and follow the rules you would expect to see
>the
>> rest of the community follow
>>
>>
>> Ian,
>> To lessen the burden of the DWG, I would say that this thread is
>> sufficient to document the redaction, plus whatever documentation the
>DWG
>> usually make.
>>
>>
>> I strongly disagree. As a group of people who have received
>extra-judicial
>> powers in the OSM community, they should be expected to follow
>community
>> guidelines to a higher degree than the rest of the community.
>>
>
>I agree with Ian.  Yves what about the DWG lessening the burden on
>mappers?

I would say that to me, it's a strange way of thinking, the same for Ian 
comment. 
Could you both elaborate on this, what made you think these ways about the DWG 
work? 
Yves 

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

Re: [OSM-talk] [Talk-us] Redacting 75, 000 street names contributed by user chdr

[Yves]

 a écrit :

Frederik,


Thanks for notifying us about this. I hope that you treat this as an import or 
automated edit and follow the rules you would expect to see the rest of the 
community follow


Ian, 
To lessen the burden of the DWG, I would say that this thread is sufficient to 
document the redaction, plus whatever documentation the DWG usually make. 
Yves ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM and science

[Yves]

On Thursday 24 August 2017, Frederik Ramm wrote:


It is certainly good for OSM to offer a helping hand to scientists
who are seeking cooperation. I would also like us to develop a review
and fact check mechanism for scientific publications on OSM so that
those who don't bother to get their facts right are held accountable
for the bad science they inevitably produce.


No need to take it this way: it would be a way for publishers to get a review 
from the community while not being part of it. I 'm no expert in social 
science, and I  wouldn't necessarily judge badly this argument. 

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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Yves]

What an out of topic festival! Phone models, routers, rendering styles, what 
else? 
Yves ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Macromapping problems

[Yves]

I'm quite certain that this could be solved by a crowdsourced OpenLabelMap, 
Mountain ranges come into discussion in various mailing lists from time to time 
every year, but any solution faces the ground truth rule and high resolution of 
OSM a hard way. 
A separate database is IMHO the way to go. 
A crowdsourced version of Natural Earth, maybe? 
Yves 

Le 22 août 2017 01:42:35 GMT+02:00, "Daniel Koć"  a écrit 
:
>I guess most of you understand the problems of so called "micromapping"
>
>(very detailed geo data mapping). But when I started to look at the 
>opposite end (macro level), it looks even worse.
>
>Low zoom rendering on default map style lacks lot of important things 
>(see https://github.com/gravitystorm/openstreetmap-carto/issues/2688 ).
>
>We have basically:
>
>- land/water distinction (but some big lakes are missing for example)
>
>- ice areas
>
>- country (and district) borders
>
>- capitals and big cities
>
>- big roads
>
>- nature reserves
>
>- railway and ferry lines
>
>- big military areas
>
>
>What we don't have there:
>
>- big landuses, like forests, farmlands, sands and grasslands
>
>- ocean and sea names
>
>- continent names
>
>- big deserts
>
>- big mountain chains
>
>- big rivers
>
>
>Of course we can have some of them, but while landuses can be added 
>quite easily, it's different with the rest. Rivers have their own 
>problems, which we've just started to solve with crafting some 
>classification, but all the big area objects share at least one common 
>issue: lack of precise borders.
>
>That's probably why we have Asia mapped as a node in the middle of
>nowhere:
>
>http://www.openstreetmap.org/node/36966065
>
>the same for Andes:
>
>http://www.openstreetmap.org/node/3446705497
>
>and not a trace of Sahara _desert_ in Nominatim:
>
>http://www.openstreetmap.org/search?query=sahara
>
>
>You get the picture probably. We started as a city-scale project with 
>routing as the most important goal, but now we're "The map" for every 
>GIS data-related activity. I think this is the time to look how should 
>we map the biggest objects in the world? Our attitude is high accuracy 
>and ground truth, which are not easy to apply there.
>
>There are also other problems, like no special tools for macro objects 
>probably - for example Overpass service is choking with some data 
>requests even at country level. Another problem is importing data for 
>planet/continents, because there's too much of them already. There is a
>
>tool to filter some of them (
>https://github.com/gmgeo/osm-carto-lowzoom 
>), but it's not easy to customize - you need some programming skills.
>
>How do you think we could improve macro level mapping, rendering and 
>data analysis?
>
>
>-- 
>"Like a halo in reverse" [M. Gore]
>
>
>___
>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] Draft Trademark Policy

[Yves]

" How you formulate a policy that permits osmosis and osmium but not OsmAnd,
though, I have no idea" 


How you formulate a policy that deals with the name of established projects, I 
have no idea. But should you? Maybe a far softer grandfathering rule would be 
easier. 
Yves 


Le 5 août 2017 11:37:07 GMT+02:00, Richard Fairhurst  a 
écrit :
>Roland Olbricht wrote:
>> This makes clear that neither the file name extension "osm" is 
>> jeoparday. Or you do not want to discourage people from using 
>> "osmium", "osmosis" or a range of other software.
>
>I see your point there, but conversely I am really uncomfortable with
>the
>OsmAnd situation.
>
>It's evident (from IRC, help.osm.org, other non-OSM forums etc.) that a
>lot
>of people assume OsmAnd is the official OpenStreetMap Android app. This
>is
>already a problem in terms of support burden. It could potentially
>become a
>problem for others building apps on OSM data (if users say "oh, no, I'd
>rather use the official app") or by effectively encouraging mapping for
>this
>official-sounding renderer. In brief, I don't believe we should have
>permitted OsmAnd to use that name, though by now the ship has almost
>certainly sailed.
>
>How you formulate a policy that permits osmosis and osmium but not
>OsmAnd,
>though, I have no idea.
>
>Richard
>
>
>
>--
>View this message in context:
>http://gis.19327.n8.nabble.com/Draft-Trademark-Policy-tp5900227p5900330.html
>Sent from the General Discussion mailing list archive at Nabble.com.
>
>___
>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] class=bicycle usage

[Yves]

" this highway is lower speed limit" is enough to tag, let the data consumers 
do the rest. 
Saw this in the latest OSM Weekly:
http://k1z.blog.uni-heidelberg.de/2017/07/10/reducing-stress-by-avoiding-noise-with-quiet-routing-in-openrouteservice/
Yves 

Le 16 juillet 2017 02:51:03 GMT+02:00, john whelan  a 
écrit :
>"This is primarily subjective rubbish which, IMO, has no place in OSM.
>
>"Lovely scenery." indeed "
>
>OSM has many of its roots in cycling.  A cyclist with a GPS could cover
>a
>much greater distance than a pedestrian in the days before we had the
>imagery we enjoy today.  If you look at the web sites that provide
>cycling
>routes many actually use OSM and provide different types of routing
>according to the needs of the cyclist.
>
>Locally in Ottawa we have these things called City parks where you may
>cycle over many of the paths, the NCC has what are called multiuse
>paths
>that many consider to be cycle paths. These stretch for many kilometres
>and
>a few run alongside the river Ottawa, you're quite right many commuters
>enjoy the scenery as they cycle.  We even have a few tourists who hire
>a
>bike or bring their own to travel them.  We have highways that cyclists
>may
>use but with a 60 km/hr speed limit and high traffic volumes the more
>timid
>cyclists prefer not to use them but a number of of the "spandex"
>cyclists
>seem to relish the close contact with fast moving cars.
>
>We have room in OSM for tagging to say this highway is lower speed
>limit
>and low volume traffic and suitable for more timid cyclists or this one
>is
>higher speed limit and volume of traffic but how we would tag I'm not
>sure.
>We do of course have tourism=viewpoint but that isn't quite the same as
>a
>safer route for cyclists.
>
>Cheerio John
>
>
>
>On 15 July 2017 at 19:34, Dave F  wrote:
>
>> This is primarily subjective rubbish which, IMO, has no place in OSM.
>>
>> "Lovely scenery." indeed 
>>
>> DaveF
>>
>>
>> On 15/07/2017 23:45, Rodrigo Rodríguez wrote:
>>
>>> Hello,
>>>
>>> I'm trying to map bicycle-friendly ways in my city [Managua], which
>>> doesn't have any cycleways or lanes. I'm wondering whether I should
>use
>>> the "class=bicycle" to map those ways where I usually ride on my
>bike
>>> sharing with the whole traffic (cars, buses, etc.)
>>>
>>> Is this the case where I can use this tag? I'm expecting some
>comments
>>> based on your cyclist mapping experience.
>>>
>>> Regards,
>>>
>>> ___
>>> 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] Tool for users to add wikidata tags

[Yves]

Reading the discussion, I can't help but feel greatful for Edward's effort to 
ensure good quality. Have a read again on his first post: a lot have already 
been thought already. Don't give the impression you blame the tool! 
Just a feeling, I'm not fond of external IDs in OSM myself. 
Yves 


Le 7 juin 2017 23:08:28 GMT+02:00, Edward Betts  a écrit :
>I've built a tool for mappers to match things in OSM with Wikidata and
>add the
>appropriate wikidata tag to OSM.
>
>https://osm.wikidata.link/
>
>Users can search for a administrative area or city, then pick an area
>to
>analyse. It works best if mappers pick areas they're familiar with.
>
>The matcher can take a few minutes to run. It grabs items from Wikidata
>and
>figures out a target set of tags and keys to search for. Then it
>downloads OSM
>data and looks for matches. The matching is based on tags and names,
>currently
>the wikipedia tags aren't considered.
>
>The OSM data is retrieved from the Overpass API, large (more than 1,000
>sq km)
>or dense areas might fail with a timeout error.
>
>The results are cached in the system and are available here:
>
>https://osm.wikidata.link/places
>
>Once the matching process is complete the mapper is given a tabbed page
>with
>the results. The five tabs are:
>
>  Match candidates - things on OSM that might be considered for tagging
>  Already tagged - matches that are already tagged in OSM
>  No match - items from Wikidata with no match found in OSM 
>  Wikidata query - the query used to find Wikidata items
>  Overpass query - the Overpass query to find OSM objects in this area
>
>To start tagging the mapper is able to login to OSM via OAuth. Tick
>boxes will
>appear next to the likely matches, the mapper can tick the box next to
>the
>matches they want to upload, then add a change comment and upload them
>using
>their own OSM account. Uploads within an area are combined into a
>single
>changeset.
>
>If the mapper sees an obviously incorrect match they can use the
>'report bad
>match' option to warn other mappers and provide feedback that I can use
>to
>improve the algorithm.
>
>This tools doesn't add any new objects to OSM. The only change it makes
>is
>adding a wikidata tag to existing things.
>
>My approach is to aim for a one-to-one mapping between Wikidata and
>OSM. If
>there are two or more things in OSM that look like a Wikidata item then
>it
>isn't a good match. This means for example that most road and rail
>bridges
>won't be tagged because they are represented as two OSM ways. I might
>change
>this at some point.
>
>There are occasional duplicates in Wikidata, this tool should spot them
>and
>refuse to add wikidata tags until the Wikidata duplicate is resolved.
>
>The bug/todo list is here:
>https://github.com/EdwardBetts/osm-wikidata/issues
>
>Any ideas or suggestions are welcome.
>-- 
>Edward.
>
>___
>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] HDYC, login requirement and "privacy"

[Yves]

Actually, can an OSM username be considered as 'personal data'? 
Can somebody point out to a definition of 'personal data' ? 
How would this be different from, say, my github account? 
Yves ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Responding to vandalism

[Yves]

Interesting, I didn't know such patrolling took place at a country scale in 
OSM. Have you revert/re-map stats? 

However with your point 1)you have an idea. 
How about a service rendering the area affected by an edit before 'commit'?
This preview could be the place for an additional warning about the the live 
DB. 
Yves 

Le 17 mars 2017 16:50:53 GMT+01:00, Tomas Straupis  a 
écrit :
>Let's get on the higher level first.
>There are two ways of doing it from the process perspective:
>
>1) EDIT->TEST->COMMIT
>2) EDIT->COMMIT->TEST
>
>The first one gives higher quality but also discourages edits and
>maybe even prohibits edits in areas with no/few "checkers".
>
>So obviously the way to go for OSM is option 2.
>
>Now here what has to be done is an appropriate testing mechanism.
>There are some functionality already done (like the one in Belgium),
>but the problem is that everybody sees ALL last changes, there is no
>way to SHARE the work of checking and you never know if somebody has
>already checked the changeset.
>
>What we are doing in Lithuania for the last 5 years or so is we have a
>patrolling mechanism similar to wikipedia. That is all changesets in
>the region (in our case in Lithuania) are filtered out and placed into
>"check list". If the editor is known good mapper - his/her edits are
>"approved" automatically. Otherwise somebody with a status of "known"
>mapper should approve it. But when the changeset is approved - it does
>not show up for other "approvers". This way we avoid double work. So
>in practice this allows us to review only "suspicious" changes and in
>5 year of experience this worked out perfectly - all bad/suspicious
>changes have been noticed in a matter of hours! (for example all
>suspicious crap.me edits can be reverted promptly)
>
>So my suggestion is to add some global "patrolling" mechanism with
>division to regions (maybe by countries, maybe by country regions for
>large countries). So if there are people interested in some region,
>they will review the changesets, if there is nobody interested -
>nobody will review, but changes will be in database anyway - so no
>preventing of edits.
>
>P.S. Second step would be more automated checks but that is a separate
>topic and should only go after this first one is solved/implemented.
>
>-- 
>Tomas
>
>___
>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] Responding to vandalism

[Yves]

Another approach is a middle player between the raw DB and the data consumers. 
Yves ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk