Develop symbology for Helipad & Heliport - NCWG8-06.10A

[alvarosanuy]

NCWG8 meeting decided to develop a new symbol for Helicopter Landing Pads (Helipads) and Heliports as per INT1 symbol D18.

This symbol is to be mapped to:

• AirportAirfield feature of type point [attribute category of airport/airfield = 3 (military heliport) or 4 (civil heliport)]

• Runway feature of type point [attribute category of runway = 2 (helicopter landing pad)]

The new symbol will also be used to create a 'pattern' version as per S-52 AP(AIRARE02) - implemented in S-101 as AIRARE02P. This last symbol will be used in a new Area Fill file to be created.

This area pattern will be used to depict:

AirportAirfield feature of type Surface [attribute category of airport/airfield = 3 (military heliport) or 4 (civil heliport)]

[alvarosanuy]

@MikusRL - Can you please develop the new point symbols HELIPD02 and HELIPD02P as per the previous comment?

NIWC would create the new Area Fill file (and update AirportAirfield and Runway Rules) once HELIPD02P becomes available.

[MikusRL]

@alvarosanuy I can deliver this with similar time frames as with the new Pilotage symbols. If I will have any uncertainties I will ask them here.

[MikusRL]

So references are from FC 1.0.2, and are: AIRARE02 and AIRARE02P

@alvarosanuy If I understand correctly the expectation is to achieve the same, so then:

• the helipad is expected to portray the point geometry feature, practically as in the INT1 image above, like AIRARE02, and
• the heliport should be then portraying area geometry feature without the circle for the area pattern generation, like AIRARE02P.

Now working on it.

[MikusRL]

Have created the symbols. Update_20221129. Fixed .svg files and returned back the .css file values as per earlier values - "round": HELIPD02.zip

While working on them I noticed the following about the daySvgStyle.css file we were using all the time for viewing in the web browsers and using screen captures from there in engineering drawings:

But for this particular symbol the line caps had to be square. I looked in the Raphael's S-100 v.5.0.0 schemas at https://schemas.s100dev.net/ and in S100SymbolDefinition.xsd in THE LINE STYLES PACKAGE the default CapStyle is named the "Butt":

It works for me this time, I amended the default line cap style to Butt and line join style to Miter in the daySvgStyle.css, which I added now with this zip file:

But is this correct? If the default in ECDIS for S-100 is round line ends, then what should be added in the .svg file to override this? To NIWC, could you please tel, if the .css files are used in ECDIS, or is it only for symbol viewing and development purposes, and in either way, please check, if the new symbol in your ECDIS test bed has the default line cap style as Butt, so the new helipad symbol portrays correctly - sharp square and not rounded line ends. And should the .css files be reviewed for the default values mentioned in S-100 v5.0.0 portray schemas as such? Thanks.

[DavidGrant-NIWC]

Short Answer

Remove the "sl" from the class attribute of the path instructions and revert to the original CSS file.

  <circle cx="0" cy="0" r="3.98" class="sl f0 sLANDF" style="stroke-width:0.32" />
  <path d=" M -1.4,-2.2 L -1.4,2.2" class="f0 sLANDF" style="stroke-width:0.64;" />
  <path d=" M 1.4,-2.2 L 1.4,2.2" class="f0 sLANDF" style="stroke-width:0.64;" />
  <path d=" M -1.3,0 L 1.3,0" class="f0 sLANDF" style="stroke-width:0.64;" />

Long Explanation

The default values in the S-100 schemas only apply to S-100 line styles, the defaults for the symbols are specified in the SVG Tiny 1.2 spec (which happens to also specify "butt" and "miter").

S-100 Line styles are contained in the LineStyles folder of the portrayal catalog or can be created within the drawing instructions output by the portrayal. S-100 Line styles are used when the portrayal draws lines directly. The SVG symbols do not use S-100 line styles, they instead use SVG Tiny 1.2 stroke and fill properties: https://www.w3.org/TR/SVGTiny12/painting.html#StrokeLinecapProperty

The CSS files are used by the ECDIS when drawing SVG symbols. Note that all three files are used: daySvgStyle.css, duskSvgStyle.css and nightSvgStyle.css. The ECDIS will use the file which matches the currently selected color palette. If no style is specified, then the SVG Tiny 1.2 defaults would apply. However, currently all the symbols override the defaults by using classes defined in the CSS files: "sl" for the stroke style and "f0" for the fill style.

The changes you made would cause your new symbol to portray correctly (but only in the day palette). However, it would also change all the other symbols to use "butt" and "miter" and I don't think that's desired. Probably best to leave them as-is unless someone wants to go through all the symbols and update the line / stroke styles.

In the future, if you don't want to use the default values and you also don't want to use the pre-existing class, you could either:

• Create a new class in all the CSS files: .slSquareBevel {stroke-linecap:square;stroke-linejoin:bevel} and use that new class in your drawings: <path d=" M -1.4,-2.2 L -1.4,2.2" class="slSquareBevel sLANDF" style="stroke-width:0.64" />
• Specify the style explicitly when drawing: <path d=" M -1.4,-2.2 L -1.4,2.2" class="f0 sLANDF" style="stroke-width:0.64;stroke-linecap:square;stroke-linejoin:bevel" />

[MikusRL]

I will update my delivered files according to your short description. As I understand, then that is how in this case the desired outcome for just this particular symbol should be achieved. Correct? I agree that we do not need to change the .css files at this stage, if the "sharp" H symbol can be achieved by removing the "sl" from the stoke row.

@DavidGrant-NIWC , as always, very much appreciated both - your short and long answers. I trust that now at least 27 persons will benefit from this your input as well and will use this knowledge to deliver correct and consistent files to you also with their input to you - NIWC test bed and S-101 PC. Thanks again.

[MikusRL]

@DavidGrant-NIWC I have uploaded the fixed symbol files in the first comment. Thanks for input again.

[DavidGrant-NIWC]

I have uploaded the fixed symbol files in the first comment. The update looks good.

Thanks for input again. Thank you for being so thorough with the symbol development.

Looking at our testbed implementation of these defaults led us to discover a conflict between S-100 5.0 Part 9 and Part 9a with regard to the default join style: Part 9 specifies "miter" and Part 9a specifies "bevel". This is not relevant to the symbols as the conflicting defaults apply to S-100 line styles, but an issue nonetheless. Additionally, our testbed currently defaults to "bevel" in all cases (including for SVG symbols), but this will be corrected in the next release.

I'll try to get a late proposal in for the upcoming S-100 WG to address the Part 9 / 9a discrepancy.

[alvarosanuy]

Portrayal subWG meeting - 11th January 2023

1. Symbols HELIPD02 and HELIPD02P were approved.

2. It was decided to develop the new Area Fill pattern using the HELIPD02P symbol. @MikusRL - Please develop and submit Area Fill accordingly.

3. NIWC - Map new symbols as per instructions below:

HELIPD02 is to be mapped to:

• AirportAirfield feature of type point [attribute category of airport/airfield = 3 (military heliport) or 4 (civil heliport)]
• Runway feature of type point [attribute category of runway = 2 (helicopter landing pad)]

New Area Fill will is to be used to depict:

• AirportAirfield feature of type Surface [attribute category of airport/airfield = 3 (military heliport) or 4 (civil heliport)]

[MikusRL]

Created the files as per the point 2. above, but needs to be checked by NIWC or @HolgerBothien or Hugh, if it is correct. Please fix/adjust them as necessary before implementation. Does the "conspicuous" version of the pattern defines only through the look up tables, like for the "AIRARE"? HELIPD02_area_pattern.zip

HELIPD02.svg: (must be checked by NIWC or Holger or Hugh) Metadata line is definitely to be updated, but I do not know to what exactly. I think if it is done then must be applied consistently across all new defined or created/updated symbols in 2022/2023, but that is not yet agreed.

[HolgerBothien]

There are a few things worth to be mentioned:

1. The file HELIPD02.svg is not an SVG file and should be better named HELIPD02.xml.
2. It conforms to the Schema defined in S-100 ed.5 (S100AreaFill.xsd) unfortunately with no namespace defined
3. The S100lineage and S100Meta are so called XML processing instructions. Their content is not described in the schema. This might be the reason for having them in the areafills so far. The are some kind of problematic and should not contain information that is expected to be used by any client software. But this is not a topic for this group.
4. In order to get this information (if required) into the area fill the model, and schema must be extended in S-100 first. Again, not a task for this group. Summary: The file is OK but must be renamed. I would remove the S100lineage or put some information as you like. The good thing is the the content of processing instructions can be any text (though it looks like that the using a structure as XML attributes) Means that <?S100lineage Put in whatever you like ?> is compliant :-)

[MikusRL]

Thanks @HolgerBothien for your quick answer. But is the Pivot point correctly written in the expected .hml file, and what then should be written in the engineering drawing table at the Pivot point entry? Thanks.

And I actually saved the file as .svg, because I used the Download function for the AIRARE02 pattern file from the GI Registry, and it then offered to save it as .svg. So I named my file as .svg to be consistent. But I of course can update it in my zip file as you say to .xml. I also agree that then it would be less confusing between the point file (.svg) and the area fill file, as otherwise they are called then exactly the same.

[MikusRL]

Updated zip file with pattern file renamed to .hml. HELIPD02_area_pattern.zip

[HolgerBothien]

The pattern is using the symbol HELIPD02P by reference. The pivot point and the bounding rectangle are property of the point symbol. There is no pivot point in the model of an area fill. I think that the table in the Word document needs a different structure ans we need two tables, one for the point symbol and another one for the area fill.

[alvarosanuy]

Updated zip file with pattern file renamed to .hml. HELIPD02_area_pattern.zip

@DavidGrant-NIWC - Can you please test the area fill and provide a "preview' image I can use during the registration process?

@MikusRL - Is the 'Engineering Drawing' an output from KHOA Symbol Editor tool? If so, should we ask them to have a different template for Area Fills as mentioned by @HolgerBothien ? Can you please discuss with @HolgerBothien and manually update the Word document so it reflects only the information needed for this AF and can be used by KHOA if required?

[MikusRL]

@alvarosanuy , @HolgerBothien , I will try to to re-arrange the table to achieve what you both are suggesting. And I partly used the engineering drawing as it is laid out in S-52 Addendum to part 1 Symbol Catalogue Area Pattern table, but apparently for S-100 it needs some adjustment as you propose.

And, no, I have access only to point symbol editor in KHOA S-100Toolkit tool. Although there is line and pattern editor developed by KHOA, currently only Yong and IHO have access to these tools. I saw in KHOA demonstration at the S-100WG meeting last December, that there are such a tools, no functionality was shown of these tools though, asked if I can get to use these tools too, and Yong answered that these are not tested and approved yet. I would be happy to use them too instead of trying to create files manually, with a lot of guesswork on top, from other already registered patterns.

[alvarosanuy]

@JeffWootton - See comment from @MikusRL below. Any chance you can escalate this requirement with Yong/KHOA ??

And, no, I have access only to point symbol editor in KHOA S-100Toolkit tool. Although there is line and pattern editor developed by KHOA, currently only Yong and IHO have access to these tools. I saw in KHOA demonstration at the S-100WG meeting last December, that there are such a tools, no functionality was shown of these tools though, asked if I can get to use these tools too, and Yong answered that these are not tested and approved yet. I would be happy to use them too instead of trying to create files manually, with a lot of guesswork on top, from other already registered patterns.

[MikusRL]

Can you please discuss with @HolgerBothien and manually update the Word document so it reflects only the information needed for this AF and can be used by KHOA if required?

In progress.

[HolgerBothien]

I think the table for a symbol fill should only contains the details defined by the symbol fill and not repeat the details of the referenced point symbol. Those details are:

• the referenced symbol(s)
• the two vectors that define the pattern
• a preview of the pattern
• explanation, reference and some other metadata

I attach a proposal. Note that this is only my view on it, and the preview doesn't show the correct pattern.

[HolgerBothien]

HELIPD02_SymbolFill.docx

[MikusRL]

@alvarosanuy I have updated the table for it to be for symbol fill for area objects. In comparison to @HolgerBothien suggested table I propose to leave in also the two descriptive fields for pattern drawing - for quality control purposes for the xml file drawing, that it draws as intended and described. But that can be discussed further. I also cleaned the x and y values in the drawing and in the xml file, as in Holgers suggestion. I hope it should be ok for helipad symbol, if it is good for airport symbol. But please feel free to check and give feedback, if that update does not fit heliport symbol. NIWC still please generate the pattern preview image. I have no tools at the moment to create a preview for patterns.

Updated pattern files: HELIPD02_area_pattern_26012023.zip

Then the image should have the V1 and V2 vectors on top, as Holger suggested in his example:

[DavidGrant-NIWC]

It would take a large heliport area for more than one or two symbols to be visible. Using fake data:

At scale (1:45k - no symbols visible)

1:22k

1:8k

[MikusRL]

@DavidGrant-NIWC thank you for the preview. That looks too sparse. I will update the .xml instruction for half of the size of this preview.

[MikusRL]

Updated. I will keep the metadata lines as per airport fill symbol for now until it is decided what it is it should be there. HELIPD02_area_pattern_27012023.zip

@DavidGrant-NIWC Could you please create an updated preview? Thank you. But in longer term I would like to have one or two workshop session with you in closer future on how I could do it myself changing the right files in the installed NIWC test bead, which you helped me to install, in my own PC. I will contact you on email about that. Perhaps there could be some more interesents to participate as well, which could increase the symbol building and delivering capacity of this group and wider in IHO perhaps. Similarly we could try to arrange perhaps also about the KHOA's symbol builder, as I know at least Mikan is trying it out too.

[DavidGrant-NIWC]

[...] in longer term I would like to have one or two workshop session with you in closer future on how I could do it myself changing the right files in the installed NIWC test bed [...]

We can do that, but it's actually pretty simple (recommend doing this in a temp copy of the PC):

• Add symbol(s) to "Symbols" folder
• Add entries in portrayal_catalogue.xml <symbols> section
• Repeat for other elements ("AreaFills"/<areaFills>, "LineStyles"/<lineStyles>)
• Find a chart feature which is the approximate size/shape of the portrayal you want to test (I used IceArea)
  • Edit the rule (IceArea.lua) to temporarily modify the portrayal to match what is desired.

Re-load the chart into the simple viewer (S100Viewer.exe) and check the result. This will work for looking at potential portrayals, but is not a complete test because we aren't using actual features with their attribute values and associations.

Here's a comparison of the Heliport area with a "Vegatation, Wood in General" area on a chart with a compilation scale of 1:45k	Scale	Heliport Area	Vegatation Area
1:45k
1:22k
1:12k

[alvarosanuy]

@MikusRL - The new distance for the pattern looks much better but I'm still questioning myself how big are the heliports currently charted around the world. Would it be possible for PRIMAR to do a search on ENCs having the Area objects matching the Object/Attribute combinations below? We can then use their average size to compile test features in an S-101 dataset and assess how close the 'H' pattern has to be to work in real case scenarios.

AirportAirfield feature of type Surface [attribute category of airport/airfield = 3 (military heliport) or 4 (civil heliport)]

[MikusRL]

@alvarosanuy I will try to do my best as soon as possible. That is a good idea, and perhaps should be used in similar cases by default. This of course then involves me being then able to "sandbox" the found datasets in the NIWCs' test bed as David writes above. This I have not yet done before, just need to find time to get my head around that and establish some workflow to be repeatable...

[alvarosanuy]

@MikusRL - Any luck with the database search? We should make the final decision regarding symbol spacing in the next week or so.

[MikusRL]

@alvarosanuy My apologies, last two weeks were extremely busy, but I am on it now.

[TomRichardson6]

@alvarosanuy and @MikusRL I recall that at the PT9 meeting helicopters were regularly operating from just in front of the meeting room the NZ cell includes that as an area of roughly 8 metres square. I support a query to support this but I think it would be logical to consider a point centred symbol here rather than an area pattern.

[MikusRL]

I did queried the PRIMAR available DB as of today and there are 21 military and 74 civil heliports encoded as polygons.

These are most of the cases:

Almost all of them are not readable, and in two production and two ECDIS systems we looked into the pattern was "floating", meaning the pattern was not guaranteed to be visible in the polygon.

I support too to use the point symbol as the center symbol, if the polygon is encoded. It will be also more easy to find. Not it is not possible to manually find the heliport on ECDIS if you do not know where it is. There is one manufacturer who has kind of "cheated" the symbol by grouping three planes closer together and centered them over the polygon. This basically tells that the problem has been recognized already earlier by some manufacturers, and some "way around" has been tried to introduce.

And my opinion is that there is no need for a specific different center symbol that the one already created in the circle. Only difference to usual center symbols I would think would be that this centered symbol should not disappear, if the polygon becomes smaller than the centered symbol. I think it is ok for it to overlap the border and be visible as long it's SCAMIN allows it to be shown. The "borders in this case just gives additional information when either overzoomed, or using chart in compilation scale.

[DavidGrant-NIWC]

Only difference to usual center symbols I would think would be that this centered symbol should not disappear, if the polygon becomes smaller than the centered symbol. I think it is ok for it to overlap the border and be visible as long it's SCAMIN allows it to be shown.

S-52 PL 4.0.3 clause 8.5.1 includes: If the centre of the symbol bounding box falls outside of the area then it must not be drawn.

So, as long as no offset is applied to the symbol it will be visible, provided nothing else disables it (viewing group, SCAMIN, date dependent, etc.)

[alvarosanuy]

Consensus in not implementing Area Fill pattern as originally planned.

@DavidGrant-NIWC - Please proceed and use the Point symbol HELIPD02 as a center symbol for AirportAirfield feature of type Surface [attribute category of airport/airfield = 3 (military heliport) or 4 (civil heliport)]. The boundary of the surface is to display as per S-52 for AIRARE. This is LS(SOLD,1,LANDF).

[DavidGrant-NIWC]

Holding off on checking this change into the PC until I get feedback on the implementation:

Runway

• RUNWAY with point geometry has no portrayal in S-52 (it's intentionally not portrayed).
  • In S-101 it currently portrays using NullInstruction (it's not visible but will show up in a pick report if you happen to click on it).
  • It's not clear from the DCEG when a Runway would ever be encoded using point geometry.
  • The change proposed in this issue would make Helicopter Landing Pad (categoryOfRunway=2) points visible, but Aeroplane Runway (categoryOfRunway=1) points would remain invisible.

AirportAirfield

• The change results in inconsistencies in the portrayal of AirportAirfield.
  • Heliport areas use a centered point whereas other airfields use an area pattern fill
  • The area fill pattern for a non-Heliport AirportAirfield of type surface is typically not visible, whereas a Heliport AirportAirfield of type surface always has a visible centered point symbol.
• The point and centered area symbol are the same for a heliport (exactly the same symbol and size).

Object	Point	Surface	Overscaled
Military or civil heliport
Other

[alvarosanuy]

My view

I guess the main difference between Airport/Airfield and Heliports and Helipads is the area they cover on the ground.

The overwhelming majority of Airports/Airfields can be captured as areas at large and medium scale bands whereas Heliports and Helipads are too small to show their boundaries (even less an Area Fill pattern) at any scale (unless >4000); and if they do, having a central symbol is sufficient. The example used for 'Military or Civil Airport - Overscaled and Surface' above are, from my point of view, unrealistic due to their size.

Agree that existing encoding guidance does not help with the management of Runway of type point. In practice we (AHO) encode these features as AirportAirfield (AIRARE) Point features to get them to display (workaround). We have several examples in PNG and Solomon Islands. In the end is all about informing mariners that from that location aircrafts operate (land and take off). I think there are merits to start mapping Runway Point features as AirportAirfield Point features in S-101. If others think the same, I'm happy to create a new Github issue and leave it open for a couple of weeks.

- In Summary:

• [ ] Keep the mapping of Heliports and Helipads as already agreed in this Github Issue
• [ ] Consider amending the S-101 mapping of Runway features of type Point to depict as AirfieldAirport features of type Point

[MikusRL]

I agree to @alvarosanuy .

And if back to the heliports - I think the testing of 1.1.0 should show if the border of heliport is to be hidden or it works as useful additional information and does not create too much clutter when together with the central symbol. The only improvement for the examples above I could think that we could make it "faint" and the circle 0,64, as it is not as important chart info, but if needed, still would be foundable by looking, but not for 1.1.0 implementation. Perhaps this same idea, if it works well, could be taken and changed from pattern to central symbol for Airports and runways as well for later tests.

[DavidGrant-NIWC]

Ok, so my understanding:

• [x] Implement AirportAirfield as shown in my previous comment.
• [ ] Implement Runway with point geometry (regardless of attribution) as
  • Please confirm
• [ ] @alvarosanuy to create a DCEG issue for Runway points (to be resolved in a future edition)?

[DavidGrant-NIWC]

And if back to the heliports - I think the testing of 1.1.0 should show if the border of heliport is to be hidden or it works as useful additional information and does not create too much clutter when together with the central symbol. The only improvement for the examples above I could think that we could make it "faint" and the circle 0,64, as it is not as important chart info, but if needed, still would be foundable by looking, but not for 1.1.0 implementation. Perhaps this same idea, if it works well, could be taken and changed from pattern to central symbol for Airports and runways as well for later tests.

• If desired, recommend creating a separate issue for this (to be addressed in a future edition).

[alvarosanuy]

Implementation needed to close this issue:

• AirportAirfield feature of type point [attribute category of airport/airfield = 3 (military heliport) or 4 civil heliport)] - Map to HELIPD02.
• AirportAirfield feature of type Surface [attribute category of airport/airfield = 3 (military heliport) or 4 (civil heliport)] - Use HELIPD02 as a central symbol for the area and show the area boundary as per S-52 for AIRARE. This is LS(SOLD,1,LANDF).
• Runway feature of type point [attribute categoryOfRunway = 2 (helicopter landing pad)] - Map to HELIPD02

@alvarosanuy will create a new Github issue to seek endorsement of the following portrayal (which will differ to S-52):

• Runway feature of type Point [attribute categoryOfRunway=1 (Aeroplane Runway)] - Map to AIRARE02.

[DavidGrant-NIWC]

Do we want to draw anything for Runway feature of type point [attribute categoryOfRunway = unknown]? Perhaps:

S-52 intentionally does not display any runway features of type point.

[HolgerBothien]

To be consistent with S-52 it is worthwhile not to symbolize it. I believe that this is rather a rare case anyway. For small scale charts AIRARE would be used instead of RUNWAY. Can someone find out how many RUNWAY (Point) exists in the current ENC coverage?

[MikusRL]

There are around 1700 features of type RUNWAY in PRIMAR DB. With encoded category there are around 750, of which 210 are heliport, and of the last 39 are point features and 166 are polygon features. For the Category of airplane runway there is only 1 encoded as a point feature that I can find. Rest are polygons.

[alvarosanuy]

Implemented in PC 1.1.0

[TomRichardson6]

All

TDS 06 has had a point heliport added to support testing.

https://github.com/iho-ohi/S-101-Test-Datasets/tree/main/dev/cells/101AA00DS0006/3

[DavidGrant-NIWC]

@TomRichardson6 The updated dataset won't load on ECDIS because the dataCoverage min/max scales are reversed. See issue https://github.com/iho-ohi/S-101-Test-Datasets/issues/46

Portrayal in S-100 Viewer: