Additional Pirep Live data during block off/on to be used to improve live maps and/or even near-to-real-time feeds ...

[abuelo007X]

@nabeelio as discussed via PM opening this topic to evaluate the options for this

Today via vmsacars we receive live data following several rules, based on VA configuration mainly on two tables:

• pireps: level, distance, flight_time, fuel_used, score (those get updated during the flight in the same record, until finished)
• acars: several but with a new record, instead of updating the same record

for pireps table it uses acars_update_timer setting to establish the refresh frequency

for acars position reports get updated depending on situation using the position_report_ground, position_report_under_transition, position_report_above_transition settings, and using these settings we can avoid having a huge number of unneeded records

Today live map position is based on the acars position report, but it you want to avoid having too many records, the position_report_above_transition tends to be large, making live maps in the event of updating every 5 minutes for example, not too much live :-)

Seeing some others VA software, normally position on live map tend to be updated more frequently, and while this can be done reducing the position reports interval, this will only increase storage usage of something is not entirely of value.

A proposal is to have the information sent on the acars position report also shared on the pirep table itself or another table with data that will only apply while flight is active

What are the fields needed from the acars position report that be useful?

• lat, lon, heading, altitude_agl, altitude_msl, gs, ias

This can be used like the current pireps live data to update the map data, but as this will use acars_update_timer which in general will be shorter interval, and does not add new record like the acars position report, will provide useful data without the hit of incremental amount of records in the database, and can be used for live map or even any other possible feeds that will get more frequent data update

Thanks

[farfromexact]

I would keep the append-only ACARS history and add a separate current-flight projection rather than duplicating live fields into the completed PIREP row too early.

A practical model is one active-flight state row keyed by flight or PIREP ID, containing the latest latitude, longitude, heading, altitude, ground speed, indicated airspeed, last_seen timestamp, and source sequence. Each ACARS update upserts that row, while the existing ACARS records remain subject to the current retention policy. The live map reads the projection and can mark a flight stale when last_seen exceeds a timeout.

That gives frequent map updates without growing the history table, but it needs clear ownership rules:

• the active projection is authoritative only while the flight is in progress
• completion copies the final snapshot into the PIREP or preserves a link to it
• updates are idempotent and reject older sequence numbers or timestamps
• indexes cover active flight ID and last_seen
• clients can distinguish no report yet from stale last report

For the API, exposing a current-flight endpoint or stream is cleaner than making every consumer understand the ACARS retention tables. I would first agree on field names and units, especially altitude_agl versus altitude_msl and knots versus another speed unit, then add a migration and one live-map consumer before changing all feeds.

[nabeelio]

I'm adding a new table. They're addressing separate concerns