I've imported OSM data, including specifically LineString railroad tracks for different subdivisions.
I want to distribute mile markers at fixed intervals, but am getting very different distance measurements with different tools and zooming scales. The original data is in 3857 as default OSM and in my PostGIS db.
First I used the Marker line symbology for tick marks. It's consistent but any view with scale higher than 1:100000 and the distances and mark locations keep varying, even with feature clipping turned off. At lower scales the distances are wrong even if consistent. A line of length 82 is showing 102 miles by the marker distribution.
Then I created a virtual field simply with $length.. It's the same here, where only zoomed in closer than 1:100000 does the length stay consistent. The lengths do match what I measure with Google Earth, and whether in 3857 or UTM 32611, it's the same behavior and variance when zoomed out. This is the correct length but only closer than 1:100000 Is the geometry changing, or the projection at those scales??
The other feature I wanted was to "create points along geometry". This method doesn't vary spacing as it's not dynamic, but is also incorrect and showing 103 instead of 82 miles. I've tried a few other projections, but problem appears the same?
Why is the create points giving wrong distances, from the same line objects? Using the measure tool is consistent and represents the resulting spacing.
Any advice to get these distances to be correct? It's difficult to trust the measurements.
-UPDATE- So I understand that Web Mercator is not a good projection for measuring distances, and am trying to get a better handle on projections in the workflow. I used regional OSM data downloads, merged using Osmosis, then imported into PostGIS with osm2pgsql. I never addressed the projection at these steps, and data ended up with default PostGIS 3857. I then did some reprojections with QGIS to try to achieve correct measurements, including explicit reprojections in PostGIS or on the fly changes. At this stage none of these make any perceptible differences, which leads to...
Is correctness lost during first import to 3857, or is it reversible? At what stage in the workflow do I need to ensure it's in the correct crs?