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

Tue Nov 24 07:58:55 PST 2015

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

_______________________________________________
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 

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