[postgis-users] LinestringM with one point

[Martin Davis]

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.

On Tue, Sep 21, 2021 at 11:28 AM Martin Davis <mtnclimb at gmail.com> wrote:

> There has been no change in PostGIS behaviour, only in the documentation.
> :)
>
> 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!
>
> So the docs need to be improved to distinguish between OGC validity, and
> what PostGIS actually allows.  I'll work on that.
>
> 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:
>
> SELECT ST_AsEWKT('LINESTRING(0 0)'::geometry);
> ERROR:  geometry requires more point
>
> But the ST_MakeLine constructor allows single-point lines:
>
> SELECT ST_AsEWKT( ST_MakeLine(  ARRAY[ ST_MakePoint(1,2,3) ]  ));
> -------------------
>  LINESTRING(1 2 3)
>
> 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.
>
>
> On Tue, Sep 21, 2021 at 7:33 AM Poul Bondo <poul.bondo at gmail.com> wrote:
>
>> Hello
>>
>> We have been using postgis for the past 7-8 years for storing a lot of
>> ship tracks in PostgreSQL.
>>
>> We are storing the data with one record per vessel per day as
>> geography(linestringm) of position reports with a timestamp in the M part.
>>
>> In many cases we only have one position per day and thus have stored a
>> linestringm with length = 1.
>>
>> Until now this has not caused problems.
>>
>> In the documentation for the upcoming PostGIS 3.2.0 a new section has
>> been added including the statement:
>>
>> "A LineString must have at least two points." and by extension we assume
>> this will be the case for linestringM also
>>
>> Also we discovered a problem when using replication which uses COPY in
>> some cases which works fine and INSERT which does not work in other
>> cases when using linestringM with length = 1
>>
>> Is there a significant reason for having / adding this requirement and
>> if so are there any recommendation on how to handle the scenario with
>> only one sample?
>>
>> Thanks
>>
>> Poul
>>
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/postgis-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20210921/14b67b3c/attachment.html>