[gdal-dev] gdalbuildvrt : addalpha adds a new band even if not needed

Hello, I'm using gdalbuildvrt to create a virtual raster from multiple tiff tiles. I need the output virtual raster to have an alpha band, and as I do not know beforehand if the input rasters will contain one or not, I use the 'addalpha' option of gdalbuildvrt to add one if needed. As I understand

Re: [gdal-dev] "gdalbuildvrt does not support rotated geo transforms"

Hi, Try with gdalinfo, it should reveal the rotation. And with gdalwarp you can convert the image into north-up. -Jukka Rahkonen- Lorenzo Di Giacomo wrote > Hi, do you know why this happens when i try to merge tiles of a specific > tiff? > How can check if a tiff had a rotated geo transforms? A

[gdal-dev] "gdalbuildvrt does not support rotated geo transforms"

Hi, do you know why this happens when i try to merge tiles of a specific tiff? How can check if a tiff had a rotated geo transforms? And how can i fix it before merging it? Here are some QGIS info about the tiff: SR EPSG:4326 - WGS 84 - Geografico Estensione -179.9716,-90.00400010370684

Re: [gdal-dev] gdalbuildvrt and band descriptions

Done! Enable gdalbuildvrt to retain metadata such as band description https://github.com/OSGeo/gdal/issues/3627 -Matt From: Even Rouault Sent: March 26, 2021 5:09 PM To: Matt.Wilkie ; gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] gdalbuildvrt and band descriptions Matt, copying over band

Re: [gdal-dev] gdalbuildvrt and band descriptions

Thanks Even, very useful. I didn't check the parent class, GDALMajorObject, my fault. I use two sources (example for raster band): - https://gdal.org/doxygen/classGDALRasterBand.html where I have to click on the parent class(es), and study them recursively. Oh, now I realize that the small arrow

Re: [gdal-dev] gdalbuildvrt and band descriptions

Javier, Le 27/03/2021 à 12:44, Javier Jimenez Shaw a écrit : Hi, Is there any way in C++ to set the band description? GDALMajorObject::Description() I know only SetColorInterpretation  that has a limited

Re: [gdal-dev] gdalbuildvrt and band descriptions

Hi, Is there any way in C++ to set the band description? I know only SetColorInterpretation that has a limited number of options ( https://gdal.org/doxygen/gdal_8h.html#ace76452d94514561fffa8ea1d2a5968c) none of

Re: [gdal-dev] gdalbuildvrt and band descriptions

Matt, copying over band description (and other band metadata) in the -separate case would make sense. Please file an enhancement ticket about that Even Le 27/03/2021 à 00:40, matt.wil...@yukon.ca a écrit : Hi Folks, `gdal_translate -b 1 infile.tif outfile.vrt` will copy the band 1 descrip

[gdal-dev] gdalbuildvrt and band descriptions

Hi Folks, `gdal_translate -b 1 infile.tif outfile.vrt` will copy the band 1 description to the output file. `gdalbuild.vrt` on the other hand leaves the band descriptions behind. Is there a way to have vrt carry the description across also? The project behind the question is to keep only the 4

Re: [gdal-dev] gdalbuildvrt files not recognized

Yep, it is easier to build your process with a listing step that you'll feed to gdalbuildvrt. For example, on our win10 env it works with tamas' gisinternal build with cmd but not with the conda build and cmd :) Le vendredi 05 février 2021 à 08:58 -0700, Richard Greenwood a écrit : > I think that

Re: [gdal-dev] gdalbuildvrt files not recognized

I think that wildcard expansion has been an on and off problem with some of the GDAL utilities on Windows. If you Google "gdalbuildvrt wildcard expansion" you'll find at least three tickets, the most recent of which is: https://github.com/OSGeo/gdal/issues/1749 I think the safest and easiest is to

Re: [gdal-dev] gdalbuildvrt files not recognized

On Thu, 4 Feb 2021 at 23:22, Simon Shak wrote: > > However, your suggestion to check the filelist.txt file has found the error. > Somehow a trailing space was before the CRLF and caused it to not recognize > the file. There also could be an issue if there are spaces in file names. I don't know

Re: [gdal-dev] gdalbuildvrt files not recognized

if I try to use wildcard: gdalbuildvrt output.vrt input/*.ecw I get the error: ERROR 4: `input/*.ecw' does not exist in the file system, and is not recognized as a supported dataset name. it doesn't matter if I use / or \ or * or *.ecw or *.*. My expectation based on the documentation and previous

Re: [gdal-dev] gdalbuildvrt files not recognized

On Thu, 4 Feb 2021, 23:02 Simon Shak, wrote: > > If I do it straight via commandline as: > for %f in (input\*.ecw) do (gdalbuildvrt output.vrt %f) > I wind up with a VRT with only one of the several hundred files in it. > Yes, that's expected, isn't it. if I try it using a file list by first:

[gdal-dev] gdalbuildvrt files not recognized

I'm working on using the gdal2tiles to convert a mosaic of ECW files into TMS format. Since the gdal2tiles command needs a single input file, I'm building VRT's to use as the input. I have gotten this to work on ons set of files. When I do the same commands for the second set of files, gdalbuildvr

[gdal-dev] gdalbuildvrt ignoring NoData for complex (CFloat32) valued rasters

Hi, I wanted to check here first before reporting this as a bug: I'm trying to tile 2 together with buildvrtraster. I can make it work with 2 Float32 images that have 0s; however, with the complex images, the last image always overwrites all of the previous, even where it has 0s and the nodata is

[gdal-dev] gdalbuildvrt cannot specify srcnodata for multiple bands

I'm trying to build a vrt and specify multiple source nodata values. It's the same problem with both gdalbuildvrt on the commandline and calling gdal.BuildVRTOptions programmatically. Looking at the doc and at the code, it seems that the srcNodata value needs to be a string of space separated va

Re: [gdal-dev] gdalbuildvrt could not use worldfile

It might indeed be the missing CRS info (world files include only the pixel size and corner pixel). Try to add the -a_srs parameter as Jukka suggested. for instance, add "-a_srs EPSG:32632" (if you are using WGS84 / UTM Zone 32N https://epsg.io/32632 ) On Thu, 20 Aug 2020 at

Re: [gdal-dev] gdalbuildvrt could not use worldfile

Dear Idan, thank you for your input. I use the .vrt step to assemble a group of tif's to one common file. In a second step I use something like gdal_translate -of GTiff -co COMPRESS=LZW -co tiled=yes maps.vrt maps.tiff But the maps.tiff has no georeference data's as well. This two steps w

Re: [gdal-dev] gdalbuildvrt could not use worldfile

Hi, I don't know your map viewer but perhaps it wants to know both the location of your image (the coordinates) and in what coordinate reference system the coordinates are. You have now the corner coordinates and pixel size but the CRS is unknown. Run gdalbuildvrt with "-a_srs" for attaching it. I

Re: [gdal-dev] gdalbuildvrt could not use worldfile

Hi, According to gdalinfo your vrt looks fine, so it might be a problem with the vrt support in mapviewer. What are you trying to accomplish with this vrt? if you just want to georeference your tif you could try: gdal_translate -of GTiff input.tif ouput.tif use "-co COMPRESS=DEFLATE -co TILED=YES

[gdal-dev] gdalbuildvrt could not use worldfile

Hello list, I'm a beginner with gdal and use Linux Debian testing as the OS. I like to create a .vrt file to use a map. The map comes with a worldfile .tfw: 1.27 0.00 0.00 -1.27 376279.10 5679613.91 If I try to build the .vrt by using gdalb

[gdal-dev] gdalbuildvrt -separate from list of files with two bands

Hi, I'd like to combine a large list of raster files (each of which has two bands) into one .vrt, where each band of the VRT would have the 2nd band from each file. I thought that the "-b 2" option , but doing gdalbuildvrt -b 2 -separate outvrt.vrt *two2band_inputs.tif just gives the warnin

Re: [gdal-dev] gdalbuildvrt issues

""" With -separate, each files goes into a separate band in the VRT dataset. Otherwise, the files are considered as tiles of a larger mosaic and the VRT file has as many bands as one of the input files. """ I guess it's this bit " Otherwise, the files are considered as tiles of a larger mosaic.

Re: [gdal-dev] gdalbuildvrt issues

> Yes, also found that (after). It's the panchromatic band 8 of the LandSat8 > set, which has double resolution. But in this case, shouldn't the -separate > option make a difference? But it doesn't. The result is the same either if > I use it or not (confess that I don't understand the meaning of t

Re: [gdal-dev] gdalbuildvrt issues

You probably need to define the following in your nmake.local: ># To be enabled defined to point to wsetargv.obj from the Visual C++ >directory, # when you want >the utility programs to be able to expand >wildcards. >#SETARGV = "D:\Software\VStudio\VC98\lib\wsetargv.obj" >Note: regular s

Re: [gdal-dev] gdalbuildvrt issues

On lundi 11 novembre 2019 16:14:34 CET Joaquim Manuel Freire Luís wrote: > Hi, > > I'm facing strange things when using gdalbuildvrt. First, with my own build > (GDAL master) I can't use wild cards (Windows here) You probably need to define the following in your nmake.local: # To be enabled defi

[gdal-dev] gdalbuildvrt issues

Hi, I'm facing strange things when using gdalbuildvrt. First, with my own build (GDAL master) I can't use wild cards (Windows here) $ gdalbuildvrt --version GDAL 3.1.0dev, released 2019/99/99 j@MARILU C:\SIG_AnaliseDadosSatelite\SIG_ADS\DadosEx2\LC82040332015145LGN00 $ gdalbuildvrt lixo.vrt *.T

Re: [gdal-dev] Gdalbuildvrt does not read *.tif

On lundi 23 septembre 2019 17:26:47 CEST Rahkonen Jukka (MML) wrote: > Hi, > > On Windows, with GDAL 3.1.0dev, released 2019/99/99, downloaded today from > gisinternals > http://download.gisinternals.com/sdk/downloads/release-1911-x64-gdal-mapser > ver.zip the gdalbuildvrt utility does not read a

[gdal-dev] Gdalbuildvrt does not read *.tif

Hi, On Windows, with GDAL 3.1.0dev, released 2019/99/99, downloaded today from gisinternals http://download.gisinternals.com/sdk/downloads/release-1911-x64-gdal-mapserver.zip the gdalbuildvrt utility does not read a list of files with "*.tif". Instead happens this gdalbuildvrt test.vrt *.tif

Re: [gdal-dev] gdalbuildvrt with different resolutions

Hi, What I imagined would be the option for getting an error message if not all of the files have the same resolution. Something like -allow_projection_difference but the other way around. Maybe -disallow_different_resolutions is clearer than my previous suggestion. All the best, Christoph

Re: [gdal-dev] gdalbuildvrt with different resolutions

Christoph Paulik wrote > Hi, > > Would it be possible/a good idea to add an option to gdalbuildvrt to force > all files > to be of the same resolution? > > We have files that go into a VRT that should all have the same > resolution and I would like an error to be raised if they do not. We > could

[gdal-dev] gdalbuildvrt with different resolutions

Hi, Would it be possible/a good idea to add an option to gdalbuildvrt to force all files to be of the same resolution? We have files that go into a VRT that should all have the same resolution and I would like an error to be raised if they do not. We could of course implement an external check

Re: [gdal-dev] gdalbuildvrt 2.1.0 and off by 1 pixel display

Great. Thanks!   Original Message   From:even.roua...@spatialys.com Sent:July 1, 2016 15:50 To:jedfreche...@gmail.com Cc:gdal-dev@lists.osgeo.org Subject:Re: [gdal-dev] gdalbuildvrt 2.1.0 and off by 1 pixel display Le vendredi 01 juillet 2016 22:48:36, Jed Frechette a écrit : > On 2016-07-0

Re: [gdal-dev] gdalbuildvrt 2.1.0 and off by 1 pixel display

Le vendredi 01 juillet 2016 22:48:36, Jed Frechette a écrit : > On 2016-07-01 1:51 PM, Even Rouault wrote: > > If read by GDAL < 2.1, those VRT files will > > exhibit possible one-off shift, since those older versions only read > > values as integers. Is it your case ? > > I see it in QGIS 2.14.3

Re: [gdal-dev] gdalbuildvrt 2.1.0 and off by 1 pixel display

Le vendredi 01 juillet 2016 20:43:24, Jed Frechette a écrit : > Starting with version 2.1.0 I've started to see display errors in both > QGIS and ArcGIS for datasets built with gdalbuildvrt. In both cases, the > vrt data ends up offset by 1 pixel relative to the source files. This > offset is not c

[gdal-dev] gdalbuildvrt 2.1.0 and off by 1 pixel display

Starting with version 2.1.0 I've started to see display errors in both QGIS and ArcGIS for datasets built with gdalbuildvrt. In both cases, the vrt data ends up offset by 1 pixel relative to the source files. This offset is not consistent between applications or within the data set. My guess is th

Re: [gdal-dev] gdalbuildvrt for multiband files?

gdalbuildvrt to create a VRT for the first band of each dataset, then read the VRT using python and duplicate the relevant nodes to add in new bands, then write it out again. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-gdalbuildvrt-fo

[gdal-dev] gdalbuildvrt for multiband files?

Folks: Is there any trick to "stacking" multiple *multiband* files via gdalbuildvrt for further use with e.g. gdal_translate? Basically, this restriction using "separate": "In that case, only the first band of each dataset will be placed into a new band." Is causing problems -- I want to have A

Re: [gdal-dev] gdalbuildvrt & gdal2tiles.py with GeoTIFF across anti-meridian...

Hi Jan, It is worth mentioning that if you render map tiles (mercator or different) for large area from multiple input files and you are hitting issues like: - heterogenous projections (differing srs in input files) - alpha compositing of input files - dateline crossing (anti-meridian) issues -

Re: [gdal-dev] gdalbuildvrt & gdal2tiles.py with GeoTIFF across anti-meridian...

Le mardi 05 janvier 2016 16:20:08, Jan Knepper a écrit : > All, > > Running across (an) other issue(s)... > > I was able to gdalwarp a .tif overlapping the anti-meridian with > --config CENTER_LONG 180 > > Next step was to use gdalbuildvrt to build a .vrt file in preparation > for tiling with gd

[gdal-dev] gdalbuildvrt & gdal2tiles.py with GeoTIFF across anti-meridian...

All, Running across (an) other issue(s)... I was able to gdalwarp a .tif overlapping the anti-meridian with --config CENTER_LONG 180 Next step was to use gdalbuildvrt to build a .vrt file in preparation for tiling with gdal2tiles.py. When trying that this message displays: Warning 6: gdalbu

Re: [gdal-dev] gdalbuildvrt with multiple nodata

How about: gdalbuildvrt -addalpha -hidenodata -srcnodata "0" On Wed, Sep 23, 2015 at 1:50 PM, Jonathan Greenberg wrote: > Folks: > > I've got a weird one -- I'm trying to perform a mosaic of GeoTIFF tiles > that are somewhat overlapping. Here's the odd issue -- I need the mosaic > to basical

[gdal-dev] gdalbuildvrt with multiple nodata

Folks: I've got a weird one -- I'm trying to perform a mosaic of GeoTIFF tiles that are somewhat overlapping. Here's the odd issue -- I need the mosaic to basically set all values of 0 AND "NODATA" to be the srcnodata. How do I do this? Will gdalbuildvrt automatically use "true" NODATA values t

[gdal-dev] gdalbuildvrt overwrite always the vrt file

Hi, I try to create a vrt-datasource using this sintax: gdalbuildvrt /path-to/dataset.vrt \ /path-ti-tiffs/tiff_1.tif It was correctly created. After, I do this other command: gdalbuildvrt /path-to/dataset.vrt \ /path-ti-tiffs/tiff_2.tif The new dataset.vrt I notice is containing the

[gdal-dev] gdalbuildvrt different bands

Hi, I want to produce a set of VRTs that comprise a re-arrangement of bands of a number of individual GeoTIFF files. Say I have file_01: band_01...band_04 file_02: band_01...band_04 file_03: band_01...band_04 file_04: band_01...band_04 And what I want to have is vrt_01: file_01:band_01 file_02:ban

Re: [gdal-dev] gdalbuildvrt problem with heterogenous band characteristics

Dear all, in regard of this different behavior performed by gdalwarp and gdalbuildvrt respect to different data type entries, I have some considerations. The error raised by gdalbuildvrt made me wonder about my data and then with your help I discovered what was wrong with them. On the other hand,

Re: [gdal-dev] gdalbuildvrt problem with heterogenous band characteristics

Hi, On Thu, Aug 16, 2012 at 11:02 PM, Eli Adam wrote: > > Band 1 Block=5000x1 Type=Int16, ColorInterp=Gray > ... > > Band 1 Block=1x1 Type=Float32, ColorInterp=Gray > > > > I can't see anything obvious why these two files can't be mosaiced.. > > > > It looks like one is 16 bit and the other

Re: [gdal-dev] gdalbuildvrt problem with heterogenous band characteristics

> Band 1 Block=5000x1 Type=Int16, ColorInterp=Gray ... > Band 1 Block=1x1 Type=Float32, ColorInterp=Gray > > I can't see anything obvious why these two files can't be mosaiced.. > It looks like one is 16 bit and the other 32. gdalbuildvrt probably can't determine the type of output to create.

Re: [gdal-dev] gdalbuildvrt problem with heterogenous bandcharacteristics

On Thu, Aug 16, 2012 at 5:24 PM, Nicolas Simon < nicolas.si...@spw.wallonie.be> wrote: > ** > Hello, > The problem comes from the data type: Int16 for the first file, > Float32 for the second file. > > Nicolas > > > Thanks! -- Dr. Margherita Di Leo __

Re: [gdal-dev] gdalbuildvrt problem with heterogenous bandcharacteristics

Even Rouault Cc : gdal-dev@lists.osgeo.org Objet : Re: [gdal-dev] gdalbuildvrt problem with heterogenous bandcharacteristics On Thu, Aug 16, 2012 at 4:32 PM, Even Rouault < even.roua...@mines-paris.org> wrote: Selon Margherita Di Leo < direg...@gmail.com>: > Hi All, > &g

Re: [gdal-dev] gdalbuildvrt problem with heterogenous band characteristics

On Thu, Aug 16, 2012 at 4:32 PM, Even Rouault wrote: > Selon Margherita Di Leo : > > > Hi All, > > > > On Mon, Jul 30, 2012 at 7:31 PM, Casper Børgesen (CABO) >wrote: > > > > > Hi! > > > > > > ** ** > > > > > > I’m trying to create a VRT file from 4 GeoTIFFs using gdalbuildvrt. > Three > >

Re: [gdal-dev] gdalbuildvrt problem with heterogenous band characteristics

Selon Margherita Di Leo : > Hi All, > > On Mon, Jul 30, 2012 at 7:31 PM, Casper Børgesen (CABO) wrote: > > > Hi! > > > > ** ** > > > > I’m trying to create a VRT file from 4 GeoTIFFs using gdalbuildvrt. Three > > of the GeoTIFFs are created using OrthoVista and the last one created with > >

Re: [gdal-dev] gdalbuildvrt problem with heterogenous band characteristics

Hi All, On Mon, Jul 30, 2012 at 7:31 PM, Casper Børgesen (CABO) wrote: > Hi! > > ** ** > > I’m trying to create a VRT file from 4 GeoTIFFs using gdalbuildvrt. Three > of the GeoTIFFs are created using OrthoVista and the last one created with > an earlier version of the same program. When I

Re: [gdal-dev] gdalbuildvrt problem with heterogenous band characteristics

not present in the 3 new files. Could this be the reason? *** > * > > ** ** > > Btw. my normal version of gdal is 1.9. > > ** ** > > Regards, Casper > > ** ** > > *From:* Chaitanya kumar CH [mailto:chaitanya...@gmail.com] > *Sent:* 31. juli 2012 15:30 > *To:* Ca

Re: [gdal-dev] gdalbuildvrt problem with heterogenous band characteristics

(CABO) Cc: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] gdalbuildvrt problem with heterogenous band characteristics Casper, This message should not appear unless there is a difference in the band data type, colour interpretation or the band order. Can you check if manually adding the old

Re: [gdal-dev] gdalbuildvrt problem with heterogenous band characteristics

Casper, This message should not appear unless there is a difference in the band data type, colour interpretation or the band order. Can you check if manually adding the old file works? On Mon, Jul 30, 2012 at 11:01 PM, Casper Børgesen (CABO) wrote: > Hi! > > ** ** > > I’m trying to create

[gdal-dev] gdalbuildvrt problem with heterogenous band characteristics

Hi! I'm trying to create a VRT file from 4 GeoTIFFs using gdalbuildvrt. Three of the GeoTIFFs are created using OrthoVista and the last one created with an earlier version of the same program. When I run gdalbuildvrt I get the following error message when I try to add the file created by the ea

Re: [gdal-dev] gdalbuildvrt changes data when building VRT

On Mon, Jan 30, 2012 at 1:17 PM, John Twilley wrote: > I'm using gdalbuildvrt as a simple way to merge adjoining data files. > Unfortunately, I'm noticing that some values change.  I've created a > simple test case where I make a VRT from a single GeoTIFF and compare > histograms before and after,

[gdal-dev] gdalbuildvrt changes data when building VRT

I'm using gdalbuildvrt as a simple way to merge adjoining data files. Unfortunately, I'm noticing that some values change. I've created a simple test case where I make a VRT from a single GeoTIFF and compare histograms before and after, and I've attached it to this message. Can someone tell me why

Re: [gdal-dev] gdalbuildvrt does not support heterogenous band characteristics

Likely Quickbird_06m10.tif has more or less bands than the previous files, or band bit depth is different. That was it, thanks. For some reason although they were all created from the same source and process (arcmap > export > selected area) some images are 8bit RGB and others 16bit grey

Re: [gdal-dev] gdalbuildvrt does not support heterogenous band characteristics

Matt, Likely Quickbird_06m10.tif has more or less bands than the previous files, or band bit depth is different. For example, don't try to include a 1 band 16-bit (e.g. gray scale) tiff in a VRT of 3 band, 8 bits each (e.g. RGB color) tiffs. What does gdalinfo say about this file (and

[gdal-dev] gdalbuildvrt does not support heterogenous band characteristics

Hi Folks, what does this error mean? gdalbuildvrt -input_file_list img-list.txt mosaic.vrt 0...10Warning 6: gdalbuildvrt does not support heterogenous band characteristics . Skipping Quickbird_06m10.tif ...etc. thanks! -- matt wilkie Geomatics Anal

Re: [gdal-dev] gdalbuildvrt, gdal_translate, and MODIS HDF files

Le mardi 03 mai 2011 15:34:16, Jose Gomez-Dans a écrit : > Hi, > > > > > I have recently come across the mosaicking magic that is 1) build a > > vrt > > > > > usin gdalbuildvrt and then 2) gdal_translate the vrt to whatever > > format > > > > > I want -- I'm noticing this is a crazy-fast way t

Re: [gdal-dev] gdalbuildvrt, gdal_translate, and MODIS HDF files

Hi, > > > I have recently come across the mosaicking magic that is 1) build a vrt > > > usin gdalbuildvrt and then 2) gdal_translate the vrt to whatever format > > > I want -- I'm noticing this is a crazy-fast way to do mosaicking > > > compared I had a similar question on this a while ago, and o

Re: [gdal-dev] gdalbuildvrt, gdal_translate, and MODIS HDF files

Le samedi 30 avril 2011 23:01:18, Jonathan Greenberg a écrit : > Even: > > Thanks: how would I "wildcard" this into a gdalbuildvrt? The files all > follow the pattern MCD15A2.A2002185.h14v10.005* On Linux, you could try : for i in MCD15A2.A2002185.h14v10.005*; do echo HDF4_EOS:EOS_GRID: \"$i\":

Re: [gdal-dev] gdalbuildvrt, gdal_translate, and MODIS HDF files

Even: Thanks: how would I "wildcard" this into a gdalbuildvrt? The files all follow the pattern MCD15A2.A2002185.h14v10.005* --j On Sat, Apr 30, 2011 at 11:26 AM, Even Rouault wrote: > Le samedi 30 avril 2011 17:34:28, Jonathan Greenberg a écrit : > > GDALers: > > > > I have recently come acr

Re: [gdal-dev] gdalbuildvrt, gdal_translate, and MODIS HDF files

Le samedi 30 avril 2011 17:34:28, Jonathan Greenberg a écrit : > GDALers: > > I have recently come across the mosaicking magic that is 1) build a vrt > usin gdalbuildvrt and then 2) gdal_translate the vrt to whatever format I > want -- I'm noticing this is a crazy-fast way to do mosaicking compare

[gdal-dev] gdalbuildvrt, gdal_translate, and MODIS HDF files

GDALers: I have recently come across the mosaicking magic that is 1) build a vrt usin gdalbuildvrt and then 2) gdal_translate the vrt to whatever format I want -- I'm noticing this is a crazy-fast way to do mosaicking compared to some other techniques. My current issue is that I have a set of MOD

Re: [gdal-dev] gdalbuildvrt

Aníbal, Have you tried opening the .vrt file with a text editor? For each source .tif there should be three entries in the .vrt file (one per band). What does gdalinfo source.tif say? -marius On Fri, 2011-02-04 at 11:41 -0200, Aníbal Pacheco wrote: > On 02/03/2011 04:59 PM, Frank Warmerdam wrot

Re: [gdal-dev] gdalbuildvrt

On 02/03/2011 04:59 PM, Frank Warmerdam wrote: On 11-02-03 01:30 PM, Aníbal Pacheco wrote: Hi, I'm using gdalbuildvrt to produce a virtual raster layer which can then used in Mapnik and its ogcserver(WMS), everything works except that the result image is black & white and with a very poor resolu

Re: [gdal-dev] gdalbuildvrt

On 11-02-03 01:30 PM, Aníbal Pacheco wrote: Hi, I'm using gdalbuildvrt to produce a virtual raster layer which can then used in Mapnik and its ogcserver(WMS), everything works except that the result image is black & white and with a very poor resolution. The 2 source tif files used in this test w

[gdal-dev] gdalbuildvrt

Hi, I'm using gdalbuildvrt to produce a virtual raster layer which can then used in Mapnik and its ogcserver(WMS), everything works except that the result image is black & white and with a very poor resolution. The 2 source tif files used in this test were both colored with a good resolution. A

Re: [gdal-dev] [GDALBUILDVRT]Syntax to do tiles

Selon Tacot : gdalbuildvrt is aimed at building a single dataset from a mosaic of tiles. You just want to do the contrary. You were on a better track the other day when you were exploring gdal_retile. Generally the syntax for GDAL utilities is there : http://gdal.org/gdal_utilities.html > > Hi >

[gdal-dev] [GDALBUILDVRT]Syntax to do tiles

Hi I would like to reshape a ECW pictures in several tiles. Would it be possible to translate ECW in VRT; cut the VRT in tiles, and re-translate all VRT in ECW? And if it's possible, what are the syntax for those commands? Thanks -- View this message in context: http://osgeo-org.1803224.n2.nab

Re: [gdal-dev] gdalbuildvrt absolute path work, relative paths do not work

I see . I will try again after first changing that to. I did not know about relativeToVRT. Thank you very much. Greg On Jan 5, 2010, at 7:04 PM, Even Rouault wrote: > Greg, > > I doubt this is QGIS related, because QGIS has no idea of what is inside the > VRT itself ! So you should be able to

Re: [gdal-dev] gdalbuildvrt absolute path work, relative paths do not work

Greg, I doubt this is QGIS related, because QGIS has no idea of what is inside the VRT itself ! So you should be able to reproduce only with gdal utilities. A gdalinfo -checksum on the VRT would emit an error message and output 0 as the checksum value if he cannot find the source rasters. Yo

[gdal-dev] gdalbuildvrt absolute path work, relative paths do not work

I am running the 31 Dec 2009, Qgis version 1.4.0 Enceladus, code revision 12644, compiled for Mac OS X 10.6, downloaded from http://www.kyngchaos.com The problem I am having is that while files created by GDAL 1.6.3, released 2009/11/19 gdalbuildvrt that include in the .vrt file absolute paths w

Re: [gdal-dev] gdalbuildvrt -init 255

The black image shows the result of the gdalbuildvrt. Please note the large black areas near the western edge of the canvas, which are created as a result of the gdalbuildvrt, and not being able to specify -init 255 for a white canvas. The white image shows how it would look if I could pass -ini

Re: [gdal-dev] gdalbuildvrt -init 255

Even Rouault a écrit : Well, actually, I can propose a 3rd solution that should work with any recent GDAL version to produce a white & small raster. 1) Copy your source.vrt as white.vrt 2) Add a 255 line after each 3) Remove all existing content So basically you get something as simple as

Re: [gdal-dev] gdalbuildvrt -init 255

Greg Coats a écrit : I do not think I want the black, opaque areas that gdalbuildvrt is making up for areas where there is no imagery to become transparent and remain black, I want them to be white and opaque. Surely, there are many places in the RGB images where one or more bands is already s

Re: [gdal-dev] gdalbuildvrt -init 255

I do not think I want the black, opaque areas that gdalbuildvrt is making up for areas where there is no imagery to become transparent and remain black, I want them to be white and opaque. Surely, there are many places in the RGB images where one or more bands is already set to the value 255, an

Re: [gdal-dev] gdalbuildvrt -init 255

Greg, I don't think the issue is really about black or white, but more about setting nodata appropriately. Basically, if I've well understood your needs, you want to make some black padding in images transparent. Assuming that your imagery is RGB, you could try adding -srcnodata 0 to the gdal

[gdal-dev] gdalbuildvrt -init 255

By default, gdal_merge.py starts by creating an output image with all black pixels, and then replaces these black pixels with pixels from the images being read in. Passing to gdal_merge.py -init 255 pre-initializes the output image to all white, instead of all black, pixels. Similar to gdal_merg

Re: [gdal-dev] gdalbuildvrt save relative paths

Greg, I already answered to the question in the very same thread you're refering to. The conclusion is that gdalbuildvrt already saves relative paths in most cases where it makes sense. See my post : http://lists.osgeo.org/pipermail/gdal-dev/2009-October/022358.html. On Oct 14, 2009, at 1

Re: [gdal-dev] gdalbuildvrt save relative paths

On Oct 14, 2009, at 12:40 PM, Greg Coats wrote: How does one specify that gdalbuildvrt save relative paths, rather than absolute paths? On Oct 14, 2009, at 12:59 PM, Jürgen E. Fischer wrote: Looks like that isn't supported directly yet. Since Qgis supports saving relative paths, it would

Re: [gdal-dev] gdalbuildvrt save relative paths

Selon Greg Coats : > Thanks for that info. > What is the date of the r17818 code? 10 minutes ago : http://trac.osgeo.org/gdal/changeset/17818 > > On Oct 14, 2009, at 2:17 PM, Even Rouault wrote: > > > I've fixed that in trunk r17818. > > ___ gdal-dev

Re: [gdal-dev] gdalbuildvrt save relative paths

Selon "Jürgen E. Fischer" : Greg, you were not enough specific to understand what when wrong for you. I'd expect an example of the exact gdalbuildvrt command line and the current directory from where you tried it, like Jürgen did. Indeed in Jürgen's example, GDAL was not behaving optimally. I've

Re: [gdal-dev] gdalbuildvrt save relative paths

Hi Greg, On Wed, 14. Oct 2009 at 12:40:19 -0400, Greg Coats wrote: >How does one specify that gdalbuildvrt save relative paths, rather than >absolute paths? Looks like that isn't supported directly yet. But I'd try: cd /PATH/TO/THE/VRT/ gdalbuildvrt foo.vrt ../RELATIVE/PATH/TO/THE/DATAS

[gdal-dev] gdalbuildvrt save relative paths

I develop on one computer, and then deploy on other computers. For example, I develop on a desktop computer with many external hard drives, and then deploy on a notebook computer with only an internal hard drive. Additionally, I develop using a desktop computer's external hard drives, and t

Re: [gdal-dev] gdalbuildvrt and nulls again - now from Photoshop

Le Tuesday 14 July 2009 20:50:14 William Kyngesburye, vous avez écrit : > Ah, yes, some of the images don't have nulls, and so I didn't save the > transparency. > > Is it to generate the vrt with mixed rasters? Maybe merge the vrts of > one set of no-null rasters and one set of rasters with nulls

Re: [gdal-dev] gdalbuildvrt and nulls again - now from Photoshop

On Jul 14, 2009, at 1:28 PM, Even Rouault wrote: Le Friday 10 July 2009 21:14:18 William Kyngesburye, vous avez écrit : This time I'm taking some Photoshop-created tiffs that I georeference with a TFW. These tiffs I save with transparency mask (not layers) to handle nulls. Reported by gdal

Re: [gdal-dev] gdalbuildvrt and nulls again - now from Photoshop

Le Friday 10 July 2009 21:14:18 William Kyngesburye, vous avez écrit : > This time I'm taking some Photoshop-created tiffs that I georeference > with a TFW. These tiffs I save with transparency mask (not layers) to > handle nulls. > > Reported by gdalinfo, they appear as: > > Band 1 Block=12775x5

[gdal-dev] gdalbuildvrt and nulls again - now from Photoshop

This time I'm taking some Photoshop-created tiffs that I georeference with a TFW. These tiffs I save with transparency mask (not layers) to handle nulls. Reported by gdalinfo, they appear as: Band 1 Block=12775x5 Type=Byte, ColorInterp=Red Mask Flags: PER_DATASET ALPHA Band 2 Block=12775x

Re: [gdal-dev] gdalbuildvrt and location, Location, LOCATION

Yep, my fault. gdaltindex and gdalbuiltvrt are just fine the way they are... Sorry for the noise, Brent Brent Fraser wrote: Hmm, my gdaltindex creates a DBF with "LOCATION", even though I see that gdaltindex.c sets the default to "location" on line 71: const char *tile_index = "location";

Re: [gdal-dev] gdalbuildvrt and location, Location, LOCATION

Hmm, my gdaltindex creates a DBF with "LOCATION", even though I see that gdaltindex.c sets the default to "location" on line 71: const char *tile_index = "location"; I'll have to step through the code with the debugger... Thanks! Brent Even Rouault wrote: By default, gdaltindex produces a

Re: [gdal-dev] gdalbuildvrt and location, Location, LOCATION

By default, gdaltindex produces a DBF with 'location' (lowercase) and ogrtindex 'LOCATION' (uppercase). So I think I've added this check so that people don't try to use ogrtindex output. The '-tileindex' option is indeed done for those specific cases where non-standard GDAL tileindex must be used

[gdal-dev] gdalbuildvrt and location, Location, LOCATION

I'm trying to use gdalbuildvrt (v1.6.0) to create a vrt file from a tileindex shapefile. The tileindex shapefile was created using gdaltindex, and dbfinfo reports: 1 Columns, 16 Records in file LOCATION string (254,0) Doing: gdalbuildvrt 082h04w2.vrt 082h04w.shp reports: