Comments on: SqlGeometry and POINT EMPTY in WKB

By: mloskot

mloskot — Wed, 03 Mar 2010 16:07:29 +0000

Paul,

I agree with you. The geometry collection trick is far from ideal. However, with I’m rather having in mind problems that may occur trying to parse truncated WKB of POINT EMPTY while having no flag indicating if it’s empty or not:

010100000000000000

I mean, this would be a serious issue for C/C++ and similar languages.

By: Paul Ramsey

Paul Ramsey — Wed, 03 Mar 2010 01:25:59 +0000

I don’t really agree that pushing all empties down into a geometry collection is so wise. Practically, it means we are making our data less expressive as we transit WKB. Typed empties exist, they are in the spec, and our functions can emit them, so we should express them. I just wish there was some way to express POINT EMPTY. Oh, and I wish the ISO SQL/MM spec didn’t contradict the implementation facts on the ground.

By: GIS-Lab Blog» ????? ????? » ??????? ?????? 40

GIS-Lab Blog» ????? ????? » ??????? ?????? 40 — Tue, 02 Mar 2010 12:09:58 +0000

[...] ??? ???????? «?????? ?????????» ? ???????? WKB. [...]

By: mloskot

mloskot — Sat, 27 Feb 2010 14:19:51 +0000

Even, of course it would be a security issue if POINT EMPTY is truncated to 9 bytes, especially in languages as C or C++. And I have pointed out this problem. However, a consistent approach is needed and in my personal opinion PostGIS approach is the most reasonable. User learns that for every EMPTY geometry he can expect empty collection, so his code can become more generic, without checking a type, just checking size component and performing zero iteration over the bytes stream. Shortly, IMO, all EMPTY should evaluate to

010700000000000000

Back to OGR. It's a bad idea to report POINT(0 0) for POINT EMPTY and it is actually invalid as these two geometries are not equivalent. The former is non-empty valid point of both coordinates of Zero, the latter is valid geometry with no coordinates initialized. I'm sure you get my point.

By: Even Rouault

Even Rouault — Sat, 27 Feb 2010 13:08:50 +0000

Actually, as you suggested, accepting to truncate to 9 bytes for POINT EMPTY would not work for code that imports wkb without knowing the length of the string (which is a bad practice from a security point of view as the code cannot check for malformed wkb)

For example, OGRGeometry::importFromWkb( unsigned char *, int = -1 ) takes the length of the binary content as optionnal argument. If the size is specified (second argument >=0), it can check that no read outside of the buffer is attempted. Otherwise it supposes that the passed buffer is large enough.

One could imagine to represent the wkb form of POINT EMPTY by setting one of the most significant bit of the 4 bytes used for the geometry type, as it is done to specify the Z or M form. Or add a new geometry type just meaning “POINT EMPTY”. Hum, another proof that emptyness is a non trivial concept ;-)

By: Even Rouault

Even Rouault — Sat, 27 Feb 2010 12:48:41 +0000

As far as OGR is concerned, here's the output of :

from osgeo import ogr
import binascii

wktlist = [ 'POINT EMPTY',
            'LINESTRING EMPTY',
            'POLYGON EMPTY',
            'MULTIPOINT EMPTY',
            'MULTILINESTRING EMPTY',
            'MULTIPOLYGON EMPTY',
            'GEOMETRYCOLLECTION EMPTY' ]

for wkt in wktlist:
    geom = ogr.CreateGeometryFromWkt(wkt)
    wkb = geom.ExportToWkb(ogr.wkbNDR)
    geom2 = ogr.CreateGeometryFromWkb(wkb)
    print wkt
    print '%s (%d bytes)' % (binascii.hexlify(wkb), len(wkb))
    print 'After importing wkb : %s' % geom2.ExportToWkt()
    print



POINT EMPTY
010100000000000000000000000000000000000000 (21 bytes)
After importing wkb : POINT (0 0)

LINESTRING EMPTY
010200000000000000 (9 bytes)
After importing wkb : LINESTRING EMPTY

POLYGON EMPTY
010300000000000000 (9 bytes)
After importing wkb : POLYGON EMPTY

MULTIPOINT EMPTY
010400000000000000 (9 bytes)
After importing wkb : MULTIPOINT EMPTY

MULTILINESTRING EMPTY
010500000000000000 (9 bytes)
After importing wkb : MULTILINESTRING EMPTY

MULTIPOLYGON EMPTY
010600000000000000 (9 bytes)
After importing wkb : MULTIPOLYGON EMPTY

GEOMETRYCOLLECTION EMPTY
010700000000000000 (9 bytes)
After importing wkb : GEOMETRYCOLLECTION EMPTY

So OGR behaves like SqlGeometry, except for the POINT EMPTY case where it fallbacks to exporting it as POINT (0, 0) in wkb. Truncating the wkb of POINT EMPTY to 9 bytes might make sense for the sake of consistency, but it would require an update of the OGC SF spec