I'm trying to use the following code to detect a possible error caused
by the GetGeoTransform() call, but it reports no error has occurred, and
does not raise an exception.
Making this call on the same dataset from native C code returns
CE_Failure from GDALGetGeoTransform().
Here's the C#
hi list,
I am trying to make gdal 1.5.3 on linux (Redhat Enteroprise)
I use HDF4.2 r3 and HDF5 1.8.2.
here is the error message:
libtool: compile: g++ -g -O2 -Wall
-I/home/sgong/dev181/gdal-1.5.3/port
-I/home/sgong/dev181/gdal-1.5.3/gcore
-I/home/sgong/dev181/gdal-1.5.3/alg
Gong, Shawn (Contractor) wrote:
Thank you Frank and Andrew Brooks.
Following your leads, I went to check the ticket #2609 and the nightly
snapshot of the 1.5 branch.
I have two questions:
1) Is http://download.osgeo.org/gdal/daily/ always the latest update on
the last public release (currently
hi list,
I have made gdal 1.5.3 using the stable branch
http://download.osgeo.org/gdal/daily/
After make install, libgdal.so.1.12.3, libgdal.la, libgdal.a were
generated in /local-install/lib/
However compared to my previous gdal 1.4.0, these files are missing
under
Hey,
I'm using GDAL to read in a NITF image and write it out as either a NITF
or a GeoTiff file, and I'm basically doing it the same way as
gdal_translate but with a few changes. The reason I'm writing is because
when the GeoTIFF gets written out using CreateCopy(), the ColorInterp data
is gray
Tom V. wrote:
Hey,
I'm using GDAL to read in a NITF image and write it out as either a NITF
or a GeoTiff file, and I'm basically doing it the same way as
gdal_translate but with a few changes. The reason I'm writing is because
when the GeoTIFF gets written out using CreateCopy(), the
Michael P. Gerlek wrote:
int sceneWidth = (int)(nXSize * maxWidth / (double)maxWidthAtL0 + 0.99);
int sceneHeight = (int)(nYSize * maxHeight / (double)maxHeightAtL0 +
0.99);
Ouch, you shouldn't be doing rounding like that. Use the getDimsAtMag()
function to get the exact width/height you
I've been mercilessly beating a dead horse on a couple of lists about some
weird artifacts that I'm getting when doing reprojections in Mapserver from
epsg:4326 to epsg:900913. It's recently come to my attention that something
was discussed in an IRC chat that might be pertinent to this issue,
Roger André wrote:
I've been mercilessly beating a dead horse on a couple of lists about
some weird artifacts that I'm getting when doing reprojections in
Mapserver from epsg:4326 to epsg:900913. It's recently come to my
attention that something was discussed in an IRC chat that might be
Hi Frank,
I've theorized all sorts of reasons for what I'm seeing. So far none of
them are right. Basically, if I take a really high-res epsg:4326 image, and
serve it up through Mapserver in epsg:900913, there are instances where I
get images back which are missing rows of pixels at the bottom
Roger André wrote:
Hi Frank,
I've theorized all sorts of reasons for what I'm seeing. So far none of
them are right. Basically, if I take a really high-res epsg:4326 image,
and serve it up through Mapserver in epsg:900913, there are instances
where I get images back which are missing rows
Hi Frank,
You're absolutely right. Changing those values in mapresample.c to 10
removed the artifacts when using a WMS request. They're still present when
the request is made via mapscript though. I need to manually code a
mapscript example though, because right now I'm testing that via
12 matches
Mail list logo
