[postgis-tickets] [PostGIS] #4758: ERROR: XX000: SQL/MM Spatial exception - geometry crosses edge 2, LOCATION: pg_error, lwgeom_pg.c:250

[PostGIS]

#4758: ERROR:  XX000: SQL/MM Spatial exception - geometry crosses edge 2,
LOCATION:  pg_error, lwgeom_pg.c:250
-----------------------+---------------------------
  Reporter:  laopsahl  |      Owner:  strk
      Type:  defect    |     Status:  assigned
  Priority:  blocker   |  Milestone:  PostGIS 3.1.0
 Component:  topology  |    Version:  3.0.x
Resolution:            |   Keywords:
-----------------------+---------------------------

Comment (by laopsahl):

 I am really unsure about what is the best to do here, since I am not able
 to see all the consequences, but I think "snap-to-segment" is ok because

 1) We must avoid that the red point close the blue point are added when
 adding line two or else we we have blocked the system for the blue node,
 without moving a exiting node.


 2) We must avoid that lines/nodes already added are moved/changed. Adding
 a node to a line does not mean that a line is changed.


 3) We run with snapto and then we must accept that incoming points are
 moved or adjusted to fit to data already added inside given tolerance. One
 used case can for instance be that we add the most accurate lines first
 and use bigger tolereance when adding the next lines.


 4) “snap to vertex” is the best, but I don't see snapto "snap-to-segment"
 as problem, when there are no vertex to snap for the given tolerance. I
 here understand a vertex as node, where a line end or meet other lines. So
 the problem when adding line two this is that there are no node so we to
 have to create the blue node before we can snap to it.

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