Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
backbone-message-format backbone-message-format
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 29
    • Issues 29
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge requests 5
    • Merge requests 5
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Metrics
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Package Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Communications Backbone System
  • backbone-message-formatbackbone-message-format
  • Issues
  • #76

Something went wrong while setting issue due date.
Closed
Open
Created 11 months ago by Dan Jones@danjonOwner
  • New issue

  • Report abuse

  • New issue

  • Report abuse

Should depth and altitude be coordinates?

Open

Should depth and altitude be coordinates?

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.

  1. Oh no!

    You are trying to upload something other than an image. Please upload a .png, .jpg, .jpeg, .gif, .bmp, .tiff or .ico.

    Incoming!

    Drop your designs to start your upload.

Linked issues
0

Related merge requests
1
  • Draft: Resolve "Should depth and altitude be coordinates?"
    !46
    Avatar for Dan Jones
    Avatar for Dan Jones
When this merge request is accepted, this issue will be closed automatically.

  • Dan Jones @danjon created merge request !46 to address this issue 11 months ago

    created merge request !46 to address this issue

  • Dan Jones @danjon mentioned in merge request !46 11 months ago

    mentioned in merge request !46

  • You're only seeing other activity in the feed. To add a comment, switch to one of the following options.
Please register or sign in to reply
0 Assignees
None
Assign to
None
Milestone
None
Assign milestone
None
Time tracking
No estimate or time spent
Due date
None
None
0
Labels
None
Assign labels
  • No matching results
  • Manage project labels
Confidentiality
Not confidential
Not confidential

You are going to turn on confidentiality. Only team members with at least Reporter access will be able to see and leave comments on the issue.

Lock issue
Unlocked
1
1 participant
user avatar
Reference: