Resolve "Test validating messages with references to GeoJson schema in both JS and python"

Closes #45 (closed)

formats/planning_configuration.py

         },
         "target_waypoint": {
             "$ref": "https://geojson.org/schema/Point.json",
-        }
+        },
     },
     "required": [
         "target_waypoint",
         "region_of_interest": {
             "type": "array",
             "items": {
-              "$ref": "https://geojson.org/schema/Polygon.json",
+                "$ref": "https://geojson.org/schema/Polygon.json",
             },
             "description": "Region of interest for the entire operation",
         },
         "exclusion_zones": {
             "type": "array",
             "items": {
-              "$ref": "https://geojson.org/schema/Polygon.json",
+                "$ref": "https://geojson.org/schema/Polygon.json",
             },
             "description": "Exclusion zones for all platforms",
         },

[Dan Jones]

This is the experiment I did during the design sprint with compiling the geojson schemas into the backbone message format at build time so messages can be compiled against local refs derived from the published geojson schemas.

[Dan Jones]

GeoJSON Point accepts a minimum of 2 coordinates but sets no maximum.

If we use GeoJSON Point to specify lat/long do we want to include altitude/depth and if so do we just have a convention that says [x(long), y(lat), z(depth), a(?)(altitude)] so you can provide points as 2D, 3D, or 4D as required?

Alternatively do we just use GeoJSON Point for lat/long and keep depth/altitude as separate named parameters? Or do we have a 3D Point [x,y,z] with a parameter that says whether z refers to depth or altitude?

[Dan Jones]

Hmm - Importing the individual geographies works OK but for some reason importing the Feature or FeatureCollection schemas fails and I can't immediately see why.

We can probably do without FeatureCollection but I think we need Feature for the primitive list because we want primitives to accept different geometry types.

So far I've removed $id and $schema from the published schemas

I think removing properties that don't alter the structure or validation of the data is probably fine. I might be able to make Feature work with a bit more of that.

If I have to do anything else to make Feature work then I think it needs a different answer.

[Dan Jones]

This is a bug with our current pinned version of openapi-spec-validator and can be fixed by upgrading the package.