Accept NaN from WKT parser

[strk]

I know this is going to be controversial, but it doesn't seem good to me that the output of ST_AsText() cannot be read back by the WKT parser. Here's one such case:

select ST_AsText(ST_MakeLine(ST_MakePoint('NAN', 'NAN'),ST_MakePoint(0, 0)));
select ST_AsText(ST_MakeLine(ST_MakePoint('NAN', 'NAN'),ST_MakePoint(0, 0)))::geometry;

The first statement works, outputting LINESTRING(NaN NaN,0 0), the second statement, which tries reading that WKT back, fails with: ERROR: parse error - invalid geometry

References #4825 as this limitation makes testing harder

[mdavis]

+1 for this. It is certainly good to be able to round-trip all WKT strings. And adding support for NaN in WKT seems relatively harmless, since it should rarely happen except deliberately.

[edzer]

+1 for round-tripping. But what does this geometry mean? Why does ST_MakePoint('NAN', 'NAN') result in a valid point?

[pramsey]

Try it out here, ​https://github.com/postgis/postgis/pull/600

[pramsey]

PostGIS has already made its peace with representing invalid geometries. You can load all kinds of bad stuff. However, thanks for this reminder that there's actually other things you can hand-build in PostGIS that you cannot round trip.

select st_astext(st_makeline(ARRAY['POINT(0 0)'::geometry]));

Making "round trip" a principle also opens the door to geometries with Inf coordinates. What's the UTILITY of doing all this?

[pramsey]

I'm not sure if the solution is "allow crazy things into WKT" or "don't allow people to hand build crazy things in PostGIS". For example, you can't hand build a Polygon with < 4 points.

select st_astext(st_makepolygon(st_makeline(ARRAY['POINT(0 0)'::geometry])));

[pramsey]

I mean, it goes on and on… particularly with POINT(NaN NaN), which can't be round-tripped through WKB, since WKB needs that form to encode POINT EMPTY.

select st_astext(st_geomfromwkb(st_asbinary(ST_MakePoint('NAN', 'NAN'))));
select st_astext(ST_MakePoint('NAN', 'NAN'));

[edzer]

It is reasonable to require that all coordinates are finite. If you don't, you need to cope with the problems such geometries cause downstream, like in geom operations.

Does some of this have its roots in the simple feature standard's lacking WKB definition for POINT EMPTY?

[strk]

The reason to _allow_ it, is to make PostGIS a useful tool to _fix_ them. You can't fix them if you can't take them.

The other reason is to be able to restore what you dump. If due to a bug your geometries end up with infinite or Nan ordinate values you can get stuck, can't upgrade or transfer (dump/restore) because PostGIS won't accept them…

[Paul Ramsey <pramsey@…>]

In 83480f5/git:

Accept 'Nan' coordinates in WKT input, to allow for round-tripping of oddball bad geometry.
Closes #4827