Basically this: The expected values for amenity=parking for separately mapped on-street parking are both lane (which appears to be inofficial but widely in use) and street_side (which is official). However, almost no tool (from carto to Osmose to iD) supports on_kerb nor half_on_kerb and will treat them as parking lots (personal example where I’ve added them).
For example
Both of the former treat them similar to parking lots with a big P for the former and the latter complaining for the lack of connecting way to the parking “lot” while the latter doesn’t allow to set the orientation, though admittingly neither for lane which the former do support
On the large scale, the tags for amenity=parking and parking:<side>=* are basically the same, only that the former use no parking prefix and the latter has the type defined by parking:<side>=* (which is understandable). This is one exception where both are treated differently.
The two solutions are this:
Make these values official and bag the various maintainers that parking=on_kerb/half_on_kerb are as valid for separately mapped street parking.
Tag for the renderer and claim these are street_side under the logic that you can’t convert them into lanes.
Since the street parking scheme fully harmonized tagging on separate mapped parking areas and tagging on the highway centerline, parking=on_kerb and parking=half_on_kerb are valid and meaningful values on amenity=parking features. Anything else would contradict the logic of mapping street parking in OSM. Data users have to deal with this fact for themselves.
After finishing the street parking proposal, the iD maintainers initially refused to treat parking=on_kerb and parking=half_on_kerb similarly to parking=lane or parking=street_side, as these tags were still new and therefore almost not in use at that time. Even currently, the tags are only in use ~500 times, which is in the nature of things, as such areas are more often (but not always) mapped to the street centerline instead of as a separate areas.
I therefore see little need for action here. Data users have to decide for themselves whether the logic is sufficient for them or whether they want to wait a while longer until the usage numbers increase.
=street_side means a parking bay. The importance is they are dedicated space. These aren’t, still shared with the sidewalk. However, I did find =street_side to not be the best term.
My thinking agreed with keeping =on_kerb and =half_on_kerb . For something as =sidewalk ( it’s called “footway parking” in UK), =half_on_kerb is still partially on sidewalk and partially on carriageway. Using =on_kerb and =half_on_kerb directly is more useful.
To reiterate the above, your voting option has a false premise. =on_kerb and =half_on_kerb are already “official”. They are voted through that proposal.
Street-side parking areas are a common feature of the urban cityscape of many countries. In contrast to other types of parking spaces commonly used in OSM, especially parking=surface, they represent a different class of parking spaces, both in terms of their structure and terminology. In some languages there are unique terms for this type of parking, in the German language e.g. it’s called Parkbucht, Parktasche or Parkhafen. In the English language there seems to be no clear unambiguous term for this type of parking, so we decided upon street_side.
It’s a deliberate choice for using street_side instead of, say, layby or parking_bay.