Discussion:
[QGIS-Developer] New Features in Shape Tools 3.2.0
C Hamilton
2018-09-18 19:57:48 UTC
Permalink
The latest version of Shape Tools has several nice new features.

1) *Geodesic Measurement Layer *will take a line or polygon layer and for
each of the geometries calculate the geodesic distances of each feature.
The user can choose whether each line segment is measured and output as a
line measurement or whether the entire line/polygon geometry is measured.
It outputs a new layer of styled lines that display the measured distances.
Here is an example of the results processing a polygon layer.

measure-polygon.jpg
<https://drive.google.com/file/d/1lr1HsPPRs_sSR6Hz93f06xfsv0T2Z5Dk/view?usp=drive_web>

2) *Azimuth Distance Sequence Digitizer* - This provides the ability to
click on the map as a starting point and then give a series of bearings and
distances in the order of 'bearing 1, distance 1, bearing 2, distance 2,
... bearing N, distance N' and it will create a path.

3) All shape creation has been ported to the processing toolbox.

4) Additional ellipsoids are now supported.

*So what is next?*

Here are some possible next steps.

1. *Interactive drawing *of the shapes that are not already a part of the
QGIS interface. If a polygon or line layer is selected and editable then
the user would select a shape, parameters, and then click on the map and
draw, rotate, and size the shape.

2. *Geodesic Move and Rotate tools*. It appears that the QGIS vector move
and rotate tools work using the layer's projection so if it happens to be
in degrees you get some strange results especially when rotating. There is
a need for true rotate and move tools that preserves the area and size of
the object.

If you have any suggestions I would welcome them.

Thanks,

Calvin
Nyall Dawson
2018-09-20 22:26:20 UTC
Permalink
Post by C Hamilton
If you have any suggestions I would welcome them.
Shape Tools is fantastic, and plugs a much needed gap in QGIS core
functionality. Lovely work!

Can I strongly encourage you to investigate porting some of these
features/fixes over to QGIS core? You've obviously got the talent and
knowledge to do so, and it'd be great to offer this functionality
out-of-the-box. I'm available for mentoring if you need assistance
with QGIS core development/build setup/general c++ help!

Nyall
C Hamilton
2018-09-24 20:49:08 UTC
Permalink
Nyall,

Thanks for your confidence and encouragement. I would be interested, but
don't know where to begin. Shape Tools relies on geographiclib which is
slightly more accurate than Vincinty. Geographlib is not a library that is
included with the OSGeo distribution. However, as of the past several years
Proj.4 makes use of geographiclib. I am guessing QGIS has not exposed any
of proj.4's geographiclib routines and I don't know how much of
geographiclib Proj.4 actually uses. Including geographiclib could open up
future opportunities of using some of the Earth's gravity models which are
even more accurate for measuring distances. Using the C++ geographiclib
libraries in the QGIS core would be faster than python only code.

For me to even begin, I need geographiclib as part of the QGIS core. If
there is a path to accomplish this, then we can discuss further details on
what and how to migrate Shape Tools functionality into core.

Calvin
Post by C Hamilton
If you have any suggestions I would welcome them.
Shape Tools is fantastic, and plugs a much needed gap in QGIS core
functionality. Lovely work!
Can I strongly encourage you to investigate porting some of these
features/fixes over to QGIS core? You've obviously got the talent and
knowledge to do so, and it'd be great to offer this functionality
out-of-the-box. I'm available for mentoring if you need assistance
with QGIS core development/build setup/general c++ help!
Nyall
Nyall Dawson
2018-09-24 23:25:21 UTC
Permalink
Post by C Hamilton
Nyall,
Thanks for your confidence and encouragement. I would be interested, but don't know where to begin. Shape Tools relies on geographiclib which is slightly more accurate than Vincinty. Geographlib is not a library that is included with the OSGeo distribution. However, as of the past several years Proj.4 makes use of geographiclib. I am guessing QGIS has not exposed any of proj.4's geographiclib routines and I don't know how much of geographiclib Proj.4 actually uses. Including geographiclib could open up future opportunities of using some of the Earth's gravity models which are even more accurate for measuring distances. Using the C++ geographiclib libraries in the QGIS core would be faster than python only code.
For me to even begin, I need geographiclib as part of the QGIS core. If there is a path to accomplish this, then we can discuss further details on what and how to migrate Shape Tools functionality into core.
That should be relatively straightforward. I can do this after 3.4 is
released and feature freeze is lifted. Remind me after this :)

Nyall
Post by C Hamilton
Calvin
Post by Nyall Dawson
Post by C Hamilton
If you have any suggestions I would welcome them.
Shape Tools is fantastic, and plugs a much needed gap in QGIS core
functionality. Lovely work!
Can I strongly encourage you to investigate porting some of these
features/fixes over to QGIS core? You've obviously got the talent and
knowledge to do so, and it'd be great to offer this functionality
out-of-the-box. I'm available for mentoring if you need assistance
with QGIS core development/build setup/general c++ help!
Nyall
Kristian Evers
2018-09-25 05:24:26 UTC
Permalink
Nyall,

that would be a very welcome addition to QGIS! Let me know if I can be of assistance to you in that regard (I suspect documentation might be the biggest issue
).

Calvin,

The functionality that PROJ exposes from GeographicLib is seen in the geodesic.h header [0]. I am not entirely sure that it’s a one to one representation of the standalone version of the library but I think so. If there’s is something that you need that is missing let me know and I’ll see what I can do about it for the next release of PROJ.


On a related note, I have been meaning to raise a similar issue based on QGIS’s not so accurate polygon-area-on-the-ellipsoid calculations. A colleague of mine came across some differences between QGIS and CARIS LOTS while doing area calculations in relation to a border dispute at sea. After that I tested several popular closed source GIS apps and they all performed better than QGIS. I would have loved to use QGIS to solve this problem but unfortunately had to go with one of the other applications for this. Basing qgsdistancearea.[cpp|h] (probably other ones as well) on GeographicLib should sort that out and bring QGIS at the top of the game :-)

/Kristian

[0] https://github.com/OSGeo/proj.4/blob/master/src/geodesic.h

On 25 Sep 2018, at 01:25, Nyall Dawson <***@gmail.com<mailto:***@gmail.com>> wrote:

On Tue, 25 Sep 2018 at 06:49, C Hamilton <***@gmail.com<mailto:***@gmail.com>> wrote:

Nyall,

Thanks for your confidence and encouragement. I would be interested, but don't know where to begin. Shape Tools relies on geographiclib which is slightly more accurate than Vincinty. Geographlib is not a library that is included with the OSGeo distribution. However, as of the past several years Proj.4 makes use of geographiclib. I am guessing QGIS has not exposed any of proj.4's geographiclib routines and I don't know how much of geographiclib Proj.4 actually uses. Including geographiclib could open up future opportunities of using some of the Earth's gravity models which are even more accurate for measuring distances. Using the C++ geographiclib libraries in the QGIS core would be faster than python only code.

For me to even begin, I need geographiclib as part of the QGIS core. If there is a path to accomplish this, then we can discuss further details on what and how to migrate Shape Tools functionality into core.

That should be relatively straightforward. I can do this after 3.4 is
released and feature freeze is lifted. Remind me after this :)

Nyall


Calvin

If you have any suggestions I would welcome them.

Shape Tools is fantastic, and plugs a much needed gap in QGIS core
functionality. Lovely work!

Can I strongly encourage you to investigate porting some of these
features/fixes over to QGIS core? You've obviously got the talent and
knowledge to do so, and it'd be great to offer this functionality
out-of-the-box. I'm available for mentoring if you need assistance
with QGIS core development/build setup/general c++ help!

Nyall


_______________________________________________
QGIS-Developer mailing list
QGIS-***@lists.osgeo.org<mailto:QGIS-***@lists.osgeo.org>
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Paolo Cavallini
2018-09-25 06:23:21 UTC
Permalink
Hi Kristian,
Post by Kristian Evers
On a related note, I have been meaning to raise a similar issue based
on QGIS’s not so accurate polygon-area-on-the-ellipsoid calculations.
A colleague of mine came across some differences between QGIS and
CARIS LOTS while doing area calculations in relation to a border
dispute at sea. After that I tested several popular closed source GIS
apps and they all performed better than QGIS.
this is worth exploring in detail. could you please be more specific? do
you have a test case? could you share the results, or give us a way to
replicate them?
Thanks.
--
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
Kristian Evers
2018-09-25 06:59:24 UTC
Permalink
Hi Paolo,

I have some rought notes that I can try to polish up a bit and share here.
I'll see if I can find the time for that today. I didn't get to the bottom of
the problem but I am leaning towards the issue being that QGIS uses an
inferior algorithm to determine geodesics. Unfortunately I couldn't find out
from either the source code or the documentation which algorithm is used.
As far as I remember it differs from the otherwise popular algorithm by
Vincenty. That may be because a different algorithm is used or the
Implementation is wrong.

I'll get back with a better write-up later and some test data and results.

/Kristian

-----Oprindelig meddelelse-----
Fra: QGIS-Developer <qgis-developer-***@lists.osgeo.org> På vegne af Paolo Cavallini
Sendt: 25. september 2018 08:23
Til: qgis-***@lists.osgeo.org
Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0

Hi Kristian,
Post by Kristian Evers
On a related note, I have been meaning to raise a similar issue based
on QGIS’s not so accurate polygon-area-on-the-ellipsoid calculations.
A colleague of mine came across some differences between QGIS and
CARIS LOTS while doing area calculations in relation to a border
dispute at sea. After that I tested several popular closed source GIS
apps and they all performed better than QGIS.
this is worth exploring in detail. could you please be more specific? do
you have a test case? could you share the results, or give us a way to
replicate them?
Thanks.

--
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/

_______________________________________________
QGIS-Developer mailing list
QGIS-***@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Nyall Dawson
2018-09-25 07:06:41 UTC
Permalink
Post by Kristian Evers
Hi Paolo,
I have some rought notes that I can try to polish up a bit and share here.
I'll see if I can find the time for that today. I didn't get to the bottom of
the problem but I am leaning towards the issue being that QGIS uses an
inferior algorithm to determine geodesics. Unfortunately I couldn't find out
from either the source code or the documentation which algorithm is used.
As far as I remember it differs from the otherwise popular algorithm by
Vincenty. That may be because a different algorithm is used or the
Implementation is wrong.
I'll get back with a better write-up later and some test data and results.
We use a direct port from GRASS:

https://github.com/qgis/QGIS/blob/master/src/core/qgsdistancearea.cpp#L690

vs GRASS upstream:

https://trac.osgeo.org/grass/browser/grass/trunk/lib/gis/area_poly1.c?rev=71260

It's not very stable for very small areas -- better to use cartesian
calculations there. Or bring in geographiclib and punt the
responsibility elsewhere ;)

Nyall
Post by Kristian Evers
/Kristian
-----Oprindelig meddelelse-----
Sendt: 25. september 2018 08:23
Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0
Hi Kristian,
Post by Kristian Evers
On a related note, I have been meaning to raise a similar issue based
on QGIS’s not so accurate polygon-area-on-the-ellipsoid calculations.
A colleague of mine came across some differences between QGIS and
CARIS LOTS while doing area calculations in relation to a border
dispute at sea. After that I tested several popular closed source GIS
apps and they all performed better than QGIS.
this is worth exploring in detail. could you please be more specific? do
you have a test case? could you share the results, or give us a way to
replicate them?
Thanks.
--
Paolo Cavallini - www.faunalia.eu
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
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
2018-09-25 07:14:59 UTC
Permalink
It's not a small area, that's why I have been nitpicking ellipsoid area calculation
algorithms!
I did end up doing the calculations with geographiblib to get a reference to judge
various other calculations by. It's a pain in the butt to extract the data from a
polygon shapefile (or whatever) and format it to suit the planimeter app of
geographiclib. It would be so much cooler if I could get the same results by
clicking info on a polygon in QGIS :-)

/Kristian


-----Oprindelig meddelelse-----
Fra: Nyall Dawson <***@gmail.com>
Sendt: 25. september 2018 09:07
Til: Kristian Evers <***@sdfe.dk>
Cc: Paolo Cavallini <***@faunalia.it>; qgis-developer <qgis-***@lists.osgeo.org>
Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0
Post by Kristian Evers
Hi Paolo,
I have some rought notes that I can try to polish up a bit and share here.
I'll see if I can find the time for that today. I didn't get to the bottom of
the problem but I am leaning towards the issue being that QGIS uses an
inferior algorithm to determine geodesics. Unfortunately I couldn't find out
from either the source code or the documentation which algorithm is used.
As far as I remember it differs from the otherwise popular algorithm by
Vincenty. That may be because a different algorithm is used or the
Implementation is wrong.
I'll get back with a better write-up later and some test data and results.
We use a direct port from GRASS:

https://github.com/qgis/QGIS/blob/master/src/core/qgsdistancearea.cpp#L690

vs GRASS upstream:

https://trac.osgeo.org/grass/browser/grass/trunk/lib/gis/area_poly1.c?rev=71260

It's not very stable for very small areas -- better to use cartesian
calculations there. Or bring in geographiclib and punt the
responsibility elsewhere ;)

Nyall
Post by Kristian Evers
/Kristian
-----Oprindelig meddelelse-----
Sendt: 25. september 2018 08:23
Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0
Hi Kristian,
Post by Kristian Evers
On a related note, I have been meaning to raise a similar issue based
on QGIS’s not so accurate polygon-area-on-the-ellipsoid calculations.
A colleague of mine came across some differences between QGIS and
CARIS LOTS while doing area calculations in relation to a border
dispute at sea. After that I tested several popular closed source GIS
apps and they all performed better than QGIS.
this is worth exploring in detail. could you please be more specific? do
you have a test case? could you share the results, or give us a way to
replicate them?
Thanks.
--
Paolo Cavallini - www.faunalia.eu
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
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
2018-09-25 13:31:48 UTC
Permalink
Right, here are the calculated areas as returned by a number of different GIS applications and the planimeter app of GeographicLib for reference:

Caris LOTS: 14.737 km^2
ArcMap: 14.727,446 km^2
MapInfo: 14.727,352 km^2
GeoMedia: 14.726,443 km^2
Planimeter: 14.722,522 km^2
QGIS 3.2: 14.652,181 km^2
QGIS 2.8: 14.652,181 km^2

The polygon that I have used to get the numbers above can be found here: https://gist.github.com/kbevers/207b5bcb9be20e7554abe5f56742ec2c

I am quite confident that GeographicLib delivers the most accurate result (if you have doubts, this reference [0] should convince you). As can be seen from the table above all but QGIS come fairly close. I expect some variation in the results as these are numerical approximations, although I think QGIS is too far of the mark. My suspicion is that the geodesic algorithm used by QGIS (and apparently GRASS) is to blame here.

/Kristian

[0] https://arxiv.org/pdf/1102.1215.pdf

-----Oprindelig meddelelse-----
Fra: QGIS-Developer <qgis-developer-***@lists.osgeo.org> På vegne af Kristian Evers
Sendt: 25. september 2018 09:15
Til: Nyall Dawson <***@gmail.com>
Cc: qgis-developer <qgis-***@lists.osgeo.org>
Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0

It's not a small area, that's why I have been nitpicking ellipsoid area calculation
algorithms!
I did end up doing the calculations with geographiblib to get a reference to judge
various other calculations by. It's a pain in the butt to extract the data from a
polygon shapefile (or whatever) and format it to suit the planimeter app of
geographiclib. It would be so much cooler if I could get the same results by
clicking info on a polygon in QGIS :-)

/Kristian


-----Oprindelig meddelelse-----
Fra: Nyall Dawson <***@gmail.com>
Sendt: 25. september 2018 09:07
Til: Kristian Evers <***@sdfe.dk>
Cc: Paolo Cavallini <***@faunalia.it>; qgis-developer <qgis-***@lists.osgeo.org>
Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0
Post by Kristian Evers
Hi Paolo,
I have some rought notes that I can try to polish up a bit and share here.
I'll see if I can find the time for that today. I didn't get to the bottom of
the problem but I am leaning towards the issue being that QGIS uses an
inferior algorithm to determine geodesics. Unfortunately I couldn't find out
from either the source code or the documentation which algorithm is used.
As far as I remember it differs from the otherwise popular algorithm by
Vincenty. That may be because a different algorithm is used or the
Implementation is wrong.
I'll get back with a better write-up later and some test data and results.
We use a direct port from GRASS:

https://github.com/qgis/QGIS/blob/master/src/core/qgsdistancearea.cpp#L690

vs GRASS upstream:

https://trac.osgeo.org/grass/browser/grass/trunk/lib/gis/area_poly1.c?rev=71260

It's not very stable for very small areas -- better to use cartesian
calculations there. Or bring in geographiclib and punt the
responsibility elsewhere ;)

Nyall
Post by Kristian Evers
/Kristian
-----Oprindelig meddelelse-----
Sendt: 25. september 2018 08:23
Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0
Hi Kristian,
Post by Kristian Evers
On a related note, I have been meaning to raise a similar issue based
on QGIS’s not so accurate polygon-area-on-the-ellipsoid calculations.
A colleague of mine came across some differences between QGIS and
CARIS LOTS while doing area calculations in relation to a border
dispute at sea. After that I tested several popular closed source GIS
apps and they all performed better than QGIS.
this is worth exploring in detail. could you please be more specific? do
you have a test case? could you share the results, or give us a way to
replicate them?
Thanks.
--
Paolo Cavallini - www.faunalia.eu
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
QGIS-***@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
C Hamilton
2018-09-25 14:27:18 UTC
Permalink
Kristian,

Thanks for those calculations. Before this discussion I was contemplating
doing a line and polygon measurement tool for Shape Tools by clicking on an
existing shape and using geographiclib calculate the measurements, but if
it is possible to replace the existing QGIS measuring functions and
Vincinty with geographiclib, then I will hold off. Shape Tools uses
geographiclib for all its calculations and I am pleased with it. In the
last release I included a function to measure all geometry on a layer.

I don't know who has the most accurate algorithm. I just checked Google
Earth and it measures your polygon at 14,672 km^2. I'm guessing Google
Earth is not as accurate as some of those other applications. As far as I
know geographiclib has the most accurate ellipsoid calculations. The only
thing better would be to include elevation. I'm not an expert in this area,
but would the gravity models provide more accuracy?

https://geographiclib.sourceforge.io/html/gravity.html#gravityinst

Calvin
Post by Kristian Evers
Right, here are the calculated areas as returned by a number of different
Caris LOTS: 14.737 km^2
ArcMap: 14.727,446 km^2
MapInfo: 14.727,352 km^2
GeoMedia: 14.726,443 km^2
Planimeter: 14.722,522 km^2
QGIS 3.2: 14.652,181 km^2
QGIS 2.8: 14.652,181 km^2
https://gist.github.com/kbevers/207b5bcb9be20e7554abe5f56742ec2c
I am quite confident that GeographicLib delivers the most accurate result
(if you have doubts, this reference [0] should convince you). As can be
seen from the table above all but QGIS come fairly close. I expect some
variation in the results as these are numerical approximations, although I
think QGIS is too far of the mark. My suspicion is that the geodesic
algorithm used by QGIS (and apparently GRASS) is to blame here.
/Kristian
[0] https://arxiv.org/pdf/1102.1215.pdf
-----Oprindelig meddelelse-----
Kristian Evers
Sendt: 25. september 2018 09:15
Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0
It's not a small area, that's why I have been nitpicking ellipsoid area calculation
algorithms!
I did end up doing the calculations with geographiblib to get a reference to judge
various other calculations by. It's a pain in the butt to extract the data from a
polygon shapefile (or whatever) and format it to suit the planimeter app of
geographiclib. It would be so much cooler if I could get the same results by
clicking info on a polygon in QGIS :-)
/Kristian
-----Oprindelig meddelelse-----
Sendt: 25. september 2018 09:07
Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0
Post by Kristian Evers
Hi Paolo,
I have some rought notes that I can try to polish up a bit and share
here.
Post by Kristian Evers
I'll see if I can find the time for that today. I didn't get to the
bottom of
Post by Kristian Evers
the problem but I am leaning towards the issue being that QGIS uses an
inferior algorithm to determine geodesics. Unfortunately I couldn't find
out
Post by Kristian Evers
from either the source code or the documentation which algorithm is used.
As far as I remember it differs from the otherwise popular algorithm by
Vincenty. That may be because a different algorithm is used or the
Implementation is wrong.
I'll get back with a better write-up later and some test data and
results.
https://github.com/qgis/QGIS/blob/master/src/core/qgsdistancearea.cpp#L690
https://trac.osgeo.org/grass/browser/grass/trunk/lib/gis/
area_poly1.c?rev=71260
It's not very stable for very small areas -- better to use cartesian
calculations there. Or bring in geographiclib and punt the
responsibility elsewhere ;)
Nyall
Post by Kristian Evers
/Kristian
-----Oprindelig meddelelse-----
af Paolo Cavallini
Post by Kristian Evers
Sendt: 25. september 2018 08:23
Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0
Hi Kristian,
Post by Kristian Evers
On a related note, I have been meaning to raise a similar issue based
on QGIS’s not so accurate polygon-area-on-the-ellipsoid calculations.
A colleague of mine came across some differences between QGIS and
CARIS LOTS while doing area calculations in relation to a border
dispute at sea. After that I tested several popular closed source GIS
apps and they all performed better than QGIS.
this is worth exploring in detail. could you please be more specific? do
you have a test case? could you share the results, or give us a way to
replicate them?
Thanks.
--
Paolo Cavallini - www.faunalia.eu
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
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
2018-09-25 14:50:20 UTC
Permalink
Calvin,

I am quite sure that Charles Karney holds an undisputed claim of the Most Accurate Geodesic Algorithm™. At least I haven’t come across any papers offering better accuracy.

Google Earths figure of 14.672 km^2 is very similar to MapInfos spherical area calculation of 14.670 km^2, so for now I think we can assume that Google’s Earth is not subject to either rotation nor gravity :-)

Regarding including the gravity (geoid) models in GeographicLib I must admit that that is outside my knowledge of the library. If the library can calculate geodesics on the geoid that would be even more accurate, yes. Although you are at the mercy of the accuracy of the geoid models. For my particular application I wouldn’t use one since the global models mention in the docs you link to are not that well-fitting in this area. In theory I could produce a grid from a better geoid model. While an interesting problem to handle I think it is taking it just a step too far.

/Kristian

Fra: C Hamilton <***@gmail.com>
Sendt: 25. september 2018 16:27
Til: Kristian Evers <***@sdfe.dk>
Cc: Nyall Dawson <***@gmail.com>; qgis-developer <qgis-***@lists.osgeo.org>
Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0

Kristian,

Thanks for those calculations. Before this discussion I was contemplating doing a line and polygon measurement tool for Shape Tools by clicking on an existing shape and using geographiclib calculate the measurements, but if it is possible to replace the existing QGIS measuring functions and Vincinty with geographiclib, then I will hold off. Shape Tools uses geographiclib for all its calculations and I am pleased with it. In the last release I included a function to measure all geometry on a layer.

I don't know who has the most accurate algorithm. I just checked Google Earth and it measures your polygon at 14,672 km^2. I'm guessing Google Earth is not as accurate as some of those other applications. As far as I know geographiclib has the most accurate ellipsoid calculations. The only thing better would be to include elevation. I'm not an expert in this area, but would the gravity models provide more accuracy?

https://geographiclib.sourceforge.io/html/gravity.html#gravityinst

Calvin


On Tue, Sep 25, 2018 at 9:31 AM, Kristian Evers <***@sdfe.dk<mailto:***@sdfe.dk>> wrote:
Right, here are the calculated areas as returned by a number of different GIS applications and the planimeter app of GeographicLib for reference:

Caris LOTS: 14.737 km^2
ArcMap: 14.727,446 km^2
MapInfo: 14.727,352 km^2
GeoMedia: 14.726,443 km^2
Planimeter: 14.722,522 km^2
QGIS 3.2: 14.652,181 km^2
QGIS 2.8: 14.652,181 km^2

The polygon that I have used to get the numbers above can be found here: https://gist.github.com/kbevers/207b5bcb9be20e7554abe5f56742ec2c

I am quite confident that GeographicLib delivers the most accurate result (if you have doubts, this reference [0] should convince you). As can be seen from the table above all but QGIS come fairly close. I expect some variation in the results as these are numerical approximations, although I think QGIS is too far of the mark. My suspicion is that the geodesic algorithm used by QGIS (and apparently GRASS) is to blame here.

/Kristian

[0] https://arxiv.org/pdf/1102.1215.pdf

-----Oprindelig meddelelse-----
Fra: QGIS-Developer <qgis-developer-***@lists.osgeo.org<mailto:qgis-developer-***@lists.osgeo.org>> PÃ¥ vegne af Kristian Evers
Sendt: 25. september 2018 09:15
Til: Nyall Dawson <***@gmail.com<mailto:***@gmail.com>>
Cc: qgis-developer <qgis-***@lists.osgeo.org<mailto:qgis-***@lists.osgeo.org>>
Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0

It's not a small area, that's why I have been nitpicking ellipsoid area calculation
algorithms!
I did end up doing the calculations with geographiblib to get a reference to judge
various other calculations by. It's a pain in the butt to extract the data from a
polygon shapefile (or whatever) and format it to suit the planimeter app of
geographiclib. It would be so much cooler if I could get the same results by
clicking info on a polygon in QGIS :-)

/Kristian


-----Oprindelig meddelelse-----
Fra: Nyall Dawson <***@gmail.com<mailto:***@gmail.com>>
Sendt: 25. september 2018 09:07
Til: Kristian Evers <***@sdfe.dk<mailto:***@sdfe.dk>>
Cc: Paolo Cavallini <***@faunalia.it<mailto:***@faunalia.it>>; qgis-developer <qgis-***@lists.osgeo.org<mailto:qgis-***@lists.osgeo.org>>
Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0
Post by Kristian Evers
Hi Paolo,
I have some rought notes that I can try to polish up a bit and share here.
I'll see if I can find the time for that today. I didn't get to the bottom of
the problem but I am leaning towards the issue being that QGIS uses an
inferior algorithm to determine geodesics. Unfortunately I couldn't find out
from either the source code or the documentation which algorithm is used.
As far as I remember it differs from the otherwise popular algorithm by
Vincenty. That may be because a different algorithm is used or the
Implementation is wrong.
I'll get back with a better write-up later and some test data and results.
We use a direct port from GRASS:

https://github.com/qgis/QGIS/blob/master/src/core/qgsdistancearea.cpp#L690

vs GRASS upstream:

https://trac.osgeo.org/grass/browser/grass/trunk/lib/gis/area_poly1.c?rev=71260

It's not very stable for very small areas -- better to use cartesian
calculations there. Or bring in geographiclib and punt the
responsibility elsewhere ;)

Nyall
Post by Kristian Evers
/Kristian
-----Oprindelig meddelelse-----
Sendt: 25. september 2018 08:23
Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0
Hi Kristian,
Post by Kristian Evers
On a related note, I have been meaning to raise a similar issue based
on QGIS’s not so accurate polygon-area-on-the-ellipsoid calculations.
A colleague of mine came across some differences between QGIS and
CARIS LOTS while doing area calculations in relation to a border
dispute at sea. After that I tested several popular closed source GIS
apps and they all performed better than QGIS.
this is worth exploring in detail. could you please be more specific? do
you have a test case? could you share the results, or give us a way to
replicate them?
Thanks.
--
Paolo Cavallini - www.faunalia.eu<http://www.faunalia.eu>
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
QGIS-***@lists.osgeo.org<mailto:QGIS-***@lists.osgeo.org>
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
QGIS-***@lists.osgeo.org<mailto:QGIS-***@lists.osgeo.org>
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Helmut Kudrnovsky
2018-09-25 17:52:35 UTC
Permalink
Post by Kristian Evers
[...]
Caris LOTS: 14.737 km^2
ArcMap: 14.727,446 km^2
MapInfo: 14.727,352 km^2
GeoMedia: 14.726,443 km^2
Planimeter: 14.722,522 km^2
QGIS 3.2: 14.652,181 km^2
QGIS 2.8: 14.652,181 km^2
[...]
My suspicion is that the geodesic algorithm used by QGIS (and apparently
GRASS) is to blame here.

a quick check in GRASS 7.7.svn shows :-)

|m2|km2|
|14718097678,673|14.718,097679|



-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
Nyall Dawson
2018-09-27 06:31:31 UTC
Permalink
Post by Kristian Evers
Post by Kristian Evers
[...]
Caris LOTS: 14.737 km^2
ArcMap: 14.727,446 km^2
MapInfo: 14.727,352 km^2
GeoMedia: 14.726,443 km^2
Planimeter: 14.722,522 km^2
QGIS 3.2: 14.652,181 km^2
QGIS 2.8: 14.652,181 km^2
[...]
My suspicion is that the geodesic algorithm used by QGIS (and apparently
GRASS) is to blame here.
a quick check in GRASS 7.7.svn shows :-)
|m2|km2|
|14718097678,673|14.718,097679|
Hmm... confusing. I've double checked and the QGIS/GRASS code matches,
so we should get identical results. The cause must lie in the data
passed to the area calculation. I'll investigate.

Nyall
Kristian Evers
2018-09-27 07:01:36 UTC
Permalink
A possible explanation could be that QGIS doesn't pick up the correct ellipsoid definition from the CRS metadata. I had a hunch that might be the problem but couldn’t come up with a test to confirm it. I suspect it would be simple to test in debug mode.

/Kristian

-----Oprindelig meddelelse-----
Fra: QGIS-Developer <qgis-developer-***@lists.osgeo.org> På vegne af Nyall Dawson
Sendt: 27. september 2018 08:32
Til: ***@web.de
Cc: qgis-developer <qgis-***@lists.osgeo.org>
Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0
Post by Kristian Evers
Post by Kristian Evers
[...]
Caris LOTS: 14.737 km^2
ArcMap: 14.727,446 km^2
MapInfo: 14.727,352 km^2
GeoMedia: 14.726,443 km^2
Planimeter: 14.722,522 km^2
QGIS 3.2: 14.652,181 km^2
QGIS 2.8: 14.652,181 km^2
[...]
My suspicion is that the geodesic algorithm used by QGIS (and apparently
GRASS) is to blame here.
a quick check in GRASS 7.7.svn shows :-)
|m2|km2|
|14718097678,673|14.718,097679|
Hmm... confusing. I've double checked and the QGIS/GRASS code matches,
so we should get identical results. The cause must lie in the data
passed to the area calculation. I'll investigate.

Nyall
_______________________________________________
QGIS-Developer mailing list
QGIS-***@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Nyall Dawson
2018-09-27 07:35:31 UTC
Permalink
Post by Kristian Evers
Post by Kristian Evers
[...]
Caris LOTS: 14.737 km^2
ArcMap: 14.727,446 km^2
MapInfo: 14.727,352 km^2
GeoMedia: 14.726,443 km^2
Planimeter: 14.722,522 km^2
QGIS 3.2: 14.652,181 km^2
QGIS 2.8: 14.652,181 km^2
[...]
My suspicion is that the geodesic algorithm used by QGIS (and apparently
GRASS) is to blame here.
a quick check in GRASS 7.7.svn shows :-)
|m2|km2|
|14718097678,673|14.718,097679|
Hi Helmut,

I'm struggling to work out where the difference lies between the code
paths. Do you mind sharing the values from the st state struct when
G_ellipsoid_polygon_area is called for this polygon?

Nyall
Post by Kristian Evers
-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
_______________________________________________
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Helmut Kudrnovsky
2018-10-01 13:09:07 UTC
Permalink
Post by Nyall Dawson
I'm struggling to work out where the difference lies between the code
paths. Do you mind sharing the values from the st state struct when
G_ellipsoid_polygon_area is called for this polygon?
Nyall
delivered by Markus Metz, GRASS dev:

st->AE: 40408299984661.4
st->QA: 0.00446291999342754
st->QB: 2.68888340714427e-05
st->QC: 1.71432450253425e-07
st->QbarA: -1.00448998025995
st->QbarB: 0.0015057373196404
st->QbarC: -5.48062628444059e-06
st->QbarD: 2.44903500362035e-08
st->Qp: 1.00448998025995
st->E: 510065621153775

precision: %.15g

by adding a debug message in GRASS: in lib/gis/area_poly1.c add debug
messages in G_begin_ellipsoid_polygon_area().





-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
Nyall Dawson
2018-10-02 03:01:29 UTC
Permalink
Post by Helmut Kudrnovsky
Post by Nyall Dawson
I'm struggling to work out where the difference lies between the code
paths. Do you mind sharing the values from the st state struct when
G_ellipsoid_polygon_area is called for this polygon?
Nyall
st->AE: 40408299984661.4
st->QA: 0.00446291999342754
st->QB: 2.68888340714427e-05
st->QC: 1.71432450253425e-07
st->QbarA: -1.00448998025995
st->QbarB: 0.0015057373196404
st->QbarC: -5.48062628444059e-06
st->QbarD: 2.44903500362035e-08
st->Qp: 1.00448998025995
st->E: 510065621153775
precision: %.15g
by adding a debug message in GRASS: in lib/gis/area_poly1.c add debug
messages in G_begin_ellipsoid_polygon_area().
Thanks so much -- found the error now!

Nyall
Helmut Kudrnovsky
2018-10-01 13:01:22 UTC
Permalink
Post by Kristian Evers
Post by Kristian Evers
[...]
Caris LOTS: 14.737 km^2
ArcMap: 14.727,446 km^2
MapInfo: 14.727,352 km^2
GeoMedia: 14.726,443 km^2
Planimeter: 14.722,522 km^2
QGIS 3.2: 14.652,181 km^2
QGIS 2.8: 14.652,181 km^2
[...]
My suspicion is that the geodesic algorithm used by QGIS (and apparently
GRASS) is to blame here.
a quick check in GRASS 7.7.svn shows :-)
|m2|km2|
|14718097678,673|14.718,097679|
-----
best regards
Helmut
--
http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
_______________________________________________
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
forwarding from the GRASS GIS dev ML:
[https://lists.osgeo.org/pipermail/grass-dev/2018-October/090080.html]

------------------------------------------
Post by Kristian Evers
fyi see
https://lists.osgeo.org/pipermail/qgis-developer/2018-September/054644.html
Post by Kristian Evers
with GRASS mentioned
------------------
Right, here are the calculated areas as returned by a number of different
Caris LOTS: 14.737 km^2
ArcMap: 14.727,446 km^2
MapInfo: 14.727,352 km^2
GeoMedia: 14.726,443 km^2
Planimeter: 14.722,522 km^2
QGIS 3.2: 14.652,181 km^2
QGIS 2.8: 14.652,181 km^2
adding to the confusion:

I used the geographiclib API as included in PROJ 5.2.0 following the
example for geod_polygonarea() in geodesic.h and get
geographiclib: 14,737.935 km^2
quite different from
Planimeter: 14,722.522 km^2

GRASS native gives 14,718.097679
as also reported by Helmut and Stefan

Markus M
------------------------------------------



-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
Nyall Dawson
2018-10-02 03:12:16 UTC
Permalink
Post by Kristian Evers
Post by Kristian Evers
[...]
Caris LOTS: 14.737 km^2
ArcMap: 14.727,446 km^2
MapInfo: 14.727,352 km^2
GeoMedia: 14.726,443 km^2
Planimeter: 14.722,522 km^2
QGIS 3.2: 14.652,181 km^2
QGIS 2.8: 14.652,181 km^2
[...]
My suspicion is that the geodesic algorithm used by QGIS (and apparently
GRASS) is to blame here.
a quick check in GRASS 7.7.svn shows :-)
|m2|km2|
|14718097678,673|14.718,097679|
Ok, with https://github.com/qgis/QGIS/pull/8090 QGIS now exactly
matches GRASS' value (14.718 km2).

(For reference -- not a regression, this bug has been around since
ellipsoidal calculations were introduced to QGIS!)

Nyall
Paolo Cavallini
2018-10-02 06:04:02 UTC
Permalink
Hi all,

thanks a lot for this. It's a beautiful example of how open source
works, finding and solving problems through collaboration and highly
skilled people. It would be nice if someone would write about this for a
wider audience.

All the best.
Post by Nyall Dawson
Post by Kristian Evers
Post by Kristian Evers
[...]
Caris LOTS: 14.737 km^2
ArcMap: 14.727,446 km^2
MapInfo: 14.727,352 km^2
GeoMedia: 14.726,443 km^2
Planimeter: 14.722,522 km^2
QGIS 3.2: 14.652,181 km^2
QGIS 2.8: 14.652,181 km^2
[...]
My suspicion is that the geodesic algorithm used by QGIS (and apparently
GRASS) is to blame here.
a quick check in GRASS 7.7.svn shows :-)
|m2|km2|
|14718097678,673|14.718,097679|
Ok, with https://github.com/qgis/QGIS/pull/8090 QGIS now exactly
matches GRASS' value (14.718 km2).
(For reference -- not a regression, this bug has been around since
ellipsoidal calculations were introduced to QGIS!)
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 - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
C Hamilton
2018-10-02 14:11:12 UTC
Permalink
Nyall,

Thanks so much for investigating and fixing this. Also thank you all who
have contributed to this discussion. This was an important bug to find and
fix. I think we will find that the geographiclib calculations are going to
be slightly more accurate coming in at 14.737 km^2, but the GRASS
calculations are quite accurate.

Calvin
Post by Kristian Evers
Post by Kristian Evers
Post by Kristian Evers
[...]
Caris LOTS: 14.737 km^2
ArcMap: 14.727,446 km^2
MapInfo: 14.727,352 km^2
GeoMedia: 14.726,443 km^2
Planimeter: 14.722,522 km^2
QGIS 3.2: 14.652,181 km^2
QGIS 2.8: 14.652,181 km^2
[...]
My suspicion is that the geodesic algorithm used by QGIS (and
apparently
Post by Kristian Evers
GRASS) is to blame here.
a quick check in GRASS 7.7.svn shows :-)
|m2|km2|
|14718097678,673|14.718,097679|
Ok, with https://github.com/qgis/QGIS/pull/8090 QGIS now exactly
matches GRASS' value (14.718 km2).
(For reference -- not a regression, this bug has been around since
ellipsoidal calculations were introduced to QGIS!)
Nyall
Stefan Blumentrath
2018-09-26 20:36:51 UTC
Permalink
Hi,

Even if the discussion already moved on, for the record below some more numbers from other OSGeo tools:
PostGIS (in UTM 33N): 14727443738.0 m2
GRASS 7.4 (in WGS84): 14707741818.0911
GRASS 7.4 (in UTM33): between 14707741818.0911 m2 and 14727443738.0262 m2 (depending on how much one densifies vertices on the boundaries during reprojection, the latter value measured without boundary vertex densification)

Please see also: https://issues.qgis.org/issues/12057 for earlier discussion of area calculations in QGIS...
And https://trac.osgeo.org/grass/ticket/3356 for recent changes in area calculations in GRASS.

Cheers
Stefan

-----Original Message-----
From: QGIS-Developer <qgis-developer-***@lists.osgeo.org> On Behalf Of Kristian Evers
Sent: tirsdag 25. september 2018 15:32
To: Kristian Evers <***@sdfe.dk>; Nyall Dawson <***@gmail.com>
Cc: qgis-developer <qgis-***@lists.osgeo.org>
Subject: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0

Right, here are the calculated areas as returned by a number of different GIS applications and the planimeter app of GeographicLib for reference:

Caris LOTS: 14.737 km^2
ArcMap: 14.727,446 km^2
MapInfo: 14.727,352 km^2
GeoMedia: 14.726,443 km^2
Planimeter: 14.722,522 km^2
QGIS 3.2: 14.652,181 km^2
QGIS 2.8: 14.652,181 km^2

The polygon that I have used to get the numbers above can be found here: https://gist.github.com/kbevers/207b5bcb9be20e7554abe5f56742ec2c

I am quite confident that GeographicLib delivers the most accurate result (if you have doubts, this reference [0] should convince you). As can be seen from the table above all but QGIS come fairly close. I expect some variation in the results as these are numerical approximations, although I think QGIS is too far of the mark. My suspicion is that the geodesic algorithm used by QGIS (and apparently GRASS) is to blame here.

/Kristian

[0] https://arxiv.org/pdf/1102.1215.pdf

-----Oprindelig meddelelse-----
Fra: QGIS-Developer <qgis-developer-***@lists.osgeo.org> På vegne af Kristian Evers
Sendt: 25. september 2018 09:15
Til: Nyall Dawson <***@gmail.com>
Cc: qgis-developer <qgis-***@lists.osgeo.org>
Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0

It's not a small area, that's why I have been nitpicking ellipsoid area calculation algorithms!
I did end up doing the calculations with geographiblib to get a reference to judge various other calculations by. It's a pain in the butt to extract the data from a polygon shapefile (or whatever) and format it to suit the planimeter app of geographiclib. It would be so much cooler if I could get the same results by clicking info on a polygon in QGIS :-)

/Kristian


-----Oprindelig meddelelse-----
Fra: Nyall Dawson <***@gmail.com>
Sendt: 25. september 2018 09:07
Til: Kristian Evers <***@sdfe.dk>
Cc: Paolo Cavallini <***@faunalia.it>; qgis-developer <qgis-***@lists.osgeo.org>
Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0
Post by Kristian Evers
Hi Paolo,
I have some rought notes that I can try to polish up a bit and share here.
I'll see if I can find the time for that today. I didn't get to the
bottom of the problem but I am leaning towards the issue being that
QGIS uses an inferior algorithm to determine geodesics. Unfortunately
I couldn't find out from either the source code or the documentation which algorithm is used.
As far as I remember it differs from the otherwise popular algorithm
by Vincenty. That may be because a different algorithm is used or the
Implementation is wrong.
I'll get back with a better write-up later and some test data and results.
We use a direct port from GRASS:

https://github.com/qgis/QGIS/blob/master/src/core/qgsdistancearea.cpp#L690

vs GRASS upstream:

https://trac.osgeo.org/grass/browser/grass/trunk/lib/gis/area_poly1.c?rev=71260

It's not very stable for very small areas -- better to use cartesian calculations there. Or bring in geographiclib and punt the responsibility elsewhere ;)

Nyall
Post by Kristian Evers
/Kristian
-----Oprindelig meddelelse-----
Sendt: 25. september 2018 08:23
Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0
Hi Kristian,
Post by Kristian Evers
On a related note, I have been meaning to raise a similar issue
based on QGIS’s not so accurate polygon-area-on-the-ellipsoid calculations.
A colleague of mine came across some differences between QGIS and
CARIS LOTS while doing area calculations in relation to a border
dispute at sea. After that I tested several popular closed source
GIS apps and they all performed better than QGIS.
this is worth exploring in detail. could you please be more specific?
do you have a test case? could you share the results, or give us a way
to replicate them?
Thanks.
--
Paolo Cavallini - www.faunalia.eu
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
QGIS-***@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
QGIS-***@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
C Hamilton
2018-09-27 20:46:00 UTC
Permalink
Stefan,

You mentioned getting different results when you densify the polygon. The
results should be the same. With geographiclib all distances are based on
geodesic shortest paths between vertices to calculate the area. I tried
your experiment but used a geodesic densifier on the polygon, calculated
the area, and in both cases they were almost identical. The only difference
was way down in the noise. What this tells me is that whatever densify
algorithms you were using, they were not geodesic.

Regards

On Wed, Sep 26, 2018 at 4:36 PM Stefan Blumentrath <
Post by Stefan Blumentrath
Hi,
Even if the discussion already moved on, for the record below some more
PostGIS (in UTM 33N): 14727443738.0 m2
GRASS 7.4 (in WGS84): 14707741818.0911
GRASS 7.4 (in UTM33): between 14707741818.0911 m2 and 14727443738.0262 m2
(depending on how much one densifies vertices on the boundaries during
reprojection, the latter value measured without boundary vertex
densification)
Please see also: https://issues.qgis.org/issues/12057 for earlier
discussion of area calculations in QGIS...
And https://trac.osgeo.org/grass/ticket/3356 for recent changes in area
calculations in GRASS.
Cheers
Stefan
-----Original Message-----
Sent: tirsdag 25. september 2018 15:32
Subject: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0
Right, here are the calculated areas as returned by a number of different
Caris LOTS: 14.737 km^2
ArcMap: 14.727,446 km^2
MapInfo: 14.727,352 km^2
GeoMedia: 14.726,443 km^2
Planimeter: 14.722,522 km^2
QGIS 3.2: 14.652,181 km^2
QGIS 2.8: 14.652,181 km^2
https://gist.github.com/kbevers/207b5bcb9be20e7554abe5f56742ec2c
I am quite confident that GeographicLib delivers the most accurate result
(if you have doubts, this reference [0] should convince you). As can be
seen from the table above all but QGIS come fairly close. I expect some
variation in the results as these are numerical approximations, although I
think QGIS is too far of the mark. My suspicion is that the geodesic
algorithm used by QGIS (and apparently GRASS) is to blame here.
/Kristian
[0] https://arxiv.org/pdf/1102.1215.pdf
-----Oprindelig meddelelse-----
Kristian Evers
Sendt: 25. september 2018 09:15
Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0
It's not a small area, that's why I have been nitpicking ellipsoid area
calculation algorithms!
I did end up doing the calculations with geographiblib to get a reference
to judge various other calculations by. It's a pain in the butt to extract
the data from a polygon shapefile (or whatever) and format it to suit the
planimeter app of geographiclib. It would be so much cooler if I could get
the same results by clicking info on a polygon in QGIS :-)
/Kristian
-----Oprindelig meddelelse-----
Sendt: 25. september 2018 09:07
Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0
Post by Kristian Evers
Hi Paolo,
I have some rought notes that I can try to polish up a bit and share
here.
Post by Kristian Evers
I'll see if I can find the time for that today. I didn't get to the
bottom of the problem but I am leaning towards the issue being that
QGIS uses an inferior algorithm to determine geodesics. Unfortunately
I couldn't find out from either the source code or the documentation
which algorithm is used.
Post by Kristian Evers
As far as I remember it differs from the otherwise popular algorithm
by Vincenty. That may be because a different algorithm is used or the
Implementation is wrong.
I'll get back with a better write-up later and some test data and
results.
https://github.com/qgis/QGIS/blob/master/src/core/qgsdistancearea.cpp#L690
https://trac.osgeo.org/grass/browser/grass/trunk/lib/gis/area_poly1.c?rev=71260
It's not very stable for very small areas -- better to use cartesian
calculations there. Or bring in geographiclib and punt the responsibility
elsewhere ;)
Nyall
Post by Kristian Evers
/Kristian
-----Oprindelig meddelelse-----
af Paolo Cavallini
Sendt: 25. september 2018 08:23
Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0
Hi Kristian,
Post by Kristian Evers
On a related note, I have been meaning to raise a similar issue
based on QGIS’s not so accurate polygon-area-on-the-ellipsoid
calculations.
Post by Kristian Evers
Post by Kristian Evers
A colleague of mine came across some differences between QGIS and
CARIS LOTS while doing area calculations in relation to a border
dispute at sea. After that I tested several popular closed source
GIS apps and they all performed better than QGIS.
this is worth exploring in detail. could you please be more specific?
do you have a test case? could you share the results, or give us a way
to replicate them?
Thanks.
--
Paolo Cavallini - www.faunalia.eu
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
C Hamilton
2018-09-27 16:34:37 UTC
Permalink
I am resending this since I did not include everyone.

I wrote a little script that calculates the area using geographiclib in
QGIS. You need to have the Shape Tools plugin installed and then change the
path accordingly in the script. You also need to have the polygon layer
selected in QGIS because it is looking for the active layer and it only
pulls out the first polygon. You can run it from the python console. Here
are the results running it on your polygon.

num = 4017
perim = 503.3782852369916 km
area = -14737.935340098571 km^2

It is interesting that the area is negative. It must be the direction that
he points are added. This value corresponds to Caris LOTS.

Calvin
Post by Kristian Evers
Right, here are the calculated areas as returned by a number of different
Caris LOTS: 14.737 km^2
ArcMap: 14.727,446 km^2
MapInfo: 14.727,352 km^2
GeoMedia: 14.726,443 km^2
Planimeter: 14.722,522 km^2
QGIS 3.2: 14.652,181 km^2
QGIS 2.8: 14.652,181 km^2
https://gist.github.com/kbevers/207b5bcb9be20e7554abe5f56742ec2c
I am quite confident that GeographicLib delivers the most accurate result
(if you have doubts, this reference [0] should convince you). As can be
seen from the table above all but QGIS come fairly close. I expect some
variation in the results as these are numerical approximations, although I
think QGIS is too far of the mark. My suspicion is that the geodesic
algorithm used by QGIS (and apparently GRASS) is to blame here.
/Kristian
[0] https://arxiv.org/pdf/1102.1215.pdf
-----Oprindelig meddelelse-----
Kristian Evers
Sendt: 25. september 2018 09:15
Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0
It's not a small area, that's why I have been nitpicking ellipsoid area calculation
algorithms!
I did end up doing the calculations with geographiblib to get a reference to judge
various other calculations by. It's a pain in the butt to extract the data from a
polygon shapefile (or whatever) and format it to suit the planimeter app of
geographiclib. It would be so much cooler if I could get the same results by
clicking info on a polygon in QGIS :-)
/Kristian
-----Oprindelig meddelelse-----
Sendt: 25. september 2018 09:07
Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0
Post by Kristian Evers
Hi Paolo,
I have some rought notes that I can try to polish up a bit and share
here.
Post by Kristian Evers
I'll see if I can find the time for that today. I didn't get to the
bottom of
Post by Kristian Evers
the problem but I am leaning towards the issue being that QGIS uses an
inferior algorithm to determine geodesics. Unfortunately I couldn't find
out
Post by Kristian Evers
from either the source code or the documentation which algorithm is used.
As far as I remember it differs from the otherwise popular algorithm by
Vincenty. That may be because a different algorithm is used or the
Implementation is wrong.
I'll get back with a better write-up later and some test data and
results.
https://github.com/qgis/QGIS/blob/master/src/core/qgsdistancearea.cpp#L690
https://trac.osgeo.org/grass/browser/grass/trunk/lib/gis/
area_poly1.c?rev=71260
It's not very stable for very small areas -- better to use cartesian
calculations there. Or bring in geographiclib and punt the
responsibility elsewhere ;)
Nyall
Post by Kristian Evers
/Kristian
-----Oprindelig meddelelse-----
af Paolo Cavallini
Post by Kristian Evers
Sendt: 25. september 2018 08:23
Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0
Hi Kristian,
Post by Kristian Evers
On a related note, I have been meaning to raise a similar issue based
on QGIS’s not so accurate polygon-area-on-the-ellipsoid calculations.
A colleague of mine came across some differences between QGIS and
CARIS LOTS while doing area calculations in relation to a border
dispute at sea. After that I tested several popular closed source GIS
apps and they all performed better than QGIS.
this is worth exploring in detail. could you please be more specific? do
you have a test case? could you share the results, or give us a way to
replicate them?
Thanks.
--
Paolo Cavallini - www.faunalia.eu
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Mark Johnson
2018-09-25 07:25:54 UTC
Permalink
This may also be caused by:

/*
* From original rttopo documentation:
* Tested against:
* http://mascot.gdbc.gov.bc.ca/mascot/util1b.html
* and
* http://www.ga.gov.au/nmd/geodesy/datums/vincenty_direct.jsp
*/
QgsPointXY QgsDistanceArea::computeSpheroidProject(
const QgsPointXY &p1, double distance, double azimuth ) const

which is used in rtspheroid.c when GeographicLib is not avaliable.

Mark
Continue reading on narkive:
Loading...