I was wondering if the WFS/WMS specs (any version) define an order for polygon vertices (either in WKT or in GML geometries). I found a line in https://www.ogc.org/publications/standard/sfa/ that says:
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. The interior LinearRings will have the opposite orientation, and appear as clockwise when viewed from the “top”
For reference, in GeoMesa we don’t assume any winding order, and use JTS to evaluate polygons, which means that any span > 180 degrees longitude gets interpreted as wrapping the opposite way (around the anti-meridian). In order to wrap the other way, you need to insert some waypoints. For example, POLYGON((-179 10, -179 -10, 179 -10, 179 10, -179 10)) is interpreted as at 2-degree longitude span, even though using counter-clockwise winding it would have a 358 degrees longitude span.
But recently someone asked if this was the correct behavior, and I’m not entirely sure. Any guidance would be helpful!
GML (the geometry format used by WFS / WMS) does specifies a winding order. I do not think it is required for SFSQL either.
This link indicates that counter-clockwise is specified for simple features, and clockwise for shape files, before going through other options like GeoJSON (no order).
If you have capacity there was a the good idea to make a geometry transformation function to provide a winding order (for consistent styling offset lines).
Hi Emilio,
I’ve searched for the same a few times, and could not find such a thing.
One specification that mentions winding order is mapbox vector tiles, but in that case, one cannot just go
the opposite direction (the specified winding order is mandatory).
Regardling dateline crossing, the only reference I’m aware of in OGC specs
is bounding boxes in WCS 2.0 and OGC APIs: if a bounding box has a min longitude
that is greater than the max longitude, then it’s supposed to span the dateline, e.g.:
170,40,-170,60
is supposed to cover a 20x20 degrees box crossing the dateline.
For reference, I tried cql_filter on a wms PostGIS layer using GeoServer 2.24.4, and it did not make any difference what order I specified the coordinates in. In both cases (intersects(geom,POLYGON((-179 10, 179 10, 179 -10, -179 -10, -179 10))) and intersects(geom,POLYGON((-179 10, -179 -10, 179 -10, 179 10, -179 10)))) it interpreted the polygon as spanning the whole globe, and not crossing the anti-meridian.
I believe that a polygon crossing the antimeridian is a different thing than the winding order in this context. With geometry data type it is common to play with cartesian coordinates and you should split the polygon that crosses the antimeridian into two halves. See similar example “Antimeridian cutting” in the GeoJSON specification RFC 7946 - The GeoJSON Format.
Programs which can deal with geography datatype know to select the shorter route. For example PostGIS 18. Geography — Introduction to PostGIS
No surprise there.
For the example of the BBOX that I mentioned before, at parse time the dateline crossing is recognized and the filter turned into two ORed bbox filters, on either side of the dateline: that’s the only way to make it work across all data sources
(a tiny fraction of which could understand dateline cross to start with, and only if using the right datatype).
So if there were to be a specification at the OGC level for polygon filtering, we’d have to do the same: slice and OR.