Add ED-269 GeoZone structure

[BenjaminPelletier]

This PR adds an optional field in Constraint details containing fields that are intended to be compatible with the data model specified in section 8 of ED-269.

The results of this change can be seen here. In the Constraint Details section, select the GET operation and then expand the return type for a 200 response. Under constraint.details, there is a new geozone field that contains this new data model.

[BenjaminPelletier]

Last call for comments; as indicated in last week's meeting, I plan to merge this change in the next day or so.

[davidmurphy1152]

Hi Ben. I gave this a review and have 1 question and 1 comment:

AuthorityRequirements:

• Just to confirm - would these parameters emerge as part of the regulatory overlay of the standard? In other words, they are not part of the constraint model but influence who/how/when constraints are generated?

DailyPeriod:

• The constraint model seems to be missing this concept. The time start/end for constraints include date as part of the definition. As such, there's no means to create a recurring constraint (beyond creating numerous singular constraint entities to replicate the recurrence). Was this your intent? (I tend to agree with the approach as it would be a little more intrusive to incorporate this DailyPeriod concept to the existing model.) If so it may be worth confirming this approach with the focus group.

[BenjaminPelletier]

AuthorityRequirements:

• Just to confirm - would these parameters emerge as part of the regulatory overlay of the standard? In other words, they are not part of the constraint model but influence who/how/when constraints are generated?

Yes, I think these would be generated according to regulatory overlays outside the standard. From the standard's perspective, I think our only duty is to provide the data fields in a format that matches ED-269, and how those fields are used is beyond the standard.

DailyPeriod:

• The constraint model seems to be missing this concept. The time start/end for constraints include date as part of the definition. As such, there's no means to create a recurring constraint (beyond creating numerous singular constraint entities to replicate the recurrence). Was this your intent? (I tend to agree with the approach as it would be a little more intrusive to incorporate this DailyPeriod concept to the existing model.) If so it may be worth confirming this approach with the focus group.

Yes, there is no means for an infinitely-repeating periodic constraint in this translation. We can approximate that by having many 4D volumes, one for each repeating instance, but they will not be infinite. Yes, the need to incorporate pure periodic expression and/or infinite repetition would be very intrusive and this change assumes we will not do that. The only thing we strictly lose is the ability for infinite periodic repetition.

[davidmurphy1152]

Thanks for the responses, Ben. I think we're on the same page here.