looking for a spherical trigonometry library

[kfj]

Hi group!

I am doing some panospace maths currently and I'm tired of handcoding
spherical trigonometry. I've spent a fair amount of time looking for a
spherical trigonometry library, but it seems like I can't find one.
Ideal would be a Python library or a C/C++ library with Python
bindings, and even if it were only C/C++ it'd help since I could write
the Python bindings myself.

My current need is something that can do elementary spatial set-
theoretic operations on polygons on spherical surfaces (intersection,
union, difference), like pyton.shapely or GGL, which is now
Boost.Geometry, do for planar polygons. Initially I thought GGL would
do it, but it's merely coordinate-system-agnostic insofar as it can
accept spherical coordinates, but it still works in ordinary 3D, and
not on the sphere's surface.

I'd like something that is well-documented, so a mere bunch of naked
routines won't really do, because there is so much room for ambiguity
in spherical trigonometry (like, handedness and the order of the
coordinates) that having to decipher which conventions are used by a
given body of code isn't much less work than writing it anew.

It should be FOSS, but GPL would be okay.

Any ideas?

Kay

[Tom Sharpless]

Hi Kay

I can't recommend any such library; but I can say that you would be
much better off with 3D vector geometry than trying to use the
spherical trigonometry formulas. For example: given the 3D vertices
of a spherical polygon (which are unit vectors) replace each edge by a
3D plane, represented by its normal vector (which is just the cross
product of 2 vertices). Then the sign of a dot product with the
normal tests which side of the edge a given point is on, and you can
build everything else on that. In other words, you can replace
spherical trig with linear algebra (but not conversely).

The great weakness of trigonometry is that the error, and even
computability, of the functions varies with direction; but linear
algebra works almost independently of direction, and its few
singularities are far easier to detect and avoid. That is why
engineers pretty much stopped using trig (for geometrical work) as
soon as they had mechanical calculators.

I put together a small C++ library of 3D vector functions that I use
all the time for panosphere calculations, you are welcome to use it
if you want to.

Regards, Tom

[kfj]

On 22 Feb., 21:46, Tom Sharpless <tksharpl...@gmail.com> wrote:
>
> I can't recommend any such library; but I can say that you would be
> much better off with 3D vector geometry than trying to use the
> spherical trigonometry formulas.  For example: given the 3D vertices
> of a spherical polygon (which are unit vectors) replace each edge by a
> 3D plane,  represented by its normal vector (which is just the cross
> product of 2 vertices).  Then the sign of a dot product with the
> normal tests which side of the edge a given point is on, and you can
> build everything else on that.  In other words, you can replace
> spherical trig with linear algebra (but not conversely).

I thought about this approach myself but still hoped I could find a
library for spherical surfaces, just merely because the surface of the
sphere is the very ground we stand on, literally and pano-
metaphorically.

> The great weakness of trigonometry is that the error, and even
> computability, of the functions varies with direction; but linear
> algebra works almost independently of direction, and its few
> singularities are far easier to detect and avoid.  That is why
> engineers pretty much stopped using trig (for geometrical work) as
> soon as they had mechanical calculators.

I agree. It is rather cumbersome and unobvious, and I've found it
really hard to get my head around all the maths involved just to be
able to half-ways cope with hugin's lon/lat model and the transforms.
I sometimes dream of keeping all image data as clouds of vectors in 3D
space...

> I put together a small C++ library of 3D vector functions that I use
> all the time for panosphere calculations,  you are welcome to use it
> if you want to.

Thank you for the offer. Would you be so kind to point me to this
library so I can have a look? It might come in handy. On the other
hand, are you aware of GGL, which is now Boost.Geometry?

http://geometrylibrary.geodan.nl/

It does geometry and we already have Boost dependencies in hugin, so
we might as well use it - it's not yet full part of Boost but Boost-
approved, and it treats geometry in a dimension-agnostic way - just
not on curved surfaces. Coding with it is a bit awkward to debug -
like, I reckon, a lot of 'generic' C++ code - I had a case where a
single bug in my program triggered about a hundred screens full of
error messages - but if it works it seems to work just fine, like
vigra. The generic idea is admittedly intriguing.

Kay

[Tom Sharpless]

Hi Kay

e-mail me, I'll send you my 3D vector package.

On Feb 23, 12:12 pm, kfj <_...@yahoo.com> wrote:
> On 22 Feb., 21:46, Tom Sharpless <tksharpl...@gmail.com> wrote:
> > I can't recommend any such library; but I can say that you would be
> > much better off with 3D vector geometry than trying to use the
> > spherical trigonometry formulas.  For example: given the 3D vertices
> > of a spherical polygon (which are unit vectors) replace each edge by a
> > 3D plane,  represented by its normal vector (which is just the cross
> > product of 2 vertices).  Then the sign of a dot product with the
> > normal tests which side of the edge a given point is on, and you can
> > build everything else on that.  In other words, you can replace
> > spherical trig with linear algebra (but not conversely).
>
> I thought about this approach myself but still hoped I could find a
> library for spherical surfaces, just merely because the surface of the
> sphere is the very ground we stand on, literally and pano-
> metaphorically.

Yes, but spherical trigonometry is a nightmare.

The fact that the panosphere happens to be a 2-D surface is not really
relevant to most of the uses to which we put it, because mostly we are
concerned about directions in space, not points on a surface. Any 3-
vector will do for specifying a direction; when you need to map it to
the sphere, just normalize the vector.

>
> > The great weakness of trigonometry is that the error, and even
> > computability, of the functions varies with direction; but linear
> > algebra works almost independently of direction, and its few
> > singularities are far easier to detect and avoid.  That is why
> > engineers pretty much stopped using trig (for geometrical work) as
> > soon as they had mechanical calculators.
>
> I agree. It is rather cumbersome and unobvious, and I've found it
> really hard to get my head around all the maths involved just to be
> able to half-ways cope with hugin's lon/lat model and the transforms.
> I sometimes dream of keeping all image data as clouds of vectors in 3D
> space...
>

Best to keep image data in 2D arrays, and use the panosphere only as
the reference surface for coordinate mappings.

> > I put together a small C++ library of 3D vector functions that I use
> > all the time for panosphere calculations,  you are welcome to use it
> > if you want to.
>
> Thank you for the offer. Would you be so kind to point me to this
> library so I can have a look? It might come in handy. On the other
> hand, are you aware of GGL, which is now Boost.Geometry?
>
> http://geometrylibrary.geodan.nl/
>
> It does geometry and we already have Boost dependencies in hugin, so
> we might as well use it - it's not yet full part of Boost but Boost-
> approved, and it treats geometry in a dimension-agnostic way - just
> not on curved surfaces. Coding with it is a bit awkward to debug -
> like, I reckon, a lot of 'generic' C++ code - I had a case where a
> single bug in my program triggered about a hundred screens full of
> error messages - but if it works it seems to work just fine, like
> vigra. The generic idea is admittedly intriguing.

I dislike 'generic programming', for the reason you mention: it makes
many bugs into obscure compiler errors, that are much harder to
diagnose than bugs in 'real' code (this is just a toolset problem, of
course, someday compilers may offer better diagnostics for deep
template errors). Plus it can generate code that is essentially
impossible to debug in the usual way, simply because it runs mortally
slow, when a lot of temporary objects get instantiated and deleted in
inner loops (without debug checks, the slowdown is far less
noticeable). I really think this is more of a solution in search of a
problem than a practical advancement in programming technology. But
Vigra does work....

Regards, Tom

>
> Kay

[dmg]

On Wed, Feb 23, 2011 at 1:45 PM, Tom Sharpless <tksha...@gmail.com> wrote:
>
> I dislike 'generic programming', for the reason you mention: it makes
> many bugs into obscure compiler errors, that are much harder to
> diagnose than bugs in 'real' code (this is just a toolset problem, of
> course, someday compilers may offer better diagnostics for deep
> template errors).  Plus it can generate code that is essentially
> impossible to debug in the usual way, simply because it runs mortally
> slow, when a lot of temporary objects get instantiated and deleted in
> inner loops (without debug checks, the slowdown is far less
> noticeable).  I really think this is more of a solution in search of a
> problem than a practical advancement in programming technology.  But
> Vigra does work....
>

For these reasons I find it difficult to understand and maintain if I
am not the original author.

--
--dmg

---
Daniel M. German
http://turingmachine.org