Making use of the mpop
package¶
The mpop
package is the heart of mpop: here are defined the core classes
which the user will then need to build satellite composites.
Conventions about satellite names¶
Throughout the document, we will use the following conventions:
- platform name is the name of an individual satellite following the OSCAR naming scheme, e.g. “NOAA-19”.
- variant will be used to differentiate the same data (from the same
- satellite and instrument) coming in different flavours. For example, we use variant to distinguish data coming from the satellite Metop-B from direct readout (no variant), regional coverage (EARS) or global coverage (GDS).
All the satellite configuration files in PPP_CONFIG_DIR should be named <variant><platform name>.cfg, e.g. NOAA-19.cfg or GDSMetop-B.cfg.
Creating a scene object¶
Creating a scene object can be done calling the create_scene function of a
factory, (for example mpop.satellites.GenericFactory.create_scene()
).
The reader is refered to the documentation of the
mpop.scene.SatelliteInstrumentScene()
for a description of the input
arguments.
Such a scene object is roughly a container for mpop.channel.Channel
objects, which hold the actual data and information for each band.
Loading the data¶
Loading the data is done through the
mpop.scene.SatelliteInstrumentScene.load()
method. Calling it effectively
loads the data from disk into memory, so it can take a while depending on the
volume of data to load and the performance of the host computer. The channels
listed as arguments become loaded, and cannot be reloaded: a subsequent call to
the method will not reload the data from disk.
Re-projecting data¶
Once the data is loaded, one might need to re-project the data. The scene
objects can be projected onto other areas if the pyresample software is
installed, thanks to the mpop.scene.SatelliteInstrumentScene.project()
method. As input, this method takes either a Definition object (see
pyresample’s documentation) or string identificator for the area. In the latter
case, the referenced region has to be defined in the area file. The name and
location of this file is defined in the mpop.cfg configuration file, itself
located in the directory pointed by the PPP_CONFIG_DIR environment variable.
For more information about the internals of the projection process, take a look
at the mpop.projector
module.
Geo-localisation of the data¶
Once the data is loaded, each channel should have an area attribute
containing a pyresample area object, if the pyresample package is
available. These area objects should implement the get_lonlats()
method,
returning the longitudes and latitudes of the channel data. For more
information on this matter, the reader is then referred to the documentation of
the aforementioned package.
Image composites¶
Methods building image composites are distributed in different modules, taking advantage of the hierarchical structure offered by OOP.
The image composites common to all visir instruments are defined in the
mpop.instruments.visir
module. Some instrument modules, like
mpop.instruments.avhrr
or mpop.instruments.seviri
overload these
methods to adapt better for the instrument at hand.
For instructions on how to write a new composites, see Geographic images.
Adding a new satellite: configuration file¶
A satellite configuration file looks like the following (here Meteosat-7, mviri instrument):
The configuration file must hold a satellite section, the list of channels for the needed instruments (here mviri-n sections), and how to read the data in mipp (mviri-level1) and how to read it in mpop (mviri-level2).
Using this template we can define new satellite and instruments.
Adding a new satellite: python code¶
Another way of adding satellites and instruments to mpop is to write the correponding python code.
Here are example of such code: