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

[Bert -Araali- Van Opstal]

On 27/02/2021 19:47, Georg wrote:
>
> Am 2021-02-27 um 16:47 schrieb Bert -Araali- Van Opstal:
>
> > - tag a building as amenity shop, supermarket, bank, postal office
> > etc...,  and tag it with it's primary service keys.  Apply one unique
> > name. In the building add additional names for the supplementary
> > services you want to map, without providing a name.
>
> While I like this "linking approach" quite a lot for its simplicity,
> IMHO it is not a well feasible solution for our case: In Germany, a
> _considerable_ share of shops/offices/amenities offering also postal
> services are not having a complete building on their own (like building
> supply markets usually have), nor is indoor mapping common enough that
> they have a polygon on their own (e.g. within a shopping mall), but many
> of these shops/offices/amenities are mapped as points only - as a point
> does not stretch, it can't contain anything.
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.
This tagging scheme in the mean time is extended, so we use operator and 
owner keys to distinguish one service from another, with the same 
motivation, so f.i. if a shop provides postal services from company A as 
well as from company B, again we split it in different nodes with owner 
(owner of the service provided since the shop is a licensor, brand=* is 
another candidate) is owner=Company A and another node with 
owner=Company B.
>
>> 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.  Maybe because they were never well documented ? You 
can however use them in Nominatim, works perfect. I know we should not 
tag for rendering but at that time it was a breaking point not to use 
relations, also because relations are not feasible for most beginner 
mappers.
>
> > Reflecting this back to your proposal you could use the same
> > principals with a minimum of specific service keys in your cases.
>
> I will add this into the proposal so we can start discussion on it.
> Thanks for pointing out!
>
> Georg
>
> _______________________________________________
> 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/2ee1e78c/attachment.htm>