Render tourism outlines one zoom level sooner for small zoos and theme parks #3648
Conversation
Previously tourism boundaries (zoos and theme parks) only rendered at z17 or if waypixels were >750 from z10 to z16 This commit changes the limit to 180 waypixes at z13 and above, while from z10 to z12 the way_pixels (area) limit remains Usually this means that small tourism=zoo and tourism=theme_park areas will render one zoom level sooner.
|
Maybe it's a database thing (Postgres/PostGIS)? |
|
The |
|
|
|
So way_area is the actual area of the polygon in e.g. square meters, and
way_pixels is approximately the area of the polygon in pixels, correct?
…On Fri, Jan 18, 2019 at 11:43 PM Matthijs Melissen ***@***.***> wrote:
way_pixels comes from project.mml, for example way_area/NULLIF(!pixel_width!::real*!pixel_height!::real,0)
AS way_pixels.
pixel_width and pixel_height in turn come from Mapnik:
https://github.com/mapnik/mapnik/wiki/PostGIS#other-tokens
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3648 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshI4mkZscsT323KWEm-aPjbQoDhVZks5vEd17gaJpZM4aHXer>
.
|
Correct! Forgot to mention, but way_pixels is calculated by osm2pgsql. |
|
Note way_area is in Mercator square meters, not in actual square meters. For making styling decisions regarding label size etc. normalization with |
|
Should we redefine all occurrences of way_pixels as
```
way_area/!scale_denominator
```
?
…On Sat, Jan 19, 2019 at 8:49 AM Christoph Hormann ***@***.***> wrote:
Note way_area is in Mercator square meters, not in actual square meters.
For making styling decisions regarding label size etc. normalization with
!pixel_width!/!pixel_height! is not ideal because it is not invariant
w.r.t. rendering resolution. See #2524
<#2524>.
Normalization with !scale_denominator! would make more sense.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3648 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshOE0c71KMUyLMO0P5HuED-jSNwZHks5vEl11gaJpZM4aHXer>
.
|
|
Yes, would be great if that works. |
|
I think the new smaller outlines look messy and not so clear; personally I'd prefer the current rendering. |
|
PR looks technically fine. |
|
It’s a shame that we don’t have a fast way to query the minimum dimensions
of a polygon. I think this PR looks good with zoos and theme parks that are
nearly square or circular (say width:height < 2) but it doesn’t work as
well with the example of the long, thin theme park.
Still, I find it odd to have land-color “holes” at z14 or z13 on a rendered
area that is actually 100% tagged with some sort of landcover or landuse,
so I prefer to see the area rendered, even when it looks more like a fill
color than an outline.
…On Fri, Jan 25, 2019 at 8:28 AM Matthijs Melissen ***@***.***> wrote:
PR looks technically fine.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3648 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshJWaVY9nJfAZWsX22fHHCClkN8Myks5vGkGRgaJpZM4aHXer>
.
|
|
I've tested the way_pixels calculation change. The scale_denominator = map_width_in_metres/ (map_width_in_pixels * 0.00028m) Because 0.28mm is the standardized pixel size. So at z17 scale_denominator=4265.4591677, which means that one standard pixel is approximately the same as one square meter at this zoom level (near the equator). See: https://github.com/openstreetmap/mapnik-stylesheets/blob/master/zoom-to-scale.txt So to convert way_area to pixels, divide by 0.28mm squared [=0.0000000784 meters] multiplied by the scale_denominator squared.
I've pushed a commit to the border-labels branch, i.e. PR #3652 after testing. |
|
Thanks - to make the formula better understandable i would formulate it as
(that is millimeter-to-meter*millimeter-per-inch/assumed-ppi) And i would not use it selectively for some features but roll it out universally in those cases where way_area is used in relation to the map display scale. |
|
millimeter-to-meter*millimeter-per-inch/assumed-ppi
That sounds sensible by an American perspective. I didn’t think
pixels-per-inch was the standard in other countries.
roll it out universally in those cases where way_area is used in relation
to the map display scale.
I’ll do a PR for this, next
…On Sat, Jan 26, 2019 at 7:51 PM Christoph Hormann ***@***.***> wrote:
Thanks - to make the formula better understandable i would formulate it as
way_area/NULLIF(POW(!scale_denominator!*0.001*25.4/90, 2),0)
(that is millimeter-to-meter*millimeter-per-inch/assumed-ppi)
And i would not use it selectively for some features but roll it out
universally in those cases where way_area is used in relation to the map
display scale.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3648 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshF_-mvUAQxxQVIAJwFgM_sv8gPgUks5vHDNCgaJpZM4aHXer>
.
|
|
I tested with Current way_pixels calculation (based on pixel_width and pixel_height):
With
Compared to
In fact the assumed "ppi" for mapnik is based on a 0.28mm pixel, so it should be approximately 90.71 standardized "ppi" (pixels per inch):
I'm not convinced that |
|
I am sorry - my bad. I just assumed mapnik - like almost all other programs converting between pixel and real world units - would assume a certain integer ppi (historically often 72, recently more often 90 or 92). |
|
It looks like @matthijsmelissen is not in favor of the cartographic changes, and no one else has spoken out in support. I agree that the long and narrow areas do not look good with this change (though it works fine with shapes closer to square or circular) so I think this PR can be closed. |
Partially reverts #2835
Changes proposed in this pull request:
Explanation:
Prior to #2835, all zoos and theme parks were rendered from z10 if the way_pixels was > 20. This meant that very small features, for example 5 pixels tall and 5 pixels wide, would render. Those with less than way_pixels between 20 and 60 were rendered with a thin 1 pixel border, which was difficult to see and looked quite different than the wide, double border used for larger areas (as seen now).
#2835 improved this situation by only rendering tourism area outlines when the waypixels was > 750. This is 1/4 of 3000 way_pixels, the number used to show the name of the area, so the outline would show exactly 1 zoom level sooner than the name label. Very small areas were hidden.
However, this caused some mid-sized areas to disappear; for example a 30 by 20 pixel area is hidden, even though this is 3 times larger than an icon. This looks strange when there are two tourism areas adjacent, a situation sometimes found in areas with more than one theme park or zoo next to each other (as see in Singapore, below). If one of the areas is slightly smaller, it could disappear a zoom level sooner than it's neighbor, leaving a gap in the map.
I initially considered rendering all zoos and theme parks from >=z13, because that is where all landcover colors and patterns are now shown. However, I found that it was not helpful to show very small areas less than 100 waypixels. The limit in this PR is now set to 180, which will cause small zoos and theme parks to render approximately 1 zoom levels sooner than before. This solves the problems without losing most of the benefits of #2835
Test renderings:
Sentosa Island, Singapore
https://www.openstreetmap.org/#map=15/1.2513/103.8229
z15 Current
z15 After
z16 (Same)
Jurong Bird Park, Singapore
https://www.openstreetmap.org/#map=14/1.3229/103.7269
z13 Current
z13 After
z14 (unchanged)
z15 (unchanged)
Singapore Zoo and Night Safari
https://www.openstreetmap.org/#map=14/1.4043/103.7957
z13 Current
z13 After
z14 (Same)
Bangor, Northern Ireland
https://www.openstreetmap.org/#map=15/54.6637905/-5.6726521
z13 current
z13 after
z14 (same)
z15 (same)
Damhead Miniature Railway
https://www.openstreetmap.org/#map=17/55.1115842/-6.5977664
z15 (Same)
z14 Current
z14 After
z13 (same before and after)
[Before #2835 this would have been the rendering at z13:]
z13 Damhead railway rendering with 20 way_pixels limit: