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

[Daniel Koć]

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 land for certain leisure activities."


"Rights would normally not include camping, lighting a fire, or holding 
an event without the owner's permission."


[ https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dcommon ]

Sounds to me like "no" for both and "yes" for recreation.

--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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

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

[Warin]

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 a certain tag 
in the future is not a reason for not using it where that tag is 
actually the most appropriate.


This is the other way around - the tagging seems to be broken, so we 
think of dropping it. It's a common pattern to neglect problems just 
because they happened to bite us during rendering development process.


Let's see:

1. "A *village green* is a distinctive part of a village centre. [...] 
This tag is very often *not* used to map the situation above, but to 
map all kinds of mixed vegetation"


- that's 2 different meanings, with the second being full blown 
misinterpretation, probably tagging for rendering just because it 
sounds similar and it was visible on default map.


2. "In the UK common land is registered. [...] Use leisure 
=common to identify 
land over which the public has general rights of use for certain 
leisure activities."


Sounds like stretching UK legal definition for some reasons.



Were not 'commons' used for more than 'recreation'? I think they were 
used for grazing and camping too?


landuse=recreation_ground or leisure=recreation_ground are not loaded 
with local customs and would be good candidates to take over (they are 
both currently rendered on default map style, which would make 
transition much easier in practice).



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

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

[Daniel Koć]

(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 reason for not using it where that tag is actually 
the most appropriate.


This is the other way around - the tagging seems to be broken, so we 
think of dropping it. It's a common pattern to neglect problems just 
because they happened to bite us during rendering development process.


Let's see:

1. "A *village green* is a distinctive part of a village centre. [...] 
This tag is very often *not* used to map the situation above, but to map 
all kinds of mixed vegetation"


- that's 2 different meanings, with the second being full blown 
misinterpretation, probably tagging for rendering just because it sounds 
similar and it was visible on default map.


2. "In the UK common land is registered. [...] Use leisure 
=common to identify 
land over which the public has general rights of use for certain leisure 
activities."


Sounds like stretching UK legal definition for some reasons.

landuse=recreation_ground or leisure=recreation_ground are not loaded 
with local customs and would be good candidates to take over (they are 
both currently rendered on default map style, which would make 
transition much easier in practice).


--

"My method is uncertain/ It's a mess but it's working" [F. Apple]

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

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

[ajt1...@gmail.com]

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.


Both are very popular - 57k and 86k uses, respectively - and still 
growing:


https://user-images.githubusercontent.com/5439713/33458839-19814f9c-d628-11e7-92fd-b51326fa8b25.png 



That means that maybe such tagging should be discouraged and replaced 
to not spread the confusion.





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 reason for not using it where that tag is actually 
the most appropriate.


Best Regards,

Andy


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

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

[Daniel Koć]

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 uses, respectively - and still growing:

https://user-images.githubusercontent.com/5439713/33458839-19814f9c-d628-11e7-92fd-b51326fa8b25.png

That means that maybe such tagging should be discouraged and replaced to 
not spread the confusion.



--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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

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

[Kevin Kenny]

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 into multiple segments.  I am not exactly sure how your approach
> would solve that.

I really favour a "good enough" solution over a "perfect" one.

The existing wikidata=* scheme is 'pretty good' in that while it won't do things
like "search for all public art works by a given artist", it will
allow backlinking
to specific objects in OSM by means of an Overpass query.

Few mappers, when casually splitting a way, simply delete tags willy-nilly.
Moreover, most way splitting happens in order to do things like add part of
the way to a route relation, put a traffic restriction on part of the
way, or other
things that don't change the 'identity' of the given way, so a 'wikidata=*'
tag is highly likely to be conserved. (If mappers simply replace one way
with another, obviously all bets are off, but that's already regarded as
impolite, particularly if they destroy existing tagging while doing so.)

If we abandon the idea that the back link must be to a single OSM object
and instead think of it as a link to a set of objects (ideally singleton, but
possibly zero, or more than one), to what extent does the problem go
away? The data link in both directions, and the tag is likely to be conserved
even when the underlying objects are restructured.

Is this at least the 90% solution? Will it buy us time and the opportunity
to grow into a better answer? What am I missing?

For what it's worth, I already maintain a few sets of [mostly imported]
objects in the database that bear tags whose values are
ID's in several foreign databases. "Any tag you like."
They are there precisely so that I can use them as forward links
and use Overpass queries as back links. I don't demand that they
be 100% stable, just that I have some likelihood of finding again an
object that I labeled once before. If mappers mess up a few of them,
it's no big deal, I don't expect crowdsourced data to follow any
external schema rigorously. Just as with anything else on the Web,
broken links happen sometimes. If the tags were deleted wholesale,
that would make me quite cross, particularly since we have no better
theory about how to deal (even approximately) with references between
our data and data housed in other repositories.

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

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

[Erkin Alp Güney]

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 permanent ID of the successor objects. This will also
> solve road split problems as multiple objects can point to the same
> ancestor.
>
>
> Erikn, if I understood you correctly, you are proposing the data
> structure to generate and track IDs.  I think there are several issues:
> * determining feature ID requires O(N) - linear search through history.
If you just want the latest version, one lookup. If you want ancestors
and descendants, linear pointer chase.
> * given an ID, if you want to examine what it points to, you have to
> assemble the whole tree of descendants to determine all of the leafs,
> and test if they still exist or were deleted. Which also means that
> instead of a human-currated single relation for the multi-segment
> road, and a single list of tags, you are now looking at a set of
> objects, each with its own list of tags.
ID-only lean tree may be stored at the server side. You will then only
download the objects you actually want.
> * Download must contain an entire OSM change history to work with the
> IDs offline
>
See git's shallow cloning. As OSM IDs are linear counter rather than
hashes, it is even easier to work: You can prune objects by ID thresholding.

Yours, faithfully
Erkin Alp

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

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

[Yuri Astrakhan]

> 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 problems as multiple objects can point to the same
> ancestor.
>

Erikn, if I understood you correctly, you are proposing the data structure
to generate and track IDs.  I think there are several issues:
* determining feature ID requires O(N) - linear search through history.
* given an ID, if you want to examine what it points to, you have to
assemble the whole tree of descendants to determine all of the leafs, and
test if they still exist or were deleted. Which also means that instead of
a human-currated single relation for the multi-segment road, and a single
list of tags, you are now looking at a set of objects, each with its own
list of tags.
* Download must contain an entire OSM change history to work with the IDs
offline
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[marc marc]

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 whether or not an object is 
always the same in the event of a change.
For example :
- a road in a city with such a name. If the way is divided, merged, 
delete+create, it will always have the same query id.
if the way is cut in 2 with a part that changes its name, this part will 
no longer be linked to the id of the previous request.
- In case of poi in a building, you can easily create an id for the 
building and another id for the poi.
- a poi that can close or move : you can make a request id related to 
the poi at this specific location (and which will correspond to the new 
business if the previous one closes) or you can choose if the id 
corresponds to the poi even if it moves to the next street.

Or course mabe we can create a OsmData that host and/or redirect to 
overpass query. but it'll avoid the need to make software change at a 
large-scale to work.

Regards,
Marc
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Erkin Alp Güney]

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 problems as multiple objects can point to the same
ancestor.


30-11-2017 22:30 tarihinde Yuri Astrakhan yazdı:
>
> 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 for
> that road somewhere, I would like that ID to continue working even if
> the road gets broken up into multiple segments.  I am not exactly sure
> how your approach would solve that.
Yours, faithfully
Erkin Alp


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

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

[Yuri Astrakhan]

>
> 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 for that road
somewhere, I would like that ID to continue working even if the road gets
broken up into multiple segments.  I am not exactly sure how your approach
would solve that.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Erkin Alp Güney]

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 guidelines and
> let it be solved by each editor on a case-by-case basis.  It will
> never be perfect, but neither is not doing anything.
>
Immutable objects with ancestor pointer fields are far easier to
implement than implementing a Wikidata analog for OSM.

Yours, faithfully
Erkin Alp

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

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

[Yuri Astrakhan]

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

Janko, I'm all for using a better storage tech if warranted, but I don't
think introducing Wikibase will solve the problem mentioned by others --
**what is an entity?**. Wikidata community is all about defining those
conceptual entities, and OSM community is mostly concerned with reflecting
the current state of the world.  In other words, OSM community does not
concentrate with the historical continuity -- preserving the history of a
"concept", or even specifying the definition of the "concept".

The two basic continuity questions need to be solved for permanent IDs to
become a reality:
* keeping an ID when feature's geometry change - e.g. a single road way
becomes multiple segments, merging duplicates with redirects, etc.
* deciding when to break the continuity when the feature is "no longer the
same concept" - e.g. a restaurant closed, and a new one opened in its place
needs a new ID, instead of reusing the same node.

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 guidelines and let it be solved
by each editor on a case-by-case basis.  It will never be perfect, but
neither is not doing anything.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Janko Mihelić]

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 permanent ID won't just be an empty number, but it can have all sorts
of structured data attached to it, for example Name, so mappers can see
what that ID is about.

Of course, duplicating data would be strongly discouraged, and that can be
easily done by restricting properties that can be added to items. So
property "religion" won't be available for church items, because that
property is already expected in the OSM database.

Janko
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] part_of:wikidata key

[Christoph Hormann]

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 
generally verifiable according to the rules of verifiability we have in 
OSM.  But otherwise i think you got my point here.

> For me Wikidata IDs can be viewed as URLs, just like the URL of a
> shop. If I can verify that it describes the same item (more or less
> (*)), I can add the Wikidata ID (or shop URL).

If that its the case for you you should be aware that url=* tags are 
generally considered a related URL to the feature in question, not a 
unique ID.  url=http://www.apple.com/ would be considered a valid url 
tag for all apple stores probably.  Previous discussion showed that 
some (though not all) mappers think wikidata tags have to be unique 
(i.e. each value only used once).

Website URLs will often be locally verifiable - either because of 
written information (shop sign, restaurant menu etc.) or - like with 
the name - by asking informed locals.

-- 
Christoph Hormann
http://www.imagico.de/

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

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

[Christoph Hormann]

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 - just that the 
problems are seemingly outsourced to an external project and the mapper 
does not have to deal with them - which is wrong of course.

-- 
Christoph Hormann
http://www.imagico.de/

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

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

[Martin Koppenhoefer]

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


what if the shop moves to 2 different addresses? In this case the ID
wouldn't be unique any more (or we'd have to create a relation to hold
the ID, i.e. change our mapping technique due to the ID concept, i.e.
more complexity).


>> * A restaurant POI and the building it resides in are 2 different
>> concepts, they both need their own permanent ID. How can we
>> distinguish them ?
>
> If the entire building is a restaurant (e.g. a standalone McDonald's), than
> it should probably be the same id. But if restaurant is occupying the first
> floor of a residential bldg, probably two.


No, I don't think it is a good idea to have the same ID, because many
properties will still be different (e.g. start date, architect of shop
will often be different to that of the building, operator might be
different, etc.) and many properties will only apply to one (e.g. a
building doesn't have a "cuisine" in the OSM tag sense).


> How does the software knows this when someone "joins" the POI and the
>> building ?
> Software wouldn't know, but an editor should always keep this in mind, and
> there tools should offer some "join" mechanism.


IMHO buildings and users of the building should in most cases be distinguished.



>> * What do you do when a modern part is attached to a listed building ?
>> Will the building parts have permanent IDs ?
> If the building or a road is extended, it should keep the old id. If the
> new part is notable on its own, the part may get a new id as well, while
> also being part of the old id.


"notable"? That wasn't an OSM concept until now. IMHO we would have to
have a mechanism that keeps trace of what happens to IDs (e.g. this ID
is now part of this ID, or has become this ID, or was deleted because
of a / b / c / d etc.)

Ultimately, we'll need an ID for every tag, and for every combination
of tags, of an object (i.e. a lot of IDs for every object). So every
need can be suited ;-)

I still believe OSM IDs together with versions / timestamps, are
already suitable for referring to a certain state at a given point in
time. Additional IDs introduce more problems than they promise to
solve (because mappers will have to decide what to do with them when
modifying the map, and therefore the IDs would either have to be very
finegrained (as stated above, one for every tag, and for every
combination of tags), or would sooner or later brake for some of the
usecases for which people rely on them (e.g. one mapper seeing the ID
referring to the restaurant, the other to the building).


Cheers,
Martin

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

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

[Erkin Alp Güney]

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 was generally: We don't want to shoulder the
> responsibility of maintaining a permanent ID in OSM that others can use
> for easy linking; instead, those others should be doing that work for
> themselves. Hence the idea of "fuzzy" permanent links was born, where
> your link is not really a link but a search query:


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