search

iho-ohi / S-102-Product-Specification

It is opened to develop S-102 Bathymetric Surface Product Specification. The contents of this repository are not offical publication in force, therefore please check the final version on the IHO website.
Other
26 stars 10 forks source link

approximateGridResolution remarks & note: remove parts of ungeorectified grid, variable cell size grid #94

Closed tfilppula closed 1 month ago

tfilppula commented 1 month ago
  1. Table 20 — S100_DataCoverage parameters, approximateGridResolution, Remarks:

Remove sentence May be approximate for ungeorectified data (not applicable to this edition of S-102).

  1. Table 20 — S100_DataCoverage parameters, Remove Note:

NOTE: If the grid cell size varies over the extent of the grid, an approximated value based on model parameters or production metadata should be used.

giumas commented 1 month ago

Given that we are modifying this part, would it make sense to also add an example in case of unprojected coordinates (geographic)?

RohdeBSH commented 1 month ago

Given that we are modifying this part, would it make sense to also add an example in case of unprojected coordinates (geographic)?

Why? Even if you use a non-projected grid, you have to specify the "approximateGridResolution" in meters. The attribute type is "real" so it would be something like "7.12345". In my opinion, the only meaningful modification would be to change "5" to "5.0" to clarify that you can enter decimal numbers.

@tfilppula What's your opinion?

giumas commented 1 month ago

If the coordinates are geographic, is it expected to have 2 or 1 approximateGridResolution values? Along the N-S axis, how is the suggested approximated value calculated? E.g., it could be the maximum value, the average value. In @RohdeBSH's example ("7.12345"), should such a value be truncated or rounded to a significant digit (e.g., "7.123")? These are 3 aspects that look unclear/undefined to me in the current formulation of the attribute.

tfilppula commented 1 month ago

@giumas @RohdeBSH Multiplicity is 1..2 and in the remarks it says: 

A single value may be provided when all axes have a common resolution. 
For multiple value provision, use axis order as specified in dataset.

So either one value if the ground resolution is the same (approximately) for both axes or two values if they are different. I think the standard is quite clear here.

As the name suggests this is an approximate value - I don't think it is necessary to go for millimetre level. For geographic grids I personally would probably use the mean value for (longitude) resolution but someone else might use something else. If there is a big difference in resolution (north-south), it might be worth considering splitting the dataset to two or more datasets or using UTM projection to minimise scale error.

Bottom line: I wouldn't change it.

giumas commented 1 month ago

@tfilppula, I still believe that an additional example for geographic grids would be useful.