Skip to content
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

Add rendering for natural=valley labels #788

Open
matthijsmelissen opened this issue Jul 28, 2014 · 71 comments
Open

Add rendering for natural=valley labels #788

matthijsmelissen opened this issue Jul 28, 2014 · 71 comments
Labels
new features Requests to render new features text
Milestone

Comments

@matthijsmelissen
Copy link
Collaborator

matthijsmelissen commented Jul 28, 2014

The following issue has been moved over from trac:

The following are all tags used for common natural features in Iceland (and probably elsewhere) on nodes (along with place=locality to get them to render). They're traditionally rendered as plain text on maps:

  • natural=fjord
  • natural=valley
  • natural=peninsula
  • natural=channel
  • natural=inlet

The list is ordered roughly by how prominent each should be on the map. But of course these things can differ wildly.

@daganzdaanda
Copy link

natural=heath has been added in the meantime, see #780.
"valley" is not in the code, but #787 seems to say it is rendered? maybe it was once?
The name of a "bay" should be rendered now at >=14 (#199 removed the fill)

+1 for showing the names of the rest.

Good rendering will not be easy, I assume. Putting a name on a fjord or inlet should be possible, since watery areas are not usually full of other things that get in the way, But a valley, or a natural=ridge?

People use things like place=locality or place=region to give names to larger areas.
User maxbe has a way to render a name over a large area:
http://geo.dianacht.de/topo/ Go to the alps to see the names of the regions there.
Explanation: http://wiki.openstreetmap.org/wiki/User:Maxbe/Kartenversuch#Beschriftung_von_Gebirgen
Short explanation in English (pic): http://wiki.openstreetmap.org/wiki/File:Maxbe-stubaier-beschriftung_en.png

It looks really great, but my guess is, it can't be done with carto-css alone. Or am I wrong?

@matthijsmelissen
Copy link
Collaborator Author

#787 seems to say it is rendered?

I guess the catchall rendered it on lines and areas.

@Klumbumbus
Copy link

See also openmapsurfer as an example of nice rendering of strait (Kattegat, Skagerrak) and some other similar features. Also on the other zoom levels.

@23cpo
Copy link

23cpo commented Aug 2, 2014

I would also add the following place tags to the list:
place=sea - http://www.openstreetmap.org/node/305640275
place=ocean - http://www.openstreetmap.org/node/305640074

@sabas
Copy link

sabas commented Sep 10, 2014

natural=cape http://wiki.openstreetmap.org/wiki/Tag:natural%3Dcape

matthijsmelissen added a commit to matthijsmelissen/openstreetmap-carto that referenced this issue Sep 12, 2014
This commit changes the rendering of landcover labels.

For the purpose of this commit, with 'landcover label' we mean text connected to
a background colour or pattern rendering, and not connected to an icon.

* All rendered landcover tags now have their name rendered (resolves gravitystorm#537). We
  add labels to the following tags:
  * natural=beach,scrub,grassland,heath,sand,desert (partially resolves gravitystorm#788)
  * highway=services,rest_area (resolves gravitystorm#575)
  * aeroway=apron
  * power=station,generator,substation,sub_station
  * tourism=zoo
  * military=barracks
* The minimum zoom level of labels is now defined based on the number of pixels
  rendered (resolves partially gravitystorm#703, resolves gravitystorm#861, resolves gravitystorm#913).
  Labels are rendered from 3000 pixels (but never earlier than the corresponding
  landuse is rendered).
* Font size now also depends on way_pixels. In other words, larger objects get
  a larger label, in three steps (resolves gravitystorm#308).
* Landuse labels are now rendered oblique, to easier visually tell them apart
  from village and POI labels.
* All labels are rendered in a colour similar to the landuse they belong to
  (using landuse color variables, resolves gravitystorm#56). Also some existing colours
  are changed, in order to make them clearly colourful but still readable.
* The text-halo-radius and text-wrap-width properties are made consistent across
  landuse types.
* Font-size, wrap-width an face-name are now defined by easy to change
  variables.
matthijsmelissen added a commit to matthijsmelissen/openstreetmap-carto that referenced this issue Sep 21, 2014
This commit changes the rendering of landcover labels.

For the purpose of this commit, with 'landcover label' we mean text connected to
a background colour or pattern rendering, and not connected to an icon.

* All rendered landcover tags now have their name rendered (resolves gravitystorm#537). We
  add labels to the following tags:
  * natural=beach,scrub,grassland,heath,sand,desert (partially resolves gravitystorm#788)
  * highway=services,rest_area (resolves gravitystorm#575)
  * aeroway=apron
  * power=station,generator,substation,sub_station
  * tourism=zoo
  * military=barracks
* The minimum zoom level of labels is now defined based on the number of pixels
  rendered (resolves partially gravitystorm#703, resolves gravitystorm#861, resolves gravitystorm#913).
  Labels are rendered from 3000 pixels (but never earlier than the corresponding
  landuse is rendered).
* Font size now also depends on way_pixels. In other words, larger objects get
  a larger label, in three steps (resolves gravitystorm#308).
* Landuse labels are now rendered oblique, to easier visually tell them apart
  from village and POI labels.
* All labels are rendered in a colour similar to the landuse they belong to
  (using landuse color variables, resolves gravitystorm#56). Also some existing colours
  are changed, in order to make them clearly colourful but still readable.
* The text-halo-radius and text-wrap-width properties are made consistent across
  landuse types.
* Font-size, wrap-width an face-name are now defined by easy to change
  variables.
matthijsmelissen added a commit to matthijsmelissen/openstreetmap-carto that referenced this issue Sep 22, 2014
This commit changes the rendering of landcover labels.

For the purpose of this commit, with 'landcover label' we mean text connected to
a background colour or pattern rendering, and not connected to an icon.

* All rendered landcover tags now have their name rendered (resolves gravitystorm#537). We
  add labels to the following tags:
  * natural=beach,scrub,grassland,heath,sand,desert (partially resolves gravitystorm#788)
  * highway=services,rest_area (resolves gravitystorm#575)
  * aeroway=apron
  * power=station,generator,substation,sub_station
  * tourism=zoo
  * military=barracks
* The minimum zoom level of labels is now defined based on the number of pixels
  rendered (resolves partially gravitystorm#703, resolves gravitystorm#861, resolves gravitystorm#913).
  Labels are rendered from 3000 pixels (but never earlier than the corresponding
  landuse is rendered).
* Font size now also depends on way_pixels. In other words, larger objects get
  a larger label, in three steps (resolves gravitystorm#308).
* Landuse labels are now rendered oblique, to easier visually tell them apart
  from village and POI labels.
* All labels are rendered in a colour similar to the landuse they belong to
  (using landuse color variables, resolves gravitystorm#56). Also some existing colours
  are changed, in order to make them clearly colourful but still readable.
* The text-halo-radius and text-wrap-width properties are made consistent across
  landuse types.
* Font-size, wrap-width an face-name are now defined by easy to change
  variables.
@matthijsmelissen matthijsmelissen changed the title Add rendering natural=* labels Add rendering for natural=* labels Sep 24, 2014
@matthijsmelissen
Copy link
Collaborator Author

Reopened - only resolved partially.

@matkoniecz
Copy link
Contributor

I think that it would be better to open separate tickets for separate tags. BTW, natural=bay is rendered and I removed it from list in the ticket.

@matkoniecz
Copy link
Contributor

place=ocean - http://www.openstreetmap.org/node/305640074

It is a really poor idea. Borders of oceans (and even number of oceans) varies depending on sources (see for example http://en.wikipedia.org/wiki/Borders_of_the_oceans). Also, mapping ocean as node is absurd. At this scale manually selected labels are a better solution.

@imagico
Copy link
Collaborator

imagico commented Oct 26, 2014

Also, mapping ocean as node is absurd

Please keep in mind we do not only map for the renderer - the ocean nodes provide useful and relevant information and nodes are the only sensible way to map those currently in OSM. And in a (non real time) renderer they can - when reasonably placed - even be used to calculate appropriate automatic label placement.

@matkoniecz
Copy link
Contributor

natural=heath label is now rendered.

@matthijsmelissen
Copy link
Collaborator Author

The tag natural=peninsula has 59 occurrences, natural=channel has 34 occurrences, and natural=inlet has 9 occurrences. That's too little to render them.

@dieterdreist
Copy link

2015-03-22 1:45 GMT+01:00 math1985 [email protected]:

The tag natural=peninsula has 59 occurrences, natural=channel has 34
occurrences, and natural=inlet has 9 occurrences. That's too little to
render them.

I don't agree, these are typically very significant features and supporting
them will increase the overall cartographic quality. Also there exist much
fewer of these features in the world than of other features, so maybe those
numbers aren't that bad (refering to channel and peninsula).

@imagico
Copy link
Collaborator

imagico commented Mar 24, 2015

Note natural=channel, natural=inlet, natural=fjord and natural=sound are all undocumented and it is not clear what exactly distinguishes them from natural=strait and natural=bay.

natural=fjord is the only one with more widespread and consistent use, could be defined as something like 'long and narrow bay formed by glaciers' and would make sense to be rendered together with natural=bay.

@jeisenbe
Copy link
Collaborator

jeisenbe commented Sep 23, 2019 via email

@eehpcm
Copy link

eehpcm commented Sep 23, 2019

@jeisenbe

Is it the line that is halfway between the tops of the ridges on each side, or the line at the center of the flatish part of the valley, or something in between?

It's an approximation. The best we can do using aerial imagery and OpenTopoMap. Complicated by the fact that the valley may contain a wood. But everything we do is an approximation. Look at the Afon Teifi just north of Cwm Morgenau. Two years ago it came from NPE and was a very crude approximation to the true course. Some time in the last 2 years I tweaked it, but I had no idea where the thalweg was so placed it roughly midway between the banks. Sometime after that I mapped the banks to show the true width. One day somebody might actually map the thalweg, but until then it's a better approximation than it was with NPE data. Comparing different aerial imagery shows transitional, rotational and scaling differences, so everything is approximate.

No two mappers would map the same valley exactly the same way. But most conscientious mappers would come up with approximations that were in broad agreement and that were good enough.

Unfortunately this isn't defined.

I think that may be a good thing. It would turn a difficult task (that's a reasonable approximation) to an impossible one (there's no way of knowing the exact centreline to that standard, so I can't map it).

The labels are shown in other styles like Opentopomap,

I hadn't realized that. I just checked Cwm Morgenau and can't see why the label is there twice. I don't think it's something I did wrong, it looks like OpenTopoMap had a brain fart.

It's more appropriate to show linear valleys differently in that case, since mappers will see if there is something clearly wrong, like a line that has been draw without regard to the actual shape of the valley to just get a certain label position.

I still don't see that as a huge problem. Sure, I could map a valley, be unhappy with the non-oriented label placement, remap it, check again, remap it,... until I was happy with the label placement. Or I could just add a place=locality and do a lot less work. I think the majority of valleys will be mapped as honest attempts to show the true valley, not to place labels. I also think that if standard carto renders a valley label no differently from that which would be shown by place=locality, more mappers will be tempted to just use place=locality because it's far less work. In fact, I think if valleys are shown with non-oriented labels, that makes it more likely mappers will tweak the valley (possibly a lot) just to get a better placement when they'd accept an oriented label that looked a little unaesthetic as simply representing reality.

@mboeringa
Copy link

mboeringa commented Oct 4, 2019

I think the majority of valleys will be mapped as honest attempts to show the true valley, not to place labels.

I have seen few if any problems with mappers mis-using valley tagging on lines and polygons. I agree most are honest attempts to show the approximate location of the valley.

The main problem I see with current tagging sometimes is that people simply replicate the course of a river or main stream running through the the valley, which may not always be appropriate for the valley as a whole.

@jeisenbe
Copy link
Collaborator

Here are a couple of valleys that I mapped a year or two ago (though I'm not too happy with them now). Attempting to render a text label on the line does not work well:

iniye-z14

  • The valley line should closely follow the river, but this looks bad when rendered on the line.

iniye-z15

lower-baliem-valley-z15

grand-baliem-valley-z13

grand-baliem-valley-z14

grand-baliem-valley-z16

  • Here the label might be confused as belonging to the residential area.

Perhaps some combination of simplification of the line, plus stretching out the label to match the length of the way to some extent could work in another style, but probably not in this style which lacks a representation of the terrain.

@jeisenbe
Copy link
Collaborator

I considered rendering the valley label near the center of the way (or on the point). But this looks odd at high zoom levels, when the valley is large, though it is fine for small valleys.

@imagico, in this case would it be appropriate to stop rendering the labels for very long valleys which extend off the screen, as we would for the text label of a large area?

E.g:

  ST_Length(way)/NULLIF(SQRT(!pixel_width!::real*!pixel_height!::real),0) AS way_length,

(though it would be better to use scale_denominator)

  [feature = 'natural_valley'][zoom >= 12][way_length < 1200] {

I know we wouldn't want to show text labels larger or at an earlier zoom level without a representation of the line, but perhaps this is acceptable, since it only is removing the text label when the valley is too long for the usual screen size?

@eehpcm
Copy link

eehpcm commented Mar 22, 2020

@jeisenbe

Here are a couple of valleys that I mapped a year or two ago (though I'm not too happy with them now). Attempting to render a text label on the line does not work well:

What other maps do (which may be a simple matter of programming here or very, very difficult) is offset the label so it doesn't overlap the watercourse. It results in a label that isn't positioned exactly, but gives a reasonable indication of the length and geometry of the valley.

@jeisenbe
Copy link
Collaborator

offset the label so it doesn't overlap the watercourse.

Generalization is a great idea for map legibility, but another very important goal of this style is mapper feedback, and for that it is important for the precise geometry to be shown. That's why we don't move overlapping roads along rivers. Also the processing would be somewhat computationally expensive, and the more complex code would be harder to edit and maintain

@imagico
Copy link
Collaborator

imagico commented Mar 24, 2020

Independent of the questions if there is a consistent and verifiable mapping of valleys at the moment i would - like in case of polygons - be very much against labeling linear ways without providing feedback on the geometry and its extent. That would incentivize drawing of non-verifiable labeling geometries.

@jeisenbe
Copy link
Collaborator

jeisenbe commented Mar 24, 2020

As mentioned above, my suggestion is to render a horizontal text label at the center point of the natural=valley way only.

The only possible use of the line length would be to stop rendering valleys which were clearly much larger than the usual screen size. All would start rending at the same zoom level.

If this isn't feasible, we could only render labels on nodes. At least in that case it would incentivize using natural=valley instead of a place=locality node, and would get us a step closer to removing the rendering of place=locality.

@imagico
Copy link
Collaborator

imagico commented Mar 24, 2020

As mentioned above, my suggestion is to render a horizontal text label at the center point of the natural=valley way only.

The only possible use of the line length would be to stop rendering valleys which were clearly much larger than the usual screen size. All would start rending at the same zoom level.

I see - i am doubtful about the usefulness of that regarding the goals of this style. Even if i imagine that tag was consistently used on linear ways in some form (which is purely wishful thinking) that would only lead to a meaningful labeling at a very small range of zoom levels and what range that is depends a lot on the circumstances. There are valleys that are in size of the order of a few hundred meters while there are also valleys of a few hundred kilometers. The range of sensible zoom levels for those two does not even overlap.

@jeisenbe
Copy link
Collaborator

there are also valleys of a few hundred kilometers

Fortunately, very few of these are mapped as ways in Openstreetmap. I haven't found any so far in the dozen areas that I have looked at.

There are valleys that are in size of the order of a few hundred meters

Most valleys which I have checked are in this range of a few hundred meters to a few kilometers.

Many areas have no natural=valley features mapped, e.g. most developing countries which I checked, and flat areas like most of the Netherlands and Delaware. Also most US states and Canadian provinces do not have any valleys mapped yet.

However, there are some mountainous and hill areas where they are commonly used.

Of the places I have downloaded, Burgenland in eastern Austria and Hautes Alpes in France have the most valleys, and fortunately they are fairly consistently used there. Some regions of Spain also have a number of valleys, though these are often very coarselly mapped with just 2 to 4 nodes, but I'm still happy to encourage tagging these, rather than using locality for all small unpopulated place names (very common in France and Spain).

@jeisenbe
Copy link
Collaborator

In these test images I've rendered the valley name label on the center of the line (or on the node) with landform-color (same as peaks/saddles), and rendered a thin landform-color line along the way, if there is one, to show the underlying data. This is not a proposed rendering, but a way to show what the data looks like. Testing at z14 since that would be the earliest to show these features (thoug z15 would be consistent with ridges, aretes and cliffs).

Hautes Alpes

  • 26 ways, all except 1 with a name, no nodes
  • Never added to the same feature as waterway=stream, though sometimes it follows a similar geometry

https://www.openstreetmap.org/#map=14/44.4583/6.5547
valleys-france-14:44 4583:6 5547

https://www.openstreetmap.org/#map=15/44.8117/6.7131
valley2-france-15:44 8117:6 7131

https://www.openstreetmap.org/#map=15/44.8117/6.7131

  • 5 valleys - one name is blocked by the peak icon (northeast)
    valley2-france-15:44 8117:6 7131

https://www.openstreetmap.org/#map=15/44.6942/5.8519

  • Smallest one. This works at z15, but z14 is pushing it
    valley-france-15:44 6942:5 8519

valley-france-14:44 6942:5 8519

== Burgenland ==

  • 61 ways, no nodes, all but 2 with names.
  • This appears to be a karst region, since many valleys lack a waterway feature.
  • One of the forest polygons is broken in this extract; pretend the background is green.
  • Obviously the test rendering doesn't work well with track roads.
    https://www.openstreetmap.org/#map=14/47.9775/16.8216
    valleys-2-burgen-14:47 9775:16 8216

https://www.openstreetmap.org/#map=14/47.8852/16.5819
valleys-more-burgen-14:47 8852:16 5819

https://www.openstreetmap.org/#map=14/47.8828/16.5008]
valleys-many-burgen-14:47 8828:16 5008

https://www.openstreetmap.org/#map=14/47.4354/16.2099
valley-stream-burgen-14:47 4354:16 2099

https://www.openstreetmap.org/#map=14/47.3785/16.3751
valleys-4-burgen-14:47 3785:16 3751

https://www.openstreetmap.org/#map=15/47.3355/16.3519
valleys-3-burgenland-15:47 3355:16 3519

== Asturias, Spain ==

  • I also checked Extremadura, but there were no valleys there.
  • Asturias has 5 ways with natural=valley, all named.

https://www.openstreetmap.org/#map=14/43.2623/-4.8033
valley-canal-lilamedu-14:43 2623:-4 8033

At z16 lots of place=locality features are visible nearby
valley-canal-lilamedu-16:43 2623:-4 8033

https://www.openstreetmap.org/#map=14/43.1975/-4.7749

  • Valle de las moñetas is duplicated as a place=locality node, the intermittent waterway has a different name "riega de las moñetas"
    valley-monetas-14:43 1975:-4 7749

valley-monetas-16:43 1975:-4 7831

https://www.openstreetmap.org/#map=15/43.1951704/-5.2233951

  • This valley looks like a pass or saddle too
    foz-valley-15:43 1951704:-5 2233951

https://www.openstreetmap.org/#map=14/43.3719/-4.8662

  • Somewhat roughly mapped
    asturias-valley1-14:43 3719:-4 8662

@jeisenbe
Copy link
Collaborator

There are a few valleys mapped in Tasmania, Wales and Hawaii, though many other English-speaking areas do not have any mapped yet.

== Tasmania ==

  • 5 valleys, all mapped as ways but one, all named
  • The ways are rather rough

https://www.openstreetmap.org/#map=14/-43.6010/146.8627

  • Finally a node
    blowhole-valley-14:-43 6010:146 8627

https://www.openstreetmap.org/#map=14/-41.6632/145.9525
Marigold valley - rather small, perhaps it is a ravine?
marigold-valley-14:-41 6632:145 9525

marigold-valley-15:-41 6632:145 9525

https://www.openstreetmap.org/#map=14/-41.8186/146.3115

  • Fun Biblical / Holy Land names in this area
    valley-of-hinom-14:-41 8186:146 3115

https://www.openstreetmap.org/#map=14/-41.9200/146.1540
valley-never-never-14:-41 9200:146 1540

== Wales ==

  • 3 ways, all named

https://www.openstreetmap.org/#map=15/51.9998/-4.6185
z15-valley-wales-15:51 9998:-4 6185

https://www.openstreetmap.org/#map=14/52.0590/-4.6242

  • z14 is marginal for these 2 small valleys
    z14-valleys-wales-14:52 0590:-4 6242

== Hawaii ==

  • No nodes, 42 ways, but only 30 named. The 12 unnamed ways are also tagged waterway=*, as are 8 of the named ways - these would not be rendered.
  • Lots here are mapped in gullies which might deserve to have a waterway=intermittent mapped as well, based on the aerial imagery, though often the name includes "valley" rather than "gully" or "stream" etc.

https://www.openstreetmap.org/#map=16/23.0581/-161.9168

  • These ways are double-tagged as valleys and intermittent streams, though the name includes the word "valley":
    hawaii-nihoa-valleys-streams-16:23 0581:-161 9168

https://www.openstreetmap.org/#map=15/20.0296/-155.8133

  • Small gulches which look like intermittent streams on aerial imagery (there are bridges on the road)
    hawaii-gulches-15:20 0296:-155 8133

https://www.openstreetmap.org/#map=14/21.8934/-160.0998

  • All these valleys are fairly nicely mapped. They should also have the intermittent streams mapped, though this has not been done yet. The name appears to refer to the valley not the stream.
    hawaii-niihau-valleys-14:21 8934:-160 0998

@jeisenbe
Copy link
Collaborator

Besides the 2 really big valleys that I mapped here in Papua, the only really large valleys I have found so far are in Norway - partially they appear big due to the high lattitude. Here are there some that really should be shown at z12 or z13.

== Norway, Sogn og Fjordane ==

  • One node, 35 ways, all named. One is also a waterway=stream.

https://www.openstreetmap.org/#map=14/61.4989/8.3040

  • Mapped as a node, moderate sized per topo map
    norway-valley-node-14:61 4989:8 3040

norway-valley-node-Opentopomap

Most of the ways are 5 to 20 kilometers long (22/35), like these. The very longest is 38 but includes part of a fjord: only 5 are over 20km.

https://www.openstreetmap.org/#map=14/61.4749/8.2782
norway-valley-way-long-14:61 4749:8 2782

https://www.openstreetmap.org/#map=14/61.4825/7.9626
norway-valley-long-14:61 4825:7 9626

https://www.openstreetmap.org/#map=14/61.4640/8.0680
norway-valley-long-14:61 4640:8 0680

But there are 8 that are less than 5 kilometers long, (about 1/4) eg:
https://www.openstreetmap.org/#map=14/61.9903/6.4627
norway-short-valley-14:61 9903:6 4627

@jeisenbe
Copy link
Collaborator

=== Analysis of all natural=valley ways ===
I downloaded all 11,106 natural=valley ways with name=* tags - ouch, that was 49 megabytes.

2495 have a waterway= tag (mostly waterway=stream), but most of these are waterway=drystream (stream is the next most at 846). Also, 1547 of these are all in one small region of Russia(?) centered on 50.8797426, 40.1522567, most added by User:keder in 2016-17

No other combinations are very significant.

  • 95% are shorter than 13 kilometers (only 579 have waylength > 12,000 meters)
  • 90% are shorter than 8 kilometers
  • 85% are shorter than 5 kilometers

The median natural=valley way is 1281 meters long, according to JOSM.

  • 95% are longer than 150 meters
  • 90% are longer than 300 meters
  • 85% are longer than 400 meters

So a super-majority (70%) are between 0.4 kilometers and 5 kilometers in length, and 80% are 300m to 8km in length

The middle 46% are between 0.5 and 2.0 kilometers: only 2 zoom levels difference.

=== Conclusion ===

I think we can consider rendering these features by focusing on the majority that are a couple hundred meters to a few kilometers in length (and also the small number of nodes should be rendered).

Unfortunately I do not have any good ideas for a linear representation. Since these are not usually nodes, a point icon (like natural=saddle) would not be appropriate.

So I am planning to just render the name at the center, though probably in gray rather than landform-color.

@jeisenbe
Copy link
Collaborator

I believe a gray label is the best option. While I considered something similar to the landform-color text labels used for peaks and saddles, that is matching an icon.

As a text label only it might make more sense to match the place=locality, place=island and natural=cape labels, and natural=ridge / natural=arete which are gray.

Options:

1) Brown labels (based on landform-color)
valleys-after-brown-14:44 4596:6 5612

valley-vs-ridge-france-15:45 0822:6 3171

2) Gray labels, oblique
valleys-after-gray-oblique-14:44 4596:6 5612

martignare-valley-ridge-gray-oblique

3) Gray labels, standard (book-fonts)
valleys-after-gray-book-14:44 4596:6 5612

martignare-valley-ridge-15-gray-book

@jragusa
Copy link
Contributor

jragusa commented Mar 27, 2020

Grey label with standard font would be consistent with ridge names. I also notice that natural=cape is labelled in black colour, do we need to have two colours for natural features ?

@imagico
Copy link
Collaborator

imagico commented Mar 27, 2020

So a super-majority (70%) are between 0.4 kilometers and 5 kilometers in length, and 80% are 300m to 8km in length

The middle 46% are between 0.5 and 2.0 kilometers: only 2 zoom levels difference.

It is natural for this kind of feature there are a large number of smaller ones and only very few larger ones. But that does not mean there are no larger ones. Like:

https://www.openstreetmap.org/way/374056124
https://www.openstreetmap.org/way/539764751
https://www.openstreetmap.org/way/706934555
https://www.openstreetmap.org/way/539763901

Overall i have strong doubts about the kind of labeling you suggest. The main problem with the current mapping of natural=valley is that there is no consistency in the geometries. The suggested labeling would not help changing that because the mapper will get feedback about having done something right (by there appearing a label) but that positive feedback will appear no matter how they draw the line. At the same time the benefit for the map usefulness seems rather small by placing a point label somewhere along the mapped geometry.

@jeisenbe
Copy link
Collaborator

So you would only be in favor of labeling these if we also show the line?

I haven't been able to find examples online of linear representations for valleys. Probably in modern maps it is assumed that shading and contour lines are used instead.

Any ideas on how it might be done?

@imagico
Copy link
Collaborator

imagico commented Mar 27, 2020

So you would only be in favor of labeling these if we also show the line?

No, even if there was a good way to do that - mapping lacks the consistency for this to make sense.

It seems to me that most of the natural=valley geometries in the database were created to generate a certain result in maps which render labels for those. This is in particular cases where mappers draw the lines with a deliberate offset to place an offset label.

We could of course do the same and offer mappers the option to directly draw labels in our map. But i don't think this is the responsible thing to do.

Ultimately it is not within our mandate to tell mappers actively how they are supposed to map valleys. Therefore i think the only thing we can say at the moment is that the current way these are mapped does not work and we therefore can't support it.

@eehpcm
Copy link

eehpcm commented Sep 25, 2020

I just noticed that OpenTopoMap renders valleys. I'm not saying it's the way to go (especially as I don't know how much computational load their approach requires) but it gives an example of how it could be done.

z=16
z=17

I think it looks acceptable. We might quibble over the text colour for consistency with other features, but apart from that I think it looks OK.

BTW, would a river gorge be considered natural=valley or should it be natural=gorge? If the latter, would code be added to render natural=gorge if code is added for natural=valley?

@Ircama
Copy link
Contributor

Ircama commented Sep 28, 2020

I also considered this topic in the past and as far as I remember the reason why valley is not currently rendered in openstreetmap-carto is due to the lack of verifiability in the valley definition (as with other geographical features in OpenStreetMap). For instance, currently its data model does not support intersecting a house with a valley to check whether that house is inside a valley.

Discussions on data models are common to other geographical features in OpenStreetMap, where unfortunately geometry is not yet agreed and related arguments do not provide improvements.

Designing an acceptable geometry for valleys (e.g., whether a valley shall be represented through its thalweg or it is an area) is needed before considering its rendering here. At least this looks the spirit of the maintainers of openstreetmap-carto, the official OpenStreetMap rendering, possibly also as an incentive to improve arguable data models of some OpenStreetMap features.

Platforms like OpenTopoMap and Osmand, which are not official even if remarkable, decided to render valleys and many other geographic features based on current definitions, also in case they are more oriented to directly draw a label with the current renderers than describe the feature.

@eehpcm
Copy link

eehpcm commented Sep 28, 2020

Designing an acceptable geometry for valleys (e.g., whether a valley shall be represented through its thalweg or it is an area) is needed before considering its rendering here. At least this looks the spirit of the maintainers of openstreetmap-carto, the official OpenStreetMap rendering, possibly also as an incentive to improve arguable data models of some OpenStreetMap features.

In this thread there have been many reasons put forward why valleys cannot be rendered, or should not be rendered, or must not be rendered. One of the arguments was along the lines of "Even if we could rigidly define how to map a valley as a way, there is no good way of rendering it because reasons."

I think OpenTopoMap has shown that it is possible to adequately render a valley mapped as a way, even when the label partially obscures the associated river.

Now we can move onto the arguments about accuracy and definitions (and even thalwegs, if you insist). To which i'll respond that everything we map is an approximation and we understand that when better aerial imagery, or better GPS traces or whatever come along then we refine that approximation. If we insist that we must not map something unless we can map it perfectly then we can all give up an go home.

@Ircama
Copy link
Contributor

Ircama commented Sep 28, 2020

In this thread there have been many reasons put forward why valleys cannot be rendered, or should not be rendered, or must not be rendered. One of the arguments was along the lines of "Even if we could rigidly define how to map a valley as a way, there is no good way of rendering it because reasons."

I am generally in favor to see names of valleys rendered, together with other mountain features and I have tried to summarize the essence of the issue as I understand it.

@ppete2
Copy link

ppete2 commented Nov 8, 2023

I wish to see valleys rendered too. Valleys are an important topological feature, which are in frequent use in talks, newspapers etc.

Btw: On the very top of this issue it's written "Fixed by #941" . Could this be deleted, cause the issue isn't fixed at all.

@dch0ph
Copy link
Contributor

dch0ph commented Jan 27, 2024

I suspect that rendering valley names will look odd in a non-topographic map like Carto.

It can work if you have contours / hill-shading. Here a Carto-derivative where valley names are only rendered at Z11 and Z12:
Z12:
image
Z13:
image

The valley name would interfere with the extra detail that appears at Z13.

@gylfiolafsson
Copy link

I would revive this thread in support of rendering valleys. Here are three reasons:

  1. In Iceland, as in many other countries of similar geology, valleys are very highly-ranked as geographical features that are used in everyday speech. Minor issues with rendering should not come in the way of showing these features on maps.

  2. Looking at data on number of tags, we can see that in the 10 years since this thread was started, valleys have grown to be 55.000 worldwide. image With rendering, this number will increase quickly to cover more valleys.

  3. The tag is approved in the Openstreetmap wiki https://wiki.openstreetmap.org/wiki/Tag:natural%3Dvalley

Many beautiful renderings are shown here above, indicating that this is perfectly possible in an elegant way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new features Requests to render new features text
Projects
None yet
Development

No branches or pull requests