Separate z/x/y from decoding logic

[springmeyer]

We should follow the lead of both https://github.com/mapbox/vector-tile-js and https://github.com/mapbox/vector-tile when organizing decoding logic. Instead of passing in the z/x/y into the decoder as an argument we want to offer a decoder that is agnostic to the geographical location and works primarily in tile coordinates. Only when doing something like converting to GeoJSON would the z/x/y would be needed and it should be passed in on-demand like https://github.com/mapbox/vector-tile-js/blob/b7abef267dc60977a25a8374c0b0a79f41acf344/lib/vectortilefeature.js#L129-L145

[springmeyer]

Looking at the code and the structure of List<List<LngLng>> to hold geometries, I can see this being quite useful. Nice work on this @BergWerkGIS. At the same time I'm worried that there will be unwanted overhead of allocating all those nested structures. I wonder if we can instead decode into a flat array and then provide functions that can be called later on to transform and scale and geometries as needed for different APIs. An API that wants GeoJSON-like objects could transform as needed into geographical coords and nested objects. But others might want be able to work with flat arrays in the original tile coordinates. I think we should aim to provide examples that do both.

See below for clarified comment.

[wilhelmberg]

Agreed, background why I chose to do it like this at the end of this comment.

[wilhelmberg]

I wonder if we can instead decode into a flat array and then provide functions that can be called later on to transform and scale and geometries as needed for different APIs.

@springmeyer Any suggestions on how a flat array would provide information about multiparts and inner rings?

[springmeyer]

@BergWerkGIS I apologize, I've crossed out the second comment as my thinking was not clear. The main points of this issue are:

• For best performance, I recommend decoding only into tile coordinates (not merc or wgs84).
• To be consistent with other vtile APIs:
  • Pass only a scaling value to decode geometries into tile coordinates: https://github.com/mapbox/vector-tile/blob/master/include/mapbox/vector_tile.hpp#L209
  • Only require z/x/y when decoding into geographical coords (like when converting to GeoJSON, https://github.com/mapbox/vector-tile-js/blob/master/lib/vectortilefeature.js#L129-L145)
• As far as geometry storage, ignore my flat array comment - we do want easy to use, nested, arrays for parts following the lead of https://github.com/mapbox/geometry.hpp.

[wilhelmberg]

Implemented.

New usage:

            VectorTile vt = new VectorTile(data);
            foreach (var layerName in vt.LayerNames())
            {
                VectorTileLayer layer = vt.GetLayer(layerName);
                for (int i = 0; i < layer.FeatureCount(); i++)
                {
                    VectorTileFeature feat = layer.GetFeature(i);
                    List<List<LatLng>> wgs84Coords = feat.GeometryAsWgs84(zoom, tileColumn, tileRow);
                }
            }