User:Nw520/Notebook

Proposal: Consolidated tagging of mail-related features

2022-12-25

Consolidated tagging of mail-related features
Proposal status:	Draft (under way)
Proposed by:	Nw520
Draft started:	2022-12-25

Proposal

FIXME

Rationale

Consistency

In June 2021 the “shop as post-partner”-proposal introduced the keys:

Key	Values	Description
post_office:letter_from=*	yes/no or names of service providers	dispatch (handing in for sending) of letters
post_office:parcel_from=*	yes/no or names of service providers	dispatch (handing in for sending) of parcels
post_office:parcel_pickup=*	yes/no or names of service providers	parcel pickup of missed shipments
post_office:parcel_to=*	yes/no or names of service providers	alternative delivery address ('send the parcel to the shop')

In January 2022 the “amenity=parcel locker”-proposal introduced the keys:

Key	Values	Description
parcel_pickup=*	yes/no or names of service providers	You can pick up your parcels there. If "yes" the tag can be skipped as it is assumed.
parcel_mail_in=*	yes/no/returns_only or names of service providers	You can drop off your parcels there. Other than yes/no special value returns_only can be used if the machine does not allow sending parcels but returning parcels is allowed.

Both proposals concern features that enable the dispatching and receiving of parcels and letters. Due to this overlap in purpose of both classes of features one would expect them to have a common tagging schema. However, as it is, parcel lockers use the key parcel_mail_in=* which is completely unrelated to the keys used for post offices and parcel locker schema's parcel_pickup=* has slightly different semantics compared to post_office:parcel_pickup=* although both sharing the same subkey:

Key states whether I can…	post office				parcel locker
	post_office:letter_from=*	post_office:parcel_from=*	post_office:parcel_pickup=*	post_office:parcel_to=*	parcel_pickup=*	parcel_mail_in=*
…dispatch letters at this feature	yes	no	no	no	no	no
…dispatch parcels at this feature	no	yes	no	no	no	yes
…pickup missed parcels at this feature	no	no	yes	no	yes	no
…use this feature as an alternative delivery address	no	no	no	yes	maybe¹	no
…only return parcels at this feature	no	no	no	no	no	yes (returns_only)

1 This use-case is covered by the key's description, but as the key is conflated with picking up missed parcels one can't really know whether this service is provided

This difference in semantics of parcel_pickup=* and post_office:parcel_pickup=* is confusing for contributors and data users. Subkeys are among other things used “as an additional key which further describes a Feature”. Therefore one would expect parcel_pickup=* and post_office:parcel_pickup=* to have identical semantics. Similarly, it's confusing that for parcel lockers one has to use tags from one schema while for post office the other schema's tags have to be used.

Naming

In both the “shop as post-partner”-proposal and even twice in the “amenity=parcel locker”-proposal a few contributors stated their dissatisfaction with using _from and _to as they perceived these as ambiguous. Similarly, _receive was also criticised.

• Proposed features/unified postal service tagging

FIXME

Result

To consolidate both schema's (sub-)keys, this proposal aims to deprecate FIXME and instead use these keys for both parcel lockers (namespaced with post_office:) and post offices:

Key	Values	Description
letter_dispatch=*	yes/no or names of service providers	Letters can be dispatched (handed in for sending) from this feature
parcel_dispatch=*	yes/no or names of service providers	Parcels can be dispatched (handed in for sending) from this feature
parcel_reroute=*	yes/no or names of service providers	Parcels can be rerouted to this feature (either explicitly or when the service provider was unable to deliver it to the recipient's address)
parcel_destination=*	yes/no or names of service providers	Use this feature as delivery address („send the parcel to the shop“)

This allows simpler querying (“Show me features a can dispatch a parcel from” ⇒ [~"(post_office:)?parcel_dispatch"~".+"]), reduces the number of (sub-)keys that contributors have to know and eliminates contributors mixing up both schemas.

Example tagging for features:

Post office		Parcel locker
Old	New	Old	News
shop=mobile_phone name=HANDY SHOP post_office=post_partner post_office:brand=Hermes PaketShop post_office:service_provider=Hermes Group post_office:parcel_from=yes post_office:parcel_to=yes post_office:parcel_pickup=yes	shop=mobile_phone name=HANDY SHOP post_office=post_partner post_office:brand=Hermes PaketShop post_office:service_provider=Hermes Group post_office:parcel_dispatch=yes post_office:parcel_destination=yes post_office:parcel_reroute=yes	amenity=parcel_locker brand=Paczkomat InPost operator=InPost parcel_pickup=yes parcel_mail_in=yes ref=KRA165M	amenity=parcel_locker brand=Paczkomat InPost operator=InPost parcel_destination=yes parcel_reroute=? parcel_dispatch=yes ref=KRA165M

Comments

Please comment on the discussion page.