[FEA]: Allow users to define precision of coordinates

[jarmak-nv]

Is this a new feature, an improvement, or a change to existing functionality?

New Feature

How would you describe the priority of this feature request

Medium

Please provide a clear description of problem you would like to solve.

Currently coordinates in cuSpatial are FP64 but many users do not require this level of precision.

We can see as much as 2x to 64x speedups dropping to FP32 depending on the hardware used to run cuSpatial. To support this, it would be nice to see a way to define coordinates, either on a global scale or on a per-geoseries scale.

Some potential implementations:

cuspatial.set_coord_precision = float32

Or

On a geoseries/dataframe using GeometryDType and recording coordinate dtype in there, along side with other geoseries specific info (ie crs if we go that route).

Describe any alternatives you have considered

N/A

Additional context

No response

[harrism]

How does geopandas handle precision?

[jarmak-nv]

geopandas might support the changing of precision through Shapely's set_precision() function - I haven't tested this https://shapely.readthedocs.io/en/stable/reference/shapely.set_precision.html - if this doesn't work, then geopandas does not support precision changes as far as I know.

I can do some testing later to check if geopandas overrides and provides a float64 with something like:

import geopandas as gpd
from shapely.geometry import Point

point = Point(0.9, 0.9)
set_precision(point, 1.0)
gdf = gpd.GeoDataFrame(geometry=[point])

type(gdf.loc[0, 'geometry'])

[harrism]

Hmmm, that seems to snap values to a grid of the specified resolution. It doesn't say anything about storing them in lower precision. It provides no way to specify "32-bit", for example, it only mentions that 0 corresponds to "double precision". Seems like it conflates "resolution" and "precision".

[harrism]

libGEOS provides PrecisionModel. https://libgeos.org/doxygen/classgeos_1_1geom_1_1PrecisionModel.html#details Seems related to the above, but has explicit modes for fp32 and fp64.

[jarmak-nv]

Yes you're right - I just tested:

from shapely.geometry import Point

point = Point(0.9, 0.9)
point = set_precision(point, 1.0)
point.coords._coords.dtype
>>> float64

[jarmak-nv]

So, this looks like something not offered by our CPU Python counterparts

[harrism]

However we decide to support this, at the header-only C++ API level it should be trivial, because it is a template library. Depending on whether or not the column-based API already dispatches to both types, supporting both fp32 and fp64 everywhere may double compile time. We already test everything in both single and double precision on the C++ side.