[gdal-dev] How to specify extent of a VRTWarpedDataset in Python?
Even Rouault
even.rouault at mines-paris.org
Wed Jun 1 05:32:55 EDT 2011
Selon Anton Korosov <anton.korosov at nersc.no>:
> Hi!
> we are developing software for automatic processing of satellite data
> and decided to base it mostly on GDAL-Python bindings. Can I ask you
> about options to create Warped VRT datasets in Python?
>
> 1. The command
>
> gdalwarp -t_srs '+proj=utm +zone=24 +datum=WGS84' -of VRT -tr 1000 1000
> -te -1000000 7000000 2000000 10000000 input.tif output.vrt
>
> creates a VRT file of subclass VRTWarpedDataset. The size, resolution
> and spatial reference is specified by the options of that command.
> Is there any way I can create such VRTWarpedDataset using GDAL-Python
> bindings?
Yes, with Dataset.Create() by specifying a SUBCLASS=VRTWarpedDataset creation
option. ... But I don't think it will help you much since the
GDALInitializeWarpedVRT() that is then used by gdalwarp to fill the dataset
isn't mapped to SWIG.
>
> I'm afraid that with the function gdal.AutoCreateWarpedVRT() I can
> specify only spatial reference (i.e. UTM Zone) but not raster size and
> resolution. Am I right?
Yes
> Of course I can edit the generated VRT file and adjust RasterXSize,
> RasterYSize, GeoTransform and DstGeoTransform manually. But is there any
> way to do that programmatically?
None that I am aware of with Python
>
>
> 2. How can I convert the VRT dataset generated by AutoCreateWarpedVRT
> into a string without writing to disk? That's necessary since a VRT from
> a MERIS full swath exceeds 6 MB. Also for our applications it would be
> much more efficient to edit XML in memory and then to flush to disk with
> CreateCopy.
You can use a virtual memory file. You translate your in-memory VRT dataset with
CreateCopy() into a /vsimem/some_name.vrt and then you can read the content of
that virtual file with gdal.VSIFOpenL() / gdal.VSIFReadL() / gdal.VSIFCloseL() /
gdal.Unlink(). I assume you use at least GDAL 1.8.0 since they weren't mapped to
python before.
>
> Thanks for support!
> Anton
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
More information about the gdal-dev
mailing list