-
Notifications
You must be signed in to change notification settings - Fork 829
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rendering of service=alley #4994
Comments
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:
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). |
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 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:
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?
The text was updated successfully, but these errors were encountered: