Support for dynamic geospatial map automated testing

[Brendan-Hillis]

Is your feature request related to a problem? Please describe.
One cannot test dynamic geospatial map restrictions with interUSS automated tests.

Describe the solution you'd like
The currently provided geospatial map automated testing interface is superb at testing static restrictions (e.g. airports, national parks,...). However there are also restrictions which are dynamic in nature (e.g. Temporary flight restrictions (TFRs) in the US, Emergency/Fire feeds in AU) which we cannot test today. These dynamic feeds cannot be incorporated into the test in a similar manner to the static geospatial feature checks since by their nature they are dynamic.

• Initially I believe limiting this scope to geoJSON source would cover the majority of feeds.
• Priority 1 for a homogenous restriction souces (e.g. every geometry results in a block) Notional feature would be to have interUSS consume the authoritative source and for each feature in the feature collection extract the centroid of that geometry/point and use that as a dynamic geospatial feature check.
• Priority 2 for a non-homogenous restriction source (e.g. logic applies to if the geometry is a block/advise/neither) InterUSS could be given the criteria for what parameters equate to a block/advise/neither. Note this would only work if ALL the data required to determine block/advise/neither was within the authoritative source.

Describe alternatives you've considered

• No solutions attempted.

Additional context

• Something to consider is the potential for an acceptable difference between the USS and the authoritative source since these dynamic sources typically come with a minimum refresh period from the regulator (e.g. 15 minute).
• Initially would expect to work with publicly available data sources, but in the future would need to support authentication with private data sources.

[Brendan-Hillis]

Some sample data feeds can be found in the CASA operating rules (specifically Appendix E):

• https://www.pfes.nt.gov.au/incidentmap/json/incidents.json
• https://publiccontent-gis-psba-qld-gov-au.s3.amazonaws.com/content/Feeds/BushfireCurrentIncidents/bushfireAlert.json
• https://emergency.vic.gov.au/public/osom-geojson.json

Nominally it at test execution the test would query these sources for the locations, then use each of those locations to generate a row in the feature check table. Each source would have a unique template for the other parameters (expected_result, restriction_source, restriction_source, description, requirement_ids). The geospatial_check_id would have to iterate based on the number of rows.

[BenjaminPelletier]

Could you describe how the volumes field in a FeatureCheck "row" would be populated? For instance, here is one feature from your first link:

    {
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [
          132.1423914021,
          -14.16812935024
        ]
      },
      "properties": {
        "_category": "fire",
        "_status": "closed",
        "_eventtype": "Grass and Scrub Fire",
        "_location": "EDITH FALLS -, NITMILUK",
        "_dateclosed": "2025-09-26T10:46:03+09:30",
        "_datenotified": "2025-09-24T12:23:01+09:30",
        "_lastupdate": "2025-09-26T10:46:03+09:30",
        "Fire Type": "Grass and Scrub Fire",
        "Location": "EDITH FALLS -, NITMILUK",
        "Status": "Closed",
        "Alert Level": "Advice",
        "Responsible Agency": "NTFRS",
        "Last Update": "26/09/2025 10:46",
        "Notified": "24/09/2025 12:23",
        "Closed": "26/09/2025 10:46"
      }
    }

How would the spatial 3D volume and temporal time bounds be defined for that GeoJSON Feature?

[Brendan-Hillis]

Good Question. I suspect most of the data sources will not provide a full 4D volume, and if they did we would want to potentially change some of the provided values. For the entire feed on a source row by row basis we will want to convert the provided 2D geometry into a fully defined 4D test volume.

Could we consider the user providing a Jinja template which converts each of the source’s feature/row into a geospatial check feature table row or nothing.

[BenjaminPelletier]

To verify my understanding of the issue, would the following approach satisfy the request?

1. Add an additional field to FeatureCheckTableSpecification allowing a test designer to specify the URL of a GeoJSON file + the URL of a script (e.g., Jinja2 template)
   1. The existing table field would become optional, and the new field could be provided instead of table
2. At the time of resource instantiation, retrieve the GeoJSON file and use its contents along with the other information provided by the test designer to generate the FeatureCheckTable.
   1. Each Feature in the GeoJSON would be parsed and provided as an input parameter to the script
   2. The script would be expected to produce text that can be parsed as a JSON object, either null or following the FeatureCheck schema

[BenjaminPelletier]

I believe #1222 meets this need. The basic approach is for the test designer to provide a .jsonnet "script" that will generate a FeatureCheckTable at runtime. The test designer may also specify one or more URLs for resources the "script" needs (like an "incidents" feed) and the uss_qualifier framework will download and parse those resources into objects available to the "script" via extVars. The example dynamically-generated FeatureCheckTable uses just one feed as the source data for its "script", but there is no reason the "script" couldn't fuse multiple sources/feeds when generate the FeatureCheckTable.

This approach places responsibility for generation of/translation to FeatureCheckTable fully in the test designer's responsibility so the test designer can make all the decisions that were previously unclear (e.g., row per Feature, how to construct volume, which Features to skip, etc).

One worry I have is that the documentation for test steps defined via configuration (what existed before) could be very difficult for test participants to troubleshoot when they have a failed check. With this addition of making the test procedure dynamically generated at runtime, I think that validation link of "why are we sure that this check failing necessarily means the requirement was violated" becomes even weaker. This is probably an area for future improvement so please keep us up to date on your practical experience using dynamic tests like these.

I believe this fully addresses the request so I will close the Issue as complete, but please reopen it and add comments if the issue is not fully addressed.