added rendering of amenity=parcel_locker

[ttomasz]

Fixes #3558

Changes proposed in this pull request:

• adds rendering of amenity=parcel_locker

Test rendering with links to the example places:
don't have it hosted in public, tested location: 19/52.34919/14.56307

Before
was not rendered

After

In the issue it was proposed to use coalesce(brand, operator, name) + ref if present for text but adding that would require larger change (modifying CASE expression that sets name) and I wasn't sure how that would be received since it's my first contribution to carto. Therefore this uses just name + ref (if present) to get these features rendered and further improvements can be done in the future if required.

[imagico]

Thanks for the PR.

amenity=parcel_locker has 1342 uses, almost all of them added during the last month, almost all in Europe, most of them in Poland operated by InPost, about half added/retagged by a single user (Dawid2849).

#3558 is about rendering of vending=parcel_* - since i mentioned the use numbers in #3558 (comment) they have about doubled in less than a year (~18k now in total). So this quite clearly remains so far the dominating tag for this kind of feature.

Independent of tagging - the symbol does not appear intuitive to me - looks like some kind of box measuring/wrapping device to me (like from one of these foil wrapping services on airports for luggage). As a general advice: When you want to illustrate infrastructure for human interaction the most intuitive symbol is often coming from illustrating the human activity itself. And perspective is not typically going to work well at our standard symbol size, we therefore with good reason mostly use profile depictions in our symbol designs. Since for the moment it is unlikely anyway that we will add this feature it would be a good idea to put some more thought and work into designing a suitable intuitive symbol.

If it makes sense to render either name or ref on those if and when rendering is added is a different question. Right now almost none of the features with amenity=parcel_locker have an actual name tagged on the name tag, most have a description/verbal classification (Paczkomat InPost) or a description plus reference number in the name tag (Packstation 105). Unless mappers change their practice i see no basis of rendering labels from that under the goals we have.

[matkoniecz]

I am familiar with this devices and rendering seems actual fitting and reasonably clear.

Not sure which activity can be displayed within 16x16 pixels.

I agree that right now name tags are clearly misused. I would suggest rendering brand instead, similarly to how ATM labels are rendered.

about half added/retagged by a single user (Dawid2849).

In this case such retagging has a clear community support.

Though I agree that this devices are far more important and popular in Poland than elsewhere. Though as far as I know their number grows across world so I would be fine with their rendering.

[matkoniecz]

have you tried flat icon (without 3D effect) to be more consistent with other icons?

The tagging thing will be a bit controversial given the entire deprecation vote vs "there is no such as deprecation vote" position etc, and may be a bit better to wait a bit until it is more clearly established.

[imagico]

In this case such retagging has a clear community support.

I did not mean to imply otherwise. My comment was about the lack of broad adoption of the tag. A proposal process supported by a small, extrovert English speaking part of the community is one thing, actual use of the tag world wide by the whole mapping community something very different. We should have a close look at the latter when making any decisions on feature additions.

Regarding symbol design - see #3558.

[Tomasz-W]

I suggest to use man_made-grey color for this icon as amenity-brown is more likely for bigger services operated by people (e.g. cultural centres) and also historical features. For the same reason vending=parking_tickets and vending=publc_transport_tickets icons color was set to man_made-grey because they are more smal, free standing objects than a regular amenity.

[pnorman]

I'm not convinced about the symbol either, but the SVG needs cleaning up

[ttomasz]

@imagico I'll sum up some of history of issue #3558 and parcel lockers.

It was initially proposed to render these features in #1561 in this comment (2018) but it was not implemented citing tagging issues (usage of vending_machine instead of separate tag).

Issue #3558 was created in 2018 citing popularity of such services in Germany and requesting to render them.
Quote for reference:

In germany we have a lot of discussion about parcel services having capacity issues due to the growth of e-commerce.
(...)
The biggest parcel service in germany is DHL: Most of their parcel pickup-locations are tagged with:
vending=parcel_pickup;parcel_mail_in

I created issue #4372 proposing the same thing in 2021.
I'll paste some description here for reference:

Rendering these features would be highly valuable.
There are about 11 000 - 14 000 [as of 2021-04-14, currently this number is around 18 000 - 20 000] of these points in Poland.
They are very popular alternative to post offices which means it's something that people would like to see on the map so they know where these points are located.
Right now we have only a few thousands mapped but efforts to map these features could increase significantly if people saw their work visible in the map.

Major global shipping companies such as DHL, GLS or Amazon operate these machines. If you check NSI you'll see that there brands for these machines from companies all over the world. They are very popular in Poland and demand to see them on the map is very high. Functionally they are similar to post boxes which are already rendered so I don't see a reason to not render them.

In the #3558 again it was cited that tagging of these features was an issue.

I created proposal to fix the tagging which was approved by the community.
Old tagging (amenity=vending_machine) was deprecated and new tagging (amenity=parcel_locker) was established as the correct way to tag these features. Community voted and approved this proposal.

Features will be retagged to the new tagging scheme and since they are not rendered at the moment in carto I don't see a reason to wait since it's not going to make things disappear from map.

Therefore this:

amenity=parcel_locker has 1342 uses, almost all of them added during the last month, about half added/retagged by a single user (Dawid2849).

#3558 is about rendering of vending=parcel_* - since i mentioned the use numbers in #3558 (comment) they have about doubled in less than a year (~18k now in total). So this quite clearly remains so far the dominating tag for this kind of feature.

is result of the proposal that was created by requirements from the issue that you mention (#3558).

As for:

Independent of tagging - the symbol does not appear intuitive to me (...)

This symbol is consistent with other similar features e.g.:

• https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpost_box
• https://wiki.openstreetmap.org/wiki/Tag:amenity%3Datm
• https://wiki.openstreetmap.org/wiki/Tag:vending=parking%20tickets?uselang=en-GB
• https://wiki.openstreetmap.org/wiki/Tag:vending%3Dpublic_transport_tickets
• https://wiki.openstreetmap.org/wiki/Tag:vending%3Dexcrement_bags

All of these contain the bar symbolising machine/box and item which is taken from machine/box or put into machine/box.

There is not space for much more and if these are considered intuitive enough then I believe the package in proposed icon should be good enough as well.

If it makes sense to render either name or ref on those if and when rendering is added is a different question.

This was discussed in #3558 and I think everyone who commented was in favour. There may be multiple lockers from diferent companies in close proximity and differentiating them is needed.

Right now almost none of the features with amenity=parcel_locker have an actual name tagged on the name tag, most have a description/verbal classification (Paczkomat InPost) or a description plus reference number in the name tag (Packstation 105).

Not sure what you mean but as mentioned above if e.g. InPost and DHL put their machines close to each other one would want to see on the map which is which before going to the physical location to retrieve the package to save time on looking for the right box.

In the issue it was proposed to use brand or operator or name in that order for the label. I wasn't sure about implementing it since I don't know Carto that well but if this will be better I'll upload the change in the next commit.

have you tried flat icon (without 3D effect) to be more consistent with other icons?

@matkoniecz I haven't but I think similarly to books:

• https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dlibrary
• https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpublic_bookcase
• https://wiki.openstreetmap.org/wiki/Tag:shop%3Dbooks

it is easier to show package in "3D".

The tagging thing will be a bit controversial given the entire deprecation vote vs "there is no such as deprecation vote" position etc, and may be a bit better to wait a bit until it is more clearly established.

Not sure why? What is the point of proposals if not to establish accepted ways of tagging things? If there are no ongoing proposals that wish to change tagging of these features I don't see a reason to wait.

For the same reason vending=parking_tickets and vending=publc_transport_tickets icons color was set to man_made-grey because they are more smal, free standing objects than a regular amenity.

@Tomasz-W but these features are brown in the style?

  [feature = 'amenity_vending_machine'][zoom >= 19] {
    [vending = 'excrement_bags'] {
      marker-file: url('symbols/amenity/excrement_bags.svg');
    }
    [vending = 'parking_tickets'] {
      marker-file: url('symbols/amenity/parking_tickets.svg');
    }
    [vending = 'public_transport_tickets'] {
      marker-file: url('symbols/amenity/public_transport_tickets.svg');
    }
    marker-fill: @amenity-brown;
    marker-clip: false;
  }

[ttomasz]

@matkoniecz I changed name rendering to prefering brand and operator to name.
Here's how it looks now:

@pnorman I tried modifying SVG as requested and I think it's good now but I'm no expert in Inkscape so let me know if there are any issues with the file.

[Tomasz-W]

@Tomasz-W but these features are brown in the style?

Sorry, my bad. Then it should be also brown :)

[imagico]

I will primarily comment on the symbol design aspect here - the question of the real world relevancy of the real world feature parcel locker/parcel pickup and accordingly the principal suitability of showing it in a map was something i did not and do not intend to comment on and the question of what tagging is right is - as mentioned again and again in the past - off-topic on this tracker. To put it bluntly: We would have no problem if mappers decided to tag this kind of feature moon=cheese if they do so consistently and we might do that even if there is a proposal approved to deprecate such tagging.

And since you asked:

What is the point of proposals if not to establish accepted ways of tagging things?

No, proposals are a way for people who invent new tags to get critical evaluation and feedback on their tagging ideas. They are not in any way authoritative (and they completely lack any legitimacy to be that). There are plenty of tags that are approved by proposals but that are complete failures in practical mapping and there are also tags that have been rejected in proposals but have still become very successful and widely accepted tags.

Regarding the symbol design - the existing symbols using a slot symbology (atm, post box, vending machines) do so not to symbolize a machine or box, they symbolize the slot you can find on those machines (to receive a ticket or money, to enter a card or a letter). This visual of a (typically horizontal) slot is strongly present in the memory of those who know and have used those machines because it is strongly tied to the process of using them - hence it tends to lead to intuitive recognition of the real world feature from the symbol. That is not the case here.

Regarding the perspective/3D symbolization - to try without that is a recommendation from me and @matkoniecz based on our past experience with symbols in this style. We have no rule that disallows this but it is rare this works well at our symbol size. Hence the recommendation to try a profile symbol design. You are welcome to further work on the perspective/3D idea but the chances are in my experience small that this will work well.

[imagico]

My formal review for what i think is needed for this to be accepted under the goals of the project:

• Needs to be based on a well established tagging that is dominating in use by the mapper community at large and world wide. Right now that is the case for vending=parcel_* - though with iD endorsing amenity=parcel_locker there is a significant chance that this might change over time. Until that is decided we should keep our long term practice not to actively steer mappers into a direction we favor (or what the small segment of the English speaking part of the community active in tagging proposal votes favors) but limit ourselves to supporting mappers in consistent use of tags.
• Needs a symbol that is broadly intuitively recognizable. I have presented a sketch for a possible concept in Render vending=parcel_pickup;parcel_mail_in #3558 (comment) - could use further fine tuning work - or any other design idea would be welcome as well.
• Based on current tagging trends on amenity=parcel_locker should not render the name tag because that is almost never used to tag an actual name. Based on tagging trends of vending=parcel_pickup;parcel_mail_in both brand and ref could be suitable for labeling - but for constructive mapper feedback it should be visible from the label design which part of the label is which (so not just concat both).

None of these is essential for me - if there is consensus among the other maintainers in favor of this change despite my objections/requests for changes that is ok.

[ttomasz]

Regarding the symbol design - the existing symbols using a slot symbology (atm, post box, vending machines) do so not to symbolize a machine or box, they symbolize the slot you can find on those machines (to receive a ticket or money, to enter a card or a letter). This visual of a (typically horizontal) slot is strongly present in the memory of those who know and have used those machines because it is strongly tied to the process of using them - hence it tends to lead to intuitive recognition of the real world feature from the symbol. That is not the case here.

Is locker really that different from a slot? I think very similar logic applies in both cases.

Anyway I tried various icons starting with one currently implemented in carto that has parcel for greatest consistency (https://wiki.openstreetmap.org/wiki/Tag:shop%3Dtrade):

and variations to try to make it look more like a parcel:

as well as icon presenting the locker machine (from iD icons):

Here's the icon that you put together:

and I believe none of them are as intuitive as 3d package shown in original post.

Regarding "Needs to be based on a well established tagging " there are two planned retagging actions from:

• french community: https://wiki.openstreetmap.org/wiki/Mechanical_Edits/overflorian-mass-edits/deprecate_vending%3Dparcel_pickup_in_France
• polish community: https://forum.openstreetmap.org/viewtopic.php?id=74790

and new tagging is already being utilized by downstream applications e.g.: https://www.openstreetmap.org/user/skunk/diary/398522

Rendering name was addressed in 2002c7f

[Adamant36]

and I believe none of them are as intuitive as 3d package shown in original post.

Just to throw my opinion out there since I'm sort of involved in this, the 3d icon isn't great because most (or all) icons are 2d. Also, it's always clearer to have an icon that's filled in. That said, the rendering of the icon presented by @imagico isn't great either. At least not in the example you've provided. That could be up to how it's currently drawn though. From what I understood of @imagico's comment in the other issue though the icon is merely a draft. So there's totally room for improvement. I like the first couple of 2d examples in your last comment though, but that's just me. I can see where the second one might not be super intuitive. The first one makes sense though and I like that it's filled in. The third one might work if the style had a higher rendering DPI or whatever. I don't think it does at the current resolution though.

[imagico]

What you need to understand when assessing intuitive readability of map design is that it is essential to abstract from your own subjective and culture specific impression. Neither you nor me are representative for target map users of this style. It does not matter much if we find a symbol design intuitive or not. Therefore my key argument is not that the suggested symbol is not intuitively recognizable to me but that i see reasons to think that it is non-recognizable to many potential world wide map users. And i tried to explain a bit how i came to that conclusion by describing how the psychology of recognition of symbols tends to work.

I think it is very good that you try different variations now - but as you probably can imagine none of them so far really seems to work to me.

Your rendering of my symbol draft for some reason is not pixel aligned by the way - to properly assess its suitability you need to change that. Both the box and the wall shape in that symbol are meant to be perfectly pixel aligned - they should be so in the final rendering as well.

[SomeoneElseOSM]

Re flat vs 3d, in another style I went with flat: https://map.atownsend.org.uk/maps/map/map.html#zoom=25&lat=-25.00600137&lon=135.18000193 (that symbol isn't svg, though, so isn't suggested to be used here).

[ttomasz]

Also, it's always clearer to have an icon that's filled in.

@Adamant36 there a nice example of filled icon but it's DPD's logo, so even if we remake it from different perspective I'm afraid it could be too similar to avoid some IP infringement and I'm not willing to spend time on getting legal opinions for that.

here's an example of their parcel locker btw https://commons.wikimedia.org/wiki/File:DPD_pakiautomaat_Kosel._31.01.2021.jpg

[syntex1]

What you need to understand when assessing intuitive readability of map design is that it is essential to abstract from your own subjective and culture specific impression. Neither you nor me are representative for target map users of this style. It does not matter much if we find a symbol design intuitive or not. Therefore my key argument is not that the suggested symbol is not intuitively recognizable to me but that i see reasons to think that it is non-recognizable to many potential world wide map users. And i tried to explain a bit how i came to that conclusion by describing how the psychology of recognition of symbols tends to work.

I think it is very good that you try different variations now - but as you probably can imagine none of them so far really seems to work to me.

Your rendering of my symbol draft for some reason is not pixel aligned by the way - to properly assess its suitability you need to change that. Both the box and the wall shape in that symbol are meant to be perfectly pixel aligned - they should be so in the final rendering as well.

📦 Well the package/parcel emoji exists, so I think it is a well-recognized symbol.

[Adamant36]

Well the package/parcel emoji exists, so I think it is a well-recognized symbol.

I agree with @imagico comments. That said, most even semi-modern countries these days deliver parcels in boxes. I doubt there's much else they would use considering this is specifically about lockers and there probably isn't many, if any, parcel lockers in the middle of the Congolian rainforest or where ever he imagines someone might not understand the symbol. So as much as the Mbuti won't recognize it, they aren't going to be using parcel lockers either. Let alone OSM. Extreme edge cases aside of course.

[ttomasz]

@imagico I agree that w should be mindful of individual and cultural biases but I don't think this particular situation is where there is an issue with that.

I have created threads on community specific sections of OSM's forum for communities from all over the world:

• Argentina: https://forum.openstreetmap.org/viewtopic.php?id=74799
• Brazil: https://forum.openstreetmap.org/viewtopic.php?id=74800
• China: https://forum.openstreetmap.org/viewtopic.php?id=74801
• Cuba: https://forum.openstreetmap.org/viewtopic.php?id=74802
• Indonesia: https://forum.openstreetmap.org/viewtopic.php?id=74803
• India: https://forum.openstreetmap.org/viewtopic.php?id=74804
• Israel: https://forum.openstreetmap.org/viewtopic.php?id=74805
• Japan: https://forum.openstreetmap.org/viewtopic.php?id=74806
• Malaysia: https://forum.openstreetmap.org/viewtopic.php?id=74807
• Mexico: https://forum.openstreetmap.org/viewtopic.php?id=74812
• Panama: https://forum.openstreetmap.org/viewtopic.php?id=74808
• Russia: https://forum.openstreetmap.org/viewtopic.php?id=74809
• Thailand: https://forum.openstreetmap.org/viewtopic.php?id=74810

After 4 days there are no replies (I chose subforums that had some recent activity).

The notion that the icon might be unintuitive outside of anglosphere is theoretical unless we can confirm or measure it within those communities.

[imagico]

The discussion here on the matter of intuitive recognizability is mostly on a very shallow level so far - arguing with the existence of emoji for certain things and unanswered forum posts is decidedly besides the point.

I think i explained quite well why i think certain design approaches are more likely to be broadly and intuitively recognizable than others. Feel free to disagree. But you will only convince me to change my view of this with more substantial arguments. I have thought about this intensely for at least half an hour based on quite extensive experience in designing symbols and reviewing symbol designs of others - if you want to try to convince me that my conclusions from this are wrong you need to expect to spend at least a similar amount time on self critical reflection on the matter and careful formulation of your line of argument.

As i have explained a long time ago in #3635 i do not subscribe to the paradigm of primacy of feature addition and as a result choosing the least bad of all the bad options you can find without much effort. This does not work to create a well usable map style in a sustainable fashion and it leads to mediocrity in design.

So instead of trying to push a design concept through that is unlikely to work well - really try to think outside the box (sorry for the pun). And if you don't think you have any suitable new ideas for how to symbolize this feature: Take my draft and try to tune it to work well. First step would be to get an accurate pixel aligned rendering of the draft as is. Then have some brainstorming what exactly does not work about it to afterwards try to improve on those points.

[syntex1]

Ok, here is my attempt. I made it in paint :P Maybe we should include a delivery van within the icon?

[syntex1]

And a combination of three symbols

[ttomasz]

Subject of parcel lockers' icons was discussed a few times within Polish community before I started working on #3558 and two main lines of design were discussed:

1. icon presenting the machine
2. icon presenting package

While many people initially preferred icon presenting the machine when we tried asking people outside of OSM it turned out that it's not intuitive and package works better.

It was also discussed in the issue.

It's not like it was something randomly put together with no thought.

Take my draft and try to tune it to work well.

Now the problem with your suggestion and your draft that I have is that it's incompatible with all the other icons. Already people are arguing that 3d icon is too inconsistent with other existing icons and going with your idea of presenting "activity" would just make it worse.

Some examples:

ATM:

There is no activity. No hand taking the money from the slot.

Postbox:

No person putting mail in.

Vending:



No hand taking the item. Tickets have perforation/cutout that I have seen only in american movies.

Shops:








No exchange of goods for currency.

Not showing the service provided.

---

Currently proposed icon is consistent with similar objects: same colour, usage of "slot". Package is recognizable symbol that will correctly suggest that this place has something to do with receiving/sending packages. Usage of 3d is a little rare but not unprecedented (see book) and to go back to emoji example: https://emojipedia.org/package/ you can see how it renders by different companies and almost all of them chose to use 3d perspective which is also not that common for emojis which should confirm that this is indeed a good approach.

If carto icons should be redesigned to be more intuitive to larger variety of people from different cultural background then I believe that should be an organized separate effort redesigning them in bulk so consistency is maintained. Because trying to do that here would go against current design patterns which in my opinion would be worse than mediocre but consistent design so that should not be a blocker for this PR imo.

[imagico]

Please read carefully what i wrote - i did not present the lack of use of perspective in symbols in this style as an argument against its use, what i wrote is:

And perspective is not typically going to work well at our standard symbol size, we therefore with good reason mostly use profile depictions in our symbol designs.

You further write:

Now the problem with your suggestion and your draft that I have is that it's incompatible with all the other icons.

First of all that is a factually incorrect statement. Second: If that is the only argument against my draft then this is excellent. We should never let bad decisions from the past lead us to perpetuate mediocre design into the future.

If carto icons should be redesigned to be more intuitive to larger variety of people from different cultural background then I believe that should be an organized separate effort redesigning them in bulk so consistency is maintained. Because trying to do that here would go against current design patterns which in my opinion would be worse than mediocre but consistent design so that should not be a blocker for this PR imo.

As i have indicated in #3635 i know this is a belief shared by some here. I however do not share this view and am supported in this more critical thinking by clear evidence in the history of this style that this is not a sustainable development paradigm. As indicated i do not oppose the rendering of parcel lockers/parcel pickup stations in general, i just would like to see them being shown in a way that is compatible with our documented goals.

[syntex1]

What you need to understand when assessing intuitive readability of map design is that it is essential to abstract from your own subjective and culture specific impression. Neither you nor me are representative for target map users of this style. It does not matter much if we find a symbol design intuitive or not. Therefore my key argument is not that the suggested symbol is not intuitively recognizable to me but that i see reasons to think that it is non-recognizable to many potential world wide map users. And i tried to explain a bit how i came to that conclusion by describing how the psychology of recognition of symbols tends to work.

I think it is very good that you try different variations now - but as you probably can imagine none of them so far really seems to work to me.

Your rendering of my symbol draft for some reason is not pixel aligned by the way - to properly assess its suitability you need to change that. Both the box and the wall shape in that symbol are meant to be perfectly pixel aligned - they should be so in the final rendering as well.

I am sorry, but the icon you have provided is even less intuitive than the package/parcel symbol. My first thought of this symbol (seriously, I am not trying to be ironic right now) was baby hatch... Also it resembles more than a parcel locker a luggage storage, laundry or any machine that you can put things into. Possibly also a furnace of some kind. The point is, my first idea of it (and probably of many users) was not a parcel locker. So you criticize a symbol, because it is not unambiguous, yet you propose a symbol that is even more vague. There is a strong community support to render this feature, you've said that you don't oppose the rendering of this feature, yet you made a request of a symbol that is truly unambiguous without proposing a better one that the ones in @ttomasz posts.

[jeisenbe]

Re: the SVG symbol, I am not convinced that the current wire-frame diagram style is the best option. Most of our icons appear to be solid objects.

In this case the use of an isometric view rather than front-on is acceptable since otherwise a cube-shaped parcel is hard to visually identify.

However, we have not seen an example where the sides are solid. I would recommend providing that as an example, since it will address some of the concerns raised by @pnorman and others above.

Also, I would suggest trying the slot at the top of the symbol, as with the other vending services, though perhaps the current configuration with the slot on the left will still be best after all.

[ttomasz]

However, we have not seen an example where the sides are solid. I would recommend providing that as an example

I'll consider testing in the future it but at the moment I don't want to invite further accusations from people like Frederik Ramm who insinuated that trying to raise awareness of issues with governance of carto are somehow vengeance for "my pet feature not getting rendered". I don't want to take away from this discussion which I believe is necessary by giving fuel to people who see this effort in such a cynical way.

That a small group of wealthy, cosmopolitan North Americans and Europeans now gets worked up over their favourite urban amenities not getting rendered in the map based on the tagging they have decided a few months back should replace the pre-existing tagging for those while rural features of truly world wide importance mapped with roughly ten times the volume of mapping and a decade old established tagging scheme (#1224) are of no interest apparently for hardly anyone other than the maintainers of this style (see in particular #1224 (comment), #1224 (comment), #1224 (comment), #1224 (comment)) and of course the mappers who continue using these tags - is telling.

This is like saying that you can't research HIV cure while there are homeless or hungry people. You are presenting a false dichotomy.

What next we won't render volcanoes since they are concentrated in some areas?

Adding just one more symbol will not make a significant difference immediately, but it would imply that similarly popular tags should also be rendered. This is not an extremely common tag - it only has about ~20,000 current uses, mostly in one region, and there are many other tags that could also be rendered at that standard.

First I created an issue #4372 making my case for rendering parcel lockers. Imagico reopened older issue #3558 that already had discussion about it but was closed due to issue #1561 having part of discussion about the subject. #1561 was initially closed but was reopened by a maintainer due to contributor citing increase in tagging usage. It was closed after some things were implemented but for parcel lockers it was said that the tagging was awkward and likely to change due to proposal by SeaHorse so it was put off. Notice that there was no decision from maintainers that this is a feature that shouldn't be displayed because it doesn't fit project goals or requirements.

The time to question whether this should or shouldn't be rendered was when issue asking for it was created. I started working on implementation because maintainers didn't reject it.

Not rejecting a feature and then starting to wonder whether this feature should be rendered or not after six months of effort were put into implementing it is just... well I'll leave it to the reader to pick an adjective but at the very least it is unprofessional.

[jeisenbe]

I'll consider testing in the future

That would be great @ttomasz. There is no rush, since the usage is climbing steadily and the old tagging is declining, we are more likely to accept this in a few months in the future, if not immediately.

there was no decision from maintainers that this is a feature that shouldn't be displayed because it doesn't fit project goals or requirements

That is correct. There has not been a final decision. We usually don’t close an issue or PR unless it is clear that it will not be accepted. In this case there are good arguments on both sides, pro and con.

I understand that many supporters of this tag do not want to wait longer to see it rendered, but the tag is still only a few months old. It is quite normal for us to wait at least a year before rendering a new tagging method, since it can take at least that long for a new tag to become clearly established and replace a previous method.

If in 6 months from now there are 30,000 of these mapped in a number of different countries, and the old tagging is clearly deprecated as shown by most mappers switching to the new tag, it will be clearer.

Changes made

[pnorman]

Have you had a chance to test with solid sides?

[ttomasz]

Here are some examples (disregard artifacts and icon placement, it was easiest to test multiple iterations that way quickly):
currently proposed

solid sides, small gap one side

small gap other side

small upper gap, larger side gap

large gaps

[pnorman]

My preference is for the 2nd or 3rd, the ones with a smaller gap on one side or the other. I can't really see the difference between the two options. The middle gap isn't pixel aligned, and that's quite visible. If you have to pick between having the sides pixel aligned and the middle, go for the middle.

[ttomasz]

I can do some further testing after 17.07

[ttomasz]

version that is better aligned to grid

Changes made

[imagico]

My position on this is essentially unchanged - the tag this is meant to render had no use before 2022 and it is too early in my eyes to assess to what extent there is a genuine grassroots support developing for the tag from the mapper community world wide.

But as also said i will not oppose this if there is otherwise consensus among the maintainers in support of this change. In this case i would however still suggest to remove the rendering of the name tag - see below).

On the more technical level - compared to when i previously looked at this the symbol has changed - from a perspective line drawing of a box with a taping line to a solid color perspective view of a box with inverse highlighting of the edges. This is somewhat simpler in shape but at least equally generic and much heavier in appearance. I consider both well made perspective depictions of a box at this size and i would have a hard time giving one of them a preference.

The labeling logic has not changed, it still shows a feature with amenity=parcel_locker + name=foo with a foo label and it is still difficult for the mapper to understand how the various tags result in the label shown and therefore does decidedly not support mapper in consistent use of tags. See also #4512 (comment)

[dieterdreist]

sent from a phone

On 27 Jul 2022, at 19:22, Christoph Hormann ***@***.***> wrote: My position on this is essentially unchanged - the tag this is meant to render had no use before 2022 and it is too early in my eyes to assess to what extent there is a genuine grassroots support developing for the tag from the mapper community world wide.

I’d rather prefer a system that is open to “new” developments as soon as they are effectively “established” (significant use, undisputed, and if there is an approved proposal even better). This is not a new concept, the former tagging had issues, a proposal was set up to correct it, voted upon, 60 people participated, this new tag has now more than 15000 uses, I would not wait a second longer, for me this is the way the community wants to represent the feature.

[NotSoImportant]

With hopefully not opening a new debate, allow me to ask if it would be more acceptable to render both: the old and new tagging?