Update utm-adapter.yaml

[jokalode]

I have elaborated a bit on the traffic information endpoint.

[jokalode]

Regarding the discussion we had in the last meeting on Thu 2024-03-14 about the changes to the traffic information endpoint, I checked the API definitions for remote ID consistent with the ASTM remote ID standard here on GitHub, and can present the following.

For the endpoint /dss/subscriptions, described as "Subscriptions for airspace updates to a volume of interest" the GET request has a parameter called area of type GeoPolygonString.

In the light of this information, I suggest to use the same approach in the /trafficInformation endpoint of the UTM adapter.

[hrishiballal]

Can I request that we keep crewed traffic it is more clear and explicit

[jokalode]

… and incorrect. Traffic information comprises crewed and uncrewed traffic.

[hrishiballal]

Hi @jokalode , thanks for this, the thing is that only crewed information will be present at this interface, for un-crewed information we will use network RID, maybe I am missing something.

[jokalode]

Why make the distinction, when you don't have to?
NB: Network remote ID is pretty useless for receiving traffic information.

[hrishiballal]

I would like to discuss why you think NetRID is useful for traffic information. We have conducted many trials re NetRID for a "limited time" traffic querying. The idea is to use Net RID endpoints to get NetRID traffic information and use this for exclusively crewed traffic. From the beginning the end-points were separated, especially given that many times there is no way to detect small drones, we can create a new endpoint that gives both the traffic information. Lets talk about this in the next call.