Encode nil or empty list coordinates as EMPTY in WKT

[aseigo]

WKT has the EMPTY keyword for geometries that have no coordinates. e.g. POINT EMPTY or POLYGON EMPTY.

While the WKB encoder appears to handle this fine, the WKT encoder fails to do so. This PR adds both encoding and decoding support for EMPTY geometries to the WKT modules.

I ran into this while working with SpatialLite and needing to send a POINT EMPTY WKT string from a %Geom.Point{} struct. I was then able to replicate this with PostGIS as well, for both the encoding and decoding directions. geo_postgis dodges this bullet by using WKB for all its encoding.

[s3cur3]

Hi @aseigo! The code changes look good. What I'm not clear on is when null geometries would be useful, and whether it's worth making all downstream code cope with this case. For instance, right now the typespec for Geo.Point promises that the coordinates are a lon-lat tuple. It'll be a breaking change (and, for my money, a rather annoying one for users of the library) if we make the coordinates sometimes nil.

I guess what I'm really wondering is: is it important that in these use cases you actually get back a geometry struct, or could we instead return a parsing error or something and thereby maintain our existing guarantees that the coordinates field is never nil?

[aseigo]

when null geometries would be useful,

There are a few reasons for this:

a) It exists in the SQL/MM standard.
b) Certain SQL/MM functions are required to return a "no geometry" response that has to simultaneously be a valid geometry type AND be empty.

You can verify (b) for yourselves with the following query:

postgis_test=# select ST_AsText(ST_Intersection(ST_GeomFromText('POINT (1 1)'), ST_GeomFromText('POINT (0 0)')));
  st_astext
-------------
 POINT EMPTY
(1 row)

So not only is it part of the standard, SQL queries can (and will) return these values. Currently the PostGIS extension chokes on them and errors out, despite it being valid data.

return a parsing error or something

Failing to parse such returns would be incorrect behaviour according to the spec and real-world data. It needs to resolve to something.

The way I stumbled across this was in querying real-world data using this library. :/

I agree that it is a fair point to want to not have nil geometries. Perhaps consider empty ones ([] or {} depending on the type)?

I'm also not entirely sure it's a "breaking" change per se. Currently, it stumbles over valid data (as per the standard), which is very unexpected. Making it not error on valid data sounds like a bugfix?