Add rendering for natural=valley labels

[matthijsmelissen]

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]

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]

787 seems to say it is rendered?

I guess the catchall rendered it on lines and areas.

[Klumbumbus]

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]

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]

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

[matthijsmelissen]

Reopened - only resolved partially.

[matkoniecz]

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]

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]

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]

natural=heath label is now rendered.

[matthijsmelissen]

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]

2015-03-22 1:45 GMT+01:00 math1985 notifications@github.com:

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]

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.

[Tomasz-W]

Labels to render:

• natural=fjord
• natural=valley
• natural=cape (https://github.com/gravitystorm/openstreetmap-carto/issues/3148)
• natural=ridge (https://github.com/gravitystorm/openstreetmap-carto/issues/1148 https://github.com/gravitystorm/openstreetmap-carto/issues/2774)

[hansfn]

It would help a lot if the initial post was updated with the labels in the comment above and any other labels mentioned in the previous comments. I probably wouldn't have created issue #3148 then :-)

[Tomasz-W]

@matthijsmelissen Can you update a list in first post to a task list with tags from https://github.com/gravitystorm/openstreetmap-carto/issues/788#issuecomment-405082390

[meased]

This may be a question more general to this style than this particular issue, but are there any issues using text-character-spacing with all of the languages we render?

Some features (such as valleys, maybe even streams/rivers) would look nice with character separation but I believe some languages rely heavily on ligatures.

Has anyone looked into this before?

[kocio-pl]

Ask @sommerluk about such things.

[sommerluk]

Some features (such as valleys, maybe even streams/rivers) would look nice with character separation

Indeed letter-spacing looks nice for features like big valleys or big water bodies. It’s something I would like to have.

but I believe some languages rely heavily on ligatures.

The problem are not so much the ligatures. OpenType does a quite good job separating typographic ligatures like “fi” from orthographic ligatures like “æ”: The former should break up when using letter-spacing, the latter not.

are there any issues using text-character-spacing with all of the languages we render?

Has anyone looked into this before?

The problem are cursive scripts. Quoting myself from another issue comment:

• Regular/letter-spacing works for LGC scripts and probably most other scripts without big problems except cursive scripts like arabic. Some Mapbox software even disables letter-spacing for Arabic scripts.

Apart from Arabic, there are many Indic scripts that have joined letter forms, though it seem they use sometimes letter-spacing, but the rules are complex and based on syllables, not on letters.

The latest Noto release “phase III” has not only introduced support for many new scripts, but also various font widths that are designed by hand and are a good choice for usage – not only for the Latin script, but also for many other scripts including Arabic and various Indic scripts. Unfortunately, the list of width is

• extracondensed
• condensed
• semicondensed
• normal

There are no “expanded” variants. It’s really a pity, because an “expanded” style would be perfect for our usage. (Anyway, maybe we can make use of one of the condensed styles one day…)

So, in summary I see some risks when using letter-spacing, that is difficult to control for complex scripts without breaking rendering – and scripts like Arabic and the Indic scripts together might have 10% or 20% of the population world-wide, which is considerable.

[meased]

Thanks for the explanation @sommerluk, very informative.

[jragusa]

natural=fjord is discouraged on the wiki page in favour to bay=fjord. Since natural=bayis already supported (#3144), we can exclude fjord from the above todo list.

[jeisenbe]

That’s right.

We could still add a special rendering for natural=bay with bay=fjord mapped as a linear way, with the text following the way. On Sat, Oct 20, 2018 at 6:03 AM Jérémy Ragusa notifications@github.com wrote:

natural=fjord is discouraged on the wiki page https://wiki.openstreetmap.org/wiki/Tag:bay%3Dfjord in favour to bay=fjord. Since natural=bayis already supported (#3144 https://github.com/gravitystorm/openstreetmap-carto/pull/3144), we can exclude fjord from the above todo list.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gravitystorm/openstreetmap-carto/issues/788#issuecomment-431498142, or mute the thread https://github.com/notifications/unsubscribe-auth/AoxshBp0wOLZZUmMwbfwrBOu_EinI9J7ks5umj4RgaJpZM4CRmLr .

[Tomasz-W]

Task list:

• [x] natural=cape #3148 -> PR https://github.com/gravitystorm/openstreetmap-carto/pull/3452
• [ ] natural=ridge #1148 #2774
• [ ] natural=valley
• [ ] bay=fjord (https://github.com/gravitystorm/openstreetmap-carto/issues/788#issuecomment-431508369)

[geozeisig]

Please render the label for ocean and sea in the same way as bay. For ocean the tag place=ocean is used and for a large sea place=sea (Do you believe that place is right here?) For example for the Mediterranean Sea there is a node. I think that's too little. We should use a polygon. But if we use the coastline, even a relation will be overloaded. We should draw a polygon that roughly represents the coastline and whose segments are about 10 km. But which tag is right here? Or do we use bay or strait?

[jragusa]

@geozeisig related to #1982 ?

[Tomasz-W]

@geozeisig There is already a ticket for this issue: https://github.com/gravitystorm/openstreetmap-carto/issues/2278

[Adamant36]

We could still add a special rendering for natural=bay with bay=fjord mapped as a linear way, with the text following the way.

@jeisenbe, it says on the wiki that they aren't suppose to be mapped as liner ways. Any other thoughts on possible rendering? Is there a reason they couldn't be rendered the same as capes with no fill and the name in the middle of the area?

[Adamant36]

Anyone have any idea how valleys or ridges could be rendered? I thought there was a PR for ridge rendering that was closed that could be used as an example, but I can't seem to find it. Maybe it was for something else.

[kocio-pl]

There was #1148 and #2774, you can check it.

[Adamant36]

Thanks. I looked through #1148 before and didn't see it. Now I notice its issue #2138 though.

[jeisenbe]

Re: Fjords

... rendered the same as capes with no fill and the name in the middle of the area

Fjords should be tagged natural=bay and bay=fjord, so they should currently render in this way if tagged as a closed way, multi-polygon, or node.

The wiki page for bay=fjord suggested tagging this on a linear way for long fjords, until last month. On Nov 19 user @Geozeisig deleted the option to map as a linear way from the wiki page, with the explanation that “tagging on ways does not render.”

I’ve reverted this change to the wiki.

We could add a text label that follows the shape of the way (just like river lables), if there is a linear way tagging. This will be the best-looking option for long, narrow fjords.

Joseph

[matkoniecz]

I’ve reverted this change to the wiki.

Thanks, "tagging on ways does not render.” used as a sole reason is a clear case of tagging for render.

[jragusa]

For the record: there is a new discussion about peninsula in the tagging list

[eehpcm]

natural=valley appears to have fallen through the gaps (see the crossed-off items in the first post in this thread and issue #2774).

In my local area there are a lot of named valleys. I've tagged a few of them with natural=valley but the labels don't render. In this part of Wales, valley names often serve the same purpose, and are used the same way, as place=neighbourhood in England - they are distinct regions (albeit long and narrow) within a larger named locality and are used by locals to refer to those regions.

I could replace it with place=neighbourhood, but that isn't for use on linear ways and doesn't convey that the place is, in fact, a valley. I could replace it with place=locality, but over on the tagging mailing list @jeisenbe suggested trying to find more specific tagging to use instead of that. So here I am, asking if labels can be rendered for place=valley.

[jeisenbe]

Thank you for mentioning this, @eehpcm. Previously there was a PR that attempted to render name labels for valleys mapped as linear ways, along with ridges and related features, with a label following the line of the way, but it was closed. See #2138 It may be easier to just label valleys with a standard text label at the midpoint of the way; this will prevent the temptation to tag as place=locality.

[eehpcm]

@jeisenbe

Previously there was a PR that attempted to render name labels for valleys mapped as linear ways, along with ridges and related features, with a label following the line of the way, but it was closed. See #2138

Ugh! That is a large, catering-size can of worms. The label following the line of the way is a nice touch, but not strictly necessary. And whether the labels follow the line of the way or not, it seems there was no agreement about anything.

It may be easier to just label valleys with a standard text label at the midpoint of the way;

A standard text label? There's a tag just for adding a label? What is it?

I agree that place=locality is often wrong because it is for uninhabited areas. One of the valleys I've mapped is uninhabited, but is mentioned on descriptions of walking routes. The other is inhabited - I've seen people on facebook referring to it in the same way they would a neighbourhood - as in "I think Briony moved to a house in Cwm Plysgog" (Valley of the Plysgog). They are topographical features which people refer to by name for one reason or another, which is why they're labelled in the OS_OpenData_StreetView layer. I'm not saying we should slavishly do whatever the Ordnance Survey does, but I don't think we should assume they label features unnecessarily.

[jeisenbe]

A standard text label? There's a tag just for adding a label?

No. I’m sorry that I wasn’t clear.

I meant that the name could be rendered as a horizontal black text label using the standard font (not bold or italic) centered on the node or the center of the way. This would similar to the rendering of other landform features such as natural=cape or place=island.

[eehpcm]

@jeisenbe

I meant that the name could be rendered as a horizontal black text label using the standard font (not bold or italic) centered on the node or the center of the way. This would similar to the rendering of other landform features such as natural=cape or place=island.

That would be better than nothing. :) I don't see a need for rendering the way itself, and it would probably be confusing if it were rendered. However, I suggest that the label be oriented in the general direction of the way. See Cwm Morganau in the OS_OpenData_StreetView layer. There is no need to curve the text along the way (as is done with road and river names), just get the general direction. OTOH, calculating a "general" direction from a contorted way might be a difficult algorithm to get right, and you already have code for curving labels of roads and rivers.

[jeisenbe]

Changed title since natural=valley is the only remaining feature on the list. I believe it would be worth trying a simple label-only rendering for valleys. This would at least prevent tagging them as place=locality

[eehpcm]

@jeisenbe

Test cases to see how they look (and how they compare with OS OpenData StreetView):

Cwm Plysgog

Cwm Rhew-erwyll

Cwm Morgenau

The first two should look OK(ish) whether the label is horizontal or follows the valley. The third is not going to look good (and be misleading) unless the label follows the valley.

[jeisenbe]

Thank you for the examples.

The third is not going to look good (and be misleading) unless the label follows the valley.

Looking at Cwm Morgenau, it won't be much more misleading that the rendering of the linear woodland to the west

(the valley is the orange line, the wood has the green text label west of the river)

Note that the natural=wood area named Allt Pen-lan (which is to the north and west of the river) is rendered with a label placed near the center, even though the wood is long, narrow and curved. A hand-crafted map would also want to label this with a curve: https://www.openstreetmap.org/way/638346143#map=16/52.0591/-4.6115

While following the OSM way with the label will be better in some cases, a non-oriented label at the center of the valley will work in most cases.

[eehpcm]

@jeisenbe

Looking at Cwm Morgenau, it won't be much more misleading that the rendering of the linear woodland to the west

Actually, a horizontal label for the valley would be more misleading, because woods are rendered objects and valleys are not. So if you see a patch of green wood with a label, you know the maximum possible extent and shape of the wood. Maximum possible extent and shape because it may be a named chunk of a larger area of woodland, as Allt Pen-lan is (actually, I've probably made that named chunk extend more to the north than it really does, and if I fixed that the label would render closer to where OS OpenData StreetView puts it). With a valley, that doesn't render, all you have to go on is the label itself. The two situations aren't really comparable.

I know you already have code that places labels so they follow ways because you do that with roads and rivers. I know this means labelling valleys would consume more resources at render time, but at least you don't have to write such code from scratch (I'd hope it's a subroutine/procedure call but copy/paste is still easier than writing from scratch). Roads and rivers do render, so the label following the way isn't vital, it just makes the map look better. When labelling an unrendered valley, the label is all you have to go on.

While following the OSM way with the label will be better in some cases, a non-oriented label at the center of the valley will work in most cases.

Assuming the valley doesn't meander much (which it may), a non-oriented label will work (even for very small values of "work") in only 50% of cases. It will work for the 50% of cases where the valley deviates no more than 45 degrees from horizontal. It will fail for the 50% of cases where the valley deviates no more than 45 degrees from vertical. Even with the most generous definition of "work" it's wrong half the time.

All that said, a non-oriented label is better than no label at all, and I'll settle for it if that's all I can get. But if you do add the label, people are more likely to use the tag, and I'd expect that eventually you will get some of those people asking for oriented labels.

[jeisenbe]

With a valley, that doesn't render, all you have to go on is the label itself.

That's why it may be a problem to render just the label, oriented along the way. This could encourage mappers to draw "labeling geometries", based on how they want the label to look on openstreetmap.org, rather than based on a verifiable feature on the ground.

For valleys that contain rivers or streams, usually that would be the lowest spot, so that could be a verifiable place to draw the natural=valley way. However, I notice in your examples that the valley does not exactly follow the waterway. I've seen this commonly in other valleys drawn as ways: the mapper often uses a simplified line, instead of following the thalweg (line of lowest elevation).

Since natural=valley ways are not being drawn in a particularly consistent way, we would not want to contribute to this problem and encourage more "mapping for the renderer". But valleys are real, physical geography features, even if it is difficult to map their boundaries or exact course, and by placing a label on the midpoint of the line, or the node, we can provide a basic idea of the centerpoint of the valley. This is better than mappers using place=locality - which can include valleys in it's definition, unfortunately.

If mappers start using natural=valley in a more consistent way, for example by attempting to follow the lowest ground in the valley (usually the same as the waterway, if there is one), we could reconsider using those geometries for labeling purposes.

I'm aware that the rendering will look nicer when using the ways - in many cases, if we just let mappers directly draw the size and location of our labels they would come out better, but we have a responsibility not to push mappers to do the work of renderers for them.

[eehpcm]

@jeisenbe

That's why it may be a problem to render just the label, oriented along the way. This could encourage mappers to draw "labeling geometries", based on how they want the label to look on openstreetmap.org, rather than based on a verifiable feature on the ground.

You appear to assume that many mappers would wish the label to look like anything other than the course of the valley. I think that most mappers, like myself, would like the label to follow the valley but accept small imperfections introduced by the rendering process. I think what is more likely if the label is non-oriented is that they will trim the valley length or course to try to get the label in the centre of the valley (essentially twiddling the line to get the same result as using a node).

For valleys that contain rivers or streams, usually that would be the lowest spot, so that could be a verifiable place to draw the natural=valley way. However, I notice in your examples that the valley does not exactly follow the waterway. I've seen this commonly in other valleys drawn as ways: the mapper often uses a simplified line, instead of following the thalweg (line of lowest elevation).

I suspect the other mappers did it that way for the same reason I did: that's what the wiki suggests. The river or stream will almost always follow the thalweg, but the valley is often a good deal wider than the waterway and the waterway meanders within it. This is why the wiki says "Note that valleys and waterways are not necessarily congruent. Rivers are often meandering. There may be multiple branches of the river, or no river at all. Therefore, you better ignore waterways in U-shaped valleys, and go for the middle line of the valley bottom instead." That is what I attempted to do, as best I could interpret aerial images and the OpenTopoMap layer.

Since natural=valley ways are not being drawn in a particularly consistent way, we would not want to contribute to this problem and encourage more "mapping for the renderer".

I am not convinced that they are being drawn inconsistently. I think it likely that the discrepancy is in your expectation that the valley follow the thalweg and mappers trying to map the centre of the valley as the wiki tells them to. It's easier to map the thalweg if the waterway is already there, just follow the waterway. It's more work to try and figure out the centre of the valley. And, right now, people most definitely aren't tweaking the valley in order to affect label placement because there are no labels.

If mappers start using natural=valley in a more consistent way, for example by attempting to follow the lowest ground in the valley (usually the same as the waterway, if there is one), we could reconsider using those geometries for labeling purposes.

I believe they already are using them consistently. I would have taken the easy way out and followed the watercourse had not the wiki persuaded me to put a little more effort in to do the job properly. But even if I'd decided to avoid the watercourse just because I didn't want to superimpose the valley on it, I'd have placed the valley close by and following a somewhat smoother path.

Nobody has abused the tag to place a label because there currently are no labels. Might they do that in the future in order to get around the renderer suppressing a label because of space restrictions? Maybe, but there are already many other opportunities for them to do things like that if they're so inclined.

[jeisenbe]

It's more work to try and figure out the centre of the valley.

I agree. From my experience trying to map some valleys here in Indonesia with linear ways, it's quite hard to decide on where the center of a wide valley should be. 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? Unfortunately this isn't defined.

Nobody has abused the tag to place a label because there currently are no labels.

The labels are shown in other styles like Opentopomap, which show contour lines and hillshading. 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.

[eehpcm]

@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]

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]

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:

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

• 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]

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]

@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.