[QGIS-Developer] Length measurement weirdness (again)

Kristian Evers kreve at sdfe.dk
Mon May 7 04:14:00 PDT 2018


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-bounces at lists.osgeo.org] På vegne af C Hamilton
Sendt: 4. maj 2018 15:22
Til: Paolo Cavallini <cavallini at faunalia.it>
Cc: qgis-developer <qgis-developer at 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.

On Fri, May 4, 2018 at 3:07 AM, Paolo Cavallini <cavallini at faunalia.it<mailto:cavallini at faunalia.it>> 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
QGIS-Developer at lists.osgeo.org<mailto:QGIS-Developer at lists.osgeo.org>
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20180507/79a2bdcd/attachment.html>


More information about the QGIS-Developer mailing list