Hi all
I had a detailed look with the debugger at what happens in the different
versions. It turned out fTools does indeed handle geometry collections,
but assumed a geometry collection has wkb type 'unknown' (which was true
<= 2.8, but now geometry collections are not unknown anymore). Commit
https://github.com/qgis/QGIS/commit/594fafe73b80d91d94b962c2e51aea0b0168a08a
should solve the issue and bring back the old behaviour.
Regards,
Marco
On 24.11.2015 11:29, Marco Hugentobler wrote:
On 24.11.2015 11:13, Matthias Kuhn wrote:
Hi Marco
On 11/24/2015 11:01 AM, Marco Hugentobler wrote:
Hi Alessandro, Matthias
>Is there no requirement for multi types?
Afaik, the problem for f-tools are not the multi types, but only the
geometry collections (containing geometries with different shape
type). In my experience, if geos returns a geometry collection, it
usually contains one 'expected' geometry and the others are slivers
(@strk, please correct me if wrong).
I was mostly thinking about collections that contain a multitype with
several parts which are not considered slivers. This seems to be a
very valid scenario.
It is, but it was also not handled by f-tools <= 2.8.
>Based on what indicator should be chosen what to extract? Try
polygons first, if there are none try lines, if there are none take
points?
One possibility would be to pass the expected shapetype (Point /
Line / Polygon) to the function and take the best candidate (e.g.
longest line, largest polygon area).
Before the geometry changes, the algorithms were able to provide the
results without this additional information. How was that done?
Not sure. Maybe the logic in the geos -> QgsGeometry conversion
handled the collections differently.
Regards,
Marco
>How much effort (in time) do you think is required to implement
this fix?
Difficult to estimate. It seems straightforward to implement the
extraction function. Then it needs to be called by the f-tools
internally and be tested with a few examples. If unit tests are
required (as mentioned by Alessandro), this seems to be the most
time consuming task to me.
Unit Tests for processing are on my todo list anyway (I think as a
psc member you should have voted for that ;) )
Matthias
Regards,
Marco
On 24.11.2015 10:42, Matthias Kuhn wrote:
Hi Marco
Good to have your feedback, you probably know the problem best.
On 11/24/2015 09:28 AM, Marco Hugentobler wrote:
Hi
>ad issue 1: update fTools to warn users when some features cause
problems
>ad issue 2: quick fix fTools to convert geometry collections to
single geometry types
A function that takes a geometry type and extracts the longest
line / the largest polygon / the first point from the geometry
collection should be straightforward to do.
Is there no requirement for multi types?
Based on what indicator should be chosen what to extract? Try
polygons first, if there are none try lines, if there are none take
points?
>These fixes/updates would be made available as fTools updates via
the plugin installer asap
If the fix does not take too long, we probably don't need a
warning at all.
How much effort (in time) do you think is required to implement
this fix?
Regards,
Matthias
Regards,
Marco
On 23.11.2015 21:35, Anita Graser wrote:
Hi,
If you are following the psc list, you've probably seen the
thread discussing current shortcomings of ftools
(http://lists.osgeo.org/pipermail/qgis-psc/2015-November/003623.html)
In short, the key issues are:
1. When ftools encounter issues with certain features, warning
messages get written to the log but this is largely hidden from
users since they would actively have to actively monitor the log.
The problematic features are then missing from the results but
this is not always obvious.
2. The above issue is more common now (since 2.10) since
underlying libraries more often (and correctly so) produce
geometry collections as outputs. These geometry collections are
not handled well by the current ftools code which is much older.
To address these issues, the following suggestions have been made
so far:
ad issue 1: update fTools to warn users when some features cause
problems
ad issue 2: quick fix fTools to convert geometry collections to
single geometry types
For the warnings, there's already a first PR draft
https://github.com/qgis/QGIS/pull/2432 which needs to be fleshed
out.
These fixes/updates would be made available as fTools updates via
the plugin installer asap.
If you have ideas how to handle this efficiently or have already
implemented code that addresses similar issues, let us know.
It would be good to have a quick discussion in order to be able
to provide improvements fast.
Best wishes,
Anita
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info:http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe:http://lists.osgeo.org/mailman/listinfo/qgis-developer
--
Dr. Marco Hugentobler
Sourcepole - Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentob...@sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info:http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe:http://lists.osgeo.org/mailman/listinfo/qgis-developer
--
Matthias Kuhn
OPENGIS.ch -https://www.opengis.ch
Spatial • (Q)GIS • PostGIS • Open Source
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info:http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe:http://lists.osgeo.org/mailman/listinfo/qgis-developer
--
Dr. Marco Hugentobler
Sourcepole - Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentob...@sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info:http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe:http://lists.osgeo.org/mailman/listinfo/qgis-developer
--
Matthias Kuhn
OPENGIS.ch -https://www.opengis.ch
Spatial • (Q)GIS • PostGIS • Open Source
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info:http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe:http://lists.osgeo.org/mailman/listinfo/qgis-developer
--
Dr. Marco Hugentobler
Sourcepole - Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentob...@sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
--
Dr. Marco Hugentobler
Sourcepole - Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentob...@sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
