Add Z Information, UAS Info Object #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The edits propose that altitude values are only allowed / used on LineString geographies, and that the maxAltitude value of FlightPart be at least as high as the highest point in the LineString. We also tied the datum of the geography to that of the maxAltitude object; maxAltitude defines the datum for both. Technically coordinate reference systems like WGS84 do define elevation datums, but for the convenience of localized UAS operations it seems more efficient to override that and use the datum defined in the Flight Declaration. We'd also like to start a discussion on multiple datums in the altitude object. This provides flexibility but may complicate future routing and deconfliction efforts; if several drones operating in the same area are using different datums, some translation is involved to deconflict them. Particularly, working from AGL, each operation effectively sets its own zero point based on local topography. AGL is the datum of choice for low altitude operations and we are not suggesting to change that, or to restrict the allowable altitude datums. However, we should give some thought to making a variety of datums play well together once we are deconflicting and routing on the exchange.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The edits propose that altitude values are only allowed / used on LineString geographies, and that the maxAltitude value of FlightPart be at least as high as the highest point in the LineString. We also tied the datum of the geography to that of the maxAltitude object; maxAltitude defines the datum for both. Technically coordinate reference systems like WGS84 do define elevation datums, but for the convenience of localized UAS operations it seems more efficient to override that and use the datum defined in the Flight Declaration.
We'd also like to start a discussion on multiple datums in the altitude object. This provides flexibility but may complicate future routing and deconfliction efforts; if several drones operating in the same area are using different datums, some translation is involved to deconflict them. Particularly, working from AGL, each operation effectively sets its own zero point based on local topography. AGL is the datum of choice for low altitude operations and we are not suggesting to change that, or to restrict the allowable altitude datums. However, we should give some thought to making a variety of datums play well together once we are deconflicting and routing on the exchange.