As Flight Data data consumer I want an easier JSON structure, to better understand how integrate the data in my application.

[sseppi]

Wile I was looking at the Real Time flight data we offer I noticed that in the JSON structure there is space for some optimizations.

As you can see at the point 1 in the screenshot, the measurement name "tname" is always arrival, even when the data are about a flight that starts from Bolzano. My proposal would be to name the measurement "realTimeFlight" and then change the JSON structure as follows.

Since in future we are planning to have real time data also about flights that are departing and landing not in Bolzano, I would suggest to change the part of the JSON at the point 2 in the screenshot up:

scheduledDepartureTime: ""
expectedDepartureTime: ""
scheduledArrivalTime: ""
expectedArrivalTime: ""

As descibed in the screenshot up, tn the actual version we have only scheduledTime and expectedTime and it refers always to the landing or departing time to or from the airport of Bolzano. In my point of view, this is quite difficult to understand for the data consumer.

scheduledTime: ""
expectedTime: ""

Finally, by checking the data I suspect that expectedTime and scheduledTime are inverted. Since the flight that I used as example had 2 hours of delay, I expect that is the expectedTime that is changing and not the scheduledTime.

The call to get the real time data of the flight described in the screenshots is the following:

https://mobility.api.opendatahub.com/v2/flat/Flight/*/latest?limit=20&where=scode.eq.BQ1943_20JUN24

[sseppi]

@rcavaliere as I mentioned before, this is one oprimization I see for the real time flight data JSON structure.