Re: [gdal-dev] gdal docker with numpy2-compatible python bindings

is free, but my time generally not. -- Vincent Schut Remote Sensing Software Engineer +31 302272679 ~ Maliebaan 22 | 3581CP | Utrecht | Netherlands Linkedin <https://www.linkedin.com/company/satelligence/>~ satelligence.com <http://www.satelligence.com>&

[gdal-dev] gdal docker with numpy2-compatible python bindings

;/usr/lib/python3/dist-packages/osgeo/gdal_array.py", line 10, in     from . import _gdal_array I hoped that the python bindings in the docker image would be compatible with both numpy 1 and 2, but apparently they're not? Would it be possible to create docker images with bindi

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

ividual drivers set their own 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.

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

9, Vincent 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

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 a

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

-> tiledb 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:/

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 characteri

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] vrt: prevent opening all source files on open?

Hi, Is there a way (or: what are the prerequisites) to avoid gdal opening all source files from a vrt on opening the vrt? Context: I have created a large vrt, referencing many tif files. Both the vrt and tifs are remote (using /vsigs/). It works, but opening (e.g. running gdalinfo) is very s

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

[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 .hgt.g

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 -Wl,-Bs

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* mailto:boxe...@gmail.com>> Date: Tue, Jan 12, 2016 at 4:06 PM Subject: Re: [gdal-dev] Fwd: OpenJPEG: The Slumbering Giant Awakens To: armin.bur...@gmx.net Hi Arm

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

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 be

[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 -ljpeg

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 wit

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 hd

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

[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 /us

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) agains

Re: [gdal-dev] gdal trunk compatibility

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 wonder about its compatibility with other software

[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 is

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)' subprocess.

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

On 06/20/2014 04:03 PM, Joaquim Luis wrote: On 20-06-2014 14:45, Vincent Schut wrote: 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

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] 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

[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 from osgeo import gdal, gdal_array File "/usr/lib/python2.7/site-packages/GDAL-1.10.0-py2.7-linu

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] Tiling and Overviews disappear after compressing with LZW

taken, the overviews use the settings from the main dataset, so would also use lzw compression. Best, Vincent Schut. //Ammar ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev

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 th

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

[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: `/data/modis/MOLA/MYD09GQ.005/201

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

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

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 prod

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 s

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, wi

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

how to find and refer to the subdataset name. 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. Bes

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 lin

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

On 11/29/2011 11:57 AM, Even Rouault wrote: Selon Vincent Schut: 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 fou

[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 function

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. Than

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 t

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 c

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

with the same image using gdal2tiles but not with -kmlsuperoverlay. I see 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 mailto:sc...@sarvisi

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 out.kmz your infile need be a rgb or rgba format (if you want to maintain transparency, add '-co

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 optio

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

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 s

[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 d

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

ing configure? (Or even better, build and install it for both pythons in one run...) Thanks, Vincent. Best regards, Even Le mercredi 29 décembre 2010 14:27:09, Vincent Schut a écrit : Oops, wrong conclusion. Seems more complicated than I thought, as there are some python checks in configure t

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

Vincent. On 12/29/2010 02:19 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&#

[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 wi

Re: [gdal-dev] Require Help Transforming into Equirectangular

On 11/30/2010 10:21 PM, ssobieraj wrote: Hello, I'm trying to use FWTools to transform from an arbitrary Datum/Projection pair in an arbitrary format into a Geographic (lat/lon) projection with the WGS84 ellipsoid in GeoTiff format. To do this, I've tried the following: gdalwarp -s_srs Input.

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

, go 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().GetFeat

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

ine 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

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

mask 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 pyth

[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 imp

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. Yo

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 this

[gdal-dev] kmlsuperoverlay driver

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 this into my gdal lib, either internally or as a pl

Re: [gdal-dev] gdal_calc.py

of evolution, however I personally don't feel the code is 'production quality'... Regards, Vincent. Regards, Ivan Vincent Schut wrote: Just fyi: I've been using my own brewn version of a band-math like command line gdal python script for some years now (have sent it to the

Re: [gdal-dev] gdal_calc.py

Just fyi: I've been using my own brewn version of a band-math like command line gdal python script for some years now (have sent it to the gdal list once, like a year ago or something), you might be interested to take a look at the source and compare approaches. I've attached the script with t

[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 perf

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) function

[gdal-dev] some problem in python bindings

tail later next 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

[gdal-dev] gdaldem hillshade directions

Is it just me, or is the result/documentation for gdaldem hillshade off by 90 degrees? While the docs state "azimuth of the light, in degrees. 0 if it comes from the top of the raster, 90 from the east, ..." (so: clockwise from north), I find that a sun azimuth of 0 degrees is west, 90 is sout

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 th

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 entire

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 don't

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

On 03/17/2010 09:22 PM, John Cartwright wrote: Hello All, I'm trying to get 1.7.1 compiled on a 64-bit RHEL 5 server using hdf5-1.8.4-patch1. I have hdf5 and netcdf apparently compiled successfully and have included the following in my configure statement for gdal: --with-hdf5=/usr/local/co

Re: [gdal-dev] Re: Proposal: gdal_muladd.py

On 02/03/2010 01:48 AM, Ivan wrote: Even, That was a little thing that I start years ago. Here is the usage: {{{ # = # Usage Message # =

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 calculat

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 correctly

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

Matt Wilkie wrote: I'm by no way a vector expert, but for this kind of stuff I'd go the postgis way, at least for intermediate storage. I've thought of this but have shied away from it because of the overhead of installing postgis etc. just to get started. Time to get over my shyness perhaps

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. I'v

Re: [gdal-dev] Question about gdal2wktraster

Jorge Arévalo wrote: Hi Vincent, 2009/7/13 Vincent Schut : Hi Jorge, I'm not sure what projection your cea.tif was in (it seems you've not pasted the full wkt output from gdalinfo on cea.tif?), but you say in your message that it is supposed to be UTM. For UTM, it is very easy

[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 'Datase

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

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 and/or save data. In some cases, I saw the m

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

[gdal-dev] memory leak in hdf driver

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 and/or save data. In some cases, I saw the memory use of my python worker processes gr

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

d 1 Block=561x4 Type=Byte, ColorInterp=Red Band 2 Block=561x4 Type=Byte, ColorInterp=Green Band 3 Block=561x4 Type=Byte, ColorInterp=Blue --- On Fri, 4/10/09, Vincent Schut wrote: From: Vincent Schut Subject: Re: [gdal-dev] Problem in importing to Google Earth a nitf image converted from a

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 no

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 g

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 w

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 Sjahput

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

Frank Warmerdam wrote: Ozy Sjahputera wrote: I am trying to create image overviews for a GTiff file using GDALDataset::BuildOverviews. I keep getting various errors such as: ERROR 1: TIFFSetField:VISUAL.tif: Cannot modify tag "Compression" while writing ... writing ERROR 1: TIFFSetField:VIS

Re: [gdal-dev] mask bands howto

o.org/gdal/browser/trunk/autotest/gcore/mask.py Le Wednesday 24 September 2008 16:37:27 Vincent Schut, vous avez écrit : Hi, is there any up-to-date documentation/tutorial available on the recently added mask bands feature? I found http://trac.osgeo.org/gdal/wiki/rfc15_nodatabitmask, but I was hopi

[gdal-dev] mask bands howto

Hi, is there any up-to-date documentation/tutorial available on the recently added mask bands feature? I found http://trac.osgeo.org/gdal/wiki/rfc15_nodatabitmask, but I was hoping more on something like an api tutorial. The doxygen generated stuff all is empty for mask related functions...

Re: [gdal-dev] 8-bit GeoTIFF and transparency over multiple bands

D wrote: I would need to know, if a three band (RGB) 8-bit GeoTIFF can have transparency enabled? No, there would be no way to know the transparency for a pixel if there are only red/green/blue values available. For that you'll need a 4-band (rgba) image. I know that it is possible to enabl

[gdal-dev] small typo in dox for gdal_sieve

Frank, a small typo has slipped into the gdal_sieve.dox file: -4: Four connectedness should be used when determining polygons. That is diagonal pixels are not considered directly connected. This is the default. -4: Eight connectedness should be used when determining polygons. That i

[gdal-dev] Re: GDAL version for reading TerrasarX data

wrote: Hi Vincent, thank you very much for your information. I have compiled GDAL 1.5.0 and also GDAL 1.5.2 but I get a crash with both of them. I have to see if I can identify the reason. This happens just using otbReadImageInfo. Regards Severino On 18 sep, 14:37, Vincent Schut <[EMAIL P

[gdal-dev] terrasar-x driver swaps gcp lon/lat

FYI, the terrasar-x driver assigned the lat of a gcp as its x coordinate, and lon as y, which should obviously by lat -> y and lon -> x. I have created a ticket 2565 which includes a patch. Cheers, VS. ___ g

[gdal-dev] openev weird geoconcept error on opening large raster

Hi lists (sorry for cross-posting, it's an openev question but gdal related and the openev-list is pretty much traffic-less these days, so I decided to also post to gdal-dev...) I'm using openev from fwtools-2.0.6 on linux, and have difficulties opening largish rasters, be it (big)tiff or envi. L

  1   2   >