Opened 5 years ago
Closed 5 years ago
#4694 closed defect (invalid)
NewEdgesSplit does not snap to edge
Reported by: | tomass | Owned by: | strk |
---|---|---|---|
Priority: | medium | Milestone: | |
Component: | topology | Version: | 3.0.x |
Keywords: | Cc: |
Description
ST_NewEdgesSplit is unable to split an edge with an error "SQL/MM Spatial exception - point not on edge".
Script to reproduce an error is attached. It drops and then creates a new topology to make sure we have a clean environment. Inserts new edge. Then a call to ST_Distance shows that a distance to the node which will be used as a split point for an edge is "9.946529457016767e-10" away. Then a call to ST_NewEdgesSplit fails with an error:
ERROR: SQL/MM Spatial exception - point not on edge
NOTE: If I do a workaround and modify an edge adding a new point to the edges geometry - then call to ST_NewEdgesSplit is successful.
Tested on Centos8.1, PostgreSQL 12.1, Postgis3.0.1 (topology 3.0.1), GEOS3.7.2.
Attachments (1)
Change History (5)
by , 5 years ago
Attachment: | bug_reproduce.sql added |
---|
comment:1 by , 5 years ago
comment:2 by , 5 years ago
Thank you. Do I understand correctly, that in PostGIS/Topology 3.0.1 you can only split an existing edge at the vertex which already exists in edges geometry?
I am using a workaround of calling ST_ChangeEdgeGeom and adding a new vertex at the point where I want to split an edge prior to calling ST_NewEdgeSplit/ST_ModEdgeSplit. Is this the correct way to split an edge at any point, at least for now?
comment:3 by , 5 years ago
Yes, that's a possible way. The topology population functions do this, if the splitting point is not found on the edge by ST_Contains
comment:4 by , 5 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
What you describe is not a bug but expected behavior. ST_NewEdgeSplit and ST_ModEdgeSplit and all other ISO-SQLMM defined topology functions (those starting with ST_) do not consider the topology "precision" (no such concept in ISO-SQLMM).
I think there's an enhancement ticket in this trac instance about adding support for "tolerance" in these functions.