[postgis-tickets] [PostGIS] #3280: Almost collinear edges prevent adding a copy of existing edge

[PostGIS]

#3280: Almost collinear edges prevent adding a copy of existing edge
-----------------------+---------------------------
  Reporter:  strk      |      Owner:  strk
      Type:  defect    |     Status:  new
  Priority:  medium    |  Milestone:  PostGIS 2.1.9
 Component:  topology  |    Version:  2.0.x
Resolution:            |   Keywords:  robustness
-----------------------+---------------------------

Comment (by strk):

 I think this case would succeed if we were able to order intersecting
 edges by their distance, but unfortunately the fully-containing and the
 not-containing edges are both found to be at distance 0 from the reference
 point:
 {{{
 strk=# SELECT
 st_distance('01010000005649EE1F280F384164E065F493C85241'::geometry, geom),
 edge_id,geom FROM "bug3280".edge_data WHERE
 ST_DWithin('01010000005649EE1F280F384164E065F493C85241'::geometry, geom,
 1.77267e-08) order by
 st_distance('01010000005649EE1F280F384164E065F493C85241'::geometry, geom);
  st_distance | edge_id |
 geom
 -------------+---------+--------------------------------------------------------------------------------------------------------------------
            0 |       1 |
 010200000002000000EC51B89E320F3841333333B3A9C8524114AE47611D0F384114AE47B17DC85241
            0 |       2 |
 010200000003000000EC51B89E320F3841333333B3A9C852415649EE1F280F384164E065F493C85241A4703D8A230F38410AD7A37094C85241
 (2 rows)
 }}}

 So how to force the longer edge (the one containing the point) to be
 handled first ?
 @nicklas note that GEOS finds the query point at a distance of ~5e-11 from
 the point.
 Not sure how that happens to work, exactly (is ST_Distance using some
 tolerance?)

--
Ticket URL: <https://trac.osgeo.org/postgis/ticket/3280#comment:5>
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.