Dane Springmeyer wrote:
Gdal-dev,
I just had occasion to rebuild gdal from SVN trunk on Mac OS 10.5, which
worked great.
I thought perhaps recording a few of the warnings might be useful.
Pasted below.
Dane,
Thanks. I have corrected these:
http://trac.osgeo.org/gdal/changeset/15591
Gdal-dev,
I just had occasion to rebuild gdal from SVN trunk on Mac OS 10.5,
which worked great.
I thought perhaps recording a few of the warnings might be useful.
Pasted below.
Dane
[...snip...]
libtool: compile: g++ -g -O2 -Wall -I.. -I../.. -I/Users/spring/src/
gdal/port -I/Users/sp
Roger André wrote:
Hmm, let me ask this a different way. Does the GMT driver implemented
in gmtdataset.cpp support the creation of "Nan" values when writing to
an output dataset?
Roger,
I see no support for handling NaN on read or write in gmtdataset.cpp.
So, no.
Best regards,
--
-
Brian Hone wrote:
Hi Folks,
Sorry if this is a newbie question, but I've looked all over and can't
find any good information.
I have a desktop app (wxGTK / C++ / OpenGL) on which I want to display
all manner of geo-images, in all manner of projections, etc. I have
coded the ability to display
Hi Folks,
Sorry if this is a newbie question, but I've looked all over and can't
find any good information.
I have a desktop app (wxGTK / C++ / OpenGL) on which I want to display
all manner of geo-images, in all manner of projections, etc. I have
coded the ability to display simple NITF, etc. us
Hmm, let me ask this a different way. Does the GMT driver implemented in
gmtdataset.cpp support the creation of "Nan" values when writing to an
output dataset?
Thanks,
Roger
--
On Wed, Oct 22, 2008 at 4:38 PM, Roger André <[EMAIL PROTECTED]> wrote:
> Sooo... apparently nodata values are no
Andrew,
my guess is that your merged1.tif TIFF has areas which are not initialized
(black/transparent areas). gdal_merge.py probably doesn't write any data in
them, thus leading to missing blocks in the file. GDAL support them in
reading, but those kind of tiff files are maybe not supported by
Hello
When I use gdal_merge.py to merge two files and write a geotiff
it creates a file which PhotoshopCS3 cannot read. Yet the result
of passing that tiff through gdal_translate produces a different
tiff (of a completely different size) which *is* readable.
% gdal_merge.py -v -o merged1.tif -of
Hi Tom, Vincent,
I'm using GDAL via Java by means of the SWIG bindings.
The error message automatically appears on the console when I call the
gdal.Open(name, accessType) method and GDAL is unable to open the dataset.
Anyway, I have just taken a look on the thread suggested by Vincent and now
I can
Daniele,
this thread should give you some hints:
http://lists.osgeo.org/pipermail/gdal-dev/2003-March/000323.html
Regards,
Vincent.
Tom Kazimiers wrote:
Hi Daniele,
were to you get those error message? Since GDAL is a library it
shouldn't come up with thing like this - at least not errors w
Hi Daniele,
were to you get those error message? Since GDAL is a library it
shouldn't come up with thing like this - at least not errors which are
shown to the user automatically (like message boxes or std::out prints
(I guess). So if your application gets no dataset for a file it will get
NULL r
Hi all,
I have a quick question on how the Projection information is handled
when creating GeoTIFF files using GDAL's GTIFF driver.
As stated here:
http://www.gdal.org/frmt_gtiff.html
GDAL uses some auxiliary .csv files to pick-up the correct CS.
>From this message:
http://lists.osgeo.org/pipe
Hi list,
Is it somehow possible to customize/hide some GDAL error messages?
I know error messages are really useful to fix/understand problems.
Anyway, let me expose my use case:
I simply need to check if I can obtain a Dataset for a file and return a
boolean.
If I get a Dataset, great! Otherwise.
13 matches
Mail list logo
