Skip to content
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

Closed
hungerburg opened this issue Jul 16, 2024 · 4 comments
Closed

Rendering of service=alley #4994

hungerburg opened this issue Jul 16, 2024 · 4 comments
Labels

Comments

@hungerburg
Copy link

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?

@pnorman
Copy link
Collaborator

pnorman commented Jul 18, 2024

We've rejected rendering roads their physical width in the past. Changing which service values are thin is an option

@imagico
Copy link
Collaborator

imagico commented Jul 18, 2024

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.

@imagico imagico added the roads label Jul 18, 2024
@hungerburg
Copy link
Author

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.

@imagico
Copy link
Collaborator

imagico commented Jul 21, 2024

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:

  • The service=* classes are not physically defined.
  • The primary method of indicating the physical/usable width of a road is through 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.

@imagico imagico closed this as not planned Won't fix, can't repro, duplicate, stale Jul 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants