Add UVs to building coordinates.

[zerebubuth]

When we clip a building it makes it difficult to properly align textures on the extruded sides, as the sides may now have "seams" between adjacent tiles. This doesn't look good.

We can add u, v texture coordinates to the geographic coordinates on the server before splitting occurs. This appears to be allowed by GeoJSON and TopoJSON, although perhaps would require a dummy z coordinate before u and v.

However, it looks like MVT and OSciMap formats only allow 2D coordinates, so we might have to consider an alternative representation. Given that the transforms are affine and 2D, would it be possible to encode a parameter with a position and orientation to calculate the u, v coordinates from the real coordinates? For example, assuming the values scale, cx, cy and theta are given:

x' = cos(theta) * (x - cx) + sin(theta) * (y - cy)
y' = -sin(theta) * (x - cx) + cos(theta) * (y - cy)

(apologies for that, but apparently GFM doesn't support real maths, so it was ASCII art or pseudocode...)

@bcamper would calculating u, v on the client from a formula like the one above be too time-consuming?

[bcamper]

cc @meetar

[bcamper]

and @blair1618

[matteblair]

This is a possibility. The client-side transformation would not be expensive to calculate, in fact for the native renderer the more expensive part would be looking up the relevant properties within the feature.

If we were to add UV coordinates to all geometries I would be concerned about the increased size of tile payloads, but per-feature UV parameters would address that.

Another consideration: our current generated-on-the-fly UVs can be applied to any geometries, not just those from our servers. To preserve this behavior, we could keep a best-guess UV generator for features where UV parameters are absent.

[zerebubuth]

I was thinking we'd start with just the buildings. It would be possible, with a bit of mode movement, to limit new parameters to just the buildings which cross tile boundaries... but might be easiest to just test it out on all buildings to begin with.

[bcamper]

@zerebubuth I think all we would need for lines would be the cumulative length along the line so far at the point where it was cut, e.g. for a line that gets split across 4 tiles, we would want to know where each "break" at the tile boundary occurred along the line:

               +------------------------------------------------+
               |                       |                        |
               |                       |                        |
               |                       |                        |
               |                       |                        |
               |                       |                        |
  0            |5                      |15                      |
  +---------------------------------------------------------------------+
               |                       |                        |
               |                       |                        |
               |                       |                        |
               |                       |                        |
               |                       |                        |
               |                       |                        |
               +------------------------------------------------+

I think anyway :) We don't need the length of the original line, because we are just repeating a pattern and we need to know where in the pattern we are where the line breaks. But I think we can just modulus the cumulative length.

[patriciogonzalezvivo]

I think we only need the starting offset... lines preserve their direction across tiles. Right? So we need the starting pattern offset.

    +------+      +------+      +------+      +------+
+---|------|  +---|------|  +---|------|  +---|------|
    +------+      +------+      +------+      +------+