Closed hungerburg closed 2 months ago
We've rejected rendering roads their physical width in the past. Changing which service values are thin is an option
The idea of intermixing a physical classification into our functional road classification system has been discussed in #4948. Short: This is not a good idea IMO.
As said there: our current rendering of white roads in different on-screen widths is based on a functional hierarchy:
highway=tertiary
highway=unclassified
/highway=residential
highway=service
highway=service
+ service=driveway
/service=parking_aisle
/service=drive-through
.The last variant - the minor service roads - are characterized not by a smaller physical size (parking aisles are for example frequently wider than residential roads in dense urban centers) but through a narrow and purely local function within a compact and well defined feature (a private estate, a parking lot, a drive through business). service=alley
does not fit into that classification in any way.
The documentation says: An alley or alleyway is a narrow service road usually located between properties to provide access to back gardens, rear entrances, fire exits, and storage areas. The thing I mapped as an alley is connecting a fire brigade access to the public road network. It is 2.5 m wide with curbs.
I retagged as a cycleway because that is the predominant use of the thing. Maybe urban planners did not look farther than the project site when they designed that narrow pass. I now learned that narrowness is not a constituent of alleys and not a way of telling the local emergency centre (they use OSM and look at OSM Carto) about physical infrastructure.
Closing this as the only actionable suggestion made has been to re-frame minor service roads to include service=alley
.
However, no suggestion has been made how this re-framed minor service road class would be delineated. The idea that this is based on physical width clashes with two things:
service=*
classes are not physically defined.width=*
/max_width=*
.Us implying something different to the mappers in rendering would be in conflict of our goal of constructive mapper feedback.
Furthermore: For the idea of transiting from a functional visualization of roads to a physical visualization at high zoom levels we already have #4948.
Expected behavior
I'd have expected service=alley render like service=driveway eg., because it is understood to be slim, as far as I could gather from documentation.
Actual behavior
Service=alley renders like any service=you-make-it-up, i.e. full width of service.
Screenshots with links illustrating the problem
No screenshots, but on the highways where physical width=* has been tagged might be used instead to determine rendering width?