Clipping logic

[ycabon]

This PR adds the capability of deriving on the fly clipped geometries from a vector tile.

Part of the indexing work done here Esri/mapbox-gl-js#1 https://gist.github.com/odoe/ce6a150658526901ef27#file-vector-tile-pr-md

Each feature is created with extra properties.

• dz - delta in z between the native resolutions of the tile and the synthesized one
• xPos - position in x of the synthesized tile in the native tile at dz
• yPos - position in y of the synthesized tile in the native tile at dz

Those properties are used to generate the clipped geometry when loadGeometry() is called.
For tile with native extent greater than 4096, loadGeometry() scales down the coordinates to comply with the default 4k extent and work around the vertex buffer encoding using int16.

If the clipped geometry is null, the feature isn't added the buckets.

This was the least invasive way in mapbox-gl-js. Probably there is another way to architecture this.

[tmcw]

could this be tape test/*.test.js so that assertions in the test suites are combined?

[jcardonadcdev]

@tmcw - Sorry for the delay. package.json now changed to run all tests in batch

[flippmoke]

I am not an expert on all this JS code, but what you are doing with vector tiles (as far as the clipping and scaling algorithm) does concern me in terms of making valid tiles as per the v2 specification.

Rounding issues associated with scaling up from a higher precision set of data to a lower precision set of data can possibly cause inverted winding orders, duplicated points, and invalid polygons (mostly from interior rings touching the edges of exterior rings.

Here is an example of a floating point rounding causing an inverting of winding order, while these are not floating point numbers the same problem can occur:

An inverted interior ring could single the start of a new polygon and a future exterior ring could be considered an exterior ring of that polygon. This looks really ugly once it gets to the renderer.

For duplicated points this is not considered valid per: https://github.com/mapbox/vector-tile-spec/tree/master/2.1#4332-lineto-command

If you clipped an interior or exterior polygon to representable by only a line, it would no longer have a valid area. I did not see these sort of polygons being removed prior to being sent out.

Currently in some of our code we are using the angus clipper to help clean up some of this, however, it requires intensive processing. Therefore, currently it is typically better to clip polygons like this on the client side.

/cc @ycabon

[flippmoke]

Issue that might be helpful: mapbox/vector-tile-spec#58

[mbriat]

Thanks for your comments.
This work was pre v2 which is why it was ignoring those constraints.
The duplicated points and null area polygons issues can definitively be fixed.
Inverted rings (I guess we're just talking about a change of area sign, or would local inversion also be a problem?) and overlapping rings are more difficult issues to address in this context.
My understanding is that this will be problematic for the earcut tessellation to work properly (exterior/interior order identification and leftmost point of interior extending past exterior). Let me know if there are other considerations to this.
Some additional questions:

• the v2 spec does not clearly distinguish between touching and crossing interior/exterior rings. It seems that touching is ok. Is this correct?
• did you mean the angus clipper is best used at cooking time, when building the tiles?