Thank you Marco! Much appreciated.
Andreas On 2015-11-24 16:36, Marco Hugentobler wrote: > 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 > [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 _______________________________________________ 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 _______________________________________________ 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
_______________________________________________ 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
