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

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.

StrutturaJSON

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.

Screenshot from 2024-06-20 10-33-37

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

noi-techpark / bdp-commons

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