-
Notifications
You must be signed in to change notification settings - Fork 1
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
Comments
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. |
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. |
@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). |
Re: " this is a case where an S-57 concept has worked its way into S-100 in preference to the ISO requirement". |
I guess TSMAD may have chosen to do this. |
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. |
Invalid GML because GML requires the surface to be on the left of the exterior boundary, i.e. the boundary to go counter-clockwise. |
"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!) |
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.) |
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. |
Origin: iho-ohi/S-101-Test-Datasets#85 (comment)
S-57 requires that the outer boundary of a polygon is encoded CW:
![image](https://private-user-images.githubusercontent.com/62906211/316140911-92fdbe68-ef4c-478a-8adb-6a4e5ba19138.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTk5NjM0MTQsIm5iZiI6MTcxOTk2MzExNCwicGF0aCI6Ii82MjkwNjIxMS8zMTYxNDA5MTEtOTJmZGJlNjgtZWY0Yy00NzhhLThhZGItNmE0ZTViYTE5MTM4LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA3MDIlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNzAyVDIzMzE1NFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWE5MjJjNzBjZmI4NmZlMDhlZGVmYzIzOTkwNjgxOGM2NmJkZDhkZGRkYzUwZGZiMWU3ODMzN2VmYTI1YzQxZDMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.KHMEjCQumUBiGm4ZIeqVuyqxYRwtduEh65aw6B4kkHY)
S-101 copies this requirement:
![image](https://private-user-images.githubusercontent.com/62906211/316144840-c1c83220-3bd0-4a42-afec-4633be8e14c2.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTk5NjM0MTQsIm5iZiI6MTcxOTk2MzExNCwicGF0aCI6Ii82MjkwNjIxMS8zMTYxNDQ4NDAtYzFjODMyMjAtM2JkMC00YTQyLWFmZWMtNDYzM2JlOGUxNGMyLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA3MDIlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNzAyVDIzMzE1NFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTc2OTkxNWVmMGY2OGE2NzAzYjdhMGFmMjY1OTI2N2JmNTNmY2EyYzEyMDJlODg4Yjc3NmRhODkwNmNjZjY1OGMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.GATT52sERyvlcLaNwLNJ2RfV7pPgO1C3h2Qfd-HNzm4)
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](https://private-user-images.githubusercontent.com/62906211/316141197-2a3c8ad7-3e43-4f85-8588-fe6a1ff614b1.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTk5NjM0MTQsIm5iZiI6MTcxOTk2MzExNCwicGF0aCI6Ii82MjkwNjIxMS8zMTYxNDExOTctMmEzYzhhZDctM2U0My00Zjg1LTg1ODgtZmU2YTFmZjYxNGIxLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA3MDIlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNzAyVDIzMzE1NFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTBlZGQxMDMzNjBjNzgyNTk5MTYxMjMwMTViN2U3MzU0OGQwOWU0Yzk5YTI3NjJmYmFhM2Y0YWFiOTU2MThjYjImWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0._QJIWRtekctYZSkhSOU3WJWS6xsNRPHlntZTQiMzaDw)
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.
The text was updated successfully, but these errors were encountered: