<div dir="ltr">Recently I was studying SFCGAL [1], which most of you probably know, surely Oslandia's people :)<div>I have done some tests with PostGIS and its option to swtich between GEOS and SFCGAL as its internal geometry engine (for 3D operations).</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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?</div><div><br></div><div>Let's rephrase it: how much work would it require to implement (complete?) the engine decoupling?</div><div><br></div><div>Cheers,</div><div>Giovanni</div><div><br></div><div>[1] <a href="http://www.sfcgal.org/">http://www.sfcgal.org/</a></div></div>