[Qgis-developer] QgsGeometry, Geos and SFCGAL

[Nyall Dawson]

On 10 March 2017 at 19:29, G. Allegri <giohappy at gmail.com> wrote:
> Recently I was studying SFCGAL [1], which most of you probably know, surely
> Oslandia's people :)
> I have done some tests with PostGIS and its option to swtich between GEOS
> and SFCGAL as its internal geometry engine (for 3D operations).
>
> I wondered if the current QGIS architecture could adapt to do something
> similar. I lost the thread about the geometry internals refactoring but I
> thought it was in the right fashion to support it with the QgsGeometryEngine
> interface (abstract class). However I see that the main entry point to the
> geometrical side of data, QgsGeometry, relies on the specific and unique
> current engine, QgsGeos.

I remember discussing this in the past with someone, but can't
remember who now! I originally thought that this would be a good
option - allowing users to select the geometry backend with choices of
GEOS/CGAL. But after discussing at length (again, I can't remember
where!) I'm got convinced that this would be a really bad thing. By
allowing users to select this we'd inevitably end up with users
changing this option just because it exists, because they "tried it
and found that rendering seemed a bit smoother", or because "someone
on stackexchange said they should change it", etc. End result is that
the results from geometry operations would no longer be predictable
when using the affected API functions.

Instead, a better approach is if we selectively change certain
operations to use a different backend only after we carefully evaluate
the results for each individual operation concerned. E.g. if we found
that SFCGAL resulted in intersections which are equally reliable as
GEOS, and faster in the majority of geometries, then we'd change
QgsGeometry::intersection to ALWAYS use SFCGAL.

In other words, it'd be nice to have this choice from a development
perspective, but the choice should not be exposed to users. (After
all, it's common knowledge that we know better then them in 100% of
situations ever, including in general life stuff like choosing a
mobile phone or what to eat for breakfast).


> I'm not as expert as most of you on complex software achitectures but I
> wondered why QgsGeometry refers to QgsGeos in its methods rather then using
> the QgsGeometryEngine interface? If the interface was used it would
> theoretically possible to "easily" switch between different engine (read a
> futurist QgsSFCGALEngine).

Given the above, I don't think there's a strong argument in favour of
the QgsGeometryEngine interface and we could potentially just have
QgsGeos/QgsSfcgal classes without the common interface.

On a related note - I once nearly did the work of allowing calling
SFCGAL methods on QgsGeometry, but stopped only after I realised I'd
mis-read the CGAL docs and that the particular method I was looking
for wasn't available. I was looking for a way to obtain the
approximate medial axis of a geometry (in order to generalise dual
carriageway roads to a single line geometry), but it turns out whilst
CGAL can generate skeletons it can't do the medial axis. There's still
a few interesting algorithms available through CGAL such as alpha
shapes, but I'd lean toward just reimplementing these in QGIS directly
and avoid the expense of going through multiple geometry engines. Of
course, it's entirely possible that we could benchtest and find that
CGAL geometry operations are faster than GEOS, in which case there's a
good justification for pulling in a SCGAL dependancy... but I'd
suggest testing this thoroughly before going to any effort!

Nyall