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

[Georg]

Am 2021-02-27 um 16:47 schrieb Bert -Araali- Van Opstal:
> I thought I've given this explanation how we solved a similar concept:

Yes, you had 2021-02-16 16:43 and I whish I had read it _before_ sending
my reply to your other post dating 2021-02-16 15:32... sorry!

> In Africa we use mobile_money.  [...] all telecom services have
> local licensors where you can physically deposit and collect cash.
> However most of them don't have seprate counters and deliver the  > services additionally to there main activities.

This is indeed very related to the postal partner situation.

> you create separate nodes which have a separate key.

 > the options you have are:
 >
 > - 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.

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

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

 > 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