-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Better rendering for tags with left/right semantics (e.g. coastline, cliff) #1475
Comments
Tag 5: barrier=city_wall if two_sided != yes |
I would think most times someone explicitly reverses one of these would be to fix an incorrect direction. All of these objects should be styled so that the result of a reversal is obvious without a warning. |
waterway=* and oneway=* should be issued, too |
We're not planning to add any warnings for reversing ways. Warnings may be well intentioned, but they run counter to iD's goal of encouraging new users to contribute to the map because they make them feel insecure, even when their edits are perfectly legitimate. "I might break something, I better not touch." Not to mention they are an annoyance for experienced mappers, who think "of course I want to reverse it", and click through without reading. Fortunately, careful design makes users feel MORE secure AND less likely to break something. The best way to do it is show them, in a way they can understand without a deep knowledge of OSM data structures, what's on the map and what changes they are making to it. We're planning to add styles for natural=coastline that indicate the water/land sides (#1465), and we can do the same for cliffs, embankments and barriers. Waterways and oneways already have a clear direction indicator. |
For the warnings I know from JOSM there is a checkbox for users feeling nagged: |
Updated list of problematic tags. |
@bhousel Better rendering is useful, but it is not a full solution. |
Cliffs could be rendered like osm-carto does or with a thick line at top and a glow on the bottom. Would save me having to check the wiki each time! |
Ideas for the rendering in iD: I looked for an easy way to draw a css-border with triangles but apparently there is none. (Except for some (crazy?) svg+border-image workarounds.) However iD has the ability to draw arrows over a line: (Left waterway=stream, Right selected highway=unclassified) So, there might be a way to use this, to draw arrows above (or next to) the line for this usecase? A very (very) rough scribble for natural=cliff and man_made=embankment: The arrows are already direction-aware. With this it should be possible to – more or less – recreate styles like in this OSM-Wiki-Image: Something different: To further point out, that the way is direction aware, we could try to find a place for the "switch direction" button that is used for the "oneway=yes"-preset. However, I don't see a good place for that in tags like natural=cliff and man_made=embankment. |
…ff). This generalizes the oneway arrow logic for adding SVG markers along a line. Using that functionality, certain tags get arrows on their right-hand side, indicating which side is "inside", e.g. the right-side of a cliff is the lower side. The list of tags considered to be sided (unless there's a two_sided=yes tag) is: - natural=cliff - barrier=retaining_wall - barrier=kerb - barrier=guard_rail - barrier=city_wall - man_made=embankment The triangles attempt to be reminiscent of the triangles used for rendering cliffs on OSM (and elsewhere). Fixes openstreetmap#1475.
…ff). This generalizes the oneway arrow logic for adding SVG markers along a line. Using that functionality, certain tags get arrows on their right-hand side, indicating which side is "inside", e.g. the right-side of a cliff is the lower side. The list of tags considered to be sided (unless there's a two_sided=yes tag) is: - natural=cliff - barrier=retaining_wall - barrier=kerb - barrier=guard_rail - barrier=city_wall - man_made=embankment The triangles attempt to be reminiscent of the triangles used for rendering cliffs on OSM (and elsewhere). Fixes openstreetmap#1475.
…ff). This generalizes the oneway arrow logic for adding SVG markers along a line. Using that functionality, certain tags get arrows on their right-hand side, indicating which side is "inside", e.g. the right-side of a cliff is the lower side. The list of tags considered to be sided (unless there's a two_sided=yes tag) is: - natural=cliff - natural=coastline - barrier=retaining_wall - barrier=kerb - barrier=guard_rail - barrier=city_wall - man_made=embankment The triangles attempt to be reminiscent of the triangles used for rendering cliffs on OSM (and elsewhere). The different tags get different renderings (e.g. colors that match the main way, and different spacings). In addition, natural=coastline is special-cased to have blue markers (despite having a green way), to emphasise that the "inside" of a coastline is the water. Fixes openstreetmap#1475.
Thanks a lot for adding this @huonw! Btw, it can be viewed on http://preview.ideditor.com/master/#background=Berlin-2018&disable_features=boundaries&map=19.05/52.47535/13.45292 already. As a follow up: I wonder if the styling and behaviour of barrier=kerb should be tuned down a bit. What I notice:
An example of a not-ideal place (source link above): What do you think, is this worth creating an issue to discuss and improve it further? |
That does look rather overwhelmingly busy! It wouldn't be very hard to give the kerb tag a different style/size of arrows. For instance, |
The following tags make ways "non-reversible":(aka the semantics depend on way direction) natural=cliff, natural=coastline, barrier=retaining_wall and man_made=embankment.
There is no "good" way of handling these outside of showing an "are you sure" alert or similar, this needs to be done for both explicit reversal and implicit (when merging ways).
Updated list of tags:
natural=cliff
natural=coastline
barrier=retaining_wall
barrier=kerb
barrier=guard_rail
man_made=embankment.
barrier=city_wall if two_sided != yes
some people believe that waterway=* belongs in this list too
The text was updated successfully, but these errors were encountered: