Hi Cedric,
I was about to, but then forgot it. Also, since no one else had voiced
the same problem and I was terribly new to OSG/GDAL, I ended up just
made a hack in the VPB src instead:
Index: src/vpb/SourceData.cpp
===================================================================
--- src/vpb/SourceData.cpp (revision 927)
+++ src/vpb/SourceData.cpp (working copy)
@@ -33,7 +33,7 @@
defaultValue(0.0f),
noDataValue(-32767.0f),
minValue(-32000.0f),
- maxValue(FLT_MAX)
+ maxValue(55000.0f) // maxValue(FLT_MAX)
{
if (band)
{
...but now that you have reproduced the exact same behaviour, please go
ahead and add a bug report to gdal.
Best regards,
John
Cedric Pinson wrote:
I have the same problem, i did not notice the bug in the trac of gdal
did you report it ?
Cedric
John Vidar Larring wrote:
Hi Robert,
> This sounds like a GDAL bug. Would it be possible for you to provide
> links to the problematic data.
As far as I know this is just the standard GTOPO30 data from USGS. The
DEM files can be downloaded from:
http://edc.usgs.gov/products/elevation/gtopo30/gtopo30.html
> I'd guess the GDAL team might like to look at it as well.
...as in, I should report this to http://trac.osgeo.org/gdal/ ???
Best regards,
John
Robert Osfield wrote:
Hi John,
This sounds like a GDAL bug. Would it be possible for you to provide
links to the problematic data. I'd guess the GDAL team might like to
look at it as well.
Robert.
--
Best regards,
John
WeatherOne
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
