3

I try to snap a line to a polygon boundary. This is working fine, due using the snapping option in QGIS (snap mode vertex and segments & tolerance 0 pixels)

enter image description here

Line 1 is snapping to the polygon segment.

If I export these geometries to PostGIS and do a ST_relate test with line1 and polygon, I don't get the expected result:

I would aspect that touching is true

   SELECT  st_touches (line.geom, poly.geom) FROM snapping_line line,snapping_poly poly;
   SELECT  st_relate (line.geom, poly.geom) FROM snapping_line line,snapping_poly poly;

But touches is false and st_relate is completely not what I'm expecting with snapping: 10F0FF212

I get the correct result if I snap the line to polygon vertexes (Line 2) with touching true and correct st_relate FF1F0F212

So now, where is the error? Is snapping not working correctly? Why is the result different between vertex and segment snapping. I am using QGIS 3.4.4-Madeira on Windows and Ubuntu

|improve this question
  • 1
    The only way to reliably retain a point-on-line relationship is to add a vertex to the line and shift the point onto it. From that point on you must be fastidious about coordinate representation, lest floating-point drift force you to resnap. – Vince Mar 3 at 12:51
  • 1
    Also the tolerance should be a value more than 0 pixels, like 10 or 15 pixels – Gerardo Jimenez Mar 3 at 17:21
1

Imagine that one side of the polygon starts at coordinates ( 0 , 0 ) and ends at coordinates ( 3 , 1 ).

And you want to snap the endpoint of a line to that side of the polygon, at coordinates ( 1 , 1\3 ).

The y coordinate of the point is a rational number and can be expressed accurately as a fraction, but its decimal expression contains infinite decimal places.

I suppose that when digitizing that point, some rounding should be taking place when establishing its coordinates in decimal format, and the endpoint of the line will not really coincide with the trajectory of the polygon side.

Also, the relate matrix between the line and the polygon in that case could be expected to be 1010FF212 instead of 10F0FF212.

|improve this answer
  • Better to use 2/3 or 1/7 as the intercept point to reinforce the impact of rounding – Vince Mar 3 at 15:58
  • @Vince, thanks for the response. The absolute difference between 0.6666667 and 2/3 is exactly the same as between 0.3333333 and 1/3. The difference between 1/7 and its finite decimal representation depends on the decimal place in which the rounding took place, but it will always be greater than zero and less than half the magnitude that that decimal place represents. In order to understand the problem posed, the example provided in the answer seems simple and adequate enough. – Gabriel De Luca Mar 4 at 5:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.