[gdal-dev] resampling a raster data set on the commandline
Hi all, I need to resample raster files on the command line. First I thought that resampling would be an option of gdal_translate, but it seems like it isn't implemented and there is a patch pending: http://trac.osgeo.org/gdal/ticket/1724 - but this patch is against an old version. gdal_warp allows to specify the resampling method and resolution change when reprojecting, but I don't want to reproject my data, I just want resampling. Is gdal_warp the tool to use for resampling by specifying the same input and output projection? Thanks, Andreas -- Andreas Neumann Böschacherstrasse 6, CH-8624 Grüt/Gossau, Switzerland Email: [EMAIL PROTECTED], Web: * http://www.carto.net/ (Carto and SVG resources) * http://www.carto.net/neumann/ (personal page) * http://www.svgopen.org/ (SVG Open Conference) * http://www.geofoto.ch/ (Georeferenced Photos of Switzerland) ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Question about ENVI Hdr format. Where to find file sample data? Which file extension?
Hi list, I'm extending the ImageIO-Ext's supported formats. Now I'm adding ENVI Hdr format support. 1) Where could I find some sample data available in that format? I have already taken a look at http://download.osgeo.org/gdal/data/... (In case data samples are unavailable I will use gdal_translate -OF ENVI from a sample GeoTIFF.) 2) Are the file extensions for that format .bil .bip .bsq? Thank you very much. Best Regards, Daniele -- --- Eng. Daniele Romagnoli Software Engineer GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 328 0559267 http://www.geo-solutions.it --- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Question about ENVI Hdr format. Where to find file sample data? Which file extension?
Daniele Romagnoli wrote: Hi list, I'm extending the ImageIO-Ext's supported formats. Now I'm adding ENVI Hdr format support. 1) Where could I find some sample data available in that format? I have already taken a look at http://download.osgeo.org/gdal/data/... (In case data samples are unavailable I will use gdal_translate -OF ENVI from a sample GeoTIFF.) Daniele, The tutorials here have example files http://www.ittvis.com/ProductServices/ENVI/Tutorials.aspx 2) Are the file extensions for that format .bil .bip .bsq? Traditionally they are .img, but I think it doesn't matter Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Memory fragmentation and memory consumption when warping with GCPs
Hi, I managed to solve my problem with the GCPs in MEM driver (and sorry if I bothered some with that thread), which turned up to be due to a bad initialization of the dataset geotransform. After that I wrote a MEX version of gdaltransform to be able to reproject points using GCPs. This MEX works but it revealed serious problems. At least under Matlab. Matlab requires not only LOTS of memory but also that the available memory is continuous. For example, if one needs a variable of 100 Mb the system needs to have a chunk of free memory not less than 100 Mb. Two chunks of 99 and 1 Mb are not enough as we'll have an out memory error. Now, I just realize that when I call a MEX that links against gdal.dll the memory immediately becomes highly fragmented. As an example of my current case, I had the largest chunk of free memory of 1070 Mb and after loading gdal.dll the largest chunk become 540 Mb Eventually due to this memory fragmentation, I could not reproject a file having a large number of GCPs ( 5000 GCPs). By decreasing the number of GCPs to half I was able to perform the operation. So one question is, why warping with GCPs takes such large amount of memory (apparently a chunk of 500 Mb was not enough to process 5000 GCPs)? I also tried with the command line GDAL gdaltransform and here I had no problems. So I'm a bit puzzled. Do all programs depend on the memory fragmentation issue, or is it just a Matlab limitation? (Ah, Windows XP here) As a side note, I also have MEXs that link with the OpenCV library, but those do not sensibly fragment the memory. Thanks Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] resampling a raster data set on the commandline
Andreas Neumann wrote: Hi all, I need to resample raster files on the command line. First I thought that resampling would be an option of gdal_translate, but it seems like it isn't implemented and there is a patch pending: http://trac.osgeo.org/gdal/ticket/1724 - but this patch is against an old version. gdal_warp allows to specify the resampling method and resolution change when reprojecting, but I don't want to reproject my data, I just want resampling. Is gdal_warp the tool to use for resampling by specifying the same input and output projection? Andreas, Yes, gdalwarp would be the appropriate tool to use. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GDALGridCreate() in python?
I like to use the gdal_grid/GDALGridCreate() command from python. Are the function wrapped for use in python now? See: http://trac.osgeo.org/gdal/ticket/2023. If not,are there a posible workaround? Hans ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Memory fragmentation and memory consumption when warping with GCPs
Frank Warmerdam wrote: Joaquim Luis wrote: So one question is, why warping with GCPs takes such large amount of memory (apparently a chunk of 500 Mb was not enough to process 5000 GCPs)? Joaquim, Is the memory fragmentation really related to the use of many GCPs? Does the same problem occur with 4 GCPs? Frank, Maybe I was not clear enough, but the memory segmentation has nothing to do with the GCP warping. It results from loading the gdal.dll For example, on a fresh start if I call (one other MEX for reading) gdalread without arguments, it prints the usage on screen. After this, which did not perform any calculus, the memory is already fragmented. The issue with the GCPs is that with a largest chunk of ~500 Mb I'm not able to warp with 5000 GCPs. Joaquim I also tried with the command line GDAL gdaltransform and here I had no problems. So I'm a bit puzzled. Do all programs depend on the memory fragmentation issue, or is it just a Matlab limitation? (Ah, Windows XP here) As a side note, I also have MEXs that link with the OpenCV library, but those do not sensibly fragment the memory. It is possible that OpenCV uses a private heap thereby minimising the amount of fragmentation in the master heap. It might also be that OpenEV just doesn't use that much memory. I suspect you are seeing some heap fragmentation and consumption due to GDAL's block caching mechanism but it is really hard to know. You can influence the amount of memory available for the block cache using GDALSetCacheMax(). I'm not in the habit of monitoring heap fragmentation on Win32. I will say that GDAL normally uses malloc() and free() for memory allocation so that may have some implications for heap effects. Best regards, ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Memory fragmentation and memory consumption when warping with GCPs
Joaquim Luis wrote: Frank, Maybe I was not clear enough, but the memory segmentation has nothing to do with the GCP warping. It results from loading the gdal.dll For example, on a fresh start if I call (one other MEX for reading) gdalread without arguments, it prints the usage on screen. After this, which did not perform any calculus, the memory is already fragmented. Joaquim, OK. Well, generally speaking GDAL should allocate relatively little memory just on loading the DLL (and perhaps calling GDALAllRegister()). So I don't know why you are seeing the problem you see. The issue with the GCPs is that with a largest chunk of ~500 Mb I'm not able to warp with 5000 GCPs. Does this aspect really have anything to do with the number of GCPs? Are you using the GDAL warp algorithm? There are things you can control about the amount of memory it tries to use that might be relavent. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Memory fragmentation and memory consumption when warping with GCPs
Joaquim, OK. Well, generally speaking GDAL should allocate relatively little memory just on loading the DLL (and perhaps calling GDALAllRegister()). So I don't know why you are seeing the problem you see. Frank, It's ok. I was not expecting an easy answer but I think this issue worth reporting. Anyway, the fragmentation (note that there is not a total free memory reduction) is probably originated by all the gdal.dll dependencies that one can see with the Dependency Walker being loaded by the gdal.dll Does this aspect really have anything to do with the number of GCPs? Are you using the GDAL warp algorithm? Oh yes, with 2500 GCPs I can do the warping. And yes I'm using the GDAL warp algorithm (the mex is more or less a copy of gdaltransform) Thanks Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdalwarp cutting off projected image
Hi, I'm fairly new with GDAL, and have been working with a coworker who is a little more familiar with GDAL and gdalwarp, but we are both stumped by this particular issue. I have a GeoTiff image that is in a north polar Lamber Azimuthal Equal Area (laea) projection. I am trying to reproject it using gdalwarp to a cylindrical projection (like EPSG:4326). I am using the following command: gdalwarp -t_srs EPSG:4326 input.gtiff.tif output.gtiff.tif The tool runs OK, but when I open output.gtiff.tif, the projection is incomplete. The parts that are there look correct, but it seems everything above about 50 degrees is cut off, like the input.gtiff.tif had a big circle around 50 degrees cut out before the reprojection was made. I've tried looking at the options for gdalwarp, but can't seem to find anything that would help. Is there a way to force gdalwarp to reproject the entire image? Thanks! Scott Lewis NSIDC ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Supporting ECW as a plugin. (Windows)
Hi again list, I'm back to work on setting ECW format as a GDAL external plugin on windows XP with visual studio 7.1 (nmake command line). I have some issues... My main steps are: - building GDAL without ECW - building ECW driver on frmts/ecw separately. - configuring an ENV variable GDAL_DRIVER_PATH linking to the location where the gdal_ECW_JP2ECW.DLL have been built. - running gdalinfo to test things. When running gdalinfo I get this error: ERROR 1: Can't find requested entry point: GDALRegister_ECW_JP2ECW Indeed, putting the generated DLL in the depends/dependency walker tool, I have only noticed the presence of the following two functions: - GDALRegister_ECW - GDALRegister_JP2ECW whilst the GDALDriverManager:autoLoadDrivers function does: 1) looks for a DLL in the specified GDAL_DRIVER_PATH --- gdal_ECW_JP2ECW.DLL 2) tries to call GDALRegister_ECW_JP2ECW function (missing). The weird thing is that ecwdataset.cpp contains that function but the generated DLL doesn't contain it. I have also noticed that the ECW plugin available here ( http://download.osgeo.org/gdal/win32/1.5/) doesn't contain that registration function. Does anyone already successfully used the ECW as a separated plugin on windows? Am I doing something wrong? Any tips/suggestion would be really appreciated. Best Regards, Daniele -- --- Eng. Daniele Romagnoli Software Engineer GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 328 0559267 http://www.geo-solutions.it --- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp cutting off projected image
Le Tuesday 09 December 2008 18:51:59 Scott Lewis, vous avez écrit : Frank, Thanks for the help. I tried doing this, and ended up with the same image (even diff found them to be the same). Here are the various commands I tried. Maybe I'm just using the -wo option wrong. gdalwarp -t_srs EPSG:4326 -wo SOURCE_EXTRA=1000 input.gtiff.tif output1.gtiff.tif gdalwarp -t_srs EPSG:4326 -wo SOURCE_EXTRA=1000 input.gtiff.tif output2.gtiff.tif gdalwarp -t_srs EPSG:4326 -wo SOURCE_EXTRA=1000 SAMPLE_GRID=YES SAMPLE_STEP=100 input.gtiff.tif output3.gtiff.tif This last one won't work as you expect. You should repeat -wo in front of each option : gdalwarp -t_srs EPSG:4326 -wo SOURCE_EXTRA=1000 -wo SAMPLE_GRID=YES -wo SAMPLE_STEP=100 input.gtiff.tif output3.gtiff.tif I'll continue to play with those options, though. gdalwarp seems to not act any different (IE, it takes the same amount of time to process) with or without the -wo option, so I'm thinking I'm just not using the option correctly somehow. Again, I appreciate your help! Scott Frank Warmerdam wrote: Scott Lewis wrote: Hi, I'm fairly new with GDAL, and have been working with a coworker who is a little more familiar with GDAL and gdalwarp, but we are both stumped by this particular issue. I have a GeoTiff image that is in a north polar Lamber Azimuthal Equal Area (laea) projection. I am trying to reproject it using gdalwarp to a cylindrical projection (like EPSG:4326). I am using the following command: gdalwarp -t_srs EPSG:4326 input.gtiff.tif output.gtiff.tif The tool runs OK, but when I open output.gtiff.tif, the projection is incomplete. The parts that are there look correct, but it seems everything above about 50 degrees is cut off, like the input.gtiff.tif had a big circle around 50 degrees cut out before the reprojection was made. I've tried looking at the options for gdalwarp, but can't seem to find anything that would help. Scott, There are various challenges in pole (or even dateline) spanning reprojection operations. The options at: http://www.gdal.org/structGDALWarpOptions.html#0ed77f9917bb96c7a9aabd73d4 d06e08 may be helpful. In particular, you might try specifying -wo SOURCE_EXTRA=1000 or some similar large value on the gdalwarp commandline. It is also possible that the SAMPLE_GRID=YES and SAMPLE_STEPS=100 options might help but generally if you have lots of RAM and a not-too-big input image specifying a large SOURCE_EXTRA value will resolve the issues. Best regards, ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDALGridCreate() in python?
Hans Ole Ørka kirjoitti: I like to use the gdal_grid/GDALGridCreate() command from python. Are the function wrapped for use in python now? See: http://trac.osgeo.org/gdal/ticket/2023. If not,are there a posible workaround? It's not been added to the swig interface and there's no workaround. I guess you need to use the command line program. Adding it to the swig interface needs some thought as the function does not create a GDAL object- in fact it interpolates onto an in-memory raster. Best regards, Ari Hans ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Prof. Ari Jolma Environmental Management Information Technology Teknillinen Korkeakoulu / Helsinki University of Technology tel: +358 9 4511 address: POBox 5300, 02015 TKK, Finland Email: ari.jolma at tkk.fi URL: http://geoinformatics.tkk.fi ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Supporting ECW as a plugin. (Windows)
Just a pointer : http://trac.osgeo.org/gdal/ticket/2320 The GDALRegister_ECW_JP2ECW function is only available in GDAL 1.5.3 or later, so when using the plugin in http://download.osgeo.org/gdal/win32/1.5/, it's normal that you don't find the GDALRegister_ECW_JP2ECW entry point. And, as a reminder, you shouldn't mix plugins between GDAL 1.5.X and GDAL 1.6.0. You should always recompile a plugin version that lies in the GDAL tree with which you want to use it. Le Tuesday 09 December 2008 19:16:34 William Kyngesburye, vous avez écrit : On Dec 9, 2008, at 11:37 AM, Daniele Romagnoli wrote: When running gdalinfo I get this error: ERROR 1: Can't find requested entry point: GDALRegister_ECW_JP2ECW Indeed, putting the generated DLL in the depends/dependency walker tool, I have only noticed the presence of the following two functions: - GDALRegister_ECW - GDALRegister_JP2ECW whilst the GDALDriverManager:autoLoadDrivers function does: 1) looks for a DLL in the specified GDAL_DRIVER_PATH --- gdal_ECW_JP2ECW.DLL 2) tries to call GDALRegister_ECW_JP2ECW function (missing). The weird thing is that ecwdataset.cpp contains that function but the generated DLL doesn't contain it. I have also noticed that the ECW plugin available here (http://download.osgeo.org/gdal/win32/1.5/ ) doesn't contain that registration function. Does anyone already successfully used the ECW as a separated plugin on windows? Am I doing something wrong? Any tips/suggestion would be really appreciated. Strange coincidence, or it points to some GDAL bug: I was messing around with ECW on OSX as a plugin this weekend. When I compiled the plugin for GDAL 1.6, it loaded. When I compiled the plugin for GDAL 1.5, I got the equivalent error: ERROR 1: dlsym(0x10160bd50, _GDALRegister_ECW_JP2ECW): symbol not found ERROR 1: dlsym(0x10160bd50, _GDALRegisterMe): symbol not found Simply renaming the plugin either gdal_ECW or gdal_JP2ECW works to load the driver for the named format. Having one as gdal_ECW, then symlinking that to gdal_JP2ECW works to load both. I don't know what the equivalent to symlink is on Windows, but duplicating the binary should also work. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Theory of the Universe There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened. -Hitchhiker's Guide to the Galaxy 2nd season intro ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Promote RC4 as official 1.6.0 Release
On Sat, Dec 06, 2008 at 08:12:15AM -0500, Frank Warmerdam wrote: Motion: That the GDAL 1.6.0 RC4 release candidate be promoted to being our official 1.6.0 release. +1 Best regards, Andrey -- Andrey V. Kiselev ICQ# 26871517 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDALGridCreate() in python?
On Tue, Dec 09, 2008 at 08:41:32PM +0200, Ari Jolma wrote: I like to use the gdal_grid/GDALGridCreate() command from python. Are the function wrapped for use in python now? See: http://trac.osgeo.org/gdal/ticket/2023. If not,are there a posible workaround? It's not been added to the swig interface and there's no workaround. I guess you need to use the command line program. Adding it to the swig interface needs some thought as the function does not create a GDAL object- in fact it interpolates onto an in-memory raster. I am thinking on idea to create the native NumPy bindings for GDAL (using the NumPy typemaps). That should greatly help to create practical bindings for Grid functions and some other. Also it is possible to create the higher level wrapper for gridding hiding the arrays inside. Best regards, Andrey -- Andrey V. Kiselev ICQ# 26871517 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp cutting off projected image
Scott Lewis wrote: Frank, Thanks for the help. I tried doing this, and ended up with the same image (even diff found them to be the same). Here are the various commands I tried. Maybe I'm just using the -wo option wrong. gdalwarp -t_srs EPSG:4326 -wo SOURCE_EXTRA=1000 input.gtiff.tif output1.gtiff.tif gdalwarp -t_srs EPSG:4326 -wo SOURCE_EXTRA=1000 input.gtiff.tif output2.gtiff.tif gdalwarp -t_srs EPSG:4326 -wo SOURCE_EXTRA=1000 SAMPLE_GRID=YES SAMPLE_STEP=100 input.gtiff.tif output3.gtiff.tif I'll continue to play with those options, though. gdalwarp seems to not act any different (IE, it takes the same amount of time to process) with or without the -wo option, so I'm thinking I'm just not using the option correctly somehow. Again, I appreciate your help! Scott, I suspect I've misconstrued what is going wrong. If you can stage the input file somewhere, and if it isn't too terribly huge, I would be interested in trying it myself. Ideally this could be filed as a Trac ticket. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Supporting ECW as a plugin. (Windows)
On Dec 9, 2008, at 12:52 PM, Even Rouault wrote: Just a pointer : http://trac.osgeo.org/gdal/ticket/2320 The GDALRegister_ECW_JP2ECW function is only available in GDAL 1.5.3 or later, so when using the plugin in http://download.osgeo.org/gdal/ win32/1.5/, it's normal that you don't find the GDALRegister_ECW_JP2ECW entry point. And, as a reminder, you shouldn't mix plugins between GDAL 1.5.X and GDAL 1.6.0. You should always recompile a plugin version that lies in the GDAL tree with which you want to use it. I figured that a driver's prototypes would be in the driver's source, but there I see it in gdal_frmts.h. So yeah, GDALRegister_ECW_JP2ECW() really is not going to work in GDAL 1.5.2. (checking the library symbols, GDALRegister_ECW_JP2ECW() ends up as a C ++ symbol, instead of a C symbol) I need to update ;) - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ The equator is so long, it could encircle the earth completely once. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Promote RC4 as official 1.6.0 Release
+1 Tamas 2008/12/6 Frank Warmerdam [EMAIL PROTECTED] Motion: That the GDAL 1.6.0 RC4 release candidate be promoted to being our official 1.6.0 release. -- Voting will close Tuesday evening. -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdamhttp://pobox.com/%7Ewarmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] How to CreateCopy a dataset from an empty virtual dataset (no source dataset is linked)?
I am trying to write a program which is able to create a raster dataset of
any supported format. To do so, I first created a virtual dataset in memory
using the Create() function, then set the projection and add the bands to
the virtual dataset (no links to source datasets), and then used the
CreateCopy() function to create a non-virtual dataset from the virtual
dataset I just created. However, the CreateCopy() always returned a NULL
pointer. I also tried creating a temporary vrt file using the Create()
function before using CreateCopy(). Still, the CreateCopy() returned a NULL
pointer.
Has anyone done this before or have any idea how to do this? Do I have to
link a source dataset to the virtual dataset before using CreateCopy() to
create a non-virtual dataset from the virtual dataset? I just want to create
an empty dataset in which all the pixels are set to some initial value (for
example, zero).
I am using GDAL 1.5.3. The following is the code I wrote:
...
GDALDriver *poDriver = (GDALDriver *) GDALGetDriverByName( VRT );
GDALDataset *poVRTDS;
poVRTDS = poVRTDriver-Create(, xSize, ySize,
3, GDT_Byte,
NULL);
if(poVRTDS == NULL) {
cerr Error: unable to create virtual GDAL dataset \
endl;
return false;
}
if(poVRTDS-SetProjection(pProjRef) == CE_Failure ||
poVRTDS-SetGeoTransform(adfGeoTransform) == CE_Failure) {
cerr Error: unable to set projection for the virtual dataset \
endl;
return false;
}
GDALDriver *poDriver = (GDALDriver *) GDALGetDriverByName( Gtiff );
GDALDataset *poDesDS;
poDesDS= poDriver-CreateCopy(myGTIFF.tif,
poVRTDS,
FALSE, NULL,
NULL, NULL);
if(poDesDS== NULL) {
cerr Error: unable to create GDAL dataset endl;
GDALClose(poVRTDS);
return false;
}
GDALClose(poVRTDS);
...
--
--== Qingfeng (Gene) Guan ==--
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Supporting ECW as a plugin. (Windows)
On Tue, Dec 9, 2008 at 7:52 PM, Even Rouault [EMAIL PROTECTED]wrote: Just a pointer : http://trac.osgeo.org/gdal/ticket/2320 The GDALRegister_ECW_JP2ECW function is only available in GDAL 1.5.3 or later, so when using the plugin in http://download.osgeo.org/gdal/win32/1.5/, it's normal that you don't find the GDALRegister_ECW_JP2ECW entry point. Ok. Thank you for the info. I didn't know that. I have simply quickly checked that set of DLL to see if that entry was present somewhere. And, as a reminder, you shouldn't mix plugins between GDAL 1.5.X and GDAL 1.6.0. You should always recompile a plugin version that lies in the GDAL tree with which you want to use it. Sure. I have made my experiments only with version 1.5.3. Regards, Daniele Le Tuesday 09 December 2008 19:16:34 William Kyngesburye, vous avez écrit : On Dec 9, 2008, at 11:37 AM, Daniele Romagnoli wrote: When running gdalinfo I get this error: ERROR 1: Can't find requested entry point: GDALRegister_ECW_JP2ECW Indeed, putting the generated DLL in the depends/dependency walker tool, I have only noticed the presence of the following two functions: - GDALRegister_ECW - GDALRegister_JP2ECW whilst the GDALDriverManager:autoLoadDrivers function does: 1) looks for a DLL in the specified GDAL_DRIVER_PATH --- gdal_ECW_JP2ECW.DLL 2) tries to call GDALRegister_ECW_JP2ECW function (missing). The weird thing is that ecwdataset.cpp contains that function but the generated DLL doesn't contain it. I have also noticed that the ECW plugin available here (http://download.osgeo.org/gdal/win32/1.5/ ) doesn't contain that registration function. Does anyone already successfully used the ECW as a separated plugin on windows? Am I doing something wrong? Any tips/suggestion would be really appreciated. Strange coincidence, or it points to some GDAL bug: I was messing around with ECW on OSX as a plugin this weekend. When I compiled the plugin for GDAL 1.6, it loaded. When I compiled the plugin for GDAL 1.5, I got the equivalent error: ERROR 1: dlsym(0x10160bd50, _GDALRegister_ECW_JP2ECW): symbol not found ERROR 1: dlsym(0x10160bd50, _GDALRegisterMe): symbol not found Simply renaming the plugin either gdal_ECW or gdal_JP2ECW works to load the driver for the named format. Having one as gdal_ECW, then symlinking that to gdal_JP2ECW works to load both. I don't know what the equivalent to symlink is on Windows, but duplicating the binary should also work. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Theory of the Universe There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened. -Hitchhiker's Guide to the Galaxy 2nd season intro ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- --- Eng. Daniele Romagnoli Software Engineer GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 328 0559267 http://www.geo-solutions.it --- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Supporting ECW as a plugin. (Windows)
On Tue, Dec 9, 2008 at 7:16 PM, William Kyngesburye [EMAIL PROTECTED]wrote: On Dec 9, 2008, at 11:37 AM, Daniele Romagnoli wrote: When running gdalinfo I get this error: ERROR 1: Can't find requested entry point: GDALRegister_ECW_JP2ECW Indeed, putting the generated DLL in the depends/dependency walker tool, I have only noticed the presence of the following two functions: - GDALRegister_ECW - GDALRegister_JP2ECW whilst the GDALDriverManager:autoLoadDrivers function does: 1) looks for a DLL in the specified GDAL_DRIVER_PATH --- gdal_ECW_JP2ECW.DLL 2) tries to call GDALRegister_ECW_JP2ECW function (missing). The weird thing is that ecwdataset.cpp contains that function but the generated DLL doesn't contain it. I have also noticed that the ECW plugin available here ( http://download.osgeo.org/gdal/win32/1.5/) doesn't contain that registration function. Does anyone already successfully used the ECW as a separated plugin on windows? Am I doing something wrong? Any tips/suggestion would be really appreciated. Strange coincidence, or it points to some GDAL bug: I was messing around with ECW on OSX as a plugin this weekend. When I compiled the plugin for GDAL 1.6, it loaded. When I compiled the plugin for GDAL 1.5, I got the equivalent error: ERROR 1: dlsym(0x10160bd50, _GDALRegister_ECW_JP2ECW): symbol not found ERROR 1: dlsym(0x10160bd50, _GDALRegisterMe): symbol not found Simply renaming the plugin either gdal_ECW or gdal_JP2ECW works to load the driver for the named format. This also worked for me before sending the email. I would just like to know if someone have noticed this before. Having one as gdal_ECW, then symlinking that to gdal_JP2ECW works to load both. I don't know what the equivalent to symlink is on Windows, but duplicating the binary should also work. Regards, Daniele - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Theory of the Universe There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened. -Hitchhiker's Guide to the Galaxy 2nd season intro -- --- Eng. Daniele Romagnoli Software Engineer GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 328 0559267 http://www.geo-solutions.it --- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to CreateCopy a dataset from an empty virtual dataset (no source dataset is linked)?
Qingfeng (Gene) Guan wrote:
I am trying to write a program which is able to create a raster dataset
of any supported format. To do so, I first created a virtual dataset in
memory using the Create() function, then set the projection and add the
bands to the virtual dataset (no links to source datasets), and then
used the CreateCopy() function to create a non-virtual dataset from the
virtual dataset I just created. However, the CreateCopy() always
returned a NULL pointer. I also tried creating a temporary vrt file
using the Create() function before using CreateCopy(). Still, the
CreateCopy() returned a NULL pointer.
Has anyone done this before or have any idea how to do this? Do I have
to link a source dataset to the virtual dataset before using
CreateCopy() to create a non-virtual dataset from the virtual dataset? I
just want to create an empty dataset in which all the pixels are set to
some initial value (for example, zero).
I am using GDAL 1.5.3. http://1.5.3./ The following is the code I wrote:
...
GDALDriver *poDriver = (GDALDriver *) GDALGetDriverByName( VRT );
GDALDataset *poVRTDS;
poVRTDS = poVRTDriver-Create(, xSize, ySize,
3, GDT_Byte,
NULL);
Gene,
It turns out that VRTSourcedRasterBand::IRasterIO() returns CE_Failure if
there are no sources for the band. I believe this is an inappropriate
behavior, and unnecessarily interferes in situations like yours.
I would appreciate your filing a trac ticket on the issue, and I'll look
into applying a fix. Tentatively I'm considering this change
in gdal/frmts/vrt/vrtsourcedrasterband.cpp:
Index: vrtsourcedrasterband.cpp
===
--- vrtsourcedrasterband.cpp(revision 15924)
+++ vrtsourcedrasterband.cpp(working copy)
@@ -122,7 +122,7 @@
{
int iSource;
-CPLErr eErr = CE_Failure;
+CPLErr eErr = CE_None;
if( eRWFlag == GF_Write )
{
@@ -171,7 +171,7 @@
/* */
/* Overlay each source in turn over top this. */
/* */
-for( iSource = 0; iSource nSources; iSource++ )
+for( iSource = 0; eErr == CE_None iSource nSources; iSource++ )
{
eErr =
papoSources[iSource]-RasterIO( nXOff, nYOff, nXSize, nYSize,
You might want to try it yourself.
Best regards,
--
---+--
I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp cutting off projected image
Frank, The image I've been trying to convert is at this URL. It's about 6MB, hopefully that's not too big. ftp://sidads.colorado.edu/pub/incoming/glewis/polar.gtiff.tif Basically, I'm trying to convert it to a plain-old EPGS:4326 (latlong projection). I appreciate you taking a look. Scott PS - I'm still new to the GDAL list; when you say file a Trac ticket, where would I do this? Scott Lewis wrote: I've been having problems getting it staged. As soon as I'm able to I'll send the URL. Maybe the source geotiff file doesn't have the information necessary to convert correctly, perhaps. Again, thanks for your help. Hopefully I'll have the URL soon. Scott Frank Warmerdam wrote: Scott Lewis wrote: Frank, Thanks for the help. I tried doing this, and ended up with the same image (even diff found them to be the same). Here are the various commands I tried. Maybe I'm just using the -wo option wrong. gdalwarp -t_srs EPSG:4326 -wo SOURCE_EXTRA=1000 input.gtiff.tif output1.gtiff.tif gdalwarp -t_srs EPSG:4326 -wo SOURCE_EXTRA=1000 input.gtiff.tif output2.gtiff.tif gdalwarp -t_srs EPSG:4326 -wo SOURCE_EXTRA=1000 SAMPLE_GRID=YES SAMPLE_STEP=100 input.gtiff.tif output3.gtiff.tif I'll continue to play with those options, though. gdalwarp seems to not act any different (IE, it takes the same amount of time to process) with or without the -wo option, so I'm thinking I'm just not using the option correctly somehow. Again, I appreciate your help! Scott, I suspect I've misconstrued what is going wrong. If you can stage the input file somewhere, and if it isn't too terribly huge, I would be interested in trying it myself. Ideally this could be filed as a Trac ticket. Best regards, ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Working between GeoTIFF's and Arc/Info ASCII Grid formats with NAN values
Hi All, Just had an email from a client complaining about the nan values that I included in some Arc/Info ASCII Grid files that I sent them. The files were created by converting GeoTIFF's into ASCII Grid format via gdal_translate. I personally like that the nan's were carried through, but I would like to know if there is a way that I can map the nan into a - value via the gdal utilities? Thanks, Roger -- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Working between GeoTIFF's and Arc/Info ASCII Grid formats with NAN values
ROTFL You could also potentially do it with by ascii search and replace in the resulting grid file You are SO right! I had totally forgotten that this was ASCII output. Doh! Thanks Frank. -- On Tue, Dec 9, 2008 at 5:24 PM, Frank Warmerdam [EMAIL PROTECTED] wrote: Roger André wrote: Hi All, Just had an email from a client complaining about the nan values that I included in some Arc/Info ASCII Grid files that I sent them. The files were created by converting GeoTIFF's into ASCII Grid format via gdal_translate. I personally like that the nan's were carried through, but I would like to know if there is a way that I can map the nan into a - value via the gdal utilities? Roger, I'm not aware of a way to convert NaN values to an actual value with the GDAL command line utilities. You could accomplish this with a program, or a python script. You could also potentially do it with by ascii search and replace in the resulting grid file. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdamhttp://pobox.com/%7Ewarmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Memory fragmentation and memory consumption when warping with GCPs
Does this aspect really have anything to do with the number of GCPs? Are you using the GDAL warp algorithm? Oh yes, with 2500 GCPs I can do the warping. And yes I'm using the GDAL warp algorithm (the mex is more or less a copy of gdaltransform) Sorry for being so dumb. The GCP warping memory problem was due to a stupid error of over allocation - nGCPCount*nGCPCount instead of the needed nGCPCount It works fine now. But the memory fragmentation issue is another story, and that still remains. Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp cutting off projected image
Scott Lewis wrote: Frank, The image I've been trying to convert is at this URL. It's about 6MB, hopefully that's not too big. ftp://sidads.colorado.edu/pub/incoming/glewis/polar.gtiff.tif Basically, I'm trying to convert it to a plain-old EPGS:4326 (latlong projection). I appreciate you taking a look. Scott, I have established the problem is the logic that computes the desired extent of the output file. It walks the edges of the input file, transforming to WGS84 and ends up with incomplete extents because there is no recognition that there is a topological discontinuity in the transformation (the pole issue). Normally my advice would be to use the SAMPLE_GRID=YES warp option to force internal sampling of the region when computing the bounds, but I have discovered that only applies to deciding what source region to read during warping - not to the computation of the original warp region. So, in the meantime you can just force selection of output extents. Something like: gdalwarp -t_srs EPSG:4326 polar.gtiff.tif out.tif -te -180 28 180 90 When I have the ticket in hand, I'll plan to modify the GDALSuggestedWarpOutput() function to allow forcing of internal gridding. It would also be nice if I could automatically recognise this sort of case to trigger it automatically, but I'm not sure how to do that without quite a bit of extra work. PS - I'm still new to the GDAL list; when you say file a Trac ticket, where would I do this? Visit: http://trac.osgeo.org/gdal There should be brief instructions on getting an OSGeo Userid which you can use to login to the site, and then hit New Ticket to file a bug report. If you find this path isn't deducable from the main GDAL web page, please email me suggestions on how to improve things. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
