Add "bits" parameter to "loadGeometry"

[lucaswoj]

fixes #2568

cc @mourner @jfirebaugh @mollymerp @ansis

This PR allows loadGeometry to use as many bits as available to store coordinates instead of always assuming the worst possible case (15 bits). This change allows us to skirt all “Geometry exceeds allowable extent” errors from Mapbox sources.

[jfirebaugh]

This seems like an odd way to fix this. Isn't the existing warning valid, indicating an off-by-one issue somewhere that should be fixed?

[lucaswoj]

The existing warning logic requires that all positions are representable within 15 bits.

In reality, only line layers are subject to this restriction. All other layer types allow 16 bits.

This PR we keeps the valid warning for line layers and suppress the invalid warning for all other layers.

Because the only layer that triggers this warning is rendered as a "symbol" layer, it effectively fixes the problem for all Mapbox sources.

Alternate solutions include

• adding a byte to each line vertex (would regress perf)
• offsetting coordinates by a constant so that we use the domain of the signed integer more efficiently (would require added shader & bucket complexity in GL JS and GL Native)
• reducing the maximum buffer size in mapnik (doesn't fix the problem for existing tiles)

Isn't the existing warning valid, indicating an off-by-one issue somewhere that should be fixed?

It's not an off-by-one bug within the GL renderer. The root of the problem is that Mapnik allows the buffer to be as big as the extent and has an inclusive upper bound.

For example, if you have a tile with a buffer size of 512, coordinates may be in the range [-512, 1024]. A signed 10 bit integer, however, can only hold [-1024, 1023] (naively).