[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