Proposal:Amenity=parcel locker
Jump to navigation
Jump to search
| The Feature Page for the approved proposal amenity=parcel locker is located at Tag:amenity=parcel_locker |
| amenity=parcel locker | |
|---|---|
| Proposal status: | Approved (active) |
| Proposed by: | Tomczk |
| Tagging: | amenity=parcel_locker |
| Applies to: |  
|
| Definition: | Machine for picking up and sending parcels. |
| Statistics: |
|
| Rendered as: | picture |
| Draft started: | 2021-12-20 |
| RFC start: | 2021-11-03 (before the first vote which was cancelled and second vote was started immediately) |
| Vote start: | 2021-12-20 |
| Vote end: | 2022-01-03 |
This proposal was reworked from previous version using amenity=parcel_machine to amenity=parcel_locker. Majority of votes opposing previous proposal said that they were against the word "machine" specifically and preferred to call these "locker" or "lockers".
Proposal
Disclaimer. This proposal was rewritten due to discussion in Talk page and then during voting. Initial proposal was for amenity=parcel_lockers tag but it was requested to change it to parcel_machine. However during vote majority of opposing votes mentioned that parcel_locker(s) was better tag so vote was cut short (rejected) and proposal was reworked to be put to vote again with the more accepted tag.
Parcel lockers (also called parcel terminals, parcel stations, packstations, parcel machines or parcel-o-mats) are electrical machines with lockers for picking-up parcels. They allow for interaction with the customers, usually by a touchscreen. Some parcel lockers also allow for sending parcels or to be used as ordinary lockers.
Currently they are tagged under vending=parcel_pickup;parcel_mail_in / vending=parcel_pickup / vending=parcel_mail_in.
This proposal aims to introduce a new dedicated tag amenity=parcel_locker.
Attributes of parcel locker would be described using complementing tags based on original values for vending tag: parcel_pickup=yes/no , parcel_mail_in=yes/no/returns_only. (pickup functionality is assumed to be present otherwise parcel_pickup=no should be added). Other options might be introduced in the future using similar scheme eg. if there are lockers dedicated for receiving packages containing perishable goods and is refrigerated one could use Template:TTag.
Other standard tags such as: operator=*, brand=*, brand:wikidata=*, brand:wikipedia=*, description=*, payment=* might be used to add additional information.
Example record:
amenity=parcel_locker parcel_mail_in=yes operator=Inpost Sp. z o.o. brand=InPost brand:wikidata=Q3182097 brand:wikipedia=pl:InPost payment:blik=yes payment:wire_transfer=yes payment:contactless=yes ref=WAW123A
Reference number/ID of parcel locker used by operator should be added using: ref=*.
It's recommended to use brand=* or operator=* tag together with ref=* tag instead of name=* tag so renders are consistent in how they show these on a map if they wish to provide label. (similar to ATMs)
Minimum set of tags for an object to be considered useful are: amenity=parcel_locker (if parcel_pickup=no other functions should be listed so at least one function is present). It's strongly recommended to add also at least: operator=* or brand=* and ref=*.
Parcel lockers should be mapped as points (nodes).
This proposal approves tags:
- amenity=parcel_locker
- parcel_pickup=yes/no
- parcel_mail_in=yes/no/returns_only
- refrigerated=yes
and deprecates tags:
- vending~parcel_pickup
- vending~parcel_mail_in
- and their combinations (vending=parcel_pickup;parcel_mail_in, vending=parcel_mail_in;parcel_pickup)
Rationale
Q: Why not use previous proposal from SelfishSeahorse ?
A: It seems dead (no updates in the past 2 years) so I decided to create a new one. Additionally it proposes parcel_postbox tag which seemed a little controversial in the discussion so I wanted to skip it here focusing only on parcel_locker.
Q: Why change from vending machine?
A: Packstations do not sell packages (or anything else really) so they don't really fit in vending machine category. They are specialised machines like ATMs so I think it's sensible to use a dedicated tag for them instead of trying to fit them into existing category that's imperfect match.
Q: Why parcel_locker instead of parcel_lockers?
A: It is called that way on wikipedia https://en.wikipedia.org/wiki/Parcel_locker
Leading operators seem to be using "locker" for individual machine vs "lockers" for their entire network/product line, see:
Amazon: "Locker is a secure, self-service kiosk" - https://www.amazon.com/ulp/view
InPost: https://inpost.pl/en/help-what-inpost-parcel-locker
UPS: https://www.youtube.com/watch?v=ONwWXAFPyiw
Additionally for Tag:amenity=letter box singular form is used even when object represents multiple boxes.
Tagging
| Element | Allowed |
|---|---|
| node | Yes |
| way | No |
| area | Yes |
| relation | No |
Due to suggestion from discussion areas were allowed.
Main tag:
amenity=parcel_locker
Due to suggestion from discussion main tag was changed from parcel_lockers to parcel_locker then to parcel_machine then back to parcel_locker.
Supplementing tags:
| Tag | Possible values | Description |
|---|---|---|
| parcel_pickup | yes/no | 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 | 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. |
Other standard tags such as: operator=*, brand=*, brand:wikidata=*, brand:wikipedia=*, description=*, payment=* might be used to add additional information.
Reference number/ID of parcel locker used by operator should be added using: ref=*.
It's recommended to use brand=* or operator=* tag together with ref=* tag instead of name=* tag so renders are consistent in how they show these on a map if they wish to provide label. (similar to ATMs)
Minimum set of tags for an object to be considered useful are: amenity=parcel_locker (if parcel_pickup=no other functions should be listed so at least one function is present). It's strongly recommended to add also at least: operator=* or brand=* and ref=*.
For temporarily disabled machines that do not function one can use tag: disused=yes
Examples
| Before | After |
|---|---|
| amenity=vending_machine
vending=parcel_pickup;parcel_mail_in |
amenity=parcel_locker
parcel_mail_in=yes |
Current usage
Proposed tags
| amenity=parcel_locker |
|---|
Current tags
| vending=parcel_pickup | vending=parcel_pickup;parcel_mail_in |
|---|---|
| vending=parcel_mail_in | vending=parcel_mail_in;parcel_pickup |
Rendering
This feature should be rendered since it is a point that people want to see on a map to be able to navigate to it (so they can receive their packages).
I opened issue in Carto github repo asking for the feature to be rendered and they pointed to the previous proposal from 2018 and said that it doesn't make sense to implement with the current tagging scheme so it can be said that this proposal is a result of that.
Main thread for rendering this feature in default (Carto) style is in this issue: https://github.com/gravitystorm/openstreetmap-carto/issues/3558
At the time proposed icon is https://gist.github.com/Tomasz-W/18032cc646055bf17b866cb4eb48fa48 created by User:Tomasz W but suggestions are welcome (post them in the github issue).
We should probably also contact OpenMapTiles people so parcel lockers would be available in their vector tiles.
Features/Pages affected
Wiki pages to be edited:
Tag:vending=parcel pickup;parcel mail in
Tag:amenity=post office (see also section)
Tag:amenity=post box (see also section)
Parcel lockers in the United Kingdom
...And others referencing the Tag:vending=parcel pickup page
Wiki page to be created:
Other actions to be taken:
- Retag existing objects with the new tagging schema (mostly automatic)
- Create issue or PR with updated mapping for iD editor - preset PR, NSI PR
- Create issue for OpenMapTiles github repo so they include new tagging in their schema?
- Update JOSM mapping?
External discussions
- Forum discussion (in Polish)
- OSM Carto GitHub issue
- Discussion in previous proposal: Talk:Proposed features/Parcel lockers and parcel postbox
Comments
Please comment on the discussion page.
the first vote
Voting
Instructions for voting
- Log in to the wiki if you are not already logged in.
- Scroll down to voting and click 'Edit source'. Copy and paste the appropriate code from this table on its own line at the bottom of the text area:
| To get this output | you type | Description |
|---|---|---|
|
{{vote|yes}} --~~~~
|
Feel free to also explain why you support proposal. |
|
{{vote|no}} reason --~~~~
|
Replace reason with your reason(s) for voting no. |
|
{{vote|abstain}} comments --~~~~
|
If you don't want to vote but have comments. Replace comments with your comments. |
~~~~ automatically inserts your name and the current date.For full template documentation see Template:Vote. See also how vote outcome is processed.
---
I approve this proposal. --Arc2 (talk) 18:38, 21 December 2021 (UTC)- I approve this proposal. --NieWnen (talk) 22:53, 20 December 2021 (UTC)
- I approve this proposal. Though I am not convinced that current vending tagging is wrong Mateusz Konieczny (talk) 23:02, 20 December 2021 (UTC)
- I approve this proposal. --Kocio (talk) 23:05, 20 December 2021 (UTC)
- I approve this proposal. --Syntex (talk) 23:11, 20 December 2021 (UTC)
- I approve this proposal. --Rmikke (talk) 23:47, 20 December 2021 (UTC)
- I approve this proposal. Hope this one sticks, this is needed. --Emilius123 (talk) 23:52, 20 December 2021 (UTC)
I oppose this proposal. As per my comment on the talk page, approving a duplicate would just cause unnecessary confusion, and "deprecating" a widely supported tag even more. SomeoneElse (talk) 01:50, 21 December 2021 (UTC)- I approve this proposal. --Carnildo (talk) 06:20, 21 December 2021 (UTC)
- I approve this proposal.—-Dieterdreist (talk) 06:46, 21 December 2021 (UTC)
- I approve this proposal. --AncymonOSM (talk) 06:58, 21 December 2021 (UTC)
- I approve this proposal. --Riiga (talk) 07:15, 21 December 2021 (UTC)
- I approve this proposal. --Thetornado76 (talk) 07:41, 21 December 2021 (UTC)
- I approve this proposal. --Marek-M (talk) 08:19, 21 December 2021 (UTC)
I have comments but abstain from voting on this proposal. comments --Wobi9000 (talk) 08:57, 21 December 2021 (UTC) Hello, I have a general question. Are we sure about having parcel lockers being areas? IMO just having a single option in form of nodes would make tagging more consistent and in doubt more concise. Thanks for your feedback.
- - @Wobi9000 I strongly support only mapping those features as nodes and disallowing areas but a lot of people in the discussion page wanted areas so I included them in the proposal.
--Tomczk (talk) 20:30, 21 December 2021 (UTC)
- @Wobi9000: The reason for accepting areas for this tag was that micromappers WILL map it as areas anyway. This has already happened with bicycle rentals AFAIR. --Rmikke (talk) 09:56, 27 December 2021 (UTC)
- I approve this proposal. --Village (talk) 08:58, 21 December 2021 (UTC)
- I approve this proposal. --pio2_122 (talk) 09:06, 21 December 2021 (UTC)
- I oppose this proposal. Because with "parcel_pickup" and "parcel_mail_in" we are introducing a tagging that is not compatible with the previously accepted tagging in post-office and will clearly lead to confusion. It would make more sense to adopt the tags from post-office in their meaning. Also, no main tags are necessary for this, post_office:* or if absolutely necessary parcel_locker:* can be used --SafetyIng (talk) 09:25, 21 December 2021 (UTC)
- I approve this proposal. --Starsep (talk) 10:52, 21 December 2021 (UTC)
- I have comments but abstain from voting on this proposal. Should take the opportunity to discuss post_office:*=* vs parcel_locker:*=* ---- Kovposch (talk) 12:32, 21 December 2021 (UTC)
- I approve this proposal. --Szydzio (talk) 12:39, 21 December 2021 (UTC)
- I approve this proposal. --Maraf (talk) 12:48, 21 December 2021 (UTC)
- I approve this proposal. --Władysław Komorek (talk) 13:05, 21 December 2021 (UTC)
- I approve this proposal. --Tordanik 14:26, 21 December 2021 (UTC)
- I oppose this proposal. Welcome to the chaos. Ending a proposal prematurely and starting a new one almost at the same time is not very productive. For this reason alone, I reject it. I also consider the established tagging to be sufficient.--streckenkundler 15:09, 21 December 2021 (UTC)
- "Ending a proposal prematurely and starting a new one almost at the same time is not very productive. " the previous vote was clearly going to be refused, author of proposal amended as requested. Why keeping clearly doomed vote for longer and wasting time of all involved would be productive? Mateusz Konieczny (talk) 20:44, 21 December 2021 (UTC)
- Sure, but you have to give the user time to look at the new proposal. Instead, a new proposal was created with the old data of "Drafted on" and "RFC start". I wonder if the vote is valid at all... For me, this vote is invalid from the start!--streckenkundler 21:29, 21 December 2021 (UTC)
- Wiki page describing proposal process does not specify if putting proposal for revote requires restarting entire process of RFC etc. It just claims that author can end vote early as rejected, re-work proposal and resubmit. Therefore I do not see a reason why this vote would be considered invalid. The only thing that changed was one tag which was clearly communicated. --Tomczk (talk) 23:43, 21 December 2021 (UTC)
- I would have expected that between the first and the second proposal the user would be given enough time to assess the new proposal. I miss that here. For me, this process of the proposal is the worst way to go. I cannot say more than no! --streckenkundler 23:19, 22 December 2021 (UTC)
- Wiki page describing proposal process does not specify if putting proposal for revote requires restarting entire process of RFC etc. It just claims that author can end vote early as rejected, re-work proposal and resubmit. Therefore I do not see a reason why this vote would be considered invalid. The only thing that changed was one tag which was clearly communicated. --Tomczk (talk) 23:43, 21 December 2021 (UTC)
- Sure, but you have to give the user time to look at the new proposal. Instead, a new proposal was created with the old data of "Drafted on" and "RFC start". I wonder if the vote is valid at all... For me, this vote is invalid from the start!--streckenkundler 21:29, 21 December 2021 (UTC)
- See German Forum for my other substantive criticisms.This is too long for this vote...--streckenkundler 18:12, 23 December 2021 (UTC)
- Brief summary of my critique of the content... I still don't understand the process? Why is there an attempt to push through the unfinished proposal at all costs? Why is the discussion of the first proposal mixed up with that of the second? This causes massive confusion. It has been criticised several times that a renewed RFC process is missing. It really is the better way to always do this! It has been pointed out again and again at https://wiki.openstreetmap.org/wiki/Key:post_office. This has still not been taken into account. In my opinion, this can and must be taken into account! Subsequently, something can and should then be changed there as well. At https://wiki.openstreetmap.org/wiki/Key:post_office there is a section "post_office:<service>=*". This is nothing more than a list of the respective services. These can be entered as post_service:*=* instead of the previous entry and can be used in this proposal at the same time. However, this also requires a cancellation of this Proposal. For me, a textual change and extension is absolutely necessary. It must also be described exactly what is to be changed by what. For example, we have a distinction here between with a screen and without... That is also missing. Translated with www.DeepL.com/Translator (free version)--streckenkundler 22:21, 26 December 2021 (UTC)
- Usage of "post_office:<service>=*" has been addressed in discussion page before the first RFC and nothing changed since then. Some people wanted it, most people didn't want these tags in this proposal since they are semantically confusing.
- You have made your points here multiple times and I really don't think there is anything more to add. If your arguments convinced people then they will vote against the proposal. --Tomczk (talk) 00:18, 27 December 2021 (UTC)
- Brief summary of my critique of the content... I still don't understand the process? Why is there an attempt to push through the unfinished proposal at all costs? Why is the discussion of the first proposal mixed up with that of the second? This causes massive confusion. It has been criticised several times that a renewed RFC process is missing. It really is the better way to always do this! It has been pointed out again and again at https://wiki.openstreetmap.org/wiki/Key:post_office. This has still not been taken into account. In my opinion, this can and must be taken into account! Subsequently, something can and should then be changed there as well. At https://wiki.openstreetmap.org/wiki/Key:post_office there is a section "post_office:<service>=*". This is nothing more than a list of the respective services. These can be entered as post_service:*=* instead of the previous entry and can be used in this proposal at the same time. However, this also requires a cancellation of this Proposal. For me, a textual change and extension is absolutely necessary. It must also be described exactly what is to be changed by what. For example, we have a distinction here between with a screen and without... That is also missing. Translated with www.DeepL.com/Translator (free version)--streckenkundler 22:21, 26 December 2021 (UTC)
- @Streckenkundler: But here I have to agree with he other: The wiki says that the process can be withdrawn from the vote and revised as "rejected". (Quote: "It is acceptable for author of the proposal to end the vote earlier as a rejected". Further down it says under "rejected": "Rejected features may be resubmitted, modified, and new vote started. You can also move back to the RFC process." So you don't must move back to RFC and no other timespan is called. So from the process all okay. The old voting was also clear, why there were voting against the proposal. -- SafetyIng
- "Ending a proposal prematurely and starting a new one almost at the same time is not very productive. " the previous vote was clearly going to be refused, author of proposal amended as requested. Why keeping clearly doomed vote for longer and wasting time of all involved would be productive? Mateusz Konieczny (talk) 20:44, 21 December 2021 (UTC)
- I approve this proposal. --Eifelkobold! (talk) 15:22, 21 December 2021 (UTC)
- I approve this proposal. --Cz ja (talk) 17:00, 21 December 2021 (UTC)
- I approve this proposal. --Rskedgell (talk) 16:58, 21 December 2021 (UTC)
- I approve this proposal. Well done Map HeRo (talk) 17:37, 21 December 2021 (UTC)
- I approve this proposal.--Cristoffs (talk) 17:52, 21 December 2021 (UTC)
- I approve this proposal.--Dawid2849 (talk) 18:59, 21 December 2021 (UTC)
- I approve this proposal. --Mordechai23 (talk) 18:01, 21 December 2021 (UTC)
- I approve this proposal. --Voltairovicz (talk) 18:09, 21 December 2021 (UTC)
- I oppose this proposal. As several people have pointed out, the correct term is "parcel lockers" (plural). Besides, there was no RFC and no time between the cancellation of the first vote and the start of the second vote. --Dafadllyn (talk) 18:16, 21 December 2021 (UTC)
- I approve this proposal. --Charl3s (talk) 18:25, 21 December 2021 (UTC)
- I approve this proposal. --VMeads (talk) 19:01, 21 December 2021 (UTC)
- I approve this proposal. --Jendrusk (talk) 19:23, 21 December 2021 (UTC)
- I approve this proposal. --BCNorwich (talk) 20:05, 21 December 2021 (UTC)
- I approve this proposal. --Mapminik (talk) 21:12, 21 December 2021 (UTC)
- I approve this proposal. --Olo81 (talk) 21:13, 21 December 2021 (UTC)
- I oppose this proposal. While one of the main concerns with the old proposal has been remedied (terminology), other concerns have not been further evaluated (deprecating of widely supported tag; vagueness; lack of a clear and well-articulated sub-scheme, etc). --kartonage (talk) 22:37, 21 December 2021 (UTC)
- I oppose this proposal. I was never bothered about lockers vs machine, as I expected it would result in a scenario like this one, with an “instant retry” RFC. Still, main reasons for voting against the proposal are not reusing existing mail service tags from post_office, and an assumption that objects with >10k uses can simply be “automatically” retagged. --Tohaklim (talk) 01:22, 22 December 2021 (UTC)
- I oppose this proposal. Same as the last two votes above and additionally as adding only a single value could by easy accomplished and this proposal only adds work to all developers without further gain. Please, take a step back and come up with a complete improvement. Thanks. --Skyper (talk) 15:47, 22 December 2021 (UTC)
- @Skyper: In my research I did not encounter any software using packstations with current tagging but I may have missedsomething. The point of this proposal is so that developers start using this feature e.g. carto will render them and they (devs) specifically said that current tagging scheme doesn't make sense to them and they would like something different and pointed to Seahorse's proposal. I don't think this was brought to attention in the discussion before and your comment made me curious so if you have an example of existing software where developers would need to put in work to adjust to new tagging scheme I would like to see it. --Tomczk (talk) 16:09, 23 December 2021 (UTC)
- Well, similar to getting the proper value name, you did not do your homework, carefully, e.g. taginfo lists some projects, [1]. I just read, that this is your first proposal, and I can understand that you want to get it accepted rather sooner than later but maybe you can reflect the criticism and for sure do not take it personal. Let's take a deep breath and give us together some more time to get more of us happy. I probably forgot to mention that I am in favor of reworking the parcel and letter infrastructure but we need a deeper reflected proposal. E.g. I like the idea to have more specific values than only "yes" and "no" for the services but in fact the single new value is the only improvement, atm. Why not proposing parcel_pick=only and so on. More to come on the talk page of this proposal or the fifth? one which will be needed if this one passes in its current state. --Skyper (talk) 20:35, 23 December 2021 (UTC)
- Two projects that use the tags have been informed of the proposal. I am a little surprised though since RFC lasted almost month and a half, you were actively participating and only now you decided to share this. I consider this thread closed to avoid any further off-topic comments. --Tomczk (talk) 22:40, 24 December 2021 (UTC)
- Yes, I was unaware that this was your first proposal and thought that the main concerns of deprecating tags are known and sadly did not take a careful look. Do you want to blame me for that? Additionally, I was surprised about your rush and ask you to slow down, some weeks ago, besides all the other concerns which were not carefully solved in my point of view. --Skyper (talk)
- Two projects that use the tags have been informed of the proposal. I am a little surprised though since RFC lasted almost month and a half, you were actively participating and only now you decided to share this. I consider this thread closed to avoid any further off-topic comments. --Tomczk (talk) 22:40, 24 December 2021 (UTC)
- Well, similar to getting the proper value name, you did not do your homework, carefully, e.g. taginfo lists some projects, [1]. I just read, that this is your first proposal, and I can understand that you want to get it accepted rather sooner than later but maybe you can reflect the criticism and for sure do not take it personal. Let's take a deep breath and give us together some more time to get more of us happy. I probably forgot to mention that I am in favor of reworking the parcel and letter infrastructure but we need a deeper reflected proposal. E.g. I like the idea to have more specific values than only "yes" and "no" for the services but in fact the single new value is the only improvement, atm. Why not proposing parcel_pick=only and so on. More to come on the talk page of this proposal or the fifth? one which will be needed if this one passes in its current state. --Skyper (talk) 20:35, 23 December 2021 (UTC)
- Vespucci, NSI, iD at least Mateusz Konieczny (talk) 18:16, 23 December 2021 (UTC)
- Well, the editors sure, the mappings will need to be updated which was mentioned in "other actions to be taken". I think both iD and JOSM have these schemas/mappings in JSON/XML formats so Pull requests can be created by non developers so not that much work for devs. --Tomczk (talk) 18:37, 23 December 2021 (UTC)
- @Skyper: In my research I did not encounter any software using packstations with current tagging but I may have missedsomething. The point of this proposal is so that developers start using this feature e.g. carto will render them and they (devs) specifically said that current tagging scheme doesn't make sense to them and they would like something different and pointed to Seahorse's proposal. I don't think this was brought to attention in the discussion before and your comment made me curious so if you have an example of existing software where developers would need to put in work to adjust to new tagging scheme I would like to see it. --Tomczk (talk) 16:09, 23 December 2021 (UTC)
- I oppose this proposal. My english is not so good, but I have the same opinion as user SafetyIng --Surveyor54 (talk) 15:58, 22 December 2021 (UTC)
- I oppose this proposal. As before, I'm not of the opinion that a migration to a new tag is necessary but I can live with that. However, parcel_pickup=* and parcel_mail_in=* are still unnecessarily duplicating the keys recently introduced with post_office=post_partner. --Nw520 (talk) 17:48, 22 December 2021 (UTC)
- Which keys are supposed to be duplicated? post_office:parcel_pickup post_office:parcel_to ? But it is not fitting as it is not a post office Mateusz Konieczny (talk) 11:14, 23 December 2021 (UTC)
- @Mateusz Konieczny: Yes, I did mean post_office:parcel_from=*, post_office:parcel_pickup=* and post_office:parcel_to=*. In my opinion newly proposed tags should strive to be as closely similar to already existing tags as possible, meaning that I would have expected
parcel_from=*,parcel_pickup=*andparcel_to=*as keys instead (with the major benefit that when looking for a place to drop off your parcel you can simply query~"parcel_from$"~".*"and that similar concepts share the same (sub-)keys). --Nw520 (talk) 14:08, 25 December 2021 (UTC)- @Nw520:I can see a good reason for NOT mimicking post_office:parcel_from=* and so on. It would be confusing, as the post_office=post_partner scheme is designed for much more complicated system of mail pickup/send points, each possibly working for multiple mailing systems. For example parcel_pickup=* has different meaning than both post_office:parcel_pickup=* and post_office:parcel_to=*, so trying to make it look like post_office=post_partner schema would rather add confusion than resolve it. --Rmikke (talk) 09:37, 27 December 2021 (UTC)
- @Rmikke: I'm probably being silly for not noticing (honestly sorry for that), but could you please point out what exactly can be expressed using parcel_mail_in=* but not using post_office:parcel_from=* (minus the prefix)? I'm with you that parcel_pickup=* as it's proposed here would lead to a great amount of confusion due to it's broader definition compared to post_office:parcel_pickup=* since it also includes the concept behind post_office:parcel_to=*, but this only reinforces my view that the three relevant sub-tags of post_office:=* should be adopted instead.
- I also don't understand why taking a (from my point of view fully compatible) subset of a scheme designed for much more complicated systems would be problematic: Sure, parcel lockers are usually operated by only one mailing system but at least in local politics there are already discussions of lockers served by multiple companies (as part of so-called Micro-Hubs) so it wouldn't even be bad to consider such multi-system lockers. And as stated before, in my opinion 1) post_office:parcel_from=*, 2) post_office:parcel_pickup=* and 3) post_office:parcel_to=* (minus the prefixes) can very much be applied to parcel lockers: 1) I can dispatch parcels, 2) I can pickup parcels which were rerouted since I wasn't at home at the time of delivery and 3) (at least for DHL in Germany) I can give others an address of a parcel locker instead of my home's address. --Nw520 (talk) 17:39, 27 December 2021 (UTC)
- @Nw520:I can see a good reason for NOT mimicking post_office:parcel_from=* and so on. It would be confusing, as the post_office=post_partner scheme is designed for much more complicated system of mail pickup/send points, each possibly working for multiple mailing systems. For example parcel_pickup=* has different meaning than both post_office:parcel_pickup=* and post_office:parcel_to=*, so trying to make it look like post_office=post_partner schema would rather add confusion than resolve it. --Rmikke (talk) 09:37, 27 December 2021 (UTC)
- @Mateusz Konieczny: Yes, I did mean post_office:parcel_from=*, post_office:parcel_pickup=* and post_office:parcel_to=*. In my opinion newly proposed tags should strive to be as closely similar to already existing tags as possible, meaning that I would have expected
- Which keys are supposed to be duplicated? post_office:parcel_pickup post_office:parcel_to ? But it is not fitting as it is not a post office Mateusz Konieczny (talk) 11:14, 23 December 2021 (UTC)
- I approve this proposal. --Krystek (talk) 18:25, 22 December 2021 (UTC)
- I approve this proposal. --Yazhubal (talk) 19:02, 22 December 2021 (UTC)
- I approve this proposal. I think lockers should be plural, but this is far better than "parcel machine". --InsertUser (talk) 19:17, 22 December 2021 (UTC)
- I approve this proposal. What happens to the existing vending=parcel_pickup etc tags? They are deprecated, but what does that mean. We introduce more complexity here. And what is with Key:post_office:parcel_pickup? Does this coexist, too? --Strubbl (talk) 21:24, 22 December 2021 (UTC)
- @Strubbl: I think this is well described in this wiki article: https://wiki.openstreetmap.org/wiki/Deprecated_features ; in essence it would be discouraged to tag new features using old tags (can't do outright tag bans in osm) and it would be justified to edit old features to use new tags, it would also be a kind of contract for data consumers e.g. carto render that this is the way this feature will be tagged and they can rely on this tagging scheme while rendering the features on a map. As for post_office:* tags they were rejected during RFC/discussion by a lot of people due to being confusing so they were not implemented in the proposal. If this explanation is satisfying you may consider changing your vote. Thanks. --Tomczk (talk) 21:43, 22 December 2021 (UTC)
- @Tomczk:Thanks for clarifying. Would it be possible to add the reference to the deprecated wiki page above or is not allowed anymore? One more point: The proposal states that discussion led to the possibility to add this tagging to areas, but not the reason why that makes sense. Would it be possible to state why here in the proposal? --Strubbl (talk) 22:19, 22 December 2021 (UTC)
- @Strubbl: I added the link. Well the reason for allowing areas is that people would vote no to the proposal if I didn't allow it :) The arguments are in the discussion page and I'm not sure more clarification to that point is needed in the proposal itself as the proposal is mainly about changing the vending machine tag to amenity and allowing areas is just a small details here. --Tomczk (talk) 00:29, 23 December 2021 (UTC)
- @Tomczk:Thanks for clarifying. Would it be possible to add the reference to the deprecated wiki page above or is not allowed anymore? One more point: The proposal states that discussion led to the possibility to add this tagging to areas, but not the reason why that makes sense. Would it be possible to state why here in the proposal? --Strubbl (talk) 22:19, 22 December 2021 (UTC)
- @Strubbl: I think this is well described in this wiki article: https://wiki.openstreetmap.org/wiki/Deprecated_features ; in essence it would be discouraged to tag new features using old tags (can't do outright tag bans in osm) and it would be justified to edit old features to use new tags, it would also be a kind of contract for data consumers e.g. carto render that this is the way this feature will be tagged and they can rely on this tagging scheme while rendering the features on a map. As for post_office:* tags they were rejected during RFC/discussion by a lot of people due to being confusing so they were not implemented in the proposal. If this explanation is satisfying you may consider changing your vote. Thanks. --Tomczk (talk) 21:43, 22 December 2021 (UTC)
- I approve this proposal. --JannikK (talk) 23:12, 22 December 2021 (UTC)
- I oppose this proposal. This proposal is against the requirements because: 1) there had been no RFC two weeks before the vote started. Rewritten proposal is a new proposal which also needs RFC; 2) All discussions have not been resolved on the Talk page: [2] - still an open question and only one answer so no consensus; 3) All major and minor disagreements about the proposal have not been resolved. And the previous vote should be kept on a separate page, not removed and be hidden in the history. Furthermore, from what I see from native speakers, "parcel_lockers" name is more popular: [3], [4], [5], [6]. I also prefer the plural form. But the main reason I'm voting against is that there was no RFC after rewriting the proposal, so this vote is not valid. So I agree with streckenkundler. --maro21 23:31, 22 December 2021 (UTC)
![[6]](https://wiki.openstreetmap.org/wiki/File:Australia_Post_Parcel_Lockers.JPG){kind=link}
- I approve this proposal. Makes tagging this much more clear for average users; Most "deprecated" stuff comes from imports anyway, so not much compassion afforded. --Hungerburg (talk) 11:36, 23 December 2021 (UTC)
- I approve this proposal. --Doktorpixel14 (talk) 17:00, 23 December 2021 (UTC)
- I approve this proposal. --zuicz (talk) 18:22, 23 December 2021 (UTC)
- I approve this proposal. --Kubahaha (talk) 21:45, 23 December 2021 (UTC)
- I oppose this proposal. There was no discussion and time for comments on this proposal. What I dislike most is the unclear situation with the thousands of existing parcel lockers tagged using the old scheme and the completely inconsistent naming of tags with respect to the recently approved post_office:* tags. --Mueschel (talk) 10:18, 26 December 2021 (UTC)
- @Mueschel: For existing parcel lockers tagged using the old scheme please see https://wiki.openstreetmap.org/wiki/Deprecated_features . As for consistency with the recently approved post_office:* tags please see my answer for Nw520 above. --Rmikke (talk) 09:47, 27 December 2021 (UTC)
- @Rmikke: The right time for this discussion would have been the RFC phase - which was skipped --Mueschel (talk) 10:37, 27 December 2021 (UTC)
- @Mueschel: I agree that it might be better to have this proposal waiting another two weeks, but... First, it is not required as SafetyIng noticed above. Second, as I understand, the voting has been reissued after the users protested changing parcel_locker to parcel_machine during the previous vote, so it is closer to the original proposal than the one we voted before. And there is link to previous proposal in this proposal, so there is an easy access to the previous RFC and the discussion and all your answers are there. Please consider changing your vote. --Rmikke (talk) 14:46, 30 December 2021 (UTC)
- I approve this proposal. --Javnik (talk) 10:21, 27 December 2021 (UTC)
- I approve this proposal. It's not a usual vending machine (at least in my opinion) and it's independent from post offices. --ZiemekZ (talk) 15:05, 27 December 2021 (UTC)
- I approve this proposal. --Michi (talk) 02:05, 29 December 2021 (UTC)
- I approve this proposal. --Mikmach (talk) 16:10, 29 December 2021 (UTC)
- I approve this proposal. --快乐的老鼠宝宝 (talk) 06:44, 30 December 2021 (UTC)
Voting Results
| name | approved | rejected | withheld |
|---|---|---|---|
| AncymonOSM | 1 | 0 | 0 |
| Arc2 | 1 | 0 | 0 |
| BCNorwich | 1 | 0 | 0 |
| Carnildo | 1 | 0 | 0 |
| Charl3s | 1 | 0 | 0 |
| Cristoffs | 1 | 0 | 0 |
| Cz ja | 1 | 0 | 0 |
| Dafadllyn | 0 | 1 | 0 |
| Dawid2849 | 1 | 0 | 0 |
| Dieterdreist | 1 | 0 | 0 |
| Doktorpixel14 | 1 | 0 | 0 |
| Eifelkobold! | 1 | 0 | 0 |
| Emilius123 | 1 | 0 | 0 |
| Hungerburg | 1 | 0 | 0 |
| InsertUser | 1 | 0 | 0 |
| JannikK | 1 | 0 | 0 |
| Javnik | 1 | 0 | 0 |
| Jendrusk | 1 | 0 | 0 |
| kartonage | 0 | 1 | 0 |
| Kocio | 1 | 0 | 0 |
| Kovposch | 0 | 1 | 0 |
| Krystek | 1 | 0 | 0 |
| Kubahaha | 1 | 0 | 0 |
| Map HeRo | 1 | 0 | 0 |
| Mapminik | 1 | 0 | 0 |
| Maraf | 1 | 0 | 0 |
| Marek-M | 1 | 0 | 0 |
| maro21 | 0 | 1 | 0 |
| Mateusz Konieczny | 1 | 0 | 0 |
| Michi | 1 | 0 | 0 |
| Mikmach | 1 | 0 | 0 |
| Mordechai23 | 1 | 0 | 0 |
| Mueschel | 0 | 1 | 0 |
| NieWnen | 1 | 0 | 0 |
| Nw520 | 0 | 1 | 0 |
| Olo81 | 1 | 0 | 0 |
| Pio2_122 | 1 | 0 | 0 |
| Riiga | 1 | 0 | 0 |
| Rmikke | 1 | 0 | 0 |
| Rskedgell | 1 | 0 | 0 |
| SafetyIng | 0 | 1 | 0 |
| Skyper | 0 | 1 | 0 |
| SomeoneElse | 0 | 1 | 0 |
| streckenkundler | 0 | 1 | 0 |
| Strubbl | 1 | 0 | 0 |
| Surveyor54 | 0 | 1 | 0 |
| Syntex | 1 | 0 | 0 |
| Szydzio | 1 | 0 | 0 |
| Thetornado76 | 1 | 0 | 0 |
| Tohaklim | 0 | 1 | 0 |
| Tordanik | 1 | 0 | 0 |
| Village | 1 | 0 | 0 |
| VMeads | 1 | 0 | 0 |
| Voltairovicz | 1 | 0 | 0 |
| Władysław Komorek | 1 | 0 | 0 |
| Wobi9000 | 0 | 0 | 1 |
| Yazhubal | 1 | 0 | 0 |
| ZiemekZ | 1 | 0 | 0 |
| zuicz | 1 | 0 | 0 |
| 快乐的老鼠宝宝 | 1 | 0 | 0 |
| Vote count | Approved | Rejected | Abstained |
|---|---|---|---|
| 60 | 47 | 12 | 1 |
Approval rate:
47 / (60 - 1) = 0.7966
Approval rate is greater than required 75%. Proposal is approved.