Conversation
Elaborated on the traffic information endpoint
|
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 In the light of this information, I suggest to use the same approach in the |
| - geo-zone | ||
|
|
||
| /crewed_traffic_information: | ||
| /traffic_information: |
There was a problem hiding this comment.
Can I request that we keep crewed traffic it is more clear and explicit
There was a problem hiding this comment.
… and incorrect. Traffic information comprises crewed and uncrewed traffic.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Why make the distinction, when you don't have to?
NB: Network remote ID is pretty useless for receiving traffic information.
There was a problem hiding this comment.
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.
2 participants
I have elaborated a bit on the traffic information endpoint.