[Qgis-developer] QgsGeometry, Geos and SFCGAL

[Hugo Mercier]

Hi,

Thanks for the discussion.

SFCGAL is interesting for algorithms that are not yet present in other
geometry backends. Especially when dealing with 3D geometries.

We understand very well concerns that have been raised here.
For information, we are aware of some issues with SFCGAL that we
would like to tackle in the future:

- geometry conversion. We designed SFCGAL as yet another geometry
backend, with its own data structure to handle geometry primitives.
Converting back and forth between, say postgis internal format, and ours
takes some time.
The approach taken by boost::geometry where you can provide "adaptors"
for a specific internal geometry representation is a very good one. We
could imagine here SFCGAL as a set of algorithms (rather than a library
with its own data structure) that have adaptors to postgis geometries,
qgis geometries, etc.

- use of "exact" computations. It is interesting when you can store and
keep construction information in geometries (like "this point has been
constructed by the intersection of these two lines") because lots of
computations can afterward be avoided / simplified.
But as it is used now in postgis (and would be in qgis), all the
geometries are coming from raw floating point numbers without any
additional information. Which leads to slow conversion from doubles to
rational numbers, slow validity verification and slow algorithms. The
point about validity has been tackled and we should introduce a validity
flag on geometries in postgis hopefully soon.

For the more general case, a better approach would be to avoid using
exact computations for geometric constructions by using exact predicates
and inexact constructions and detecting validity issues. From last talks
with people from GeometryFactory that seems doable for algorithms that
work on 2D/3D meshes.

- python. Having a Python API would be very handy to play with the
library. This could probably be the way it gets used in qgis as a first
step.

So, next moves on SFCGAL would be to refactor it a bit so that it
gets faster and easier to integrate into existing libs / apps. If you
are interested in funding such new developments, feel free to contact us.


On 10/03/2017 10:29, G. Allegri 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'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).
> 
> I know this is a simplicistic view of the big picture, I imagine that
> there will be a lot of intricacies to decouple the geometry management
> from the geometrical engine. Anyway do you think that making the
> QgsGeometry (and its related friends) rely on an abstract engine would help?
> 
> Let's rephrase it: how much work would it require to implement
> (complete?) the engine decoupling?
> 
> Cheers,
> Giovanni
> 
> [1] http://www.sfcgal.org/
> 
> 
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>