[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 robe):

 Replying to [comment:6 latot]:

 > The invalid features, are not always useful by it self, but is very
 useful recognize them, usually they need other algorithm to they do what
 we want them to do.
 >
 > Maybe, instead go to too deep definitions, we can explore in the
 functions, if there is edge cases write a base catalogue, and how their
 properties can affect the calculations in the function, like a start
 point, the zero-vectors and non-zero-vectors.
 >
 > I don't like the idea of send a param to do something with non-valid
 geometries, the reason, the treatment to the invalid geometries depends of
 what we want to achieve, so, is like there will be no standard for it. I
 think the better is a way to just recognize them, and let the ppl do what
 they want to do with them.
 >
 > I'll just imagine..., maybe there is a better way, the example is
 inspired in a real work I did some time ago, there is always several ways
 to do it, but the next query is pretty easy to read, and know the type
 helps to work better! (just a illustrative example :)):
 >
 > ```
 >
 > SELECT
 >  CASE
 >   WHEN stl.type = 'zero-vector' THEN
 >    ST_ShortestLine(ST_OffsetCurve(table.geom1, 1), table.geom2)
 >   ELSE stl.geometry
 > FROM table
 > LATERAL (ST_ShortestLine(table.geom1, table.geom2)) stl -- Two columns,
 geometry, type
 >
 > ```
 >
 > Personally, would be great something like this, maybe a param to trigger
 this return type? Can handle one by one, really simplifies everything,
 yeah more lines, and less errors.
 >
 > Thx!.
 >
 >
 > Edited:
 >
 > Checking this more, part of this can be achieved with something like
 ST_IsNull, but, I have two concerns
 >
 > One of them is if there is done too much ST_IsProperty_Name, check every
 one of them can be harder, so I think would be great has other way to know
 the properties of the vector.
 >
 > Second is performance, know the properties is good, someone may say that
 some times is not necessary and is true, but there is some times when we
 need it, and, there is the case you think is not necessary just you wasn't
 able to consider all the edge cases, and is right. So a way to can know
 this without affect too much would be great, I'm thinking in the case
 written above, where ST_MakeValid has impact, but we don't need it all the
 time, all is case by case.


 One thing Paul Norman was complaining about is that CASE statements are
 relatively slow.  So yah his code has a lot of case to handle invalid
 geometries, but would be better if maybe it was handled in the function,
 the performance would be better than resorting to a CASE statement. In
 theory anyway.
-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/5268#comment:7>
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.