[BUG]: cuspatial.core._column.geocolumn.GeoColumn._from_points_xy has some type issue

[thomcom]

Version

23.04

On which installation method(s) does this occur?

Rapids-Compose

Describe the issue

This private helper method needs to have some more careful type enumeration taking place. If you create a column using this method from a column of type int64, the resulting column contains all zeros.

Minimum reproducible example

import cupy as cp
import cudf
long = cudf.Series(cp.arange(20))
series = cuspatial.GeoSeries(cuspatial.core._column.geocolumn.GeoColumn._from_points_xy(long._column))
series

Relevant log output

0    POINT (0.00000 0.00000)
1    POINT (0.00000 0.00000)
2    POINT (0.00000 0.00000)
3    POINT (0.00000 0.00000)
4    POINT (0.00000 0.00000)
5    POINT (0.00000 0.00000)
6    POINT (0.00000 0.00000)
7    POINT (0.00000 0.00000)
8    POINT (0.00000 0.00000)
9    POINT (0.00000 0.00000)
dtype: geometry

Environment details

rapids-compose

Other/Misc.

No response

[isVoid]

I would assume you don't want to construct a coordinate array with integers. We should raise an error if the input is an integer column.

[thomcom]

I know that downstream types will be safely converted to the proper type for use with point-in-polygon, I'm not strongly opinionated about this.

[isVoid]

I admit I don't know enough about coordinate representation in GIS applications. Are there any application/coordinate system/storage system that adopts integer to store coordinates? I know morton code is used as a compression technique in some cases but we don't expose them in user code space. Libgeos uses a precision grid to store coordinates, but representation is still is floating point numbers (?). So I'm not sure about supporting additional dtypes in cuSpatial.

Reducing the number of dtypes supported also reduces the cost of maintenance.

@jarmak-nv @zhangjianting