Restore building scale rank

[zerebubuth]

Made scale_rank on buildings meaningful again - based on the properties before merging rather than after.

Connects to #1732.

[nvkelso]

GIF looks great! Do we have any idea on file size impact for a few tiles?

[zerebubuth]

Yup, I'm running the analysis now. Will post as soon as it's done.

[zerebubuth]

Looks somewhat as expected: We're including more features at zoom 14, so the buildings layer size has gone up. The slight increase at zoom 15 is because we're not able to merge quite as much as we were able to before (because everything effectively had scale_rank=1 before). The decrease at 13 is because scale_rank filtering is now working properly, and has dropped some buildings which were scale_rank=1 post-merge, but now are scale_rank > 2.

San Francisco Downtown

Nominal Zoom	Tile Coordinate	Master (bytes)	Branch (bytes)	Reduction
16	15/5241/12664	85816	85816	0.00%
15	14/2620/6332	50814	53820	-5.92%
14	13/1310/3166	21650	50552	-133.50%
13	12/655/1583	14819	12467	15.87%

San Francisco Suburbs (Sunset)

Nominal Zoom	Tile Coordinate	Master (bytes)	Branch (bytes)	Reduction
16	15/5234/12667	147195	147206	-0.01%
15	14/2617/6333	24266	25027	-3.14%
14	13/1308/3166	1845	4858	-163.31%
13	12/654/1583	5302	4393	17.14%

Santa Monica

Nominal Zoom	Tile Coordinate	Master (bytes)	Branch (bytes)	Reduction
16	15/5599/13088	108774	108774	0.00%
15	14/2799/6544	46142	47343	-2.60%
14	13/1399/3272	3583	8539	-138.32%
13	12/699/1636	1229	1083	11.88%

[nvkelso]

What happens in zoom 16? If we clamp feature inclusion at zooms 13, 14, 15 based on scale_rank, but don't clamp at max zoom 16, it seems like zoom 16 would include new features that could have a min_zoom < 16 but weren't shown at the earlier zooms?

Should we go farther and make scale_rank and min_zoom consistent (and then mark scale_rank for retirement in v2)?

From the map examples, including the clamping:

scale_rank	min_zoom	color in map
1	13	dark green
2	13.5	¿missing?
3	14	dark blue
4	14.5	light blue
5	15	light green

In the existing building.yaml file:

  - &z13_area_volume
      all:
        any:
          way_area: { min: 5000 }
          volume: { min: 150000 }
        not: { "tags->location": "underground" }
  - &z14_area_volume
      any:
        way_area: { min: 3000 }
        volume: { min: 100000 }
  - &z15_area_volume
      way_area: { min: 20 }
  - &z16_area_volume
      way_area: { min: 10 }

In Bubble Wrap:
problematic at zoom 15

            filter:
                # show footprints for buildings at least one zoom level before they will be extruded
                - { $zoom: 13, scale_rank: [1,2] }
                - { $zoom: 14, scale_rank: [1,2,3] }
                - { $zoom: 15, height: { min: 100 } }
                - { $zoom: 15, area: { min: 500 } }
                - { $zoom: 15, volume: { min: 100000 } }
                - { $zoom: 16, area: { min: 100 } }
                - { $zoom: 16, volume: { min: 50000 } }
                - { $zoom: { min: 17 }, area: true }

In Refill (map):
problematic at zoom 15

        footprints:
            filter:
                any:
                    - { $zoom: [13], scale_rank: [1,2] }
                    - { $zoom: [14], scale_rank: [1,2,3] }
                    - { $zoom: [15], height: { min: 100 } }
                    - { $zoom: [15], area: { min: 500 } }
                    - { $zoom: [15], volume: { min: 100000 } }
                    - { $zoom: [16], area: { min: 100 } }
                    - { $zoom: [16], volume: { min: 50000 } }
                    - { $zoom: { min: 17 }, area: true }

Then the existing scale_rank.csv is:

area::int,height::float,volume::int,landuse_kind,scale_rank
>=100000,*,*,*,1
*,>=250,*,*,1
*,*,>=300000,*,1
>=20000,*,*,*,2
>=5000,*,*,+,2
*,>=150,*,*,2
*,*,>=150000,*,2
>=5000,*,*,*,3
>=3000,*,*,+,3
*,>=100,*,*,3
*,*,>=100000,*,3
>=1000,*,*,*,4
>=500,*,*,+,4
*,*,>=50000,*,4
+,*,*,*,5

Should the building.yaml file change like (I'm fussy on the landuse_kind and 14.5 logic)?

  - &z13_area_volume
      all:
        any:
          way_area: { min: 100000 } # was 5000, larger value from scale_rank CSV
          height: { min: 250 }            # newly added from scale_rank CSV
          volume: { min: 300000 }   # was 150000, larger value from scale_rank CSV
        not: { "tags->location": "underground" }
  - &z14_area_volume
      any:
        way_area: { min: 3000 }     # no change, same as scale_rank CSV (prefer landuse area)
        height: { min: 100 }            # newly added from scale_rank CSV
        volume: { min: 100000 }    # no change, same as scale_rank CSV
       not: { "tags->location": "underground" }  # NEW
# needs corresponding YAML change later on for 14.5 min_zoom assignment
  - &z14d5_area_volume
      any:
        way_area: { min: 500 }     # NEW, same as scale_rank CSV (prefer landuse area)
        height: { min: 100 }          # NEW, same as scale_rank CSV (from z14_area_volume)
        volume: { min: 50000 }   # NEW, same as scale_rank CSV
       not: { "tags->location": "underground" }  # NEW
  - &z15_area_volume
      any:
        way_area: { min: 200 }      # was 20, larger value between scale_rank CSV (100) and map style (500)
        height: { min: 15 }             # NEW, middle ground to remove < 3 story buildings; map style 100
        volume: { min: 10000 }    # NEW, smaller compromise between area * height, map style (100000)
  - &z16_area_volume
      way_area: { min: 10 }          # no change, same as scale_rank CSV, because of backyard sheds
# Implied that features with way_area smaller than 10 are `min_zoom: 17` later in YAML

Then this clamp section wouldn't be needed at all? We leave the scale_rank CSV alone, but only modify the min_zoom calcs?

[zerebubuth]

What happens in zoom 16?

Ah, well spotted, thanks! Yes, we should make that consistent. I've made the change in 449a1d7.

Should we go farther and make scale_rank and min_zoom consistent (and then mark scale_rank for retirement in v2)? ... Then this clamp section wouldn't be needed at all? We leave the scale_rank CSV alone, but only modify the min_zoom calcs?

Unfortunately, the scale_rank calculation makes use of the landuse_kind, which is assigned by a post-processor and not known when we assign min_zoom in the database. I'm all for simplifying, but we'll end up with a process that looks a lot like the current one (i.e: assign the minimum min_zoom for the feature, then assign scale_rank, then use scale_rank to clamp min_zoom - basically dropping half a zoom based on landuse_kind).

One question is how the min_zoom logic works in the client. If we assign a min_zoom of 14.5, will that be visible in the zoom 14 tile? Or would it require work-arounds in the style file (filter: function() { return $zoom > feature.min_zoom - 0.5; }) to make sure that we're not including a bunch of data in the tile that'll never be shown?

[nvkelso]

We talked about this IRL...

Now that the clamp is always applied I think we're aways consistent, thanks!

Please add tests to ensure min_zoom: 16 and min_zoom: 17 buildings (tiny ones!) still get their min_zoom preserved, then I think we're good for merging.

I filed #1745 to address removing scale_rank entirely (just in favor of min_zoom) for eventual v2 milestone.

[nvkelso]

Please add the 2 more small (literally small area!) tests and then we're ready for merging :)

[zerebubuth]

Thanks! Small area tests added in ca66504.