[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[geovrml] Re: binary grid format - WAS: For The Visualiza tion Junkies (fwd)
Morning,
I havent had a read of the .bt format yet but I do like a lot the push
for adaptive terrain rendering being done the vtp group.
If we're only looking at raster formats what are the problems with a
standard BIL and an ascii header (extending the esri/gtopo .hdr for
example). The BIL could be binary or ascii, big or little endian. Im not
sure about compression, although the wavelet compression Ive seen used
by ER Mapper's ecw format is very effective when seen in their image web
server. (people do tend to carried away with compression ratios and lose
too much quality wth it though. And the compression seems horrible on
anything more than 8 bit elevation data). 2D Polygon/Polyline versions
using the same header file could also be used. Again, my experience is
with ER Mapper who quite effectively do this with their raster and
vector formats.
< I just got off onto a spiel about tiled representation here and axed
it, slightly different topic and I havent thought it out well enough to
discuss it but it tries to tie streaming, whole earth coverage, adaptive
terrain rendering and constructed models (of objects and very local
terrain features), (the best bits of the TerraVision and VTP projects in
a wishlist) >
Ciao
Martin Reddy wrote:
>
> Hey Eric,
>
> A lot of this information is already stored in the GeoElevationGrid, and the
> rest could be placed in a GeoMetadata node. I guess the question comes down
> to whether you want just a binary version of the height[] array, or whether
> you want a fully-fledged binary format that stands on its own. If we went the
> latter direction, then I think we want to make the best efforts to not
> reinvent the wheel here. There must be some good formats out there that
> already solve this problem.
>
> There is the ESRI binary grid format (.adf) Which includes georeference
> information, RLE compression and grid dimensions, but it uses a bunch of
> files which is rather horrible.
>
> http://gdal.velocet.ca/projects/aigrid/aigrid_format.html
>
> There is the NIMAMUSE Raster Format which can handle 2, 4, and 8-byte values,
> with georeference information, date, and image dimensions.
>
> http://164.214.2.59/geospatial/SW_TOOLS/NIMAMUSE/doc/formats/muserfmt.htm
>
> Finally, Ben Disco put together the BT (Binary Terrain) file format which is
> real simple, includes georeference information, and is supported by products
> such as Leveller, World Construction Set, LandSerf, and XTerra.
>
> http://www.vterrain.org/Implementation/BT.html
>
> Any others?
>
> I have to say that I like the .BT format. It's simple, appropriate, and does
> the job. Ben is also on the GeoVRML list, and supporting the VTerrain work
> would be a good thing for us to do IMHO.
>
> Cheers,
>
> Martin.
>
> On Tue, 26 Jun 2001, Eric wrote:
> > 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
> > >
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------------
> 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
--
Garry Keltie
garry.keltie@rmit.edu.au
Interactive Information Institute &
School of Architecture and Design
RMIT