[QGIS-Developer] Length measurement weirdness (again)

[Paolo Cavallini]

Hi all,
the measurements of a EPSG:4326 line appear correct in any SRS, both
with the interactive info tool and writing on the table the value of
$length, *if* the OTF reprojection is active (including 4326).
If it is not, the result is grossly overestimated (298 m instead of 228,
etc.).
Am I missing something, or this is a serious bug?
I attach a tiny sample showing the effect.
Thanks.

[Paolo Cavallini]

Post by Paolo Cavallini
Hi all,
the measurements of a EPSG:4326 line appear correct in any SRS, both
with the interactive info tool and writing on the table the value of
$length, *if* the OTF reprojection is active (including 4326).
If it is not, the result is grossly overestimated (298 m instead of 228,
etc.).
Am I missing something, or this is a serious bug?
I attach a tiny sample showing the effect.

Forgot to tell: 2.18.19 (rather obviously, in qgis3 OTF is always on).
Thanks for confirmation and comments.
All the best.

[andreaerdna]

Have you noticed this in the measure tool info box part?:

- if OTF is off:

The calculations are based on:
Project CRS transformation is turned off. Distance is calculated in degrees,
based on project CRS (WGS84).
Ellipsoidal calculation is not possible with CRS transformation disabled.
Distance is roughly converted to degrees by using scale at equator (1 degree
= 111319.49 meters).


- if OTF is on:

The calculations are based on:
Project CRS transformation is turned on and ellipsoidal calculation is
selected.
The coordinates are transformed to the chosen ellipsoid (WGS84), and the
distance is calculated in meters.


Moreover the User Guide (paragraph 8.8) is more clear:

QGIS provides four means of measuring geometries:
• the interactive measurement tools ,
• measuring in the Field Calculator,
• derived measures in the Identify Features tool,
• and a vector analysis tool: Vector→Geometry Tools→Export/Add Geometry
Columns

Measuring works within projected coordinate systems (e.g., UTM) and
unprojected data. The first three measuring tools behave equally to global
project settings:
• If “on the fly” CRS transformation (see Define On The Fly (OTF) CRS
Transformation) is enabled, the
default measurement metric is - different from most other GIS - ellipsoidal,
using the ellipsoid defined in
File → Project properties → General. This is true both when geographic and
projected coordinate systems
are defined for the project.
• If you want to calculate the projected / planimetric area or distance
using cartesian maths, the measurement ellipsoid has to be set to “None /
Planimetric” (File → Project properties → CRS). However, with a geographic
(= unprojected) CRS defined for the data and project, area and distance
measurement will be ellipsoidal.
• If “on the fly” CRS transformation is disabled, the measurement metric is
planimetric when the project coordinate system is projected and ellipsoidal
when the project coordinate system is unprojected / geographic.
However, neither the identify tool nor the field calculator will transform
your data to the project CRS before measuring. If you want to achieve this,
you have to use the vector analysis tool: Vector → Geometry Tools
→Export/Add Geometry Columns. Here, measurement is by default planimetric
except if you choose the ellipsoidal measure.





-----
Andrea Giudiceandrea
--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html

[Nyall Dawson]

Post by Paolo Cavallini
Hi all,
the measurements of a EPSG:4326 line appear correct in any SRS, both
with the interactive info tool and writing on the table the value of
$length, *if* the OTF reprojection is active (including 4326).
If it is not, the result is grossly overestimated (298 m instead of 228,
etc.).
Am I missing something, or this is a serious bug?

It's not a bug as much as very confusing 2.x behavior. The obscure
link between a "rendering" setting (OTF projection) and ellipsoidal
calculations (area/distance) is extremely confusing for users. We
couldn't change this in 2.x because of the API freeze and how embedded
this logic was in many areas of QGIS code and API.

That's why in 3.0 the whole OTF logic was reworked, so that OTF is
always on for rendering and doesn't the choice of ellipsoidal
calculations or not is totally based on the project's ellipsoid
setting.

So unfortunately for 2.18 there's really no choice but to ensure that
OTF projection setting is enabled.

Nyall

[Patrick Dunford]

It was always my impression that these measurements can never be that
accurate as the projections are approximated? Or do you know otherwise?

Post by Nyall Dawson

Post by Paolo Cavallini
Hi all,
the measurements of a EPSG:4326 line appear correct in any SRS, both
with the interactive info tool and writing on the table the value of
$length, *if* the OTF reprojection is active (including 4326).
If it is not, the result is grossly overestimated (298 m instead of 228,
etc.).
Am I missing something, or this is a serious bug?

It's not a bug as much as very confusing 2.x behavior. The obscure
link between a "rendering" setting (OTF projection) and ellipsoidal
calculations (area/distance) is extremely confusing for users. We
couldn't change this in 2.x because of the API freeze and how embedded
this logic was in many areas of QGIS code and API.
That's why in 3.0 the whole OTF logic was reworked, so that OTF is
always on for rendering and doesn't the choice of ellipsoidal
calculations or not is totally based on the project's ellipsoid
setting.
So unfortunately for 2.18 there's really no choice but to ensure that
OTF projection setting is enabled.
Nyall
_______________________________________________
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[Paolo Cavallini]

Post by Patrick Dunford
It was always my impression that these measurements can never be that
accurate as the projections are approximated? Or do you know otherwise?

we are not talking about approximations here, but of 30-40% errors.
thanks.

[Paolo Cavallini]

Post by Nyall Dawson
It's not a bug as much as very confusing 2.x behavior. The obscure
link between a "rendering" setting (OTF projection) and ellipsoidal
calculations (area/distance) is extremely confusing for users. We
couldn't change this in 2.x because of the API freeze and how embedded
this logic was in many areas of QGIS code and API.

I understand, thanks for the explanation. Then why not disabling
measurements when OTF is off? giving a totally false measurement does
not seem a good idea.
I believe 2.18 will be around for a good while, and I hate sending
around wrong results of which the user has no clue whatsoever.
Still unclear to me why the lack of ellipsoid would lead to 40% error,
but that's my ignorance.
All the best.

[C Hamilton]

This is one of the reasons why I wrote Geodesic Measure tool that is part
of Shape Tools. It is based on geographiclib's distance measures and is
relative accurate. I never knew whether I had the default QGIS measure tool
set correctly or not to give accurate measurements. More accurate
measurements could be obtained using geographiclib's gravity models such as
EGM2008, but that would require shipping the associated data which is large.

By the way I found out that the latest versions of proj.4 integrated
geographiclib. Is there a way to call these routines from a python plugin
in QGIS. I would assume the C code would be faster than the python library
which is what I use.

All the best.

Post by Paolo Cavallini

Post by Nyall Dawson
It's not a bug as much as very confusing 2.x behavior. The obscure
link between a "rendering" setting (OTF projection) and ellipsoidal
calculations (area/distance) is extremely confusing for users. We
couldn't change this in 2.x because of the API freeze and how embedded
this logic was in many areas of QGIS code and API.

I understand, thanks for the explanation. Then why not disabling
measurements when OTF is off? giving a totally false measurement does
not seem a good idea.
I believe 2.18 will be around for a good while, and I hate sending
around wrong results of which the user has no clue whatsoever.
Still unclear to me why the lack of ellipsoid would lead to 40% error,
but that's my ignorance.
All the best.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis
_______________________________________________
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[Kristian Evers]

I am not super familiar with QGIS’ interface to PROJ but I don’t think there’s a way to do that at the moment. The new PROJ API exposes a function that computes the geodesic distance between two points directly: https://proj4.org/development/reference/functions.html#c.proj_lp_dist

This would be a good idea to expose once QGIS incorporates the new PROJ API. The calculations are super fast and Charles Karney, the developer of GeograhpicLib, says that they are accurate to micrometer level.

/Kristian

PS. The proj_factors function is also a good candidate for inclusion in the QGIS Python API since it gives direct access to various cartographic properties of a projection: https://proj4.org/development/reference/functions.html#c.proj_factors

Fra: QGIS-Developer [mailto:qgis-developer-***@lists.osgeo.org] PÃ¥ vegne af C Hamilton
Sendt: 4. maj 2018 15:22
Til: Paolo Cavallini <***@faunalia.it>
Cc: qgis-developer <qgis-***@lists.osgeo.org>
Emne: Re: [QGIS-Developer] Length measurement weirdness (again)

This is one of the reasons why I wrote Geodesic Measure tool that is part of Shape Tools. It is based on geographiclib's distance measures and is relative accurate. I never knew whether I had the default QGIS measure tool set correctly or not to give accurate measurements. More accurate measurements could be obtained using geographiclib's gravity models such as EGM2008, but that would require shipping the associated data which is large.

By the way I found out that the latest versions of proj.4 integrated geographiclib. Is there a way to call these routines from a python plugin in QGIS. I would assume the C code would be faster than the python library which is what I use.

All the best.

Post by Nyall Dawson
It's not a bug as much as very confusing 2.x behavior. The obscure
link between a "rendering" setting (OTF projection) and ellipsoidal
calculations (area/distance) is extremely confusing for users. We
couldn't change this in 2.x because of the API freeze and how embedded
this logic was in many areas of QGIS code and API.

I understand, thanks for the explanation. Then why not disabling
measurements when OTF is off? giving a totally false measurement does
not seem a good idea.
I believe 2.18 will be around for a good while, and I hate sending
around wrong results of which the user has no clue whatsoever.
Still unclear to me why the lack of ellipsoid would lead to 40% error,
but that's my ignorance.
All the best.