BUG: `gdf.geometry.total_bounds` reads all columns from Parquet instead of only geometry column about dask-geopandas HOT 5 OPEN

Two questions here:

1. what happens with bounds? Does it also read all columns?
2. what happens with unary_union? That uses a very similar implementation based on reduction.

from dask-geopandas.

bounds and unary_union both correctly read only the geometry column (if doing gdf.geometry.bounds/unary_union of course). So not really sure what's special about total_bounds.
One difference is that it returns an array instead of series/dataframe.

from dask-geopandas.

See dask/dask#7885 for an analysis of the issue. The way to solve it (with current dask at least) is to return a Series/DataFrame object instead of an array.

I was first thinking that might be a too big of a change for total_bounds if we want to keep it consistent with the geopandas version. But, actually a Series of 4 elements might be compatible enough for most use cases. For example the typical unpacking (xmin, ymin, xmax, ymax = gdf.total_bounds) or plain indexing (gdf.total_bounds[0]) should both still work with a Series as well.

from dask-geopandas.

Can we keep this open for some time to see how dask/dask#7885 evolves?

A Series would be okay but to have it compatible in the way you mention gdf.total_bounds[0] it needs to have a range index while it would make more sense to have an index as ['minx', 'miny', 'maxx', 'maxy'].

So I propose to wait a bit and make a decision on this before the actual 0.1. release.

from dask-geopandas.

A Series would be okay but to have it compatible in the way you mention gdf.total_bounds[0] it needs to have a range index while it would make more sense to have an index as ['minx', 'miny', 'maxx', 'maxy'].

A Series with index values ['minx', 'miny', 'maxx', 'maxy'] would actually work for this, because in case of a non-numeric index, indexing with integers like that falls back to positional indexing.

from dask-geopandas.