Re: [Qgis-developer] QgsGeometry, Geos and SFCGAL

2017-03-10 Thread Nyall Dawson 
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] New Processing option menu troubles

2017-03-10 Thread matteo 
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

2017-03-10 Thread Giovanni Manghi 
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.

2017-03-10 Thread noreply 

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.

2017-03-10 Thread noreply 

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)

2017-03-10 Thread Yves Jacolin 
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

2017-03-10 Thread G. Allegri 
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

2017-03-10 Thread Tom Chadwin 
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