Proposal talk:Shop as post-partner

Proposal too big and to controversy to be voted/decied with one Vote

In my opinion this proposal touches to many things at one time. While I agree with some points, but not with all, I really have a hard time to support this Proposal. The implementation of all the new tags would take years to be rolled out to all tools. And the tagging is not widely used yet. I think it would be better to concentrate on a simple improvment like the suggestion of just using the brand as post/parcel partner, like post_parter=BRAND. Once the Mappers starting to add more details and some more widely used tagging schemes are seen, we can follow up on this. --Agent redd (talk) 10:53, 17 April 2021 (UTC)

Okay...? What is to big for you? There is first post_office=brands and post_office=:type. And the other tags are absolutly optional for discribing the 'post-partner'-Element....

The main problem is - where should the mapper add infromation, e.g. about services. Although I only suggested post_office: services before, it just doesn't work with multiple providers at the same time. --SafetyIng (talk) 11:10, 17 April 2021 (UTC)

imho the 2 "main/core" issues/choices are

post_office:type (existing with 11000 objets) or post_office

post_office:brand or a-key-without-brand to store the brand (and I very dislike the idea to use a key without brand to store the brand !)

Marc marc (talk) 12:54, 18 April 2021 (UTC)

Sorry, the post is not clearly understandable for me :-| Is it a reply to the original post or the response? I don't understand how it relates to any of the two. --Schoschi (talk) 12:05, 2 May 2021 (UTC)

@"Once the Mappers starting to add more details and some more widely used tagging schemes are seen, we can follow up on this." This propsal already is the follow-up: For years, we have seen many variations "in the wild" to tag such postal features, and because of this fragmentation, no single variation is really widely used on a global scale, several mappers reported they are hesisting to map the features at all due to missing "well-defined" tagging scheme, no single variation is well supported by editors, data consumers, etc because the added value of each single variation is low and you don't know whether you're betting on a variation that will last or one that is soon cutted out by other variations. This proposal tries to combine the best of the many existing variations into one single, consistent, agreed, officially approved tagging scheme. Which in turn makes it worth & easy to be implemented in editors + data consumers and learned by mappers. --Schoschi (talk) 12:05, 2 May 2021 (UTC)

Do we need post_partner=yes?

Resolved: obsolete, current version of proposal does not contain post_partner with value "yes" any more but post_office value enumeration

Couldn't we just use post partner=DHL that seems easier and cuts down on tags

And if you don't know the post partner you can still use post partner yes. -Identität (talk) 18:48, 1 February 2021 (UTC)

True. On the other side, why not keep post_partner=yes to allow very easy processing by data consumers, and omit post_partner:brand=*? Or, the same question just from the other side, do you find any benefit in naming "DHL" in (post_partner XOR post_partner:brand) AND additionally in (post_partner:<brand>:brand:wikidata=* OR post_partner:<brand>:operator=*)? --Schoschi (talk) 23:32, 1 February 2021 (UTC)

Well I mean if you have anything after post partner you can already assume that it's a yes

But for further tags that does seem practical Identität (talk) 08:45, 2 February 2021 (UTC)

I would prefer omit post_partner:brand=* --SafetyIng (talk) 18:39, 3 February 2021 (UTC)

I second this and agree with Schoschi. Using post_partner=DHL would be very intuitiv and easy to implement. --Agent redd (talk) 10:45, 17 April 2021 (UTC)

I really disagree. osm have 38000k post_office with brand, it's a common pratie to the the brand into the brand key and it's also common to use namespace if to add an info about a "part" of an objet (for exemple bridge:name or roof:shape). using brand for amenity=post_office but a key "without-rand" for post_office is counterintuitive and would be a totally unnecessary exception Marc marc (talk) 12:36, 18 April 2021 (UTC)

--> Using post_office:brand=* ; see section Talk:Proposed_features/shop_as_post-partner&type=revision&diff=2144266&oldid=2144262#New_format --SafetyIng (talk) 21:01, 20 April 2021 (UTC)

separator for several values

For post_partner=multiple, the proposal suggests to use pipe symbol | as separator. To me, this seems quite uncommon in the OSM world. I would strongly suggest to do it similar as for other tags, which is usually ; but if special requirements exist, we may also map it differently (e.g. like for socket in amenity=charging_station). --Schoschi (talk) 00:15, 27 January 2021 (UTC)

Good idea, I used the tag "lanes" as a basis, for example, in order to create a clear assignment of the postal service provider and the respective service. So a tag with "post_partner:<post_service_provider/brand>:services" would be appropriate. Rather then always or only in the case of post_partner = multiple ? --SafetyIng (talk) 19:05, 27 January 2021 (UTC)

You're right, extended Lanes informations use pipe symbol - it did not come to my mind - and thus your proposal was in fact similar to an existing taggig scheme :) Still, pipe as primary and semicolon as secondary seperator (so two hierarchy levels of values lists which must have identical order/sequence in all keys) are much more rarely used than semicolon and dedicated keys. Hence, IMHO the updated proposal is preferrable as more mappers are used & tools are made for this kind of tagging and it is less error prone (when maintaining an object, changing the sequence in only one key, tools cannot validate whether same change was made in all other keys, while changing the brand name in one key only, tools may raise a confirmation dialog whether the same brand change shall really not be done in other keys). I would perfer to always (i.e. not only when multiple brands are supported) use "post_partner:<post_service_provider/brand>:services" because variances require more description on the wiki page, more learning & thinking by mappers, and more programming by tool & template developers. The updated proposal is pretty straight forward to me and I would feel happy to use it as it is :) --Schoschi (talk) 12:16, 29 January 2021 (UTC)

Lanes use the pipe symbol as an even higher-precedence separator because ";" is already used as a (normal) value separator (e.g. 2-lane road: left;through|through;right) Jengelh (talk) 07:39, 30 January 2021 (UTC)

I think this proposal should avoid coining a novel syntax (or a novel interpretation of existing punctuation) if at all possible. The | separator is not only intended to be higher-level than ; but also express an intrinsic ordering that does not exist here (e.g., the left lane to the left of the right lane). – Minh Nguyễn ^💬 22:31, 7 February 2021 (UTC)

Resolved: no more use of the seperator |

letters

As of now, the DE variant of the page says "letter = Verkauf und Annahme von Briefen". While I instantly understand "Anname" and see it as clear (same function as a post box / DE:Briefkasten), I am not sure about "Verkauf" - what is sold? The envelope and sheet of paper and pencil? Additional letter services like express or registered letter (DE: Einschreiben)? Stamps are already having their own, distinct value. --Schoschi (talk) 12:16, 29 January 2021 (UTC)

Writing material in general, i.e. now one gotta figure out how to incorporate shop=stationery into shop=kiosk, too. Jengelh (talk) 07:45, 30 January 2021 (UTC)

That challenge is already quite known ;-( To provide a little relief, I added service "packaging" into the proposal, so at least the very limited stationary supply that's offered by many PaketShops is easy to tag. --Schoschi (talk) 23:51, 1 February 2021 (UTC)

Thanks, actually it should named "Annahme" (mail_in) only - possibly "letter_mail_in" ? --SafetyIng (talk) 11:26, 1 February 2021 (UTC)

I see. Then "letter_mail_in" is IMHO more clear and also more extensible. --Schoschi (talk) 23:51, 1 February 2021 (UTC)

Resolved: new wording find in section "Confusing tags"

Offered services

IMHO we shall extend the list of services so for most services, we have defined values/names, mainly for two reasons.

1. We avoid to end up with a big amount of variances which would pose difficulties for data consumers like mobile apps: Translation/Localization needs known values. Displaying icons needs known values. Designing GUIs like filtering works better for a known amount of alternatives.
2. Several "values in the wild" will be difficult to interpret for humans.

Such a list of nearly all services seems well feasible: I did look at the websites of some postal service's brands operating in Germany (like DHL, DPD, Hermes, UPS). They leave their partners (DE: Paketshops) rather limited choice concerning the offered services, i.e. all partner shops of one postal service's brand must offer the same 3-5 base services and only 0-5 additional/optional services exist (numbers for all looked up brands together). For example, DHL's partners may also sell stamps, Hermes' partners may transport luggage, DPD may offer identity checks. Please extend the list of services by still missing services that are common for other countries & brands', so we get an idea of the amount of potential list items. And does anything speak against that approach of an "as-complete-as-possible list"? --Schoschi (talk) 21:56, 31 January 2021 (UTC)

Services, we may want to discuss whether we really want to add them

1. warpping_service, so the staff does wrap your goods for you. This is offered "officially" e.g. by some UPS partners, and probably also many other shops will do it, just "not officially" but when asked friendly or for a tip/fee or for people needing assistence (e.g. injured or elderly). This may also vary by who of a shop's staff is currently working or how many customers are currently queing. Hence, it's difficult to tell apart whether a shop offers that service or not, and a value of "sometimes" is not helping much.
   • I would not want it in the list --Schoschi (talk) 21:56, 31 January 2021 (UTC)
2. returns, so not sending a "new parcel" that is addressed & payed by the sender, but returning a parcel that is addressed & payed by the receiver (usually, an online shop). At least in DE, a considerable amount of postal brands officially distingush between both services (DHL, UPS,...), but at shop level, this does usually not make a difference, i.e. mostly all postal_partners offer both services. Does it make a difference somehwere respectively for some postal brands?

Resolved

Store within a store

In terms of physical objects, what represents the postal partner within a shop? Is it a dedicated room, counter, or kiosk or just an extra menu behind a shared counter (i.e., consignment inventory)? Reading this proposal as an American, what comes to mind for me are the counters and kiosks at office supply stores. I would be inclined to map those counters and kiosks as separate features (typically nodes) rather than as tags on the overall store, because they often have a distinct name, operator, opening hours, phone number, website – all the trappings of a POI. The American term for this kind of service is "postal provider", but the more general concept is a "store within a store". There are whole nationwide chains of taquerías, walk-in beer refrigerators, pharmacy counters, (microwaved) pizza counters, and photo processing kiosks that have their own signs out front no matter how little footprint they occupy within the store. [1]

I would suggest mapping a postal store-within-a-store as a separate amenity=post_office feature – or amenity=postal_partner if it feels wrong to overload the term "post office" this way. Doing so would skirt the syntactic gymnastics in this proposal. For one thing, the proposal calls for arbitrary brand identifiers within keys, which would all but ensure that a search engine wouldn't surface these tags in search results. The OSM tooling ecosystem doesn't support arbitrary keys all that well. Even if we could somehow get everyone to agree on a standard set of brand identifiers, there are perhaps hundreds of store-within-a-store delivery services in the U.S. alone, some with exactly the same name. On the other hand, if the keys were to be consolidated into a single post_partner=*, as proposed above, then the question becomes how to associate services with partners. We already have this problem with the payment=* and destination=* namespaces, but in this case we have an opportunity to avoid syntactic questions with separate features. The "one feature, one element" rule would be strengthened, not violated, as long as we can identify the postal partner's physical presence within the store.

 – Minh Nguyễn ^💬 03:35, 3 February 2021 (UTC)

Yes, in your case a seperate node is the right way. In Germany and other countries there is a shop, like a phoneshop, a tailor, a travel agency or a gas station - you see: very various - and this shop also offers the services on behalf of a postal service provider. So normaly here there are no extra counters (like here: [[2]] ) What you discribed are two commercials in one room/building. Here are more one commercial with two seperaly services operated by the same employees, with (normaly) same opening hours and so on. These are very often in Germany.

In case of "One thing - one element" a second node isn't an option, because the operator of the service itself is the operator of the actual shop. --SafetyIng (talk) 18:35, 3 February 2021 (UTC)

The case described by Minh Nguyễn is now extremely common in the UK, where even major post offices (i.e., those offering a full range of services) are co-located in other shops. Sub post offices have nearly always been a post office and a shop (convenience, newsagent are most common). Additionally in small villages post offices may be co-located within other amenities (such as village halls or even pubs). The general approach taken has always been to map these as stores within stores: the facilities are always distinct, use different cash registers, payment methods and have different opening hours). It is important that the discussion makes it abundantly clear that this is not a proposal to map shop-in-shop post offices. SK53 (talk) 20:04, 6 February 2021 (UTC)

Hey Minh Nguyễn and SK53, would you agree to my adjustment? Is this clarification clear enough in your eyes? --SafetyIng (talk) 21:34, 6 February 2021 (UTC)

@SafetyIng: I think it's improvement (which should be reflected in the "Definition" in the summary box at the top). Maybe it would help for the proposal to clarify that it's all about documenting offered services and not about documenting physical infrastructure or staffing. By analogy, Key:service#Business services and service:vehicle=* document that a shop can realign your tires without necessarily saying there's a dedicated station for tire realignment. But I'm still uneasy about the brand tagging being incorporated into this proposal. Inevitably there would be calls for the name suggestion index to tag certain parcel carriers with amenity=post_office and others with this tagging scheme, putting that project in a difficult spot because it's intended for whole-feature tagging. [3] – Minh Nguyễn ^💬 22:24, 7 February 2021 (UTC)

@Minh Nguyen: Oh, the service-Tag i wasn't known already. I would think over a better description.

At the problem with the brands, that we have to stay out. The main problem is, I know some kiosks they have a parcel service for "DHL" and sell stamps but dont accept parcels for a local postal service provider. It is the only way to differentiate both postal service providers and it facilitate the oppertunity for data consumers to search of all post_offices and post_partner of one brand, that allows one special service. --SafetyIng (talk) 11:45, 8 February 2021 (UTC)

Resolved

Avoid arbitrary keys

#separator for several values and #Store within a store touch upon what I see as an impediment to this proposal's adoption by data consumers: it calls for a limitless and unpredictable set of possible keys, because <brand> could be quite literally anything. For shops that partner with FedEx, does this proposal require post_partner:brand=FedEx post_partner:FedEx:services=*, or could a mapper get away with post_partner:brand=Federal Express post_partner:Federal_Express:services=* or even post_partner:brand=FDX post_partner:FDX:services=* to save some typing?

• If the proposal does standardize each company's subkeys, then it would need to enumerate the allowed subkeys, which could be a daunting task. Moreover, there's nothing preventing naming conflicts, such as the U.S.-based Amtrak and unrelated former UK-based Amtrak. (There are too many unrelated "ABC Courier" delivery companies to count, though none has a Wikidata item yet.)
• If the proposal doesn't standardize subkeys but instead relies on post_partner:brand=* to assign per-feature IDs to brands, then this scheme would be even less machine-readable than the :1/:2/:3 scheme used by Seamarks/Sectored and Directional Lights or the name_1=*/_2/_3 scheme introduced by the TIGER import and later deprecated. An Overpass query for FedEx parcel pickup service would have to manually iterate over each feature tagged with post_partner:brand=* to determine the post_partner:*:services=* subkey to filter by, which would be impractical. And who knows if it's practical for a search engine to do that at scale when indexing?

It seems to me that this proposal could skirt these questions by pivoting on services instead of brands. Then the example in the proposal would become much more straightforward for a data consumer to interpret:

shop=kiosk
name=Lotto Kiosk
post_partner:letter:brand=Deutsche Post
post_partner:stamps:brand=Deutsche Post
post_partner:parcel_send_in:brand=DHL
post_partner:parcel_send_in:operator=DHL Paket GmbH
post_partner:parcel_mail_in:brand=DHL
post_partner:parcel_mail_in:operator=DHL Paket GmbH
post_partner:parcel_pickup:brand=DHL
post_partner:parcel_pickup:operator=DHL Paket GmbH
post_partner:parcel_mail_in:brand=Hermes PaketShop
post_partner:parcel_mail_in:operator=Hermes Logistik Gruppe Deutschland
post_partner:parcel_pickup:brand=Hermes PaketShop
post_partner:parcel_pickup:operator=Hermes Logistik Gruppe Deutschland

(Along with :wikidata-suffixed keys as necessary.)

There might be more keys overall, but it would be more straightforward for an editor to facilitate entering them. This scheme would be forward-compatible with new companies that crop up without any effort on the part of the wiki. If a company changes its name, a simple ~"post_partner:.*:brand"~"Acme" in the Overpass turbo query wizard can find the shops to update.

 – Minh Nguyễn ^💬 23:21, 7 February 2021 (UTC)

I fully agree with the statement that having brand names in the key is problematic at best. Right now we have just a dozen of these tags in the database, but already three different spellings of Hermes (Hermes_PaketShop, hermes_Paketshop, Hermes). --Mueschel (talk) 11:24, 8 February 2021 (UTC)

@Minh Nguyen:, @Mueschel:: This in your idea is impossible. See under Elements#Tag : "An element cannot have 2 tags with the same 'key', the 'key's must be unique." So only post_partner:parcel_mail_in:brand=DHL;Hermes PaketShop is possible. That's worse than the proposed option. Currently we have in Germany the page Deutsche Postdienstleister - an analogical table could be possible. I haven't any other idea to "solve" this... --SafetyIng (talk) 21:23, 8 February 2021 (UTC)

@SafetyIng: My bad – I didn't mean to duplicate the keys like that:

shop=kiosk
name=Lotto Kiosk
post_partner:letter:brand=Deutsche Post
post_partner:stamps:brand=Deutsche Post
post_partner:parcel_send_in:brand=DHL
post_partner:parcel_send_in:operator=DHL Paket GmbH
post_partner:parcel_mail_in:brand=DHL;Hermes PaketShop
post_partner:parcel_mail_in:operator=DHL Paket GmbH;Hermes Logistik Gruppe Deutschland
post_partner:parcel_pickup:brand=DHL;Hermes PaketShop
post_partner:parcel_pickup:operator=DHL Paket GmbH;Hermes Logistik Gruppe Deutschland

I don't see the problem with using semicolon-delimited lists this way. Certainly it would be more machine-readable than a table on the wiki. You could find Hermes PaketShop parcel pickup in Overpass using a wizard query of "post_partner:parcel_pickup:brand"~"Hermes PaketShop" or, more robustly, "post_partner:parcel_pickup:brand:wikidata"~"Q1613532($|;)".

 – Minh Nguyễn ^💬 00:08, 9 February 2021 (UTC)

Okay, i understand your point. But the problem is, which information is more important? For me very clear: The Brand/Postal service provider. I would like to know whose services are offered where. So the order with brand/postal service provider should named in the key. If I want to list/see all services I have to look at all possible services (what is, if a nother service is running up?) - so I have the same problem like the brands. I don't search for the service "mail_in" but for the services of "DHL" oder "Hermes". I hope you understand my point of view to prioritize the band/postal service provider against the services. --SafetyIng (talk) 10:21, 9 February 2021 (UTC)

@SafetyIng: ~"post_partner:.*:brand:wikidata"~"(Q489815|Q1613532)($|;)" would reliably find any POI served by DHL or Hermes, regardless of which services they offer there. Even if it weren't possible to search keys by regular expression, there would only be a handful of common keys to search. By contrast, it would be much more complex to search by brand when the brand's own subkey may differ arbitrarily. For example, this convoluted query finds features that specify which services Hermes offers, but it isn't possible for Overpass to find the offered services when a POI is tagged with multiple brands, because Overpass lacks an operator for splitting a string. If the offered services are unimportant, then why complicate the proposal beyond just post_partner:brand=* and post_partner:brand:wikidata=*? – Minh Nguyễn ^💬 07:12, 12 February 2021 (UTC)

@Minh Nguyen: - I changed the tagging - so better? --SafetyIng (talk) 16:23, 21 February 2021 (UTC)

@SafetyIng: Thanks, this is a step in the right direction. There are a few more minor details to iron out still:

• Now that the subkeys are oriented around services, is there still a need for post_partner:wikidata=*?
• post_parter:<service>:wikidata=* should be post_parter:<service>:brand:wikidata=* and post_parter:<service>:operator:wikidata=*, since it describes a brand or operator, not a service.
• There are still a few subkeys that vary by "<brand>", but maybe this is OK since ref=* has a variety of company-specific subkeys too. Should the proposal specify any rules about how this "<brand>" is formed, or should it be left unspecified, similar to how the ref=* subkeys have developed organically?

The examples still need to be updated to match the new proposed subkeys. Thanks again for being open to this feedback, as inconvenient as it has been for you.

 – Minh Nguyễn ^💬 22:46, 21 February 2021 (UTC)

Resolved

Term post or other terms

The term "post" seems not matching the thing we want to tag/describe, so please help to find a better wording by contibuting to terms like courier, logistics, messengers etc.

this discussion is out of date, when we use the suggested wording by using the single tag post_office=*, wich is already used in germany, and combine it with the current proposal. (see mailing list and the section "Discussion of/on the terms") --SafetyIng (talk) 10:07, 2 March 2021 (UTC)

Resolved

List of terms

Please let's keep this list short and consolidated and discuss below or in mailing list or the like :-)

"Post" seems not suitable: According to participants in the tagging mailing list and several dictionaries like e.g. entry postal service, the terms "post" / "postal service" / "post office" are usually understood to refer to the fully / partly / formerly governmental owned post service provider, for instance USPS in U.S. and Royal Mail in UK, and their locations (to some extent also when branded + approved but run by a partner). In contrast, this proposal is targeting all service providers and also the locations not strongly branded.

"Courier" seems not suitable:

• wikipedia explains

Couriers are distinguished from ordinary mail services by features such as speed, security, tracking, signature, specialization and individualization of express services, and swift delivery times, which are optional for most everyday mail services. As a premium service, couriers are usually more expensive than standard mail services

That means the service providers the proposal is for (Hermes, DPD, arriva,...) are less into direction courier service providers than traditional post (e.g. DHL), as most of them are cheaper, offer less premium + additional services, do not deliver in shorter time, etc.

• Tag Office=courier exists, is in proposal state, descriptions & discussions mention as distinction from "post*" the much faster delivery and the additional services. If we merged these two proposals into one, we could not any more distinguish between those related but quite different services XOR needed some kind of classification tag.

"Mail" seems suitable

• Wikipedia defines "is a system for physically transporting postcards, letters, and parcels.", i.e. the term matches the scope of the proposal
• Unlike "post" there is no implicit confusion with "post office".
• Please add further sources pro + con

"Messengers" is maybe suitable

• According to dictionaries, it includes messages, letters and parcels, i.e. matches the scope of the proposal
• Wikipedia does not have an own article but redirects to courier - a concept which seems not suitable (see above)
• Please add further sources pro + con

"Logistics" seems not suitable

• According to dictionaries and wikipedia, the term has a much broader meaning than the thing we want to describe with the proposal (receiving + handing in letters + parcels and very little more) and is focusing much more the military / wholesale / business 2 business / organizational aspect than the business 2 customer aspect.
• Tag office=logistics exists, currently has a very short description, seemingly targets wholesale / pure business 2 business - i.e. it's kind of the "backoffice counterpart" of this proposal, so complementary instead the same.

"Delivery services" (or related) is maybe suitable

• How to distinguish from completely different delivery types like restaurant's food delivery? For example, Wikipedia speaks of package delivery, but the proposal is not only about package but also letters.
• Please add further sources pro + con

Other, less misleading wording could we use?* In case a possibly suiting term comes to your mind, please add it.

Discussion of/on the terms

[As of writing, this section is only a stub and I might not understand the problem outlined in it to begin with.] Firstly, although "post" as such might be ambiguous in English, terms like "post office", "post box" (and postal service) do exist and should be understood fairly well by both native and non-native speakers. Secondly, if "post partner" is unclear in its meaning (or poses other problems beyond my current understanding), the problem might easily be avoided, if the already in use and documented (currently only in DE:) post_office=yes would be chosen instead and its schema extended accordingly. (I am not sure why this was not the case to begin with – again, maybe I am missing something.) --!bm (talk) 22:57, 27 February 2021 (UTC)

@!bm: - The problem - the "post_office=yes" is used for a full postal office (like the german known "Postagenturen") with a full range of services. That is no tagging for stamps-Points or parcel-pickups. I could compare to expand this and change from post_partner=* to post_office=*. But the main problem with a part of the community ("post-points" in shops should always mapped with saperal nodes, see for more the mailing list).

To the problem "post" - a lot countries there are "post" normaly use only for postal services of the state-owned provider. I see that post also mean all postal services (like wikipedia: "The mail or post is a system for physically transporting postcards, letters, and parcels." . But not everybody goes straigt.) --SafetyIng (talk) 12:51, 28 February 2021 (UTC)

Resolved

Why tagging details

I would like to ask the question: Why do you want to tag data that is still in the internet? I mean, who shall maintain all the service details and service hours for all these post_partners? This is still done by the providers. Why isn't it enough to map the brand and the ID of the partner. The renderer can provide a link to get further information about this provider. Amegaz 14:557, 3 March 2021 (UTC+1)

I'd like to mention 2 aspects. 1st, for example Hermes Germany does not update the opening status & times as they are changing during Covid19 pandemic but only publishes the "usual" opening times of before 2/2020 despite some shops are completely closed already several months, i.e. the provider is not maintaining the information, so there is no usefuly data source I know of. 2nd, let's take your approach of thinking to a higher level than only this proposal. It would mean OSM shall not contain any data beside an ID for highway, building, shop, hotel etc that is already stored somewhere, e.g. govenmental data bases like swisstopo, the websites of the hotel/shop, Google Maps,... Obviously, this would result in an OSM not being very useful, e.g. as transfer protocols + data formats would be extremely heterogenous making implementation of any OSM data consumer very demanding (required for seraching, filtering etc). This is why we usually store some details like phone number, cuisine, piste type etc. within OSM, even though this data can be found somehwere else in the Internet. --Schoschi (talk) 13:32, 4 March 2021 (UTC)

Resolved

Confusing examples

I find the two examples you give on your proposal page a little confusing. Could you give me some advice on:

• where to find the tag "post_office:type=post_partner" that you state as "required"?
• what is the benefit of having tags for both brand and operator?
• why to use post_office:wikidata=Q1613532 and not post_office:wikidata=Q105702843 if post_office=Hermes PaketShop?
• wouldn't the operator in all cases likely be mixed up with the person actually running the shop?

I guess to make your proposal easier to understand and apply (and maybe also easier to pass approval) I would get rid of the operator tags entirely and only keep the brand tags. For the same reasons, I also wouldn't so heavily depend on wikidata tags and instead just use the actual brand name to be in line with nearly all other tagging schemes.

Additionally I'd recommend a different word for the "parcel-send-in" service as it is to similar to "letter-mail-in" but has an entirely different meaning.

Hey, @Kjon:,

* I just forgot it. Thanks.

* You have an operator of the postal services. That is - to be at your example - Hermes Group with the subsidiary company "Hermes Germany" for Germany. And the brand, how the post-partnership is called "Hermes PaketShop" - that is the brand. So also the post_office:wikidata is to the company and not the brand. It is confusing - likely i had another standing in my head and I removed the operator-element. Thank you!

* Would you think "parcel-sent-to" fits more?

--SafetyIng (talk) 12:50, 17 April 2021 (UTC)

Resolved: updated the examples

Confusing tags

pickup, dispatch, send in (with various meanings), luggage...: what a mess! bulk is in use in shop for a different meaning and you won't sent "bulk" - you would need a wrapping service, why not using standard terms?

Bulk => oversized_item (use the term used in airports). Luggage: I don't understand what is the service. Luggage deposit? Luggage transportation? According to the discussion it seems to be luggage transportation. parcel_to (you can ask for delivery in this shop), parcel_from (you can send a parcel from here). And the same for letter, oversized_item, luggage - or luggage_deposit if the other sense is meant. I would also add the return possibility: parcel_return.

"from" "to" "return" seems unambiguous. in/out is less obvious. Is the shop or the end user meant? If you send a parcel from a shop, it's clear.

"parcel_pickup parcel pickup of missed shipments". Weirdness threshold exceeded :-(. The above service (I named parcel_to is a pickup service - another possible name BTW). What is a need for indicating such a service? If the good can be delivered, you'll find a notice telling you where to take it, did I miss something? --Nospam2005 (talk) 19:16, 17 April 2021 (UTC)

Thanks for this. It is really simplier. But one question: What do you mean with "return"? A return_parcel? Does it really make a difference between sending a parcel from your own or if its a return? Yes, you often don't have to pay for it. But for the processing in the office? --SafetyIng (talk) 21:10, 20 April 2021 (UTC)

You're right the difference seems to be marginal, but it's probably paperless for the shop: they probably just check the presence of a return authorization number. Note that I did not invent that, it was on the proposal, if you think we don't need that, feel free to remove ;-). I can imagine that some places accept sending parcels but not return parcels. --Nospam2005 (talk) 21:38, 20 April 2021 (UTC)

Resolved

KISS

Currently post_office:type has 3 possible values: bureau (full office), post_annex (usually limited services run by a municipality) and post_partner.

The logic would be to simplify that (post_office=bureau|post_annex|post_partner).

A partner is not running the service as main service but more as extra service. The new proposal breaks compatibility, notably for France.

We can break compatibility, but only for good reasons that I don't see here.

post_office=* name(s) of the brands. is pretty much non sense in the OSM terminology. Brands use the key brand. Amazing, isn't it?

Here you would not find a more detailed description of the post_office as usual but... brands!

Why not using post_office:brand=La Poste;DHL for instance? (or using wikidata). BTW it's not brands, but names of the partner (Colissimo is a brand of La Poste). post_office:operated_for= maybe be better.

For clarification: I'm fine with the rationale of the proposal.

--Nospam2005 (talk) 19:36, 17 April 2021 (UTC)

Resolved: Treated in section New format --SafetyIng (talk) 21:01, 20 April 2021 (UTC)

New format

Why would you use post_office=* instead of post_office:brand=*, when post_office:*:brand=* is used below? Or do you mean something like post_office:name=*? Then post_office=post_partner can be used. No need to continue using the awful post_office:type=*. There are ~550 post_office=* and ~170 post_office:brand=* instances.

LOADING TAG LIST...

-- Kovposch (talk) 07:02, 18 April 2021 (UTC)

I agree with Kovposch that the :type suffix doesn't seem to be necessary and should be avoided. Instead just use post_office=* to indicate the "type". In addition to that why not use:

• post_office:brand=DHL;Hermes to tag brands if no service information is available
• post_office:<service>=yes to tag services if no brand information is available or you don't know wich brand offers which service
• post_office:<service>=DHL;Hermes to tag service and brand information in detail

I these tags should cover the mentioned use cases --Kjon (talk) 11:57, 18 April 2021 (UTC)

Okay, for this i only answer here. For information to @Kovposch:, @Kjon:, @Nospam2005:, @Marc marc: - somebody missed?

• I had changed the proposal to change from post_office:type to post_office - with the same meanings. Especially the question to Marc - what does the French community say about this? Would she go with you? Can you ask there?
• brand is cleared up as brand of the post_office; so how is the type of post_office tagged. Examples: "Hermes Paketshop" in Germany or "Relais poste" in France.
• I had introduced the subkey :service_provider to don't confuse with operator ; so the service_provider is clear identified. Brand and serviceprovider are not everytime the same name.
• I had cleaned up the mess with the services in additonal to Kjons suggestion.

Something that I forgot? --SafetyIng (talk) 20:26, 20 April 2021 (UTC)

wikidata or brand name preferred?

What is the preferred tagging: wikidata or brand names or both? This should be explicit in the proposal to prevent edit wars. --Lkw (talk) 08:22, 18 April 2021 (UTC)

main tags in osm are human readable, so of course, brand=* is "needed" before a brand:wikidata=* subkey, :wikidata is only needed when several firms have the same brand. I don't see how there could be an edit war, if someone has added one of them correctly, there is no reason to delete it if you want to add the other Marc marc (talk)

I would agree to Marc. Even though I know that Wikidata entries would make more sense in terms of integrity, since fewer name differences are possible; Compare e.g. Hermes, Hermes Group, Hermes Europe and Hermes Germany.... --SafetyIng (talk) 15:01, 21 April 2021 (UTC)

Resolved

Status

Can you please acknowledge the various topics in this long list by adding the template {{ok}} - turning into at the end of the section headers hen you take them into account? It would make reading the discussion more efficient and show the progress! --Nospam2005 (talk) 20:38, 20 April 2021 (UTC)

Of course - I added a '- solved' to it so that it can also be recognized in the table of contents --SafetyIng (talk) 21:01, 20 April 2021 (UTC)

Actually you should use {{resolved|*}} in the content. This avoids breaking the section titles in case they need to be linked to.

Resolved: A conclusion and any supplementary information can be put here, which is able to be timestamped and signed.

---- Kovposch (talk) 15:32, 21 April 2021 (UTC)}}

collection_times: KISS?

Do we need a namespace post_office for that? According to Key:collection times, it's about "post box, recycling container or other fixed location drop-off facility.". As post partners aren't recycling container or other fixed location drop-off facility (except for postal goods), I don't see a possible collision, therefore I would rather keep the usual collection_times=*. --Nospam2005 (talk) 20:50, 20 April 2021 (UTC)

I think, that it is simple, when for the post_partner everything is in the same namespace. So that let me decide to use post_office:collection_times.

In a normal amenity=post_office you also use brand=* instead of post_office:brand=*. So I would think you adapt all post_office relevant data to the namespace (likewise ref is here the only exception with it's own namespace). I hope my train of thought is understandable? --SafetyIng (talk) 21:06, 20 April 2021 (UTC)

It's perfectly understandable and that's exactly the reason why I put a question mark. Your logic is more contributor oriented, mine more data user oriented. Both are valid, the question is just is one better than the other? --Nospam2005 (talk) 21:45, 20 April 2021 (UTC)

@Nospam2005: Neither is better or worse. But since you should commit yourself to one thing, I would choose the priority more with one for the mapper way, because that would really only be one or two lines of code ... --SafetyIng (talk) 14:57, 21 April 2021 (UTC)

Mention post_office:service_provider as optional only

Resolved

post_office:service_provider seems a bit nitpicky to me and should only be mentioned as an optional tag in order to keep the proposal simple to use and and easy to understand.--Kjon (talk) 19:15, 21 April 2021 (UTC)

Thank you, @Kjon:, was also intended and probably just overlooked. --SafetyIng (talk) 20:33, 25 April 2021 (UTC)

@SafetyIng: You forgot to also update your examples.--Kjon (talk) 20:50, 25 April 2021 (UTC)

Am I blind? What do you mean by that, @Kjon:? That in the examples *service_provider is not listed under "Optional Information about services"? The *:brand:wikidata also not. --SafetyIng (talk) 16:38, 26 April 2021 (UTC)

I will update the proposal page to show what I mean. Feel free to revert, if you're not happy.--Kjon (talk) 17:53, 26 April 2021 (UTC)

opening_hours

Although namespacing everything below post_office:* seems intuitive at first, I suggest to switch the keys for this one and use the more practical as well as consistent opening_hours:* — that is, use opening_hours:post_office=* instead of (currently proposed) post_office:opening_hours=*. (Cf. opening_hours:kitchen=*, opening_hours:covid19=*.) Furthermore, opening_hours:post_office=* is already in use:

opening_hours:post_office=*

More details at taginfo

post_office:opening_hours=*

More details at taginfo

--!bm (talk) 23:36, 25 April 2021 (UTC)

I disagree with the opening_hours:kitchen=* underpinning this. There are "only" 2312 instances of it. post_office=*, kitchen=*, atm=*, etc should be feature-attributes that are in front, with *:opening_hours=* as an attribute for it. (The notion of opening_hours=* for the "kitchen" is dubious as well) Here, post_office:brand=* and other post_office:*=* are going to be used. Won't they be changed to brand:post_office=* for consistency? opening_hours:kitchen=* is more of an outlier that began this trend. There are also some confusions with service_times=*, as seen in Talk:Proposed features/Kitchen hours (which itself suggested kitchen_hours=*, like the collection_times=* and other tags we have now).

Cf atm=yes: (format is broken when not used alone)

atm:network=*

More details at taginfo

atm:operator=*

More details at taginfo

atm_ref=*

More details at taginfo

opening_hours:atm=*

More details at taginfo

atm:fee=*

More details at taginfo

atm:opening_hours=*

More details at taginfo

*:covid19=* is something I have commented against. It should be an event, similar to temporary:*=* and xmas:*=*, for easy and quick interpretation. It doesn't look like a condition either (eg I can understand this for recurrent natural disasters such as earthquakes, volacno eruptions, tsunami, and typhoons). At that time, it was suggested this is used for some conformal reasons only. Basically "if it works", then didn't care much about it.

---- Kovposch (talk) 10:19, 26 April 2021 (UTC)

I would agree to Kovposch. I don't see any point in splitting the namespace further. --SafetyIng (talk) 16:48, 26 April 2021 (UTC)

wikidata for post_office:service_provider

Currently, for post_office:service_provider=* the propsal states "Could also added with wikidata subelement". IMHO we shall explicitly name the key to avoid several variances emerge. Is post_office:service_provider:wikidata=* fine? --Schoschi (talk) 12:09, 2 May 2021 (UTC)

Services

Am I correct to assume that the post_office:<service>=* section was a suggestion of possible tags that could be used and not necessarily something that was approved along with the main tagging scheme that was the purpose of the proposal? --Adamant1 (talk) 00:09, 30 August 2021 (UTC)

Example 1 cointains undefined values

From Example 1

post_office:parcel_send_in=yes
post_office:parcel_mail_in=yes

keys parcel_send_in & parcel_mail_in are missing in services list above (letter_from, parcel_from, parcel_pickup, parcel_to, stamps, oversized_item, packaging, post_bank, id_check) --MalgiK (talk) 15:36, 27 January 2022 (UTC)