Disclosure/caveat: more info on Elasticsearch Circle rendering

[warwickdufour]

Some time ago I submitted code to render Elasticsearch geo_shapes of type 'circle'. Having recently returned to working with GeoServer, Elasticsearch and GeoJSON I've had a few thoughts about that code, specifically regarding coordinate reference systems (CRSs) and how the circle is rendered.

At the time I wrote the code I needed it for use in the aviation domain, specifically to be able to visualise circular danger areas defined by a lat/lon centre and a radius in metres. For this purpose the radius is converted into a geodesic arc, one end of which is located at the circle centre and the bearing of which is (adaptively) varied to trace out a series of perimeter points which, when joined, approximate a circle.

This suited me fine as this is how a Circle is interpreted in this domain. On reading the GeoJSON spec again I became aware that this is not how someone used to GeoJSON might interpret a circle as GeoJSON's geometric primitives are defined using the WGS-84 CRS. The crucial part of the spec is:

"A line between two positions is a straight Cartesian line, the shortest line between those two points in the coordinate reference system."

This "straight cartesian line" almost certainly does not define a geodesic on the surface of a sphere (except in the case where it is joining two points with the same longitude). Although GeoJSON does not define a circle geometry, Elasticsearch does and it exists alongside other GeoJSON (geo_shape) features such as LineStrings and so it seems reasonable that the Elasticsearch Circle geo_shape definition would be in the same CRS as the other geo_shape primitives. If this is the case then an Elasticsearch circle would not define a 'geodesic circle' (as I have coded) and this would become more obvious the nearer the poles the circle was defined. This distortion can be seen on the attached image here:

Where 'geodesic circles' are displayed in an EPSG:4326 projection. There would be similar type of distortion if a circular shape in EPSG:4326 were mapped to the surface of the earth (see here and here for more info).

I've only written this note to highlight what may be a problem for some people and currently I have no idea what should be done, if anything.

[sjudeng]

Thanks for the summary on the implementation and potential caveats. I've been meaning to do some testing comparing JTS intersect queries with the geometries you produce here versus Elasticsearch queries with the corresponding circles indexed. I agree ideally we'd want to represent the circle as close to how Elasticsearch is treating it for querying as we can.

In the meantime and in preparing for the next release, I think the FAQ can be updated to include a note on this. I just noticed there's still a note in there that circles aren't supported, so that needs to be updated anyway. I can take a stab at this using your summary here unless you'd like to.

[warwickdufour]

I'm very happy for you to have a stab at it. There's not much I'd add anyway, the trick is to make it more concise but it's not very amenable to that as I've found it to be a complex subject that doesn't appear to be very important at first until one runs up against the edge cases. The question of just how GeoJSON lines are interpolated is not just restricted to ElasticGeo as I seem to remember the question arose when I looked at the rendering of large GeoJSON airspace boundaries in Cesium.

[sjudeng]

Right I think I'll just say that circle geometries are approximate and may not be fully consistent with the implementation in Elasticsearch, especially at extreme latitudes.

[warwickdufour]

Masterful contraction.