Hi Knut-Frode, Il giorno Wed, 06 Apr 2011 11:58:28 +0200 Knut-Frode Dagestad <knutfrodesop...@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<knutfrodesop...@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@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Antonio Valentino _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev