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

Bert -Araali- Van Opstal bert.araali.afritastic at gmail.com
Sat Feb 27 15:47:19 UTC 2021


I agree, it is a mess, but trying to solve that now in this proposal 
seems to me as a very bad idea.

@georg

I thought I've given this explanation how we solved a similar concept:
In Africa we use mobile_money.  A digital wallet service provided by all 
telecom providers. They are not banks, but all telecom services have 
local licensors where you can physically deposit and collect cash.  
These local licensors can very broadly, they can be dedicated, kiosks, 
supermarkets, banks and even some ATM's. However most of them don't have 
seprate counters and deliver the services additionally to there main 
activities.
We struggled with the same issue as you did, they are not banks, yet 
they deliver a service, we didn't want multiple values in main keys like 
shop=* or amenity.  So we decided it is not wrong to use a separate tag 
to describe a distinctive secondary service.  The value we used is 
mostly bureaux_de_change, money_exchange. We change digital money into 
cash. Same could be applied for your case, you create separate nodes 
which have a separate key.
The relationship or link to the main activities of these service 
providers is by putting these nodes within the same building. You can 
give the building the shop name and the nodes within the building, 
either can have the same name, which is of course not so optimal because 
you create duplicated data, or a variant like adding that particular 
service to the name. F.i. the building would carry the name = Shopright 
A, it contains a shop=supermarket node with the name=Shopright 
Supermarket, and another node amenity=post_office or office=courier as 
you like with the name=Shopright Postal service or Postal service by 
Shopright.  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.  But we have some candidates 
like relation=site, relation=cluster (you consider it as a cluster of 
services provided by one shop, the name is unique and defined in the 
relation.  Surely room for improvement.
To summarize: I don't see any objections or discouragement to use 
different nodes for different services, although in the ground truth 
they are served from the same counter, but mostly indivdiually 
signposted.  So not really a violation of the general OSM principles in 
my honest opinion.

On 27/02/2021 18:18, Marc_marc wrote:
> Le 27.02.21 à 16:09, Georg a écrit :
>> office=courier has a purpose closely related to
> the office=* key is being a mess with both
> internal company offices
> and
> "service stores" like office=insurance (it's more like a shop=*)
>
>
>
> _______________________________________________
> 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/c60cc0b2/attachment-0001.htm>


More information about the Tagging mailing list