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

Common point rule: limit allowed values? #74

Closed tfilppula closed 1 month ago

tfilppula commented 6 months ago

The attribute commonPointRule (Table 11 in PS) is used for evaluating the coverage at a position that falls on the boundary between geometric objects in the domain of the coverage. Currently the following values are allowed (S-100 ed. 5.0.0):

image

Since we're talking about a navigation product and safety comes first: should we allow only the value 2 to be used?

AnnaWall01 commented 6 months ago

SMA will only use value '2', for the reason the Topi mentions regarding safety of navigation.

RohdeBSH commented 5 months ago

I don't think it's that relevant. When I make a depth query in a grid, it always happens with an XY coordinate. So I hit exactly one grid cell with exactly one depth value, or no grid cell at all. The commonPointRule is therefore not used at all, because only one depth value is returned, not several. The situation is different if I request the depth using a bounding box. Then many depth values can be returned. The commonPointRule then helps me to select the correct one. However, I do not see this use case with the S-102. Nevertheless, the value 2 (low) is the more correct value. As Topi has already mentioned. However, the CommonPointRule depends on the direction of the z-axis. In the case of the S-102, where the positive z-axis points to the center of the earth, it must therefore be 2 (low) in order to be nautically safe.

tfilppula commented 5 months ago

I beg to differ. You can query a grid at exactly at border of two (or three or four) grid cells containing data. If this happens, you have several nearest neighbours, so which one to report? I think the shoalest value makes most sense.

tfilppula commented 5 months ago

In the S-102PT16 meeting this proposal was accepted and it was decided that this change is included in the pull request #73 The change has been made and this issue will be closed when the pull request is merged.