Re: [Qgis-developer] QgsGeometry, Geos and SFCGAL
On 10 March 2017 at 19: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 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
[Qgis-developer] Extra 2.14 LTR lifespan by two months?
Hi, After reviewing the release schedule recently put forward [0], I notice a discrepancy between what the project has advertised (1 year LTRs for 2.x) and when the upcoming LTRs are to released/packaged. Here is the schedule, pruned of non-relevant dates (with one proposed new packaging date for 2.14): LTR 2.14.0 Mar 01, 2016 LR 2.16.0 Jul 22, 2016 (2.14 LTR packaged) LR 2.18.0 Nov 08, 2016 LTR 2.18.7 May 19, 2017 *PR 2.18.9 Jul 21, 2017 (2.18 LTR packaged - proposed) FF (2.99) Aug 18, 2017 LR 3.0.0 Sep 29, 2017 (2.18 LTR packaged - current) FF (3.1) May 18, 2018 LTR 3.2.0 Jun 29, 2018 LR 3.4.0 Oct 26, 2018 (3.2 LTR packaged) What this shows is that the lifespan of 2.14 was extended by just over two months. While two months may not seem that long, is there a reason for not packaging the 2.18 LTR twelve months after 2.14 LTR packaging? Besides sticking with the advertised 1 year for 2.x LTRs, changing the *packaging-only* release date for 2.18 to Jul 21, 2017 offers these advantages: * Project management of the 2.x branches can be closed out a month prior to the FF on 2.99. This keeps focus of release on the move forward to 3.0.0, instead of mixing 2.x and 3.x releases, i.e. a clean break from 2.x releases, making 3.0.0 the only focus when it is released. * Regressions and bugs for 2.18 LTR, as reported by Giovanni [1], may not get fixed if project focus is split between the 3.0.0 FF/release and 2.18 release. Keeping the community focused on finishing up problems with 2.x and then 100% focus on 3.0.0, prior to the FF, avoids any split in limited dev resources. I do see the balance provided by the Sep 29, 2017 packaging date for 2.18 LTR: 14 months since 2.14 packaging and 13 months until 3.2 packaging. However, the 2.x releases really do not need 'tied' to the 3.x releases in any way. Having 15 months between 2.18 and 3.2 is more reasonable than extending the time current LTR users have to wait for 2.18 LTR packages. Opinions on proposed change of 2.18 packaging-only date? Please note: this suggests no change whatsoever with the 3.x release schedule. [0] http://qgis.org/en/site/getinvolved/development/roadmap.html#release-schedule [1] http://osgeo-org.1560.x6.nabble.com/bug-tracker-cleanup-td5311756.html Regards, Larry Shaffer -- Boundless Desktop and QGIS Support/Development Boundless Spatial - http://boundlessgeo.com lshaf...@boundlessgeo.com ___ 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
[Qgis-developer] New Processing option menu troubles
Hi all, I just compiled QGIS and I found that the Processing options are in the Settings -> Options menu That's great, it avoid confusions for the users. Anyway I'm experiencing some trouble when using the filtering boxes to search the options (another super cool feature!): * using the general filter box, it does not filter the Processing options * very oftern the Processing options filter freezes QGIS when trying to filter some strings and I have to kill QGIS (it happens not always, but very often) Wouldn't be more coherent to have just one filter (the general one) that looks also the Processing options and get rid of the Processing one? Just my 2cents Cheers Matteo ___ 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
[Qgis-developer] bug tracker cleanup
Hi all, Over the past few days I was tasked with the periodical triage and cleanup the the QGIS bug tracker. As usual I focused on the issues that supposed to be more serious, specifically (known) regressions (priority = “severe”) and the ones that are known to cause crashes or data corruption (priority = “high”): causing crashes: http://hub.qgis.org/projects/quantum-gis/issues?query_id=116 regressions: http://hub.qgis.org/projects/quantum-gis/issues?query_id=115 The regressions list grouped by affected version is useful to understand that I tagged as “affected version = master” the ones that are really only affecting the QGIS 3 master branch. There may be more regressions or “causing crashes” issues hidden in the very large list (1300+) of issues tagged as “normal”: I have done my best to spot as many as possible but is not a quick task. Many issues are very poorly reported, needing quite an effort to test them. The good news is that now there are a good number of issues awaiting feedback because I was not able to replicate them locally (usually on multiple platforms). Anyway… if you are aware of any regression or causing crash issue now tagged as “normal” please let me know or just change the priority accordingly. Speaking about the severe list you may have noticed that there are issues that are known since a long ago, but there are also others that are *pretty recent*, in fact there are a few regressions that have slip into 2.18 since 2.14. Releasing now 2.18 as new LTR would mean effectively releasing a worse QGIS compared to 2.14. I would like to understand if before the release of the next LTR there will be scheduled bug fixing effort, as has been done for other releases; and, if in this is the case, it will be a targeted one, in order to give the priority to regressions that have appeared between 2.14 and 2.18. With regards -- Giovanni -- Note: we should really do something to ask people to be more disciplined when posting issues, making for example the category mandatory and somehow help choosing the correct priority > ex: if is a regression then “severe”, if causes a crash then “high”, use normal for all the other cases. We should also state/force the users to try in a clean environment, with no 3rd party plugins before reporting. Note2: I would really like to do a major cleanup of the tracker in Essen. ___ 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
[Qgis-developer] Plugin [1146] layer2kmz approval notification.
Plugin layer2kmz approval by pcav. The plugin version "[1146] layer2kmz 1.2" is now approved Link: http://plugins.qgis.org/plugins/layer2kmz/ ___ 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
[Qgis-developer] Plugin [740] qgis2web approval notification.
Plugin qgis2web approval by pcav. The plugin version "[740] qgis2web 2.8.0" is now approved Link: http://plugins.qgis.org/plugins/qgis2web/ ___ 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
Re: [Qgis-developer] New branch for 3.x documentation (master_3x)
Le mercredi 8 mars 2017, 08:30:13 CET Matthias Kuhn a écrit : > Instead I would propose to follow the branching schema of QGIS. On > github you can define the "default branch" in the repository settings to > release-2_18, so pull requests will be opened against this branch by > default at the moment. I agreed, late, but I agree. It was in my first proposition. Y. ___ 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
[Qgis-developer] QgsGeometry, Geos and SFCGAL
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@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Port Password Helper plugin into core
Sorry to threadjack, but a related question: Larry I think mentioned maybe removing the Python bindings for the auth system. Is that still the intention? Nyall has implemented FTP upload in qgis2web (other connection types such as SCP, SFTP can be developed using this framework). However, securely saving the password would be a real benefit. The auth system would be the most secure way to achieve this, obviously. If the Python bindings are to be removed, there's no point in using them to allow password saving. - Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Port-Password-Helper-plugin-into-core-tp5311418p5311718.html Sent from the QGIS - Developer mailing list archive at Nabble.com. ___ 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