coordEach indexing bug

I noticed this evening that when using coordEach that it doesn’t really deal with holes properly.

So for example I pass in a poly with a hole like

[ [ [ 100, 0 ], [ 101, 0 ], [ 101, 1 ], [ 100, 1 ], [ 100, 0 ] ],
  [ [ 100.2, 0.2 ], [ 100.8, 0.2 ], [ 100.8, 0.8 ],[ 100.2, 0.8 ],[ 100.2, 0.2 ] ]
]

if I do something like

    coordEach(poly, function (currentCoord, currentIndex, featureIndex, featureSubIndex) {
        console.log(currentCoord)
        console.log(currentIndex, featureIndex, featureSubIndex)

I get

[ 100, 0 ]
0 0 0
[ 101, 0 ]
1 0 0
[ 101, 1 ]
2 0 0
[ 100, 1 ]
3 0 0
[ 100.2, 0.2 ]
4 0 0

So the hole get’s the same featureIndex and featureSubIndex as the rest of the poly which means I can’t detect that the coord belongs to a hole.

Would be great to add some polys with holes to the test fixtures to those meta modules.

[DenisCarriere]

👍 Agreed, I’ve added a 3rd index (geometryIndex) which indicates the index when iterating over the geometry (used in Polygon & MultiPolygon geometries).

There are 3 major index tiers which are broken down like so:

• featureIndex => multiFeatureIndex => geometryIndex

Using those 3 indexes you should be able to find your way back to the exact geometry part of the feature.

turf.coordEach(features, function (currentCoord, coordIndex, featureIndex, multiFeatureIndex, geometryIndex) {
  //=currentCoord
  //=coordIndex
  //=featureIndex
  //=multiFeatureIndex
  //=geometryIndex
});

@rowanwins Have a go at it and let me know if you are having any issues with the new update. (Close issue whenever you confirm it’s 👍 )

[DenisCarriere]

I know… Handling Polygons with holes is brutal! Don’t hesitate to test the other @turf/meta modules, we can do another big revamp at the next major release to make it easier to work with by returning Objects in the callbacks.