Request predicted GNSS navigation models for GPS, GLONASS, Galileo, or BeiDou satellite systems.

This service provides predicted navigation models for a certain amount of upcoming days in a
series of LPP messages, each of which covers a specific time interval, as shown in the table below:

Note, these values are based on the current service configuration and may be changed
in future. The validity period of each LPP message is provided in the response, so clients
should rely on that information instead of the values in the table above.

The service returns prediction data for up to 48 hours per request.
Client specifies required GNSS system(s) and the start time for the prediction data
by query parameters 'gps', 'glo', 'gal' and 'bds' for GPS, GLONASS, Galileo and BeiDou
systems, respectively.

To get the first 48 hours of prediction data for a specific GNSS system,
the client can set the corresponding parameter to now, or to the current time as Unix time
or GNSS time in seconds. The first LPP message for the corresponding GNSS system
in the response will have a validity interval that covers this start time,
and the following LPP messages will have consecutive validity intervals that together
cover up to 48 hours of prediction data.

Each LPP message in the response contains predicted navigation models for just one GNSS system.
Each body part in multipart responses corresponds to a single LPP message for a specific
GNSS system and is described with following headers:

• X-Constellation indicating the GNSS system of the message,
  with values gps, glo, gal or bds for GPS, GLONASS, Galileo and BeiDou systems,
  respectively
• X-Validity-Start indicating the validity start time in seconds since Unix epoch
• X-GNSS-Validity-Start indicating the validity start time in seconds since
  corresponding GNSS epoch
• X-Validity-Duration indicating the validity duration in seconds

JSON responses contain the same validity information in the validity field with each LPP message.

To get prediction data for next 48-hour intervals, send follow-up requests.
In order to avoid receiving duplicate LPP messages, set each time parameter
to the validity end time of the last received LPP message for the corresponding GNSS system.
The validity end time can be calculated as the sum of the validity start time and
the validity duration. For simplicity of client implementation, the service sends
the query string with properly set time parameters for the next request for prediction data
in the X-Prediction-Next response header.

For example, suppose the initial client's request is GET /v2/prediction?gps=now&glo=now.
The response contains prediction data for GPS and GLONASS systems,
and the last LPP message for GPS has validity
start time 1772380800 and validity duration 14400, while the last LPP message
for GLONASS has validity start time 1772393400 and validity duration 1800.
The response also contains header X-Prediction-Next: gps=1772395200&glo=1772395200.
The client can calculate new time parameters for each constellation by adding the validity
start times and durations, or simply use the value of X-Prediction-Next header,
to build the next request URL: GET /v2/prediction?gps=1772395200&glo=1772395200.
(This example uses Unix times, but the same logic applies if the client uses GNSS times.
Both the initial and the next request URLs might need additional parameters,
such as lpp or apiKey.)

Repeating this process, the client can get prediction data for the full 14-day period
for GPS and GLONASS systems in 7 requests, and for the full 7-day period for
Galileo and BeiDou systems in 4 requests.