Hi!
Frank Warmerdam wrote:
>
> Also, high contour density
> can occur if there are crazy no-data values in the raster (ie. -1e7 in a
> floating point raster) which can trigger a huge "pile" of contours around
> the bad data value.
>
I think you are right. After another subdivision, both halv
NopMap wrote:
Hi!
I have sudden problem with gdal_contour after using ist successfully many
times. There seems to be a problem with a certain area. When I tried it
first, gdal_contour quit with an out-of-memory message, exceeding 2GB of
virtual memory. When I reduced the area and called
gdal_m
Hi!
I have sudden problem with gdal_contour after using ist successfully many
times. There seems to be a problem with a certain area. When I tried it
first, gdal_contour quit with an out-of-memory message, exceeding 2GB of
virtual memory. When I reduced the area and called
gdal_merge.py -o M:\s
Gé Gé wrote:
Hi all and Franck,
I use OGR and GDAL in a software that has to manipulate and convert UTM
and WGS84 coordinates and maps.
OGR/GDAL is very powerful and I'm very happy with it.
Nevertheless I have a (maybe stupid) question concerning UTM zones
exceptions, for instance for Norway
Hi,
I originally posted to the GRASS list, but it was suggested that it
would be more appropriate here, given that GRASS uses GDAL for this
particular problem.
I'm in the process of importing sea ice concentration data from:
ftp://ftp-projects.zmaw.de/seaice/AMSR-E_ASI_IceConc
I have chosen to
Thanks for responding Hermann. Yes, I tried using -s_srs EPSG:3412 as
well as the full PROJ4 string with the same result. When specifying
-s_srs, does gdalwarp ignore (override) the project information in the
hdr file?
If I include the Hughes 1980 ellipsoid in the hdr file (projection info
li
Even,
You are right. The point is how to take full advantage of the GDAL Java API choosing the right
approach to deal with the raster buffer on the client side.
Best regards,
Ivan
Even Rouault wrote:
Selon Ivan :
Ivan,
I'm not sure what you are really measuring if you compare a C++ code v
Selon Hermann Peifer :
Hermann,
I've reproduced what you observe with trunk too and created ticket
http://trac.osgeo.org/gdal/ticket/3217 with 2 patches that solve the issue. One
must be applied in libgeotiff, the other one in the GTiff driver.
> Hi,
>
> testepsg EPSG:3785 gives [1], whereas
> g
Selon Simone Giannecchini :
Simone,
thanks for all this interesting information. I'm doing some experiment with Sun
JRE 1.6 and I observe that array pinning doesn't really work. I mean that the
jenv->GetByteArrayElements($input, &isCopy) call always return isCopy ==
JNI_TRUE, which seems to be co
Did you try: gdalwarp -s_srs EPSG:3412 ?
Hermann
John Callahan wrote:
Is it possible to define/set a coordinate system using GDAL? I
downloaded some data (from NSIDC) I know is in EPSG:3412.
(http://spatialreference.org/ref/epsg/3412/,
http://nsidc.org/data/atlas/epsg_3412.html)
The data
Selon Ivan :
Ivan,
I'm not sure what you are really measuring if you compare a C++ code versus its
translation to Java code. I think it just reflects the known slowdown of Java
when doing intensive computations in comparison to native code. The 0.2 second
difference between the regular array vers
>I'm also not sure if GDAL supports NetCDF4 directly. It looks like the
>NetCDF driver is for NetCDF3. If you're lucky, NetCDF4 files might be
>accessible in GDAL using the HDF5 driver...
I will try to write files directly with the netcdf4-python module instead of
through gdal. Building from scra
Hermann Peifer a écrit :
Hi,
testepsg EPSG:3785 gives [1], whereas
gdalwarp -t_srs EPSG:3785 input.tif output.tif results into [2]
Hi,
I don't know if it will solve your problem, but EPSG:3785 is now
obsolete, replaced by EPSG:3857
___
gdal-dev m
Jennings Jay wrote:
I expected outputsize-pixels to
be [inputsize-pixels * 0.50/0.2986] in both directions, but it is a good
bit bigger than that. Can anybody see why ?
Input size X, Y (pixels) : 45974, 39526
Output size X, Y (pixels) : 83468, 72894
This looks reasonable. EPSG:3785 uses
14 matches
Mail list logo