Opened 4 years ago

Closed 3 years ago

#4827 closed defect (fixed)

Accept NaN from WKT parser

Reported by: strk Owned by: pramsey
Priority: medium Milestone: PostGIS 3.1.2
Component: postgis Version: master
Keywords: Cc:


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

Change History (10)

comment:1 by mdavis, 4 years ago

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

comment:2 by pramsey, 3 years ago

Milestone: PostGIS 3.1.1PostGIS 3.1.2

comment:3 by edzer, 3 years ago

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

comment:5 by pramsey, 3 years ago

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?

Last edited 3 years ago by pramsey (previous) (diff)

comment:6 by pramsey, 3 years ago

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])));
Last edited 3 years ago by pramsey (previous) (diff)

comment:7 by pramsey, 3 years ago

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'));

comment:8 by edzer, 3 years ago

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?

comment:9 by strk, 3 years ago

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…

comment:10 by Paul Ramsey <pramsey@…>, 3 years ago

Resolution: fixed
Status: newclosed

In 83480f5/git:

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

Note: See TracTickets for help on using tickets.