[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[geovrml] binary grid format - WAS: For The Visualiza tion Junkies (fwd)
Hi,
there are already a lot of binary formats for elevation grids, including or
not some header information in the file, or as a separate file, althought
none compressed AFAIK (unless for proprietary formats). But gzip is never
far away isn't it.
Since geoVRML is slowly sliding from the visualisation arena to geographic
enabled visualisation, I think we should opt for :
* a format that enables geographic registration (specifying coord system,
etc ...)
* a format that enables tracking of information source (how has it been
modified, is it copyrighted, etc ...)
In addition, seeing the recent devs of the group, or from Mr Parker, or from
dot geo, I would argue for an
interoperable format, easy to get in and out of a GIS system, easy to reuse
as part of the devlopment process. We all now how tedious it is to find on
our disk the grid version adequately decimated, interpolated like needed,
and containing in itself all the info needed for adjusting a model after a
resolution change (cf Mr Parker proposal). This leads to a huge amount of
grids/subgrids scattered on disks, which usually leads to go back to the
original data, reinterpolate it, readjust details, and produce again a whole
bunch of files ...
Wouldn't it be nice to define a format that would carry enough information
to automagically generates an adaptated grid 'on the fly', when just
specifying a raster georeferencing, a scale, a desired quality.
This is what Mr Parker proposition leads to in it's full extent ... but it
must be controlled by geographic standards.
Think about a refinement scheme as depicted. How would you specify such a
refinement information out of a simple grid file ? well there's no problem
if you're using a 'real' draping (satellite or aerial orthophoto). But you'd
run into problems as soon as you're draping is a virtual representation (a
map, a GIS output) since there will be scale problems (road segments will
not fit the geometry anymore, lake would go up hills, etc ...), and if you
put objects on the ground, there's no way to 'anchor' them on a 'undefined'
ground ... Those are severe limitations, but linked essentially to
engeneering constraints.
I don't really know how to circumvents these (it's already not this easy in
2D), but I feel we should think this over : binary or not, the grid format
must carry some information that'll define it's possible use (and source of
original data is crucial for this, for it enables to use associated vector
data), a limit or a scheme for over / subsampling (ideally, depending on the
surface interpolating schemes must be very different IDW, kriging, NN, etc
...), associated data scale (geographic one)
As an example, this is my very own proprietary format I'm using in my devs
(as a compressed binary form btw), this is a primer ! it's never been out of
my computer yet ! ;):
header info :
* Author or vendor information
* Copyright
* Date of creation of the original (very usefull in urban or engineered
areas)
* FullPath (just in case I copy ar move the file around, I can easily find
the original)
* dirty (has it been modified ?)
* interpolation type used
* higherGrid (if it's derived from a another higher res grid, this links to
it)
* subGridFrom (if it's part of a tiled grid set, this links to to the higher
level grid)
* GridSubIndex (if the preceding field is filled this gives the index in the
collection)
* AssociatedTIN (I usually link some triangulated objects (IFS) to a grid
tile)
* Infos (authors notes)
* offset (height offset if needed)
* projection
* georeferencing information
* nb lines
* nb rows
* cell height
* cell width
* noDataValue
* minHeight
* maxHeight
... and then the data itself (I'm not playing endians ... this is for
internal use on my PC:!)
An associated TIN file carries the same type of information plus constraints
information
This eases authoring, and that is the main target of it. But if we adopt
sophisticated visualization schemes (like Mr Parker's), we're not very far
away from authoring conditions, and I guess such embedded information would
be very usefull.
Eric.
> -----Message d'origine-----
> De : geovrml-bounce@AI.SRI.COM [mailto:geovrml-bounce@AI.SRI.COM]De la
> part de Martin Reddy
> Envoyé : mardi 26 juin 2001 20:25
> Ā : Jan-Olof@ai.sri.com Janson
> Cc : GeoVRML@ai.sri.com List
> Objet : [geovrml] Re: SV: SV: Re: SV: Re: Re[2]: [www-vrml] For The
> Visualiza tion Junkies (fwd)
>
>
>
> I don't quite see why you want to translate a TIFF into an RGB JPEG. As I
> understand it, you are talking about using an image file format to contain
> the elevation values in a compact binary form for streaming into a
> GeoElevationGrid type node. An elevation grid is not an RGB image and
> shouldn't be treated as one. You could use something like a TIFF format
> because it gives you support for 32-bit pixel values, but this is
> not going
> to be viewable in common image viewers by default. If you use
> TIFF, then you
> are requiring the client to be able to read TIFF images, which is not
> trivial. Another option is to look for another, more suitable
> binary format
> for storing a grid of elevation values, even using a raw stream of
> floats/integers (where the endianness is well specified). I understand the
> argument of using existing image tools to create the elevation grid, but
> elevation data do not normally come in an image format and most
> common image
> tools can't handle the 16-bit or 32-bit components that are needed for
> representing elevation values.
>
> Cheers,
>
> Martin.
>
>
> On Tue, 26 Jun 2001, Jan-Olof Janson wrote:
> > Maybe it would be possible to use all the three channels in the JPEG?
> > The problem is maybe then how the 24 bit Greyscale TIFF should be
> > translated into a RGB JPEG. For better resolution, maybe two parallel
> > JPEG may be used.
> >
> > // Best Regards J.O Janson
> >
> >
> > -----Ursprungligt meddelande-----
> > Från: Martin Reddy [mailto:reddy@AI.SRI.COM]
> > Skickat: den 25 juni 2001 17:32
> > Till: Jan-Olof Janson
> > Kopia: GeoVRML@ai.sri.com List
> > Ämne: Re: [geovrml] SV: Re: SV: Re: Re[2]: [www-vrml] For The
> > Visualization Junkies (fwd)
> >
> >
> >
> > Using a binary format would be good for improved streaming, however,
> > using an 8-bit greyscale image format is not going to be a good idea
> > because of course it limits you to only 256 discrete elevation levels.
> > For our terrain system, we use either 32-bit integers, or 16-bit
> > integers
> > with a scale and offset to give sufficient precision and range. TIFF
> > can handle 32-bit pixel values, or perhaps there is a more simple
> > binary format out there to suit our needs - TIFF is a pretty complex
> > format?
> >
> > Cheers,
> >
> > Martin.
> >
> >
> > On Mon, 25 Jun 2001, Jan-Olof Janson wrote:
> > > I suggest that some kind of binary format is used. Maybe, the
> > > elevationgrid could be represented by a progressive greyscale JPEG
> > file.
> > > I guess that BSP is a good algoritmh for hidden surface optimisation.
> > It
> > > would be nice if it was possible to use the TrimmedSurface node on the
> > > elevationgrid (Mentioned in X3D Nurbs extension). This could be used
> > for
> > > parts of higher details, like road models.
> > >
> > > // Regards J.O Janson
> > >
> > >
> > > <Qouted>
> > >
> > > > That should be included in the standards, like X3D. It seems
> > > > to me that Cortonas spline objects, like SplineElevationGrid
> > > > should be included in standards as well. By the way, will
> > > > there be a GeoAdaptiveSplineElevationGrid? A very optimised
> > > > terrain description (except the name maybe ;-) )
> > > >
> > >
> > > We want to create GeoElevationGrid that can increase its detalisation.
> > > Our
> > > algorithm can increase detalisation only on visible place - all
> > geometry
> > > outside screen will be in default resolution (as defined in
> > > GeoElevationGrid).
> > >
> > > I have plane to implement concept of "data providers" - components
> > that
> > > provide additional data to geo-coordinate. For example, default data
> > > provider will be Terrain Data Provider - when GeoAdaptiveElevationGrid
> > > split
> > > edge, it ask provider to provide height in new point. Provider can ask
> > > terrain database or use some other methods.
> > >
> > > I want to create this node with you, because you expirience is very
> > > important for me. We can discuss all - beginning from node type name
> > > (GeoAdaptiveElevationGrid at this time).
> > > At this time I can show you default implementation that just split
> > each
> > > edge
> > > to 2 equal parts. Use Wireframe rendering for view effect.
> > >
> > > At this time node has following declaration:
> > > EXTERNPROTO GeoAdaptiveElevationGrid [
> > > field SFNode geoOrigin #NULL
> > > field MFString geoSystem #["GDC"]
> > > field SFString geoGridOrigin #"0 0 0"
> > > field SFInt32 xDimension #0 # [0,)
> > > field SFString xSpacing #"1.0" # (0,)
> > > field SFInt32 zDimension #0 # [0,)
> > > field SFString zSpacing #"1.0" # (0,)
> > > field MFFloat height #[] # (-,)
> > > eventIn MFFloat set_height
> > > field SFFloat yScale #1.0
> > > eventIn SFFloat set_yScale
> > > exposedField SFNode color #NULL
> > > field SFBool normalPerVertex #TRUE
> > > field SFBool ccw #TRUE
> > > field SFBool colorPerVertex #TRUE
> > > field SFFloat creaseAngle #0 # [0,]
> > > eventIn SFVec3f set_position
> > > ] [ "urn:web3d:geovrml:1.0/protos/GeoElevationGrid.wrl"
> > >
> > >
> > "http://www.parallelgraphics.com/vrml/proto/GeoVRML/1.0/protos/GeoAdapti
> > > veEl
> > > evationGrid.wrl"
> > > ]
> > >
> > >
> > > All fields as in GeoElevation grid (exclude solid, I omit this field)
> > > eventIn set_position control node. I use ProximitySensor for set
> > > position.
> > >
> > > You can see this node in action at
> > > http://www.parallelgraphics.com/vrml/geo/cities2.wrl
> > >
> > > Use wireframe.
> > > Must work in Cortona 3.1
> > >
> > > Any suggestions are welcome.
> > >
> > > parker
> > > Please, don't expose this discussion outside GeoVRML list.
> > >
> > >
> > >
> > >
> >
> > ------------------------------------------------------------------------
> > ---
> > 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
> >
> >
> >
>
> ------------------------------------------------------------------
> ---------
> 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
>
>
>