On 10 March 2017 at 19:29, G. Allegri <gioha...@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 _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer