Following V2 Specification #42
Description
I took a quick glance over your encoder code and I am concerned about if the code actually makes v2 compliant vector tiles. My suggestion would be to simply tag as v1 tiles until further notice. Don't feel rushed IMO to get up to v2 until you feel you have a solid implementation.
We also are working to put together better documentation around the specification, so please see the living document at http://mapbox.github.io/vector-tile-spec/
Layer Message:
https://github.com/mapbox/vector-tile-spec/tree/master/2.1#41-layers
Name Field:
A layer MUST contain a name field. A Vector Tile MUST NOT contain two or more layers whose name values are byte-for-byte identical. Prior to appending a layer to an existing Vector Tile, an encoder MUST check the existing name fields in order to prevent duplication.
- Looking here if layer name is an empty string does it actually encode a layer name (as this is required)
- You do not seem to check for any duplicate layer names from what I can tell.
Extent Field:
A layer MUST contain an extent that describes the width and height of the tile in integer coordinates. The geometries within the Vector Tile MAY extend past the bounds of the tile's area as defined by the extent.
- While the specification doesn't specify it, I would suggest checking that the extent is greater then 0.
Not Required But Good to Do:
A Vector Tile SHOULD contain at least one layer. A layer SHOULD contain at least one feature.
Feature Message:
https://github.com/mapbox/vector-tile-spec/tree/master/2.1#42-features
Geometry Type Field:
A feature MUST contain a type field as described in the Geometry Types section.
Just glancing at your code I wasn't positive that this is enforced.
Geometry Encoding:
https://github.com/mapbox/vector-tile-spec/tree/master/2.1#43-geometry-encoding
LineTo Command:
https://github.com/mapbox/vector-tile-spec/tree/master/2.1#4332-lineto-command
https://github.com/mapbox/vector-tile-spec/tree/master/2.1#4332-lineto-command
I think your code currently makes it possible for there to be a lineto with no movement.
Line-string Geometry:
https://github.com/mapbox/vector-tile-spec/tree/master/2.1#4343-linestring-geometry-type
The geometry command sequence for a linestring geometry MUST consist of one or more repetitions of the following sequence:
A MoveTo command with a command count of 1
A LineTo command with a command count greater than 0
I believe it is currently possible to make linestring type geometries that consist of only a moveto.
Polygon Geometry:
https://github.com/mapbox/vector-tile-spec/tree/master/2.1#4344-polygon-geometry-type
Each ExteriorRing and InteriorRing MUST consist of the following sequence:
A MoveTo command with a command count of 1
A LineTo command with a command count greater than 1
A ClosePath command
I believe that this is not currently enforced in your code as you could have a polygon type with less then 3 points.
An exterior ring is DEFINED as a linear ring having a positive area as calculated by applying the surveyor's formula to the vertices of the polygon in tile coordinates. In the tile coordinate system (with the Y axis positive down and X axis positive to the right) this makes the exterior ring's winding order appear clockwise.
An interior ring is DEFINED as a linear ring having a negative area as calculated by applying the surveyor's formula to the vertices of the polygon in tile coordinates. In the tile coordinate system (with the Y axis positive down and X axis positive to the right) this makes the interior ring's winding order appear counterclockwise.
I think that this issue might be a good read. I am worried that your code fails specifically in the coordinate transform area. It is important to check winding order after coordinate transform into integers due to the possibility of inverting the winding order! I am pretty sure that your code does not do this currently, this can greatly break multipolygons/polygons when they are decoded.
Linear rings MUST be geometric objects that have no anomalous geometric points, such as self-intersection or self-tangency.
It is a short note currently, but this might be the most difficult line so far for us as we are writing our encoder. We have spent a great deal of time working on problems around ensuring the validity of polygons according to the OGC specification. While the specification does not strictly state the OGC specification, I believe we might shift to that eventually. http://postgis.net/docs/using_postgis_dbmanagement.html#OGC_Validity
In general this is one of the most important things to consider. There are many problems with maintaining validity of polygons AFTER there is any transformation done. This includes rounding and transforming into the vector tile coordinates!