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

Guidance should be provided to ensure polygon orientation (CW/CCW) and portrayal catalog contents are compatible #13

Open
DavidGrant-NIWC opened this issue Mar 22, 2024 · 12 comments

Comments

@DavidGrant-NIWC
Copy link

Origin: iho-ohi/S-101-Test-Datasets#85 (comment)

S-57 requires that the outer boundary of a polygon is encoded CW:
image

S-101 copies this requirement:
image

All the S-101 symbols are designed based on this presumed orientation.

However, in ISO 1907 the outer boundary of a surface can be oriented either CW or CCW, but the "up" side is the one where the orientation is CCW:
image

S-101 doesn't distinguish between the top and bottom, so it doesn't really matter if we draw our polygons facing down. For other products this could matter. Additionally, other products may have historically had geometry and symbolizations which were based on a CCW encoding.

This disconnect should at least be mentioned somewhere (S-97?) so that product specs can specify the required orientation, and symbols can be designed based on the required orientation for the given product.

@DavidGrant-NIWC
Copy link
Author

Looking into this further, I see that S-100 requires CW orientation:
image

This has the consequence that polygons will always be oriented so that the bottom faces up, and for 3D objects would cause the outer surface to face inwards.

@kusala9
Copy link

kusala9 commented Apr 3, 2024

I got a comment from ISO forwarded from Yong. This comments on the source of the CW/CCW which makes the same point. My reading of this is that the ISO view is different between 2003 and 2017. I only have a copy of 2003 though...

==============================

We have received a very late technical comment on ISO 19152-3 LADM Marine Georegulation, which as you know is closely based on IHO S-121. We are considering what to do with it in the ISO community; most likely, we won’t make any change. There are two reasons for this: ISO 19152-3 is at the FDIS stage where technical comments are not allowed; also, the issue lies in S-121 as well.

So, what is it?

Clause 7.2 of ISO/FDIS 19152-3 says “The outer boundary of a surface shall be in a clockwise direction (surface to the right of the curve)”. This is identical to S-121 4.2.3 which in turn is identical to S-100 7-4.3.2 item 5.

However, S-100 says it is based on ISO 19107:2003, ties its definition of polygon to ISO 19107’s GM_Surface, and cites ISO 19107 as the source of the definition for “geometric boundary”, and ISO 19107:2003 says:

“The orientation of a surface chooses an “up” direction through the choice of the upward normal, which, … is the side of the surface from which the exterior boundary appears counterclockwise.”

ISO 19107:2019 makes this clearer in its definition of Polygon “REQ. 180 The Curves in a Polygon boundary shall always be oriented so that their left side is toward the interior of the Polygon.” (A polygon is a specialisation of Surface consisting of only one “patch”). This requirement on the boundary is also true for GML3 (and later) and OGC Simple Features, which says of a polygon, “The exterior boundary LinearRing defines the “top” of the surface which is the side of the surface from which the exterior boundary appears to traverse the boundary in a counter clockwise direction.”

As I understand it, this would result in all S-100 Surfaces/Polygons being “upside down”. I doubt this is intentional and it would certainly become a problem for implementing S-121 / ISO 1915-3 in GML or anything else that builds on OGC Simple Features.

As I said, I doubt that we will be changing the text of ISO 19152-3 at this stage but we would appreciate further discussion with the S-100 team on this matter, to determine if it is an “issue” to be solved or not.

@PeterParslow
Copy link

Posting as the one who raised this to Yong.

In response to @kusala9

I can’t see that changing language from “upward direction” to “top” for a surface would suggest it has reversed. For me, if I’m floating on the surface, “upward” is to the sky; that’s the same (in my way of thinking) as the “top” of the surface. If I’m looking “down” from that upward direction, I’m looking “down” at the top of the surface: the boundary (according to 19107) appears counter clockwise. Or as the GML spec (since v3 in 2002) puts it:

“Each such ring* consists of directedEdges connected in a cycle, and is oriented with the face on its left.”

*”the non-dangling edges in the boundary of a face” – this phrasing is in the topology section, but is to me clearer than the phrase in the geometry section.

GML3 has always required its polygon boundaries to work like this, which I feel supports my view that ISO 19107 has always had it that way.

@DavidGrant-NIWC
Copy link
Author

@kusala9 and @PeterParslow: it doesn't really matter what other versions of ISO 19107 specify, ISO 19107:2003 clearly requires CCW orientation on the "upward" or "outward" face. S-100 references ISO 19107:2003; this is a case where an S-57 concept has worked its way into S-100 in preference to the ISO requirement. I suspect that GML datasets will be in violation of this S-100 requirement, at least until checked and "corrected".

One possibility to correct the issue is to remove the orientation requirement from S-100 (via correction). This would allow those (current and future) products where orientation is important to use the "proper" orientation but would also allow products such as S-101 where top/bottom don't matter to continue using CW orientation (downward facing surfaces, but the orientation will match the current design of the complex line styles).

image

@TDYCARHugh
Copy link

Re: " this is a case where an S-57 concept has worked its way into S-100 in preference to the ISO requirement".
My recollection is that IHO WG (TSMAD) was aware of the ISO direction and intentionally chose to stay consistent with S-57 and VPF for compatibility reasons.

@PeterParslow
Copy link

I guess TSMAD may have chosen to do this.
However, it will give problems when encoding any S-100 product in GML. Either the polygons (surface boundaries) would have to be reversed for that particular encoding, or the GML would be consistently misinterpreted by many generic GML readers. If the dataset (somehow) uses a 2-D cartesian coordinate system (projection), it would just be invalid GML. If it uses a 'world' system (WGS 84 etc) then it should be flagged as invalid if it has holes, and would be misinterpreted if it has none; "inside out" - the GML data would say that the 'rest of the world' has this S-121 administrative constraint, or is this S-101 measured depth.

@TDYCARHugh
Copy link

I found notes from a TSMAD meeting in 2006. "Discussion about walking polygons the math way as in ISO TC211 or continue to cycle polygons the GIS way. ". So it is an old discussion.

Where the math polygons are counterclockwise and the GIS systems and products such as S-57 and VPF have traditionally been using clockwise.

The point about consistency in GML may need consideration to be addressed in S-100 Part 10b.

@DavidGrant-NIWC
Copy link
Author

If the dataset (somehow) uses a 2-D cartesian coordinate system (projection), it would just be invalid GML.

GML supports projected CRS's. Do you mean that it would be invalid GML because of a topology constraint?

and would be misinterpreted if it has none; "inside out" - the GML data would say that the 'rest of the world' has this S-121 administrative constraint, or is this S-101 measured depth.

I believe that ISO 19107 allows either orientation to define the outer boundary. GML may have a topology constraint, but note that S-100 doesn't currently support topology (further supporting removal of the orientation constraint in S-100):
image

A polygon describing the 'rest of the universe' would have a null exterior ring with at least one inner ring. S-100 compliant applications must not (currently) rely on topology to determine inner vs. outer with respect to the boundary.

@PeterParslow
Copy link

Invalid GML because GML requires the surface to be on the left of the exterior boundary, i.e. the boundary to go counter-clockwise.
For ISO 19107 see the extracts quoted in kusala9's comment above. There may be some way to say that an ISO 19107 surface is "upside down" with respect to its boundary - there's something about "plus" and "minus" as a property.

@PeterParslow
Copy link

"Discussion about walking polygons the math way as in ISO TC211 or continue to cycle polygons the GIS way"

But even in 2006, GML polygon boundaries went one way whilst Shape file & S-57 polygon boundaries went the other way! Shape was not the be all & end all of GIS even then (as I understand it; I was very new to GIS in 2016!)

@rmalyankar
Copy link
Collaborator

Compatibility between different S-1xx products on ECDIS should probably be the overriding concern at this point of time, which implies GML encodings of S-1xx products should also use the convention in S-100 Part 7 clause 7-4.3.2 ("interior-on-right" or "CW").

(That is, continue to use that convention - while I have not checked every single extant S-1xx GML product specification, I know that several of them adopt language that is the same or substantially similar to S-101 as regards the direction of surface boundaries.)

@TomRichardson6
Copy link

This is an interesting discussion and I can only suggest that this is included on the S-100WG9 agenda for discussion at that meeting.

I sense that this decision may stem from considerations like portrayal meaning that linestyles would all need to be reversed if the direction was changed in the data. With the dual fuel period of S-57 and S-101 production this brings further complexity. For me a strategic approach to this change may be needed possibly after S-57 is sunsetted, and as part of an S-100 new edition which changes S-100 Part 7.

Clearly developing new standards is easy! but transitioning between them and harmonising the data is not.

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

6 participants