Another thing to consider is the sensor data for perception or scientific observation, and whether it should go under platform status or a separate status message/topic for on-board sensor payload. Another thing we discussed previously is if this could be made generic or if we should allow customised data/messages for some platforms.
For SoAR, this would be for the pings/targets/feature-of-interests detected by the AUVs.
Should action also be required? I guess the sub can declare its position without that, but I'd think that might be an action in and of itself? declare_pos action or something?
Few comments of little bits I think have been from copy + pasting Only other thing is there's a lot of TODOs, commented out stuff, and just things to come back to later. Are the comments needed in there? And are there issues or notes somewhere of what work is left to do amongst all the TODOs and that?
Can we have a chat about the structure of the messages maybe after stand-up tomorrow? This (I think) is the opposite way round from the schema I've based the prototype on. In the prototype schema every message is an instance of Message and the anyOf defines which payload schema it contains. The idea is that the backbone only deals in messages and passes the message on to the protocol handler which cares about what a message contains.
The model here is there are a bunch of different top-level schemas which each contain the content of the "Message" schema. It may well be fine or even preferable but it doesn't match the thing I've currently got working so it's probably worth a conversation.
[TO DISCUSS] Interesting. Let's discuss this (need to clarify). If we need to change it from this end instead of the core, we should make the changes sooner since the partners will be working with this schemas as a start
Have you tried validating the examples against this schema? I had a go with npm swagger-model-validator which I've used for the javascript adapter in the prototype. So far I've only tried the ecosub platform status message but it's not successfully validating.
Oh wait a minute. openapi-spec-validator is validating that the swagger.json conforms to the open api standard. It's not parsing a messaging and validating that the message conforms to the schema definition. What I'm talking about is validating that the example platform_status.json messages validate against the PlatformStatus definition defined in the schema.
The swagger.json is also curiously different in structure to all out existing APIs. Normally the models are under definitions but here they're under components/schemas and definitions is there but empty.
The other thing Ashley suggested was that rather than define our own schema for anything geographic we just point to the existing GeoJson feature schema: https://geojson.org/schema/Feature.json
We could explicitly require a Point or a BoundingBox or whatever or just point to the parent feature definition.
Point is not very specific - it just has a min of 2 coordinates so we could supply 3=z or even 4=depth+altitude if it were necessary.
The advantage of using Feature would be that the operating area and exclusion zones could be a BoundingBox or they could be a Polygon or even a MultiPolygon. We might not want to allow that complexity for the MVP but it would be good to have it in future - especially given the ultimate goal of the funders.
Actually geojson is being in the planning_configuration message for exclusion_zones and the optional region_of_interest. Would we want to generate a 4-point polygon for each point then?
Would we want to generate a 4-point polygon for each point then
No - We use the GeoJSON feature that represents what we want to draw. So Point for a status update/area of interest, Polygon for an operating area / exclusion zone.
@allore what's the best terminology to distinguish between the type of status message (i.e. from USBL or from the platform itself) vs. source/rx mode of the message (i.e. from acoustics, iridium, or wifi)?
Tricky. Maybe we want a field called something like platform_source: {USBL, Slocum, Ecosub, ALR ...} and other called transmission_mean : {Wifi, acoustics, iridium, starlink ... }
Didn't just validate the FULL mock messages against message_schema because it kept passing even when it should have errors. Decided to break it down in the meantime to ensure it gets validated & does prompt errors (as it should). Added TODO in epic issue card to clean this up for better validation
