Normalize geometry structure; classify polygon rings

[jfirebaugh]

Fixes #32

No change in benchmarked performance.

[jfirebaugh]

Downside of this change is that client code may need to switch on the geometry type in cases where it wants to handle all types of geometry in a uniform manner (e.g. do something to each vertex or ring). This is the case with mapbox-gl-native.

[mourner]

Looks good to me. I was worried about performance degrade since all polygon features now go through ring classification (since there's no other way to determine if something is Polygon or MultiPolygon), but if benchmarks are fine, I'm 👍

[mourner]

@jfirebaugh @springmeyer should we also do a vector-tile-spec patch version bump that clarifies ring order in multipolygons?

[springmeyer]

@mourner - yes, I had started this months ago but missed pushing: mapbox/vector-tile-spec#36

[mourner]

Just tagging so that we don't forget: the condition should be ccw === undefined, otherwise classification is buggy in certain cases.

[springmeyer]

Next actions here now that we have the v2 spec in place (https://github.com/mapbox/vector-tile-spec/tree/master/2.1):

• Add test/testcases with v2 tiles (These can be generated with tippecanoe or Mapbox Studio Classic)
• merge and release, test in mapbox-gl-js
• get on official tag: mapbox/vt2geojson@4724db1

[mourner]

Is this outdated now?

[jfirebaugh]

No, not really. This is still a change that would make the vector-tile-js API a bit cleaner and remove the need for downstream clients to do ring classification, at the cost of a semver-major release.