Thank you Marco, Are you confident that these are the only places that need changes, so does this mean that there is no more reason for a warning and we just need a quick point release? I applied the same to processing and did some changes to your fix to make it work also for union and clip.
Regards Matthias On 11/24/2015 04:58 PM, Neumann, Andreas wrote: > > 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] <mailto:[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 -- 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
