[postgis-devel] Question about EWKT and Dimension qualifiers

[Paul Ramsey]

TL;DR: don’t change the behaviour of ST_AsEWKT or ST_AsEWKB

ST_AsEWKT is doing exactly what it supposed to, which is emit “extended” WKT. This format pre-dated ISO standards, and was a hacky shim to both support higher dimensionality and SRID numbers. In the “olden days” (pre 2.0)  it is what ST_AsText() emitted. At 2.0 we shifted over to emitting ISO WKT and WKB. You’ll note that ST_AsEWKB() also emits strange “nonstandard” format, as again it has to support higher dimensions and srids, and was invented prior to the official standards taking a position on those topics.

As Raul notes, in some ways EWKT is better than ISO WKT, since it avoids over-specifying dimensionality, and thus avoid whole categories of potential errors that ISO admits. How is one to interpret in ISO world the following?

POINT ZM (1 1)
POINT ZM (1 1 1)
POINT (1 1 1 1)

The relatively ugly, snaggletoothed EWTK doesn’t have those corner cases. A 4-d input is clearly XYZM, since what else could it be? A 3-d input without an ‘m’ flag is clearly XYZ, since what else could it be?

Anyways, that’s al a digression. I have closed https://trac.osgeo.org/postgis/ticket/4561 <https://trac.osgeo.org/postgis/ticket/4561> as invalid

P

> On Nov 8, 2019, at 4:59 AM, rmrodriguez at carto.com wrote:
> 
> My thoughts about this:
> 
> Let's start by saying that changing ST_AsEWKT from `WKT_EXTENDED` to
> `WKT_EXTENDED | WKT_ISO` should be enough to address #4561, but as
> observed quite a bit of tests expect its output to not include `Z`,
> `M` or `ZM` so I wouldn't consider this a bug but an improvement.
> 
> Having said that, now I want to backtrack and think about whether
> we want to address #4561 or not, since doing it involves a breaking
> change. First thing I see is that, even though ST_AsEWKT does not
> include the full dimension qualifiers, the dimension information
> isn't lost:
> 
> ```
> template_postgis=# Select ST_AsEWKT('SRID=4326; POINT Z (0 0 0)');
>       st_asewkt
> ------------------------
> SRID=4326;POINT(0 0 0)
> (1 row)
> 
> template_postgis=# Select ST_AsEWKT('SRID=4326; POINT M (0 0 0)');
>        st_asewkt
> -------------------------
> SRID=4326;POINTM(0 0 0)
> (1 row)
> 
> template_postgis=# Select ST_AsEWKT('SRID=4326; POINT ZM (0 0 0 0)');
>        st_asewkt
> --------------------------
> SRID=4326;POINT(0 0 0 0)
> (1 row)
> ```
> 
> But it isn't different to what I expected before looking at the code,
> which was ST_AsText + SRID information:
> ```
> template_postgis=# Select ST_AsText('SRID=4326; POINT Z (0 0 0)');
>    st_astext
> -----------------
> POINT Z (0 0 0)
> (1 row)
> 
> template_postgis=# Select ST_AsText('SRID=4326; POINT M (0 0 0)');
>    st_astext
> -----------------
> POINT M (0 0 0)
> (1 row)
> 
> template_postgis=# Select ST_AsText('SRID=4326; POINT ZM (0 0 0 0)');
>     st_astext
> --------------------
> POINT ZM (0 0 0 0)
> (1 row)
> ```
> 
> So I see 1 necessary change:
> - Document clearly in ST_AsEWKT that the output doesn't follow WKT_ISO.
> 
> And 1 optional change:
> - Change the behaviour of ST_AsEWKT in 3.1+ to follow ST_AsText footsteps
> and include the dimension qualifiers at all times, thus making a breaking
> change.
> 
> 
> To be honest, if ST_AsEWKT has lived all this time without complains I don't
> think breaking a lot of tests is really worth it and just documenting the
> behaviour more clearly should be enough, but I'd like to hear what's the
> opinion of the "older generation" :D.
> 
> 
> Regards
> -- 
> Raúl Marín Rodríguez
> carto.com
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20191108/f0c16107/attachment.html>