Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion of InTheWater attribute. #3

Open
kusala9 opened this issue Jan 8, 2021 · 8 comments
Open

Discussion of InTheWater attribute. #3

kusala9 opened this issue Jan 8, 2021 · 8 comments

Comments

@kusala9
Copy link
Collaborator

kusala9 commented Jan 8, 2021

image

this issue is for discussion, from an ENC conversion perspective, on how to automatically convert S-57 data to encode InTheWater in a way consistent with the feature catalogue and DCEG.

Some questions:

  • How do we determine whether a feature is located in or over navigable water?
  • Does this attribute take the place of the coincident point features (e.g. piles) used to ensure base display of features in S-57. should we be deleting these extraneous point features?
  • Can we accomplish this process automatically, if not, what are the data preparations necessary to be consistent.

This issue needs a bit of explanation and discussion from DCEG/S-101 encoding experts, and trialling with some real examples of S-57 features to illustrate how the process can work.

@Christian-Shom
Copy link
Collaborator

  • How do we determine whether a feature is located in or over navigable water: would suggest: if it is covered by a Depth Area, Dredged Area or Unsurveyed Area.
  • My view is that there should be nothing to do to prepare S-57 data. Should be automatically processed: If the object admits "In the Water" attribute, and the Feature object instance is covered by Depth Area, etc, then In the water=1.

@kusala9
Copy link
Collaborator Author

kusala9 commented Feb 11, 2021

Is UNSARE navigable water? I agree with DEPARE and DRGARE certainly. I agree if we can do this automatically it makes sense. My understanding is that inTheWater replaces the coincident point objects referred to in the UOC, should we remove these when doing the conversion?

@Christian-Shom
Copy link
Collaborator

Of the opinion that S-57 point objects will have to be removed (as they are work-arounds).

@tdepuyt
Copy link

tdepuyt commented Feb 12, 2021

  • How do we determine whether a feature is located in or over navigable water?
    The DCEG currently states that "* over navigable water, in the context of ENC encoding, is defined as areas covered by Group 1 features Depth Area, Dredged Area, Dock Area, Lock Basin, or Unsurveyed Area". That seems pretty straight forward for the converter to figure out.

  • Does this attribute take the place of the coincident point features (e.g. piles) used to ensure base display of features in S-57. should we be deleting these extraneous point features?
    According to the DCEG for features with the in the water attribute, it states: ". Where such structures are located in the water it is not required to encode any supporting structures (for example piles)."
    The converter should be able to drop any supporting structures. Is there a clearly defined list of structures that should be deleted besides piles?
    If the piles are deleted in S-101, what considerations should be made to ensure you can convert back to S-57 without causing display issues?

  • Can we accomplish this process automatically, if not, what are the data preparations necessary to be consistent.
    If there's a clear list of use cases, then there shouldn't be an issue removing the unwanted features. Encoding the in the water attribute shouldn't be an issue as long as we agree on the underlying features such as G1.

@HermanSchouten
Copy link

Not converting Piles (PILPNT) coincident with Wind Motors in the water etc is logical.
Correct me if I'm wrong; but I think if the Boolean attribute InTheWater is available in the S-101 feature this should be used instead of a PILE/PILPNT in all cases? This would ease reverse conversion.
LIGHTS don't have the possibilty to encode "InTheWater" this is in accordance with the following:
DCEG states the following: When a light is
located in the water with no indication on the source of the structure feature, regardless of the height
of the light, a Pile feature of type surface or a Beacon Special Purpose/General feature should be
encoded as the structure feature. This will ensure that a symbol will be shown on ECDIS systems
when the light features are not displayed during daytime navigation.

@Christian-Shom
Copy link
Collaborator

Christian-Shom commented Sep 13, 2021

During last meeting, I mentionned LNDAREs or other objects could be treated similarly.
As Tom mentionned in his post dated 12 Feb, the DCEG give the following guidance for the 5 feature objects CRANES, BUISGL, SILTNK, LNDMRK and FORSTC:
"For xxx located in navigable water, the Boolean attribute in the water must be set to True to indicate
that the feature is to be included in the ECDIS Base Display. Where such structures are located in the
water it is not required to encode any supporting structures (for example piles).
".
Consequently, I am of the opinion, for each CRANES, BUISGL, SILTNK, LNDMRK and FORSTC Point object situated in navigable waters (Depth Area, Dredged Area, Dock Area, Lock Basin, or Unsurveyed Area), to:

  • set "in the water attribute" to True, and
  • not retain the other coincident object (PILPNT, LNDARE, PONTON, OBSTRN, etc.).

I did not check, but I guess all Feature objects with In the water=True will trigger an alarm.

@JeffWootton
Copy link

Agree with all the above, noting however my comment at the last Sub-Group meeting that LandArea point should not be automatically deleted from the converted S-101 dataset if coincident with the supposed "in the water" feature (in such cases, inTheWater should not be present or set to False).
I should also note a correction that has been made to the draft S-101 DCEG Edition 1.0.2: It has been pointed out that the Skin of the Earth features DockArea and LockBasin must only be encoded in ENC if the area is non-navigable at the compilation scale of the ENC. Therefore these features have been removed from the list of Skin of the Earth features constituting "navigable water" at DCEG clause 2.4.3.

@Christian-Shom
Copy link
Collaborator

LandArea point should not be automatically deleted from the converted S-101 dataset if coincident with the supposed "in the water" feature (in such cases, inTheWater should not be present or set to False).

The difficulty/impossibility here is to know whether the point LNDARE has been encoded because there is actually a Land Area or to have a Base Display feature encoded. There must be a unique conversion rule and I would be in favour of treating the LNDARE like the PILPNT and PONTON (i.e. do not convert and set inTheWater to True).
Is there any issue if we do it differently?

For back conversion to S-57, a LNDARE would be created coincident with every S-101 feature having inTheWater = True.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants