# Semantics of polygon points - How to join the dots?

The question arise from reading the standard "OGC® Sensor Planning Service Interface Standard 2.0 Earth Observation Satellite Tasking Extension", that you can get from http://www.opengeospatial.org/standards/sps (Although, I think it is more general and also applies to kml standard too).

Suppose I receive a Polygon expressed in terms of WGS84 UTM latitude longitude points, how should I interpret that set of points? I mean, how should I build the polygon from the points?:

1. Should I use straight lines in the lat lon plane (linear interpolation between points in the lat lon plane)?
2. Should I use great circle curves to join contiguous points?
3. Should I use the geodesic curves in the WGS84 ellipsoid?
4. Must this be explicitly specified in the interface?

Specifically, I'm asking about the RegionOfInterest class that contains a Polygon class in page 31 of that standard.

If it's UTM, that means Universal Transverse Mercator, and by definition it uses a 2-dimensional Cartesian coordinate system to give locations on the surface of the Earth (From wikipedia).

If your data are in long, lat then they are points at the ellipsoid.

The correct way would be to use geodesic curves between your points, and then project those curves to Mercator.

OGC Simple Feature Access - Part 1: Common Architecture defines for the length of a curve (which is the basis of a LineString) that a program should return it as a double in its associated spatial reference.

So in my interpretation if your program would return the lenght between two points in UTM, then it would be as simple as using the Pythagorean theorem, but if you were in a ellipsoid crs defined system you'd use geodesic curves - linearal interpolation between subpoints between your points. So depenting in your srs you would need two methods. It's quite open to interpretation to tell you the truth.

Postgis seems to go in that direction, with the implementation of geographic datatype and functions that work with it, giving the user the option to do the calculations in the ellipsoid (WGS84 ellps so far i think), and so does Microsoft's SQL Server while retaining the ability to do the calcuation to a geometry plane.

Again im not an expert on the subject; The above is mostly for you to start from something.

• Thank you for the answer. I'm wondering about the semantics of the polygons, I mean, about the correct interpretation of the polygons in the standards. Please, correct me if I'm wrong. From your answer, I understand that the correct way of interpreting WGS84 polygons is to join points with the geodesic curves of WGS84 ellipsoid, which sounds natural and sound. Just because we are talking about standards, do you have any reference (other standard, web link, famous book, etc) to support this idea? – eguaio Oct 19 '15 at 18:16
• Reviewing that standard it tells, as you say (page 22): "The length ... in its associated spatial reference", but in the same page it tells "A LineString is a Curve with linear interpolation between Points." Look at page 11, it states points are joined with segments (and mention the formula t*p0+(1-t)*p1 for 0<= t <=1), referencing to ISO 19107 standard . So, I guess it is as you say, open to interpretation. But if so, I could not believe the OGC interface standards did not include an explicit and exact way of defining what is the interpretation you are implementing. – eguaio Oct 20 '15 at 13:06

I finally got to read the ISO 19107 standard that is referenced in the OGC standard to define polygons. Apparently, the GM_Polygon contains GM_SurfaceBoundary and GM_Surface (as exterior and interior rings). In turn, GM_Surface is a GM_Ring, that in turn is a GM_Curve with other properties, that is in turn a sequence of GM_CurveSegments.

And we finally got it. A GM_CurveSegment is an abstract type that has GM_LineString and GM_GeodesicString as successors. GM_LineString is a sequence of GM_LineSegments and GM_GeodesicString is a sequence of GM_Geodesics.

A GM_LineSegment has two points and must be interpolated linearly. A GM_Geodesic also has two points but must be interpolated with geodesic curves.

In our case, this means that, as far as the standard specifies, if a polygon contain a a GM_LineString as its boundary, the interpolation must be done linearly in the lat-lon plane, specially if no interpolation attribute is present.

On the other hand, if the Polygon contains a GM_GeodesicString, the interpolation must be done by using the geodesic curves of the associated spacial referenced (WPS84 ellipsoid in our case).

What is strange to me is that, as far as my little experience in this field can tell, Polygon exteriors are always defined in terms of a LinearRing, and nothing is said about the interpolation method. This means that according to the standard, linear interpolation must be used. I guess that this is an extended practice, and when someone needs to interpret the polygon with geodesic interpolation, this is done in the implementation, not complying with the standard.

And with KML, things get more confusing, since a polygon can only contain LineStrings (there is not such thing as GeodesicString).

See https://developers.google.com/kml/documentation/kmlreference#linearring. In this link, there is even a note that tells: "Note: In Google Earth, a Polygon with an of clampToGround follows lines of constant bearing; however, a LinearRing (by itself) with an of clampToGround follows great circle lines."

That is, Google Earth shows great circle lines to join polygon points, and there is no explicit way to specify the semantics of the polygon lines. I think this is a not minor issue of KML as a geographical data standard.

• The Google Earth documentation lies. Polygon edges are not lines of constant bearing (straight lines on a Mercator projection). Instead, they are straight lines in latitude-longitude space (i.e., straight on a plate carree projection). I've pointed out the discrepancy; but no one at Google cares. – cffk Oct 21 '15 at 0:08