<div dir="ltr">And thanks for pointing out this issue with the new docs. Good to know that someone is reading it!  Any further comments or suggestions for improvement are welcome.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 21, 2021 at 11:28 AM Martin Davis <<a href="mailto:mtnclimb@gmail.com">mtnclimb@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">There has been no change in PostGIS behaviour, only in the documentation.  :)<div><br></div><div>And you raise a very good point.  PostGIS is pretty lenient about storing OGC-invalid geometry, by design.  One reason is that the OGC validity rules are a bit too strict for many use cases (such as yours).  Another reason is that if you can't get geometry into the database, it's hard to fix it!</div><div><br></div><div>So the docs need to be improved to distinguish between OGC validity, and what PostGIS actually allows.  I'll work on that.</div><div><br></div><div>That said, the enforcement of OGC validity (or lack of) is variable (some might say inconsistent).  This may be the cause of your current issues.  For example, WKT parsing does not allow 1-point LINESTRINGS:</div><div><br></div><div>SELECT ST_AsEWKT('LINESTRING(0 0)'::geometry);<br>ERROR:  geometry requires more point<br></div><div><br></div><div>But the ST_MakeLine constructor allows single-point lines:</div><div><br></div><div>SELECT ST_AsEWKT( ST_MakeLine(  ARRAY[ ST_MakePoint(1,2,3) ]  ));<br>-------------------<br> LINESTRING(1 2 3)<br></div><div><br></div><div>Many (but not all) functions will happily accept this kind of "essentially valid" geometry as well.  I have thought that it would be nice if PostGIS defined a concept of "internally valid" (or some such name) to indicate what kinds of data it can actually handle.  Single-point lines are a prime example of this - there's really no reason that they can't be handled correctly by all functions, since they are topologically equivalent to a 2-point linestring with identical vertices, which is OGC valid.</div><div>  </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 21, 2021 at 7:33 AM Poul Bondo <<a href="mailto:poul.bondo@gmail.com" target="_blank">poul.bondo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello<br>
<br>
We have been using postgis for the past 7-8 years for storing a lot of <br>
ship tracks in PostgreSQL.<br>
<br>
We are storing the data with one record per vessel per day as <br>
geography(linestringm) of position reports with a timestamp in the M part.<br>
<br>
In many cases we only have one position per day and thus have stored a <br>
linestringm with length = 1.<br>
<br>
Until now this has not caused problems.<br>
<br>
In the documentation for the upcoming PostGIS 3.2.0 a new section has <br>
been added including the statement:<br>
<br>
"A LineString must have at least two points." and by extension we assume <br>
this will be the case for linestringM also<br>
<br>
Also we discovered a problem when using replication which uses COPY in <br>
some cases which works fine and INSERT which does not work in other <br>
cases when using linestringM with length = 1<br>
<br>
Is there a significant reason for having / adding this requirement and <br>
if so are there any recommendation on how to handle the scenario with <br>
only one sample?<br>
<br>
Thanks<br>
<br>
Poul<br>
<br>
_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-users" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-users</a><br>
</blockquote></div>
</blockquote></div>