Re: [Tagging] Deprecating of leisure=common and leisure=village_green

W dniu 01.12.2017 o 02:19, Warin pisze: Were not 'commons' used for more than 'recreation'? I think they were used for grazing and camping too? "Historically these rights typically included the right to graze livestock, collect firewood, or cut turf. Today they include the rights to use the

Re: [Tagging] Deprecating of leisure=common and leisure=village_green

On 01-Dec-17 11:33 AM, Daniel Koć wrote: (It's about landuse=village_green, not leisure=village_green, of course...) W dniu 01.12.2017 o 00:47, ajt1...@gmail.com pisze: This sounds like a severe case of the tail wagging the dog - the fact that one particular renderer might not want to render

Re: [Tagging] Deprecating of leisure=common and leisure=village_green

(It's about landuse=village_green, not leisure=village_green, of course...) W dniu 01.12.2017 o 00:47, ajt1...@gmail.com pisze: This sounds like a severe case of the tail wagging the dog - the fact that one particular renderer might not want to render a certain tag in the future is not a

Re: [Tagging] Deprecating of leisure=common and leisure=village_green

On 30/11/2017 22:45, Daniel Koć wrote: While making some cleaning in osm-carto we have found that leisure=common and leisure=village_green are probably not clear enough to show them any more. They both have deep roots in British law and history and are frequently misused, as far as I can tell.

[Tagging] Deprecating of leisure=common and leisure=village_green

While making some cleaning in osm-carto we have found that leisure=common and leisure=village_green are probably not clear enough to show them any more. They both have deep roots in British law and history and are frequently misused, as far as I can tell. Both are very popular - 57k and 86k

Re: [Tagging] Permanent IDs RFC (was part_of:wikidata)

On Thu, Nov 30, 2017 at 2:30 PM, Yuri Astrakhan wrote: > Erkin, the whole idea of the permanent ID is for it to always point to the > same "conceptual" object. If I create a road, and use an ID for that road > somewhere, I would like that ID to continue working even if

Re: [Tagging] Permanent IDs RFC (was part_of:wikidata)

30-11-2017 22:56 tarihinde Yuri Astrakhan yazdı: > > If you edit a road, a new one would be created and would point to its > invalidated ancestor. Recursively chasing previous ID pointers, you > would eventually have an object without an ancestor. ID of that object > would also be

Re: [Tagging] Permanent IDs RFC (was part_of:wikidata)

> If you edit a road, a new one would be created and would point to its > invalidated ancestor. Recursively chasing previous ID pointers, you > would eventually have an object without an ancestor. ID of that object > would also be permanent ID of the successor objects. This will also > solve road

Re: [Tagging] Permanent IDs RFC (was part_of:wikidata)

Le 30. 11. 17 à 20:30, Yuri Astrakhan a écrit : > If I create a road, and use an ID for that road somewhere, I would like > that ID to continue working even if the road gets broken up into > multiple segments. why not use the existing overpass features ? you can define which criteria determine

Re: [Tagging] Permanent IDs RFC (was part_of:wikidata)

If you edit a road, a new one would be created and would point to its invalidated ancestor. Recursively chasing previous ID pointers, you would eventually have an object without an ancestor. ID of that object would also be permanent ID of the successor objects. This will also solve road split

Re: [Tagging] Permanent IDs RFC (was part_of:wikidata)

> > Immutable objects with a previous ID field would solve that. Every edit > will create or delete, no modify. First version's ID will be your > persistent ID. > Erkin, the whole idea of the permanent ID is for it to always point to the same "conceptual" object. If I create a road, and use an ID

Re: [Tagging] Permanent IDs RFC (was part_of:wikidata)

Yuri Astrakhan wrote: > Implementing the permanent ID is conceptually (relatively) simple, but > would require a lot of work.  "When to break continuity" seems to be > the philosophical sticking point, as pointed out by others in this > discussion.  We could agree on some general continuity

Re: [Tagging] Permanent IDs RFC (was part_of:wikidata)

> > I think permanent IDs should be done with our own Wikidata. Wikibase is a > Wikimedia extension, that means our own Wiki can install OSMData right now. > Then if you want to open a permanent ID for a shop, create a new OSMData > item, and tag the shop with OSMData=M38267 (M instead of Q, for

Re: [Tagging] Permanent IDs RFC (was part_of:wikidata)

I think permanent IDs should be done with our own Wikidata. Wikibase is a Wikimedia extension, that means our own Wiki can install OSMData right now. Then if you want to open a permanent ID for a shop, create a new OSMData item, and tag the shop with OSMData=M38267 (M instead of Q, for Map). This

Re: [Tagging] part_of:wikidata key

On Thursday 30 November 2017, Marc Gemis wrote: > Do I understand it correctly that one of the reasons you do not want > to use Wikidata IDs because the data on the item is not verified > according to the same rules as OSM ? Not because the data is not already verified but because it is not

Re: [Tagging] Permanent IDs RFC (was part_of:wikidata)

On Thursday 30 November 2017, Frederik Ramm wrote: > > Biggest issue IMHO that came up in the UUID discussion is that it is > unclear what the ID relates to, and mappers cannot be expected to > handle that topic in all its complexity properly. Note essentially the same applies to wikidata tags -

Re: [Tagging] Permanent IDs RFC (was part_of:wikidata)

2017-11-30 7:42 GMT+01:00, Yuri Astrakhan : >> * What if the shop moves to a new address ? What if someone already >> recorded the shop at the new location, how do we merge the IDs? > If we decide that a moved shop should have the same id, than this is a case > for

Re: [Tagging] Permanent IDs RFC (was part_of:wikidata)

Immutable objects with a previous ID field would solve that. Every edit will create or delete, no modify. First version's ID will be your persistent ID. 30-11-2017 10:28 tarihinde Frederik Ramm yazdı: > Ah, I forgot to say: The result of many, lengthy, previous discussions > about permanent IDs