GitLab

In the GeoJSON.Point implementation I'm assuming that depth is optional coordinate 3 (difference from sea level) and altitude is optional coordinate 4.

In reporting platform_status.position this probably makes sense. The platform reports it's current position and where available includes both depth and altitude. So if we were getting a USBL status like in SoAR we might get underwater positions as well as surface positions.

In mission_plan.action we typically want to specify max_depth and min_altitude constraints. Then if we want to specify z in an action we're likely to want to specify one but not the other whilst still being bound by those min/max constraints.

So we might say

• descend to 100m (unless you hit min_altitude first)
• descent to 20m from the bottom (unless you hit max_depth first)

With depth and altitude as optional coords 3 and 4 you could specify a target depth and then have a separate min_altitude constraint but you can't easily specify a target altitude with a max_depth constraint (you can't omit coordinate 3) - unless you specify the depth coordinate as well with some by-convention type value.

You could specify a depth deeper than max_depth or use an by-convention infinity value like -1. Both feel a bit ugly.