[postgis-devel] POINT EMPTY in WKB

Paul Ramsey pramsey at opengeo.org
Mon Dec 6 10:01:40 PST 2010


So, the LWGEOM structs happily handle POINT EMPTY now (and mostly have
for some time). And the new serialization will handle POINT EMPTY, so
it will be able to store and retrieve them.

So, what's the problem?

The problem is that the canonical form, the text form of our GEOMETRY
that gets written to the terminal when you type 'select the_geom from
the_table', or to dump files when you pg_dump a database, is still the
old form. It's still EWKB. And I like EWKB! It encodes 99% of
everything we need. But it doesn't encode 'POINT EMPTY'.  (Everything
else can be encoded by setting either npoints or ngeoms to zero (we
will ignore for now that ISO SQL/MM has a contradictory set of
definitions that actually imply that LINESTRING EMPTY is distinct from
a LINESTRING with zero points))

What that means is, for functions that emit EWKB, we have to either
drop 'POINT EMPTY' (turn them into nulls) or transform them (turn them
into 'GEOMETRYCOLLECTION EMPTY').

What that further means is that a database could be different after
being dump/restored. (The effect would also appear in functions like
ST_Dump(), which forces geometries through EWKB on the way out of the
dump (as I recently discovered)).

A final possibility would be to hack POINT EMPTY into WKB, as
something like POINT(nan nan nan) or POINT(inf inf inf) or POINT(-0 -0
-0). There would be a danger there in platforms that have different
interpretations of what nan, inf or -0 are in binary.

Discussion?

P.



More information about the postgis-devel mailing list