Opened 7 months ago

Closed 7 months ago

#5718 closed defect (wontfix)

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

Reported by: n0099 Owned by: pramsey
Priority: medium Milestone:
Component: postgis Version: 3.4.x
Keywords: Cc: n0099

Description

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

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.

Change History (6)

comment:1 by n0099, 7 months ago

Cc: n0099 added

comment:2 by mdavis, 7 months ago

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.

Last edited 7 months ago by mdavis (previous) (diff)

comment:3 by robe, 7 months ago

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

Last edited 7 months ago by robe (previous) (diff)

in reply to:  3 comment:4 by mdavis, 7 months ago

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

Last edited 7 months ago by mdavis (previous) (diff)

comment:5 by mdavis, 7 months ago

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.)

comment:6 by robe, 7 months ago

Resolution: wontfix
Status: newclosed

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)

Note: See TracTickets for help on using tickets.