[Qgis-developer] Quick fixes and error communication for ftools

Tue Nov 24 07:36:07 PST 2015

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 at 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.hugentobler at sourcepole.ch  http://www.sourcepole.ch
>>>>> Technical Advisor QGIS Project Steering Committee
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Qgis-developer mailing list
>>>>> Qgis-developer at 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 at 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.hugentobler at sourcepole.ch  http://www.sourcepole.ch
>>> Technical Advisor QGIS Project Steering Committee
>>>
>>>
>>> _______________________________________________
>>> Qgis-developer mailing list
>>> Qgis-developer at 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 at 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.hugentobler at sourcepole.ch  http://www.sourcepole.ch
> Technical Advisor QGIS Project Steering Committee
>
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at 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.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20151124/5c8e8715/attachment-0001.html>