Re: DOQ

[Lee Iverson <leei>]

In message <ADC9269D74C5D011A41F00805FEA40E8F1AB69@xch-hsv-02.hv.boeing.com> yo
u write:
> 
> Taking the small question first, a new data type
> seems to me to require an addition to the spec
> (and from here on is personal opinion).
> 
> So what we (geovrml) can do is prepare an email
> letter saying "VRML needs a DoubleCoordinate type"
> and send it off to the VRB.  And we (the VRB) will
> promptly send back a reply "No it doesn't", and
> that takes care of that!
>
> Or we (geovrml) can get a couple of us to prepare a
> paper which will be read at VRML 99 supporting
> the new type.  There will be applause from the
> crowd and the authors will have a new notch in
> their CVs, and nothing will happen.

Here's a fundamental difficulty, and we are definitely expecting it...

There is absolutely no doubt in the geographic, cartographic and
simulation communities that single precision floating point is
inadequate for proper georeferencing.  You simply cannot go from 1m
resolution to 12000km or more (consider satellites) with only 23 bits
of mantissa.  So, the question is, where do we go from here?

As far as I see it, there really *should* be a way to pass double
precision values into script nodes in VRML.  You might answer that
there already is -- simply place the double precision value in the
script string.  A basic question for the geographic (read GeoVRML) and
CAD communities is whether or not this is a reasonable response.
If it is a reasonable response, then clearly we move into the
Recommended Practices mode and formulate standard interfaces to
scripting methods for managing georeferencing.

If it is not adequate, then we will have to justify this conclusion
strongly, and it is certainly *not* a reasonable response from the VRB
or its representatives to simply say "tough luck."  There are
*definitely* more uses than this for double precision values in VRML
worlds.  Maybe the VRB can consider some sort of standard response (a
Recommended Practices document perhaps) which explains to those of us
less enlightened souls how to *easily* inject double precision data
into our worlds...

This is most definitely a piece of functionality we need.  If VRML
cannot or will not provide it, then it is essentially dead in the
water for our needs.  And that includes a recommended practice that is
needlessly cumbersome.

> Or, and this might actually work, we can use the
> extensibility of VRML (e.g., EXTERNPROTOs)
> and a couple of conventions about data typing
> (using MFInt32 and assuming network byte
> ordering -- big Endian -- are very popular ways to
> begin) and prepare a package of VRML extensions
> for geoscientists, demonstrating their usefulness
> in principle.

I don't think there is any doubt that we will be doing exactly this.
The question remains whether or not VRML is actually adequate for
achieving this goal in a straightforward manner.

-------------------------------------------------------------------------------
Lee Iverson     		SRI International
leei@ai.sri.com			333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/	(650) 859-3307
-------------------------------------------------------------------------
for list subscription instructions,
send email to www-vrml-request@vrml.org with text "info"