Fix low priority layers #3874

jeisenbe · 2019-09-07T05:14:01Z

Fix low priority layers

Fixes #3860

Changes proposed in this pull request:

Remove duplicate parking, motorcycle_parking, bicycle_parking, wayside_shrine, wayside_cross and man_made_cross from amenity-points layer.
Create text-low-priority layer to render text labels of parkings and wayside shrines/crosses
Move parking_entrance to low-priority-point layer, to match other parking features
Fix rendering text labels for parking on nodes
~~Adjust initial zoom level for amenity=parking nodes from z17 to z18 to match bicycle_parking and motorcycle_parking - (the code would be more complex otherwise).~~ - removed
Use ST_PointOnSurface to combine amenity-low-priority and amenity-low-priority-poly into one layer, and re-use the same SQL table for low-priority text labels layer.

Test rendering:

https://www.openstreetmap.org/#map=18/-12.35622/130.88415

Before

~~After~~

After (ST_PointOnSurface):

Move parking_entrance to low-priority, remove parking duplicate, Remove duplicate wayside_cross rendering, Make #text-low-priority section Currently amenity=parking is duplicated in the amenity-points layer and the amenity-low-priority layers, this commit removes the duplicate from amenity-points. Also amenity=parking_entrance is moved from amenity-points to the amenity-low-priority layers to match the other parking features New low priority text layers are created as well, and text code is fixed so parking lot text renders on nodes at >z18 now

jeisenbe · 2019-09-07T07:24:57Z

I've also created another branch which has the same changes, but with both amenity-low-priority point and poly layers combined into one with ST_PointOnSurface, and the text layer based off of this.

See: https://github.com/jeisenbe/openstreetmap-carto/tree/parking-combined and commit f438059

I can add that commit to this PR if desired, or we can discuss it later, since it's not required to fix these bugs.

jeisenbe · 2019-09-07T07:29:58Z

Rendering with ST_PointOnSurface; position is slightly less central:

imagico · 2019-09-07T17:05:47Z

I think if you change this you should also use the same approach as in amenity-points. If ST_PointOnSurface() leads to acceptable label positions is a different issue - if it is good enough for amenity-points it is also good enough for low priority. 😉

In any case please make sure the rendering rules are the same as before and any change in actual rendering behavior is made separately. From a quick look it seems you are not rendering parkings with way_pixels<=900 any more, not even at z18+.

kocio-pl · 2019-09-07T17:45:56Z

As a general note: I was wondering what is the difference between the weighted-centroid algorithm carefully tailored by @talaj for Mapnik and stock ST_PointOnSurface() function. Sadly the effect is disappointing for me in many places. However for me it is still acceptable (good enough, as you said), so I think we should stick to this at least to avoid double position rendering.

talaj · 2019-09-07T19:48:51Z

According to this answer ST_PointOnSurface() works the same as the former interior algorithm in Mapnik was working. What is the problem with the new interior algorithm?

kocio-pl · 2019-09-07T21:44:21Z

It was both substantially higher speed and much less code complexity - see #3712 (comment).

Hm, it would be great to deploy new algorithm directly in PostGIS too, if possible. What do you think about it?

jeisenbe · 2019-09-08T01:50:06Z

I think if you change this you should also use the same approach as in amenity-points

Done. I've pushed the commit that was shown.

please make sure the rendering rules are the same as before and any change in actual rendering behavior is made separately. From a quick look it seems you are not rendering parkings with way_pixels<=900 any more, not even at z18+.

D@mn it Jim, I'm a doctor, not a computer engineer!

Oops. I'll fix that.

(If we reconsider this, should teeny tiny parking smaller than 30 x 30 pixels have an icon or text label even at z18? I suspect z18 was picked back before we had z19 rendered on openstreetmap.org - Perhaps this should be changed to z19 in a separate PR.)

Always show amenity=parking icon at z17 and other parking icons at z18 even if area is too small Show text at z18 and above always. This matches the previous behavior.

jeisenbe · 2019-09-08T02:52:14Z

it seems you are not rendering parkings with way_pixels<=900 any more, not even at z18+

I've pushed a new commit which fixes this, and tested the rendering. Should be ready for review/merge now.

Fix rendering of text labels for wayside_shrine by adding text-dy 10

jeisenbe · 2019-09-08T04:47:51Z

Ok, now it's ready: latest commit removes duplicate rendering of wayside_shrine and adds text-dy: 10 needed for rendering of wayside_shrine name labels.

Now all the features in the amenity-low-priority layer should only render in this layer, I believe, except for waste_disposal areas which were intentionally treated differently than nodes.

talaj · 2019-09-08T06:02:29Z

it would be great to deploy new algorithm directly in PostGIS too

@kocio-pl It is possible. GEOS library should accept it. Once it's there, it should be doable to convince PostGIS to use it.

imagico

Overall looks fine at a quick glance - except for the mentioned things.

More generally speaking the whole concept of low and high priority POIs does not really work very well if the low priority ones start appearing at z10 already and then - because they are low priority - vanish as new POI types appear in the high priority layer as you zoom in. But that is a different can of worms obviously.

amenity-points.mss

project.mml

kocio-pl · 2019-09-08T13:30:43Z

GEOS library should accept it. Once it's there, it should be doable to convince PostGIS to use it.

Considering weak choices the old algorithm is making, I think that would be a win/win for us and general audience of GEOS users (which includes some important projects: https://en.wikipedia.org/wiki/JTS_Topology_Suite#Applications_Using_GEOS ).

The only question is who could do it. @talaj Would you like to try that or you prefer not to?

talaj · 2019-09-08T13:56:55Z

Would you like to try that or you prefer not to?

@kocio-pl I would like to do that but my spare time and energy is quite limited, so I cannot promise anything.

kocio-pl · 2019-09-08T14:01:01Z

I perfectly understand you, there's no need to make any promises. If you would like to use some help to make it happen, don't hesitate to ask.

jeisenbe · 2019-09-08T14:54:24Z

I've pushed a new commit which uses an id based selector for #text-low-priority and #amenity-low-priority, since there are no longer separate point and polygon layers.

jeisenbe · 2019-09-11T13:05:43Z

@imagico the changes you requested have been made. Ready to approve?

imagico

Looks good - but there is some weirdness taken over from the previous zoom level logic that does not make a lot of sense.

One potential problem this change could create is that oneway arrows will have priority over parking symbols which is not really such a sensible prioritization. But that is definitely a minor issue compared to what this fixes.

imagico · 2019-09-16T20:50:58Z

amenity-points.mss

+  [feature = 'amenity_bicycle_parking'],
+  [feature = 'amenity_motorcycle_parking'],
+  [feature = 'amenity_parking_entrance'] {
+    [zoom >= 10][way_pixels > 900],


While this is not introduced by your change this is weird - for large parking labels seems to start at z10 while the symbol does not start before z14 - which does not make much sense.

jeisenbe · 2019-09-16T22:25:02Z

Thanks! Yes, I noticed that too. I think we can limit them both to >=z14 but I will make a separate PR. Probably we should open an issue to discuss the low-priority layers in general.

This change allows points to be rendered the same as areas with way_pixels=0, simplifiying the CSS code

jeisenbe · 2019-09-18T07:54:48Z

I've pushed a new commit which uses COALESCE(way_area/NULLIF(POW(!scale_denominator!*0.001*0.28,2),0), 0) AS way_pixels as in PR #3878 so that text labels render on parking nodes again at z18 and higher. I've tested it. @imagico, would you have the time to review this new commit?

imagico · 2019-09-18T22:15:02Z

There is no way_pixels condition on z18 and above for parkings so i don't think this change makes sense here.

jeisenbe · 2019-09-18T23:27:36Z

OK, I realize now that the prior commits had already fixed the rendering on nodes, which was broken when done from the amenity-points layer. I was thinking that it would be good to use the same code COALESCE(way_area/NULLIF(POW(!scale_denominator!*0.001*0.28,2),0), 0) AS way_pixels in the amenity-low-priority layer so that in the future, contributors will not be confused why this layer works differently than amenity-points.

But that's not really necessary for this PR, so I will revert to the previously reviewed commit.

Add gravitystorm#3874, gravitystorm#3879 and gravitystorm#3847

Parking had previously been rendered in both amenity-points and amenity-low-priority. Recently PR gravitystorm#3874 had consolidated parking rendering in low-priority only, but this leads to problems when there is a building or an address on the same feature This commit moves parking back to the amenity-points layer, but near the end. The minzoom for text-low-priority is now changed back to z17

…nd fix initial zoom level (#3923) * Move parking back to amenity-points layers Parking had previously been rendered in both amenity-points and amenity-low-priority. Recently PR #3874 had consolidated parking rendering in low-priority only, but this leads to problems when there is a building or an address on the same feature The minzoom for text-low-priority is changed back to z17 * Change parking text intial zoom to z14 In PR #3612 it was planned to render parking from z14 only, however this was not yet changed for the text labels, only for the icon. * Change way_pixels limit for parking icon and text Start showing icon at 750 pixels instead of 900, but don't show text label till 3000 way_pixels, as with most other features

jeisenbe added 2 commits September 7, 2019 14:04

Combine low-priority-poly and point layers

f438059

Show parking icon/text at z18, parking icon at z17

b707e6d

Always show amenity=parking icon at z17 and other parking icons at z18 even if area is too small Show text at z18 and above always. This matches the previous behavior.

jeisenbe added bug POI text labels Sep 8, 2019

Move historic_wayside_shrine to low-priority only

9401f0d

Fix rendering of text labels for wayside_shrine by adding text-dy 10

imagico requested changes Sep 8, 2019

View reviewed changes

amenity-points.mss Outdated Show resolved Hide resolved

project.mml Show resolved Hide resolved

Remove class amenity- and text-low-priority

c434e3f

jeisenbe requested a review from imagico September 11, 2019 13:05

imagico approved these changes Sep 16, 2019

View reviewed changes

jeisenbe mentioned this pull request Sep 17, 2019

Release v4.23.0 #3889

Closed

Coalesce way_area NULL as way_pixels 0

96e8b44

This change allows points to be rendered the same as areas with way_pixels=0, simplifiying the CSS code

Revert last commit

ab9fa58

jeisenbe merged commit 792a6c5 into gravitystorm:master Sep 20, 2019

jeisenbe deleted the parking branch September 20, 2019 04:24

jeisenbe added a commit to jeisenbe/openstreetmap-carto that referenced this pull request Sep 20, 2019

Update v4.22.0 changelog

64953b7

Add gravitystorm#3874, gravitystorm#3879 and gravitystorm#3847

This was referenced Sep 22, 2019

Names of POIs instead of their housenumbers #962

Closed

Switch to ST_PointOnSurface? #1644

Closed

jeisenbe mentioned this pull request Oct 2, 2019

amenity=parking icon no longer rendered on buildings #3908

Closed

kocio-pl mentioned this pull request Oct 4, 2019

Migration to vector tiles #3201

Open

jeisenbe mentioned this pull request Oct 5, 2019

Move parking back to amenity-points layers, change way_pixels limit and fix initial zoom level #3923

Merged

kocio-pl mentioned this pull request Nov 8, 2019

Label rendering with ST_PointOnSurface is not always optimal #3857

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix low priority layers #3874

Fix low priority layers #3874

jeisenbe commented Sep 7, 2019 •

edited

Loading

jeisenbe commented Sep 7, 2019 •

edited

Loading

jeisenbe commented Sep 7, 2019

imagico commented Sep 7, 2019

kocio-pl commented Sep 7, 2019

talaj commented Sep 7, 2019

kocio-pl commented Sep 7, 2019

jeisenbe commented Sep 8, 2019

jeisenbe commented Sep 8, 2019

jeisenbe commented Sep 8, 2019

talaj commented Sep 8, 2019

imagico left a comment

kocio-pl commented Sep 8, 2019 •

edited

Loading

talaj commented Sep 8, 2019

kocio-pl commented Sep 8, 2019

jeisenbe commented Sep 8, 2019

jeisenbe commented Sep 11, 2019

imagico left a comment

imagico Sep 16, 2019

jeisenbe commented Sep 16, 2019 via email

jeisenbe commented Sep 18, 2019 •

edited

Loading

imagico commented Sep 18, 2019

jeisenbe commented Sep 18, 2019

Fix low priority layers #3874

Fix low priority layers #3874

Conversation

jeisenbe commented Sep 7, 2019 • edited Loading

Changes proposed in this pull request:

Test rendering:

jeisenbe commented Sep 7, 2019 • edited Loading

jeisenbe commented Sep 7, 2019

imagico commented Sep 7, 2019

kocio-pl commented Sep 7, 2019

talaj commented Sep 7, 2019

kocio-pl commented Sep 7, 2019

jeisenbe commented Sep 8, 2019

jeisenbe commented Sep 8, 2019

jeisenbe commented Sep 8, 2019

talaj commented Sep 8, 2019

imagico left a comment

Choose a reason for hiding this comment

kocio-pl commented Sep 8, 2019 • edited Loading

talaj commented Sep 8, 2019

kocio-pl commented Sep 8, 2019

jeisenbe commented Sep 8, 2019

jeisenbe commented Sep 11, 2019

imagico left a comment

Choose a reason for hiding this comment

imagico Sep 16, 2019

Choose a reason for hiding this comment

jeisenbe commented Sep 16, 2019 via email

jeisenbe commented Sep 18, 2019 • edited Loading

imagico commented Sep 18, 2019

jeisenbe commented Sep 18, 2019

jeisenbe commented Sep 7, 2019 •

edited

Loading

jeisenbe commented Sep 7, 2019 •

edited

Loading

kocio-pl commented Sep 8, 2019 •

edited

Loading

jeisenbe commented Sep 18, 2019 •

edited

Loading