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

Tue Nov 24 08:15:06 PST 2015

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
>>>>>>>> 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 <mailto: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
>
>  
>
>  
>
>
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20151124/3dd88e30/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20151124/3dd88e30/attachment-0001.sig>