Proposal talk:Unified postal service tagging

Stamps

You write "amenity sells stamps". Why the focus on "amenity"? There are also other kind of features which might sell stamps, e.g. vending machines, kiosks, bars, newsagents, gift shops, etc. What about distinguishing the kind of available stamps, e.g. "real stamps" (graphic artwork), and "variable value stamps" (generic stamps with amount printed on demand, also graphic artwork). Examples:

--Dieterdreist (talk) 23:38, 23 January 2022 (UTC)

stamps=yes is already used in shop=tobacco according to Tag:shop=tobacco. --- Kovposch (talk) 09:40, 24 January 2022 (UTC)

Okay, yes there are other facilities, that sell stamps. But:

for shops/amenities like kiosks, bars, newsagents, gift shops -> there is with post_office=* an approved tagging of this.

for a stamp vending machines it should be added?

The stamp-Tag for shop=tobacco don't mark "postal stamps", it marks if "Revenue stamps" are sold https://en.wikipedia.org/wiki/Revenue_stamp

--SafetyIng (talk) 12:13, 24 January 2022 (UTC)

Actually Tag:shop=tobacco contradicts Key:stamps on the meaning of stamps=*. I meant for it to be resolved. --- Kovposch (talk) 13:22, 25 January 2022 (UTC)

@Kovposch: okay, and you think, Key:stamps should stay then at the meaning of Tag:shop=tobacco? @Dieterdreist: your opinion? --SafetyIng (talk) 13:35, 11 February 2022 (UTC)

Not post service only

Resolved: user don't like namespace

As seen from the stamps question above, "postal service" may be confused as a "service" (excluding shops), or even post service only. Then what about office=courier? (Proposed features/Office=courier abandoned)
If we take a step back, postal_service:*=* or any prefixing doesn't need to be used on dedicated postal features. post_office:*=* is only required under post_office=* in other features. Naturally a amenity=post_office should avoid using it. First of all, using letter:*=* and parcel:*=* would allow us to focus on discussing the term, and allow for easy extension. Same should be done for oversized_item=* to become at least oversized_item:*=*, or something in the direction of parcel:oversized:*=* (if this makes sense).

I strongly agree that the "postal_service" prefix makes the tags really unwieldy and is mostly not required because the terms are used in their principal context. Maybe for "stamps" it could help to make it "postage_stamps", at least the letter, parcel and post_bank keys look fine just by removing the prefix, id_check might need to become something like id_check_service (it is not related to postal services anyway). Why are letter and parcel keys distinguishing between sending and receiving, but oversized_item is not? --Dieterdreist (talk) 11:56, 24 January 2022 (UTC)

1. Or use stamps=postage, as well as stamps:postage=* if needed? Other potentially affected tags: vending=stamps as reminded above; France/data.gouv.fr/Import_des_points_de_contact_postaux#affranchissement_libre_service has a stamping_machine=*.
2. We should use full form if possible. Would identity_check_service=* be too long?

--- Kovposch (talk) 13:21, 25 January 2022 (UTC)

For my opinion, a clear namespace is better than a mess with a lot of stand alone tags; Namespaces are to collect corresponding tags. We use is e.g. at the adress-Namespace and others, for a good reason. I don't see any valid argument against it, except one doesn't like "namespaces" in general. --SafetyIng (talk) 12:13, 24 January 2022 (UTC)

You are over-namespacing, missing the point of post_office:*=* in post_office=*. --- Kovposch (talk) 12:57, 25 January 2022 (UTC)

The sending/receiving debacle

I want to abandon any mention of "in/out" and "to/from", as they have proved to be ambiguous and controversial. Similarly for "send"/"receive". I considered *:origin=* & *:destination=*. Although this is a common technical term prefixed to avoid conflict with origin=* and destination=*, it may still be misunderstood as mail with these particular origins and destinations.

*:pickup=* is not used to avoid confusing with previous definition of *_pickup=* for returns.

Another idea is take a hint from aviation to have *:arrival=* and *:departure=* to make mail the subject explicitly, eliminating the implicit subject-voice. This terminology is used by mail, freight, and shipping, as well as ETA and ETD in everyday life.

This is not a dabacle, when we have a good definition. And when you see at Talk:Proposed features/amenity=parcel locker you see a lot people, who prefere this tagging --SafetyIng (talk) 12:13, 24 January 2022 (UTC)

I don't know what you are reading. There are clearly debates over the format. Otherwise you are changing the tagging with no real improvement. --- Kovposch (talk) 12:58, 25 January 2022 (UTC)

I read more opinions against *from and *to, than to it. Refer to https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/amenity%3Dparcel_locker#.22to.22_and_.22from.22

Returning

It's not clear to mix returns in sending (resulting in odd values like *=returns_only, or necessary to limit it to parcels. Use parcel:return=only.

There exists post_offices and parcel lockers, who only accept "returning parcels" - how should it then applied to this tagging? --SafetyIng (talk) 12:13, 24 January 2022 (UTC)

What's the problem? If you want to be clear, you can consider parcel:returns=yes + parcel:others=no, but parcel:returns=only is a format common enough. --- Kovposch (talk) 12:55, 25 January 2022 (UTC)

In the namespace it fits together. I just only adopted it from the parcel locker-proposal. I don't really think, we need to split this up.... The simple value is simpler than unnecessarily creating two subkeys here. --SafetyIng (talk) 13:40, 11 February 2022 (UTC)

Postal banking

Resolved

post_bank=* is on the long side when we can simply have bank=postal to be in common with amenity=bank. If other banks are present or relevant, bank:postal=* + bank:others=* (from payment:others=no).

E.g. in germany there are post_office=post_partner where you can handle post bank serices like sending money or withdraw money. I have seen this in other countries too. This hat nothing what relates to a bank at it self. --SafetyIng (talk) 13:35, 11 February 2022 (UTC)

personal comments

My review of the schema

Here we go again. That's too many back-and-forth. Let me have a thorough look to try to help settle the debate. --- Kovposch (talk) 09:40, 24 January 2022 (UTC)

@Kovposch: I have cleaned up this mess in the standard thread form here --SafetyIng (talk) 12:13, 24 January 2022 (UTC)

Fragmenting my single post to individual sections is not less of a "mess", and clutters the discussion page. This is also as standard as how several other proposals has used subsections before. --- Kovposch (talk) 12:54, 25 January 2022 (UTC)

What is the point of postal_service: prefix?

How this helps with anything? If standarization would happen I would rather support removing this prefix Mateusz Konieczny (talk) 16:38, 26 January 2022 (UTC)

Why would you remove the prefix? Why against the "namespace"; this is something we already use in a good way, see "addr:", "contact:", "service:", "payment:". In my eyes, it is only logical that these services are combined in one scheme. Since they all represent a group of "postal services" and thus effectively the values of the two completely different proposals post_office=* and amenity=parcel_locker are combined here. --SafetyIng (talk) 22:27, 26 January 2022 (UTC)

I see no benefit of such tagging in this case, unlike for addr:/payment:. And I am also against contact: Mateusz Konieczny (talk) 09:11, 9 February 2022 (UTC)

A namespace is everytime useful, when group matching items. For datausers there is a ability to identify "new" entrys wich is not listet until. E.g. someone creates "postal_service:making_beds" (Yeay, not really creative ;) ) - then every mapper and datauser can handle "making beds" as an postal service and the datausers can show them grouped together. This is one benefit of namespaces. --SafetyIng (talk) 13:44, 11 February 2022 (UTC)

Parcel lockers

Resolved: they subkey pacel_pickup fits not to every parcel locker, but for some it is neccessary (e.g. Germany)

While I generally like the idea of consistent namespace, I'm not really sure that we should try to cover all the amenities you have listed with one namespace.

Let's take parcel lockers. If postal_sevice:pacel_pickup=yes is to mean "Amenity allows user to pick up missed parcels" then it doesn't fit parcel lockers at all. They are not there for picking up missed parcels - you send the parcels specifically to that parcel locker.

What's more, other "something_lockers" become popular:

• for picking up and returning goods for specific stores
• for picking up and returning books from library
• for picking up and delivering official letters to and from governmental administration

All those seem to be candidates for unification with parcel lockers, but not necessarily with postal services. --Rmikke (talk) 16:57, 26 January 2022 (UTC)

It realy depends on the postal service provider. It is okay, when in poland this service is not offered, in Germany Deutsche Post could also place a missed parcel (when you weren't at home) in a parcellocker ("DHL Packstation") and on the notification card is a barcode wich allows me to pick up my parcel. A local postal service provider test this in the city centre too. And the amenities are covered per definition. These all offers on a way a postal service. But it should be clear, that not every amenity could handle all services. --SafetyIng (talk) 22:20, 26 January 2022 (UTC)

Defaults

As this proposal covers various amenities, I think it should define default values for those amenities.

E.g. I would expect the post office to sell stamps, but would rather not expect it from post_box. To avoid having to update every post office with postal_service:stamps=yes and every post box with postal_service:stamps=no the defaults for each amenity covered should be defined in this proposal.

@Rmikke: This is a good idea. Wich defaults do you think should exsists?

amenity=post_box => postal_service:letter_mail_in

amenity=parcel_locker => postal_service:parcel_send_to ( I would say, parcel_mail_in and parcel_pickup depends on postal service provider?)

amenity=post_office => postal_service:parcel_mail_in, postal_service:stamps

for post_office=* I would not set up a default, when you have a post_partner who only handles parcels, so you wouln't need *:stamps and so on.

Would you follow? --SafetyIng (talk) 13:52, 11 February 2022 (UTC)

For yes/no attributes I think there should be defaults with both yes or no values. Like:

amenity=post_box => postal_service:letter_mail_in=yes, postal_service:stamps=no, postal_service:parcel_mail_in=no

amenity=parcel_locker => postal_service:parcel_send_to=yes, postal_service:stamps=no ( parcel_mail_in and parcel_pickup we leave out as they depend on postal service provider)

amenity=post_office => postal_service:parcel_mail_in=yes , postal_service:stamps=yes

and so on. I think this is the only way to define defaults :) Rmikke (talk) 15:58, 7 March 2022 (UTC)