`st_isvalid(point(NaN, NaN))` is true

[n0099]

SELECT *, st_isvalid(a), st_x(a), st_y(a)
FROM (SELECT st_pointfromwkb('\x0101000000000000000000F8FF000000000000F8FF') a) t;

a	st_isvalid	st_x	st_y
0101000000000000000000F87F000000000000F87F	true	null	null

and in MySQL it will get an error:

SELECT *, st_isvalid(a), st_x(a), st_y(a)
FROM (SELECT st_pointfromwkb(0x0101000000000000000000F8FF000000000000F8FF) a) t;

[22001][3037] Data truncation: Invalid GIS data provided to function st_isvalid.

[mdavis]

GEOS has same behaviour:

bin/geosop -a 0101000000000000000000F8FF000000000000F8FF isValid
true

This is because POINT(NaN Nan) is used as the WKB representation for POINT EMPTY (since WKB doesn't actually provide a representation for an empty POINT).

So this is probably a Won't Fix in GEOS.

[robe]

As @mdavis pointed out to me in IRC, there is no representation for POINT(NaN NaN) in WKB so it gets read as POINT EMPTY which is valid.

However I can create a real NaN as follows and PostGIS does return false:

` SELECT *, st_isvalid(a), st_x(a), st_y(a) FROM (SELECT ST_GeomFromText('POINT(NaN NaN)') a) t;

`

Yields as you'd expect

 Invalid Coordinate at or near point nan nan
                     a                      | st_isvalid | st_x | st_y
--------------------------------------------+------------+------+------
 0101000000000000000000F87F000000000000F87F | f          |  NaN |  NaN
(1 row)

So only question is if it's worthwhile throwing an error or keeping the wkb casting as POINT EMPTY

[mdavis]

Replying to robe:

So only question is if it's worthwhile throwing an error or keeping the wkb casting as POINT EMPTY

I think we have to allow that WKB to represent empty points.

This was discussed in #3181. See also ​https://trac.osgeo.org/geos/ticket/1005

Also this: ​https://gis.stackexchange.com/a/351930/14766

[mdavis]

The ​GeoPackage spec also specifies the same approach:

If the geometry is a Point, it SHALL be encoded with each coordinate value set to an IEEE-754 quiet NaN value. GeoPackages SHALL use big endian 0x7ff8000000000000 or little endian 0x000000000000f87f as the binary encoding of the NaN values. (This is because Well-Known Binary as defined in OGC 06-103r4 [I9] does not provide a standardized encoding for an empty point set, i.e., 'Point Empty' in Well-Known Text.)

[robe]

Closing this out since there is nothing wrong with our NaN handling and the wkb handling was a decision we made a while ago.

FWIW, I checked on MariaDB

and it can't handle NaNs or POINT EMPTY and just returns NULLS for both of those

But interestingly for this

SELECT ST_AsText(st_pointfromwkb(0x0101000000000000000000F8FF000000000000F8FF))

It returns POINT(0 0)