Fixes non-default (4096) layer extent

[jwass]

This uses the extent field specified in each layer when decoding.

Prior to this, the extent was an input to the tile decoder. However a layer's extent isn't known until you decode the tile to find out what it is. Also it's possible that different layers may have different extents, which couldn't be handled.

This reads each layer's extent and uses that when decoding geometries. It removes the extents member of the decoder but keeps it in the constructor. I didn't want to remove it because it would be a breaking API change.

Although the extent is optional in the proto file, if it's not specified the protocol buffer library will emit it as the default value (4096). https://developers.google.com/protocol-buffers/docs/reference/python-generated.

The encoder should be modified similarly to allow layers to specify an optional extent but I wanted to get thoughts on this first.

[jwass]

Looking this over again - a problem is that there's no straightforward way to include a layer's extent with the output of decoding because each layer is just an array of the features. Seems like a new interface is needed for this.

[rmarianski]

Thanks for this. I'm 👍 on these changes, and for breaking changes on the decoding interface to simplify, like changing the constructor. For the results, instead of a list of features, we could return back an object, eg:

{'water': {'features': [], 'extent': 4096}}

If you would like to update the encoder to add support for custom extents, that would be great too!

[jwass]

@rmarianski Thanks. Completely agree on output format which also more faithfully corresponds to the description in the proto file.

Code is now updated so that the decoder no longer accepts the extent input. The decoder output is as described above also with the version field at the layer level. Also updated tests and docs.

Redefining the encoder is a bit more involved. Since the decoder has a getMessage() I'd expect the encoder to have a toMessage() (or similar) that would take a dictionary in the same format and output the binary vector tile data - so it can be round-tripped through both. I don't have the use or time for the encoder right now, would Mapzen be able to handle that?

[rmarianski]

Thanks! The pr looks good to me 👍 If it's ready to go in I'll merge.

I created a ticket to track the work on adding per layer extents to the encoder so it doesn't get lost: #25

[jwass]

Good to go. I can squash if you prefer.

[rmarianski]

I think it's fine the way it is. Thanks again!