Platform access

POST/platform/access

Purpose

Computes access from a platform to every satellite in a constellation. The platform may be stationary, in which case this is ordinary ground-station analysis, or it may move along a timed path.

Moving platforms are what distinguish this from /coverage: the access geometry changes because the satellites move and because the user does.

Request

Parameter	Type	Unit	Default	Required	Description
`constellation_id`	string	n/a	—	Yes	Identifier of an existing constellation.
`platform`	object	n/a	—	Yes	Platform document with a `fixed` or `geodetic_waypoints` trajectory.
`start`	string	RFC 3339 UTC	`2026-01-01T00:00:00Z`	No	Scenario start epoch. Waypoint offsets are measured from this.
`duration_hours`	number	h	`6`	No	Analysis window length.
`step_seconds`	number	s	`60`	No	Time step.
`propagation_model`	string	n/a	`two_body`	No	Propagation model.

Platform document

Fixed site


{
  "id": "s",
  "name": "Site",
  "min_elevation_deg": 10.0,
  "trajectory": {
    "fixed": { "lat_deg": 40.43, "lon_deg": -3.7, "alt_km": 0.6 }
  }
}

Moving platform


{
  "id": "flight-1",
  "name": "Transatlantic flight",
  "min_elevation_deg": 10.0,
  "trajectory": {
    "geodetic_waypoints": {
      "waypoints": [
        { "t_offset_s": 0, "lat_deg": 51.47, "lon_deg": -0.45, "alt_km": 11.0 },
        { "t_offset_s": 21600, "lat_deg": 40.64, "lon_deg": -73.78, "alt_km": 11.0 }
      ]
    }
  }
}

The trajectory field names are abbreviated: lat_deg, lon_deg, alt_km. That differs from the ground-station shape used by /link, which spells out latitude_deg, longitude_deg, and altitude_km.

Both are required within their objects, so a mix-up fails loudly rather than defaulting.

At least two waypoints are required, and the platform moves along great-circle legs between them. Implied leg speeds are sanity-checked, which catches a mistyped t_offset_s.

Example


curl -s -X POST http://127.0.0.1:8080/platform/access \
  -H 'content-type: application/json' \
  -d '{
        "constellation_id": "probe1",
        "duration_hours": 2.0,
        "platform": {
          "id": "s", "name": "Site", "min_elevation_deg": 10.0,
          "trajectory": {
            "fixed": { "lat_deg": 40.43, "lon_deg": -3.7, "alt_km": 0.6 }
          }
        }
      }'


{
  "constellation_id": "probe1",
  "platform_id": "s",
  "start": "2026-01-01T00:00:00Z",
  "duration_hours": 2.0,
  "step_seconds": 60.0,
  "model": "two_body",
  "satellites": [
    {
      "satellite_id": "probe1-s0-p00-sat00",
      "satellite_name": "probe1-s0-p00-sat00",
      "visible_percent": 4.132231404958678
    }
  ]
}

Response elided; one entry per satellite.

Reading the result

The response echoes start, duration_hours, step_seconds, and model, which is the only confirmation that the settings you sent were the settings used.

visible_percent of 4.1 for one satellite sounds poor in isolation. It is normal: a single low Earth orbit satellite is above a fixed site’s mask for only a few minutes per pass, and a two-hour window contains at most one or two passes.

This endpoint reports per-satellite access. It does not report whether the platform had continuous service, which is the question a user actually has.

For that, examine the union of access intervals across all satellites; gaps in the union are the outages. A fleet where every satellite shows 4 percent visibility can still provide unbroken service if the passes interleave.

Step size and short passes

At 60 seconds, a pass shorter than a minute may be missed entirely, and every pass boundary carries up to a minute of error. Low Earth orbit passes at a high elevation mask can be only a few minutes long, so reduce the step when pass timing matters.