We had some discussion in Shapely on changing the STRtree API in preparation for Shapely 2.0 / pygeos integration (shapely/shapely#1064, shapely/shapely#1112). And this eventually resulted in adding a query_geoms / query_items to return geometries and indices, respectively (instead of my original proposal to deprecate the current behaviour of returning geometries / adding a keyword to trigger this). The existing query was kept as alias of query_geoms.
And for the nearest query, we similarly now have nearest_geom and nearest_item.
I think it could be useful if we can already start adding methods to PyGEOS' STRtree that will be consistent with the future Shapely, so the eventual migration of pygeos to shapely 2.0 can be easier for the early adapters that are already using pygeos now.
Alternatively, we can also keep it as is for now, and deal with those API changes at the moment when doing this pygeos->Shapely 2.0 migration (since that will involve some changes anyway, it might also be fine to wait until then with this). But we need to be prepared that there will be API changes at that point (or already start discussing that with other Shapely devs right now if we rather want to see changes in Shapely's API).
If we already want to prepare for this, some questions:
- The
query method clashes with the Shapely version. Do we add a query_items in pygeos? (and deprecate query?)
- The
query_bulk concept doesn't yet exist in Shapely, so that's something we can keep as is (if the naming fits in the scheme of Shapely)
- The
nearest and nearest_all methods have a different interface as Shapely's nearest/nearest_item, which return a single index and not an array of left+right indices. So in a sense, the pygeos method is more like a "nearest_bulk" ? (although I don't like that name)
We had some discussion in Shapely on changing the
STRtreeAPI in preparation for Shapely 2.0 / pygeos integration (shapely/shapely#1064, shapely/shapely#1112). And this eventually resulted in adding aquery_geoms/query_itemsto return geometries and indices, respectively (instead of my original proposal to deprecate the current behaviour of returning geometries / adding a keyword to trigger this). The existingquerywas kept as alias ofquery_geoms.And for the nearest query, we similarly now have
nearest_geomandnearest_item.I think it could be useful if we can already start adding methods to PyGEOS' STRtree that will be consistent with the future Shapely, so the eventual migration of pygeos to shapely 2.0 can be easier for the early adapters that are already using pygeos now.
Alternatively, we can also keep it as is for now, and deal with those API changes at the moment when doing this pygeos->Shapely 2.0 migration (since that will involve some changes anyway, it might also be fine to wait until then with this). But we need to be prepared that there will be API changes at that point (or already start discussing that with other Shapely devs right now if we rather want to see changes in Shapely's API).
If we already want to prepare for this, some questions:
querymethod clashes with the Shapely version. Do we add aquery_itemsin pygeos? (and deprecatequery?)query_bulkconcept doesn't yet exist in Shapely, so that's something we can keep as is (if the naming fits in the scheme of Shapely)nearestandnearest_allmethods have a different interface as Shapely'snearest/nearest_item, which return a single index and not an array of left+right indices. So in a sense, the pygeos method is more like a "nearest_bulk" ? (although I don't like that name)