Add rendering for mountain_pass

[hiddewie]

Fixes #244

Changes proposed in this pull request:

• Add rendering for nodes annotated with mountain_pass=yes (taginfo https://taginfo.openstreetmap.org/keys/mountain_pass)
• Added symbol for mountain passes, using grey color #333 (text same color)
• Name is shown if available (just like saddle)
• Elevation is shown if available (just like saddle)
• If a node is both a saddle and a mountain pass, a saddle is shown
• If a node is both a saddle and a mountain pass, it is shown from zoom 14 onwards, instead of zoom 15 onwards.
• No fancy visualization concerning the direction of the pass (direction tag or in line with the corresponding way).

Icon:

Test rendering with links to the example places

After

Mountain pass z15 (no saddle) (http://localhost:6789/openstreetmap-carto/#15/47.4588/7.5113)

Mountain pass z16 (no saddle) (http://localhost:6789/openstreetmap-carto/#16/47.4588/7.5113)

Mountain pass z17 (no saddle) (http://localhost:6789/openstreetmap-carto/#17/47.4588/7.5113)

Three mountain_passes that are also saddles (http://localhost:6789/openstreetmap-carto/#14/47.2314/7.1906)

Nothing changed for existing saddles (also being a mountain_pass) (http://localhost:6789/openstreetmap-carto/#17/47.24972/7.18446)

Some other mountain passes (makes me wonder if all mountain passes should be visualized for zoom >= 14)

http://localhost:6789/openstreetmap-carto/#15/46.1789/8.6183

http://localhost:6789/openstreetmap-carto/#15/46.6085/8.9415

http://localhost:6789/openstreetmap-carto/#15/42.8415/-0.2871

[jeisenbe]

Thank you for working on this, @hiddewie.

The CI syntax check has failed for the latest commit. It looks like there is a problem with the SVG file.

Try opening it in Inkscape again, use "Save As..." and choose the format Optimized SVG (preferable) or Plain SVG.

We had previously discussed orienting the icon to match the local direction of the road at the mountain_pass node: so if the road is traveling east-west the symbol would be rotated horizontally. This is not required, but might look better. You could give it a try if the SQL query is not too difficult.

[hiddewie]

@jeisenbe Thanks, I will definitely improve the PR in response to your comment.

A question about the rotation. In comment #244 (comment) it was mentioned that there is some previous work we can build upon, but could not find it in the source code. I also searched in https://github.com/imagico/osm-carto-alternative-colors. Could you give a pointer where to find that existing work?

[hiddewie]

Updated the color to something dark. Looks better. Screenshots are updated

[imagico]

The ac-style uses the same technique for mountain_pass as for fords:

https://github.com/imagico/osm-carto-alternative-colors/blob/56a74359fbd70cde5603627e4e76ed07333b2e60/project.mml#L1773-L1833

This is technically rather complex.

I would be against rendering mountain passes with a static symbol that would cover an area most important for reading the map. We have this problem already with fords. I would also be against using a symbol indicating a specific direction without that direction matching that of the road. A rotated symbol could work but would also lead to problems with curved roads.

[jeisenbe]

A rotated symbol could work

@hiddewie are you able to try this?

[jeisenbe]

Re: problems with curved roads. It might help to use a symbol which has more space in the middle, between the two curves. This will make it less likely to overlap with a curved road or path, at most zoom levels

[hiddewie]

I will definitely try adding rotation to the rendered mountain pass!

The most interesting problem will probably occur when two or more roads intersect at the mountain pass. For example a road crossing the pass, and a walking trail crossing the road exactly at the pass. In that case the direction is not clearly defined (we can take the first way, or fall back to a direction tag).

[hiddewie]

I actually meant the previous comment as a theoretical problem, but the first rendering I see has exactly that problem (47.45925/7.51031)

I am pretty sure that the pass is actually north-south here (notice the two mountains on the east and west of the pass). There is no tagging data to back that up. Rotating the rendered icon in this way is wrong, just as not rotating it might be wrong.

---

              CASE 
                WHEN tags->'mountain_pass' IN ('yes') THEN
                  COALESCE(
                    (SELECT
                      degrees(ST_Azimuth(
                        ST_LineInterpolatePoint(lines.line, GREATEST(0, position - 0.01)), 
                        ST_LineInterpolatePoint(lines.line, LEAST(1, position + 0.01))
                      ))
                    FROM
                      (SELECT
                          l.way as line,
                          ST_LineLocatePoint(l.way, points.way) as position
                        FROM planet_osm_line l 
                        WHERE ST_DWithin(points.way, l.way, 1) -- Assumes Mercator
                        LIMIT 1 -- take the first if there are more than one way close to the way
                      ) as lines
                    ),
                  0)
                ELSE 0
              END AS rotation,

this is the (sub) query which generates those results.

[imagico]

Yes, mountain_pass=yes on nodes where more than one path goes through or more than two start/end are inherently ambiguous. You could try to address this partially by adding an ORDER BY to the subquery prioritizing paths based on their class. But that will fail if the crest route for example is a highway=track but what goes over the pass is just a highway=path (like https://www.openstreetmap.org/node/269964518). The only reliable option you would have when using a rotated symbol would be to not rendering in such a case - which however is not necessarily intuitive for the mapper (adding a path would result in the rendering vanishing).

[hiddewie]

I would actually propose to render the mountain pass icon

• with a certain direction if the direction tag is set (either a number or a bearing in degrees)
• with the direction of the road crossing the node at the path if there is exactly one way
• otherwise vertical, 0 rotation.

I think there will be few cases which would render no rotation, and having an icon is in my opinion more important than the correct direction. (I have to check the numbers on that)

[mboeringa]

* with a certain direction if the direction tag is set (either a number or a bearing in degrees)

I would actually stick with this option, instead of fancy rotation based on path direction. Using the direction tags puts a nice positive incentive to actually add this information to the database, based on actual surveying or close inspection of aerial imagery (although the last can be a bit tricky at times).

If the majority of the rotated mountain passes visible in the map is automatically rotated instead of based on actual data, no one will ever add it this cartographically important information to the mountain pass nodes.

And it is not that we need to adjust this continuously, once added, the direction tag stays valid essentially indefinitely (unless a catastrophic natural event).

* either a number or a bearing in degrees

The direction key is defined as either a number representing 0-359 degrees, or cardinal directions, see:

https://wiki.openstreetmap.org/wiki/Key:direction

[jeisenbe]

The key direction= is rarely used with mountain_pass=yes: less than 1% of passes (133 total) have this tag, and it isn't mentioned on the wiki page, so it will not help us with rendering most passes.

[hiddewie]

The direction tag is mentioned in the wiki for saddle points. Maybe it could be added for mountain passes as well, as the two are geometrically closely related. But adding it in the wiki is a future solution and not a present solution.

But the question remains, is 1% of mountain passes with rotated icons considered an incentive for mapping, or is it considered a rendering problem?

[mboeringa]

But the question remains, is 1% of mountain passes with rotated icons considered an incentive for mapping, or is it considered a rendering problem?

If there is anywhere a dedicated community willing to add such data, it is hikers in the mountain regions. I do not consider 1% a rendering problem. If users become aware that their added tagging of direction leads to visually superior cartography, they will add it.

If automated routines, that are not guaranteed to get it right, try to simulate it, no incentive is left to add such useful information.

Besides, I have seen many arguing here that openstreetmap-carto was about "mappers feedback". Automating rotation is not mapper feedback, rendering based on direction only is.

[jeisenbe]

If automated routines, that are not guaranteed to get it right, try to simulate it, no incentive is left to add such useful information.

There is actually a better way to do this automatically, demonstrated by opentopomap: use a DEM to determine the topography. Compare https://www.openstreetmap.org/#map=16/47.2501/7.1836 and https://www.opentopomap.org/#map=17/47.25011/7.18359, or https://www.opentopomap.org/#map=16/47.43778/7.40220https://www.openstreetmap.org/#map=16/47.43778/7.40220 - in these examples, the natural=saddle icon is oriented to match the contours of the topography.

While we would not want to add a whole DEM file to this style to improve the rendering of one feature, it is quite feasible for any style which is already showing contour lines or hillshading based on a DEM. See open source code to do this at https://github.com/der-stefan/OpenTopoMap/blob/master/mapnik/tools/saddledirection.c

So there isn't a need to make mappers add a direction= tag, in most cases.

[mboeringa]

So there isn't a need to make mappers add a direction= tag, in most cases.

I understand, but it still isn't "mapper feedback". In fact, it is deceptive, because it suggests there is something that isn't there.

Actually, adding "direction" to mountain passes would be a really nice "MapRoulette" task... I have never created one, maybe I should now! ;-)

[jeisenbe]

it suggests there is something that isn't there.

Using the DEM might be misleading (I do not think it would be a good idea for this style), but using the direction of the highway= way is appropriate: that is information in the OSM database.

[mboeringa]

is appropriate: that is information in the OSM database.

I am not challenging that it is appropriate or feasible, both potentially are, as you justly indicate.

But it still isn't mapper feedback about the status of having a direction key on the mountain pass node or not.

[jeisenbe]

I would actually propose to render the mountain pass icon
1 with a certain direction if the direction tag is set (either a number or a bearing in degrees)
2 with the direction of the road crossing the node at the path if there is exactly one way
3 otherwise vertical, 0 rotation.

Since only 0.5% of these nodes have a direction tag and it is not documented, I don't think that step 1 is necessary.

Number 2 is good, if possible.

Number 3 might work, but we will need to test how it looks. It might be better to orient the pass to the higher class of highway, when relevant, as mentioned in #4121 (comment)

[imagico]

It would be good to cut the tagging discussion here because as @jeisenbe said current use of that combination is negligible and undocumented. Also semantics are not at all trivial and in case of the popular combination of mountain_pass=yes + natural=saddle ambiguous. We are not going to try steering mappers to add certain data because it seems to simplify things for us - especially if the solution this promises would ultimately be quite mediocre.

Regarding the rendering of mountain passes - i see mainly the following options:

• using a very compact abstract and non-oriented symbol to indicate a mountain pass without obscuring a lot of the map in the area and without potentially blocking a lot of other symbols. Because of the widespread use of the combination of mountain_pass=yes + natural=saddle this would also call for handling the double tagging in an intuitive way.
• finding consensus on using a bridge like rendering. This isn't rocket science - though as said not trivial. It would have the advantage of being equally usable for fords - which are a long standing problem in this style. And it would have tons of advantages otherwise - like the option to intuitively handle the complex cases of junctions on the pass and that it would not need to block other symbols or labels around.

I don't see that the idea of a rotated static symbol is ultimately going to work well - no matter how you source the rotation. Surely you would for any variant of it find cases where it looks good but at the same time you will also find tons of cases where it does not. Taking care of that would quickly result in a lot of special casing and different symbols for different road types and zoom levels and ultimately probably a higher complexity in code than the bridge like solution.

[mboeringa]

Well, for anyone who would like to join me, here is now a MapRoulette task to add the direction tag to mountain passes. iD's option to show a direction on nodes, is really helpful as well:

https://maproulette.org/admin/project/40318/challenge/13209

Just rebuild the task, as my Overpass query didn't check for the missing direction key, it selected all mountain passes. Updated URL for the new task.

[mboeringa]

By the way, this is why you need to be careful making assumptions based on path direction. Notice how the path follows a ridge, and the actually tagged mountain pass is almost perpendicular to it as a consequence.

Actually, thinking about it, it is likely better to re-tag such "passes" to natural=saddle.

[jeisenbe]

Then that’s a natural=saddle, not a mountain_pass=yes

…

[image: afbeelding] <https://user-images.githubusercontent.com/7635726/80222594-6267ef00-8647-11ea-89e6-698d84e0c5c7.png>

[hiddewie]

@jeisenbe No problem. The PR is still open, and I am willing to update it to any wishes :)

I think that rotating the icon conditionally would be possible, but would give a bad result because many passes contain more than one road passing through. Defaulting to an 'upright' position would give a false impression that the pass is in the north-south direction because other mountain pass icons are be rotated. Furthermore, as mentioned in #4121 (comment), there are examples that only contain one highway passing through the pass, but the direction is different from the highway direction. The only reason I would show a rotated icon is combined with a direction tag, but this is not a solution as commented in #4121 (comment).

As for the icon, I will try to make a proposal with a small abstract icon that does not suggest a direction. I just have to come up with a suitable image (suggestions are welcome).

I will experiment with the existing colors you mentioned. 👍

[hiddewie]

Some examples with landform color and new icon

Icon (abstract enough?)

Old screenshot

See the test renderings below. The brown color makes it hard to distinguish from the peaks.

[hiddewie]

transportation-icon color (better in my opinion):

Old screenshot

[hiddewie]

In cyclosm/cyclosm-cartocss-style#462 (comment) it was suggested that the mountain pass could also be rendered with the saddle icon with a transport or dark color. The CyclOSM style currently uses that solution.

They use no rotation of the mountain pass icon, which I agree with.

[imagico]

I would definitely think reusing the same symbol as used for saddles in transportation color is a better option than what has been suggested otherwise so far. I still think an integrated bridge-like rendering would offer better readability and be more intuitive but as already said i am not tied to this - if others think a technically simple and non-contextualized static point symbol is the way to go i am not opposed to that.

[hiddewie]

👍 I will update the PR to use the saddle icon in a suitable color.

(I will also try to clean up some outdated screenshots in the list of comments on this PR, it is a huge thing to scroll though.)

[hiddewie]

The screenshots in the PR description have been updated, and old comments have been collapsed with a <details> block.

[jeisenbe]

I’ve checked the rendering. The text color needs to be changed to match other transportation-icon features, but otherwise it is ok.

(This change reminds me that it would be better to change our transportation-icon and transportation-text colors to be something different than this shade of blue, since they are rather close to water features, but that should not need to be addressed in this PR)

Examples:

Note that nodes with natural=saddle + mountain_pass=yes are not changed by this PR, but are still rendered in the landform color like mountain peaks.

[hiddewie]

@jeisenbe Thanks. I updated the code as per your comments.

The saddles are not modified to let the existing rendered features on the map remain the same. Also ref #244 (comment) that saddle is more 'important' to render than a moutain pass.

[hiddewie]

Yes ofcourse, I missed the correct name.

[jeisenbe]

@imagico does this work for you cartographically?

It would be better if @transportation-icon were not blue, though at least passes are always at ridgelines and therefore are less likely to be confused with water features such as fords or springs, when the context is clear.

[imagico]

@imagico does this work for you cartographically?

As said i would prefer a contextualized, bridge-like rendering and i also think we need to move towards such methods to maintain a rich style in the future without cluttering the map - see #3635.

But as i also said within the spectrum of static point symbols this is the best solution IMO. So if it otherwise finds support i will not oppose it. But it should be clear that it would further add to #3635 and not be a step towards solving it.

[ppete2]

I really like the result how this PR has been developed. It's nice to stick to the saddle-like icon with the blue transport color. It's also good, not to keep with the idea to use a rotated, bridge-like icon. I think it would have been to confusing for non-map experts reading the map - especally on passes where multiple ways are crossing.

I've though about the situation if a node shares both natural=saddle + mountain_pass=yes . And I accord with the current solution to render as saddle, to illustrate the saddle-property of a pass. Since usually not each pass is also a saddle, but each saddle along a highway is a pass too.

So for me this PR would be ready to publish.

Fixed

[jeisenbe]

While this PR is not ideal (I would still prefer a rendering that emphasized the orientation of the road or path through the mass), it is acceptable. I’m inclined to merge this, though will wait to see if there are any additional comments or reviews

[hiddewie]

Perfect, thanks!