iD silently changes the relation type associatedStreet->associatedstreet

[serhii-muchychka]

URL

No response

How to reproduce the issue?

At the moment I have no clear reproduction steps. Maybe someone else can describe theirs

Screenshot(s) or anything else?

For example, in these relations, iD changed the type:
https://www.openstreetmap.org/relation/1825372/history
https://www.openstreetmap.org/relation/10409703/history
This happens to experienced users as well

Which deployed environments do you see the issue in?

Released version at openstreetmap.org/edit

What version numbers does this issue effect?

2.25.2

Which browsers are you seeing this problem on?

No response

[1ec5]

This happens when selecting an existing associatedStreet relation and editing the Type field of the generic Relation preset (since there isn’t a dedicated preset for associatedStreet). Only the Type field is affected; the raw tag editor is unaffected.

The type field needs caseSensitive to be set to true. It might also be necessary to add type to the keys in this regular expression:

iD/modules/osm/tags.js

Lines 246 to 247 in 43784e2

	// Tags which values should be considered case sensitive when offering tag suggestions
	export const allowUpperCaseTagValues = /network|taxon|genus|species|brand|grape_variety|royal_cypher|listed_status|booth|rating|stars|:output|_hours|_times|_ref|manufacturer|country|target|brewery|cai_scale|traffic_sign/;

But the only documented relation types that contain a capital letter are associatedStreet, TMC, LEZ (sort of), and preferredEntry. Making the field case-sensitive would allow users to introduce capitalizations by mistake. So a more targeted alternative would be to add a special case here:

iD/modules/ui/fields/combo.js

Lines 93 to 95 in 43784e2

	if (!field.caseSensitive) {
	dval = dval.toLowerCase();
	}

[1ec5]

Or we could add presets to id-tagging-schema for each of these unusual type values. The presets should probably be made unsearchable, because associatedStreet is controversial and losing popularity, while the others are very rare.

[Marc-marc-marc]

associatedStreet` is controversial
it's only one "local"(your) optinion

in France, it is accepted as an appropriate object for storing information about all the tags relating to all the highways (e.g. 236,111 occurrences of ref:FR:FANTOIR)

in bilingual areas (for ex Bruxelles Belgium https://www.openstreetmap.org/relation/14571465 or Fribourg Switzerland https://www.openstreetmap.org/relation/11883495), it is also the cleanest way of saying that addr:housenumber=1 refers to a street name with several equilateral names (there is no one name:xx superior to the others in these places)

it is also used for cases where the name of the ground is different from the official name, with the 2 street names used in everyday life https://www.openstreetmap.org/relation/10631315

[1ec5]

For sure, associatedStreet relations are still common enough that there should be a preset for them, in case someone stumbles upon one and doesn’t know about them already. As this documentation points out, this relation type has been banished from some countries, even as others welcome it. That’s all I meant about it being controversial.

There could be two versions of a Street With Associated Features preset: one that’s searchable, limited to the countries that welcome it, and another that’s unsearchable, limited to the countries that don’t welcome it. Normally, it isn’t a great idea for id-tagging-schema to promote fragmentation along national lines, but addressing inherently differs from one country to the next.

(FYI, in countries where associatedStreet relations aren’t in common use, the assumption is that geocoders and validators know to look at every name:* or *_name, so that there isn’t a need for addr:street and name to match.)

[tyrasd]

fixed in 18a7663