Updated Arichtecture and Data documentation.

src/site/markdown/architecture/estimation.md

@@ -116,6 +116,18 @@ and Jacobians from the propagator side, calls the measurement methods to get the
 derivatives on the measurements side, and fetches the least squares estimator with the combined values, to be
 provided back to the Hipparchus least squares solver, thus closing the loop.
 
+The `SequentialBatchLSEstimator` class creates an implementation of a sequential batch least squares estimator engine
+to perform an orbit determination based on existing least square results (i.e., state and covariance). When an orbit
+determination has already been estimated and new measurements are given, it is not efficient to re-optimize the whole problem.
+Only considering the new measures while optimizing will neither give good results as the old measurements will not be
+taken into account. Thus, a sequential estimator is used to estimate the orbit, which uses the old results of the estimation
+and the new measurements. The `SequentialBatchLSEstimator` class can also be used in satellite operations when operators
+want to use the estimated covariance and state vector of an orbit determination performed the day before to improve
+the results of the daily orbit determination.
+
+The two batch least squares estimator implementations in Orekit are compatible to work with a `NumericalPropagator`, a
+`DSSTPropagator`, or a `TLEPropagator`.
+
 ### Kalman filter
 
 ![kalman filter overview class diagram](../images/design/kalman-overview-class-diagram.png)
@@ -145,7 +157,7 @@ will be more realistic than a basic constant matrix.
 
 For even more accurate representations, users are free to set up their own models, which could go up to
 evaluating the effect of each force models. This is done by providing a custom implementation of
-`ProcessNoiseMatrixProvider`.
+`CovarianceMatrixProvider`.
 
 ### Estimated parameters
 

src/site/markdown/architecture/forces.md

@@ -59,11 +59,16 @@ The force models implemented are as follows:
   penumbra and no force at all during complete eclipse, and taking attitude
   into account if spacecraft shape is defined,
 
+* Earth Albedo and IR emission force model. Our implementation is based on
+  paper: _EARTH RADIATION PRESSURE EFFECTS ON SATELLITES", 1988, by
+  P. C. Knocke, J. C. Ries, and B. D. Tapley_.
+
 * solid tides, with or without solid pole tide,
 
 * ocean tides, with or without ocean pole tide,
 
-* post-Newtonian correction due to general relativity,
+* post-Newtonian correction due to general relativity with
+  De Sitter and Lense-Thirring terms,
 
 * forces induced by maneuvers. At present, only constant thrust maneuvers 
   are implemented, with the possibility to define an impulse maneuver, thanks 

src/site/markdown/architecture/frames.md

@@ -78,7 +78,7 @@ The user can retrieve them using various static methods: `getGCRF()`, `getEME200
 `getICRF()`, `getCIRF(IERSConventions, boolean)`, `getTIRF(IERSConventions, boolean)`,
 `getITRF(IERSConventions, boolean)`, `getMOD(IERSConventions)`, `getTOD(IERSConventions)`,
 `getGTOD(IERSConventions)`, `getITRFEquinox(IERSConventions, boolean)`, `getTEME()`,
-and `getVeis1950()`.
+`getPZ9011(IERSConventions, boolean)`, and `getVeis1950()`.
 One of these reference frames has been arbitrarily chosen as the root of the frames tree:
 the `Geocentric Celestial Reference Frame` (GCRF) which is an inertial reference defined by IERS.
 
@@ -117,8 +117,8 @@ very small, slightly time-dependent transformations.
 The precession-nutation models for Non-Rotating Origin paradigm available in Orekit are those
 defined in either IERS 1996 conventions, IERS 2003 conventions or IERS 2010 conventions.
 
-In summary, four frames are involved along this path, with various precession-nutation
-models: GCRF, CIRF, TIRF and ITRF.
+In summary, five frames are involved along this path, with various precession-nutation
+models: GCRF, CIRF, TIRF, ITRF and PZ-90.11.
 
 ### Classical paradigm: equinox-based transformations
 

src/site/markdown/architecture/gnss.md

@@ -78,14 +78,14 @@ Several file formats are supported in Orekit.
 ![gnss antenna class diagram](../images/design/gnss-antenna-class-diagram.png)
 
 * SEMParser, which represents a loader for SEM almanac files. This class provides
-  the `GPSAlmanac` used to build the `GPSPropagator`.
+  the `GPSAlmanac` used to build the `GNSSPropagator`.
 
 * YUMAParser, which represents a loader for YUMA almanac files. Such as for the SEMParser,
-  this class provides the `GPSAlmanac` used to build the `GPSPropagator`.
+  this class provides the `GPSAlmanac` used to build the `GNSSPropagator`.
 
 * RinexClockParser for loading station and satellite clock solutions.
 
-* NavigationFileParser, which represents a loader for Rinex navigation files.
+* RinexNavigationParser, which represents a loader for Rinex navigation files.
   The supported versions are from 3.00 to 3.05, all the GNSS constellations are supported.
 
 ### IGS SSR Format
@@ -109,5 +109,5 @@ the image below.
 
 Several classes have been implemented to provide a link between navigation files
 and the specialized orbit propagators for GNSS constellations. These classes,
-are the base classes to build the specialized GNSS orbit propagators.
+are the base classes to build the `GNSSPropagator`.
 

src/site/markdown/architecture/propagation.md

@@ -57,7 +57,7 @@ Each propagator contains a multiplexer that can accept several step handlers.
 Step handlers can be either of `OrekitFixedStepHandler` type, which will be called at regular time
 intervals and fed with a single `SpacecraftState`, or they can be of `OrekitStepHandler` type,
 which will be called when the propagator accepts one step according to its internal time loop
-(time steps durection can vary in this case) and fed with an `OrekitStepInterpolator` that is valid
+(time steps duration can vary in this case) and fed with an `OrekitStepInterpolator` that is valid
 throughout the step, hence providing dense output. The following class diagram shows this architecture.
 
 ![sampling class diagram](../images/design/sampling-class-diagram.png)

src/site/markdown/data/contexts.md

@@ -168,7 +168,7 @@ before any other code that uses Orekit:
 ```java
 // Force initialization of classes with static fields that use the default data context
 Object o = AbsoluteDate.ARBITRARY_DATE;
-o = InertialProvider.EME2000_ALIGNED;
+o = InertialProvider.of(Frame);
 // Prevent further use of the default data context
 DataContext.setDefault(new ExceptionalDataContext());
 ```

src/site/markdown/data/filtering.md

@@ -129,5 +129,3 @@ order):
         ...
 
     }
-
-In this example, the l
\ No newline at end of file

src/site/markdown/data/supported-data-types.md

@@ -74,6 +74,6 @@ the XML format and the columns format.
 | GNSS navigation                                                                          | based on RINEX 2 and 3                        | \*.n[.gz|.Z]                                           | various                                                                                                                                            |
 | GNSS almanach                                                                            | SEM and YUMA                                  |                                                        | various                                                                                                                                            |
 | GNSS real time (navigation, clock...)                                                    | IGS SSR messages, through RTCM and NTRIP      | none (streaming data)                                  | various, sourcetable usually from [BKG](https://products.igs-ip.net/home)                                                                          |
-| laser ranging prediction file                                                            | CPF format                                    | \*.{alm\|al3}[.gz|.Z]                                  | various                                                                                                                                            |
+| laser ranging prediction file                                                            | CPF format                                    |                                                        | various, mainly [CDDIS](https://cddis.nasa.gov)                                                                                                                             |
 | laser ranging data                                                                       | CRD format                                    |                                                        | various, mainly [CDDIS](https://cddis.nasa.gov)                                                                                                    |
 Supported data types