RE: ElevationGrid

[rexb@transbay.net (Rex Brooks)]

>> Neil Woodhouse[SMTP:N.Woodhouse@earth.leeds.ac.uk] sez:
>>
>> >[.....]This is the kind of thing an authoring tool should do for you.
>> You note that there are too>ls out there to create height field image
>> files--it just as easy to go the other
>> >direction.
>>
>> Prismatic Booger
>>
>> Yes, that's fine, but i want to see it within the VRML spec. I don't
>> want to be spending hundreds of dollars/pounds on authoring tools that
>> aren't *truly* spec compliant. I'm again thinking about the end user
>> here, which in my case is the student who wants to use VRML as a
>> geographic/geologic  project.
>>
How is having it in the spec going to make any particular difference to
creating  the Egrid or IFS from the dataset?

Personally, I think the java applet script Justin Couch just cooked up
today is the direction to go, whether you're using photgrammetric images or
DEMs. The thing with Java is that you just plug in the class and go.

What we really need is a Java3d API, which is promised for the JavaOne Show
3/24-27. (Pant... GHasp!). With that, we SHOULD be able to create a whole
class of VRML classes that take geodatasets as InputStreams and turn out
EGrids or IFSs as OutputStreams--OOps, looks like a crossover or fusion
with Streams, but I'll leave that to the more technically proficient. Could
receiving the OutputStream as an EventOut  build a terrain from the
origin->out?

Bob's default methodology below works. I'm a modeler--Content Developer--I
did it months ago. And, yes, its the data set that's the thing. What I
would like would be a transition between a LowPoly Egrid LOD and more
precise and HigherPoly IFS using the same dataset.

>I think I'm catching the glimmerings of an idea here.
>
>Modelers tend to start with geo data files the
>way they start with DXF or 3DS or OBJ files:
>the file is a *resource*, but it's only something
>that *goes into* the final file which is a VRML
>wrl file.  It's the final VRML file that's kept and
>is the valuable asset.  That is, I'll take a DXF
>or DEM file and convert it to VRML 1, then apply
>LODestar to it to decimate the mesh, then
>convert it to VRML 97, run it through unnormal
>(to get rid of unneeded normal fields), vwaif
>(to get rid of extra characters) -- and when
>I'm happy with the final VRML 97 world, I'll
>keep that file and toss out every one of the
>intermediate files, including the DXF or DEM
>file.


Better keep the datafile.
>
>I think I'm hearing a very different paradigm here,
>and I wanted to get a little reality check.  I
>believe I'm hearing that the valuable asset,
>the one that's kept, is the geo file, be it DEM
>or height field image map or whatever.  The
>VRML file is only the *means* of viewing and
>sharing and combining for analysis the geo
>data, and at the end of the day the VRML file
>may be discarded.
>
that's what Neil needs--a viewer that is variable with LOD needed, without
the expensive 3D Studio Max-type tools, let alone the neverending upgrades.

>If that's the mental model, then no wonder that
>a solution which is intuitive to modelers (a
>set of conversion tools) is unsatisfactory.
>
>So (and the answer to this is probably domain
>specific) are VRML files permanent assets or
>simply means to view the real assets?
>
the latter methinks.

Thanks for focusing the issue, Bob.

Rex

Rex Brooks Communications Design        1361-A Addison, Berkeley, CA
rexb@rbcomdesign.com                     Tel: 510-849-2309
http://www.rbcomdesign.com               Fax: 510-849-1306