[Tagging] Feature Proposal - RFC - shop as post-partner

[Bert -Araali- Van Opstal]

On 27/02/2021 20:55, Robin Burek wrote:
> I could cry....
>
>
>> Very true, same here, but that shoudn't stop you from using different
>> nodes which are closely mapped to each other. When someone searches
>> for a specific service they will show up on the same screen. It makes
>> it also a feasible concept and easy to understand for beginner mappers.
>
> Than it is mapping for the randerer. You create extra nodes to show
> multiple services of one shop/amenity etc. to display it on the map.
> And really - I don't understand it after years. Why should I map an shop
> four or five times?!?! There is only ONE SHOP.
Nope, we don't tag primarily for tagging, we use different nodes to 
avoid duplicating data, to avoid to have to add multiple values in the 
same key. The rendering is a nice positive side effect. It's ONE shop 
with multiple services or is it ONE service supplied at ONE place.  This 
concept is used in other cases.
>
>
>>>
>>>> We also considered using relations for this to avoid
>>>> duplicate names, but at the time didn't seem a good idea because most
>>>> data consumers didn't process relations.
>>>
>>> Relations sound interesting as they avoid duplicate data AND make clear
>>> that several different features are belonging together AND it works for
>>> all kinds of features in OSM (relation/way/point).
>>>
>>> Do you know how data consumers respond to it nowadays, e.g. when
>>> searching for such a feature in maps.me or OsmAnd or Locus, do they
>>> display e.g. the opening hours of the relation, or do they at least 
>>> show
>>> the point is part of a relation and thus you can look up the opening
>>> hours manually (e.g. by following a link from point to relation)?
>>
>> We still provide the names of the service owners in the name fields,
>> because some users might prefer Company A instead of Company B and
>> some licensors provide the same service for different brands. This
>> concept was developed initially by a HOTOSM project.  So they use the
>> standard humanitarian mapping on OSM and Nominatim.  I don't know if
>> Nominatim does support searching in owner and operator keys now, At
>> the time this concept was developed it was not the case however like
>> f.i. with maps.me, I don't know if that has evolved in the mean time,
>> neither for the other ones.  It is however the reason why we still
>> duplicate the service owner names in the name fields, which is not an
>> advisable good practice but makes it work in most data consumers and
>> rendering.
>>>
>>>> But we have some candidates like relation=site, relation=cluster
>>>
>>> I found only the proposals under way
>>> https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site and
>>> https://wiki.openstreetmap.org/wiki/Relations/Proposed/Cluster despite
>>> >>100k uses?! Amazing.
>>>
>>> I think relation=site would be suited for the postal partner case.
>> True, they do exist since long time, developed when there was a need
>> to develop parent-child relations which never got well documented.
>> We have a big improvement to make in that.  We didn't consider it as
>> a feasible solution because the names of these relations (site /
>> cluster but also group which is somehow identical to cluster) don't
>> show up in any rendering in OSM.�
> The problem is - when and where you want to display the name on wide
> range sites like [1] - but it is a different problem that is not
> supposed to be discussed here.
Agree, no need to discuss that here, just wanted to give it as a 
justification why it was not considered as feasible in that particular 
project, because it's not rendered, but we don't tag for the renderer !
However, although we all agree with that concept, many consider other 
tagging schemes, not relations as more favourable without saying 
explicitly it's because of rendering issues.
>
> [1] - https://www.openstreetmap.org/relation/128009
>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20210227/c09b3257/attachment.htm>