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

[Robin Burek]

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.


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

[1] - https://www.openstreetmap.org/relation/128009