search

S-101-Portrayal-subWG / Working-Documents

17 stars 5 forks source link

Foul ground boundary and line element #65

Closed MikusRL closed 2 years ago

MikusRL commented 2 years ago

P_8 point symbol generated from the spreadsheet: S-101_NewSymbology_organized by KHOA with additaional details_20220308.xlsx P_8.zip image

2022-06-01. Updated. Fixed y coordinate for symbolBox in .svg file and updated Symbol Explanation in the Word table, which also goes in the .svg file as "...desc>Area of foul ground (safe for navigation but not for anchoring) boundary</desc..." P_8_20220601.zip image

IngaFjellanger commented 2 years ago

This central symbol above we agree with. The line style of the borders are not mentioned here.

DavidGrant-NIWC commented 2 years ago

Note: the symbolBox for this symbol is incorrect - it disagrees with the svgBox/viewBox. See related PC issue: #84

SylviaSpohn-BSH commented 2 years ago

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns="http://www.w3.org/TR/REC-html40">

Agree to symbol, explanation was already changed from foul area (unsafe for navigation) to area of foul ground (safe for navigation). --

MikusRL commented 2 years ago

I will update this symbol for David comment. @alvarosanuy please do not yet upload this exact one to the registry. I will also then check others. Hope this is the only one where this minus sign has gone missing. Please give me a day at least for that to check. Thanks.

@SylviaSpohn-BSH Not sure if I understand correctly your comment - do you want me to update the Symbol Explanation entry in the table above to "Area of foul ground (safe for navigation)"? Thanks.

SylviaSpohn-BSH commented 2 years ago

@Mikus: Yes, you're right. Foul area is the wrong term. Foul area is very dangerous for navigation. It should read "foul ground area" or better to what you proposed.

MikusRL commented 2 years ago

@SylviaSpohn-BSH thank you!

@alvarosanuy I am happy to update that to "Area of foul ground (safe for navigation but not for anchoring) boundary", Do you agree? Thanks.

alvarosanuy commented 2 years ago

@MikusRL - Hi Mikus, I think that the definition of 'foul ground' already exists in the DCEG and the FC. The "symbol explanation' field should be used to describe the 'symbol name' (usually encoded as an acronym), in plain words. For example 'symbol explanation' could be populated as: Central symbol used within Foul Ground area features to facilitate their identification, particularly when some or all their boundaries do not sit within the ECDIS display .

Maybe a bit too long but I hope you get what I'm trying to point out here.

DavidGrant-NIWC commented 2 years ago

Agree with Alvaro wrt the explanation.

For the name, the use of tokens is a carryover from S-52. In S-101 the xmlID is more analogous to the S-52 token. It would be better to use names which could be used by the ECDIS to convey meaning to the mariner, although note that currently it is not required to show the names in the pick report (likely because in S-52 they were not meaningful):

image

Currently in the testbed it shows the symbol description along with any aliases, but it would be nice to display a shorter string (the name) and only show the description/explanation as a tooltip: image

MikusRL commented 2 years ago

The above said gives meaning, and I am happy to update the files accordingly, but please for the firs ones still bit help needed - identify/mapp for me, where in the .svg file I need to add or change:

And then I believe group needs to discuss/agree, what exacly to put in the file - please use the first comments table entries and suggest changes, and also for the other symbols then please the same. Thanks.

DavidGrant-NIWC commented 2 years ago

Symbol Information

I don't think any of the information is stored in the SVG file, it is stored in the portrayal registry, and exposed to the ECDIS via the portrayal catalog (portrayal_catalog.xml).

image

I mistakenly said we showed an alias for the symbol; unlike the feature catalog, there is no alias for the symbols within the PC. We show the name, which is effectively equivalent to an alias for the symbols brought forward from S-52.

These are the attributes of a symbol and the corresponding definition/location within the portrayal catalog and the portrayal registry. Until the symbol is registered, the information should be tracked along with the symbol.

PC Registry Item Notes
symbol.id S100_PR_RegistrItem.xmlID
symbol.description.name S100_RE_RegisterItem.name
- S100_RE_RegisterItem.definition Not in PC
symbol.description.description S100_PR_RegisterItem.description
The symbol file S100_PR_Symbol
Symbol file and CSS files S100_PR_ColourToken The colour tokens referenced by the symbol - must be registered if new
- S100_PR_ItemSchema Not in PC

Display Parameters

Feature / attribute combinations are evaluated by the portrayal catalog rule files and these combinations drive the selection of symbols and their associated display parameters. In other words, the display parameters are independent of the symbol, but when a symbol is developed it is presumably to symbolize a given feature (possibly with specific attribute values). This feature/attribute symbolization should be described not just with a symbol, but also with the necessary display parameters.

I expect the sub-WG will need to provide these display parameters.

The minimum set of display parameters which must be defined are:

These display parameters must be associated with a feature type, any required attribution, and the geometry type (point, curve, or surface). If portrayal context parameters such as Radar Overlay, Plain Boundaries, etc., affect the symbol selection or display parameters then these must also be noted.

The above information is equivalent to the information provided in the S-52 DAI files and in the S-52 appendices to Part 1: image

Here's the description of the content of the look up tables for areas when context parameter "Plain Boundaries" is enabled: image

and entries for "CONVYR": image

Finally, note that symbolization of a particular feature type may require many different symbols, each with its own display parameters. For instance, an area may require:

DavidGrant-NIWC commented 2 years ago

We have replaced the point symbol used to symbolize points and areas with the symbol provided, but what is the desired portrayal for curves? In S-57 it was not possible to have a curve of type OBSTRN with CATOBS=7, so there is no symbolization defined in S-52.

viewing group=? (recommend 34050/34051 based on presence of VALSOU) display priority=? (recommend 12) display plane=? (recommend under radar) linestyle=? (recommend 0.32 mm dashed line with colour=CHGRD)

TomRichardson6 commented 2 years ago

I note that S-4 B-422.8 only describes point and area symbology. Although I expect curves to be rare we should cater for this and I would support a dashed grey line but propose that the point symbol FOULGD02 should be shown also (Complex linestyle).

Not related but I find it odd that the pick report details the symbols in the way shown above is this a new requirement from S-98? I am unclear on the user benefit of this information in the pick report.

DavidGrant-NIWC commented 2 years ago

Not related but I find it odd that the pick report details the symbols in the way shown above is this a new requirement from S-98? I am unclear on the user benefit of this information in the pick report.

The requirement is from S-52 10.8.1: image

The information is also useful to us when debugging the portrayal. At some point we may additionally show the symbol associated with the description in the pick report - that would be more user-friendly, but it's a little difficult to implement.

TomRichardson6 commented 2 years ago

@DavidGrant-NIWC thanks David I stand corrected, I can certainly see the value in testbeds but I don't recall ever seen this presented in an ECDIS system in the pick report only via the chart 1 function. I will gauge some mariner views on this and raise a further Github item on this point. Certainly not for action for the PC at this stage.

alvarosanuy commented 2 years ago

Decision made at Portrayal subWG meeting on 14/7/22

  1. Approve symbol FOULGD02 but it size has to be amended. Two new vesrions are required; one to support Curves (7.1mm diameter) and another one to support Surfaces (9.94mm diameter). Mikus to create and upload new SVG, CSS & Engineering Drawing files for both sizes to this Github issue.
  2. Point geometry to use existing (S-52 SY(FOULGND01) when VALSOU is not populated.
  3. Curve Geometry - Develop complex line style using new symbol FOULGD02 (7.1mm) evenly spaced on a 0.32 mm dashed line with colour=CHGRD. Inga to develop and upload Complex line style to this Github issue.
  4. Surface Geometry - Symbolised & Plain - Use 0.32 mm. dashed line with colour=CHGRD and center symbol FOULGD02 (9.94mm)
  5. DCEG subWG to discuss the need (use case) for geometric primitive Curve for this feature type (currently not allowed in S-57).
  6. If DCEG SubGroup returns that Curve should be discontinued, then an update to the FC and PC will follow as per current practices.

Alvaro - I decided to leave this issue open to discuss statement in DCEG section 13.6.1. It seems to be an intention to separate Obstruction, categoryOfObstruction=6(foul area) from FoulGround in a way that makes one feature unsafe for navigation and the other safe but we kept valueOfSounding as a valid attribute for FoulGround and therefore we are effectively allowing for 'Safety Contour' calculations that may return that a FoulGround is not safe to navigate over (!?)

MikusRL commented 2 years ago

For the fourth bullet point above:

_"4. Surface Geometry - Symbolised & Plain - Use 0.32 mm. dashed line with colour=CHGRD and center symbol FOULGD02 (9.94mm)"_

I will create a new symbol for the center symbol, so the center symbol and edge symbol do not get mixed up. Center symbol will be called FOULGD03.

LeoKuzmin commented 2 years ago

In according with: "3. Curve Geometry - Develop complex line style using new symbol FOULGD02 (7.1mm) evenly spaced on a 0.32 mm dashed line with colour=CHGRD. Inga to develop and upload Complex line style to this Github issue." Please, find the attached file with the SVG, xml, CSS & Engineering Drawing files of Foul Ground feature with curve type. @MikusRL: I suppose we don't need to rename center symbol 'FOULGD02' since the embedded symbol must be called with prefix 'EM'. I have called it EMFOULGD. FoulGround_Curve.zip

LeoKuzmin commented 2 years ago

BTW, the 2nd bullet, see Alvaro's message above: "Point geometry to use existing (S-52 SY(FOULGND01) when VALSOU is not populated." It is not quite correct, since FoulGround.lua script provides the drawing of the symbol FOULGND01 independently on VALSOU value according to S-52 Look-up Table.. Otherwise the script must be changed.

alvarosanuy commented 2 years ago

@mikan66 - Final instructions for implementation:

@MikusRL - We need a new central symbol (as per your FOULGD02 but with a diameter = 9.94mm).

Other parameters as follows:

This issue will continue open until changes are implemented in PC 1.0.2 by NIWC.

MikusRL commented 2 years ago

@alvarosanuy Sorry for a small confusion here I made. I understood from comment and saw in files from Leo, that he has created the center symbol already, but did not checked the svg file specifically in detail, as assumed it was created as per the description allocated to me. But You are correct Alvaro, Leo created a symbol for a line, and I still need to create a centered symbol. I am on it right away.

MikusRL commented 2 years ago

I have created the symbol and drawing. FOULGD51 centre symbol.zip I aplied a fainf colour, as per the sentred symbols - CHGRF.

image

mikan66 commented 2 years ago

@mikan66 - Final instructions for implementation:

  • Surface symbolised & Plain boundaries - Use 0.32 mm. dashed line with colour=CHGRD and new central symbol to be supplied by Mikus (see below).

Dashed line color CHGRD disagrees with new symbol CHGRF.

mikan66 commented 2 years ago

Are we adding this to alerts for SafetyContour? Currently it is not.

MikusRL commented 2 years ago

Dashed line color CHGRD disagrees with new symbol CHGRF.

Yes, I made it faint, as that I see as general approach for center symbols. Please correct me if I am wrong, but isn't that also the case with the magenta simplified symbolization of areas, that the line is Dominant color, but the central symbol is larger and Faint color usually. It makes sense, as is easier to distinguish on screen then a point symbol vs and centred symbol not only by size but also by lighter color.

@alvarosanuy If you also do not agree to this my initiative, then I am happy to change the color for the center symbol file to Dominant color - CHGRD.

mikan66 commented 2 years ago

@LeoKuzmin , Please note SVG FILE BUG: in new file, EMFOULGD.svg, line 16, 's1' should be 'sl'. I will correct locally on PC check-in. circle class="sl f0 sCHGRD" style="stroke-width: 0.32" cx="0.2" cy="0.2" r="3.55"

NOTE: used features AnchorageArea and LandElevation to simulate. Still testing but here are some samples.

Surface symbolised & Plain boundaries - Use 0.32 mm. dashed line with colour=CHGRD and new central symbol to be supplied by Mikus (see below). image

Point: image

curve: image

alvarosanuy commented 2 years ago

Are we adding this to alerts for SafetyContour? Currently it is not.

Not for now - Awaiting possible remodelling from DCEG. Having VALSOU as an attribute in FoulGround makes you think that this value should be compared against SC and trigger an Indication accordingly but ...... this is not the case in S-52 where OBSTRN, CATOBS=7 is excluded from CS(OBSTRN07). Foul ground by definition is an area safe to navigate but not for other activities like trawling, anchoring, etc). If producers think the area may be unsfae to navigate over by certain ships in the area the feature should be encoded as OBTRN/Foul Area ......

alvarosanuy commented 2 years ago

Dashed line color CHGRD disagrees with new symbol CHGRF.

Yes, I made it faint, as that I see as general approach for center symbols. Please correct me if I am wrong, but isn't that also the case with the magenta simplified symbolization of areas, that the line is Dominant color, but the central symbol is larger and Faint color usually. It makes sense, as is easier to distinguish on screen then a point symbol vs and centred symbol not only by size but also by lighter color.

@alvarosanuy If you also do not agree to this my initiative, then I am happy to change the color for the center symbol file to Dominant color - CHGRD.

I couldn't find any guidance on this topic and although some magenta symbols follow the principle mentioned by mikus (line is Dominant, central symbol is Faint), this is not always the case. There are multiple examples of small central symbols and area patterns in Grey that have both, line and symbol in Dominant colour ....... I think we have the opportunity to create some rules here and potentially allocate any central large (around 9mm diameter) central symbol that is enclosed in a circle a Faint colour & central symbols not having a surrounding circle and being small (generally less than 6mm D) in size a Dominant colour.

If we go ahead with this, FoulGround and DiscolouredWater https://github.com/S-101-Portrayal-subWG/Working-Documents/issues/61 will have to follow this guidance (I think they currently do as the central symbols for both were supplied in Faint grey colour).

Does anyone have something against this general ruling??

mikan66 commented 2 years ago

Are we adding this to alerts for SafetyContour? Currently it is not.

Not for now - Awaiting possible remodelling from DCEG. Having VALSOU as an attribute in FoulGround makes you think that this value should be compared against SC and trigger an Indication accordingly but ...... this is not the case in S-52 where OBSTRN, CATOBS=7 is excluded from CS(OBSTRN07). Foul ground by definition is an area safe to navigate but not for other activities like trawling, anchoring, etc). If producers think the area may be unsfae to navigate over by certain ships in the area the feature should be encoded as OBTRN/Foul Area ......

The rule will have simple VALSOU logic only controlling viewing group and radar. I plan to close this issue in the PC today as I don't see any other tweaks needed at this time (regarding visualization).

mikan66 commented 2 years ago

See https://github.com/iho-ohi/S-101_Portrayal-Catalogue/issues/39#issuecomment-1247940868

alvarosanuy commented 2 years ago

Implemented in PC 1.0.2