2

I am relatively new to Earth Engine and am trying to understand GeometryCollection elements. I have seen this post, but otherwise haven't found much additional information. Coming from desktop GIS software, the notion of a single Feature with multiple geometric types is unusual. A couple of related questions:

(1) Conceptually: For a given Feature whose geometries are defined by a GeometryCollection, is it possible to remove portions of a GeometryCollection, or does that violate internal topology? For instance, if a single Feature is composed of LineString and Polygon types, does removing the LineString components somehow invalidate the Polygon types, since they are inherently bound together?

(2) Practically: The following example returns a FeatureCollection whose Feature geometries are either Polygon, MultiPolygon, or GeometryCollection. GeometryCollection geometries are composed of LineString and Polygon geometries. If it is possible to remove portions of GeometryCollections per (1) above, how would this be accomplished? The goal is to reduce the parent FeatureCollection into a single geometry type (or set of geometry types) that can be exported to shapefile (it does not appear that Earth Engine has built-in functionality to clean/separate incompatible GeometryCollection elements during export).

(3) There are plenty of operations that could be performed on mixed geometries, and for enormous datasets there may be some non-trivial space/cost reduction by using LineStrings instead of Polygons with near-zero width. However, if there is additional rationale for permitting mixed geometries, I would love to hear it.

// Area of interest
var aoi = ee.Geometry.Rectangle([-82.4685, 23.5529, -75.5471, 27.8867])
// Load and filter Earth Engine asset
var polys = ee.FeatureCollection("FAO/GAUL/2015/level2").filterBounds(aoi)
// Store Feature geometry type as a Feature-level property for filtering
polys = polys.map(function(f) {
  return f.set('geo_type', f.geometry().type())
})
// View full collection
print(polys)
// Isolate and view GeometreyCollection elements
var nonPoly = polys.filter(ee.Filter.eq('geo_type', 'GeometryCollection'))
print(nonPoly)

// Visualize as needed
// Map.setCenter(-78.6, 25)
// Map.addLayer(nonPoly)

// Convert GeometryCollection elements into Polygon or MultiPolygon elements
// ????

How to filter through geometry of feature collection instead of properties?

2

For a given Feature whose geometries are defined by a GeometryCollection, is it possible to remove portions of a GeometryCollection, or does that violate internal topology?

Yes, that's fine — the elements of the GeometryCollection are independent and individually consistent.

If it is possible to remove portions of GeometryCollections per (1) above, how would this be accomplished?

You can use ee.Geometry.geometries() to break apart a collection into an ee.List of geometries.

var withoutNonPoly = nonPoly.map(function (feature) {
  // This can't (I think) be expressed as an ee.Filter, so use map & dropNulls instead
  var filteredGeoms = feature.geometry().geometries().map(function (geometry) {
    geometry = ee.Geometry(geometry);
    // Test is reversed because we don't have a simple "equals" and compareTo
    // returns 0 for equal.
    return ee.Algorithms.If(geometry.type().compareTo('Polygon'), null, geometry);
  }, /* dropNulls= */ true);
  return feature.setGeometry(ee.Geometry.MultiPolygon(filteredGeoms));
});

I'm not sure if the above code is the best available way to handle this because I haven't personally worked with geometry collections much.

There are plenty of operations that could be performed on mixed geometries, and for enormous datasets there may be some non-trivial space/cost reduction by using LineStrings instead of Polygons with near-zero width. However, if there is additional rationale for permitting mixed geometries, I would love to hear it.

It's not just "space/cost reduction"; it can also be that, under various transformations and reprojection, using an error margin greater than zero or merely due to numerical precision, a geometry may become fully degenerate — a polygon becoming zero area and thus a line string, or a line string becoming zero length and thus a point. Thus, heterogenous geometry collections must exist to avoid giving errors or discarding data.

Additionally, the GeoJSON format allows such collections, so Earth Engine must allow them in order to support GeoJSON.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.