Opened 9 years ago

Closed 9 years ago

#3181 closed enhancement (fixed)

Output POINT EMPTY in WKB using NaN as coordinate values

Reported by: pramsey Owned by: pramsey
Priority: high Milestone: PostGIS 2.2.2
Component: postgis Version: master
Keywords: Cc: robe

Description

Our old handling of overloading POINT EMPTY to convert into MULTIPOINT EMPTY results in outputs that are not actually consistent in type (that's a problem). A better hack would be using POINT(NaN NaN) to proxy for POINT EMPTY, since there's not much practical use for a POINT(NaN NaN) anyways. This means that database with "legitimate" POINT(NaN NaN) values would get them converted into POINT EMPTY on dump/restore, but that seems a small price to pay for the greater good.

This was discussed in #3031.

Change History (6)

comment:1 by pramsey, 9 years ago

Resolution: fixed
Status: newclosed

Done in trunk only at r13707. Not patching back to 2.1 etc.

comment:2 by robe, 9 years ago

Resolution: fixed
Status: closedreopened

broke sfcgal regress

 sfcgal/tickets .. failed (diff expected obtained: /projects/postgis/tmp/2.2.0dev_pg9.4_geos3.5.0dev_gdal2.0.0w64/test_116_diff)
-----------------------------------------------------------------------------
--- sfcgal/tickets_expected	2015-05-15 04:28:13 -0400
+++ /projects/postgis/tmp/2.2.0dev_pg9.4_geos3.5.0dev_gdal2.0.0w64/test_116_out	2015-06-25 16:31:23 -0400
@@ -184,7 +184,7 @@
 #1453.2|f
 #1454|t
 #1414|CURVEPOLYGON Z EMPTY
-#1478|MULTIPOINT EMPTY
+#1478|POINT EMPTY
 #745|GEOMETRYCOLLECTION(POLYGON((-72 42 1,-70 43 1,-71 41 1,-72 42 1)))
 #1450|POINT|POLYGON
 #1482|4326

comment:3 by pramsey, 9 years ago

Resolution: fixed
Status: reopenedclosed

Altered that test at r13710

comment:4 by strk, 9 years ago

Milestone: PostGIS 2.2.0PostGIS 2.2.2
Resolution: fixed
Status: closedreopened

Reopening as NaN was found not to be portable, see #3426

comment:5 by pramsey, 9 years ago

Rather than using a dynamic NAN as we do now (using a #defined NAN or a calculated 0/0 NAN) what if we used an IEEE NAN all the time, just hardcode the bytes? It would then be portable. For weirdo platforms it might overlap a single legitimate value so we'd be taking a 1 in HUGE chance of collision, but I'd accept those terms.

comment:6 by pramsey, 9 years ago

Resolution: fixed
Status: reopenedclosed

I'm closing this back out, please see https://trac.osgeo.org/postgis/ticket/3426#comment:11 for reasoning.

Note: See TracTickets for help on using tickets.