I have two point layers that one has 2885 and the other has same 2885 plus 1748 more features. The second one is a result of "v.net.centrality" analysis and now I want to join the result spatially into the first point layer in QGIS 3.4 LTR.

2885 of the features have exact same coordinates and reference system so I expect all of intersecting points to join spatially to give analysis' result to first point layer but in QGIS only 335 of them are intersecting. Then I tried to do it by using PostGIS with

SELECT first.id, first.geom, second.result 
FROM first 
LEFT JOIN second ON ST_Intersects(first.geom, second.geom) 

but the result is same with QGIS "Join attributes by location" tool, only 335 of them intersecting. I also tried "Equals, touches" rules on QGIS and "ST_Equals, first.geom = second.geom conditions on PostGIS but the result didn't change.

Then I pass the data into ArcGIS Pro and do spatial join on it. It gives exactly what I want, all of the attributes (analysis result) from second layer are added to the first layer with "Intersect" rule.

I'm wondering why this happening? What is the reason behind it and how can I resolve in QGIS?

  • Perhaps the coordinates are not the same till the last bit. You could try to accept some tolerance by adding ST_Snap into your query, or by using ST_DWithin instead of ST_Intersects.
    – user30184
    Commented Dec 4, 2019 at 7:36
  • I checked the coordinates by adding geometries into them and also the coordinates can not be different since the second layer is a result of the analysis of first layer.
    – omrakn
    Commented Dec 4, 2019 at 7:40
  • 1
    Without analyzing the source code of the analysis functions you can't say that coordinates can't be different. I would rather say that if ST_Equals is false then the coordinates can't be the same.
    – user30184
    Commented Dec 4, 2019 at 8:07
  • yeah I saved the output coordinates as high precision double type and saw the differences after 9th digit. Putting snap tolerance has worked. Thanks
    – omrakn
    Commented Dec 4, 2019 at 10:18

1 Answer 1


v.net.centrality is a Grass function. I have sometimes seen Grass and Qgis behave differently when handling the figures. I have also noted that when saving integers in a double with high precision, you see differences in the values. E.g. "24" becoming "23.999999999999999". This is probably due to the shapefile encoding of Qgis on a lower level.

The issue can be diagnosed by adding fields for x and y coordinates in both layers and checking the values displayed. Equals and intersects queries need exact equivalence in Qgis, whereas I guess ArcGis handles the values slighly differently to directly filter out those tiny errors (I'm not an ArcGis user).

To solve your problem, you can add some tolerance in your spatial query, as user30184 suggested. 1cm should be more than enough.

  • Okay putting some tolerance is worked but isn't it a very annoying problem, what do you say? How can one trust grass&qgis interoperability especially if user don't know how to use PostGIS since spatial join in qgis does not have any search tolerance functionality.
    – omrakn
    Commented Dec 4, 2019 at 10:16
  • 1
    I tend to agree with you. I guess that a developper could provide more insight here, as the subject gets really technical.
    – Kantan
    Commented Dec 4, 2019 at 10:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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