CATALOG.XML posList values ordered incorrectly

[DavidGrant-NIWC]

EPSG:4326 requires coordinates to ordered as (lat, lon). The posList values are currently ordered as (lon, lat).

[kusala9]

could use urn:ogc:def:crs:OGC:1.3:CRS84 as the CRS which is WGS84 in lon/lat order... Would this be a problem? This is how polygons have been encoded in the incoming CATALOG.XML (eidtion 4.0.0) so it needs attention and I think has probably been wrong for a while.

I've left all the data coverage parts out of the latest version of the exchange set (they're optional). What's "required" from an ECDIS point of view? We should decide and then clarify either in PArt 17/schemas or S-98 I believe.

[DavidGrant-NIWC]

From S-98:

There is no specific restriction on the CRS, so I guess you could use CRS84, but you risk the ECDIS not supporting. Inclusion in the test datasets might help to ensure support. In general, I think the CRS of the dataset should match the CRS of the bounding polygon(s).

The boundingPolygons are mostly useful in the case of encrypted datasets to support discovery of available datasets for which the user may not have a permit.

I've left all the data coverage parts out of the latest version of the exchange set (they're optional). What's "required" from an ECDIS point of view? We should decide and then clarify either in PArt 17/schemas or S-98 I believe.

I think they're only optional because a product is not required to have data coverages. I believe that S-101 requires dataCoverage to be populated; I'm not sure though because the post-mtg docs from S-101PT9 haven't been updated.

[DavidGrant-NIWC]

Verified: S-101 requires dataCoverage to be populated

[kusala9]

yes, I saw that. and thus raises the spectre of "The ECDIS doesn't understand the coverage is mandatory for S-101 because it only knows about S-100 and its schemas" - so there's no way an ECDIS implementer knows these features will always be there for S-101 but not for other products. I guess this means the ecdis "graphical catalogue" will only be graphical for those products which have included coverage polygons and/or boundaries.

I'll update the catalogue to insert these coverage features for the test datasets. I can understand that e.g. S-128 coverage could be meaningless but most other datasets will require coverage.

So, should this be a clarification in S-98 Annex C on how the graphical catalogue should be put together?

[DavidGrant-NIWC]

The graphical catalog on the ECDIS can be compiled from the dataCoverage polygons present in the encoding(s).

This is for discovery purposes - to discover what is available to download to my system. In my opinion, products whose datasets have a boundary should have one or both of boundingBox / dataCoverage always present in the discovery metadata.

The ECDIS could also use it (when present) to optimize certain operations, for instance to prioritize the order of import into the SENC based on ships location.

[kusala9]

this should be a clarification in S-98. There's also an option for them to use S-128 to build a catalogue of what is avialable in a service, even if it is not necessarily installed. OEMs should be aware of the difference, and validation tests setup to ensure the two sources of coverage are the same.