Is there any reason why we still allow such keys?
https://taginfo.openstreetmap.org/reports/key_lengths#keys
p.s. moreover, the API allows you to load empty keys, which is definitely useless.
6 Likes
And empty values!
3 Likes
Presumably, single character keys could carry enough meaning when using Chinese characters.
If we want that is of course a different question…
if we would want to do this - code to implement blocking this at API level would need to be properly designed, coded, reviewed and merged
and this has not yet happened
The API is, by design, agnostic to any meaning of tags.
5 Likes
But there’s no reason why that shouldn’t change.
1 Like
Well, for start it would require changing design - and designing something new. Including question how to handle existing tags.
Then writing code and maintaining this new rules.
We already have a limit on the tag length at the top (255 characters). Therefore, arguments about design are not accepted 
Carefully check them and comment on the edits of those who created them.
I will note that I do not force anyone to solve this problem urgently, write code, etc. For now, I just collect opinions and correct problematic tags.
1 Like
I am doing it already though it requires no API changes at all.
Upper limit introduced for technical reasons differs from adding QA checks.
… and after fixing these problematic tags, you can end this problem forever by prohibiting the creation of such tags.
But it will be possible to implement it in the same place in the code.
But there is no reason why single character keys couldn’t be meaningful.
I am pretty sure that maintainers prefer to not start accumulating bunch of QA checks there.
In theory? Yes. In practice? Seems extremely dubious.
1 Like
It seems that for the same reason, empty relations and ways from one point are allowed in the API 
Actually the reasons are different (and certain constraints do apply to geometries).
Yes, if you were to introduce this sort of constraint on osm.org, it would typically be done by setting a config option per deployment, as visible at https://www.openstreetmap.org/api/capabilities.
But I don’t really see the point. Single-character keys are invariably a goof just as hihgway= is a goof or Name= is a goof or whatever. We generally fix them by fixing the data. OSM’s “any tags you like” approach makes it pretty meaningless to start enforcing some arbitrary rules and not others.
1 Like
Well, I started messaging people who used this single letter keys - typical response is thanking and that they were not aware that this happened.
It is likely that they could fix it months/years before at time of edit if they would get message that upload is blocked due to suspicious tags.
On the other hand it can be also added straight to editors anyway.
1 Like
I think we should enforce the maximum length first. Officially, the length of a key or value must not exceed 255 bytes (not characters, which can be more than 1 byte each). However, there are several value strings in the database that exceed this limit (e.g. extremely complex opening_hours, or verbose inscription of a memorial).
Wrong, see below
Can you link these? I know about cases where users wanted to add long value not fitting into limits but I am not aware of any in database
That is not correct see API v0.6 - OpenStreetMap Wiki (I would note that I’m quoting myself).
PS: as this limit AFAIK goes back to the original mysql based version of the API, it is “kind of unlikely” that there are any longer strings in the data.
PPS: see also Add tag key and value max length to capabilities API call · Issue #1593 · openstreetmap/openstreetmap-website · GitHub
3 Likes