Re: [gdal-dev] how to use tiledb datasets on gcs?

conventions for dataset names seems, to me, to hurt long-term maintenance and interoperability. On Fri, Apr 23, 2021 at 7:34 AM Vincent Schut <mailto:sc...@satelligence.com>> wrote: Thanks for confirming, Even. That doesn't look too difficult. I'll give it a try. On 4/23/2

Re: [gdal-dev] how to use tiledb datasets on gcs?

Schut a écrit : On 4/23/21 2:17 PM, Vincent Schut wrote: Hi, how should I specify a tiledb dataset's url that resides on gcs (google cloud storage) to gdal? I've tried several combinations of gcs://, /vsigs/, prefixed with TILEDB:// or not, but no luck. I've looked in the driver source

Re: [gdal-dev] how to use tiledb datasets on gcs?

On 4/23/21 2:17 PM, Vincent Schut wrote: Hi, how should I specify a tiledb dataset's url that resides on gcs (google cloud storage) to gdal? I've tried several combinations of gcs://, /vsigs/, prefixed with TILEDB:// or not, but no luck. I've looked in the driver source, and apparently

[gdal-dev] how to use tiledb datasets on gcs?

uri translation, but no equivalent gcs one? Vincent. -- Vincent Schut Remote Sensing Software Engineer +31 302272679 ~ Maliebaan 22 | 3581CP | Utrecht | Netherlands Linkedin <https://www.linkedin.com/company/satelligence/>~ satelligence.com <http://www.satelligen

Re: [gdal-dev] vrt: prevent opening all source files on open?

On 08/28/2017 01:51 PM, Even Rouault wrote: On lundi 28 août 2017 13:36:36 CEST Vincent Schut wrote: > On 08/28/2017 12:30 PM, Even Rouault wrote: > > Vincent, > > > > http://gdal.org/gdal_vrttut.html should help: > > > > """Some cha

Re: [gdal-dev] vrt: prevent opening all source files on open?

On 08/28/2017 12:30 PM, Even Rouault wrote: Vincent, http://gdal.org/gdal_vrttut.html should help: """Some characteristics of the source band can be specified in the optional SourceProperties tag to enable the VRT driver to differ the opening of the source dataset until it really needs to

Re: [gdal-dev] vsigzip woes with hgt.gz files

On 08/23/2017 04:20 PM, Even Rouault wrote: On mercredi 23 août 2017 16:01:05 CEST Vincent Schut wrote: > Hi all, > > I'm trying to get the /vsigzip/ driver working on srtm .hgt.gz files, > but I don't succeed: > > gdalinfo /vsigzip/N37W105.hgt.gz > ERROR 4: `/v

[gdal-dev] vsigzip woes with hgt.gz files

Hi all, I'm trying to get the /vsigzip/ driver working on srtm .hgt.gz files, but I don't succeed: gdalinfo /vsigzip/N37W105.hgt.gz ERROR 4: `/vsigzip/N37W105.hgt.gz' not recognized as a supported file format. gdalinfo failed - unable to open '/vsigzip/N37W105.hgt.gz'. This is with a

Re: [gdal-dev] Fwd: [OpenJPEG] OpenJPEG 2.2.0 is out ! Faster and safer.

On 08/14/2017 10:49 AM, Even Rouault wrote: On dimanche 13 août 2017 15:57:54 CEST N. Farah wrote: > Great news. Thanks for the work. > > > Any plans to integrate this new version in GDAL ? Well, there's nothing to change in the GDAL source code. The existing JP2OpenJPEG driver will work

Re: [gdal-dev] make install fails

On 03/03/16 11:31, Matthias Kuhn wrote: Hi, I am trying to compile and install gdal in docker (ubuntu 12.04) container with python3 and in a custom prefix (/home/travis/deps), clang-3.6 is used. configure and make run fine, however, make install fails: /bin/bash -pthread -shared -Wl,-O1

Re: [gdal-dev] Fwd: Fwd: OpenJPEG: The Slumbering Giant Awakens

On 01/12/2016 10:10 PM, Aaron Boxer wrote: -- Forwarded message -- From: *Aaron Boxer* > Date: Tue, Jan 12, 2016 at 4:06 PM Subject: Re: [gdal-dev] Fwd: OpenJPEG: The Slumbering Giant Awakens To: armin.bur...@gmx.net

Re: [gdal-dev] build error

On 08/18/2015 07:30 PM, Even Rouault wrote: On Tuesday 18 August 2015 12:00:46 Vincent Schut wrote: Hi, this morning I wanted to refresh my gdal build, so I did an svn update (and later a fresh svn checkout to be sure), but I get an error when make wants to build gdalserver: This might

Re: [gdal-dev] build error

On 08/19/2015 08:18 AM, Vincent Schut wrote: On 08/18/2015 07:30 PM, Even Rouault wrote: On Tuesday 18 August 2015 12:00:46 Vincent Schut wrote: Hi, this morning I wanted to refresh my gdal build, so I did an svn update (and later a fresh svn checkout to be sure), but I get an error when

[gdal-dev] build error

Hi, this morning I wanted to refresh my gdal build, so I did an svn update (and later a fresh svn checkout to be sure), but I get an error when make wants to build gdalserver: make[1]: Entering directory '/usr/local/src/gdal/apps' /bin/sh /usr/local/src/gdal/libtool --mode=link g++ -lsz

Re: [gdal-dev] RFC 58: Removing Dataset Nodata Value

On 05/18/2015 08:37 PM, Sean Gillies wrote: Hi all, In consultation with Even Rouault, I've written up RFC 58. https://trac.osgeo.org/gdal/wiki/rfc58_removing_dataset_nodata_value The gist of it: allowing deletion of a nodata value defined for a dataset, thereby rendering all pixels valid

[gdal-dev] building with libkea should use kea-config --hdfincludes

Hi, I'm building gdal (svn trunk, updated this morning) on a debian (testing) server with libkea (own build). Libkea uses hdf5, and debian put's its hdf5 include files in /usr/include/hdf5/serial. Gdal build fails on libkea with: Entering directory '/usr/local/src/gdal/frmts/kea' /bin/bash

Re: [gdal-dev] building with libkea should use kea-config --hdfincludes

Saw that configure.in uses kea-config --cflags, which only results in the direct kea include dir being included. Here's a patch which uses --includes and --hdfincludes, which seems to work for me (need to run autogen.sh afterwards). Vincent. On 03/31/2015 10:55 AM, Vincent Schut wrote: Hi

Re: [gdal-dev] building with libkea should use kea-config --hdfincludes

Thanks Even, builds fine now. On 03/31/2015 11:13 AM, Even Rouault wrote: Le mardi 31 mars 2015 10:55:52, Vincent Schut a écrit : Hi, I'm building gdal (svn trunk, updated this morning) on a debian (testing) server with libkea (own build). Libkea uses hdf5, and debian put's its hdf5 include

Re: [gdal-dev] gdal trunk compatibility

On 03/03/15 10:26, Even Rouault wrote: Le mardi 03 mars 2015 10:06:51, Vincent Schut a écrit : Hi folks, I'd like to revive this thread a bit, because I'm trying to compile rsgislib (https://bitbucket.org/petebunting/rsgislib, a c++ rs/gis library which links with gdal) against my trunk

Re: [gdal-dev] gdal trunk compatibility

be fixed within gdal, or should it be changed in rsgislib? Thanks for your insights! Vincent. On 12/16/14 11:27, Even Rouault wrote: Le mardi 16 décembre 2014 11:06:14, Vincent Schut a écrit : Folks, I'd like to use gdal-trunk (e.g. 2.0) for all the new features and improvements, but I

[gdal-dev] gdal trunk compatibility

Folks, I'd like to use gdal-trunk (e.g. 2.0) for all the new features and improvements, but I wonder about its compatibility with other software. Is gdal 2.0 supposed to work transparently with libraries/programs that used to link against gdal 1.11, e.g. qgis, postgis, etc.? Reason I ask

Re: [gdal-dev] Does gdal_calc.py not calculate arithmetic with in the same file?

On 07/29/2014 04:04 PM, Cleo Drakos wrote: Thanks for your response. I tried the followings: gcalc = 'C:\\Users\\cleo\\Documents\\gdalpys\\gdal_calc.py' ##I produced second file (b)as the copy of first(a) a = 'D:\\a.tif' b = 'D:\\b.tif' outfile = 'D:\\result.tif' expr = '(A-B)/(A+B)'

[gdal-dev] OT: openev(2) alternative?

Hi list, this is a bit off topic, but I guess I'll have the biggest chance for an answer on this ml... Untill now, I always succeeded in (re)building openev2, but after some recent system upgrades, it fails... I've used openev2 (and openev before that) long as my preferred raster viewer. It

Re: [gdal-dev] OT: openev(2) alternative?

On 06/20/2014 03:39 PM, Joaquim Luis wrote: If you are on Windows and 32 bits is not a (severe) limitation, I think Mirone (http://w3.ualg.pt/~jluis/mirone) satisfies those requisites Ah, sorry, should have mentioned that: I'm on linux (64bit). 32 bit is a limitation anyway, I regularly need to

[gdal-dev] svn trunk: python import error, version says still 1.10.0?

Hi, While trying to upgrade my gdal to svn trunk, I got this python error on import: Traceback (most recent call last): File /home/vincent/src/python/rapideye_smac_002.py, line 24, in module from osgeo import gdal, gdal_array File

Re: [gdal-dev] Tiling and Overviews disappear after compressing with LZW

lzw compression. Best, Vincent Schut. //Ammar ___ 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

Re: [gdal-dev] Tiling and Overviews disappear after compressing with LZW

On 12/05/13 16:39, Vincent Schut wrote: On 12/05/13 16:21, Ammar wrote: Hello list, I am new to GDAL and I have been using the utilities to process and prepare TIFF to create a mosaic in Geoserver. I am expermineting with different compression methods and I have noticed that after

Re: [gdal-dev] gdalwarp integer overflow

On 12/03/2013 04:56 PM, Even Rouault wrote: Hi, do you have many bands and what is their data type ? Because the check for integer overflows does nSrcXSize * nSrcYSize * nWordSize * nBandCount. nSrcXSize * nSrcYSize by itself is 214 659 158. So it means that you have more than 10 bands of Byte

[gdal-dev] gdalwarp integer overflow

Hi, I get the following error (integer overflow) when running gdalwarp on a very large vrt to reproject to a very small tif: gdalwarp -overwrite -t_srs epsg:4326 -te -180 -90 180 90 -ts 36 18 -r near ${YEAR}/world_${YEAR}_sinu.vrt ${YEAR}/world_${YEAR}_ll_overview.tif Creating output file

[gdal-dev] severe memory leak when opening corrupt modis hdf (python bindings)

Hi, when opening a corrupt hdf4 modis product (I've put an example here: http://sarvision.nl/~schut/gdal_corrupt_hdf/MYD09GQ.A2010007.h11v09.005.2010010052202.hdf) with python, there is a severe memory leak (multiple GB!) it is a dataset that gives ERROR 4:

Re: [gdal-dev] severe memory leak when opening corrupt modis hdf (python bindings)

On 10/31/2013 12:29 PM, Vincent Schut wrote: Hi, when opening a corrupt hdf4 modis product (I've put an example here: http://sarvision.nl/~schut/gdal_corrupt_hdf/MYD09GQ.A2010007.h11v09.005.2010010052202.hdf) with python, there is a severe memory leak (multiple GB!) it is a dataset

Re: [gdal-dev] GDAL 1.10 build fails on FreeBSD

On Tue, 03 Sep 2013 14:55:20 +0200 Frank Broniewski b...@metrico.lu wrote: Hi all, I tried updating Gdal to the latest version on my FreeBSD system, but the build fails: snip c postgisrasterdataset.cpp -fPIC -DPIC -o ../o/.libs/postgisrasterdataset.o postgisrasterdataset.cpp: In

Re: [gdal-dev] reprojecting SRTM data

On 08/16/12 11:14, Zoltan Szecsei wrote: Hi, I've downloaded srtm_41_19 both in tiff and ASCII formats. I reproject the tiif image such: gdalwarp -t_srs '+proj=tmerc +lat_0=0 +lon_0=21 +k=1 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs' srtm_41_19.tif srtm_lo21.tif and gdalinfo

Re: [gdal-dev] [gdal_translate] Spatial subset HDF4Image with multiple subdatasets?

On 06/20/2012 02:55 PM, Etienne Tourigny wrote: You could combine them as a multi-band gtiff file for example No, in this case (MOD09GA data) you cannot, because the subdatasets have different resolutions / raster sizes, and datatypes. Imho there is no other way than to subset each subdataset

Re: [gdal-dev] plate caree and EPSG:4326

On 01/30/2012 02:28 PM, Alfredo Alessandrini wrote: Hi, I'm trying to reproject the VGT-P product with the gdal libraries. The metafile is reported below. It's right to assume the EPSG 4326 code as source spatial reference set? Probably, yes. I have always used 4326 for spot vgt products,

Re: [gdal-dev] Covert MODIS Land Temperatures Sinusoidal to Lat Lon

. Last: please CC your replies to the list too (or just send to the list, no need to send to my private address too). Others might know more and want to reply, or might learn from it. And it will appear in internet searches after some time. Best, Vincent. On 11/30/2011 10:26 AM, Vincent

Re: [gdal-dev] Covert MODIS Land Temperatures Sinusoidal to Lat Lon

On 11/30/2011 03:41 PM, elliott wrote: Hello, I have been searching for a way to convert the MODIS Land Temperature data that is in a sinusoidal projection into WSG84 lat/lon but have not found any definitive answers. Any help would be greatly appreciated. I've been using this gdalwarp

[gdal-dev] python bindings: 2x ds.WriteRaster?

Hi list, Remembering a recent message mentioning the existence of both 'ReadArray' and 'WriteArray' on the dataset level of the python swig bindings, I opened up my gdal.py (svn rev. 23438), and found this: There is a ds.ReadAsArray() There is no ds.WriteArray() There are *2* defined

Re: [gdal-dev] python bindings: 2x ds.WriteRaster?

, it is a bit confusing to have 2 definitions. The last one that overrides the first one will be used. But I agree this could be fixed to avoid the confusion. OK, so the last one is the 'valid' one. Good to know. Thank for the reply. Vincent Schut. Cheers, Vincent

Re: [gdal-dev] KMLSuperOverlay in Google Earth 6.1.0.5001

On 11/17/2011 10:36 PM, Roland Duhaime wrote: Has anyone else experienced the latest version of Google Earth (6.1.0.5001) or the G.E. API not loading PNG formatted KMLSUPEROVERLAYs created using gdal_translate? The same KMZ files worked in the past. Yes, I can confirm this. Vincent.

Re: [gdal-dev] empty Gtiff from Python

Tom van der Putte wrote: Hi List, I'm trying to save a numpy array to a GTiff, which should be quite straightforward, considering all the examples available on the web. However, I get an file that is not readable by Qgis, is regarded by ArcMap to have only 0 and gdalinfo displays nothing on

Re: [gdal-dev] help resampling raster to coarser scale

On 08/05/2011 03:57 AM, Etienne wrote: Hi all, I am trying to resample a raster with categorical data (land surface vegetation/cover) from a high resolution (500m) to a coarser resolution. I would like to do something similar to what the GRASS operator r.resamp.stats does, using the modal

Re: [gdal-dev] Gdal2tiles in Gdal18 and creating KMZ files

others had a similar experience here: http://osgeo-org.1803224.n2.nabble.com/gdal-dev-kmlsuperoverlay-nodata-support-td5624321.html Thanks Again, Roland On Fri, Feb 18, 2011 at 2:34 AM, Vincent Schut sc...@sarvision.nl mailto:sc...@sarvision.nl wrote: Roland, not really an answer to your

Re: [gdal-dev] Gdal2tiles in Gdal18 and creating KMZ files

Roland, not really an answer to your question, but note that - with a recent gdal - you can also create kmz by using the kmlsuperoverlay output format, e.g.: gdal_translate -of kmlsuperoverlay infile out.kmz your infile need be a rgb or rgba format (if you want to maintain transparency,

[gdal-dev] gdal_translate -expand rgb incompatible with geotiff COPY_SRC_OVERVIEWS

Hi all, Kind of a corner case, but i was hoping that gdal_translate's -expand option (to expand colorindexed 1-band files into 3-band rgb files) would also copy and expand the overviews when run with the (geotiff specific, I know) create option -co COPY_SRC_OVERVIEWS=YES. It appears to not do

Re: [gdal-dev] gdal swig python's setup.py not python3 compatible

On 12/30/2010 11:39 AM, Even Rouault wrote: I guess my question actually boils down to: how can I specify in the configure phase, which python to use for the bindings? E.g. I have both 2 and 3 on my system, and 3 is the default, but I want gdal to build and install the bindings for 2. Could I

Re: [gdal-dev] gdal_translate -expand rgb incompatible with geotiff COPY_SRC_OVERVIEWS

On 12/30/2010 12:07 PM, Even Rouault wrote: Le jeudi 30 décembre 2010 11:52:34, Vincent Schut a écrit : Hi all, Kind of a corner case, but i was hoping that gdal_translate's -expand option (to expand colorindexed 1-band files into 3-band rgb files) would also copy and expand the overviews when

Re: [gdal-dev] gdal_translate -expand rgb incompatible with geotiff COPY_SRC_OVERVIEWS

On 12/30/2010 12:53 PM, Norman Vine wrote: On Dec 30, 2010, at 6:18 AM, Vincent Schut wrote: On 12/30/2010 12:07 PM, Even Rouault wrote: Le jeudi 30 décembre 2010 11:52:34, Vincent Schut a écrit : Hi all, Kind of a corner case, but i was hoping that gdal_translate's -expand option

[gdal-dev] gdal swig python's setup.py not python3 compatible

Hi, some time ago, Arch linux made the rather bold decision to have python3 as system python default, of course with a /usr/bin/python2 alternative sitting next to it. However, as the /usr/bin/python link is pointing to /usr/bin/python3, gdal's swig python module's setup.py is being called

Re: [gdal-dev] gdal swig python's setup.py not python3 compatible

PM, Vincent Schut wrote: Hi, some time ago, Arch linux made the rather bold decision to have python3 as system python default, of course with a /usr/bin/python2 alternative sitting next to it. However, as the /usr/bin/python link is pointing to /usr/bin/python3, gdal's swig python module's setup.py

Re: [gdal-dev] Issue with python bindings.

further up the chain and also keep a ref to the layer, and so on. Vincent Schut. On 10/26/2010 04:54 PM, Ivan Willig wrote: Thanks Frank. That seems to be the issue. Whats the rule about this how long you should keep a reference. For example this causes the same issue. ds.GetLayer().GetFeature(0

Re: [gdal-dev] Re: gdal_rasterize -tr and -te

utilities, we would undoubtly use it often. Vincent Schut. Hermann ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev

Re: [gdal-dev] tiff with colortable loses alpha values?

band Best regards, Even Even, thanks for the info. I already was afraid it wouldn't... I'll go and write 4band rgba tiffs directly, then. Best, Vincent. Le mardi 28 septembre 2010 16:24:18, Vincent Schut a écrit : Hi, I'm creating a geotiff with colortable using the python bindings, however

Re: [gdal-dev] Erdas 2010 and OpenEV different views

On 09/28/2010 01:40 PM, Ibrahim Saricicek wrote: Hi List, By Erdas Imagine 2010 I've combined 3 bands (by Spectral/Layer Stack Menu). Saved as 32 bit. And by Rescale menu, rescaled to 8 bit. The image is shown the same on Mapserver, QGis, Ossim, OpenEv and different on Erdas Imagine 2010. You

[gdal-dev] tiff with colortable loses alpha values?

Hi, I'm creating a geotiff with colortable using the python bindings, however, the alpha value of the colorentry is lost / always set to 255 (says gdalinfo on the output image). Does gdal/geotiff with colortable not support rbga? Or, what am I doing wrong? Testcase is below: from osgeo

Re: [gdal-dev] kmlsuperoverlay driver

On 09/24/2010 03:52 PM, Frank Warmerdam wrote: Vincent Schut wrote: On 09/23/2010 02:48 PM, Vincent Schut wrote: Hi, I was curious about the new gdal klmsuperoverlay driver (frmts/kmlsuperoverlay). I have installed minizip, and ran make in the frmts/kmlsuperoverlay folder, which

Re: [gdal-dev] kmlsuperoverlay driver

On 09/23/2010 02:48 PM, Vincent Schut wrote: Hi, I was curious about the new gdal klmsuperoverlay driver (frmts/kmlsuperoverlay). I have installed minizip, and ran make in the frmts/kmlsuperoverlay folder, which resulted in a kmlsuperoverlaydataset.o. Now what? How would I incorporate

[gdal-dev] default to 'interleave=band'?

Hi, is there a way to have gdal (utilities and library interfaces, notably python) default to band interleaving instead of pixel interleaving when writing geotiffs? I know this changed some time ago, but I'd rather have the old behaviour as many of my scripts are based on delivering max

Re: [GRASS-dev] Re: [gdal-dev] gdaldem hillshade directions / GRASS r.shaded.relief

On 05/20/2010 01:38 AM, Even Rouault wrote: Hamish, I've taken some time to experiment a bit with GRASS and GRASS behaviour is correct of course, so sorry for the noise. I've finally identified why gdaldem (and initially Matt's hillshade utility) got it wrong. GRASS r.mapcalc atan(x,y)

[gdal-dev] some problem in python bindings

week, if necessary. this is on linux ('Arch') 64 bit, gdal fresh from svn, python 2.6.5, gcc 4.4.3 Regards, Vincent Schut. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Re: Hoe to convert ERDAS imagine(.img) files to ARC info ASCII files viceversa

I've never used C#, mainly use python, but guess the process will be similar. The idea is that you: 1) open your source dataset (the img file) 2) instantiate the arcinfo ascii driver (gdal.GetDriverByName in python to get a driver instance) 3) use the driver instance to create a new file with

Re: [gdal-dev] vrt performance with 1000's of tiles?

FWIW, I've done something similar (worldwide vrt of all cgiar srtm4 tiles), which is working flawlessly and performance is good. However, I am not using it for direct viewing, just to be able to extract arbitrary subsets of specific regions with gdalwarp. If I would think of viewing the

Re: [gdal-dev] help compiling hdf5 option on linux

On 03/19/2010 09:56 PM, John Cartwright wrote: Thanks for suggestions Antonio and Vincent. Unfortunately, neither --with-hdf5=/usr/local/contrib/hdf5-1.8.4/lib nor --with-hdf5=/usr/local/contrib/hdf5-1.8.4/include,/usr/local/contrib/hdf5-1.8.4/lib made any difference. Hmm, then I

Re: [gdal-dev] Raster algebra with Gdal and Python

On 02/02/2010 08:01 AM, Alexander Bruy wrote: Hi again, with your help I've fix problem with integer overflow and now I get correct results. Also I clean up my code for reduce memory usage but problem with large files is remain. I have raster with size 11779*10663 and 5 bands. When I calculate

Re: [gdal-dev] Raster algebra with Gdal and Python

On 01/31/2010 07:40 PM, Alexander Bruy wrote: Hi all I want to write a raster calculator and have two problems with Python and GDAL. My first problem: when calculating a difference between two raster bands I get a wrong results. Raster in ERDAS IMAGINE format (HFA) and bands extracted

Re: [gdal-dev] Fastest vector format for combining shapefiles

Matt Wilkie wrote: I am combining some GIS data where each layer is divided to around thousand separare shapefiles by mapsheets. We are in the same boat. For the moment I'm exploring the approach of aggregrating map sheets, creating super tiles, until we approach the 2gb shapefile limit.

[gdal-dev] TypeError: in method 'Dataset_GetRasterBand', argument 2 of type 'int'

Folks, since some days (I have upgraded both gdal (refreshed from trunk) and numpy (trunk), and maybe even swig) I get swig related errors from the python gdal bindings when passing an element from a numpy array to a gdalpython function that expects an int, like: TypeError: in method

Re: [gdal-dev] memory leak in hdf driver

issue filed as http://trac.osgeo.org/gdal/ticket/3023 Vincent Schut wrote: Hi, I'm afraid I've encountered a memory leak in the hdf driver. Context: because of massive parallel (cluster) processing, I'm reusing a python instance for lots of jobs. Some of these jobs use gdal to read

Re: [gdal-dev] Problem in importing to Google Earth a nitf image converted from a tif image by gdal_translate

--- On Fri, 4/10/09, Vincent Schut sc...@sarvision.nl wrote: From: Vincent Schut sc...@sarvision.nl Subject: Re: [gdal-dev] Problem in importing to Google Earth a nitf image converted from a tif image by gdal_translate To: Cc: gdal-dev@lists.osgeo.org gdal-dev@lists.osgeo.org Date: Friday, April 10

Re: [gdal-dev] Problem in importing to Google Earth a nitf image converted from a tif image by gdal_translate

mohwawang wrote: Hi Roger, gdalinfo gave me only info about coordinates of GCPs but I doubt that are much useful to GE. Any other way (other than using GCP in gdal_translate) to embed the coordinates info to the GeoTIFF file? Mo, I doubt GE will read and use your gcp's. And as there is

Re: [Gdal-dev] how can i get the error msg

mjollnir wrote: It's ok. thanks form your reply. can i know the health status of the image file before process it. You could try opening and reading its contents first? If the file is bad, I'd say you'd probably get an error somewhere while reading it. On the command line I'd do this with

Re: [gdal-dev] Re: gdal_fillnodata error

Wesley Roberts wrote: Hi Vincent and List, You are correct, the library was not in my path and the command you suggested worked perfectly. I think the problem lies in the number of versions of gdal I have installed on my machine. I have a recently downloaded svn version of gdal, gdal 1.5.2 and

Re: [gdal-dev] again .hdf to .tif

Yann Chemin wrote: Hi there, I am using this one right now on Level 2 and 3 MODIS products --- #!/bin/bash mkdir processed for file in *.hdf do SDS_list=$(gdalinfo $file | grep SUBDATASET_.*_NAME.*) for subdataset in $SDS_list do echo

Re: [gdal-dev] gdalnumeric.BandWriteArray gdalnumeric.Int8

use 'Byte' instead of Int8. Gong, Shawn (Contractor) wrote: hi list, I have used datablock.astype(gdalnumeric.Int16) in gdalnumeric.BandWriteArray() Is there a gdalnumeric.Int8 to write an 8-bit band/image? thanks, Shawn

Re: [gdal-dev] Is it possible to hide some ERROR messages?

Daniele, this thread should give you some hints: http://lists.osgeo.org/pipermail/gdal-dev/2003-March/000323.html Regards, Vincent. Tom Kazimiers wrote: Hi Daniele, were to you get those error message? Since GDAL is a library it shouldn't come up with thing like this - at least not errors

Re: [gdal-dev] Problem with image overview creation in GTiff files

brian wrote: by any chance do these tiffs have 4 bands? rgba? In my case (not the original reporter), no. Happens with any number of bands, well, at least with 3 and 7. Datatypes byte, float32 and int16, if I recall correctly. Vincent. brian On Thu, 2008-10-16 at 16:03 -0500, Ozy

Re: [Gdal-dev] Tif file getting larger and larger

Fodder wrote: Ah, dear, so if I want to frequently change values in TIF file, I basically can't use compression as the file will quickly get larger than the uncompressed version. Is this a fair comment? Right. the combination of tiled compression (where a line counts as a tile too) and

Re: [gdal-dev] GSoC GDAL2Tiles: Opacity for Google Maps Overlay, Embedded Google Earth, Tile generation

a lot. I must say I am very interested in a better way to force GE to not antialias raster overlays. Regards, Vincent Schut. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] BuildOverviews (python) going nuts?

Hi folks, is it just me, or is the BuildOverviews function behaving strange on you to? I regularly call someDs.BuildOverviews(AVERAGE, [plist]) on my output datasets (in swig python, that is). Until some time ago (can't tell precisely, have been out of business for some time) this worked find.