User:Nw520/Notebook

From OpenStreetMap Wiki
Jump to navigation Jump to search

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.

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

Tagging

Examples

Features/Pages affected

External discussions

Comments

Please comment on the discussion page.