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. > > >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? > > >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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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
