Add rendering for waterway=waterfall #3164

meased · 2018-04-03T02:57:09Z

Fixes #336

Adds icon and name rendering for waterway=waterfall.

Before

After

Various zoom levels:

(https://www.openstreetmap.org/#map=16/45.5762/-122.1140)

This uses the waterfall v3 icon from @gpsvisualizer (I did some slight pixel alignment) with both icon and text using the standard water text color.

I'm not sure why cliffs/highways are rendering on top of the waterfall icon. Can anyone offer some advice here? Is this just kosmtik?

I'm also not too happy with the low zoom. I think waterfalls are prominant features that primarily occur in rural areas and deserve to be rendered fairly low, but I'd like to try rendering only those with names at lower zooms.

kocio-pl · 2018-04-03T08:56:08Z

What about rendering height? I guess this would be the same code as in #3158 (comment).

kocio-pl · 2018-04-03T09:33:48Z

Please remember to add the links to the testing places, so other people can test it too.

kocio-pl · 2018-04-03T09:58:24Z

I think height is an important factor to consider initial zoom level - see for example this one (just 6.1 m):

https://www.openstreetmap.org/node/4247958331#map=19/45.57022/-122.12423

This is probably the testing place:

https://www.openstreetmap.org/node/1017565710#map=16/45.5758/-122.1210

meased · 2018-04-03T16:38:18Z

It may not be too hard to render height, assuming I can lift the code from natural=peak or towers. I'll give it a go.

jragusa · 2018-04-03T19:38:20Z

Please note that icon is rendered below the cliff features which decreases its readability. This is well visible in picture 3 and the combination of cliff with waterfall is not so rare. The icon of the lower waterfall is even nearly unreadable.

Additional question: is it normal to separate waterfall line 2155 from line 2164 ?

meased · 2018-04-03T20:44:40Z

No, that's probably not normal, I'll fix it.

As mentioned above I am aware that cliffs and highways are overlapping the icon and I suspect that it's some weirdness with kosmtik. Partly why this PR is WIP. Suggestions anyone?

jragusa · 2018-04-04T15:40:56Z

@meased Oops I missed you have already mentioned this. I think that water features are localised in a lower layer than cliffs.

kocio-pl · 2018-04-04T16:13:55Z

It may not be too hard to render height, assuming I can lift the code from natural=peak or towers. I'll give it a go.

Just to be clear: I think also about setting initial zoom related to the height, just like we do with masts and towers, for example:

openstreetmap-carto/amenity-points.mss

Lines 371 to 375 in 94fe461

    
           [feature = 'man_made_mast'] { 
        
             [zoom >= 15][height > 80], 
        
             [zoom >= 16][height > 40], 
        
             [zoom >= 17][height > 20], 
        
             [zoom >= 18] {

meased · 2018-04-04T16:54:05Z

The layering has been sorted out, I had added waterfalls to the water-barriers-points class, which is lower than highways (assumably to allow roads on top of dams). I moved it to the amenity-point class and everything looks good now.

I also got the height filtering working so we will be able to show taller waterfalls at lower zoom. I believe sorting by height is also working (lifted from natural=peak) so when two waterfalls overlap the taller will be preferred, though my test area only has one case of this.

I still would like to get the height rendered in the name like peaks.

I'll post some updated sample images later...

meased · 2018-04-05T02:07:14Z

Height rendering is working:

Zoomed in shows all waterfalls:

From this area: https://www.openstreetmap.org/#map=15/45.6227/-121.8954

The original area to show current icon rendering (none of these have height here, I recently added height to a handful of them for test rendering but have to reload my database to get it):

meased · 2018-04-05T02:19:24Z

Here's a question: should waterfalls have an oblique font? Every other natural water feature is oblique except springs, maybe waterfalls should follow suit.

gpsvisualizer · 2018-04-05T03:57:53Z

That's a good question. It seems like oblique fonts are usually used on areas, whereas single points like peaks & springs tend to have non-oblique fonts. (I'm sure there are exceptions.) At any rate, I prefer the non-oblique font in this case.

meased · 2018-04-06T02:20:33Z

Currently using this filter:

[feature = 'waterway_waterfall'] {
     [zoom >= 13][height > 20],
     [zoom >= 14][height > 10],
     [zoom >= 15][name != null],
     [zoom >= 16] {

Which will show waterfalls

Over 20m at zoom 13+
Over 10m at 14+
Any named waterfall at 15+
All waterfalls at 16+

In action at https://www.openstreetmap.org/#map=15/45.5756/-122.1161:
12

13 (large waterfalls appear at the same time as streams, peaks, and wilderness huts)

14

15

16

17

Unnamed waterfall at the highest zoom level it would be displayed in city context (the only one I could find):
https://www.openstreetmap.org/#map=16/45.4933/-122.9500

Named water fall in city context (this one is named so it would appear at zoom 15, but a city label eclipses it in this case and I couldn't find another case):
https://www.openstreetmap.org/#map=16/45.3569/-122.6047
16

17

Large river waterfall (this one would be in higher zoom levels if it had a height tag):
https://www.openstreetmap.org/#map=16/45.3513/-122.6192

kocio-pl · 2018-04-06T02:31:44Z

I like the system you invented (height+name) and the testing you've made. I will try to make independent testing soon, but it looks really good.

gpsvisualizer · 2018-04-06T05:34:34Z

Would it be possible to have smaller waterfalls appear on the map sooner (i.e., at lower zoom levels), but without their label? That way they wouldn't clutter the map much, but there'd be an indication that something's there.

kocio-pl · 2018-04-06T13:06:08Z

project.mml

@@ -1571,13 +1574,18 @@ Layer:
                  WHEN tags->'ele' ~ '^-?\d{1,4}(\.\d+)?$' THEN (tags->'ele')::NUMERIC
                  ELSE NULL
                END
+              WHEN "waterway" IN ('waterfall') THEN
+                CASE
+                  WHEN tags->'height' ~ '^\d{1,4}(\.\d+)?$' THEN (tags->'height')::NUMERIC


Check this solution please for height values with "m" unit: #3158 (comment)

Right now a trailing "m" would not match the regular expression and would be dropped as if there were no height tag.

Not hard to parse around the "m", but looking at the wiki (https://wiki.openstreetmap.org/wiki/Key:height), height may be in any of the following formats:

123

123.4

123 m

123.4 m

12'

12'3"

Supporting feet and inches will take a little parsing and unit conversion, and would also affect the tower code. (The tower code could also use a fix for this.)

Wow... I would have thought feet or feet/inches was simply not allowed! I know that meters are required in the "ele" tag.

How many waterfalls are tagged with the "'" unit? If it's not too many, maybe we should just convert them all to meters and be done with it.

EDIT: In the U.S., there were 28. Plus a handful with "ft" or "feet." I've fixed them all.

My suggestion would be to make this PR about waterfalls and add support for feet/inches in another PR (if we decide to do it at all).

Wether or not to support an "m" unit in the string doesn't matter much to me. This handles all of the above cases except feet/inches:

WHEN tags->'height' ~ '^\d{1,4}(\.\d+)?\s?m?$' THEN (SUBSTRING(tags->'height', '^(\d{1,4}(\.\d+)?)\s?m?$'))::NUMERIC

kocio-pl · 2018-04-06T23:16:02Z

Thanks to @rrzefox we can now test rendering around the planet:

http://bl.ocks.org/matthijsmelissen/raw/af7a602c222dbf1ff1a2c0d84ed755b7/#13.00/45.5565/-122.1355

…alls

kocio-pl · 2018-04-08T20:18:27Z

project.mml

@@ -2102,13 +2119,15 @@ Layer:
            access,
            CONCAT(
                name,
-                CASE WHEN name IS NOT NULL AND elevation IS NOT NULL THEN E'\n' ELSE NULL END,
-                CASE WHEN elevation IS NOT NULL THEN CONCAT(REPLACE(ROUND(elevation)::TEXT, '-', U&'\2212'), U&'\00A0', 'm') ELSE NULL END
+                CASE WHEN elevation IS NOT NULL THEN CONCAT(E'\n', REPLACE(ROUND(elevation)::TEXT, '-', U&'\2212'), U&'\00A0', 'm') ELSE NULL END,


I think such change should be made in a separate PR, since it's about different objects. It also needs discussing, because it's not clear for me what it really does.

I made a mistake here.

This is the code that appends the elevation text to the name column. It does need to be modified by this PR because now both elevation and height are rendered, whereas before it was only elevation.

I tried to simplify the expression by forcing a newline before the elevation/height text, but that doesn't work when the name is null. I have put it back to the original structure.

I meant only this line of code, but now it's the same as before, so no problem here.

sommerluk · 2018-04-09T14:43:51Z

Could (\sm) be replaced by ( m) to force U+0020 as the only valid codepoint before m?

meased · 2018-04-10T00:50:09Z

Could (\sm) be replaced by ( m) to force U+0020 as the only valid codepoint before m?

Seems like a good idea. Done.

kocio-pl · 2018-04-17T02:19:35Z

Current tagging of Niagara Falls is incomplete (no height), but detailed (specific names), so it's visible from z15:

The highest waterfall (Angel Falls) is visible from z13:

I have also tested few others and they all look sane, also the presented examples are OK, so thanks for all the work, especially for subsequent tuning!

gpsvisualizer · 2018-04-25T05:40:50Z

Thanks, everyone, for getting this done!

Add rendering for waterway=waterfall

e24cd8b

Tomasz-W mentioned this pull request Apr 3, 2018

Code needed to render prepared icons [meta ticket] #3105

Closed

13 tasks

David Mease and others added 3 commits April 3, 2018 13:57

Optimize SVG

814dcfd

Query waterfall along with other water barriers

96ecb6b

Use amenity-points layer, add height filter

7f62036

Add height rendering

3220729

Adjust filtering/filter by name

16ec966

kocio-pl reviewed Apr 6, 2018

View reviewed changes

meased added 4 commits April 6, 2018 22:12

Ignore meter units in height tag

8989cfb

Merge https://github.com/gravitystorm/openstreetmap-carto into waterf…

a79d579

…alls

Merge https://github.com/gravitystorm/openstreetmap-carto into waterf…

d5148bb

…alls

Change regex: 3 digits, force space before units

b2bb26d

kocio-pl reviewed Apr 8, 2018

View reviewed changes

BUGFIX: Don't add \n between name/height when name is null

1e63cf0

Only allow space character before units

1a6ed4d

meased changed the title ~~Add rendering for waterway=waterfall [WIP]~~ Add rendering for waterway=waterfall Apr 10, 2018

kocio-pl merged commit f45d7a0 into gravitystorm:master Apr 17, 2018

meased deleted the waterfalls branch April 17, 2018 15:56

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add rendering for waterway=waterfall #3164

Add rendering for waterway=waterfall #3164

meased commented Apr 3, 2018 •

edited

Loading

kocio-pl commented Apr 3, 2018

kocio-pl commented Apr 3, 2018

kocio-pl commented Apr 3, 2018

meased commented Apr 3, 2018

jragusa commented Apr 3, 2018

meased commented Apr 3, 2018

jragusa commented Apr 4, 2018

kocio-pl commented Apr 4, 2018

meased commented Apr 4, 2018

meased commented Apr 5, 2018

meased commented Apr 5, 2018

gpsvisualizer commented Apr 5, 2018

meased commented Apr 6, 2018

kocio-pl commented Apr 6, 2018

gpsvisualizer commented Apr 6, 2018

kocio-pl Apr 6, 2018

meased Apr 7, 2018

gpsvisualizer Apr 7, 2018 •

edited

Loading

meased Apr 7, 2018

kocio-pl commented Apr 6, 2018

kocio-pl Apr 8, 2018

meased Apr 8, 2018

kocio-pl Apr 8, 2018

sommerluk commented Apr 9, 2018

meased commented Apr 10, 2018

kocio-pl commented Apr 17, 2018

gpsvisualizer commented Apr 25, 2018

Add rendering for waterway=waterfall #3164

Add rendering for waterway=waterfall #3164

Conversation

meased commented Apr 3, 2018 • edited Loading

kocio-pl commented Apr 3, 2018

kocio-pl commented Apr 3, 2018

kocio-pl commented Apr 3, 2018

meased commented Apr 3, 2018

jragusa commented Apr 3, 2018

meased commented Apr 3, 2018

jragusa commented Apr 4, 2018

kocio-pl commented Apr 4, 2018

meased commented Apr 4, 2018

meased commented Apr 5, 2018

meased commented Apr 5, 2018

gpsvisualizer commented Apr 5, 2018

meased commented Apr 6, 2018

kocio-pl commented Apr 6, 2018

gpsvisualizer commented Apr 6, 2018

kocio-pl Apr 6, 2018

Choose a reason for hiding this comment

meased Apr 7, 2018

Choose a reason for hiding this comment

gpsvisualizer Apr 7, 2018 • edited Loading

Choose a reason for hiding this comment

meased Apr 7, 2018

Choose a reason for hiding this comment

kocio-pl commented Apr 6, 2018

kocio-pl Apr 8, 2018

Choose a reason for hiding this comment

meased Apr 8, 2018

Choose a reason for hiding this comment

kocio-pl Apr 8, 2018

Choose a reason for hiding this comment

sommerluk commented Apr 9, 2018

meased commented Apr 10, 2018

kocio-pl commented Apr 17, 2018

gpsvisualizer commented Apr 25, 2018

meased commented Apr 3, 2018 •

edited

Loading

gpsvisualizer Apr 7, 2018 •

edited

Loading