[gdal-dev] Re: VRT Derived Bands from Python?
Hi Even and Antonio,
Thank you Even for explaining how to make the impossible possible!
I will explore this option.
The suggestion of Antonio to include a default set of PixelFunctions is
an excellent idea, as it lowers the threshold for newcomers, like me.
The proposed standard functions (#3367) should also serve many basic
needs, and in fact, most of mine.
On the other hand, I do not see any apparent limitation to how
sophisticated the PixelFunctions can be. I am not sure if it is a good
idea, but I consider the option to put in relatively complex algorithms
with loops, iterations and inversions. I.e. things that are better done
in C than in Python.
Best regards from Knut-Frode
On 11/05/2011 21:05, Antonio Valentino wrote:
Hi Even, hi Knut-Frode,
Il 11/05/2011 20:08, Even Rouault ha scritto:
Le mercredi 11 mai 2011 11:53:55, Knut-Frode Dagestad a écrit :
Hi,
Derived Bands of the VRT format seems like a very powerful resource.
From the tutorial (http://www.gdal.org/gdal_vrttut.html) it is clear
that the Pixel Functions themselves have to be written in C, which is
probably anyway best for performance.
I also get the impression that the corresponding VRT files with Derived
Bands can only be used by applications written in C/C++, since the Pixel
Functions are only available inside the scope of such an application
program:
http://gis.stackexchange.com/questions/2940/gdal-pixel-functions-question
Does this mean that Pixel Functions can not be used by command line
utilities (e.g. gdalwarp and gdal_translate) or from Python?
The quick answer is : you can't use VRTDerivedBand from command line
utilities or Python.
The long answer is : but of course, as often in situations where you can't,
you can... Provided you have a C compiler handy, the workaround here is to
benefit from the GDAL plugin mechanism for other purposes than writing a GDAL
driver.
Create a gdalmypixelfunction.c whose content is :
#include gdal.h
CPLErr MyFunction(void **papoSources, int nSources, void *pData,
int nXSize, int nYSize,
GDALDataType eSrcType, GDALDataType eBufType,
int nPixelSpace, int nLineSpace)
{
/* implementation to write here */
}
void GDALRegisterMe() /* this is the entry point. don't change this name */
{
GDALAddDerivedBandPixelFunc(MyFunction, MyFunction);
}
Compile it as a shared library, called gdal_.so (or .dll on
windows), define GDAL_DRIVER_PATH to point to the directory of the shared
library, et voilà ! The library will be loaded at runtime when the utilities
or the python bindings call the GDALRegisterAll() method and the pixel
function will be available to the VRT driver.
This is exactly the solution I'm currently using and I con confirm that
it works perfectly both on linux and windows.
I wrote a little plugin to register pixel functions attached to #3367
[1] (together with other more specific for my application domain) and
now both command line tools and python scripts can use pixel functions.
The only limitation is that there is no way, as far as I know, to write
a VRT file with a VRTDerivedRasterBand using the GDAL Python API.
While I can set the Band subClass at band creation time as follows:
ds.AddBand(gdal.GDT_Float32, ['subClass=VRTDerivedRasterBand'])
I was not able to find a way to set the PixelFunctionType and the
SourceTransferType parameters using the GDAL Python API.
As a workaround I write the VRT to disk and then I perform direct XML
manipulations via xml.etree (from the python standard lib).
Do I miss something?
It would be very nice to be able to set PixelFunctionType and
SourceTransferType asadditional creation options.
[1] http://trac.osgeo.org/gdal/ticket/3367
Best regards
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GDAL 1.8.0 and MrSid no-data values
Hi, I just updated to 1.8.0 from 1.7, using the MrSid DSDK 8.0. In order to handle transparency, i have until now used the metadata values from IMAGE__NO_DATA_VALUE, and simply masked away pixels. After upgrading, the IMAGE__NO_DATA_VALUE yields nothing, neither is it listed when using gdalinfo. The band-GetNoDataValue() doesn't give me any hints either. Should I handle this in a different way ? -- Oyvind ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: VRT Derived Bands from Python?
Hi Knut-Frode, Il giorno Fri, 13 May 2011 10:37:25 +0200 Knut-Frode Dagestad knutfrodesop...@hotmail.com ha scritto: Hi Even and Antonio, Thank you Even for explaining how to make the impossible possible! I will explore this option. If you think it is useful I can attach the fake-driver code to the #3367. The suggestion of Antonio to include a default set of PixelFunctions is an excellent idea, as it lowers the threshold for newcomers, like me. The proposed standard functions (#3367) should also serve many basic needs, and in fact, most of mine. A relevant thread about this topic is http://lists.osgeo.org/pipermail/gdal-dev/2010-January/023262.html http://lists.osgeo.org/pipermail/gdal-dev/2010-February/023336.html but probably you have already read it. It would be interesting to know which function you would like to be added to the base set. In the above mentioned thread a user asked for a abs(a-b) pixel-function. Maybe there are other function it worths adding the basic set. On the other hand, I do not see any apparent limitation to how sophisticated the PixelFunctions can be. I am not sure if it is a good idea, but I consider the option to put in relatively complex algorithms with loops, iterations and inversions. I.e. things that are better done in C than in Python. IMHO the main limitation is the impossibility to pass additional parameters for pixel functions, see http://lists.osgeo.org/pipermail/gdal-dev/2009-July/021137.html Finally I think it would be very nice to have a function like http://www.pytables.org/docs/manual/ch04.html#ExprClassDescr in the GDAL python API and/or connected to the VRT format. Basically PyTables provides a general purpose expression evaluator that is disk aware and very efficient (using optimized and threaded numexpr kernels). Best regards -- Antonio Valentino ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDALPolygonize using float buffers
On 11-05-13 06:51 AM, Jorge Arévalo wrote: Hello, Is there any reason to limit the GDALPolygonize function to read data in int32 buffers, instead of using 32b float or even 64b double ones? As I stated in ticket #4005 (http://trac.osgeo.org/gdal/ticket/4005), I want to code an alternative version using these kind of buffers. But I don't know if I'm missing something. Jorge, There are no *compelling* reasons to limit polygonization to integer data, but once you get into floating point data lots of questions do arise about value comparisons will be done - will it be a within epsilon sort of test or are you looking for exact floating point matches? If a floating point option is available, I think there will still need to be a version of the algorithm operating on integer buffers to avoid problems representing some integer values in floating point and potentially more expensive comparisons. That said, I'm ok with extending the function to support floating point bands. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com 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] GDAL 1.8.0 and MrSid no-data values
Is this with MG3 or MG4 files? MG4 uses an alpha channel instead of nodata, so what you describe would be expected in that case. From: gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Oyvind Idland Sent: vendredi 13 mai 2011 04:28 To: gdal-dev@lists.osgeo.org Subject: [gdal-dev] GDAL 1.8.0 and MrSid no-data values Hi, I just updated to 1.8.0 from 1.7, using the MrSid DSDK 8.0. In order to handle transparency, i have until now used the metadata values from IMAGE__NO_DATA_VALUE, and simply masked away pixels. After upgrading, the IMAGE__NO_DATA_VALUE yields nothing, neither is it listed when using gdalinfo. The band-GetNoDataValue() doesn't give me any hints either. Should I handle this in a different way ? -- Oyvind ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Using gdal to generate thumbnails
Greetings I have a couple of Gtif Images and I want to create thumbnails. Is it possible to do that with GDAL? Thanks Antonio __ Information from ESET NOD32 Antivirus, version of virus signature database 6119 (20110513) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Using gdal to generate thumbnails
António, You can use the gdal_translate utility with the -outsize option. But you may require the original dimensions to maintain the aspect ratio. You can grab the dimensions from the output from the gdalinfo utility. http://www.gdal.org/gdalinfo.html http://www.gdal.org/gdal_translate.html 2011/5/13 António Rocha antonio.ro...@deimos.com.pt Greetings I have a couple of Gtif Images and I want to create thumbnails. Is it possible to do that with GDAL? Thanks Antonio __ Information from ESET NOD32 Antivirus, version of virus signature database 6119 (20110513) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Adopt RFC 35: Delete, reorder and alter field definitions of OGR layers
Le mercredi 11 mai 2011 10:10:52, Even Rouault a écrit : Hi, Motion: I move to adopt RFC 35: Delete, reorder and alter field definitions of OGR layers. http://trac.osgeo.org/gdal/wiki/rfc35_deletereorderalterfielddefn Hi, I declare this motion passed with support (+1) from FrankW, TamasS, EvenR, DanielM and HowardB. I will proceed to commit the work into trunk. I'll need Frank's help to upstream the shapelib's bits that I have isolated in http://trac.osgeo.org/gdal/attachment/ticket/2671/shapelib_rfc35.patch . It contains the implementation of DBFReorderFields() and DBFAlterFieldDefn(), 2 fixes in DBFDeleteField() and a bit of minor factorisation to get the null character depending on the field type, so that it can be reused by DBFAlterFieldDefn(). Thanks. Best regards, Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: VRT Derived Bands from Python?
On 13/05/2011 12:07, Antonio Valentino wrote: If you think it is useful I can attach the fake-driver code to the #3367. Thank you, that would be useful. In the meantime I have tested this approach, nearly successful: I copied one of your pixel-functions from #3367 and made a dynamic library file with: gcc -fPIC -c gdal_nerscpixelfun.c gcc -shared -lgdal -o gdal_nerscpixelfun.so gdal_nerscpixelfun.o and then set GDAL_DRIVER_PATH to point to this folder. However, at GDAL startup I get the following error: ERROR 1: dlsym(0x100e095f0, _GDALRegister_nerscpixelfun): symbol not found Any ideas what is wrong? OS is Mac OS X 10.6.7. I am not a C expert. Best regards from Knut-Frode ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: VRT Derived Bands from Python?
Le vendredi 13 mai 2011 18:59:14, Knut-Frode Dagestad a écrit : On 13/05/2011 12:07, Antonio Valentino wrote: If you think it is useful I can attach the fake-driver code to the #3367. Thank you, that would be useful. In the meantime I have tested this approach, nearly successful: I copied one of your pixel-functions from #3367 and made a dynamic library file with: gcc -fPIC -c gdal_nerscpixelfun.c gcc -shared -lgdal -o gdal_nerscpixelfun.so gdal_nerscpixelfun.o and then set GDAL_DRIVER_PATH to point to this folder. However, at GDAL startup I get the following error: ERROR 1: dlsym(0x100e095f0, _GDALRegister_nerscpixelfun): symbol not found I had also a similar error on Linux, but it worked despite the error. I have pushed a fix in trunk to silent that error. You can try to add a printf() statement in your GDALRegisterMe function to check if it is loaded correctly. Explanation : GDAL tries to load first a symbol called GDALRegister_x when the .so is called gdal_xx.so/dll, and if not present it then tries GDALRegisterMe. There's no point emitting an error if GDALRegister_x is not found, but GDALRegisterMe is found. See http://trac.osgeo.org/gdal/changeset/22359 I'm not a MacOSX user, but I believe that on the Mac, shared libraries have to be suffixed by .dylib instead of .so. That might explain your error if it doesn't work. Any ideas what is wrong? OS is Mac OS X 10.6.7. I am not a C expert. Best regards from Knut-Frode ___ 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] Translating ArcInfo binary grid to USGS .dem in C# via GDAL
For transparency's sake, I posted this to gis.stackexchange
(http://gis.stackexchange.com/questions/9609/translating-grid-to-usgs-dem-in-c-via-gdal),
but haven't heard anything that really helps, so I thought this might be a
better place to seek help.
I am attempting to translate ArcInfo binary grids to USGS DEM format (.dem)
for input into VUE Infinite, a 3D visualization program. I am *very* new to
GDAL, and I have installed the GDAL .NET bindings thru a
(http://vbkto.dyndns.org/sdk/PackageList.aspx?file=release-1500-gdal-1-8-0-mapserver-5-6-6.zip)
build installer. I can get to GDAL in my C# solution I am working on.
However, it seems that I cannot create a USGS DEM:
Gdal.AllRegister();
GDAL.Dataset originalImage = Gdal.Open(C:\\65587895\\hdr.adf,
GDAL.Access.GA_ReadOnly);
Driver demDriver = Gdal.GetDriverByName(USGSDEM);
int x = originalImage.RasterXSize;
int y = originalImage.RasterYSize;
String[] opts = new String[] { PRODUCT=DEFAULT,ZRESOLUTION=float };
Dataset dsDem = demDriver.Create(C:\\Data\\65587895\\foo.dem, x, y, 1,
DataType.GDT_Int16, opts);
Gives the error:
System.ApplicationException: GDALDriver::Create() ... no create method
implemented for this format.
I thought the USGSDEM format was read/write...am I wrong on that? The
formats list (http://www.gdal.org/formats_list.html) says that creation of
USGSDEM is supported, but a run of demDriver.GetMetadata(null) to get the
metadata from the USGSDEM driver results in no return DCAP_CREATE=YES, only
DCAP_CREATECOPY=YES, which makes me cringe, thinking that indeed the
GDALDriver::Create() method is not implemented for the USGSDEM format.
I've also poked thought the source for the USGSDEM format, and don't see
anything in there pertaining to creating a dem (although I could easily miss
that, as I am by no means fluent in C++).
Any thoughts or experience with this? Any other thoughts on translating
ArcInfo binary grids (or anything for that matter) to DEMs?
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/Translating-ArcInfo-binary-grid-to-USGS-dem-in-C-via-GDAL-tp6360189p6360189.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Translating ArcInfo binary grid to USGS .dem in C# via GDAL
On 11-05-13 01:13 PM, supercooper wrote: Dataset dsDem = demDriver.Create(C:\\Data\\65587895\\foo.dem, x, y, 1, DataType.GDT_Int16, opts); Gives the error: System.ApplicationException: GDALDriver::Create() ... no create method implemented for this format. I thought the USGSDEM format was read/write...am I wrong on that? The formats list (http://www.gdal.org/formats_list.html) says that creation of USGSDEM is supported, but a run of demDriver.GetMetadata(null) to get the metadata from the USGSDEM driver results in no return DCAP_CREATE=YES, only DCAP_CREATECOPY=YES, which makes me cringe, thinking that indeed the GDALDriver::Create() method is not implemented for the USGSDEM format. Super Cooper, Indeed, the USGSDEM driver only implements CreateCopy(), not Create(). ASCII formats like this one are not very easy to implement Create support with as they aren't well suited to random update. I've also poked thought the source for the USGSDEM format, and don't see anything in there pertaining to creating a dem (although I could easily miss that, as I am by no means fluent in C++). The CreateCopy implementation is in usgsdem_create.c in the same directory as the read driver. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com 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] Translating ArcInfo binary grid to USGS .dem in C# via GDAL
Le vendredi 13 mai 2011 19:13:32, supercooper a écrit :
For transparency's sake, I posted this to gis.stackexchange
(http://gis.stackexchange.com/questions/9609/translating-grid-to-usgs-dem-i
n-c-via-gdal), but haven't heard anything that really helps, so I thought
this might be a better place to seek help.
I am attempting to translate ArcInfo binary grids to USGS DEM format (.dem)
for input into VUE Infinite, a 3D visualization program. I am *very* new to
GDAL, and I have installed the GDAL .NET bindings thru a
(http://vbkto.dyndns.org/sdk/PackageList.aspx?file=release-1500-gdal-1-8-0-
mapserver-5-6-6.zip) build installer. I can get to GDAL in my C# solution I
am working on. However, it seems that I cannot create a USGS DEM:
Gdal.AllRegister();
GDAL.Dataset originalImage = Gdal.Open(C:\\65587895\\hdr.adf,
GDAL.Access.GA_ReadOnly);
Driver demDriver = Gdal.GetDriverByName(USGSDEM);
int x = originalImage.RasterXSize;
int y = originalImage.RasterYSize;
String[] opts = new String[] { PRODUCT=DEFAULT,ZRESOLUTION=float };
Dataset dsDem = demDriver.Create(C:\\Data\\65587895\\foo.dem, x, y, 1,
DataType.GDT_Int16, opts);
Gives the error:
System.ApplicationException: GDALDriver::Create() ... no create method
implemented for this format.
Indeed, only a small percent of drivers with write capabilities support the
full Create() method which is indicated by the DCAP_CREATE=YES metadata. The
majority of drivers with write capabilities, such as USGSDEM, support only
CreateCopy() (DCAP_CREATECOPY=YES). But from what you describe above
(translating a dataset to another format), it is just what you need.
So try instead :
Dataset dsDem = demDriver.CreateCopy(C:\\Data\\65587895\\foo.dem,
originalImage, 0, opts);
I thought the USGSDEM format was read/write...am I wrong on that? The
formats list (http://www.gdal.org/formats_list.html) says that creation of
USGSDEM is supported, but a run of demDriver.GetMetadata(null) to get the
metadata from the USGSDEM driver results in no return DCAP_CREATE=YES, only
DCAP_CREATECOPY=YES, which makes me cringe, thinking that indeed the
GDALDriver::Create() method is not implemented for the USGSDEM format.
I've also poked thought the source for the USGSDEM format, and don't see
anything in there pertaining to creating a dem (although I could easily
miss that, as I am by no means fluent in C++).
see USGSDEMCreateCopy() in frmts/usgsdem/usgsdem_create.cpp
Any thoughts or experience with this? Any other thoughts on translating
ArcInfo binary grids (or anything for that matter) to DEMs?
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/Translating-ArcInfo-binary-grid-to-
USGS-dem-in-C-via-GDAL-tp6360189p6360189.html Sent from the GDAL - Dev
mailing list archive at Nabble.com.
___
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] Re: VRT Derived Bands from Python?
On 13/05/2011 19:07, Even Rouault wrote: I had also a similar error on Linux, but it worked despite the error. I have pushed a fix in trunk to silent that error. You can try to add a printf() statement in your GDALRegisterMe function to check if it is loaded correctly. You are right, it works despite the error message! I did not even think about checking that... Great, thanks alot once again! ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Creating mosaic larger than 4GB using gdal_merge.py
Hi, Using gdal_merge.py to merge multiple Geotif files and get the following error? Is there a work around to the size issue? Expected output file size is about 12 Gigs. I was under the impression gdal was able to handle Big TIFF format. If not, can you please suggest a format available in Gdal that I can use which will support large rasters? gdal_merge.py -o tot.tif Port*.tif ERROR 6: A 53888 pixels x 35904 lines x 3 bands UInt16 image would be larger than 4GB but this is the largest size a TIFF can be. Creation failed. Creation failed, terminating gdal_merge. Thanks, Vytas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Creating mosaic larger than 4GB using gdal_merge.py
On Fri, May 13, 2011 at 11:03 AM, Vytas vy...@dendron.com wrote: Hi, gdal_merge.py -o tot.tif Port*.tif Try gdal_merge.py -co BIGTIFF=IF_NEEDED -o tot.tif Port*.tif ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Translating ArcInfo binary grid to USGS .dem in C# via GDAL
Even, CreateCopy did it. Thanks! -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Translating-ArcInfo-binary-grid-to-USGS-dem-in-C-via-GDAL-tp6360189p6360610.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: VRT Derived Bands from Python?
Hi Even, hi Knut-Frode, Il 13/05/2011 19:07, Even Rouault ha scritto: Le vendredi 13 mai 2011 18:59:14, Knut-Frode Dagestad a écrit : On 13/05/2011 12:07, Antonio Valentino wrote: If you think it is useful I can attach the fake-driver code to the #3367. Thank you, that would be useful. Now the code is at http://trac.osgeo.org/gdal/attachment/ticket/3367/pixfun-plugin-20110513.tar.gz In the meantime I have tested this approach, nearly successful: I copied one of your pixel-functions from #3367 and made a dynamic library file with: gcc -fPIC -c gdal_nerscpixelfun.c gcc -shared -lgdal -o gdal_nerscpixelfun.so gdal_nerscpixelfun.o and then set GDAL_DRIVER_PATH to point to this folder. However, at GDAL startup I get the following error: ERROR 1: dlsym(0x100e095f0, _GDALRegister_nerscpixelfun): symbol not found I had also a similar error on Linux, but it worked despite the error. I have pushed a fix in trunk to silent that error. You can try to add a printf() statement in your GDALRegisterMe function to check if it is loaded correctly. Explanation : GDAL tries to load first a symbol called GDALRegister_x when the .so is called gdal_xx.so/dll, and if not present it then tries GDALRegisterMe. There's no point emitting an error if GDALRegister_x is not found, but GDALRegisterMe is found. See http://trac.osgeo.org/gdal/changeset/22359 I just used GDALRegister_PIXFUN. There is some difference? ciao -- Antonio Valentino ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Matching two rasters
GDALers: Say I have two rasters, A and B with different projections, extents, and resolution. I want to make B match A, such that the projection, resolution, and extent (filling in with some arbitrary value where there is no data) all match. Is there a quick way to do this using command line gdal tools? --j -- Jonathan A. Greenberg, PhD Assistant Project Scientist Center for Spatial Technologies and Remote Sensing (CSTARS) Department of Land, Air and Water Resources University of California, Davis One Shields Avenue Davis, CA 95616 Phone: 415-763-5476 AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Matching two rasters
Le vendredi 13 mai 2011 21:58:50, Jonathan Greenberg a écrit :
GDALers:
Say I have two rasters, A and B with different projections, extents,
and resolution. I want to make B match A, such that the projection,
resolution, and extent (filling in with some arbitrary value where
there is no data) all match. Is there a quick way to do this using
command line gdal tools?
Hum, you could try this 2 step process :
1) Create an empty raster that has same projection, resolution and extent than
A. Let call it C.tif
Cleaner solution : with a tiny python script.
from osgeo import gdal
src_ds = gdal.Open('A')
out_ds = gdal.GetDriverByName('GTiff').Create('C.tif', src_ds.RasterXSize,
src_ds.RasterYSize, src_ds.RasterCount)
out_ds.SetProjection(src_ds.GetProjectionRef())
out_ds.SetGeoTransform(src_ds.GetGeoTransform())
out_ds = None
Or ugly way with just gdal_translate :
gdal_translate A C.tif -scale 0 1e30
(this will force rescaling the values by 1e-30, so in practice nullifying the
data if you work with non-floating point sources)
2) gdalwarp B C.tif
This will 'copy' and reproject if necessary the content of B in C.tif using
its projections, extents, and resolution
--j
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Matching two rasters
Jonathan, Assuming you want to convert B's projection to A's. First, run gdalinfo on A.tif and save the part under 'Coordinate System is:' in a file named 'A.prf'. This is the OGC's WKT representation of the Spatial Reference System of A.tif Then, run gdalwarp on B.tif with the following options. -t_srs A.prf to specify the projection system. Specify the target extents using the -te option. You can get the extents from the output of gdalinfo on A.tif. You might also want to set the resolution using the -tr option and the resampling method using the -r option. http://www.gdal.org/gdalinfo.html http://www.gdal.org/gdalwarp.html On Sat, May 14, 2011 at 1:28 AM, Jonathan Greenberg greenb...@ucdavis.eduwrote: GDALers: Say I have two rasters, A and B with different projections, extents, and resolution. I want to make B match A, such that the projection, resolution, and extent (filling in with some arbitrary value where there is no data) all match. Is there a quick way to do this using command line gdal tools? --j -- Jonathan A. Greenberg, PhD Assistant Project Scientist Center for Spatial Technologies and Remote Sensing (CSTARS) Department of Land, Air and Water Resources University of California, Davis One Shields Avenue Davis, CA 95616 Phone: 415-763-5476 AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
