Proposed features/shop as post-partner
|shop as post-partner|
|Definition:||Tagging for post services in other shops and amenities on behalf of a postal service provider (normaly operated by the employees of the shop/amenity), like gas-stations or supermarkets.|
- The tag post_office=* replaces post_office:type=bureau;post_annex;post_partner.
- In order to this: post_office:type=* is deprecated.
- The tag post_office=post_partner is approved for tagging post offices/postal service points, that can not marked as amenity=post_office, e.g. these are part of another shop=* or another amenity=*.
- The subtags (see Tagging section) are approved for tagging information about a post_office=* or an amenity=post_office.
- Create a list of postal service providers on the page Key:post office/service providers.
In Germany and other countries there are more and more supermarkets, kiosks, petrol stations and other facilities that offer services such as parcel acceptance, stamp sales and others for various postal service providers. So far there has not been a uniform concept for tagging these "post partners" – there is a lack of uniform standard/procedure, which makes mapping difficult and slows it down and also hinders data consumers, for example searching.
It's clear that these locations don't represent a real post office in the sense of the tag
amenity=post_office, because the postal services offered are not clearly in the foreground and they are often only very limited instead of comprehensive. Some advocate mapping as a
amenity=post_office anyway, which is not generally possible, especially if the main service is also mapped as amenity (e.g. cafe, library, bank, or social_centre), as multiple values are not to be used (see Semi-colon value separator#When NOT to use).
Often several nodes are created for the same location.
- These procedure is against 'One_feature,_one_OSM_element' for the frequent situation where the postal services have no own-operated dedicated area (no "shop in the shop" like in a supermarket a small bakery with own till & desk and staff) but are served by the same staff as all other services & goods.
- This results in more elements for mapping as well as analysis and inflates the amount of data (opening hours, contact data, payments, etc. must be recorded redundantly for both nodes).
- This increases the likelihood of incorrect entries, e.g
- This has the advantage that renderers represent both offers or service types.
Not everytime the postal service provider is an operator of a post office, so post_office:service_provider=* is introduced in order to be able to clearly identify them. To make the use clear, there should be a wiki page, wich discribes the amount of postal service providers.
- post_office=bureau - Full post office which is operated by the postal service provider. E.g. in france known as "bureau de poste".
- post_office=post_annex - (Full) Post office which is operated by private/ for the postal service provider. Some postal services can be restricted (e.g. financial transactions). E.g. called in France "Agence postale communale", in Germany "Postagentur".
- post_office=post_partner - A relay point in shops or amenities for a limited amount of postal services like letters, parcels, packets provided as a complementary business. E.g. called in France "Relais poste commerçant", in Germany often "Paketshop".
postal services in other institutions
The node or the area which is already tagged with the tags
office=* or similar, and which also offers a postal service, receives the tag post_office=*. Further content is specified by subtags.
Note: If there are spaces or other special characters in the brand name, replace them in the keys for detailed information (in "<brand>") with an underscore
_ (see examples and see Any tags you like).
|post_office=*||bureau ; post_annex ; post_partner||required|
|post_office:brand=*||name(s) of the brands.
Several separated by semicolons
|- Deutsche Post
- DHL Paketshop
- biberpost Service-Stelle
- Hermes PaketShop
|Brand(s) under which the postal services are/post office is offered.|
(of the post_office brand)
|optional||Q5266289||The ID allows to clearly identify the postal service brand in a machine-readable manner, which opens up many options, such as displaying the logo or the correct translation on a map. For details see brand:wikidata.
Deutsche Post Q5266289
Hermes PaketShop Q105702843
|post_office:service_provider=*||name(s) of the postal service providers||optional||- Deutsche Post
- Mediengruppe Magdeburg (biberpost)
- Hermes Group
|Name(s) of the postal service providers
|post_office:<service>=*||yes | list of service providers||optional||- DHL;Hermes Group||Use yes for the service is offered (analogical to e.g. materials in Key:recycling)
If a service (see below) is offered for/by multiple service providers, you can list them. Service providers must be named like in post_office:service_provider=*.
For the service providers, there should be a list of them in the wiki as orientation for users and dataconsumer.
(by a postal service provider)
|optional||123||Service providers must be named like in post_office:service_provider=*, but all characters in lower case and spaces must be replaced with underscores '_' (because it's the key not the value). Example: "Deutsche Post" -> "deutsche_post".
|post_office:collection_times=*||time, analogical as collection_times=*||optional||Mo-Fr 16:45; Sa-So 12:00||Deadline for processing and shipping on the day of posting|
|post_office:opening_hours=*||opening hours, analogical as opening_hours=*||optional||Mo:So 10:00-24:00||Optional information; useful, if the opening times of the postal services differ from the general opening times (e.g. gas stations with night counters)|
Services that may be listed in post_office:<service>=*:
|letter_from||dispatch (handing in for sending) of letters|
|parcel_from||dispatch (handing in for sending) of parcels|
|parcel_pickup||parcel pickup of missed shipments|
|parcel_to||alternative delivery address ('send the parcel to the shop')|
|stamps||sale of stamps|
|oversized_item||dispatch and/or pickup of bulky goods, e.g. bicycles, sports equipment or car tires|
|packaging||sale of cardboard boxes, cushioning material, letter paper and envelopes. If there is a wider range of stationery items, also tag it as shop=stationery.|
|post_bank||services of a "post office savings bank"|
|id_check||Identity check for mobile phone contracts, account opening, De-Mail, etc.|
Example 1 - "HANDY SHOP STADTFELD"
shop=mobile_phone name=HANDY SHOP post_office=post_partner post_office:brand=Hermes PaketShop post_office:brand:wikidata=Q105702843 // Optional Information about services post_office:service_provider=Hermes Group post_office:parcel_send_in=yes post_office:parcel_mail_in=yes post_office:parcel_pickup=yes
Example 2 - Kiosk with multiple service
After a project phase, the first multi-label parcel shop was opened in Hamburg in 2018. In sparsely populated areas in particular, the settlement of several postal service providers in one shop would be conceivable.
shop=kiosk name=Lotto Kiosk post_office=post_partner post_office:brand=DHL-Paketshop;Hermes PaketShop // Optional Information about services post_office:service_provider=Deutsche Post;DHL;Hermes Group post_office:letter=Deutsche Post post_office:parcel_to=DHL post_office:parcel_from=DHL;Hermes Group post_office:parcel_pickup=DHL;Hermes Group post_office:stamps=Deutsche Post ref:deutsche_post=128
- List the new Tag post_office=* in the Key-Pages of shop=* , amenity=* and craft=*
- Reference in amenity=post_office
Discussions in other OSM media than the wiki, found so far:
- "Paketshops" of 2018-07-06 at https://forum.openstreetmap.org/viewtopic.php?pid=811583 (german)
- "Taggingfrage #2: Paketshop" of 2019-04-27 https://forum.openstreetmap.org/viewtopic.php?id=66069 (german)
- Tag standard needed for "a post_office in a store" of 2020-09-19 https://forum.openstreetmap.org/viewtopic.php?pid=817269 (english)
- Feature Proposal - RFC - shop as post-partner of 2/2021 in the tagging mailing list
Please comment on the discussion page.
- I approve this proposal. Despite some typing/translation errors which can be resolved when creating the final page, this is a complex, but clear defined proposal. It addresses the evolving new concepts and services for postal services well, taking into account different regions and countries. A solid base to incorporate future improvements, diverse and changing services and good strategy to link OSM to wikidata. --Bert Araali (talk) 14:56, 28 April 2021 (UTC)
- I approve this proposal. I've long thought this was a gap in tagging, this seems like a good way to approach it.--Neuhausr (talk) 15:17, 28 April 2021 (UTC)
- I have comments but abstain from voting on this proposal. I am a bit unsure about this. It seems to generally to work well and although I find it problematic to deprecate a tag with 11,6k usage for one with 500, I agree that "*:type" is to discourage in general, as it adds nothing. The actual issue I see is how to deal with situations where a place offers services on behalf of several postal service providers. It might still "work" if they all provide the same services, but if there are different services it will break (e.g. for "post_office:collection_times" it is very likely that they will be different for different companies). The solution could be to require a list of all names in "post_office:service_provider" and use the individual names from this list as component of the keys for the services, e.g. post_office:service_provider=UPS;DPD and post_office:collection_times:UPS=* --Dieterdreist (talk) 10:49, 29 April 2021 (UTC)
- I suggest to check the discussion page - this option was turned down. Shortly after the proposal started, we had about a dozen POI mapped like this - and they had 4 or 5 different spellings of the same company in the key. Such a tagging scheme will end in a mess. --Mueschel (talk) 15:19, 29 April 2021 (UTC)
- I approve this proposal. There will always be edge cases that can't be tagged, but this scheme should be able to cover the vast majority of cases. --Mueschel (talk) 15:19, 29 April 2021 (UTC)
- are you sure the situation I described is an edge case? —Dieterdreist (talk) 18:19, 29 April 2021 (UTC)
- I approve this proposal. I've went through a bunch of shops offering these features and never found a way to tag them properly. This tagging scheme seems to offer what was missing.--GOo (talk) 13:50, 30 April 2021 (UTC)
- I approve this proposal. --SherbetS (talk) 03:15, 1 May 2021 (UTC)
- I approve this proposal. which IMHO is clear/understandable, consistent, sufficient for most of such features and data consumer's services, extensible, compatible with other tags for all situations that came to my mind during the extended discussion, well usable for mappers and data consumers, usable on global scope. Compared to the last "iteration" of February, I see the advantage of both renaming to post_office (existing key is better than existing value) and to "avoid arbitrary keys" by pivoting services & brands for the sub keys. I'd be happy to use it! --Schoschi (talk) 12:22, 2 May 2021 (UTC)
- I have comments but abstain from voting on this proposal. I am a bit unsure about this. It seems to generally to work well and although I find it problematic to deprecate a tag with 11,6k usage for one with 500, I agree that "*:type" is to discourage in general, as it adds nothing. +1. BTW Talk:#wikidata_or_brand_name_preferred? doesn't clarify how to map collection times for instance: what is the brand part: the colloquial name ? The wikidata tag? Except if it's a wikidata tag, it'll be a mess. And it will be a mess anyway, except if it's retrieved by some bots as it's done in France for post offices. --Nospam2005 (talk) 18:37, 5 May 2021 (UTC)
- I have comments but abstain from voting on this proposal. I missed something important: Unlike the above, I'm more in doubt over using names in post_office:(service)=*, so I would like further suggest eg post_office:(service):brand=* if desirable. For different attributes by each courier, I wonder whether *:conditional=* can be used, considering comment in opening_hours=* syntax is not standardizable and parsable); if not, a post_office:brand=Deutsche Post;& + post_office:brand:ref=DPAG;* to match with post_office:*:DPAG=* (ideally there would be an international standard code), instead of the ref:(service_provider)=* currently proposed (may be very long and cumbersome). As a minor note, you forgot to change Proposed_features/shop_as_post-partner#Services from post_office:*_from=* to post_office:*_mail_in=*. ---- Kovposch (talk) 20:31, 5 May 2021 (UTC)
- @Kovposch: That are 3 points, right? Then I would anser them so:
- Your opinion for post_office=* is recogniced.
- For the conditional I really don't thought about it....
- That with the service provider I haven't understand yet. Feel free to mail me. But a short-Value could invented to the service_provider-table i proposed in the tagging section. So the identifier for Deutsche Post/DHL could be DE_DPAG. I don't know or found a real international code for postal service provider anywhere.
- with the letter_from and letter_mail_in - there was a suggestion from nospam2005 in the discussion.
- --SafetyIng (talk) 14:15, 7 May 2021 (UTC)
- I approve this proposal. --Lkw (talk) 20:19, 7 May 2021 (UTC)
- I approve this proposal. --Tordanik 20:48, 7 May 2021 (UTC)
- I approve this proposal. --Klnkengi (talk) 12:46, 8 May 2021 (UTC)
- I approve this proposal. --Maxbe (talk) 08:59, 9 May 2021 (UTC)
- I approve this proposal. --Thetornado76 (talk) 03:26, 10 May 2021 (UTC)
- I approve this proposal. --kartonage (talk) 11:59, 16 May 2021 (UTC)
- I approve this proposal. --EneaSuper (talk) 12:57, 16 May 2021 (UTC)
- I oppose this proposal. Confusion between postal services and carrier's point of delivery --Deuzeffe (talk) 13:22, 16 May 2021 (UTC)
- I approve this proposal. --ForgottenHero (talk) 14:00, 16 May 2021 (UTC)
- I approve this proposal. --O0ps! (talk) 16:07, 16 May 2021 (UTC)
- I approve this proposal. --Helmut Kauer (talk) 16:18, 16 May 2021 (UTC)
- I approve this proposal. Thank you for the proposal. I see just one issue : post_office:collection_times=* will usually not be usable when there is multiple service providers in the same spot. --18:25, 16 May 2021 (UTC)
- I approve this proposal. --Reinhard12 (talk) 20:13, 16 May 2021 (UTC)
- I approve this proposal. --Ralley (talk) 20:39, 16 May 2021 (UTC)
- I approve this proposal. --Piotr Strębski (talk) 06:39, 17 May 2021 (UTC)
- I approve this proposal. --HirschKauz (talk) 08:51, 17 May 2021 (UTC)
- I have comments but abstain from voting on this proposal. I have a few remarks for practical implementation: Today, when I am walking htrough a for me unknown city and want to use a postal service, I select OSMAND on my smartphone, look for a postal icon of the corresponding provider on the map and select it. Then I see details such as opening hours. With the new implementation, I will only see e.g. a newsstand, a souvenir shop or a flower shop for now. If someone know how to use the search function, he will find a post office under these circumstances. But if 3 different providers are attached to one icon, the list of features displayed on the smartphone will become so long (e.g. due to different service times) that I fear the overview will be lost. --Protoxenus (talk) 09:52, 17 May 2021 (UTC)
- I approve this proposal. --Ibanez (talk) 15:41, 17 May 2021 (UTC)
- I approve this proposal. --OSMRogerWilco (talk) 18:50, 18 May 2021 (UTC)