Normalize geometry structure; classify polygon rings #33
Conversation
jfirebaugh
force-pushed
the
classify-rings
branch
from
83da8bc
to
c39d03f
Compare
|
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. |
|
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 👍 |
|
@jfirebaugh @springmeyer should we also do a vector-tile-spec patch version bump that clarifies ring order in multipolygons? |
|
@mourner - yes, I had started this months ago but missed pushing: mapbox/vector-tile-spec#36 |
| var area = signedArea(rings[i]); | ||
| if (area === 0) continue; | ||
|
|
||
| if (!ccw) ccw = area < 0; |
There was a problem hiding this comment.
Just tagging so that we don't forget: the condition should be ccw === undefined, otherwise classification is buggy in certain cases.
|
Next actions here now that we have the v2 spec in place (https://github.com/mapbox/vector-tile-spec/tree/master/2.1):
|
|
Is this outdated now? |
|
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. |
Fixes #32
No change in benchmarked performance.