File: pp.rst

package info (click to toggle)
python-mpop 1.0.0-1
  • links: PTS, VCS
  • area: main
  • in suites: jessie, jessie-kfreebsd
  • size: 20,516 kB
  • ctags: 1,877
  • sloc: python: 15,374; xml: 820; makefile: 90; sh: 8
file content (155 lines) | stat: -rw-r--r-- 5,137 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
=======================================
 Making use of the :mod:`mpop` package
=======================================

The :mod:`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: 

- *satellite name* will designate the name of the platform, e.g. "noaa" in
   satellite "noaa 19"

- *satellite number* will refer to the number of the satellite in the series,
   e.g. "19" for satellite "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 02 from direct
   readout, regional coverage or global coverage.

Creating a scene object
=======================

Creating a scene object can be done calling the `create_scene` function of a
factory, (for example :meth:`mpop.satellites.GenericFactory.create_scene`).

The reader is refered to the documentation of the
:meth:`mpop.scene.SatelliteInstrumentScene` for a description of the input
arguments.

Such a scene object is roughly a container for :class:`mpop.channel.Channel`
objects, which hold the actual data and information for each band.

Loading the data
================

Loading the data is done through the
:meth:`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 :meth:`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 :mod:`mpop.projector` module.

.. _pyresample: http://googlecode.com/p/pyresample

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 :meth:`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.

.. _documentation: http://pyresample.googlecode.com/svn/trunk/docs/build/html/index.html

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
:mod:`mpop.instruments.visir` module. Some instrument modules, like
:mod:`mpop.instruments.avhrr` or :mod:`mpop.instruments.seviri` overload these
methods to adapt better for the instrument at hand.

For instructions on how to write a new composites, see :ref:`geographic-images`.


Adding a new satellite: configuration file
==========================================

A satellite configuration file looks like the following (here meteosat 7, mviri
instrument):

.. literalinclude:: ../../../satprod/etc/meteosat07.cfg
   :language: ini
   :linenos:

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:

.. literalinclude:: ../../mpop/instruments/mviri.py
   :language: python
   :linenos:


The :mod:`mpop` API
===================

Satellite scenes
----------------

.. automodule:: mpop.scene
   :members:
   :undoc-members:

Instrument channels
-------------------

.. automodule:: mpop.channel
   :members:
   :undoc-members:

The VisIr instrument class
--------------------------

.. automodule:: mpop.instruments.visir
   :members:
   :undoc-members:

Projection facility
-------------------

.. automodule:: mpop.projector
   :members:
   :undoc-members:

Satellite class loader
----------------------

.. automodule:: mpop.satellites
   :members:
   :undoc-members: