All is well - Topic can be closed. I found the info I needed and have
successfully created both osg and ive databases for the terrain data I'm using.
Many thanks for all of the help!
Cheers,
Steven
--
Read this topic online here:
WHen I say build a dataset, I mean, run it through osgdem and produce a
.osg or .osgb and test it.
Start simple, then if you get that working, add complexity until you find
the breaking point, then fix whatever you identify as being the problem.
On Sat, May 4, 2019 at 12:16 AM Steven Jones
Chris,
I can definitely do that, since I have the original files (imagery and
elevation) in segregated in separate sub-directories.
I'd still need to be able to visualize them though as I test the build process
to ensure that I'm seeing the 3D aspect of the overall terrain. With a VRT, I'm
I really feel like you need to step back a couple of steps and get a
working process.
Like, can you build a dataset with JUST elevation data and just ONE simple
GeoTIFF terrain elevation file? When you have a process that works, you can
work forward, adding complexity and watch for where it
Hi Chris "D",
Thanks - I'd done some researching and came to the same basic conclusion... For
now, I'm going to trust that the values are as they should be...
I've created a VRT file using gdalbuildvrt but am not sure how that can be used
now to ultimately create an osg (or osgb) file to use
Hi,
I think they're talking about the C preprocessor definition, FLT_MAX rather
than anything specific to anything used here:
https://www.tutorialspoint.com/c_standard_library/float_h.htm
It's the maximum value of an IEEE 32-bit float.
Cheers,
Chris
--
Read this topic online
Sorry to be a bother Chris, but I've drilled through QGIS' various methods of
viewing GeoTiff metadata but cannot find anything referencing any values named
"Flt_Max". I must be missing something...
...
Cheers,
Steven
--
Read this topic online here:
I would think QGIS would do it. There may be other, simpler tools too.
On Thu, May 2, 2019 at 1:56 AM Steven Jones wrote:
> Chris,
>
>
> Chris Hanson wrote:
> > It's a single-precision 32-bit floating point TIFF. Values could be
> anywhere from -FLT_MAX to FLT_MAX.
> >
> > I've tried several
Chris,
Chris Hanson wrote:
> It's a single-precision 32-bit floating point TIFF. Values could be anywhere
> from -FLT_MAX to FLT_MAX.
>
> I've tried several methods to try to find the FLT_MAX values but so far no
> joy, so I have no idea what it could be set to... Can you recommend a method
It's a single-precision 32-bit floating point TIFF. Values could be
anywhere from -FLT_MAX to FLT_MAX.
I'm just making sure it doesn't have weird values like sea level being 0
and Everest being 8.8 (in units of kilometers).
On Wed, May 1, 2019 at 4:20 PM Steven Jones wrote:
> Chris,
>
> Not
Chris,
Not sure what value range you are referring to (still learning all I can
regarding the GeoTiff file structures).
"This seems plausible. Did you check to see what value range this elevation
TIFF has?"
Steven
--
Read this topic online here:
>
>
> Band 1 Block=1024x1 Type=Float32, ColorInterp=Gray
> don't see the measurement value type, but I'm fairly sure they are both
> in meters. (I also confirmed the above data in QGIS.)
>
This seems plausible. Did you check to see what value range this elevation
TIFF has?
I can't see anything
Chris,
When I examine an image GeoTiff with GDALinfo, here's what is output:
Driver: GTiff/GeoTIFF
Files: N33W118_D004_S001_T001_L00_U0_R0a.tif
Size is 1024, 1024
Coordinate System is:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
Steven,
You should consider making a GDAL VRT. It's a format for compositing source
files together into one virtual data source. You can build it by hand or
use the gdalbuildvrt tool.
https://www.gdal.org/gdalbuildvrt.html
Glenn Waldron / osgEarth
On Mon, Apr 29, 2019 at 7:02 PM Chris Hanson
On Mon, Apr 29, 2019 at 9:09 PM Steven Jones wrote:
> I receive no error messages, and the build completes, but when I use
> osgviewer to inspect the .ive file, it is completely flat - no visible
> change in elevation - terrain resolution is perfect though.
Is the imagery in place and proper
Chris,
I've been trying osgdem to build the database, and pointing to the overall
imagery and elevation sub-directories works fine.
I receive no error messages, and the build completes, but when I use osgviewer
to inspect the .ive file, it is completely flat - no visible change in
elevation -
Also, to add to that, osgdem relies heavily on GDAL to ingest raster data.
GDAL has several tricks for combining multiple files or directories and
referencing them as one dataset. For example:
https://gdal.org/gdal_vrttut.html
I don't recall ever using that technique with VPB, but in theory it
Hi Steven,
It's probably getting on decade since I last used or did any serious
worked on VPB so can't recall the specific command line options to use
off the top of my head. So will just provide some general notes that
may help.
It's possible to have osgdem (single process build) and vpbmaster
I'd downloaded that guide before and briefly reviewed it, but that was when I
first installed VPB but hadn't yet tried it.
It would certainly be much more efficient to combine the imagery and elevation
data and create an osg or ive formatted database.
But, since I have so many GeoTiffs and
Basically, osgEarth is really good at doing fancy layering of data sources.
VPB is a little trickier, but can do most of the same things (for elevation
and raster data anyway).
I was thinking it might be easier to use osgEarth to turn your multiple
layers of GeoTIFF images into a single elevation
Hi Scott,
Are you referring to a TMS dataset? Or something different? (All of my
elevation and imagery files are tiled GeoTiffs.)
Thanks!
Steven
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=75903#75903
I don't have a ready to consume tutorial, but your first goal is to use
osgEarth to build a dataset by merging all your data together.
The second is to feed that to VPB.
Let me think on the matter a bit.
On Thu, Apr 25, 2019 at 7:09 PM Steven Jones wrote:
> Chris - Is there a tutorial of
Chris - Is there a tutorial of some sort that would cover the basic steps to
begin building a database in VPB using GeoTiff elevation and imagery data for
the input?
I've downloaded and compiled VPB (MS Windows), but since it's mainly
command-line driven, it's not all that intuitive. Also,
You're welcome. It may also be conceivable to use osgearth tools to produce
a composite tilemap set to feed to VPB, giving you some of the best of both
worlds.
On Thu, Apr 25, 2019, 4:50 PM Steven Jones wrote:
> I'd considered VPB previously, but now it looks like it may be the most
>
I'd considered VPB previously, but now it looks like it may be the most
practical solution to meet our needs. Wish me luck, and thanks again Chris!
Cheers,
Steven
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=75897#75897
You may need to play with layering and other things to get the results you
want at the borders.
Alternately, have you considered if your work could be built through
Virtual Planet Builder, which DOES actually just produce "dumb" .osg
(actually, .osgb is recommended) files?
The result might be
Chris - Thanks for the answer. I do understand the nuts & bolts of the OSG
architecture, but was looking for a way to further streamline loading of a very
large quantity of GIS imagery and elevation data that are referenced within the
.earth file (over 4,000 images and close to 1,000 elev
So, the .earth format is not really a geometry format. It's a descriptor of
a special node data file type used by the osgEarth library, and not
representable in a .osg file.
You can't use a .earth file without the osgEarth library. If you HAVE the
osgEarth library, you can already load .earth and
28 matches
Mail list logo
