[core] Rationalize Resource initialization

[jfirebaugh]

Extract URL construction code for reuse in #3715.

[jfirebaugh]

This is a partial reroll of #3675 (the least risky parts).

[kkaefer]

Does this need to be a float? Are we supporting assets that have a fractional pixel ratio?

[kkaefer]

I know we support fractional pixel ratios when rendering, but should we always round up to the nearest integer pixel ratio when requesting assets?

[jfirebaugh]

It's a bit of a grey area because technically we don't support anything other than @2x, and that only for Mapbox sources. So if the parameter is to represent strictly what's supported now, it could be an integer or even bool retinaTiles.

In terms of offline, what I am planning to do is extract a tileCover function that takes a display pixel ratio, display bounding box, display zoom range, source type, source tile size, and SourceInfo, and returns a std::vector<Resource>, where the Resources are Resource::Kind::Tile with the appropriate TileData. (Or I might extract Resource::TileData to a non-nested class and return a vector of that.)

The tileCover function will:

• Determine the appropriate pixel ratio for the tile requests, given the display pixel ratio and supported pixel ratios of the source (currently 1.0 and 2.0 only for Mapbox sources)
• Determine the set of appropriate source zoom levels for the tile requests, given the display zoom range and taking into account
  • source min and max zoom
  • tile size normalization (i.e. requesting z1 256px tiles at display zoom level 0)
  • different raster/vector float z ⇢ integer z rounding behavior
• Determine the appropriate set of tile [x, y]s for each zoom level

Source will use this function to calculate the covering tiles for the current bounding box and zoom range (a degenerate range where min=max). Offline will use this function to calculate the appropriate tiles to download given the region definition.

This function will be responsible for rounding to the nearest integer pixel when that's all the source supports. It should be the only place we need to change if we add support for additional pixel ratios in the future (@3x or even non-integer ratios).

The only other place where the type of TileData::pixelRatio will matter is in the database schema. There I think I'd like to keep it floating point, just for future flexibility, even though right now the only values will be 1.0 and 2.0.

[jfirebaugh]

Actually, I'm comfortable saying we'll never support non-integer multipliers for tile resolution. I'll make it an integer here and in the database schema.