Hi Robert.
My change only makes access to heightfield same way as it
is in non-interpolating code and texture handling code.
So, it makes "Y" direction of image and heightfield the
same. If this change breaks any dataset with geospatial
coordinates, it, IMHO, was already fixed (workarounded)
for this bug, or there is internal flipping for geospatial
coords of heightfield (and not for texture) somewhere in
DataSet.cpp.
Proposed test: apply same geospatial coords to
ps_height_4k & ps_texture_4k and check if it breaks
things.
Can you please provide link to dataset with geospatial
coords, wich breaks with proposed change?
OT: Does anybody knows why there is no polar ice on
bluemarble-500m, and why sea on this images is so dark?
Earlier bluemarbles, as I recall, had both ice and
pleasant sea color.
On Mon, 18 Sep 2006 10:29:04 +0100 "Robert Osfield"
<[EMAIL PROTECTED]> wrote:
Hi Dmitry and Jason,
On 9/18/06, Jason Beverage <[EMAIL PROTECTED]>
wrote:
I just tried your fix with the Puget sound data and
understand what you
mean when you say things are flipped around the Y-axis
now. I'd like to
run it through some sample datasets when I get back to
work on Monday to
make sure it holds up, but it looks pretty good to me,
If we merge the changes Dmitry has provide then we'll fix
it for this data,
but then break for all data with geospatial coords. I
expect the exisitng
interopolation code is correct, and the problem lies in
the set up of GDAL,
and as Norman mentions without any geospatial coords
setup for the data the
interpretation of y orientation isn't properly defined.
Perhpas when no
geospatial coords are defined we just need to setup GDAL
telling it
explictly which way to interpret the y orientation.
Robert.
---
Professional hosting for everyone - http://www.host.ru
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
