Re: [Geographiclib-users] Find S12 using planimeter

[Mike T. <mw...@gm...>]

On 19 September 2014 01:54, Charles Karney <cha...@sr...> wrote:
> If you want different rules applied for non-simple polygons, then you
> must decompose such polygons into the union of simple polygons.  E.g.,
> change the bow tie quadrilateral
>
>     1 -1
>     -1 -1
>     1 1
>     -1 1
>
> to the hexagon
>
>     1 -1
>     -1 -1
>     0 0
>     -1 1
>     1 1
>     0 0

But of course finding the intersection point (i.e. 0 0) to make the
valid geometry is something altogether different! And yes, I see the
basic approach using a Gnomic projection. What I was looking to see if
computing an area on a non-simple polygon provides a similar answer as
other algorithms, and that it doesn't catch an unexpected exception
(e.g. divide by zero).

On 19 September 2014 10:27, Charles Karney <cha...@sr...> wrote:
> The errors you get will very much depend on the type of polygon.  0.1m^2
> per edge is a worst case; it appears that the errors cancel to some
> extent.
>
> Version 1.37 allows you to compile GeographicLib with Boost or MPFR
> allowing you to use either quad or arbitrary precision.  So perhaps you
> can gauge the errors in your case yourself.  (I can possibly get you a
> binary version of GeographicLib + MPFR for Windows.)  If you are on a
> Linux machine you can also compile using long doubles and get an extra
> 11 bits of precision.
>
> As a practical example...  I have a dataset of the boundaries of Poland
> which has
>
>     67801 edges
>     mean edge 53m
>     min edge 0.06m
>     max edge 10km
>
> Planimeter gives the area as 312679715911.98608 m^2.  The true area is
> 312679715911.9856346137 m^2.  So the error in this case is less than
> 0.001 m^2.

These errors are small enough to me. I might expect the largest errors
to be for simplified polygons with few vertices and many sharp angles.

I'm unable to build a higher precision version. On Debian Wheezy, I
can't compile with either GEOGRAPHICLIB_PRECISION 4 or 5, since the
supported releases of Boost 1.49 or MPFR 3.1.0 don't meet the
requirements for v 1.37 of GeographicLib, which requires either Boost
1.54 or MPFR 3.5.9 (in CMakeLists.txt). So I'll test this out some
other time.

-Mike