Resolve "MAS-DT update platform status message"

Closes #47 (closed)

project/soar/swagger.json

             "example": false,
             "type": "boolean"
           },
-          "latitude": {
-            "description": "Latitude (Y-coordinate) in decimal degrees.",
-            "example": 178.2,
-            "format": "float",
-            "type": "number"
-          },
           "localisation_east_error": {

examples/geojson/platform_status.json

+{
+  "header":{
+      "message_ID": "b427003c-0000-11aa-a1eb-bvcdfghjgfdd",
+      "timestamp": "2022-11-16T00:00:00Z",
+      "version": 2,
+      "source": "ecosub_c2",
+      "destination": "soar.planet-ocean.ecosub.ecosub-2.from_platform.platform_status",

formats/planning_configuration.py

 region_schema = {
     "type": "object",
     "properties": {
-        "geometry_coordinates": {
-            "type": "array",
-            "example": [
-                [
-                    [-4.1777839187560915, 50.34173405662855],
-                    [-4.1777839187560915, 50.33820949229701],
-                    [-4.143667777943875, 50.33820949229701],
-                    [-4.143667777943875, 50.34173405662855],
-                    [-4.1777839187560915, 50.34173405662855],
-                ]
-            ],
+        "geometry": {
+            "$ref": "https://geojson.org/schema/Polygon.json",
         },
     },
-    "description": "Using GEOJSON, exact 4-point region (rectangle shaped - 5 points)",
+    "description": "GeoJSON Polygon",
 }
 
 squad_metadata_schema = {

generate_schema_config.py

 import argparse
 import json
 import os
+import re
+import requests
 
 
 # Enable running on domain sub-path
 }
 
 
+def resolve_ref(ref): 
+    """
+    Get schema URL, parse JSON 
+    Return None if either fails
+    """
+    try:
+        res = requests.get(ref)
+        if res.status_code == 200:
+            return res.json()
+        else: 
+            return None
+    except (json.JSONDecodeError, ValueError):
+        return None
+        
+
+def rename_ref(ref): 
+    """
+    Convert remote ref URL into a name that can 
+    be used for a local ref in the schema 
+    Remote the URL scheme and replace / with .
+    """
+    # remove url scheme
+    deschemed = re.sub(r"^[htps]*\:*[/]{2}", "", ref)
+    # replace / with . since the name will be in a path
+    return re.sub(r"[/]", ".", deschemed)
+
+
+def nested_replace(source, key, value, replace_with):
+    """
+    Find all instances of a key value pair in a nested 
+    dictionary and replace the value with replace_with
+    """ 
+    for k,v in source.items():
+        if k == key and v == value:
+            source[k] = replace_with
+        elif type(v) is list:
+            for item in v:
+                if type(item) is dict:
+                    nested_replace(item, key, value, replace_with)
+        if type(v) is dict:
+            nested_replace(v, key, value, replace_with)
+
+
+def inject_schema(schema, remote_ref):
+    """
+    Given a parent schema and a remote ref
+    
+    1. get the remote ref schema
+    2. create a local reference name (without path separators)
+    3. insert into components.schemas 
+    4. replace remote references with local references 
+
+    
+    returns True if resolved and injected
+    """ 
+    local_name = rename_ref(remote_ref)
+    local_ref = f"#/components/schemas/{local_name}"
+    ref_schema = resolve_ref(remote_ref)
+    if (ref_schema is not None):
+        nested_replace(schema, "$ref", remote_ref, local_ref)
+        schema["components"]["schemas"][local_name] = ref_schema
+        return True
+    else: 
+        return False    
+
+
+def import_remote_refs():
+    """
+    inject the following remote refs into the schema 
+    and replace the remote refs with local refs
+
+    returns True if all schemas resolved and injected 
+    """
+    ref_imports = [
+        "https://geojson.org/schema/Feature.json",
+        "https://geojson.org/schema/FeatureCollection.json",
+        "https://geojson.org/schema/LineString.json",
+        "https://geojson.org/schema/Point.json",
+        "https://geojson.org/schema/Polygon.json",
+    ]
+
+    return all([
+        inject_schema(swagger_config, ref)
+        for ref in ref_imports
+    ])
+
+
 def configure_flask(swagger_config):
     """
     Setup a flask app, load flasgger
 
 
 if __name__ == "__main__":
+    import_remote_refs()
+    
     # Parse script args
     config = get_options()
 

requirements.txt

 Flask
 flask-restx
 flasgger
+requests

[Trishna Saeharaseelan]

We should discuss some of these fields that probably aren't useful/needed outside of soar

[Trishna Saeharaseelan]

I know this is just an example, but would be nice to have a mas-dt.x.x.x instead of soar.x.x.x in "destination"

[Dan Jones]

Agreed. Will do.

[Trishna Saeharaseelan]

Approved with small recommended update to example

[Victor Darvariu]

A few comments from my side:

1. On the new waypoint field: this is intended to report the next waypoint that will be followed, right? In the mission_plan message we aim to specify a list of waypoints, with the first one being the planner-derived "clever" waypoint, and the rest being backups. Do we maybe want to report back this entire list of waypoints instead? I don't think it's necessarily needed, but perhaps we want to be consistent.
2. Given that we will allow changing parameters with the instruction_set messages, perhaps we should also report back the values of these parameters in the status messages after the dive (in case changing them might have failed for some reason?). Maybe this would need to be handled in a different issue.

[Dan Jones]

1. The waypoint field in the platform status should contain the target point that the slocum is currently trying to navigate towards. So if you were to send a new plan but that new plan failed to transmit that field would tell you that the slocum performed the last dive based on the previous instructions.

2. We're having a think about how to manage communicating the parameters in the instruction set. So the sbd/tbd data will tell you which parameter values the slocum was operating under. What we need to figure out is how you know what parameter values the instruction set contains. You could decode and parse the ma files but I'm wondering whether we can populate those as part of the instruction set definitions so you have a list of the fixed parameters set by those files.

You would still have to check whether the dive parameters matched the instruction set you sent (in case the file transfer failed)

[Victor Darvariu]

1. Understood, sounds good.
2. For this one, we would prefer to know the parameter values from the instruction sets and not have to extract them ourselves (essentially the same point as #62 (comment 259744)). Agreed that we'd need to check the match with the dive parameters after the fact.

[Trishna Saeharaseelan]

We should discuss some of these fields that probably aren't useful/needed outside of soar