Transboundary coverage, and data overlap

[CHS-LynnPatterson]

An issue was raised at the US Canada Hydrographic Commission related to S-102 data crossing borders. In the ENC world we have an agreement with our US neighbors on how we implement coverage features that meet at the borders, they are trying to determine something similar for S-102, S-104 and S-111.

To date I don't believe there is any rule regarding non-overlapping S-102 data. and I'm not proposing that we implement that, however...

Our S-102 grids align with our S57/S101 cells, and as we know, the vertical datum must align between the ENC and S-102 in order to work together, yet there is no assurance that the datum used on adjacent transboundary ENCs will match, hence overlapping S-102 data may be an issue. and even if the datum is common, determining whose data is used may still be an issue.

Requestion feedback on a way forward for either a method to implement a coverage feature that could align with a border, confirmation that this is not an issue, or another alternative.

If something is required to address this issue, it is recommended that this be addressed post release of edition 3.0, to avoid impacting the timeline.

[tfilppula]

I think domainExtent.polygon could be a solution here, and it is already being worked on by BSH (PR: https://github.com/iho-ohi/S-102-Product-Specification/pull/90, Issue: https://github.com/iho-ohi/S-102-Product-Specification/issues/79).

@RohdeBSH what do you think?

[RohdeBSH]

Thank you @tfilppula ;) Actually, I didn't want to say anything about it because I don't have a solution yet either.

The fact is, it's not just Canada. We (Germany) currently have the same problem with Denmark, and in the future probably also with Poland and the Netherlands. I think it will be the same for most countries. We all have neighboring countries.

I think the domainExtent.polygon can be a solution to the issue. But not in the current implementation variant, as the S-100 prefers. Unfortunately, we are faced with the issue that the domainExtent.polygon cannot map complex polygons (multi-polygons, inner rings). I can't even imagine all the complex situations that arise worldwide... If these restrictions did not exist, I would also prefer the domainExtent.polygon.

At the moment, I see a solution to the issue unfavorably only in the use of the "dataCoverage" attribute on the S100_DatasetDiscoveryMetadata class. This attribute supports GML geometry, i.e. complex polygons. According to S-100, this attribute can be specified as often as desired. According to S-102, even one is mandatory.

I would always use the geometry of the exclusive economic zone (EEZ) as the border between two countries. In cases where two countries are so close to each other that there is no EEZ, you would of course use the territorial border. This means that the "dataCoverage" polygons would be a combination of the actual coverage of the S-102 product and the respective border. In this case, it would not matter if a grid cell overlaps foreign waters, because the "dataCoverage" polygon gives a clear statement as to where the S-102 product is valid. However, another important question is whether the "dataCoverage" polygon follows the boundaries of the grid cells with all nodes. This is a huge amount of data. This raises the question of the performance of the ECDIS systems.

[CHS-LynnPatterson]

The only thing I can think of is to use the border/boundary line as a clipping line for the creation of the surfaces we use to generate our S-102 datasets. We would still have the case where there are disputed boundaries, but at least a much more manageable overlap issue.

Lynn

From: RohdeBSH @.> Sent: Monday, June 3, 2024 9:13 AM To: iho-ohi/S-102-Product-Specification @.> Cc: Patterson, Lynn (DFO/MPO) @.>; Author @.> Subject: Re: [iho-ohi/S-102-Product-Specification] Transboundary coverage, and data overlap (Issue #99)

Thank you @tfilppulahttps://github.com/tfilppula ;) Actually, I didn't want to say anything about it because I don't have a solution yet either.

The fact is, it's not just Canada. We (Germany) currently have the same problem with Denmark, and in the future probably also with Poland and the Netherlands. I think it will be the same for most countries. We all have neighboring countries.

I think the domainExtent.polygon can be a solution to the issue. But not in the current implementation variant, as the S-100 prefers. Unfortunately, we are faced with the issue that the domainExtent.polygon cannot map complex polygons (multi-polygons, inner rings). I can't even imagine all the complex situations that arise worldwide... If these restrictions did not exist, I would also prefer the domainExtent.polygon.

At the moment, I see a solution to the issue unfavorably only in the use of the "dataCoverage" attribute on the S100_DatasetDiscoveryMetadata class. This attribute supports GML geometry, i.e. complex polygons. According to S-100, this attribute can be specified as often as desired. According to S-102, even one is mandatory.

I would always use the geometry of the exclusive economic zone (EEZ) as the border between two countries. In cases where two countries are so close to each other that there is no EEZ, you would of course use the territorial border. This means that the "dataCoverage" polygons would be a combination of the actual coverage of the S-102 product and the respective border. In this case, it would not matter if a grid cell overlaps foreign waters, because the "dataCoverage" polygon gives a clear statement as to where the S-102 product is valid. However, another important question is whether the "dataCoverage" polygon follows the boundaries of the grid cells with all nodes. This is a huge amount of data. This raises the question of the performance of the ECDIS systems.

— Reply to this email directly, view it on GitHubhttps://github.com/iho-ohi/S-102-Product-Specification/issues/99#issuecomment-2145037155, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A54RIRDHASRLTNYSAEOBMI3ZFRMS7AVCNFSM6AAAAABISXPEBGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBVGAZTOMJVGU. You are receiving this because you authored the thread.Message ID: @.***>

[rmalyankar]

I think the domainExtent.polygon can be a solution to the issue. But not in the current implementation variant, as the S-100 prefers. Unfortunately, we are faced with the issue that the domainExtent.polygon cannot map complex polygons (multi-polygons, inner rings). I can't even imagine all the complex situations that arise worldwide... If these restrictions did not exist, I would also prefer the domainExtent.polygon.

If a domain extent polygon has a hole or holes, it can be dissected into two or more polygons which convert the interior boundary into (parts of) exterior boundaries for the new polygons. Also split the original feature instance into two or more feature instances according to the new polygons.

The best solution would be to use meta-features (10c-9.2.3 and 10c-9.4) and encode the extents in a separate GML file accompanying the HDF5 file in the same exchange set. However, given the shortness of time and the complexity added by meta-features, the fix for this edition might be to split domain extent polygons enclosing holes as described in the previous paragraph.

[giumas]

If we go with domainExtent.polygon, what are the rasterization rules to go from polygon to cells on the bathymetric grid? You can get slightly different results based on tools/parameters. Just to make an example, check the ALL_TOUCHED option in GDAL rasterize.

Side question, what happens if there are depths outside the domainExtent.polygon? Should they be ignored? Or the whole dataset is invalid?

[RohdeBSH]

If a domain extent polygon has a hole or holes, it can be dissected into two or more polygons which convert the interior boundary into (parts of) exterior boundaries for the new polygons. Also split the original feature instance into two or more feature instances according to the new polygons.

@rmalyankar : I don't think that's a practicable solution. Who is supposed to disassemble all the polygons? That's manual work and surely none of us want that. In my view, this is also a step backwards compared to our very powerful GIS world. Then it would still be better to change the definition of the domainExtent.polygon in the S-100. Even in the current implementation, inner rings could be mapped in the domainExtent.polygon. It is just not described. An example would be that the first closed coordinate series (start==end) describes the outer ring and all following closed coordinate series always describe inner rings. But unfortunately this is not described in the S-100. The solution would be to encode the domainExtent.polygon as WKB in HDF5 and not as an array of X & Y.

---

@giumas :

Side question, what happens if there are depths outside the domainExtent.polygon? Should they be ignored?

Yes, the part outside the domainExtent.polygon is ignored for interoperability and pick reports. The problem is the same as with the multiple vertical datums (#90).

Or the whole dataset is invalid?

No, that's a common problem when raster and vector geometries have to match. If the vector geometry no longer follows the axes of the raster geometry, there is always the problem that the raster area is either too small or too large. In our case, the raster area should always be larger than the vector geometry. Otherwise, there are areas where no depth data is available and this endangers navigation (especially autonomous navigation).

[CHS-LynnPatterson]

Agree that we don't want to have to manually dissect the polygons, we need a solution that can be easily automated. That being said if we change the definition of the domainExtent.polygon, are we not emulating the coverage feature used by S-101? and if so would it not be better to make use of the existing feature? Changing that definition will have future impacts to other product specs making use of that feature and require a new version of S-100 for that to propagate to our product specification.

[giumas]

I believe that the solution proposed by @GlenRice-NOAA in https://github.com/iho-ohi/S-102-Product-Specification/issues/79#issuecomment-2147757770 may also work here (a dedicated attribute in QualityofBathymetryCoverage). It would be much simpler to have a precalculated raster-based solution for this issue, rather than providing a vector (domainExtent.polygon) that has to be rasterized on the ECDIS.

[tfilppula]

@giumas Can you elaborate what you mean by domainExtent.polygon having to be rasterized? I don't see the need.

[giumas]

@tfilppula, how would the 'valid' grid cells be identified from the domainExtent.polygon? I assume that a grid mask is derived from the rasterized domainExtent.polygon. What else can be done? Point-in-polygon using the center of each grid cell?

However, my point was that it would be useful to clarify how to filter the grid cells using the domainExtent.polygon. Maybe with one of your visual examples?

Finally, given the likelihood of different resolutions, projections and anchor points, I believe that some (minimal) level of overlap transboundary should be allowed to avoid data gaps.

[johnsonst]

Since this would affect any raster dataset in the S-100 family, should this be referred to the S-100 for a wider consideration amount the various WGs?

Sharing of data between nations for these areas or co-production of those cells would be a solution, though not always geopolitically possible. I like the idea of exploring the solution to #79 here as well. Again I am not sure QualityofBathyCoverage is the proper place for this value.. In short term, could assign a special depth value, similar to how we do for NULL, in the interim while the overriding solution is found.

[giumas]

In short term, could assign a special depth value, similar to how we do for NULL, in the interim while the overriding solution is found.

@johnsonst , why do we need a special depth value that is different from the current no data value? Based on my understanding, the current special value is not specifically designed for a specific use case (e.g., unsurveyed areas or land).

[giumas]

It looks like S-101 PS has a specific mention to this issue (in yellow):

We may get inspiration by S-101 PS wording, allowing some limited overlaps.