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 w
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 merge+making one redirect to the
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 - j
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
gener
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
>
> 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 Ma
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 guidel
>
> 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
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 probl
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 w
> 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 s
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 p
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 the road gets
> broken up in
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 us
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.
(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 reaso
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
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
18 matches
Mail list logo