5

In data formats like WKT and WKB, we have ways of representing "empty" geometries. That all pretty much makes sense: a "LINESTRING EMPTY" is a LINESTRING type with 0 vertices. Same with a MULTIPOINT, POLYGON, etc.

But what about POINT EMPTY? For starters, there is no WKB representation for a POINT EMPTY, only WKT. GeoJSON also doesn't define this case in its specification.

According to the Wikipedia definition of a geometric point, "points do not have any length, area, volume, or any other dimensional attribute". So how can it be empty, and why does the WKT specification allow this?

4
  • Why whould a line with zero vertices make sense, while a point with no vertices doesn't? They're all really nil geometries, special cases so that dimensionality can be preserved in a column which is restricted to a single datatype.
    – Vince
    Commented Aug 8, 2014 at 11:50
  • It doesn't make sense because POINTs are the primitive of all the other geometries. The other geometries are just collections of POINTs with some specific semantics. Geometrically speaking, a NULL geometry doesn't really make sense. But within a standard like WKB, it's allowed. The problem is, there is no way to represent a POINT EMPTY in WKB. This is a problem if you try to convert between different data formats. WKT and WKB are used very closely together, but there's an inconsistency.
    – larsbutler
    Commented Aug 11, 2014 at 9:12
  • 1
    An Empty Point has as much significance and use, as the number Zero. Commented Aug 11, 2014 at 11:39
  • 1
    Which makes this the same question you asked last time. A point isn't a primitive, it's the most common type of data. The lack of an empty point in WKB is a flaw in WKB, not in the point type.
    – Vince
    Commented Aug 11, 2014 at 11:45

2 Answers 2

5

Sorry for reviving an old thread, the same question came up in the context of the geopackage specification so I thought I might as well answer it here too. The reason you need all these empty geometry types is because the ISO SQL/MM part 3 specification requires them (not explicitly, but indirectly).

As an example ST_Intersection needs to be able to return a 'there is no intersection' value. The type of the returned value (what ST_GeometryType will return when called on the value) depends on the argument types. ST_Intersection(ST_GeomFromText('POINT (1 1)'), ST_GeomFromText('POINT (0 0)') for instance is specified in section 5.1.22 as returning 'an empty set of type point'. So this needs to return a valid ST_Geometry value, ST_IsEmpty should return true for it and ST_GeometryType should return ST_Point.

So what should you get when you execute ST_AsText and ST_AsBinary on that returned value? For WKT the only correct answer I think is POINT EMPTY. For WKB this is poorly defined. WKB does not provide an equivalent of WKT's EMPTY and points don't have a natural empty representation. This is why in GeoPackage there's an empty header bit and it's required to use NaN as the coordinates of the point. The intention is to avoid people accidentally using empty point sets as a regular point value. NaN works as an absorbing element, so it's pretty obvious when you've made a mistake since the outcome of your calculations is very likely to be NaN as well.

Note that in many implementations, like PostGIS for instance, the above example will return GEOMETRYCOLLECTION EMPTY instead. That's strictly speaking not compliant with the ISO spec since the type of the return value is not correct.

So to answer the question 'why do you have all these different empty types in WKT and WKB'? Because WKT and WKB are, as far as I know, defined in the SQL/MM part 3 specification, that specification defines distinct typed empty sets for each geometry type and as a consequence WKT and WKB need to have a representation for these typed empty sets.

1

This is probably answered in Empty geometries in GEOMETRYCOLLECTION which refers also to http://trac.osgeo.org/postgis/wiki/DevWikiEmptyGeometry. A practical use case for many GIS programs like QGIS which can only hold one sort of geometries on a single layer is to make it possible to import attributes into a new layer and initialize it correctly so it can accept geometries which may come later. Therefore POINT EMPTY is useful and not the same as LINESTRING EMPTY.

That WKT defines POINT EMPTY but WKB not is a known issue. In recent OGC GeoPackage standard empty geometries are marked with a special flag http://www.geopackage.org/spec/. One reason for this is just the POINT EMPTY case and it is mentioned in the standard text:

"Well-Known Binary as defined in ISO 13249-3 [12] does not provide a standardized encoding for an empty point set (i.e., Point Empty in Well-Known Text). In GeoPackages these points SHALL be encoded as a Point where each coordinate value is set to an IEEE-754 quiet NaN value."

2
  • 1
    It wasn't really answered there. That question was specifically about the behavior of geometry collections of empty things. The current question is more about consistency within the standards. I'm more or less fine with there being a strange thing like a null/empty POINT, but the problem is, there's binary representation of it!
    – larsbutler
    Commented Aug 11, 2014 at 9:16
  • I do not know if such answer exists. Missing POINT EMPTY in WKB can perhaps be considered as a bug but accepted standards do not change so easily. However, the OGC GeoPackage standard considers this case geopackage.org/spec Well-Known Binary as defined in ISO 13249-3 [12] does not provide a standardized encoding for an empty point set (i.e., Point Empty in Well-Known Text). In GeoPackages these points SHALL be encoded as a Point where each coordinate value is set to an IEEE-754 quiet NaN value.
    – user30184
    Commented Aug 11, 2014 at 9:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.