Conversation
…e don't have a zoom level full of unsimplified water geometry.
|
Connects to #1477. |
| table: ne | ||
| - filter: {featurecla: Alkaline Lake} | ||
| min_zoom: 0 | ||
| min_zoom: *water_polygon_min_zoom |
There was a problem hiding this comment.
For Natural Earth features we should just trust their min_zoom data property.
Looks like before we were always "overstuffing" by using 0, but the data property already does curated filtering for us.
Here and elsewhere...
There was a problem hiding this comment.
Yup, good point. Does this YAML pre-date NE v4? I think we might have been relying on the filter which removes features smaller than a pixel a little too much. Fixed in 67aa978.
| - [ 4, 5000000000 ] | ||
| - [ 5, 700000000 ] | ||
| - [ 6, 500000000 ] | ||
| - [ 7, 160000000 ] |
There was a problem hiding this comment.
Suggest removing lines for zooms 0-7 as those are from Natural Earth and should be taken from the data, including the junk comment copy-pasted from Walkabout for # limit show smaller landuse areas to higher zooms.
There was a problem hiding this comment.
(Should add comment to that effect... &/or keep filters as backstop against future OSM / NE zoom transition changes?)
There was a problem hiding this comment.
Sounds good. Clipped to 7 and quickly tested locally. Looks okay to me. Fixed in 67aa978.
| - [ 11, 200000 ] | ||
| - [ 12, 50000 ] | ||
| - [ 13, 20000 ] | ||
| default: 14 |
There was a problem hiding this comment.
This seems to now show tiny lakes and swimming pools at zoom 14 instead of zoom 16 max? Although in practice browsing around Cupertino (link below) most swimming pools were getting zoom 14.xxx incorrectly (and even showing before the surrounding house footprints!)
Suggest adding zoom 14, 15, 16, and default 17 instead:
- [ 14, 2000 ]
- [ 15, 1000 ]
- [ 16, 400 ]
default: 17
I've been browsing around Cupertino to gain some of these numbers:
| - vectordatasource.transform.detect_osm_relation | ||
| - vectordatasource.transform.remove_feature_id | ||
| - vectordatasource.transform.truncate_min_zoom_to_2dp | ||
| - vectordatasource.transform.truncate_min_zoom_to_1dp |
There was a problem hiding this comment.
All the min_zooms are ints in the area transform below... although switching the NE values to be data driven may sometimes introduce some float values with tenths. So this doesn't hurt, but it probably doesn't help as much now that we're switching to the area lookup table.
There was a problem hiding this comment.
Some things are still using the previous, floating point min_zoom calculation:
dockfountainbaystraitfjordbasinreef
Some of these (bay, strait, fjord) are (I think?) only used to generate label points, but they'll still inherit the min_zoom from their parent.
Overall, given the limitations of fractional min_zoom anyway, it seemed like it was worth cutting down the level of precision. It's a simple change if we want to increase it again later.
| # NOTE: the 270 factor comes from curve fitting the area table from the | ||
| # walkabout style, with 270 being the min, ranging up to 1070. | ||
| where: >- | ||
| area < 270.0 * pixel_area |
nvkelso
left a comment
There was a problem hiding this comment.
Wow, HUGE savings!
A couple comments but overall looking very good :)
…ularly affects swimming pools.
…able down to z17.
Incorporating the area look up table from #1477 (comment) and a "curve fitted" pixel-area name rule, we can reduce the number of water features (which weren't getting rendered anyway) in the tile. Additionally, we were missing simplification for water and earth layers at zoom 8 (nominal). With those changes, a zoom 8 (nominal) 512px tile at
7/30/43looks like this (previous values in red, behind, layer in front in blue is new):On tile
7/30/43, which is pretty much a worst-case scenario and has thousands of tiny lakes, we get a 97% reduction in total size (from 2.4MB to 62kB). The reduction in the number of features is massive - partly because we're being more selective about the features at this zoom and partly because we're merging a lot more lakes that we're able to strip the names off:The bytes per kind shows similar reduction: