Hi Even!
That sounds cool. Is there also a function for retrieving all available
files inside of a ZIP archive?
Kind regards,
Kosta
> -Original Message-
> From: Even Rouault [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 25, 2008 11:41 PM
> To: gdal-dev@lists.osgeo.org
> Subj
Baumann, Konstantin wrote:
Hi Even!
That sounds cool. Is there also a function for retrieving all available
files inside of a ZIP archive?
Kosta,
Programatically this can presumably be accomplished with VSIReadDir()
(aka CPLReadDir()).
char CPL_DLL **VSIReadDir( const char * );
The VSI file
Rouault,
Nice job!
Even Rouault wrote:
--
To read from a .gz file,
--
gdalinfo /vsigzip/path/to/the/file.gz were path/to/the/file.gz is relative or
absolute.
The first time that a .gz file is read, a small .gz.properties file wi
Hi All,
I must extract from a HDF MOD03 file the subdatasets of latitude and
longitude. if I open the image with ENVI, in the list of subdatasets, I
read this list:
Latitude
Longitude
Height
SensorZenith
SensorAzimuth
Range
SolarZenith
SolarAzimuth
Land/SeaMask
gflags
instead the command gdalinfo
Thanks Chris. That did the trick.
Perhaps a quick note could be added to the MEM driver doc page?
Craig
-Original Message-
From: Chris Eustace [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 26, 2008 9:43 PM
To: Craig Miller
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] MEM Dr
Konstantin,
Frank is correct.
Let's suppose you have an archive archive.zip with the following content :
"file1"
"dir1/"
"dir1/dir1file1"
"dir1/dir1file2"
"file2"
(After r15231), the behaviour of VSIReadDir and VSIStatL is similar to the
behaviour of those functions as if archive.zip was a dir
Le Wednesday 27 August 2008 15:58:54 Lucena, Ivan, vous avez écrit :
> Rouault,
>
> Nice job!
>
> Even Rouault wrote:
> > --
> > To read from a .gz file,
> > --
> > gdalinfo /vsigzip/path/to/the/file.gz were path/to/the/file.gz is
> >
Craig
In fact the true reason is that the Create() method begins by trying to
destroy the dataset by calling the Delete() method on it. And that was new to
GDAL 1.5.0.
So when you do some_driver->Create("MEM:::"), the identify method of the MEM
driver detects that "MEM:::" prefix is handles by
Even better. Thanks for the explanation and for submitting a fix.
Craig
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Even Rouault
Sent: Wednesday, August 27, 2008 11:54 AM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] MEM Driver under Vista 64
Craig,
in fact I missed a small line that make my analysis was not exact and my
commit r15232 didn't do what I've advertized...
In r15233, hopefully, ' mem_driver->Create("MEM:::", ...) ' is possible now.
However, be carefull, since it turns out that there's no easy way of avoiding
GDAL to de
Norman,
as I see you are currently editing your proposal and I've not yet made my
comments, here I go.
I would like that the dataset object to be added as the first argument of the
callback, and a void* user_data to be added as the last argument
So the call would be :
ds->RasterIO (GF_Read, x
Hello all,
I continue to have 'segmentation fault' error using gdal-1.5.2 on Ubuntu 8.04
with netcdf files.
I re-compiled gdal from source again, this time with Dylan Beaudette's gracious
help (thanks Dylan!).
I still got segmentation fault.
Below are the last few lines of strace - hope that h
Another question :
how will that work with the block cache mechanism ?
If GDALDataset::RasterIO() is overloaded by the driver, the block cache will
not be used.
Not sure if it is a problem, but that might be interesting to think about
that. I've the feeling that this is a bit linked to how the
Vishal Mehta wrote:
Hello all,
I continue to have 'segmentation fault' error using gdal-1.5.2 on
Ubuntu 8.04 with netcdf files.
I re-compiled gdal from source again, this time with Dylan
Beaudette's gracious help (thanks Dylan!). I still got segmentation
fault.
Below are the last few lines of
On Wednesday 27 August 2008, Vishal Mehta wrote:
> Hello all,
>
> I continue to have 'segmentation fault' error using gdal-1.5.2 on Ubuntu
> 8.04 with netcdf files.
>
> I re-compiled gdal from source again, this time with Dylan Beaudette's
> gracious help (thanks Dylan!). I still got segmentation f
Any chance that you are building GDAL with HDF4 support too ?
http://trac.osgeo.org/gdal/wiki/NetCDF says :
"If building GDAL with both HDF4 and NetCDF support it is necessary to build
the HDF library specially or a dangerous conflict will occur. See the
http://trac.osgeo.org/gdal/wiki/HDF topi
On Wednesday 27 August 2008, Even Rouault wrote:
> Any chance that you are building GDAL with HDF4 support too ?
>
> http://trac.osgeo.org/gdal/wiki/NetCDF says :
>
> "If building GDAL with both HDF4 and NetCDF support it is necessary to
> build the HDF library specially or a dangerous conflict wil
Tamas, Even, all
Thank you for your detailed feedback, I have added a section to the RFC
http://trac.osgeo.org/gdal/wiki/rfc24_progressive_data_support
Which takes each of your questions and provides a response, please comment
further - it is a great help.
I have added the questions to the RF
Norman,
I've seen your answers to my question on the wiki.
So, if the call is not blocking, it means that the callback will not be called
back in the thread of the caller, but by a thread created by the driver. That
might be a problem, as many bad things can happen then if the dataset is
calle
Thanks Dylan and Even,
But does this mean that I would not be able to use gdal for hdf4 if I want
netcdf support?
vishal
-Original Message-
From: Dylan Beaudette [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2008 2:11 PM
To: gdal-dev@lists.osgeo.org
Cc: Even Rouault; Vishal Meh
Even,
I really am not sure how the interface from Adam would work with JPIP - I need
to see an example of this working. Sure I understand how the interface he
proposes could work with the occassional update, but here we are talking many
updates a second and adding the locking, blocking at the
Vishal,
you can use both netcdf and HDF4, but you'll have to uninstall the HDF4
library packaged by Ubuntu, and compile it from the source with the
instructions given in the wiki.
Maybe worth reporting that to Debian/Ubuntu packagers if there's something
they can do to build a compatible HDF4
Norman,
In fact, Adam's proposal reminds me a lot of the asynchronous queue object
from GLIB-2.0
See : http://library.gnome.org/devel/glib/2.12/glib-Asynchronous-Queues.html
I don't know JPIP, but I can image that the driver would start a thread when
AsyncRasterIO() is called. It communicates
Even,
Thanks for the example, that has made it clearer, particularly the mention of a
queue, I like that - also you mention we can avoid the lockbuffer / unlock at
the api level which was my other worry.
Give me a day or so to update the RFC with both approaches - pattern vs pattern
:-). I c
Super,
I removed hdf4 libraries, recompiled gdal. Now it works!
Thanks Even and Dylan!
I'll try to fix the hdf4 bit at some later time, right now i needed netcdf to
work..
I recommend Dylan's notes on this and related topics: they're at
http://casoilresource.lawr.ucdavis.edu/drupal/node/123
Even,
Yes, ".gz" doesn't make sense. Copy&Paste error. I meant ".zip".
Imagine that you are a user and you want to know what is in the ZIP file, what
if you could browse through the ZIP directory, like that:
% gdalinfo /vsizip/myarchive.zip
Subdatasets:
SUBDATASET_1_NAME=/vsizip/myarchive.zip
26 matches
Mail list logo
