Re: [Gdal-dev] gdal_contour crashing

2009-11-11 Thread NopMap
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

Re: [Gdal-dev] gdal_contour crashing

2009-11-11 Thread Frank Warmerdam
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

[Gdal-dev] gdal_contour crashing

2009-11-11 Thread NopMap
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

[gdal-dev] Re: UTM zones exceptions

2009-11-11 Thread Frank Warmerdam
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

[gdal-dev] importing HDF sea ice grid with unusual projection

2009-11-11 Thread Seb
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

Re: [gdal-dev] Re: gdal to define projection, EPSG:3412

2009-11-11 Thread John Callahan
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

Re: [gdal-dev] Re: JAVA API - Performance

2009-11-11 Thread Ivan
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

Re: [gdal-dev] SPHEROID["unretrievable - using WGS84"...

2009-11-11 Thread Even Rouault
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

Re: [gdal-dev] Re: JAVA API - Performance

2009-11-11 Thread Even Rouault
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

[gdal-dev] Re: gdal to define projection, EPSG:3412

2009-11-11 Thread Hermann Peifer
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

Re: [gdal-dev] Re: JAVA API - Performance

2009-11-11 Thread Even Rouault
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

Re: [Gdal-dev] python bindings, no netcdf support

2009-11-11 Thread HesselWinsemius
>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

Re: [gdal-dev] SPHEROID["unretrievable - using WGS84"...

2009-11-11 Thread Jean-Claude REPETTO
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

[gdal-dev] Re: gdalwarp: output too big?

2009-11-11 Thread Hermann Peifer
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