Hi all,
Am 24.11.2015 um 11:01 schrieb Marco Hugentobler:
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).
There *could* be another problem, too [1]: 2.5D geometries, although I
did not investigate this it should be checked because users cannot see
the difference between them and regular 2D geometries.
Bernhard
[1] http://hub.qgis.org/issues/13167
>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).
>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.
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
[email protected]
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
[email protected] http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee
_______________________________________________
Qgis-developer mailing list
[email protected]
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
[email protected]
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
[email protected] http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee
__________ Information from ESET Mail Security, version of virus
signature database 12614 (20151124) __________
The message was checked by ESET Mail Security.
http://www.eset.com
_______________________________________________
Qgis-developer mailing list
[email protected]
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
__________ Information from ESET Mail Security, version of virus signature
database 12614 (20151124) __________
The message was checked by ESET Mail Security.
http://www.eset.com
_______________________________________________
Qgis-developer mailing list
[email protected]
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
