-
Notifications
You must be signed in to change notification settings - Fork 11
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
Tweak rendering style for sidewalks mapped as tags in the roadways #76
Comments
Thanks for your comments, this is interesting! About the shorter dashes, what do you think about this? The shortening of lines as intersections is not possible though (at least now). There would be two approaches to this: intersect the geometry with the other lines and cutting the actual geometries. This is not supported by OpenStreetBrowser, also I worry, this would be really slow. The "usual" approach would be, to use two layers of paint: a wide line for the "casing", a narrower line for the inner way. This is not possible, as the rendering should be transparent. |
Thanks for considering the proposal! The shorter lines in the demo you showed are marginally better than the current situation, but they're still too distracting IMHO. I feel like it's useful to distinguish sidewalks defined as attributes (tags) from those mapped as explicit geometry, so I get why you have different styles for each case, but it seems to me that even small visual differences would be enough to fulfill this goal. In particular, I don't think the lines are needed to make it clear to what road the "virtual" sidewalk belongs to — the fact that they follow the road geometry at a constant distance is already evidence enough of this. I suspect something around the same size as the ticks used for the kerbs would be sufficient. As for the geometry adjustment of the lengths of the sidewalks, I understand the technical limitations and agree that the slight visual benefit (considering that many edge cases would likely not be covered by a simple approach) is not worth the cost. |
I thought about this. I want to keep the hatching, because it visualizes "sidewalk=yes/separate/no" which you don't see in other maps. My new solution is, to split it into two separate categories:
You can test this on a development branch:
|
Just to be clear, I didn't mean to suggest omitting the explicit indication of which sidewalks are mapped directly vs. marked as tags I roadways. I was only suggesting something subtler, like e.g. what's used for the (linear) kerbs: However, I realize that anything that doesn't extend all the way into the midline of the corresponding roadway would make it very hard to depict
It looks great! My only suggestion would be to consider tweaking the label of the "Footways" category, to make it clearer that it includes sidewalks — maybe something like "All footways", or "Footways (incl. sidewalks)"?
I'm not sure. Depending on the colors, I worry that it may become a bit too noisy and make the overall picture harder to grasp. Do you think something like having the same colors but with a bit muted (less saturation, lighter/darker, or slightly transparent) for the |
The current Footways layer is very good at rendering sidewalks, both separately-mapped ones and those tagged in the streets themselves. I'd argue that the visualization manages to surpass even platforms that aim to cater specifically to pedestrian navigation. For example, see this region in Seattle, WA:
AccessMap:
OpenSidewalkMap:
OpenStreetBrowser:
However, the thin perpendicular lines are very distracting, especially when the streets curve or don't meet at 90º angles.
I would suggest a different style to be considered, e.g. using shorter lines from the sidewalk pointing towards the center of the street (similar to how linear kerbs are currently drawn). Something like this, for example:
In addition, it would also be nice if the length of such "virtual sidewalks" was cut short by the same amount that they are offset from the center of the street, so that when they meet in intersections, they don't cross over each other. I suppose the end result might end up something like this:
WDYT?
The text was updated successfully, but these errors were encountered: