[uss_qualifier/scenarios/utm/dss/subscription_interactions] Add test of requirement DSS0210,A2-7-2,4c #597
Conversation
| The response from a DSS to a valid OIR modification request is expected to contain any relevant subscription for the OIR's extents. | ||
| This should exclude one of subscriptions created earlier, as it is designed to not intersect with the OIRs being modified. | ||
|
|
||
| If the DSS includes the non-intersecting subscription, it fails to implement **[astm.f3548.v21.DSS0210,A2-7-2,4c](../../../../requirements/astm/f3548/v21.md)**. |
There was a problem hiding this comment.
I am not really sure about this check. I don't see a requirement explicitly excluding non-instersecting subscriptions to be returned. As an example, the current DSS implementation only relies on approximative intersections using geohash s2 cells to identify entities of interest. Therefore relaxing the requirement by making clearer that the check is only on the time dimension would help comprehension.
What do you think @BenjaminPelletier and @mickmis ?
There was a problem hiding this comment.
That's true -- the DSS is guaranteed to return relevant subscriptions and any intersections are necessary relevant, but the threshold for irrelevancy is not standardized. As @barroco says, the InterUSS threshold for relevancy is "same s2 cell", but that's not related to a standard requirement.
We could perhaps specify that the two areas must be separated enough to not be relevant to each other in our description of the resources which puts the burden on the test designer to provide appropriate test data. But, "A implies B" being true does not mean "not A implies not B" is true, and the requirement is "notifications for the subscription are triggered when intersecting entities are [...] modified", so I'm not sure how this requirement would apply in the case when notifications are not triggered when intersecting entities are not modified -- it seems like we would at least need further explanation, and perhaps application of a different requirement as well.
There was a problem hiding this comment.
Indeed I agree with you @barroco @BenjaminPelletier. Given this I'd propose that for this PR I remove this check altogether, and if we deem necessary to test this further, we track this with a new issue on GitHub?
There was a problem hiding this comment.
Sounds good to me. Please proceed and open an issue referencing this thread.
There was a problem hiding this comment.
For reference, relevant operational intent is defined in the standard, section 3.2.36, and includes the concept of Close proximity for 3D extents.
mickmis
force-pushed
the
sub-oir-interactions-7274c
branch
from
4cbe79a to
6ff6916
Compare
mickmis
force-pushed
the
sub-oir-interactions-7274c
branch
3 times, most recently
from
321b095 to
86c37b6
Compare
mickmis
force-pushed
the
sub-oir-interactions-7274c
branch
2 times, most recently
from
23d3ded to
8938e0b
Compare
…of requirement DSS0210,A2-7-2,4c
mickmis
force-pushed
the
sub-oir-interactions-7274c
branch
from
8938e0b to
10fd0b0
Compare
Build on top of the Subscription and entity interaction test scenario, extending an existing test case, to add checks for requirement DSS0210,A2-7-2,4c:
This PR builds on top of #588, as such please only review commit 1be30d5 until rebased.rebased.