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

Stop catch-all interpretation of access tags for POI symbols #4568

Closed
imagico opened this issue Jun 6, 2022 · 2 comments · Fixed by #4717
Closed

Stop catch-all interpretation of access tags for POI symbols #4568

imagico opened this issue Jun 6, 2022 · 2 comments · Fixed by #4717

Comments

@imagico
Copy link
Collaborator

imagico commented Jun 6, 2022

Related to #4078.

We have meanwhile a lot of POI symbols which in amenity-points.mss have a rendering logic like:

    [access != ''][access != 'permissive'][access != 'yes'] {
      marker-opacity: 0.33;
    }

See #4078 for a history of how that came to be.

That means we interpret every access tag that is not yes or permissive as restricted.

I don't think that is a good idea or is compatible to our goal to give mappers constructive feedback. It includes on many POI types values like:

  • access=FIXME
  • access=unknown
  • access=official
  • access=customers (for things like amenity=charging_station or amenity=shelter + shelter_type=public_transport)

Possible improvements are:

  • extend the list of access tags indicating the feature to be open.
  • interpret unclear access values the same way as the lack of an access tag (which currently always is open - so this would mean moving to a list of restricted values - like we do for roads).
  • move towards three rendering variants in some form with open, restricted and unknown as third class.
  • more restrictively choose which POI types are rendered with a separate access restricted symbolization
@jeisenbe
Copy link
Collaborator

jeisenbe commented Jun 7, 2022

Re: "move towards three rendering variants in some form with open, restricted and unknown as third class.”

The current rendering of private POIs already has problems. I doubt we could create 3 classes which are clearly visible on different backgrounds and clearly distinct from one another.

We might want to re-consider how many features have this unique private rendering.

@imagico
Copy link
Collaborator Author

imagico commented Jun 8, 2022

I doubt we could create 3 classes which are clearly visible on different backgrounds and clearly distinct from one another.

Yes, most certainly not in the form of color variations. But it could be considered to have symbol variations as well - the parking symbol is in principle a good candidate for that.

We might want to re-consider how many features have this unique private rendering.

I added that to the list of possible improvements.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants