ENH: Prevent creation of geometries with NaN coordinates

It seems that pygeos incorrectly reports that ‘has_z’ is false in case the first z-coordinate is NaN. This leads to the z-dimension getting culled in shapely/geopandas.

Traced this bug after getting funky results in geopandas. https://github.com/geopandas/geopandas/issues/1888

import numpy as np
import pygeos
import shapely.wkb

coords1 = [
    (1, 2, 3),
    (1, 1, np.NaN),
]

coords2 = [
    (1, 1, np.NaN),
    (1, 2, 3),
]

for coords in [coords1, coords2]:
    geom1 = pygeos.creation.linestrings(coords)
    print(pygeos.geometry.get_coordinate_dimension(geom1))
    print(pygeos.predicates.has_z(geom1))
    print(pygeos.coordinates.get_coordinates(geom1, include_z=True))
    geom2 = shapely.wkb.loads(pygeos.to_wkb(geom1))
    print(np.array(geom2.coords))
    print('\n')

Output

3
True
[[ 1.  2.  3.]
 [ 1.  1. nan]]
[[ 1.  2.  3.]
 [ 1.  1. nan]]


3
False
[[ 1.  1. nan]
 [ 1.  2.  3.]]
[[1. 1.]
 [1. 2.]]

[caspervdw]

I’d like to make a bold proposal: block NaN in geometry creation functions (just skip NaN coordinates, like we do with None for polygon/multi geometries)

Associated with this, we might create force_2d and force_3d functions. The force_3d takes an optional argument z_value, which cannot be NaN and defaults to 0.0 (like with PostGIS: https://postgis.net/docs/ST_Force_3D.html)

[brendan-ward]

Using a well-defined NODATA value for Z values seems better than using NaN; in the raster they are actually a number that has a NODATA interpretation, as opposed to something that is unrepresentable as a number. The raster dataset should define this NODATA value, so you can just use that, right? In either case, you run the risk of any interpolation applied to Z values unless you handle the NODATA values properly, and using a defined number sidesteps all the issues around GEOS and NaN.