pystac
pystac copied to clipboard
stac-utils
Implement `__geo_interface__`
__geo_interface__ is a way for Python objects to return geojson (-like) representations of themselves. Should pystac objects implement this?
This might be helpful for cases like https://github.com/stac-utils/pystac-client/issues/146, where libraries want to support a range of geojson-like objects without having to know how to convert each particular object to geojson.
Should pystac objects implement this?
Probably just Item since its the only STACObject that has a defined geometry?
Collection could also conceivably implement this by creating a Polygon or MultiPolygon from Collection.extent.spatial (depending on how many bboxes are present). In the case of a single bbox we could construct a single polygon. For multiple bboxes we could ignore the first bbox and construct a MultiPolygon from the remaining boxes. I could see that being a useful way of filtering collections to see which ones overlap another geometry.
Item is definitely the clearest, and John's suggestion for Collections make sense.
ItemCollection is a bit murky. There's a comment on that gist about letting __geo_interface__ include FeatureCollection, but it didn't seem to go anywhere.
ItemCollectionis a bit murky. There's a comment on that gist about letting__geo_interface__includeFeatureCollection, but it didn't seem to go anywhere.
Yeah, the ItemCollection implementation seems murky to me. It seems like it would be most appropriate to represent it as a GeometryCollection since it could conceivably contain geometries of different types. shapely seems to support most geometric operations (but not affine transformations) on GeometryCollections, but it doesn't seem to have the same support for FeatureCollections (shapely/shapely#770).
Maybe we should also support this for SpatialExtent. We could follow the same process I suggested above for Collections and then just surface that in Collection.__geo_interface__, too.
Strongly in favor of implementing this for Item, since a STAC Item is a GeoJSON Feature with foreign members.
I'm not clear on what the value is for Collection or ItemCollection, so I think it would be better not to do that until we can really determine how it would be used.
