[gdal-dev] Re: How to get the ENVISAT N1 Main Processing parameters

[Antonio Valentino]

Hi Knut-Frode,

Il giorno Mon, 16 May 2011 09:39:30 +0200
Knut-Frode Dagestad <knutfrodesoppel at hotmail.com> ha scritto:

> Hi RSyaoxin and Antonio,
> 
> I share your interest in these metadata. In addition to the MPH and
> SPH metadata in ASCII-format, Envisat files contain a lot of metadata
> in binary form, e.g. for ASAR:
> http://envisat.esa.int/handbooks/asar/CNTR6-6.htm#eph.asar.asardf.asarrec
> 
> It would probably be too much to ask for the GDAL Envisat driver to 
> import all of this. However, there are some missing metadata which
> are of special importance:
> 
> - the calibration factors, which RSyaoxin mentions
> - the incidence angles: 
> http://envisat.esa.int/handbooks/asar/CNTR6-6-9.htm#eph.asar.asardf.asarrec.ASAR_Geo_Grid_ADSR
> 
> Both of this is necessary to be able to calibrate the data, and hence
> to be able to make any geophysical calculations from them.
> It would be really nice if the GDAL Envisat driver could be updated
> to read this as well, and most users would not need to rely on (or
> create) external software.
> 

From a practical point of view it should be relatively easy to
implement this feature using a lower level library like the libepr-api.
I could manage to do it in a relatively short time.

Unfortunately, apart from other considerations, the solution is not
acceptable since libepr-api is GPL3.

An alternative solution is to write from scratch the routines for
decoding of ENVISAT records but this is would require a larger effort.

Again I could try to do it but I would like to receive some sign of
interest in this feature from GDAL developers before starting to code.

> The incidence angles are stored in a small grid at the same size as
> the GCP´s, (order of 100 elements), which does not fit very nicely
> into the GDAL datamodel - it would probably have to be stored as a
> list of metadata strings.
> 
> Best regards from Knut-Frode
> 

Yes, it is indeed a problem. My feeling is that the currant trend is
keeping metadata as flat and simple as possible.

> 
> On 15/05/2011 18:18, Antonio Valentino wrote:
> > Hi RSyaoxin,
> >
> > Il 15/05/2011 14:46, RSyaoxin ha scritto:
> >> Hi,I want to calibration the ENVISAT ASAR DATA(.N1 Format). I need
> >> to get it's main processing parameters,such as
> >> calibration_factors[0].ext_cal_fact[0],first_line_tie_point_angles[0-10],and
> >> I wrote: CString
> >> sDomain=m_pDataset->GetMetadataItem("MAIN_PROCESSING_PARAMS_ADS_CALIBRATION_FACTORS[0].EXT_CAL_FACT[0]");but
> >> I can't get result.
> >> However, "CString
> >> sDomain=m_pDataset->GetMetadataItem("SPH_FIRST_MID_LAT")" is
> >> right.That's Why?How should I go to get necessary information? I
> >> turn to Anybody who once did this job for some advice. Thank you!
> >> Kind regards.
> >>
> >
> > It seems that the envisat driver do not extracts all metadata from
> > all ENVISAT records.
> > It just exposes MPH, SPH and GCPs
> >
> > http://www.gdal.org/frmt_various.html#Envisat
> >
> >> From my point of view it would be very useful to be able to have
> >> access
> > to a richer set of metadata from GDAL (at east for SAR products).
> >
> > If you are only interested in ENVISAT then you could give a try to
> >
> > https://github.com/bcdev/epr-api
> >
> > that give you full access to the ENVISAT products eve if, IMHO, it
> > is not so handly as GDAL for imagery IO.
> >
> > Maybe you can use them both: EPR for metadata and GDAL for imagery.

best regards

-- 
Antonio Valentino