Add support for arcs and circles

[sweco-nlgemo]

Background

The Dutch government has defined a geo standard named Basisregistratie Grootschalige Topografie (BGT, in Dutch), which is a registration for a large scale map of the Netherlands.

One aspect that makes this standard somewhat different from other Dutch geo standards is that geometries can have arc(segment)s in them. Circles on the other hand are not allowed; they have to be converted to a curve consisting of two arcsegments.

To exchange objects with this registration, files and SOAP Webservices are used. In both cases the format is XML and the geometries are encoded with GML 3.1.1.2.

Issue

We would like to make this BGT data also available through a (REST) API and GeoJSON seems to be the standard for encoding geometries in JSON.

Besides the fixed CRS problem, we immediately encountered the issue that the GeoJSON standard RFC7946 prescribes linear interpolation between points in a line. This makes GeoJSON unusable for our goal, since there is no way to encode arcs.

Suggestion

Please add arc and circle support to JSON-FG to give it parity with existing standards like GML and WKB.

Arcs and circles are a natural part of curves and polygons in XML, which might make this approach difficult to apply to JSON-FG, since this format also has to be valid GeoJSON. This would for example mean that a polygon is placed in the GeoJSON part only if all rings of the polygon are linear rings, in all other cases the polygon would be placed in the where part.

The approach used by WKB might be more straightforward, since WKB basically has two parts. One part is for linear interpolation which maps to GeoJSON and geometries can therefore be placed in the GeoJSON part:

WKB	GeoJSON
Point	Point
MultiPoint	MultiPoint
LineString	LineString
MultiLineString	MultiLineString
Polygon	Polygon
MultiPolygon	MultiPolygon
GeomCollection	GeometryCollection

The second part of WKB adds support for arcs and circles:

• CircularString
• CompoundCurve
• MultiCurve
• CurvePolygon
• MultiSurface

These geometries could thus be placed in the where part.

[cportele]

Thank you. The charter identifies curves with non-linear interpolation as out-of-scope for the first version. That said, if it turns out that circular arcs are a special case that would be important to support and that is not much overhead for implementations, because database backends and geometry libraries support arcs (and curve/surface types to mix line strings and arcs), maybe they could be included as an additional conformance class?

The GML Simple Feature Profile also includes support for circular arcs (in addition to line strings) and GeoPackage includes an extension/conformance class for Non-Linear Geometry Types.

[sweco-nlgemo]

Is there a roadmap on when non-linear interpolation will be in scope?

Currently arcs are used in an official registration, so we have to support it. This is no problem with GML, but it also means we are stuck with GML, since I cannot find a viable JSON alternative. We could roll our own, but I'd rather use an official standard.

[cportele]

Meeting 2022-02-07: If it would be added, it would be a separate conformance class. There are important use cases that depend on arcs (or circles), but we are also concerned that this may be complicated for web developers. We are open to supporting this in JSON-FG. This would likely not be in the Core, but in an extension. We are open to work on this in parallel to the Core and see how much momentum this develops.

We discussed the question why solids are currently in Core, but arcs not. When the charter was developed, 3d solids were considered as in frequent use in web applications and used by web developers, for arcs this less the case (even though they are essential for some communities). But eventually we should determine how much support we see for certain features in implementation and how well they work and then make a decision what ends up in Core and what in an extension.

@sweco-nlgemo - Would you be interested in making a proposal to get the discussion started?

[sweco-nlgemo]

I am definitely interested in making a proposal if it helps the discussion. I will use the template document and get started as soon as possible.

[cportele]

Thank you, the proposal is now available at https://github.com/opengeospatial/ogc-feat-geo-json/blob/main/proposals/circular-geometry-objects.adoc and ready for comments.

[cportele]

Meeting 2022-11-14:

We need to discuss two separate aspects:

• Review the proposal to discuss the technical aspects in the next meeting.
• We need to discuss, if such a conformance class should be added in Core or in an extension. Currently the tendency is an extension, because non linear interpolation requires much more complex mathematical processing. An indicator for maturity and demand is also if such an extension would have multiple implementations.

[cportele]

Meeting 2023-01-09:

• We should start to review the proposal now.
• @rouault already added comments in Comments on circular-geometry-objects.adoc proposal #77.
• Homework: review the proposal and discuss in the next meeting.
• GeoPackage also has an extension and CDB is looking at adding support for circles and arcs, too.
• The Frascati meeting could be a good opportunity to discuss the topic and whether to include support with a larger audience.

[pathmapper]

+1 for adding support for arcs because it might help to adopt the OGC API - Features standard.

In Germany it's also the same situation that governmental cadastre data (ALKIS) includes geometries with circular arcs.
For our open data they are currently served via WFS as GML.
We are currently debating if we should offer them also via OGC API - Features, but the lack of support of circular arcs with GeoJSON might be a blocker.
And serving only GML via OGC API - Features ... - then we might keep serving them only as GML via WFS as we are doing currently.

[m-kuhn]

Same situation in Switzerland, official cadastre data includes arcs and for certain use cases support for arcs is required. One such case would be an OGC API - Features endpoint with transaction support for editing cadastral data, so we effectively need to preserve geometries.

[andrewhunter2066]

For cadastral datasets arcs are commonly encountered. Circles less frequently, but examples do exist, e.g.., mining leases have been defined by a centre point and radius. It would be helpful to include alternative representations for arc and circle. Some common approaches used within the cadastral domain include Arc Segment with Centre, Arc Segment by Chord, and Circle by Centre.

Arc Segment with Centre requires specification of three points being the start, centre and end points of the arc, along with arc orientation, is it drawn clockwise or anticlockwise from the start point to the end point. Radius could optionally be included to limit computation. This is a common approach as the start and end points are the tangent points of a circular arc of a specific radius fit to a pair of linear boundary lines that intersect.

Arc Segment by Chord requires specification of the start point, direction of chord, length of cord, radius, and whether the arc is left or right of the chord. Cadastral data often includes the end point as well, being a boundary monument defining the end of the curve and the start of a linear boundary. I am aware of a number of survey jurisdictions that require documentation of an arc's chord (direction and length) as part of the specification of an arc boundary.

Circle by Centre can be specified by a centre point and radius, i.e., the mining lease example above.

Cadastral data often allows non-linear curves as well (typically represent natural features defining boundaries), cubic splines being the predominant form. A cubic spline is defined in ISO 19107as a polynomial spline of degree 3, and is described by unit tangent vectors at the start and end points of the spline and at least three control points including the start and end points. The direction of the start and end tangent vectors are used to determine the shape of the cubic spline.

[Rikuoja]

+1 here, at least the City of Helsinki depends on arcs in land use planning in Finland.

They cannot be transferred to the national land use planning API until arc segments are supported in JSON-FG.

[cportele]

Meeting 2024-05-27: We agreed to work on a pull request to add support in a new requirements class based on the proposal and the comments in #77. The pull request should to be ready for discussion at the next OGC member meeting in June (if we can find a slot).

• The basic requirement is to be able to represent curves (and rings) that are a sequence of line strings and arcs. In addition we need higher order geometry types like the CurvePolygon.
• It is unclear, if we really need circle or if arcs are sufficient (a circle can also be represented using arcs). If there is no compelling need to include a circle geometry type we should omit this.
• In terms of names we should stick to the names of the related SQL/MM extensions as close as possible.

[andrewhunter2066]

Re arcs for circles, it depends on the use case requirements. Within the cadastral space a circular parcel represents an areal unit whereas an arc does not. So IMHO a circle data type is a better representation.