[Tagging] Feature Proposal - RFC - shop as post-partner
Bert -Araali- Van Opstal
bert.araali.afritastic at gmail.com
Tue Feb 16 15:43:28 UTC 2021
We had a similar situation some years ago and solved it very
successfully with overwhelming community support. It is similar, allow
me to describe the problem and how we solved it:
Here in Africa we use Mobile Money services, which are wallets on your
phone provided by the private Telecom Companies. The services are
regulated by the government. Besides using your wallet from your phone,
the Telecom companies started to grant money collection and depositing
services through banks, post offices and many private shops and kiosks.
Telecom Operators provide the same collection and deposit service
through their service centres, which you mostly find only in the major
towns. SO there was a big need to map all those shops, banks, post
offices, supermarkets etc... as Mobile Money service providers.
An existing tag existed: bureau_de_change, describing perfectly the
service provided. We didn't want to change all the other amenity or top
level keys, as they are not incorrect, and we didn't want to introduce
multiple values in one key. SO we decided to follow the OSM guideline
"one feature, one tag". Created new nodes, next to all these other
nodes and provided all the necessary details, brand , operator, owner,
contacts etc..., all using existing tags, there was no need to introduce
subkeys etc... just some specific values used in this context.
This led to many nodes with duplicate names (name of the shop or
supermarket is same as the name of the bureau_de_change service
provider. We solved that problem not consistently but 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.
- provide different nodes for different services or products provided.
Can be located in a building as such, tagged with a unique name, or
several different nodes, they can all have a different operator and a
different service. You can use a group relation if you wish to connect
them together if you want to use just a single name (no duplicate data).
This one also solved the problem that in some cases the same service was
provided for different brands (telecom operators in our case) at the
same place. You could use different values in brand separated by ; but
different nodes for every service is better, because it is not said that
this particular place delivers service A and B for brand 1, but maybe
only service A for brand 2.
Reflecting this back to your proposal you could use the same principals
with a minimum of specific service keys in your cases. Using
office=courier or office=logistics, add brand, operator etc... all to a
new node. Map them in the same building if they operate under a common
name or create a group relation to define the common keys.
How does that sound ?
Greetings, Bert Araali
On 16/02/2021 18:10, Robin Burek wrote:
> Am 16.02.2021 um 15:32 schrieb Bert -Araali- Van Opstal:
>> My analysis:
>>
>> If we refer to wikipedia (https://en.wikipedia.org/wiki/Post_office)
>> the term post office, postal service refers " to government postal
>> facilities providing customer service." in most parts of the world.
>> And luckily wikipedia refers to the German situation: "Private
>> courier <https://en.wikipedia.org/wiki/Courier> and delivery services
>> <https://en.wikipedia.org/wiki/Package_delivery> often have offices
>> as well, although these are not usually called "post offices," except
>> in the case of Germany <https://en.wikipedia.org/wiki/Germany>, which
>> has fully privatized its national postal system
>> <https://en.wikipedia.org/wiki/Deutsche_Post>."
>>
> Thats actually only discribe the position of "Deutsche Post" (refered
> throw the link) but not the other private postal service providers.
> (And it need to citation btw).
> I refer again to the previously quoted Wikipedia entry "mail": "The
> mail or post is a system for physically transporting postcards,
> letters, and parcels." - Just because there are many private providers
> and no state postal service in Germany, these are still postal
> services. And wikipedia clearly includes parcels here.
>
>> I'd like to propose the following to get this discussion going again
>> and proceed with the proposal since it looks fine and clearly defines
>> a need in the community:
>>
>> Do not introduce a new key but use the existing office=courier or
>> office=logistics (I know, not widely used but .. better then to
>> introduce a new one which is not used so far). Attribute those with
>> keys to describe the services offered, which might use post or postal
>> terms in the values but do not define them as a post or postal
>> office, much as is somehow clearly described on the English Wikipedia
>> for the German situation.
>>
> In that opinion I should map the supermarket where I can buy stamps,
> send mail and send parcels for "biber post" on the normal cashier-desk
> with amenity=post_office, office=courier and shop=supermarket? Wich
> brand I should note and so on...? Or should I know create 3 Notes?
> How I should go at the kiosk where I can buy stamps for "biber post",
> send mail with "Deutsche Post" and parcels with "Deutsche Post/DHL"?
> I've look at the naming of the postal service providers - they often
> name them "service points"....
>
>
> _______________________________________________
> 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/20210216/e06d2537/attachment.htm>
More information about the Tagging
mailing list