Add figure : Bounding box S-102

[JLeDeunf]

I am raising an issue, of a French development team, for clarification regarding the boudingbox and in particular the setting of the eastBoundLongitude and northBoundLatitude values. Since version 2.1.0 it is not specified exactly how these two values can be calculated, so their implementations can be quite free as long as the unit tests associated with the standard are not in place. We therefore propose to add a figure to clarify the geometry of the boudingbox with regard to the meshed product, a picture says more than a thousand words.

This figure is only a first draft and could be improved by indicating for example the numPointsLongitude or other attributes.

[giumas]

I support that the addition of a figure like this because it reduces the space for confusion and misunderstandings.

[RohdeBSH]

Hello,

unfortunately, it's not quite as simple as it's outlined here. But we need some time to prepare, so please stay tuned! We think an explanatory graphic is a good idea.

[RohdeBSH]

Hello everyone,

sorry it took so long. It was unclear to us what you meant. For clarification, there are two BoundingBoxes, which are not identical.

BBOX Root Group

According to the S-102 Ed. 2.1.0 Chapter 10.2 Table 8, items 7a-7d must be specified in decimal degrees of the coordinate system used for the data or, for projected coordinate systems, according to the coordinate system on which the projection is based. See also S-100 Ed. 4.0.0 Part 10c Chapter 10c-9.4 Table 10c-6 Item 7a-7d. The case of BSH is as follows:

• The Data are in the projected coordinate system UTM32N WGS84 (EPSG: 32632).
• It results in the BoundingBox in the root group having to be specified in WGS84 (EPSG: 4326)

BBOX BathymetryCoverage feature instance Group

The coordinates must be specified in the same coordinate system as the data, see S-102 Ed. 2.1.0 Chapter 10.2.4 Table 11 Item 1a-1d. The root group specifies the data coordinate system. See S-102 Ed. 2.1.0 Chapter 10.2 Table 8 Items 4 & 5. According to S-102 Ed. 2.1.0 Chapter 5.2 Table 1, using a projected coordinate system results in different values for the two BoundingBoxes.

That’s all for the BBoxes.

The grid origin is the center of the cell and the position matches to the South-West corner of the BBox in the feature instance group. It said in S-102 chapter 10.2.4 under table 11, but does that make sense? We have highlighted an area in your graphic that is not covered by your BBOX. This area, however, is part of our coverage. You always lose ½ of the GridSpacing in the edge region. This is interesting when the ECDIS has to decide if the S-102 file needs to be loaded or if it's not important for the current ship position. As long as the GridSpacing is small, e.g. 1x1m or 2x2m, this may be irrelevant. But if you use larger GridSpacings, like 50x50m or 100x100m, a lot of area in the BBOX is already missing. Even though there would be information about the area. We don’t know if the statement in S-102 chapter 10.2.4 under table 11 ("This has the effect that gridOriginLongitude and gridOriginLatitude are identical to westBoundLongitude and southBoundLatitude.") is really that good.

We have prepared a graphic illustrating how we currently write the BBoxes. It is important to remember that our data is provided in the projection EPSG:32632.

BSH-BBOX-SVG-SourceFile

[tfilppula]

Hello everyone,

I would like to second what @RohdeBSH brought up about defining the bounding box by using grid center nodes. To me it would make much more sense to use the grid cell (outer-) boundaries, otherwise we will end up indicating gaps in between neighboring S-102 products.

As pictures tell more than a thousand words, I also put up a couple of images trying to clarify this issue. Red squares represent bounding boxes. Small squares with points in center represent S-102 grid cells (different color for neighboring S-102 products). Case 1, Bboxes based on grid cell nodes:

Case 2, Bboxes based on grid cell boundaries:

Considering each cell as areas instead of points would also be in line with S-98 safety contour representation.

[tfilppula]

Should we also clarify how the bounding box is defined? What I mean is that there are different approaches to this question, cell center nodes vs. cell boundaries is discussed above, but there is also the question of do we take No Data / Fill Value cells into account or not?

In the image below there are 4 different approaches to this question:

1. Using grid cell boundaries, taking No Data cells into account (I think this makes most sense)
2. Using grid cell boundaries, only taking cells with depth information into account
3. Using grid cell nodes, taking No Data cells into account
4. Using grid cell nodes, only taking cells with depth information into account

[RohdeBSH]

Very well elaborated. We prefer the first suggestion as well.

[poseiron01]

Yes, very nice Topi! We would also prefer Case 2 where the Bbox is based on grid cell boundaries and the first approach above taking the NoData cells into account. As we mentioned in Monaco we also support the use of Cell area instead of Node. As Topi mentions this is in line with S-98 and how saftey contours are represented(Annex C C-4-1.2).

[JLeDeunf]

Hi, thanks @tfilppula and @RohdeBSH for your input! We also prefer Case 2 where the Bbox is based on grid cell boundaries and the first approach above taking the NoData cells into account.

[hasel001]

To support this agenda item for this week's S-102PT13 meeting, this paper has been uploaded to the official IHO meeting page.

[tfilppula]

I add this image to the issue as it's included in the proposition paper and might help clarifying the underlying issue.

[hasel001]

We discussed this issue during PT13. The Project Team agrees that the topic merits further investigation. SMA (@AnnaWall01 , @poseiron01) will take the lead on investigating this issue with the intent of showing their findings and any related proposals during PT14. It is highly encouraged for all contributors to share relevant information as part of this GitHub Issue. Thank you all for your contributions!

[giumas]

During PT13, we asked whether all the 4 approaches depicted by @tfilppula are valid based on current PS.

[AnnaWall01]

Hi everyone, To continue the work Sweden presented at the last PT meeting, we have, together with Finland, further investigated the impacts of the proposal. For better understanding and clarity, we have split the work into three parts:

Part 1. Impact on related specifications (still waiting for feedback from S-104). Part 2. Node-based to cell area-based product Part 3. Bounding box

The papers are not meant to be seen as a final way to go but rather as a basis for further discussions. As mentioned before, we are hoping that the PT group will contribute to the discussion and bring comments and feedback to the work. We are still looking in to how to solve these issues in practice and we will post more in August, before the upcoming PT14 meeting.

The three parts have been attached as PDF files. Have a nice summer!

//Anna

Part_1_Impact on related specifications.pdf

Part_2_Node-based to Cell area-based product .pdf

Part_3_Bounding box.pdf

[poseiron01]

Updated Part 1 with the comments from S-104PT Part_1_Impact on related specifications_addition.pdf //PO

[AnnaWall01]

In order to try to reach consensus and close this issue during PT14 SMA have added a summary and suggestions for solutions for everyone to comment on.

For part 1. Can we agree and conclude the following:

-The feedback from related specifications and working groups are satisfactory? -No additional related specification and working group should be requested for feedback?

If agreement in the PT group, our suggestion is therefore: To follow the recommendations from the feedback.

[AnnaWall01]

For part 2. With regards to the feedback from part 1, we recommend the following for changing to cell area based products:

In S-102 section 10.2.4. Root BathymetryCoverage, in the BathymetryCoverage feature container group: -Add attribute dataOffsetCode=5 (barycenter) -Use interpolationType=nearestNeighbor -commonPointRule=1-4

Editorial work for section 4. Data Content and Structure. Add something on cell areas. Editorial work for section 7. Data Capture and Classification. Change to cell- by- cell basis.

This is one of (perhaps) many possible solutions. If you have another way of solving this issue, please comment below or at the PT14 meeting.

[AnnaWall01]

For part 3. As per Finlands image, to go for approach no 1.

Add dataOffSetCode=1 into Table 12 BathymetryCoverage feature instance group.

Change definition of the Bbox. Suggestively defined as a rectangle matching the outermost cell boundaries of the S-102. This would also take into account the NoData cells (perhaps even stated explicitly this way) and provide a Bbox in the products CRS. A similar definition could be made for the geographical CRS (WGS84, LL, degrees).

Editorial work for section 5.1. Introduction.

A remaining question on this topic: The connection between Bbox in Root-group and Bbox in BathymetryCoverage feature instance group is unclear. Should the dataOffSetCode also be used in the Root-group?

Again, this is one of (perhaps) many possible solutions. If you have another way of solving this issue, please comment below or at the PT14 meeting.

[AnnaWall01]

For further work:

Create a S-100 maintenance proposal to add a new interpolation type “uniform” = Assign the same value as the data point for the cell in which the point is located. Values on cell boundaries determined by commonPointRule.

[tfilppula]

Closing as completed, 3.0.0 now has a figure (figure 5) depicting S-102 grid structure.