Proposal:Shop as post-partner

From OpenStreetMap Wiki
Jump to navigation Jump to search
shop as post-partner
Proposal status: Approved (active)
Proposed by: SafetyIng
Tagging: post_office=*
Applies to: node, area
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.
Statistics:

Draft started: 2021-01-25
RFC start: 2021-01-11
Vote start: 2021-04-28
Vote end: 2021-05-19

Proposal

Rationale

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
    • if opening times, telephone numbers, etc. are updated for only one of the "actually identical" nodes.
    • Tags of both nodes could be interchangd, so e.g. shop=supermarket and brand=DHL are combined. Or the data of the actual store will be overwritten (e.g. name becomes Hermes PaketShop).
  • This has the advantage that renderers represent both offers or service types.


In Germany and here and there in other countries there is already the use of post_office=yes ; see here DE:Key:post office. In extend of this use there is this proposal developed.


To unify the tag post_office=yes replace the often in france used post_office:type=bureau;post_annex;post_partner and some new Tags are added to specify post offices.

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.

Tagging

post_office=*

The Tag post_office=* takes over the tagging from the mainly in France used Key:post office:type

  • 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 amenity=* oder shop=* oder 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).

key value for

post partner

example(s) description
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.


Only use it if the object is not an amenity=post_office

post_office:brand:wikidata=* wikidata ID

(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

- DHL

- Mediengruppe Magdeburg (biberpost)

- Hermes Group

Name(s) of the postal service providers


Could also added with wikidata subelement

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.

ref:<service_provider>=* reference ID

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


For the service providers, there should be a list of them in the wiki as orientation for users and dataconsumer.

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


Only use it if the object is not an amenity=post_office

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)


Only use it if the object is not an amenity=post_office

Services

Services that may be listed in post_office:<service>=*:

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

Examples

Example 1 - "HANDY SHOP STADTFELD"

Today the shop "Handy Shop Stadtfeld" (1004498384) is only tagged as shop=mobile_phone. With the above scheme, the shop could additionally be tagged as post partner:

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[1]. 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

Features/Pages affected

External discussions

Discussions in other OSM media than the wiki, found so far:

Comments

Please comment on the discussion page.

Voting

Voting closed

Voting on this proposal has been closed.

It was approved with 23 votes for, 1 vote against and 3 abstentions.

information sign

The voting was extended by one week (from 12.05. to 19.05.), among other things because of the missing contribution in the weekly note.
  • I approve this proposal 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 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 abstain from voting but have comments 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 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 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 I approve this proposal. --SherbetS (talk) 03:15, 1 May 2021 (UTC)
  • I approve this proposal 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 abstain from voting but have comments 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 abstain from voting but have comments 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 see that discussion now. Didn't want to bloat the voting section too much with many formatting. Let me see how I can elaborate. ---- Kovposch (talk) 16:29, 7 May 2021 (UTC)
  • I approve this proposal I approve this proposal. --Lkw (talk) 20:19, 7 May 2021 (UTC)
  • I approve this proposal I approve this proposal. --Tordanik 20:48, 7 May 2021 (UTC)
  • I approve this proposal I approve this proposal. --Klnkengi (talk) 12:46, 8 May 2021 (UTC)
  • I approve this proposal I approve this proposal. --Maxbe (talk) 08:59, 9 May 2021 (UTC)
  • I approve this proposal I approve this proposal. --Thetornado76 (talk) 03:26, 10 May 2021 (UTC)
  • I approve this proposal I approve this proposal. --kartonage (talk) 11:59, 16 May 2021 (UTC)
  • I approve this proposal I approve this proposal. --EneaSuper (talk) 12:57, 16 May 2021 (UTC)
  • I oppose this proposal 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 I approve this proposal. --ForgottenHero (talk) 14:00, 16 May 2021 (UTC)
  • I approve this proposal I approve this proposal. --O0ps! (talk) 16:07, 16 May 2021 (UTC)
  • I approve this proposal I approve this proposal. --Helmut Kauer (talk) 16:18, 16 May 2021 (UTC)
  • I approve this proposal 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 I approve this proposal. --Reinhard12 (talk) 20:13, 16 May 2021 (UTC)
  • I approve this proposal I approve this proposal. --Ralley (talk) 20:39, 16 May 2021 (UTC)
  • I approve this proposal I approve this proposal. --Piotr Strębski (talk) 06:39, 17 May 2021 (UTC)
  • I approve this proposal I approve this proposal. --HirschKauz (talk) 08:51, 17 May 2021 (UTC)
  • I abstain from voting but have comments 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 I approve this proposal. --Ibanez (talk) 15:41, 17 May 2021 (UTC)
  • I approve this proposal I approve this proposal. --OSMRogerWilco (talk) 18:50, 18 May 2021 (UTC)

Footnotes