Hi Bob,
The inversion of data is probably down to the --whole-globe settings
for he projection assuming a particular orientation that data normally
comes in but your data is opposite to this. The --whole-globe option
is really just a convenience function for trying to handle poorly
conditioned data. Part of me is tempted to remove these hardwired
projection methods and force users to set up their data properly
before passing to osgdem - adding the geospatial projection
information in first.
So my recommendation is take the .jpg's and turn them into properly
geospatial data i.e. GeoTiffs using gdal, then pass to osgdem.
As for the texture toggling issue, this is a known bug relating to
mult-threading in osgViewer and the StateSetManipulator not being
thread safe. This is a bug I plan to resolve in OSG-2.4. The bug has
nothing to do with paged databases, it's merely a timing issue when it
appears on some models/machines and not others.
Robert.
On Nov 28, 2007 3:48 PM, Bob Kuehne <[EMAIL PROTECTED]> wrote:
> hi chris, thanks for the update!
>
> actually, the problem i'm running into is if i invoke this command:
>
> osgdem --geocentric -v 2000. -l 5 --whole-globe -t world.topo.bathy.
> 200407.3x21600x10800.jpg --whole-globe -d srtm_ramp2.world.
> 21600x10800.png --compressed --mip-mapping-hardware -o globe.ive
>
> i get results like the attached images. close, elevated, but not quite
> in the right spot. it's not clear to me why the original images, are
> in the same coordinate space, but once applied via osgdem, the color
> is right, but the height, not so much. it kinda looks like it's
> flipped about the equator. scaled source images & result images
> attached.
>
> how would i flip it? i suspect i need to change the transform somehow:
>
> Transform {
> 360 0 0 0
> 0 180 0 0
> 0 0 1 0
> -180 -90 0 1
> }
>
> to ... ?
>
> bug? user bug? conceptual bug?
>
> bob
>
> ps - also, another bug. when i look at this in osgviewer, 't' turns
> the texture off, but 't' again, doesn't toggle. works great if i try
> 'osgviewer cow.osg', but 'osgviewer globe.ive', 't' toggle is broken -
> the textured image never returns. i'll wager it has something to do
> with the paged db.
>
>
>
> On Nov 28, 2007, at 9:20 AM, Christoph Ehrler wrote:
>
> > Hi Bob,
> >
> > I have to disappoint you - sorry.
> > I gave up after a while and use a "flat" earth now...
> > (you can't see the mountains anyway if you don't zoom too much ;-)
> >
> > Cheers
> > Christoph
> >
> >
> > On Nov 28, 2007 2:48 PM, Bob Kuehne <[EMAIL PROTECTED]> wrote:
> >> hi chris, did you ever get this figured out? i'm running into the
> >> same
> >> problem. thanks! bob
> >>
> >>
> >> On Sep 19, 2007, at 5:19 AM, Christoph Ehrler wrote:
> >>
> >>> Hi @ all,
> >>>
> >>> probably it's a noob question...
> >>> I downloaded some data from NASA Blue Marble
> >>> (http://visibleearth.nasa.gov/view_set.php?categoryId=2355&p=3)
> >>> and tried to produce a whole earth representation with topography.
> >>>
> >>> But the height field does not match the texture. North and South are
> >>> mixed up as well as East and West. But when I start mirroring and
> >>> flipping the height field JPG it does not resolve much.
> >>>
> >>> Height field and texture are perfectly matching when using a normal
> >>> image viewer.
> >>> The problem is, if I use the height field as a texture the
> >>> "mountains"
> >>> show up at a complete different location than they show up as "real
> >>> bumps" when using the same file as height map.
> >>>
> >>>
> >>>
> >>> Height Field:
> >>> BMNG Raw Topography
> >>> srtm_ramp2.world.21600x10800.jpg
> >>>
> >>> Texture:
> >>> Blue Marble Next Generation w/ Topography and Bathymetry
> >>> world.topo.bathy.200406.3x21600x10800.png
> >>>
> >>>
> >>> I converted both data sources with gdal_translate to TIF files and
> >>> added a image pyramid with gdaladdo but it didn't resolve anything.
> >>> I am building the paged database to single files (IVE) instead of
> >>> building to an archive (OSGA) but as I can remember it makes no
> >>> difference for this problem too.
> >>>
> >>>
>
> >
> >>> gdal_translate srtm_ramp2.world.21600x10800.jpg srtm_ramp2.world.
> >>> 21600x10800.tif
> >>> gdaladdo -r average srtm_ramp2.world.21600x10800.tif 2 4 8 16 32
> >>>
> >>> gdal_translate world.topo.bathy.200406.3x21600x10800.png
> >>> world.topo.bathy.200406.3x21600x10800.tif
> >>> gdaladdo -r average world.topo.bathy.200406.3x21600x10800.tif 2 4 8
> >>> 16 32
> >>>
> >>>
> >>> osgdemd --whole-globe -d srtm_ramp2.world.21600x10800.jpg
> >>> --whole-globe -t world.topo.bathy.200406.3x21600x10800.tif -l 5 -v
> >>> 1000 --geocentric -o blue_marble2.ive
> >>>
> >>>
> >>>
> >>> Some suggestions welcome :)
> >>> Thanks
> >>> Christoph
> >>> _______________________________________________
> >>> osg-users mailing list
> >>> [email protected]
> >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >>
> >> bob kuehne
> >> founder and ceo - blue newt software
> >> www.blue-newt.com 734/834-2696
> >>
> >>
> > _______________________________________________
> > osg-users mailing list
> > [email protected]
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
> bob kuehne
> founder and ceo - blue newt software
> www.blue-newt.com 734/834-2696
>
>
>
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
