flatten: Geometry Collection in Feature Collection does not flatten

[dpmcmlxxvi]

While working on a PR for #692 to create a flattenEach method I noticed that @turf/flatten does not appear to flatten a geometry collection that is inside a feature collection. See the jsfiddle.

Not sure if this is the intended behavior. The GeoJSON spec discourages nesting geometry collections but I see nothing about nesting a geometry collection in a feature collection. So, seems like a valid use case.

I was planning on having the PR for #692 iterate over the same features that are yielded using @turf/flatten so I'd like some clarification on what is the desired behavior. If the current implementation is a bug than I can use a proper flattening in the PR.

The fix for the current implementation seems simple enough. Have an additional check for a GeometryCollection type in the switch case of flattenFeatureCollection.

case 'MultiPoint':
case 'MultiLineString':
case 'MultiPolygon':
case 'GeometryCollection':
    featureEach(flatten(multiFeature), function (feature) {
        features.push(feature);
    });
break;

• GeoJSON data as a gist file or geojson.io (filename extension must be .geojson).
• Snippet of source code or for complex examples use jsfiddle.

[DenisCarriere]

Never knew that GeometryCollection inside a FeatureCollection was a thing (seems like it is), you are correct by saying nested GeometryCollection shouldn't be allowed.

You might have issues using featureEach on a Geometry Collection since that will only return Features, you will need to use geomEach if you want to iterate over the Geometry Collection.

Question: Should the output remain a FeatureCollection regardless of the input geometry (open to suggestions)?

Input	Output
Feature<Point>	FeatureCollection<Point>
Feature<MultiPoint>	FeatureCollection<Point>
FeatureCollection<MultiPoint>	FeatureCollection<Point>
Geometry<Point>	FeatureCollection<Point>
Geometry<MultiPoint>	FeatureCollection<Point>
GeometryCollection<Point>	FeatureCollection<Point>

[DenisCarriere]

@dpmcmlxxvi I'm starting to get the same frustrations you're having using the @turf/flatten module. There's definitely a place for having flattenEach & flattenReduce in @turf/meta. 👍

[dpmcmlxxvi]

Agreed. I think having a FeatureCollection<Point|LineString|Polygon> as output regardless of input would be the most expected result. At least to me that's what the word flatten most suggests - reducing everything to a single geometries.

[DenisCarriere]

👍 Another thing I noticed with flatten is when you provide a Geometry Object it returns a FeatureCollection with Geometries (not Features).

@dpmcmlxxvi Let me know if you want to tackle adding flattenEach & flattenReduce to @turf/meta or do you want me to take care of it? Most of the logic is already done, just need to piece it all together.

Once this is finished, @turf/flatten will simply be using flattenEach and return a FeatureCollection<any> (will probably end up being 5 lines of code) 👍 .

[dpmcmlxxvi]

@DenisCarriere Yeah, I'll be submitting the PR pretty soon. Agree on it hopefully simplifying the flatten code. All the crucial logic is already being done in geomEach.

[dpmcmlxxvi]

Flattening GeometryCollection in FeatureCollection is now supported in @turf/meta/flattenEach @turf/flatten with updates #712 and #724. In fact, it should now support any valid GeoJSON.