Labeling of amenity=parcel_locker incompatible with the goal of constructive mapper feedback

[imagico]

As a result of #4512 we now have a labeling logic for amenity=parcel_locker of the form:

openstreetmap-carto/project.mml

Line 1462 in 9bda286

THEN CONCAT_WS(E'\n', COALESCE(tags->'brand', tags->'operator', name), ref)

Technically this renders as a label the brand (see #4575 (comment) for some comments on the specific semantic issues of that tag), the operator or the name - whichever is tagged, in that order of preference, plus the ref tag, separated by a newline if there is a (brand or operator or name).

As already explained in the PR (#4512 (comment)) this renders features tagged amenity=parcel_locker + name=foo with a foo label while the name tag of those features practically never contains an actual name and almost always contains a compound labeling string subjectively designed to the individual mappers liking. But it is even worse than just plainly rendering the name tag, it essentially communicates to the mapper: You can tag your subjectively desired labeling string in either name, brand or operator - it does not matter where, it is all the same. So it essentially actively sabotages attempts at supporting consistent use of tags.

I was not sure if i should open this issue considering i already brought this matter up in #4512 and this was merged without addressing my concern (which is fine). But it is likely that with the lot of noise on that PR other maintainers were not consciously aware of this problem. So what i essentially want to find out with this issue is if we still have consensus on what for the whole history of this style has been a core guiding principle - to provide constructive mapper feedback, to support mappers in consistent use of tags and to be intuitively understandable for mappers in how a certain tagging results in the rendering we produce. If we still have consensus about this goal this labeling logic can't be acceptable and if we accept this labeling logic we clearly abandon this goal.

[pnorman]

I don't agree that there is a problem with using multiple tags to derive the label, but would consider a PR changing it to just render the name.

Would you only render brand, plus maybe ref?

[imagico]

I am not sure what you are saying:

• do you disagree that coalescing brand, operator and name communicates to the mapper: You can tag your subjectively desired labeling string in either name, brand or operator - it does not matter where, it is all the same?
• do you disagree with the assessment that the labeling logic used here is not intuitively understandable for the mapper, especially since practically the tags brand, operator, name and ref will often have overlapping content?
• do you disagree with the assessment that the name tag is almost never used on amenity=parcel_locker to tag an actual name?

Would you only render brand, plus maybe ref?

See #4512 (comment) (and #4575 (comment) regarding the principal issues of the brand concept and the lack of a clear 1:1 relationship between real world features and brands).

Independent of what is the most meaningful information to display and what is the most consistently tagged one i would avoid a COALESCE() of different tags, especially if this is embedded within additional complexity. I would also prefer if concatenations of different tags would be clearly visually distinguished (though i understand the options to do so are fairly restricted with the limitations of carto - mapbox/carto#347). Note the latter is of course not a problem unique to amenity=parcel_locker, we also have this for addresses:

openstreetmap-carto/style/addressing.mss

Lines 33 to 50 in a2077c0

	["addr_unit" != null]["addr_housenumber" = null] {
	text-name: [addr_unit];
	}
	["addr_flats" != null]["addr_housenumber" = null] {
	text-name: [addr_flats];
	}
	["addr_unit" != null] {
	text-name: [addr_housenumber] + " " + [addr_unit];
	["addr_housename" != null] {
	text-name: [addr_housenumber] + " " + [addr_unit] + "\n" + [addr_housename];
	}
	}
	["addr_flats" != null] {
	text-name: [addr_housenumber] + " " + [addr_flats];
	["addr_housename" != null] {
	text-name: [addr_housenumber] + " " + [addr_flats] + "\n" + [addr_housename];
	}
	}

[pnorman]

• do you disagree that coalescing brand, operator and name communicates to the mapper: You can tag your subjectively desired labeling string in either name, brand or operator - it does not matter where, it is all the same?
• do you disagree with the assessment that the labeling logic used here is not intuitively understandable for the mapper, especially since practically the tags brand, operator, name and ref will often have overlapping content?

I do not find anything with coalescing that conflicts with general purpose of the style. In particular, I find it neutral on "it's an important feedback mechanism for mappers to validate their edits and helps to prevent unfavorable fragmentation of tag use" and positive on the other three purposes.

• do you disagree with the assessment that the name tag is almost never used on amenity=parcel_locker to tag an actual name?

I'm not sure what you mean by an actual name.

Note the latter is of course not a problem unique to amenity=parcel_locker, we also have this for addresses:

I don't consider it a problem for addresses either.

I'm not a huge fan of the technical complexity in using labels that aren't a single database column, but that's a technical objection based around adding complexity to SQL, MSS, and reworking indexes.

[imagico]

I do not find anything with coalescing that conflicts with general purpose of the style. In particular, I find it neutral on "it's an important feedback mechanism for mappers to validate their edits and helps to prevent unfavorable fragmentation of tag use" and positive on the other three purposes.

That is not what i asked.

I find it pretty obvious that the labeling logic used here is non-intuitive for the mapper (meaning the vast majority of mappers will not develop a correct understanding of how the label derives from the tagging merely by studying the map) and can lead to various irritating and misleading effects when a mapper changes tagging and is therefore counterproductive in terms of mapper feedback.

To give an example:

You have a node with amenity=parcel_locker and name=DHL Packstation 120 and a mapper adds brand=DHL Packstation and ref=120. The label does not change:

but the label is sourced from different tags in both cases.

I'm not sure what you mean by an actual name.

I believe the technical term here in English is proper name, as in

https://en.wikipedia.org/wiki/Proper_name_(philosophy)

The name tag by broad consensus and in practical use in general is predominantly used to record proper names. However on amenity=parcel_locker it almost never is. If you disagree i would ask you to point to examples where the name tag of an amenity=parcel_locker contains a proper name.

I'm not a huge fan of the technical complexity in using labels that aren't a single database column, but that's a technical objection based around adding complexity to SQL, MSS, and reworking indexes.

My concern has nothing to do with technical complexity, it is about the social function the style has in the OSM community.

[Elefant-aus-Wuppertal]

The name tag by broad consensus and in practical use in general is predominantly used to record proper names. However on amenity=parcel_locker it almost never is.

+1

[Elefant-aus-Wuppertal]

I find it pretty obvious that the labeling logic used here is non-intuitive for the mapper

This is true. But maybe, just concentrating on both the Tags brand and ref to render could make more sense here than concentrating on putting out the parcel locker's text out of one single key-value-pair so that this could be (intuitively) then the name only.

So as you said, dropping the rendering of name=* at parcel lockers completely could give mappers the feedback to user other tags, brand and ref. Of course these are two tags here and not just one like for ameniy=atm with its operator.

In my eyes, it's the same at mountain peaks for example. For having the height rendered, there's the tag ele=* which is used together with name.

The only special thing is in this case, that the "name rendered" is constructed out of a combination of two values which come both not from the name-tag, but come from other tags.

Rendering brand+ref and not name prevents misusing the name tag. For amenity=atm and amenity=vending_machine operators for example we did similar things for it.

[imagico]

In my eyes, it's the same at mountain peaks for example. For having the height rendered, there's the tag ele=* which is used together with name.

Note for mountain peaks we match the ele tag against a regular expression:

openstreetmap-carto/project.mml

Line 1468 in 4b58c59

WHEN (tags ? 'ele') AND tags->'ele' ~ '^-?\d{1,4}(\.\d+)?$'

to make sure we only render ele values which are numbers (and we round them to integer meters).

Rendering brand + ref or operator + ref would quite definitely be an improvement over the status quo. I don't think either of these is ideal though without a differentiation in styling that shows which part of the label is which tag.

We have one other case (in addition to elevations, addresses and amenity=parcel_locker) where we compose a label from multiple tags - that is motorway junctions:

openstreetmap-carto/style/roads.mss

Lines 2757 to 2764 in 4b58c59

	[zoom >= 13] {
	["name" != null]["ref" = null] {
	text-name: "[name]";
	}
	["name" != null]["ref" != null] {
	text-name: [name] + "\n" + [ref];
	}
	}

There are two important things that makes this much less prone to confusion:

• at z<13 only ref is rendered thereby giving visual feedback on that tag in isolation
• it uses text-wrap-character: ";" - so there are usually no line breaks in the label apart from the one separating name and ref thereby making the labeling logic much more intuitive

[RicoElectrico]

My arguments for leaving as-is:

• I think you overstate mapper feedback in this particular case. What drives tagging is iD presets. Which, incidentally, does have separate fields for brand and ref (and also uses brand suggestion index!). Only when something is not displayed or properly differentiated when necessary (like unpaved roads), then some mappers start fiddling with it.
• If you drop rendering ref=* altogether it'll cause people to tag for the renderer anyway.
• Each major parcel locker network shares their locations, and with that I expect that some bored mappers will emerge to maintain networks in their country by the means of overpass queries and cross-checks with said external datasets.

[Elefant-aus-Wuppertal]

An option to remove/drop the rendering of a name=* (if tagged) on parcel_lockers would it maybe be, when the name suggestion index (whose presets are used for parcel lockers in most cases) would have removed all "name" tags in its parcel locker presets , but unfortunately, this isn't the case at the moment, even though the "names" there aren't those and in all cases it is either completely the same as the value for "brand" or its a combination of "brand" + the word "parcel locker" and/or sometimes people put additionally "ref" in it (here, however, there is also far from agreement, with one NSI writing that one in the name, with the other that...)

[Elefant-aus-Wuppertal]

The problem is also, that if the NSI has a "name" in a parcel_loker preset and the preset for this parcel locker is in use, but then comes a fitting parcel locker where the name isn't tagged, the NSI shows this parcel locker als tagged imcompletely.

I have seen so many changesets where just the suggestions of NSI were implemented on those amenities without any other changes or something, just to satisfy NSI. So in bottom line, this will lead to that the parcel lockers of specific brands will all get tagged with a name.

But that is not so much a concrete decision in individual cases or a decision made by the local community, where a name is being considered, but the NSI simply leads to it.

I know, it seems I should rather open an issue at the NSI for this than discussing this here, but just for showing how specific tagging methods get in use on OSM today. The NSI has much impact, and about what has been decided to implement in the presets there, many "small" (sorry for that word) local mappers do not know, but just using the preset when people see there is one which fits to the parcel locker's brand.

[Elefant-aus-Wuppertal]

a differentiation in styling that shows which part of the label is which tag

interesting thought!