As single MERIS band (MDS) may contain several bands in BIP format

[korosov]

gdalinfo MER_RR2PNPDK20030809_100609_000022512018_00466_07534_3898.N1 gives (single band output only):

Band 14 Block=1121x1 Type=UInt16, ColorInterp=Undefined

Description = YS, SPM, Rect. Rho- MDS(16)

In fact this band contains three bands: Yellow substance, suspended minerals and rectified reflectance.

GDAL should read these variable in separate bands. E.g.:

Band 14 Block=1121x1 Type=UInt16, ColorInterp=Undefined

Description = YS from MDS(16)

Band 15 Block=1121x1 Type=UInt16, ColorInterp=Undefined

Description = SPM from MDS(16)

Band 16 Block=1121x1 Type=UInt16, ColorInterp=Undefined

Description = Rect. Rho from MDS(16)

General documentation describing MERIS L2 format could be found here: ​http://envisat.esa.int/handbooks/meris/ More specific here, section 11.5.1.7 Data Sets, pages 89-106: ​http://earth.esa.int/pub/ESA_DOC/ENVISAT/Vol11_Meris_5b.pdf

The MERIS Level 2 file could be downloaded from: ​http://www.brockmann-consult.de/cms/web/beam/meris-products or the direct link to the example (29 MB): ​http://www.brockmann-consult.de/beam/data/products/MER_RR__2PNPDK20030809_100609_000022512018_00466_07534_3898.zip

[antonio]

See comment:2:ticket:4141

[antonio]

Fixed in r22702 (source:trunk​ only).

Please note that the L2 flags MDS (3 bytes per sample) has been mapped onto 3 different bands with GTD_Byte type.

[antonio]

No, sorry, this is still not fixed.

[antonio]

OK, it should be now fixed in r22727. The issue regards both MDS 14 and MDS 19 of Level 2 MERIS products that seems to contain two bands not three as stated in the ticket description.

[korosov]

Now all MDS are read. But there are still seem to be problems: gdalinfo MER_RR2PNPDK20030809_100609_000022512018_00466_07534_3898.N1

Band 15 Block=1121x1 Type=Byte, ColorInterp=Undefined

Description = Chl_1, TOAVI - MDS(15)

Band 16 Block=1121x1 Type=Byte, ColorInterp=Undefined

Description = YS, SPM, Rect. Rho- MDS(16) (0)

Band 17 Block=1121x1 Type=Byte, ColorInterp=Undefined

Description = YS, SPM, Rect. Rho- MDS(16) (1)

Band 18 Block=1121x1 Type=Byte, ColorInterp=Undefined

Description = Chl_2, BOAVI - MDS(17)

Band 19 Block=1121x1 Type=Byte, ColorInterp=Undefined

Description = Press PAR Alb - MDS(18)

Band 20 Block=1121x1 Type=Byte, ColorInterp=Undefined

Description = Epsilon, OPT - MDS(19) (0)

Band 21 Block=1121x1 Type=Byte, ColorInterp=Undefined

Description = Epsilon, OPT - MDS(19) (1)

Band 22 Block=1121x1 Type=Byte, ColorInterp=Undefined

Description = Flags - MDS(20) (0)

Band 23 Block=1121x1 Type=Byte, ColorInterp=Undefined

Description = Flags - MDS(20) (1)

Band 24 Block=1121x1 Type=Byte, ColorInterp=Undefined

Description = Flags - MDS(20) (2)

MDS(15) should contain TWO bands: CHL_1 and TOAVI; MDS(16) should contain THREE bands: YS, SPM, Rect. Rho; MDS(17) should contain TWO bands: Chl_2, BOAVI; MDS(20) should contain ONE band: Flags. So this patch closes this ticket but leaves #4142 open.

[antonio]

Hi korosov, currently for bands with data type Byte the number of sub-bnads is computed from the total MDS size. Also I used for the implementation the product specification document ​http://earth.esa.int/pub/ESA_DOC/ENVISAT/Vol11_Meris_5b.pdf.

For example the MDS(15) is documented at pp 100, Table 11.5.1.7.4.3. Description says "Algal I or TOAVI or cloud top pressure pixel #1 - #1121": three possible quantities in or and dataset size is 1121 uc.

Is my interpretation of product specifications wrong?

Regarding flags band I was in doubt if expose it or not.

It contains 24 bits per pixel and if my understanding is correct it is only used in combination with binary masks to retrieve specific MDS properties.

How do you expect it is implemented in GDAL?

I could implement it as a singe band with data type UInt32 but I have some doubts about how to handle the fourth byte and endianess.

[korosov]

Hi Antonio! Yes you are right!

Sorry, only now I understood how it works. When I open a L2 MERIS file in BEAM it creates two different bands out of e.g. MDS(15). And I though it is kept in the file as two independent datasets. However it is only in one dataset: CHL_1 over water, TOAVI - over land.

Regarding FLAGS, I think the UInt32 is the best solution. Bits in the fourth byte should be just zero, endianess should be so that low_pressure_flag is in the zero bit, land_flag is in the 23rd bit. Since it is not crucial I leave the ticket open but set type to 'enhancement'.

What about reading and applying scaling factors? Should I create another ticket for that?

With great gratitude, Anton Korosov

[antonio]

Replying to korosov: [CUT]

Regarding FLAGS, I think the UInt32 is the best solution. Bits in the fourth byte should be just zero, endianess should be so that low_pressure_flag is in the zero bit, land_flag is in the 23rd bit. Since it is not crucial I leave the ticket open but set type to 'enhancement'.

You approach is absolutely reasonable. I'll try to implement it as soon as I can. Maybe It is better to track Flag bands handling in a separate ticket if you agree.

What about reading and applying scaling factors? Should I create another ticket for that?

Also another user asked me for the same feature. Yes please file a new ticket. (Probably it will take me some time so please be patient.)

A possible way to implement the functionality is using an approach similar to the one used in the radarsat2 driver (involving sub-datasets). What do you think about?

[antonio]

Full support for MERIS flag bands has been implemented in r22870. It includes support for

• Level 2 products: one UInt32 flag band
• Level 1B products: two bands
  • Flags: Byte
  • Detector Index: Int16