Requirement for Root Group Bounding Box To Be All Encompassing

[hasel001]

In an email conversation with Mikan, he called attention to a problem concerning the Root Group bounding box.

He said:

1. If transformed (e.g., UTM) data exceed the bounds set forth in the Root Group, then system checks for proper data location will fail.
2. Therefore, the Root Group bounding box must fully encompass any transformed data.
3. Such a change can be totally effected by merely adding guidance in the PS.

My recommendation is as follows:

Modify Table Root group attributes, Rows 6a to 6d, Column Remarks to read, “The values are in decimal degrees. If a projected CRS is used for the dataset, these values refer to those of the baseCRS underlying the projected CRS and must fully encompass the projected data (see Section 10.2.1, Note 3).”

The changed portion is just the insertion of "and must fully encompass the projected data" immediately before the parenthetical reference.

If there are objections to the above change, I would very much like to hear them. If significant debate occurs, perhaps this potential change will wait until the next version. If there is no heartburn, then I am okay incorporating it in 3.0.0 tomorrow (when Metanorma should be fixed).

[PalmBSH]

As Holger Bothien said at one of our PT meetings regarding our question about the bounding box, this is an approximation. Furthermore, it cannot be specified exactly because of the data type. The grid origin and grid spacing are of data type float 64-bit (double precision) and the bounding box float 32-bit (single precision).

This point concerns all PS based on S-100 Part 10c and should be clarified there.

[giumas]

I cannot think of a practical use case where adding "and must fully encompass the projected data" can become an issue. As such, I support the proposed addition.

[rmalyankar]

I should think it would be obvious, but I have no objection to the proposed change.

[hasel001]

Because of the impending requirement to send S-102 to S-100WG for their review, I felt this issue did not have enough time for debate to justify a decision within 3.0.0. As such, I have changed the milestone to 3.1.0, and we can continue this conversation at the next PT meeting, via GitHub, etc.

[DavidGrant-NIWC]

We are asking for consistency in how the bounding boxes / polygons are encoded, particularly when comparing UTM encoded datasets with EPSG:4326 encoded datasets.

• The bounding box is approximate, but it isn't a bounding box if it doesn't fully encompass the object (it's approximate in that it doesn't have to be "tight" to the object, although that is also desired).
• It should be clear what is being bounded:
  • [x] The grid?
  • [ ] The non-filled portion of the grid? Note that S-100 requires that the bounding box optionally provided in the instance group bounds the grid. The CRS matches that of the data: The root group bounding box bounds the data (including fill?). It must be specified in degrees: The instance group domain extent polygon bounds the (non-filled) data. The CRS matches that of the data: The exchange set:

Magenta = bb from root group (EPSG 4326) Blue = bb from instance group (UTM) Orange = fill data

Data extends beyond root group bb:

Fill values extend beyond both bounding boxes: