GitLab

Closes #47 (closed)

Failed merge and rebase on nested branches. I accidentally overwrote these changes.

changed milestone to %CB-2024W35

added Partner::NOC Project::MAS-DT Status::In Review Weight::2 labels

changed title from refactor: use geojson or separate properties to Resolve "MAS-DT update platform status message"

deleted the 70-refactor-geojson-loading-for-serving-from-nucleus branch. This merge request now targets the 67-mas-dt branch

added 5 commits

• 52334de6 - 1 commit from branch 67-mas-dt
• 238b0027 - refactor: use geojson or separate properties
• 0c045646 - feat: allow position coordinates in either format
• 037f0079 - chore: update example message to current project
• 62416258 - docs: changelog for platform status changes

Compare with previous version

added 7 commits

• 62416258...795b55a6 - 3 commits from branch 67-mas-dt
• d1e33be0 - refactor: use geojson or separate properties
• 04530bff - feat: allow position coordinates in either format
• b77d1bf5 - chore: update example message to current project
• 08779ed2 - docs: changelog for platform status changes

Compare with previous version

I had a thought about this in the OCS seminar. I'm not sure that including depth/altitude as dimensions of the GeoJSON.Points makes sense. Typically the depth and altitude are an either or so [x,y,z1,z2] doesn't make sense because depth z1 isn't equivalent to altitude z2. I wonder if it's better to keep these as separate fields like tolerances rather than coordinates.

Is this different between the platform_status.position and mission_plan.action? So in platform_status.position the depth and altitude should reflect where the platform is (so for a USBL status the position could be at depth) so included in the GeoJSON.Point.coordinates makes sense. In the mission_plan.action they reflect what you're telling the platform to do so the depth and altitude aren't necessarily consistent and it maybe makes more sense to keep them separate?

I'm not sure about this. We could have a chat in office with the ocs folks regarding the best representation of this data. For now, I'd say leave platform_status.position as a geojson point.

I agree. I started changing it and backed out. I've raised it as a separate issue to discuss for later.

Could you add in a depth or altitude field sample -> would be nice to see it

Do you mean a platform status using the old separate field data model? I've left those as is. https://git.noc.ac.uk/communications-backbone-system/backbone-message-format/-/blob/dev/examples/ecosub_adapter/platform_status.json#L23

approved this merge request

merged

mentioned in commit eec6dc80