Water layer are too big at zoom 8 (zoom 7 at 512 tile size)

[nvkelso]

tl;dr

• water layer min_zoom to d.d rounding (instead of d.dd), so 1.1 instead of 1.11.
• water layer simplify start of zoom 8 config.
• Consider dropping names from small and medium sized water bodies to improve their chance of being merged.
• Drop tiny and small water features at mid zooms
• [ ] roads layer drop properties at low zooms for surface (add surface tag to roads #1197) and access (add access tag to roads, fixes #1273 #1328) tags to the roads. EG we forgot to drop them at low zooms like we do for other tags. Consider dropping access=yes and related tags #1331

===

• What did you see? Tile size is too large at zoom 8 (zoom 7 at 512 tile size).
  • With compression in TopoJSON: 2x file size increase
  • With uncompressed GeoJSON: 7/37/48 tile is 13.5 mb to 3.6 mb! (or 3.75x as large!!!)
• What did you expect to see? Smaller tile size, more generalized geoms, less features
• What map location are you having problems with?
  • https://tile.nextzen.org/tilezen/vector/v1/512/all/7/37/48.json?api_key=zxy
  • https://tile.mapzen.com/mapzen/vector/v1/512/all/7/37/48.json?api_key=zxy
  • https://tile.nextzen.org/tilezen/vector/v1/512/all/8/74/97.json?api_key=zxy
  • https://tile.mapzen.com/mapzen/vector/v1/512/all/8/74/97.json?api_key=zxy
• Screenshot? Props for animated gifs.

We did change the NE to OSM switchover in #1359.

So it's expected the feature count be different...

But it seems there are to many features / they have too many names, and their geometries aren't simplified.

At zoom 7 at 512 px tile size in Nextzen build (showing no geom simplification):

Compared to Mapzen build using Natural Earth source (using default NE shapes that are already generalized):

At zoom 8 at 512 px tile size in Nextzen (with generalization):

Compared with zoom 7 at 512 px tile size in Nextzen (no generalization):

/cc @bcamper

[nvkelso]

Looks like simplify_start: 8 should be set (instead of 9):

• https://github.com/tilezen/vector-datasource/blob/v1.4.3/queries.yaml#L144
• https://github.com/tilezen/vector-datasource/blob/v1.4.3/queries.yaml#L159

To match roads:

• https://github.com/tilezen/vector-datasource/blob/v1.4.3/queries.yaml#L201

[nvkelso]

And in boundary calculation would explain the missing water lines:

• https://github.com/tilezen/vector-datasource/blob/v1.4.3/queries.yaml#L380

[bcamper]

Does this explain why there are also significantly more road geometries though?

…

On Tue, Feb 13, 2018 at 3:56 PM, Nathaniel V. KELSO < ***@***.***> wrote: Looks like simplify_start: 8 should be set (instead of 9): - https://github.com/tilezen/vector-datasource/blob/v1.4.3/ queries.yaml#L144 - https://github.com/tilezen/vector-datasource/blob/v1.4.3/ queries.yaml#L159 To match roads: - https://github.com/tilezen/vector-datasource/blob/v1.4.3/ queries.yaml#L201 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1477 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABBXdgS9SfbYeRCZIsqphfYvApBAvRIks5tUfcKgaJpZM4SEYrJ> .

[nvkelso]

Looking at number of water layer features, I think it's because the min_zoom is 2 decimal precision (eg: 8.12 instead of 8 or 8.1) which prevents feature merging.

Comparing the following two tiles:

• https://tile.nextzen.org/tilezen/vector/v1/512/all/8/74/97.json?api_key=zxy
• https://tile.mapzen.com/mapzen/vector/v1/512/all/8/74/97.json?api_key=zxy

The number of named water features is essentially the same at 68 or 69, and the remaining delta is 79 with the 2dd min_zoom in nextzen and only 7 count in the mapzen version with the int min_zoom.

But the feature count difference doesn't seem to affect total file size in GeoJSON format as both zoom 8 JSON files are 2.9 mb (compared to the huge file size difference at zoom 7).

Perhaps we should clip the min_zoom precision to 1dd (eg 8.1) for all layers except POIs (keeping them at 2dd)?

But this doesn't explain why there are more roads layer features in Nextzen as the min_zoom there is almost always an int (for other YAML related reasons).

Showing Nextzen tile having multiple unnamed features:

While Mapzen they were all dissolved to single features per kind and zoom (which was always 9, an error that was fixed).

[nvkelso]

For roads layer... it looks like the road features between new/old have the same geometry simplification, but I do see that feature count delta. Some of the delta is due to less feature merging (~120 more features with IDs that aren't merged)... but that doesn't account for the other 300 which don't have an ID implying they have been merged but to more total features than before.

Looking just at file size of the roads layer as GeoJSON, the Nextzen tile is 1.5 mb versus 1.3 mb Mapzen so it does add up.

Further research is needed.

[zerebubuth]

Looking just at file size of the roads layer as GeoJSON, the Nextzen tile is 1.5 mb versus 1.3 mb Mapzen so it does add up.

The issue seems to be that when we added the surface (#1197) and access (#1328) tags to the roads, we forgot to drop them at low zooms like we do for other tags.

For the tile 512/all/7/37/48, I see the following feature counts for different values of surface:

surface	Count
no value	2650
asphalt	445
concrete	68
paved	62
concrete_plates	8
gravel	7
metal	3
unpaved	2
compacted	2
wood	1
cobblestone	1

And the same for the access values:

access	Count
no value	3203
yes	33
permissive	1
designated	4
no	4
hov	2
private	2

Dropping the surface and access properties would take the number of unique sets of properties down from 3,249 to 2,819 - which is much closer to the 2,826 in the Mapzen tiles.

[nvkelso]

For dropping water names, here's what Walkabout style does (after a year of tweaking so I think it's fine to just copy server side):

https://github.com/tangrams/walkabout-style/blob/gh-pages/walkabout-style.yaml#L1258-L1279

        water-area-labels:
            visible: global.text_visible_water_labels
            filter:
                all:
                    - name: true
                    - $geometry: point
                    - not: { kind: [riverbank, dock, playa] }
                    - area: true
                any:
                    # show labels for smaller landuse areas at higher zooms
                    - { $zoom: { min: 5 },  area: { min: 10000000000 } }
                    - { $zoom: { min: 6 },  area: { min: 5000000000 } }
                    - { $zoom: { min: 7 },  area: { min: 400000000 } }
                    - { $zoom: { min: 8 },  area: { min: 200000000 } }
                    - { $zoom: { min: 9 },  area: { min: 100000000 } }
                    - { $zoom: { min: 10 }, area: { min: 10000000 } }
                    - { $zoom: { min: 11 }, area: { min: 4000000 } }
                    - { $zoom: { min: 12 }, area: { min: 750000 } }
                    - { $zoom: { min: 13 }, area: { min: 100000 } }
                    - { $zoom: { min: 14 }, area: { min: 50000 } }
                    - { $zoom: { min: 15 }, area: { min: 10000 } }
                    - { $zoom: { min: 16 } }

This is after the areas are already throttled generally in https://github.com/tangrams/walkabout-style/blob/gh-pages/walkabout-style.yaml#L1068-L1089:

        lakes:
            filter:
                all:
                    - kind: [ocean, lake, water, riverbank, reservoir, swimming_pool]
                # WARNING: any area filters here must match the area filters in the water_boundaries-not-ocean layer
                any:
                    # limit show smaller landuse areas to higher zooms
                    - { $zoom: { min: 0 },  area: { min: 40000000000 } }
                    - { $zoom: { min: 2 },  area: { min: 20000000000 } }
                    # some weird natural earth scale set transition
                    - { $zoom: { min: 3 },  area: { min: 80000000000 } }
                    - { $zoom: { min: 4 },  area: { min: 5000000000 } }
                    - { $zoom: { min: 5 },  area: { min: 700000000 } }
                    - { $zoom: { min: 6 },  area: { min: 500000000 } }
                    - { $zoom: { min: 7 },  area: { min: 160000000 } }
                    - { $zoom: { min: 8 },  area: { min: 20000000 } }
                    - { $zoom: { min: 9 },  area: { min: 5000000 } }
                    - { $zoom: { min: 10 }, area: { min: 1000000 } }
                    - { $zoom: { min: 11 }, area: { min: 200000 } }
                    - { $zoom: { min: 12 }, area: { min: 50000 } }
                    - { $zoom: { min: 13 }, area: { min: 20000 } }
                    - { $zoom: { min: 14 } }

Probably the order of operations is important to drop the features BEFORE generating the water boundary lines.

[nvkelso]

The above could probably be simplified to "pixel" areas. Tangram JS now has that facility but we never migrated the code... and vector-datasource has a generic pixel area... the above numbers are just for water features.

[nvkelso]

For the areas:

New:

Old:

For the labels:

New:

Old:

For @iandees:

New:

Old:

[iandees]