way_area conditions for all ST_PointOnSurface layers

[pnorman]

Fixes #4030

I used 768000 for POIs, which is about 12 tiles, and 4000000, which is about 64 tiles for cases like countries where we want to show larger objects.

[imagico]

I am strictly against introducing a lower (starting) way_area limit for features where there is no visual feedback on the geometry - in this case place=square.

Regarding changing way_area > 1*!pixel_width!::real*!pixel_height!::real - i am not sure this is a good idea. This limit had been introduced as arbitrary limit based on the cargo culted assumption that the threshold of one pixel in rendering has somehow a magic significance. Promoting this to a scale independent limit would make it even more baseless. What should be done here is to get rid of this arbitrary and distorting limit in the first place - a matter that i have discussed at length in the past (see #3273 for the most recent collection of references).

In the single case of the 0.01*!pixel_width!::real*!pixel_height!::real - that should definitely stay tied to the rendering resolution because the reasoning behind that limit is connected to the actual pixel size of the rendering, see also #1566.

[pnorman]

I am strictly against introducing a lower (starting) way_area limit for features where there is no visual feedback on the geometry - in this case place=square.

I am not introducing it - it already exists:

openstreetmap-carto/roads.mss

Lines 3307 to 3309 in e7de1cd

	#roads-area-text-name {
	[way_pixels > 3000],
	[zoom >= 17] {

For the other limits, I believe it is important that the feature selection and queries are the same independent of scale factor. If you want to get rid of the limit, that belongs in a different PR.

[imagico]

I am not introducing it - it already exists:

Ah, sorry. See #4043.

For the other limits, I believe it is important that the feature selection and queries are the same independent of scale factor.

Well - as explained the reasoning behind these limits is not independent of the scale factor.

[jeisenbe]

I support most of these changes, but would like to keep using pixel_width/pixel_height for the 1 pixel and sub-pixel rendering layers, where the limit is supposed to represent polygons which are too small to affect the final rendering. This depends on rendering resolution, so scale_denominator would not be the best idea.

comments addressed

[jeisenbe]

The code looks fine, though I haven't had a chance to do a test rendering with the latest commit.

[jeisenbe]

Test renderings are fine.

[imagico]

I have not specifically tested all the thresholds but in general the code works fine.