Adds mispelled service:bicycle tags

[mueschel]

Since version 2.23 iD adds the tag
service:bicycle:bicycle_sales_and_service
instead of the common spelling
service:bicycle:Bicycle_Sales_and_Service

Might be related to openstreetmap/id-tagging-schema#654

[tyrasd]

As far as I can tell, the service:bicycle:Bicycle_Sales_and_Service tag is not a valid subtag of the service:bicycle:* tag. Yet because it is relatively frequent it is "promoted" by taginfo.

Before iD v2.23, there was a bug which allowed iD to use the upper case letters for the different options of this field. Now, iD converts any upper case letters to lower case spelling, resulting in the addition of the "new" version of this misspelled tag.

I think the best way to approach a fix for this issue is for iD to filter out any taginfo suggestions which don't match a field's spelling requirements.

[tyrasd]

the above mentioned solution is now implemented in dcd7fb4

[mueschel]

As far as I remember, this specific tag was introduced by iD itself in 2017, without discussion (as was common at this time).
I don't think this tag makes much sense and should be replaced by the common, regular tags
service:bicycle:sales
service:bicycle:service
Until then I suggest to keep the uppercase spelling and not introduce a new, lowercase spelling.

[1ec5]

As far as I remember, this specific tag was introduced by iD itself in 2017, without discussion (as was common at this time).

I don’t think iD ever had any code specifically about “bicycle sales and service”, however capitalized. Originally, it only had separate, hardcoded fields for service:bicycle:chain_tool and service:bicycle:pump. When the service field was later implemented in a6cf49d, its definition looked like this:

iD/data/presets/fields/service/bicycle.json

Lines 1 to 5 in 8aca4f8

	{
	"key": "service:bicycle:",
	"type": "multiCombo",
	"label": "Services"
	}

Whatever taginfo reported as common service:bicycle:* values would’ve shown up in the field. The key’s linear growth is probably a result of mappers seeing that value in the taginfo-based suggestions after this field was deployed as part of v2.0.0 sometime in late 2017, well after the key came into use. iD didn’t used to have very stringent filters on these suggestions, after all.