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 > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > _______________________________________________ Qgis-developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
