<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">TL;DR: don’t change the behaviour of ST_AsEWKT or ST_AsEWKB</div><div class=""><br class=""></div>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.<div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">POINT ZM (1 1)</div><div class="">POINT ZM (1 1 1)</div><div class="">POINT (1 1 1 1)</div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">Anyways, that’s al a digression. I have closed <a href="https://trac.osgeo.org/postgis/ticket/4561" class="">https://trac.osgeo.org/postgis/ticket/4561</a> as invalid</div><div class=""><br class=""></div><div class="">P<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 8, 2019, at 4:59 AM, <a href="mailto:rmrodriguez@carto.com" class="">rmrodriguez@carto.com</a> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">My thoughts about this:<br class=""><br class="">Let's start by saying that changing ST_AsEWKT from `WKT_EXTENDED` to<br class="">`WKT_EXTENDED | WKT_ISO` should be enough to address #4561, but as<br class="">observed quite a bit of tests expect its output to not include `Z`,<br class="">`M` or `ZM` so I wouldn't consider this a bug but an improvement.<br class=""><br class="">Having said that, now I want to backtrack and think about whether<br class="">we want to address #4561 or not, since doing it involves a breaking<br class="">change. First thing I see is that, even though ST_AsEWKT does not<br class="">include the full dimension qualifiers, the dimension information<br class="">isn't lost:<br class=""><br class="">```<br class="">template_postgis=# Select ST_AsEWKT('SRID=4326; POINT Z (0 0 0)');<br class=""> st_asewkt<br class="">------------------------<br class=""> SRID=4326;POINT(0 0 0)<br class="">(1 row)<br class=""><br class="">template_postgis=# Select ST_AsEWKT('SRID=4326; POINT M (0 0 0)');<br class=""> st_asewkt<br class="">-------------------------<br class=""> SRID=4326;POINTM(0 0 0)<br class="">(1 row)<br class=""><br class="">template_postgis=# Select ST_AsEWKT('SRID=4326; POINT ZM (0 0 0 0)');<br class=""> st_asewkt<br class="">--------------------------<br class=""> SRID=4326;POINT(0 0 0 0)<br class="">(1 row)<br class="">```<br class=""><br class="">But it isn't different to what I expected before looking at the code,<br class="">which was ST_AsText + SRID information:<br class="">```<br class="">template_postgis=# Select ST_AsText('SRID=4326; POINT Z (0 0 0)');<br class=""> st_astext<br class="">-----------------<br class=""> POINT Z (0 0 0)<br class="">(1 row)<br class=""><br class="">template_postgis=# Select ST_AsText('SRID=4326; POINT M (0 0 0)');<br class=""> st_astext<br class="">-----------------<br class=""> POINT M (0 0 0)<br class="">(1 row)<br class=""><br class="">template_postgis=# Select ST_AsText('SRID=4326; POINT ZM (0 0 0 0)');<br class=""> st_astext<br class="">--------------------<br class=""> POINT ZM (0 0 0 0)<br class="">(1 row)<br class="">```<br class=""><br class="">So I see 1 necessary change:<br class="">- Document clearly in ST_AsEWKT that the output doesn't follow WKT_ISO.<br class=""><br class="">And 1 optional change:<br class="">- Change the behaviour of ST_AsEWKT in 3.1+ to follow ST_AsText footsteps<br class="">and include the dimension qualifiers at all times, thus making a breaking<br class="">change.<br class=""><br class=""><br class="">To be honest, if ST_AsEWKT has lived all this time without complains I don't<br class="">think breaking a lot of tests is really worth it and just documenting the<br class="">behaviour more clearly should be enough, but I'd like to hear what's the<br class="">opinion of the "older generation" :D.<br class=""><br class=""><br class="">Regards<br class="">-- <br class="">Raúl Marín Rodríguez<br class=""><a href="http://carto.com" class="">carto.com</a><br class="">_______________________________________________<br class="">postgis-devel mailing list<br class="">postgis-devel@lists.osgeo.org<br class="">https://lists.osgeo.org/mailman/listinfo/postgis-devel</div></div></blockquote></div><br class=""></div></body></html>