[postgis-tickets] [PostGIS] #5268: ST_ShortestLine return invalid linestring when distance of geometries is 0

[PostGIS]

#5268: ST_ShortestLine return invalid linestring when distance of geometries is 0
----------------------+---------------------------
  Reporter:  latot    |      Owner:  pramsey
      Type:  defect   |     Status:  new
  Priority:  medium   |  Milestone:  PostGIS 3.4.0
 Component:  postgis  |    Version:  3.3.x
Resolution:           |   Keywords:
----------------------+---------------------------
Comment (by latot):

 ufff, yeah, now giving it more thoughts, is a hard-call as you says, I
 start writing and there I notice, the post was big!

 My first thought is, the return should not be invalid geometries, or at
 least, not mix them, is pretty non-intuitive to get weird things from the
 functions without an easy way to know this cases, this could be different
 if in the docs is written every case of the invalid geoms that can be
 inside.

 Check this, I use a lot zero/null vectors in this post.
 https://www.cuemath.com/calculus/zero-vector/

 A trivial start point, we use functions to achieve something, so, in order
 to do that we expect a clear way to do that, if we know the invalid
 geometries, and why is every one of them, we can work with them, and do
 the right treatment do every case to achieve what we want, but, have all
 mixed causes we need to think all from zero, for all invalid cases, and
 have luck to have all of them, practically, invalid geometries is the same
 as have multiples types of data mixed.

 So, the point, if you think I'm going in a good direction, is how return
 in a clear way the results, lets pick as example the actual case,
 ST_ShortestLength.

 For now we have two types of results, vectors and the null vectors (length
 0), is a little weird if you think a null vector is a invalid geometry,
 while it is a valid geometry (in the math :)).

 But moving to a more practical space, my opinion is the difference is in
 the properties, the null vector does not has the same properties as a non
 null vector, and we don't want to every one get too deph in maths, usually
 is enough if you what go inside the function, and know what can be the
 output.

 We expect from a vector to have at least a start point, and end point, and
 both to be different or have length more than 0, so is good to know if
 there is something in the result that does not have this conditions.

 Oks, maybe, "is too complex", and you are right, if the definitions are
 not set or not enugh, but I think can helps to clarify a lot of things and
 the interactions, is obvs how a non null vector works with ST_Buffer, but,
 a null vector, what would be the effect of ST_Buffer on it? is not trivial
 with null vectors, if ST_Buffer works over a linestring the buffer of a
 null vector is it self, with no expansion because there is no linestring
 to use or calc, someone my say, but there is the points! yeah!, but you
 are buffering a 2 dim element! (there is lines in 3d and more, but still
 the element is 2d).

 Checking, this can be a invalid geometry too, buffer should do nothing on
 it:
 ```
 SELECT ST_Buffer(
  ST_GeomFromText(
   'LINESTRING(50 50,50 50)'
  ), 10);
 ```

 Someone still can says, check the docs of ST_Buffer:
 ```
 Computes a POLYGON or MULTIPOLYGON that represents all points whose
 distance from a geometry/geography is less than or equal to a given
 distance.
 ```

 And again, with a null vector, there is no distance to calculate from the
 vector it self :) We use points to represent linestrings, but that points
 are not the linestring.

 All this interpretations depends on the expected properties and
 definitions of the geometries.

 As I have written, there is 3 things, work with standard geometries, non-
 standar geometries (but valids, like null vectors), and the last one, is
 get better definitions for "standard" with the expected properties and
 "valid"/"invalid" geometries.

 My recommendation in the properties issue, is try to keep them separate
 when the behavior of them is too different, like the non-null vector, and
 null vectors. If this separations are done correctly, will be more easy to
 handle every case and the behaviors between them without need to force it
 and keep it clear.

 Maybe I put too much thoughts for one post :3

 I agree, would be very hard to check one by one :)

 But step by step is possible to improve.
-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/5268#comment:2>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.