Render mountain_passes

[remontees]

Is it possible to render on the openstreetmap moutain_passes with symbols like >=< ?

Thanks a lot!

[mrwojo]

12,203 uses per http://taginfo.openstreetmap.org/keys/mountain_pass

Technical issue: mountain_pass=* is not in the osm2pgsql style.

Technical caveat: There's some talk on the wiki doc of rendering the symbol in the direction of the way, however 99% of mountain passes are tagged on nodes (no direction).

[remontees]

Yes… but?

[sabas]

Also http://wiki.openstreetmap.org/wiki/Tag:natural%3Dsaddle could be rendered..

[simonpoole]

I don't think any fancy rendering is really necessary, name plus ele if present in brackets. For example "Pragelpass (1548)". Right now their is a tendency to add place nodes to display the name.

[matkoniecz]

Note that it conflicts with #718 - displaying both will result in duplicated names.

[matkoniecz]

As natural=saddle rendering was added in #718 I will close this issue (reopened, but I think that displaying both natural=saddle and this feature is not a good idea - and natural=saddle is more general).

[simonpoole]

Closing this doesn't seem to make an awful lot of sense at this point in time.

There are ~14'000 mountain_pass tagged vs ~5000 saddles (from an importance pov a large number of the passes are -very- well known locations, contrary to saddles as natural features). Should a natural=saddle be added to each of the passes, or what is the proposed resolution?

[matkoniecz]

Should a natural=saddle be added to each of the passes

For situations where it is saddle point - yes, it would be a good idea (technically, road may go through ridge not only through saddle points).

[kocio-pl]

Both are now about 20k uses and we have hstore already. The question is how should they be rendered?

[kocio-pl]

I guess replicating saddle rendering, but in transportation blue (similar to ford=* rendering) would be good.

[jragusa]

Several passes in the Alps comprise both natural=saddle and mountain_pass=yes(https://overpass-turbo.eu/s/yWl). What would be the correct colour in this case ?

[kocio-pl]

I still haven't decided. What would be your proposition?

[jragusa]

That's a good challenge because 45% of mountain_pass comprise natural=saddle. I would propose to render both features in orange for simplicity. I'm also wondering whether it is really necessary to render differently mountain pass and saddle. I'm not sure that people point out the difference between them.

[matkoniecz]

I am not convinced at all that displaying both "the highest point of a mountain way passing a crest" and "lowest point along a ridge or between two mountain tops" is a good idea.

Especially with the same symbol, it will strongly encourage people to start removing "duplicates".

[dieterdreist]

sent from a phone

On 19. May 2018, at 13:30, Mateusz Konieczny ***@***.***> wrote: I am not convince at all that displaying both "the highest point of a mountain way passing a crest" and "lowest point along a ridge or between two mountain tops" is a good idea.

I would guess it is not uncommon both are on the same point or very close cheers, Martin

[jragusa]

Indeed, two colours (or shapes?) are needed for both features to avoid the removal of "duplicates". But in the case of hiking path, they are frequently close or on the same point which involves to define which feature has the priority.

[matkoniecz]

Note that I reopened this issue after

Closing this doesn't seem to make an awful lot of sense at this point in time.

There are ~14'000 mountain_pass tagged vs ~5000 saddles (from an importance pov a large number of the passes are -very- well known locations, contrary to saddles as natural features). Should a natural=saddle be added to each of the passes, or what is the proposed resolution?

At this moment we have 25k of each feature (see https://taginfo.openstreetmap.org/keys/mountain_pass and https://taginfo.openstreetmap.org/tags/natural=saddle ).

Given that rendering both makes no sense at all and would be highly confusing I plan to close this issue again.

[kocio-pl]

Both are different, so I think rendering mountain_pass with transport blue and saddle with peak orange will show it. When both are tagged (11 363 cases, 45% of saddles - see https://taginfo.openstreetmap.org/tags/natural=saddle#combinations), we could show orange symbol - I think it's more generic than transport.

[matkoniecz]

I think rendering mountain_pass with transport blue

I am not convinced that it is a good idea. What would be purpose of showing it?

[kocio-pl]

They are known orientation points, with name and its own elevation, which might be different than saddle - look at this example:

https://www.openstreetmap.org/node/1672555752#map=18/49.41742/21.69584
https://www.openstreetmap.org/node/5255771803#map=18/49.41747/21.69598

[tsk1979]

Mountain passes are important features on motorable roads in the Himalayas and some are even tourist destinations. Some for adventurers. A community mapping them wanted to use google custom map, but I told them OSM, but there is no way to do it. I guess saddle is what we need to do? But that is wrong

[jeisenbe]

There are only a few "passes" that cannot be rendered right now. Many nodes that are tagged highway=mountain_pass can also be accurately tagged natural=saddle. From the wiki: "A saddle between mountains (topographic saddle) is the area around a saddle point. A saddle point is the lowest point along a ridge or between two mountain tops and the highest point between adjacent valleys or lowlands. The saddle is often a drainage divide between different watersheds." (https://wiki.openstreetmap.org/wiki/Tag:natural=saddle) Highways often go through the saddle of a ridge. In this case just add natural=saddle to the same node. But: "Be aware that highways don't always lead exactly through the saddle point, so that the highest point of the highway and the saddle point may have different positions and elevations, especially in low mountain ranges and uplands." In this case, you should add a new node at the true location of the topographic saddle, which might be a few meters away from the highway. This will be rendered, though not right on the highway. Please still add the highway=mountain_pass to the highest node on the highway, so that it can be used for routing and other map styles and database uses. Rarely, a "mountain pass" will have a highway that goes right over a high ridge, far away from any natural saddle. This would be the one situation that isn't rendered right now. There are a few of these near me, where a mountain path goes right along a ridge. Could you give an example of a few passes in your mountains that are not currently rendered? We can take a look in Opentopomap and see if they fit the "saddle" definition. I would agree with rendering something in this case, but we don't want people to add highway=mountain_pass and forget to add natural=saddle, because both tags add useful information to the database. One of the main purposes of this Openstreetmap Carto style is to give good feedback to mappers. If a feature doesn't render, hopefully the mapper will go back and find out what tag is missing. Saddle elevations can be used to calculate the prominence of nearby peaks, and they are a real natural feature, just like peaks. Perhaps a highway=mountain_pass alone could just have a label with the elevation? Or the elevation and name without an icon? The icon would be reserved for saddles, which represent the significant topographic feature

…

On 9/23/18, tsk1979 ***@***.***> wrote: Mountain passes are important features on motorable roads in the Himalayas and some are even tourist destinations. Some for adventurers. A community mapping them wanted to use google custom map, but I told them OSM, but there is no way to do it. I guess saddle is what we need to do? But that is wrong -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #244 (comment)

[kocio-pl]

I still have no clear idea how should they be rendered. Design decision is needed.

[tsk1979]

Thanks guys. I now understand it somewhat. But I am not a very experienced mapper, and I have taken it upon myself to map all motorable passes of ladakh region. I want to map such that anybody downloading openstreetmap through OSM etc., can see those and navigate to them. Please advise what I should do now.

[kocio-pl]

If you mean downloading maps for Garmin-like devices, they have their own styles of showing data. Maybe they are showing passes already, I don't know because I don't use them.

If you mean showing on default map, we need to know how should they look like - which color, which icon (if any)? How would they look comparing to saddles? This is what we need to decide and discuss.

[jeisenbe]

Please post a link to one of the passes that has a name but is not also a saddle. That way we can use it to try some options. Do you have an idea of how you would like them to show up on the map? Would the name and elevation be enough? Do we need an icon too? Opentopomap.com is another map style that uses the same database (but it is only updated once a month). You could take a look at how they show passes and saddles. Opentopomap has hillshading and contour lines, so it may work better for showing mountain areas. Inkatlas.com will allow you to print a map based on the Opentopomap style, as well as this map style, “Openstreetmap Carto” Thank you for adding the roads and passes in the Himalayas! It’s very useful data, even if this style doesn’t show all of it.

…

-Joseph

On Sun, Sep 23, 2018 at 2:33 PM tsk1979 ***@***.***> wrote: Thanks guys. I now understand it somewhat. But I am not a very experienced mapper, and I have taken it upon myself to map all motorable passes of ladakh region. I want to map such that anybody downloading openstreetmap through OSM etc., can see those and navigate to them. Please advise what I should do now. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#244 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AoxshOrAfzHWMHOrqCEbkVeVf8MGCebWks5udx1FgaJpZM4BI53C> .

[tsk1979]

Go to openstreetmap.org and search for "kakasang la"

The exact location is
http://www.geonames.org/maps/browse_33.434787_78.559313.html

In the Overland community high altitude passes are important landmarks.
So we need

1. Icon for a mountain pass
2. Altiutude
3. Name

The popular applications which use OSM on android phones are OSMAND and mapfactor Navigator + Gaia maps etc.,

If I search for kakasang la on openstreetmap,org it takes me to that point on road, but nothing is marked there.

Its more like a landmark (eg a vista point). So I guess it should be mapped as a waypoint with attributes of
name, altitude, and motorable:yes/no. Some passes are hikes only

[jeisenbe]

FYI, the node in question is https://www.openstreetmap.org/node/2163594465, at Openstreetmap Carto: https://www.openstreetmap.org/#map=19/33.43858/78.55830 Opentopomap: https://www.opentopomap.org/#map=17/33.43858/78.55830 Looking at the contour lines, it appears that this pass,named "Kakasang La", is at a natural=saddle location. There are two ridges, which rise to the west and east of the saddle, and the land is lower to the north and south. I would recommend adding the tag natural=saddle to this node. However, the topographic maps suggest that the highest point on the highway is actually 100m to the south of the currently tagged node, perhaps at this node: https://www.openstreetmap.org/node/4469519184. See https://www.opentopomap.org/#map=18/33.43451/78.55921 H Have you confirmed the location of this pass with GPS or survey in person, @tsk1979? I do have a couple of examples from my area where the high point on a highway is not at a natural saddle, so it's a real issue: https://www.openstreetmap.org/node/5597006379 Sogosa Pass, on ridge https://www.openstreetmap.org/node/5762756124 Pass, elevation 3365, very close to a peak I would suggest rendering mountain_pass=yes with an "hourglass" shape made with two convex arcs, like on Opentopomap. Similar to this, but curved: https://commons.wikimedia.org/wiki/File:Mountain_pass_12x12_n.svg However, it should be aligned to the local direction of the highway, if possible. I recall that Imagico (Christoph) showed a way to align springs to a waterway, on his blog: http://blog.imagico.de/the-way-of-the-water/. "The rendering of springs connected to a waterway is implemented by generating the symbol geometry in SQL. Like with the water barriers this requires parametrization of the waterway line width depending on zoom level from within SQL. An alternative approach would be to use SVG markers and rotate them based on the waterway direction but you would need a large number of different SVGs for every line width which in the end would not be any less complicated overall." Does anyone know if this code, to align an icon with the parent "way", is feasible to implement in this style?

…

On Mon, Sep 24, 2018 at 1:51 PM tsk1979 ***@***.***> wrote: Go to openstreetmap.org and search for "kakasang la" The exact location is http://www.geonames.org/maps/browse_33.434787_78.559313.html In the Overland community high altitude passes are important landmarks. So we need 1. Icon for a mountain pass 2. Altiutude 3. Name The popular applications which use OSM on android phones are OSMAND and mapfactor Navigator + Gaia maps etc., If I search for kakasang la on openstreetmap,org it takes me to that point on road, but nothing is marked there. Its more like a landmark (eg a vista point). So I guess it should be mapped as a waypoint with attributes of name, altitude, and motorable:yes/no. Some passes are hikes only — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#244 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AoxshMgtwdkjoeEIh3-T06pujavbPsXwks5ueGTWgaJpZM4BI53C> .

[mboeringa]

Does anyone know if this code, to align an icon with the parent "way", is feasible to implement in this style?

It is much easier if users finally start adding useful information by entering the OSM direction=x tag, as I have done in some limited areas. That tag can then be used to rotate a point feature, which is relatively easy in most rendering frameworks. Also, having looked at some of the involved mountain paths (versus true motorcar highway=x elements), I think automatic aligning may give sub-standard results due to jaggy path lines. This last thing is less of a problem with true highways that tend to be more smooth.

[mboeringa]

By the way, AFAIK OpenTopoMap does not align the mountain pass symbol to a way element, but to a DEM, in a pre-processing step that calculates the missing direction=x field, which is a sophisticated but complex method certainly not feasible for many styles.

[jeisenbe]

I agree that this would be a nice way to render features like saddles and passes, though it's not used enough yet mboeringa, have you considered adding "direction=*" to the wiki page about mountain passes? It's only on the saddle page right now. Do you have the skills necessary to take a look at @imagico's code for springs, to see if it could work for this situation? (I like his spring rendering too, but I don't know if it is feasible for this style) Joseph

…

On Tue, Sep 25, 2018 at 2:34 PM mboeringa ***@***.***> wrote: Does anyone know if this code, to align an icon with the parent "way", is feasible to implement in this style? It is *much* easier if users finally start adding useful information by entering the OSM *direction=x* tag, as I have done in some limited areas. That tag can then be used to rotate a point feature, which is relatively easy in most rendering frameworks. Also, having looked at some of the involved mountain paths (versus true motorcar highway=x elements), I think automatic aligning may give sub-standard results due to jaggy path lines. This last thing is less of a problem with true highways that tend to be more smooth. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#244 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AoxshEGETZJ__YY63uIgv3wJ7oXxrC4Wks5uecBsgaJpZM4BI53C> .

[tsk1979]

Have you confirmed the location of this pass with GPS or survey in person, @tsk1979?

Yes, in Person
I geotagged image also
N33.434787 E78.559313

Symbol is like a bridge. Here : https://wiki.openstreetmap.org/wiki/File:Geomorphology_vosges.png

[jeisenbe]

Ok. I think the pass is a saddle, based on the topographic maps: it's a place where there are two ridges leading uphill to the right a left, while the road descends both ahead and behind. I'd recommend adding natural=saddle to this point. If you can find us a good icon for passes, that would be really helpful. It needs to be in vector graphic format, so that it will look good in pdfs and for printing

…

On Tue, Sep 25, 2018 at 3:19 PM tsk1979 ***@***.***> wrote: Have you confirmed the location of this pass with GPS or survey in person, @tsk1979 <https://github.com/tsk1979>? Yes, in Person I geotagged image also N33.434787 E78.559313 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#244 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AoxshHlMqSX1E36v-1RH5iIQbJqyfzdwks5uecr3gaJpZM4BI53C> .

[tsk1979]

There is high rez png here on wikimedia. Can that be used @jeisenbe
https://commons.wikimedia.org/wiki/File:Mountain_pass_12x12_n.svg

[ppete2]

I'm missing the rendering of mountain_pass=yes in OSM carto very much. Many other tiny POIs are rendered in OSM carto. But still not such - often well known - landmarks like mountain_passes of roads or ways?

Yes, often mountain_passes are running over a natural=saddle. But not always, and those which don't actually are missing in OSM carto. And even the Wiki says "OpenStreetMap clearly differentiates between these two concepts". Saddle is a point defined by landscape, nature. mountain_pass is part of a (man-made) way, for example a road. So both things should be rendered too.

A good example where a mountain-pass is not equal to the saddle point has been already mentioned above:
#244 (comment)

How to render?

Symbol:
Also already mentioned, something like https://commons.wikimedia.org/wiki/File:Mountain_pass_12x12_n.svg , similar signs are usually used on topografic maps to indicate passes: https://wiki.openstreetmap.org/wiki/Talk:Tag:mountain_pass
No need to complex calculate rotation. Always either vertical, horizontal or diagonal as the basic .svg is.

Text:
Should contain name + elevation

Color:
should be different from natural=saddle to be easy distinguishable.

Priority:
what to render if saddle and mountain_pass share the same node. Or are (depending on zoom level) very close to each other: No need to introduce a third symbol or a third color.
Just draw the mountain_pass, since it is perhaps more in common use to most of the people than the natural saddle point. For example people which are using the map for plannig road-trips or hiking trips.

[kocio-pl]

Would you like to prepare the code implementing this proposition? That gives the biggest chance to have this feature rendered.

[ppete2]

Sorry, I'm just an OSM editor and user of maps who supports the other users in this thread with ideas how to implement mountain_pass rendering.
But I have no knowledge of Rendering, CartoCSS, Mapnik and the necessary coding stuff.

[jragusa]

It's related to transportation, so the blue colour of @transportation-icon would be suitable. An other problem is that some "pass" has both mountain_pass=yes and saddle=yes, which one would have the priority ?

[Adamant36]

It sounds like from the wiki that they are different things and mapped seperately. So if they do overlap its probably rare. Id say treat the instances where they do like ever other overlapping feature and go with whatever icon is first in rendering priority. One could also be set to render a zoom level sooner, but I'm not sure with would be more important (although id think it would probably be the natural feature).

[jragusa]

It's the case if you consider paths and sometimes also tracks or because the saddle is narrow. Moreover the saddle was used as mountain_pass in the past since it's the easier way.

[matthijsmelissen]

If the choice is between rendering saddles or mountain passes, I'd favour the latter. Mountain passes always have relevance, while there are many saddle points that are hardly interesting.

[jeisenbe]

But if you see a road or path that crosses a saddle, then you know that saddle is also a pass, by definition. If you see a road through a pass icon, you can’t know if the pass is a saddle or not, without checking for additional tags The saddle is also a real, unambiguous natural feature, just like a peak, while a pass is a road that crosses a ridgeline - but not all points where a road crosses a ridge are considered “passes”, culturally. I would suggest rendering pass at lower priority than the saddle, but it also might make sense to show a named feature tagged “pass” AND “saddle” one zoom level sooner than just a natural=saddle, since it’s true that passes are more useful. Re: the icon, I’m worried that it will not look right if not aligned to the road. @imagico has shown how to render fords in a way that aligns the “) (” shapes to the road. This code is a little complex, but could result in a very nice rendering.

[Adamant36]

If you see a road or path that crosses a saddle, then you know that
saddle is also a pass, by definition.

I was totally thinking that.