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

Marco Hugentobler marco.hugentobler at sourcepole.ch
Tue Nov 24 02:01:49 PST 2015


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).

 >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
>>> 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

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


More information about the Qgis-developer mailing list