[geovrml] Re: GeoLocation: comments and questions

[Martin Reddy <reddy>]

On Mon, 12 Jun 2000, Chris Thorne wrote:
> If I want to zoom into a digital Earth model from space down to some
> highly detailed house in Queensland, Australia then I can use GeoLocation
> to take care of the precision issues. If I were then to zoom out to see
> the Earth revolving around the Sun then I would need a GeoLocation node
> (used like a Transform node) around Earth, adjusting the tansform
> parameters to keep earth moving.  I see two problems here:
> 
> 1) GeoLocation does not allow nesting like a normal Transform so moving
> the Earth by changing the GeoLocation node around Earth does not move the
> models in Queensland.
>
> 2) GeoLocation does not have rotation parameters that I could use to keep
> the planet rotating.  Would I just have to include a Transform node at
> the top level within the GeoLocation and apply rotation to that?  Then it
> would not compose with the inner GeoLocation (given its current spec).

Mmmm, interesting point Chris.

The GeoLocation node is used to specify a point on the surface of a planet
(currently the earth). As such, I do not think that it is the place for
performing a rotation of an object, i.e. the location of an object on the
planet does not change because the earth is spinning.

I think that best solution would be to have a top-level Transform node as you
suggest. If you have not specified a GeoOrigin, then you know that the
(0,0,0) center is the center of the planet and could probably work out a good
GCC coordinate to specify the location of your point of rotation (e.g. using
the center field of the Transform node). However, if you have used a
GeoOrigin node, then the center would need to offset the GCC coordinate of
the origin. You could do this with some math apriori and embed this in the
scene, but you are right that there is not a good or robust way to do this.

I was wondering if it would make sense to have a new GeoVRML node to deal
with this, e.g. GeoRotation, where you would specify the geographic location
of your rotation point and a standard SFRotation (that could be linked up to
an interpolator or sensor as usual), e.g.

EXTERNPROTO GeoRotation [
   field    SFNode     geoOrigin
   field    MFString   geoSystem
   field    SFString   geoCenter
   field    SFRotation rotation
   eventIn  SFRotation set_rotation
   eventOut SFRotation rotation_changed
]

This would essentially be a Transform node that sets the center field (not
the translation field) to the correct coordinate based upon GeoOrigin
specified. I think I like the fact that this is segregated from the
GeoLocation functionality, but I haven't thought about it much yet. I also
haven't tested any of this either to see if it actually works.

> 3) If double precision is needed for positioning/origins then would it
> not be needed for rotations too? 

I don't think that we need double-precision for rotations. Single precision
should be enough to differentiate out to 6 or 7 decimal places of a rotation.
In terms of real world precision, my quick and dirty math says that should
let you differentiate an angle that deviates by a micron over the range of a
kilometre (o = a tan x = 1000 * tan 0.0000001). This also means that we can
still use all the standard VRML interpolators and sensors that deal with
rotations.

> On a completely different note: I get url not found if I click on the
> link for the zip file of the RP doco,

Strange, the link seems to work fine for me. What is the offending page's URL
and what's the link URL that you are trying?

Cheers,

Martin.


---------------------------------------------------------------------------
Martin Reddy                                   SRI International, AI Center
                                               Menlo Park, CA 94025-3493
reddy@ai.sri.com                               Tel : (650) 859-6468
http://www.ai.sri.com/~reddy                   Fax : (650) 859-3735