[gdal-dev] GDAL query creation options?
Is there a way to programatically query what dataset creation/layer creation options are available for a driver?I'd like to be able to do something like: driver-listDCO(*options) -- View this message in context: http://osgeo-org.1560.x6.nabble.com/GDAL-query-creation-options-tp5210356.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] GDAL query creation options?
Selon jramm jamessr...@gmail.com: Is there a way to programatically query what dataset creation/layer creation options are available for a driver?I'd like to be able to do something like: driver-listDCO(*options) driver-GetMetadataItem(GDAL_DMD_CREATIONOPTIONLIST) for raster drivers, and starting with GDAL 2.0, for vector drivers as well driver-GetMetadataItem(GDAL_DS_LAYER_CREATIONOPTIONLIST) for vector drivers, starting with GDAL 2.0 This will return a string with a XML content describing the options. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/GDAL-query-creation-options-tp5210356.html Sent from the GDAL - Dev mailing list archive at Nabble.com. -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Overlay shapefile onto Geotiff image
Hi, I have been working on this issue for quite a while. I currently have a GeoTiff image and a shapefile. I would like to overlay the shapefile on the Geotiff, is this possible with Gdal? I looked into gdal_rasterize but I just don't know how to incorporate it with what I need. A code to start with would be great if possible. Or maybe point me into the right direction of probably other libraries that could do this. First, turn your shapefile into a geotiff. You can do this by reading the documentation and searching google for gdal_rasterize. You'll need to tell it what size you want to burn. You can do that by looking at the extents (northeast, southwest) of your current raster/geotiff. Second, overlay the 'shapefile geotiff' onto the other geotiff. To do this, read the documentation for gdal_merge.pyor gdalwarp Both of them can do what you want. And look for some online articles about those tools for practical examples. For example, read this and try to practice it: http://geoinformaticstutorial.blogspot.no/2012/11/convert-shapefile-to-raster-with-gdal.html Graeme Bell ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Creating a transparent GeoTIFF, writing shape data over it, reading GeoTIFF writing as PNG with transparency.
I have attempted to answer Questions 1 and 3 here: https://github.com/geopaparazzi/Spatialite-Tasks-with-Sql-Scripts/wiki/Project-1811-gdal_question I will start on Question 2 now, since I have not used gdal_rasterize that often. A quick answer is however, 1) gdal_translate -of PNG -a_nodata 192 ../sources/1811.Neuester_Grundriss_von_Berlin.5800.3068.tif 1811.Neuester_Grundriss_von_Berlin.5800.3068.png 3) gdal_translate -of PNG -a_nodata 192 -projwin 24800 21300 25800 20700 ../sources/1811.Neuester_Grundriss_von_Berlin.5800.3068.tif 1811.Neuester_Grundriss_von_Berlin.5800.3068.area_rote_rathausturm_panorama.png Mark Johnson, Berlin Germany ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDALWarp API and paletted images
Great, thanks! I tried this, but got only a red image as result, so I guess only the first channel was used. This is the relevant code, where _ds is the input paletted data set vrtDS = vrtDriver-Create(, origW, origH, 3, GDT_Byte, NULL); double geoTransform[6]; _ds-GetGeoTransform(geoTransform); vrtDS-SetGeoTransform(geoTransform); GDALSetProjection(vrtDS, _srcProjectionWKT.c_str()); GDALRasterBand* srcBand = _ds-GetRasterBand(1); vrtDS-AddBand(GDT_Byte, NULL); vrtDS-AddBand(GDT_Byte, NULL); vrtDS-AddBand(GDT_Byte, NULL); VRTSourcedRasterBand* vrtRBand = (VRTSourcedRasterBand*)vrtDS-GetRasterBand(1); VRTSourcedRasterBand* vrtGBand = (VRTSourcedRasterBand*)vrtDS-GetRasterBand(2); VRTSourcedRasterBand* vrtBBand = (VRTSourcedRasterBand*)vrtDS-GetRasterBand(3); vrtRBand-AddComplexSource(srcBand, -1, -1, -1, -1, -1, -1, -1, -1, 0.0, 1.0, VRT_NODATA_UNSET, 1); vrtGBand-AddComplexSource(srcBand, -1, -1, -1, -1, -1, -1, -1, -1, 0.0, 1.0, VRT_NODATA_UNSET, 2); vrtBBand-AddComplexSource(srcBand, -1, -1, -1, -1, -1, -1, -1, -1, 0.0, 1.0, VRT_NODATA_UNSET, 3); Is there anything I have missed in the setup here? - Thomas On Tue, Jun 9, 2015 at 1:44 PM, Even Rouault even.roua...@spatialys.com wrote: Thomas, I'm using the GDALWarp api from C++ to reproject and cut various input images. In general this works very well for my purposes, except that for paletted images I have to use NearestNeighbour resampling, I would like to use Bilinear or higher order resampling, and wonder if there is any way to expand a paletted image to true RGB during the warp process, so I can use these resampling methods. No, you must use an intermediate step before. Alternatively, is there a way to do this conversion (from code) before the warp without having to run through the entire image in memory? You can use a in-memory VRT dataset to do on-the-fly expansion to RGB. With the AddComplexSource() method of VRTSourcedRasterBand class: CPLErr AddComplexSource( GDALRasterBand *poSrcBand, int nSrcXOff=-1, int nSrcYOff=-1, int nSrcXSize=-1, int nSrcYSize=-1, int nDstXOff=-1, int nDstYOff=-1, int nDstXSize=-1, int nDstYSize=-1, double dfScaleOff=0.0, double dfScaleRatio=1.0, double dfNoDataValue = VRT_NODATA_UNSET, int nColorTableComponent = 0); Set nColorTableComponent to 1,2,3 for respectively R,G,B. This is what gdal_translate will do if you use gdal_translate -of VRT -expand rgb pct.tif out.vrt Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] PostgreSQL drivers
I have PostgreSQL 9.4 running on a 64-bit Centos 6.4 machine, I have then used yum to install gdal.x86_641.9.2-6.rhel6 gdal-devel.x86_64 1.9.2-6.rhel6 gdal-java.x86_64 1.9.2-6.rhel6 gdal-libs.x86_64 1.9.2-6.rhel6 all from the pgdg94 repository. And when I do ogr2ogr --formats | grep Post I get - PostgreSQL (read/write) I also a 32-bit Centos 6.4 machine, on which I have used to remove PostgreSQL 8.4 and install PostgreSQL 9.4. I have then used yum to install gdal.i6861.9.2-6.rhel6 gdal-devel.i686 1.9.2-6.rhel6 gdal-java.i686 1.9.2-6.rhel6 gdal-libs.i686 1.9.2-6.rhel6 again all from the pgdg94 repository. But ogr2ogr is unable to connect to the database. When I do ogr2ogr --formats | grep Post I get nothing. It LOOKS like the 32-bit gdal packages from the pgdg94 repository do not have PostgreSQL drivers. Which makes no sense to me, given that I believe that the pgdg94 is maintained by the Postgres project. How do I track down what has gone wrong and fix it? Robert -- Robert Inder,0131 229 1052 / 07808 492 213 Interactive Information Ltd, 3, Lauriston Gardens, Edinburgh EH3 9HH Registered in Scotland, Company no. SC 150689 Interactions speak louder than words ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Creating a transparent GeoTIFF, writing shape data over it, reading GeoTIFF writing as PNG with transparency.
Question 2 is now finished: https://github.com/geopaparazzi/Spatialite-Tasks-with-Sql-Scripts/wiki/Project-1811-gdal_question-02 Short version: gdal_rasterize -tr 0.475211759942328 0.475212956422887 -te 24800 20700 25800 21300 -ot Byte -init 192 -a_nodata 192 -burn 0 -burn 173 -burn 83 -sql SELECT ST_Buffer(soldner_segment,2.5) FROM segments_berlin_1786 ../sources/berlin_segments_qgis.db segments_berlin_1786_green.tif and combine the images with - gdalbuildvrt and gdal_translate --- This was the first time I used gdal_rasterize and found the sample on the htlm-page misleading - there is no sample on creating a image that can be overlayed (i.e. create a new image) - the first sample, assumes one is directly overwriting another image -- when using that sample in creating an new image it will fail, since '.b' is not permitted in new images - there is no sample on how to influence the width of the of the created lines All of this is useful for someone trying this out for the first time. Mark ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdalwarp on a .vrt: Using internal nodata values (eg 0) for image (?)
I am experimenting with using 'gdalwarp' on a .vrt (first time), but I'm not sure what I'm doing wrong. I've been running this: gdalwarp -s_srs EPSG:4326 -t_srs EPSG:3857 -r bilinear -of VRT merged.vrt srtm_merged_3857.vrt and it processes fast (far far *too fast* for this global file) and returns Creating output file that is 194835P X 479814L. Processing input file merged.vrt Using internal nodata values (eg. 0) for image merged.vrt The return .vrt file definitely doesn't appear right...a quick look at the returned file: input: Size is 432000, 208800 Coordinate System is: GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4326]] Origin = (-180.0004170,84.0004166) Pixel Size = (0.0008323,-0.0008323) Corner Coordinates: Upper Left (-180.0004167, 84.0004167) (180d 0' 1.50W, 84d 0' 1.50N) Lower Left (-180.0004167, -89.9995833) (180d 0' 1.50W, 89d59'58.50S) Upper Right ( 179.9995833, 84.0004167) (179d59'58.50E, 84d 0' 1.50N) Lower Right ( 179.9995833, -89.9995833) (179d59'58.50E, 89d59'58.50S) Center ( -0.0004167, -2.9995833) ( 0d 0' 1.50W, 2d59'58.50S) Band 1 Block=128x128 Type=Int16, ColorInterp=Gray NoData Value=0 Overviews: 216000x104400, 108000x52200, 54000x26100, 27000x13050, 13500x6525, 6750x3263, 3375x1632, 1688x816, 844x408, 422x204 and output file: Size is 193861, 479814 Coordinate System is: PROJCS[WGS 84 / Pseudo-Mercator, GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0, AUTHORITY[EPSG,8901]], UNIT[degree,0.0174532925199433, AUTHORITY[EPSG,9122]], AUTHORITY[EPSG,4326]], PROJECTION[Mercator_1SP], PARAMETER[central_meridian,0], PARAMETER[scale_factor,1], PARAMETER[false_easting,0], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]], AXIS[X,EAST], AXIS[Y,NORTH], EXTENSION[PROJ4,+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs], AUTHORITY[EPSG,3857]] Origin = (-19837179.64248511900,18807657.84885524600) Pixel Size = (205.686440189378940,-205.686440189378940) Corner Coordinates: Upper Left (-19837179.642,18807657.849) (178d12' 1.50W, 84d 0' 1.50N)Lower Left (-19837179.642,-79883575.764) (178d12' 1.50W, 89d59'58.50S) Upper Right (20037399.339,18807657.849) (179d59'56.47E, 84d 0' 1.50N) Lower Right (20037399.339,-79883575.764) (179d59'56.47E, 89d59'58.50S) Center ( 100109.848,-30537958.958) ( 0d53'57.49E, 89d 2'43.78S)Band 1 Block=512x128 Type=Int16, ColorInterp=Gray Overviews: 96931x239907, 48466x119954, 24233x59977, 12117x29989, 6059x14995, 3030x7498, 1515x3749, 758x1875, 379x938, 191x471 One notably huge difference is that there is a huge jump in pixel size (from 0.0008323 to 205.686440189378940)... ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp on a .vrt: Using internal nodata values (eg 0) for image (?)
One notably huge difference is that there is a huge jump in pixel size (from 0.0008323 to 205.686440189378940)... ah, duh. Unit change. On Thu, Jun 11, 2015 at 2:26 PM, Ari Simmons ari.ucb.f...@gmail.com wrote: I am experimenting with using 'gdalwarp' on a .vrt (first time), but I'm not sure what I'm doing wrong. I've been running this: gdalwarp -s_srs EPSG:4326 -t_srs EPSG:3857 -r bilinear -of VRT merged.vrt srtm_merged_3857.vrt and it processes fast (far far *too fast* for this global file) and returns Creating output file that is 194835P X 479814L. Processing input file merged.vrt Using internal nodata values (eg. 0) for image merged.vrt The return .vrt file definitely doesn't appear right...a quick look at the returned file: input: Size is 432000, 208800 Coordinate System is: GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4326]] Origin = (-180.0004170,84.0004166) Pixel Size = (0.0008323,-0.0008323) Corner Coordinates: Upper Left (-180.0004167, 84.0004167) (180d 0' 1.50W, 84d 0' 1.50N) Lower Left (-180.0004167, -89.9995833) (180d 0' 1.50W, 89d59'58.50S) Upper Right ( 179.9995833, 84.0004167) (179d59'58.50E, 84d 0' 1.50N) Lower Right ( 179.9995833, -89.9995833) (179d59'58.50E, 89d59'58.50S) Center ( -0.0004167, -2.9995833) ( 0d 0' 1.50W, 2d59'58.50S) Band 1 Block=128x128 Type=Int16, ColorInterp=Gray NoData Value=0 Overviews: 216000x104400, 108000x52200, 54000x26100, 27000x13050, 13500x6525, 6750x3263, 3375x1632, 1688x816, 844x408, 422x204 and output file: Size is 193861, 479814 Coordinate System is: PROJCS[WGS 84 / Pseudo-Mercator, GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0, AUTHORITY[EPSG,8901]], UNIT[degree,0.0174532925199433, AUTHORITY[EPSG,9122]], AUTHORITY[EPSG,4326]], PROJECTION[Mercator_1SP], PARAMETER[central_meridian,0], PARAMETER[scale_factor,1], PARAMETER[false_easting,0], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]], AXIS[X,EAST], AXIS[Y,NORTH], EXTENSION[PROJ4,+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs], AUTHORITY[EPSG,3857]] Origin = (-19837179.64248511900,18807657.84885524600) Pixel Size = (205.686440189378940,-205.686440189378940) Corner Coordinates: Upper Left (-19837179.642,18807657.849) (178d12' 1.50W, 84d 0' 1.50N)Lower Left (-19837179.642,-79883575.764) (178d12' 1.50W, 89d59'58.50S) Upper Right (20037399.339,18807657.849) (179d59'56.47E, 84d 0' 1.50N) Lower Right (20037399.339,-79883575.764) (179d59'56.47E, 89d59'58.50S) Center ( 100109.848,-30537958.958) ( 0d53'57.49E, 89d 2'43.78S)Band 1 Block=512x128 Type=Int16, ColorInterp=Gray Overviews: 96931x239907, 48466x119954, 24233x59977, 12117x29989, 6059x14995, 3030x7498, 1515x3749, 758x1875, 379x938, 191x471 One notably huge difference is that there is a huge jump in pixel size (from 0.0008323 to 205.686440189378940)... ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp on a .vrt: Using internal nodata values (eg 0) for image (?)
On Thu, Jun 11, 2015 at 2:38 PM, Ari Simmons ari.ucb.f...@gmail.com wrote: One notably huge difference is that there is a huge jump in pixel size (from 0.0008323 to 205.686440189378940)... ah, duh. Unit change. On Thu, Jun 11, 2015 at 2:26 PM, Ari Simmons ari.ucb.f...@gmail.com wrote: I am experimenting with using 'gdalwarp' on a .vrt (first time), but I'm not sure what I'm doing wrong. I've been running this: gdalwarp -s_srs EPSG:4326 -t_srs EPSG:3857 -r bilinear -of VRT merged.vrt srtm_merged_3857.vrt and it processes fast (far far *too fast* for this global file) and returns That is the right speed (~0 seconds) and disk space (~0MB). That is because it doesn't actually do anything except write down notes of what it would have done (and will do in the future if you ask for it). I like testing large VRT files by outputting a subwindow tif like this: gdal_translate -13813007 5569641 -13809113 5572598 srtm_merged_3857.vrt my_subwindow.tif --config GDAL_CACHEMAX 800 If things look good on the subwindow, then it is time for all the I/O waiting, processor cycles, and storage space. Evaluating a few places, especially where tiles come together can find things early without all the wait. HTH, Eli Creating output file that is 194835P X 479814L. Processing input file merged.vrt Using internal nodata values (eg. 0) for image merged.vrt The return .vrt file definitely doesn't appear right...a quick look at the returned file: input: Size is 432000, 208800 Coordinate System is: GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4326]] Origin = (-180.0004170,84.0004166) Pixel Size = (0.0008323,-0.0008323) Corner Coordinates: Upper Left (-180.0004167, 84.0004167) (180d 0' 1.50W, 84d 0' 1.50N) Lower Left (-180.0004167, -89.9995833) (180d 0' 1.50W, 89d59'58.50S) Upper Right ( 179.9995833, 84.0004167) (179d59'58.50E, 84d 0' 1.50N) Lower Right ( 179.9995833, -89.9995833) (179d59'58.50E, 89d59'58.50S) Center ( -0.0004167, -2.9995833) ( 0d 0' 1.50W, 2d59'58.50S) Band 1 Block=128x128 Type=Int16, ColorInterp=Gray NoData Value=0 Overviews: 216000x104400, 108000x52200, 54000x26100, 27000x13050, 13500x6525, 6750x3263, 3375x1632, 1688x816, 844x408, 422x204 and output file: Size is 193861, 479814 Coordinate System is: PROJCS[WGS 84 / Pseudo-Mercator, GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0, AUTHORITY[EPSG,8901]], UNIT[degree,0.0174532925199433, AUTHORITY[EPSG,9122]], AUTHORITY[EPSG,4326]], PROJECTION[Mercator_1SP], PARAMETER[central_meridian,0], PARAMETER[scale_factor,1], PARAMETER[false_easting,0], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]], AXIS[X,EAST], AXIS[Y,NORTH], EXTENSION[PROJ4,+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs], AUTHORITY[EPSG,3857]] Origin = (-19837179.64248511900,18807657.84885524600) Pixel Size = (205.686440189378940,-205.686440189378940) Corner Coordinates: Upper Left (-19837179.642,18807657.849) (178d12' 1.50W, 84d 0' 1.50N) Lower Left (-19837179.642,-79883575.764) (178d12' 1.50W, 89d59'58.50S) Upper Right (20037399.339,18807657.849) (179d59'56.47E, 84d 0' 1.50N) Lower Right (20037399.339,-79883575.764) (179d59'56.47E, 89d59'58.50S) Center ( 100109.848,-30537958.958) ( 0d53'57.49E, 89d 2'43.78S) Band 1 Block=512x128 Type=Int16, ColorInterp=Gray Overviews: 96931x239907, 48466x119954, 24233x59977, 12117x29989, 6059x14995, 3030x7498, 1515x3749, 758x1875, 379x938, 191x471 One notably huge difference is that there is a huge jump in pixel size (from 0.0008323 to 205.686440189378940)... ___ 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] is there a vector testfile with Integer64 values?
Hi, In adapting rgdal for GDAL 2.0.0, it would be useful to know that clamping, etc, and workarounds for integers in Integer64 fields that exceed INT_MAX or INT_MIN actually work. Which of the autotest vector files include Integer64 fields that test reading with Integer or String? The files I see mostly test error trapping, so an indication of where to look would be very valuable. Best with common drivers. Thanks in advance, Roger -- Roger Bivand Department of Economics, Norwegian School of Economics, Helleveien 30, N-5045 Bergen, Norway. voice: +47 55 95 93 55; fax +47 55 95 91 00 e-mail: roger.biv...@nhh.no ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdal_rasterize does not burn polygon attributes
I'm running gdal_rasterize, trying to make it create a new tif from polygons, using an attribute field as the burn value. Here is my command: gdal_rasterize -tr 5 5 -a SOP -l test -a_nodata 0 test.shp test.tif I end up with an image that is all 0's. The shapefile is correct and can be read by OGR...what am I missing? -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-rasterize-does-not-burn-polygon-attributes-tp5210321.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] GDALWarp API and paletted images
Selon Thomas Sevaldrud tho...@silentwings.no: Great, thanks! I tried this, but got only a red image as result, so I guess only the first channel was used. This is the relevant code, where _ds is the input paletted data set vrtDS = vrtDriver-Create(, origW, origH, 3, GDT_Byte, NULL); double geoTransform[6]; _ds-GetGeoTransform(geoTransform); vrtDS-SetGeoTransform(geoTransform); GDALSetProjection(vrtDS, _srcProjectionWKT.c_str()); GDALRasterBand* srcBand = _ds-GetRasterBand(1); vrtDS-AddBand(GDT_Byte, NULL); vrtDS-AddBand(GDT_Byte, NULL); vrtDS-AddBand(GDT_Byte, NULL); You don't need the above 3 AddBand() since you called Create() with 3 already VRTSourcedRasterBand* vrtRBand = (VRTSourcedRasterBand*)vrtDS-GetRasterBand(1); VRTSourcedRasterBand* vrtGBand = (VRTSourcedRasterBand*)vrtDS-GetRasterBand(2); VRTSourcedRasterBand* vrtBBand = (VRTSourcedRasterBand*)vrtDS-GetRasterBand(3); vrtRBand-AddComplexSource(srcBand, -1, -1, -1, -1, -1, -1, -1, -1, 0.0, 1.0, VRT_NODATA_UNSET, 1); vrtGBand-AddComplexSource(srcBand, -1, -1, -1, -1, -1, -1, -1, -1, 0.0, 1.0, VRT_NODATA_UNSET, 2); vrtBBand-AddComplexSource(srcBand, -1, -1, -1, -1, -1, -1, -1, -1, 0.0, 1.0, VRT_NODATA_UNSET, 3); Is there anything I have missed in the setup here? Looks good otherwise. Did you check that you configured properly the warper to use the 3 bands of the VRT ? - Thomas On Tue, Jun 9, 2015 at 1:44 PM, Even Rouault even.roua...@spatialys.com wrote: Thomas, I'm using the GDALWarp api from C++ to reproject and cut various input images. In general this works very well for my purposes, except that for paletted images I have to use NearestNeighbour resampling, I would like to use Bilinear or higher order resampling, and wonder if there is any way to expand a paletted image to true RGB during the warp process, so I can use these resampling methods. No, you must use an intermediate step before. Alternatively, is there a way to do this conversion (from code) before the warp without having to run through the entire image in memory? You can use a in-memory VRT dataset to do on-the-fly expansion to RGB. With the AddComplexSource() method of VRTSourcedRasterBand class: CPLErr AddComplexSource( GDALRasterBand *poSrcBand, int nSrcXOff=-1, int nSrcYOff=-1, int nSrcXSize=-1, int nSrcYSize=-1, int nDstXOff=-1, int nDstYOff=-1, int nDstXSize=-1, int nDstYSize=-1, double dfScaleOff=0.0, double dfScaleRatio=1.0, double dfNoDataValue = VRT_NODATA_UNSET, int nColorTableComponent = 0); Set nColorTableComponent to 1,2,3 for respectively R,G,B. This is what gdal_translate will do if you use gdal_translate -of VRT -expand rgb pct.tif out.vrt Even -- Spatialys - Geospatial professional services http://www.spatialys.com -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
