[gdal-dev] Re: GDAL drivers written in Python

Wed Apr 6 07:09:05 EDT 2011

Hi Knut-Frode,

Il giorno Wed, 06 Apr 2011 11:58:28 +0200
Knut-Frode Dagestad <knutfrodesoppel at hotmail.com> ha scritto:

> Thank you for useful comments, Antonio.
> 
> I agree with you that the ideal thing would be to improve the support
> of GDAL for our satellite data formats of interest. It would be great
> if we could combine efforts and get some momentum on this.
> 
> Several formats (e.g. TerraSAR-X, Envisat ASAR, MERIS and AATSR) are 

OK, we have more or less the same target sensors

> read, but not georeferenced. To my understanding this must be due to 
> bugs in the drivers, as listed in some tickets (#3709, #3160)
> Since Radarsat-2 is georeferenced, I assume it should also be
> possible to georeference other formats which are not projected, but
> have only many GCPs.

I'm not sure to understand. GDAL reads data from the product. If the
product is not geo-referenced you will get data that are not
geo-referenced.

In this case you could use GDAL tools to interpolate data in a
geographic grid but you need to know geographic info and/or parameters
that are stored in the product itself.

In the case of ENVISAT product (but for stripline ones #3160) you
should be able to perform the re-projection e.g. using gdalwarp with
the -tps option (I never tested it personally).

In other cases, such as complex products in slant-range projection, the
problem is by far more complex since you need to know state vectors,
Doppler parameter, etc., and GDAL do not provide, as far a I know, the
possibility to interpolate complex data.

> I tried the Alos/Palsar driver, but it did not seem to work at all.

If you find a bug please file a bug report on the GDAL issue tracker.
Also please set me in cc if the bug is related to SAR products.

> The drivers are also rather minimalistic, and does e.g. not read the
> Doppler Grid of Envisat ASAR. 

Yes, in many cases GDAL reads only a subset of the metadata available
in the product. I could contribute some code for reading additional
metadata but, for example, it is not obvious how ENVISAT Doppler Grids
should be represented in GDAL. Any hint from GDAL developers?

> However, from your answer, I assume it
> is straightforward to read such kind of extra data with supplementary 
> Python code.

No, you should use python code to read metadata directly from the
original product and then you can store them into a GDAL objects using
the SetMetadataIterm, SetGCPs, etc.

In the case of ENVISAT products you could use the pyepr library

http://pypi.python.org/pypi/pyepr

I published recently to read easily any kind of metadata associated to
ENVISAT product.

For HDF5 products you could use pytable or h5py, etc.

In other cases (Radarsat2 and TerraSAR-X) it is just a meter of parsing
an xml file.

ALOS, unfortunately, is in CEOS format so you should implement a CEOS
parser in python or file a feature request to improve the GDAL CEOS
driver (even in this case maybe I can help in some way).

> I am also not sure how easy it is to get support and 
> geocoding for range-projected Single Look Complex data(?)

See the comment above

> Finally, we would also ideally like to have immediate (pre release) 
> support for upcoming satellites such as the ESA Sentinel satellites.

This is very interesting.
Can you point me to product specifications of Sentinel data?

> We consider a solution to use ESA Beam and NEST Java APIs for
> additional readers. But it is getting a bit messy to mix Python, C
> and Java in a multi-platform environment (Linux, Mac and Windows).
> 
> Best regards from Knut-Frode
> 
> 
> 
> On 06.04.2011 10:13, Antonio Valentino wrote:
> > Hi Knut-Frode,
> >
> > Il giorno Wed, 06 Apr 2011 09:51:42 +0200
> > Knut-Frode Dagestad<knutfrodesoppel at hotmail.com>  ha scritto:
> >
> >> Hi,
> >>
> >> Our group is looking at the possibility to use GDAL with Python
> >> bindings for our work with satellite data. One limitation seems
> >> however to be missing/incomplete drivers, as we have no capacity to
> >> implement new drivers in C.
> >
> > It would be interesting to know which are the missing formats and
> > the missing features in existing drivers.
> > I use GDAL Python bindings to read satellite data of SAR missions
> > and I'm very interested GDAL to have the best possible support for
> > this kind of data.
> > So maybe I could help in some way if you provide some more info.
> >
> >> It seems however to me that the Python API allows to create GDAL
> >> Datasets from data which in principle could be read by any non-GDAL
> >> functions, e.g. PyHDF or self-made Python readers.
> >
> > Yes, correct
> >
> >> My question is therefore: is there in principle any important
> >> differences or limitations with datasets created this way, compared
> >> to datasets read with native GDAL drivers?
> >>
> >> Best regards from Knut-Frode
> >
> > GDAL dataset are an abstraction of the real datasets on file so,
> > once created, there is no difference between datasets.
> >
> > IMHO, also depending on the version of GDAL you, python bindings
> > could miss some function that is present in the C/C++ API so
> > creating a new dataset from scratch with the Python API could be a
> > little harder in some very particular case.
> >
> > regards
> >
> 
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Antonio Valentino