NetTopologySuite / NetTopologySuite.IO.GeoJSON

GeoJSON IO module for NTS.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

GEOJSON4STJ polygon orientation opposite to GeoJson specs?

rinkeb opened this issue · comments

commented

Hi,

I'm a little confused about the orientation of polygons as serialized bij StjGeometryConverter. The generated GeoJson output is not valid according to geojsonlint.com as it complains that 'Polygons and MultiPolygons should follow the right-hand rule'.

Im a bit new to GeoJson, but there seems to be a lot of confusion about what the right hand rule actually is. However, the spec at https://tools.ietf.org/html/rfc7946#section-3.1.6 states:

A linear ring MUST follow the right-hand rule with respect to the
area it bounds, i.e., exterior rings are counterclockwise, and
holes are clockwise.

Now for the interesting part: when looking at the source of StjGeometryConverter, it seems that the exterior ring is serialized clockwise instead:

WriteCoordinateSequence(writer, value.ExteriorRing.CoordinateSequence, options, orientation:OrientationIndex.Clockwise);

That might explain why geojsonlint complains about my generated GeoJson, but perhaps i am missing something here? Hope someone can help me out.

Im a bit new to GeoJson, but there seems to be a lot of confusion about what the right hand rule actually is. However, the spec at tools.ietf.org/html/rfc7946#section-3.1.6 states:

A linear ring MUST follow the right-hand rule with respect to the
area it bounds, i.e., exterior rings are counterclockwise, and
holes are clockwise.

The "right-hand rule" means that while you're walking along the points of the ring in the order that they're specified, the inside of the ring is on your right-hand side. This is consistent with "clockwise exterior ring, counterclockwise interior rings".

It's understandable that you would be confused; even the people who wrote the spec were confused. Note "Errata Exist" at the top of the spec. Errata 5069 covers this exact inconsistency.

commented

Thanks, the errata is indeed consistent with the workings of StjGeometryConverter.

Any idea why geojsonlint fails to validate the output then, being a common referenced site for GeoJson validation?

Any idea why geojsonlint fails to validate the output then, being a common referenced site for GeoJson validation?

I can't speak for other sites / projects, but we chose "right-hand rule" instead of "exterior rings are counterclockwise, and holes are clockwise" because E5069 exists, with the claim that this is how the ambiguity should be resolved (even though it's only "reported", not "verified").

Of course, the RFC also says:

Note: the [GJ2008] specification did not discuss linear ring winding order. For backwards compatibility, parsers SHOULD NOT reject Polygons that do not follow the right-hand rule.

The fact that the published spec is ambiguous is another great reason not to reject Polygons that wind the other way.

commented

Okay, so the interpretation of 'the spec' as CW or CCW actually depends on whether one acknowledges an unverified RFC errata or not. In my opinion, the decision to use one or another will then eventually depend on the specific use case and/or the involved consumers of the GeoJson output.

Would it make sense to make this configurable, for example via the GeoJsonConverterFactory? Maybe something similar as GeometryFactoryEx.OrientationOfExteriorRing, recently introduced via NetTopologySuite/NetTopologySuite#360 ?