Hi Chistopher, The different coordinate systems is what is leading to the difference. When you don't specify a destination coordinate system VPB/osgdem has to choose one for you, and it takes the first entry in the source list as the destination coordinate system to use. If you do specify the coordinate system yourself then you'll avoid this ambiguity.
Robert. On Nov 26, 2007 8:24 AM, Christoph Ehrler <[EMAIL PROTECTED]> wrote: > Hi Robert and Jason, > > yes, there are different coordinate systems: > > texture - lat/long > height - UTM 32N (WGS 84, meter) > > At the time I care about the "optical aspect" only thus I didn't test > which coordinate system the output had. > Unfortunately I can't send images since the data is not ours. I will > do some testing with the Puget Sound data. > > Cheers, have a nice week > Christoph > > > > > On Nov 23, 2007 5:17 PM, Jason Beverage <[EMAIL PROTECTED]> wrote: > > Hi Christoph, > > > > Are your elevation and imagery in the same coordinate system? It's > > been awhile since I've looked at VPB, but if I recall correctly, the > > last input file on the command line is used to determine the > > coordinate system of the output database. So, if someGeoTiff_Height > > is in a geodetic projection and someGeoTiff_Texture is in a UTM > > projection, the first command will produce a database in geodetic and > > the second command line will produce a database in UTM. > > > > VPB should scale height values appropriately (at least it was at one > > point) if you are producing a geodetic database, but this is one > > explanation as to why your output would be different depending on the > > order of your command line arguments. > > > > Good luck! > > > > Jason > > > > > > On 11/23/07, Christoph Ehrler <[EMAIL PROTECTED]> wrote: > > > Hi @ all VTP users and developers, > > > > > > Apparently it's not arbitrary how to arrange the data input for > > > VirtualPlanetBuilder. > > > > > > The first commandline input produces a weired result with texture and > > > heightfield matching but meshing of the heightfield corrupted. Every > > > tile of the heightfield has only one central point to which all > > > triangles converge. > > > The second commandline produces perfect results though -d and -t > > > statements are yust exchanged !?! > > > > > > > > > osgdem -t <someGeoTiff_Texture> -d <someGeoTiff_Height> -l 99 -o <output> > > > > > > > > > osgdem -d <someGeoTiff_Height> -t <someGeoTiff_Texture> -l 99 -o <output> > > > > > > > > > Just to inform you because we spent hours believing it was the > > > compression or the bit depth of the GeoTIFF !! > > > > > > Cheers > > > Christoph > > > _______________________________________________ > > > osg-users mailing list > > > osg-users@lists.openscenegraph.org > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > _______________________________________________ > > osg-users mailing list > > osg-users@lists.openscenegraph.org > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
