You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
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.
Related to #4078.
We have meanwhile a lot of POI symbols which in
amenity-points.mss
have a rendering logic like:See #4078 for a history of how that came to be.
That means we interpret every access tag that is not
yes
orpermissive
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:
Possible improvements are:
The text was updated successfully, but these errors were encountered: