Track Measurements

Track measurements are the readings a measurement system captures as it travels along your track: rail wear, track geometry, and the quality indices derived from them. They come from a measurement run — a single pass over the network that produces many readings, each tied to a point on a track. Importing them lets the platform track how your track’s condition changes over time.

At a glance

• Represents: condition readings captured at points along a track during a measurement run
• Body: a JSON array of measurement objects
• Keyed by: the run (runId) plus a location (trackCode and location) at a point in time
• Belongs to: a measurement run, and the track it was recorded against (trackCode)

Tip

The full field list — every wear, geometry, and quality reading — required vs. optional flags, the finalise and delete shapes, and runnable example payloads are in the API Reference under Track Measurement Import.

What it represents

Each measurement records what was measured and where. The “where” is a point along a track: the trackCode it applies to and the location (chainage) along it, captured at a moment in time. It optionally carries the shared geolocation coordinates of the reading.

The “what” is a large set of optional numeric readings: rail wear (horizontal, vertical, and head loss for each rail), track geometry (gauge, cross level, curvature, super elevation, and more), and quality indices derived from them. Every reading is optional. Send only the values your measurement system produces.

Measurement runs

Readings always belong to a run, identified by runId. A run is one logical set of measurements. It’s typically imported in batches — many calls, each carrying part of the run — rather than all at once. The platform accumulates the batches under the run.

Because a run arrives in pieces, it isn’t processed until you mark it complete. After all batches are in, finalise the run to trigger processing. You can finalise a whole run or limit it to a single track. You can also retrieve finalised runs and an audit trail of the import operations recorded against them.

Using it

• Import all the batches for a run, then finalise it. An unfinalised run is not processed.
• A reading is identified by its run, track, and location at a point in time. Re-importing the same reading updates it in place rather than duplicating it.
• To correct or roll back a run, delete its readings by run (optionally limited to a track).
• References that the platform can’t resolve pass request validation but surface later in the job status — see Common Errors.