Hi @adishavit , thanks for your suggestion.

Personally I think it is incorrect conceptually to give a simple geometry a “.geoms” attribute.

Many Shapely operation have polymorphic return types: that is, the type of the return value may be different depending on the input (buffer, union, intersection etc.) and may also be different from the input type ofc.

The fact that such functions (e.g. .buffer()) take a shape (e.g. Polygon) and may return either a shape, "simple geometry", (Polygon) or a "collection" (MultiPolygon) as valid return types, already blurs the line between what is a so-called "collection" and what is not.

Adding .geoms to all geometries allows us to write type-agnostic code: everything provides a shape iterator interface.
This simplifies code, making it less verbose and also less error prone.

My own all_poly_iter() function (and similar related functions) are in frequent use on my team and make the code much easier to reason about with less need for verbose special case handling.

Nevertheless, this is an opt-in feature, so if one does not want to use it, they are welcome to avoid it.

I can see your argument and I tend towards approving this change. If your team uses this frequently then it probably has more use cases too. But I'd like to hear @sgillies 's opinion about this as well.

Just for some context, geopandas.GeoSeries has a .geometry property that returns self, to allow obj.geometry to return a series no matter if obj is a GeoDataFrame or GeoSeries. It is a similar logic as proposed here.

@adishavit @caspervdw In the past I've been interested in eliminating the distinction between a Polygon and a MultiPolygon with one part, but I couldn't find anybody else who cared. I suspect some algorithms are much more efficient if you know that the input is a single valid polygon and not several polygons. But I don't see harm in generalizing geoms to single part geometry types. If I were do it all over again, I might name the property parts, but geoms is fine. I think this suggestion is a good example of defining errors out of existence (as John Ousterhout would say).

Ok let’s do it! @adishavit do you have the time to do the PR?

Also looking forward to this! I don't like how methods like union_all can return many different types, and I need to check each one when parsing them.

An alternative would be to add a constructor for GeometryCollection that receives any geometry. It would also be cool to have one for MultiPolygon that receives a MultiPolygon or Polygon, one for MultiLineString that receives MultiLineString or LineString, etc.

Ideally, I would prefer that union_all, etc., always return the same type, but that would be a breaking change.