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:[email protected]] På vegne af 
C Hamilton
Sendt: 4. maj 2018 15:22
Til: Paolo Cavallini <[email protected]>
Cc: qgis-developer <[email protected]>
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.

On Fri, May 4, 2018 at 3:07 AM, Paolo Cavallini 
<[email protected]<mailto:[email protected]>> wrote:
Il 04/05/2018 01:18, Nyall Dawson ha scritto:

> 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<http://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
[email protected]<mailto:[email protected]>
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
QGIS-Developer mailing list
[email protected]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Reply via email to