Small but substantial displayed misalignment of layers with the same datum (projected vs unprojected)

[gjsa73]

Comparing two vector layers downloaded from the same provider. One is downloaded in an unprojected datum: GDA94 (EPSG 4283) The other is projected: MGA94 zone 55 (EPSG28355).

In ArcGIS Pro and Manifold 9 - these two layers are coincident at the maximum zoom and there is no misalignment shown (visible differences < 0.0005 m would be detectable.)

in QGIS 3.16 or 3.18 - these two layers are displayed offset by 0.08 to 0.8m in the north-south direction.

Lot_GDA94_EPSG4283.zip Lot_MGA94_Z55_EPSG28355.zip

[gioman]

@gjsa73 just tried on 3.16 on Windows and can't see any discernible difference, even pushing the scale to crazy levels.

[gjsa73]

@gioman thanks for looking into it. I have just double-checked on a fresh installation of QGIS 3.16.6 (this time on MacOS rather than Windows) and the same issue is present. A detailed screenshot is below - showing the lat/lon location and the offset (0.079m)

Here is the same location and same two layers in ArcGIS Pro, showing that they are coincident. The measure tool has been drawn to 0.01 m for scale purposes.

To test if this is an issue just for the map display/canvas (and not for processing), I selected two polygons with the same ID from both layers, confirmed that they were visually misaligned to a similar level as above (in this case about 0.11 m) and intersected them using Vector overlay -> Union. The result shows that the processing aligns the two layers correctly, as the union produces insignificant alignment differences.

Therefore, the issue is a display issue perhaps involving OTF projection.

[gioman]

@gjsa73 just tested on QGIS 3.18.1 on macOS Calatina: I cannot see any misalignment unless pushing the zoom to well beyond 1:1 (like 30000:1)

[gjsa73]

@gioman just to be sure that you are seeing something different - can you please measure what difference you do see?

7 or 8 cm isn't a lot, and does require pushing the zoom a lot, but it is still incorrect, and it is still a problem.

[gjsa73]

Here is the same issue - but more pronounced.

Two layers that visually misalign by 0.7 m - far easier to see now at a zoom of 1:1 When a vector union is done - the misalignment is not reflected in the result.

All three layers (two input layers and union) are in the zipped geopackage attached. proj_display_issue_pronounced.zip

[gioman]

Here is the same issue - but more pronounced.

@gjsa73 was one of the layers obtained from the other? where the two layer created independently and digitized in a way that they originally align perfectly?

[gjsa73]

@gjsa73 was one of the layers obtained from the other? where the two layer created independently and digitized in a way that they originally align perfectly?

In the first example/zip file yes. In the second example/zip file the ultimate source should be the same, but the providers of the data are different and the interim processing could have been different.

However, I don't think that this is relevant to identifying the problem.

The last zip file includes two layers that display with a 0.7m offset from each other (perhaps due to differences in the data, perhaps not) and yet the union operation detects no such offset. I can confirm that displaying those two layers in ArcGIS Pro and Manifold 9 agrees with the union operation - there is no substantial offset.

So either:

1. the canvas display of those layers or
2. the union operation (and two other 3rd party application applications) incorrectly represent those two layers spatially, because 1. and 2. are inconsistent with each other

The fact that the union operation agrees with 2 other 3rd party GIS clients suggests that the problem is almost certainly with 1.

[agiudiceandrea]

@gjsa73 using both QGIS 3.16 and 3.18 on Windows (OSGeo4W) I've added your layers (Lot_GDA94_EPSG4283.zip, Lot_MGA94_Z55_EPSG28355.zip) in a map and displayed at the maximum allowed resolution

The displacement between two corresponding vertex measured with the Measure Tool is 0,0001352 mm (about 1 micron).

[agiudiceandrea]

Not so different in ArcMap 9.3.1

[SrNetoChan]

Many things can go wrong here.

You can use different transformation parameters in different software. If the data was prepared in ArcGIS it's normal that when read in ArcGIS (using the same default transformation) the layers will match almost perfectly.

Two different CRSs have different 0,0 origins. If we think that there's a precision limit somewhere, there will be a limit in which the too layers can be aligned.

Check what transformation parameters are being used in all applications.

[agiudiceandrea]

Adding the layer in proj_display_issue_pronounced.zip I can see that:

• the measured "offset" is about 0.007 millimeters (7 microns)
• the union layer contains separate polygons for overlapping and not overlapping parts of the two layers (see fid numbers)

[agiudiceandrea]

@SrNetoChan the issue here is that @gjsa73, using QGIS, measures an offset between the two layer of some centimeters or decimeters while I measure an offset of some microns!

[gjsa73]

Ok - firstly I appreciate everyone's involvement in this issue - it's frustrating and I sincerely hope I haven't wasted your time @agiudiceandrea, @SrNetoChan, @gioman

To expose everyone to a common location where this issue is occurring without any doubt - please:

1. use the three layers in the geopackage that I have reattached to this message.
2. zoom the canvas to the following coordinates (EPSG 28355):
   • Easting: 343601
   • Northing: 6690203

I have also attached a screen record that shows exactly what the problem is: the two source layers (colored red and blue) are displayed with a (false) offset > 0,5 meter (approximately north-south at this location where the boundaries run parallel east-west).

Unioning the two source layers produces a green result layer that shows no such offset: the union is visibly precisely aligned only to one of the source layers (blue layer).

proj_display_issue_pronounced.zip

https://user-images.githubusercontent.com/21994806/119245497-16c2a480-bbbd-11eb-9ef0-5acfe716de07.mp4

Note: screen record is QGIS 3.16.7 LTR on Windows Server 2019, but the same issue exists on QGIS 3.18.x

[SrNetoChan]

@SrNetoChan the issue here is that @gjsa73, using QGIS, measures an offset between the two layer of some centimeters or decimeters while I measure an offset of some microns!

@agiudiceandrea my point is that using different transformation parameters will lead to different results

[agiudiceandrea]

my point is that using different transformation parameters will lead to different results

I don't think so. A transformation between a geographic and a projected reference system without a spheroid/datum change (like in this case) only involves "exact" calculations without the need of any transformation parameters.

@gjsa73 could you confim that the adjacent vertices of the corresponding line segment (that is about 8 km long) in the two layer have almost identical coordinates (with a difference of some micrometers) while near the centre of the segment there is an apparent offset of about 0,7 meters?

If it is the case then IMHO the "issue" you are experiencing is a due to the fact that a line vector layer actually doesn't contains lines, but vertices of segments. The layer doesn't store the coordinate of "all" the points that lay on the segment but only the two vertices of the segment. When a layer is reprojected ("statically" or on-the-fly), only the vertices of the lines are reprojected, not the lines.

How to represent/render/draw the segment between two adjacent vertex depends on the projection/reference system of the layer and of the map. A straight line in a CRS could be represented as curved line in another CRS,

There is no no unique way to render that line: it could be e.g. an Euclidean straight line in each layer CRS Cartesian plane OR a rhumb/loxodromic, great-circle/orthodromic, geodesic line approximating the Earth surface to a sphere, an authalic sphere, a spheroid, a geoid, projected in the map CRS...

AFAIK QGIS render the line segment between two adjacent vertices with the first method, while ArcMap/ArcGIS adopts the second method (not sure which one of the possible variants).

Consider this scenario: Layer A [EPSG:4283] with a LineString (145 -20, 145 -40), say Line A Reprojecting Layer A from EPSG:4283 to EPSG:28355 you'll obtain: Layer B [EPSG:28355] with a LineString (290756.7701549 7787269.2849236, 329274.5057277 5570327.0269983), say Line B Looking at the vertices of the line of the two layers at the maximum zoom in QGIS (either in a EPSG:4283 or EPSG:28355 map) you will see that they are coincident. In fact, if you reproject Layer B from EPSG:28355 to EPSG:4283 you'll obtain the same identical coordinates LineString (145 -20, 145 -40) of Layer A.

Now consider where QGIS should render the centres of the two lines (which are not stored in the layers as vertices). Should they be coincident?

The euclidean centre of Line A in its layer CRS (EPSG:4283) Cartesian plane is Point (145 -30), say Center A. Centre A is Point (145 -30) in EPSG:4283 and Point (307084.8948206 6679530.7135974) in EPSG:28355.

The euclidean centre of Line B in its layer CRS (EPSG:28355) Cartesian plane is Point (310015.6379413 6678798.155961), say Centre B. Centre B is Point (310015.6379413 6678798.155961) in EPSG:28355 and Point (145.03023809 -30.00706515) in EPSG:4283.

As you can see they are not coincident and there is about 3 km offset.

If Line A contained also the centre vertex, LineString (145 -20, 145 -30, 145 -40), then you will have two shorter segments and three coincident vertices. Anyway you will see a minor offset at the centres of the two segments.

This rendering behaviour is less evident if the segments are shorter, i.e. the lines contain less spaced vertices (Densify). An 8 km segment is a long segment... Consider that also the Densify process could follow the Euclidean method (like the QGIS Densify tool) or the geodetic method (like the QGIS Shape Tool plugin Geodesic Densifier) and that this problem is related to GIS/Cartography/Geodesy theory and is also a relevant problem in ArcMap/ArcGIS (see https://community.esri.com/t5/data-management-questions/densify-euclidean-vs-geodesic/td-p/101380)

[gioman]

If it is the case then IMHO the "issue" you are experiencing is a due to the fact that a line vector layer actually doesn't contains lines, but vertices of segments. The layer doesn't store the coordinate of "all" the points that lay on the segment but only the two vertices of the segment.

How to represent/render/draw the segment between two adjacent vertex depends on the projection/reference system of the layer and of the map. A straight line in a CRS could be represented as curved line in another CRS,

@agiudiceandrea I also think that this is exactingly the case.