[Qgis-developer] Approximation and geoprocessing

[Bernhard Ströbl]

Hi Alexander,

thank you for the link. However it does not work in processing. Start 
the "Advanced Python field caluclator" from the tool box. Anything 
entered results in a Python runtime error:
"__init__() takes exactly 2 arguments (4 given)..."

Anybody successfully used this from processing?

Bernhard

Am 10.01.2014 15:59, schrieb Alexander Bruy:
> Hi Bernhard,
>
> there is a good article about Advanced Field Calculator [0], but
> only in Russian (there is a Google Translate in the right sidebar).
> Hope this helps a bit
>
> [0] http://gis-lab.info/qa/fieldpyculator.html
>
> 2014/1/10 Bernhard Ströbl<bernhard.stroebl at jena.de>:
>> Hi,
>>
>> I provided "eliminate sliver polygons" in the processing framework some
>> months ago (thanks for your help, Victor!). Eliminate is based on a certain
>> field. You would have to calculate the area (or area/perimeter) for all
>> polygons and use that as a threshold in "Eliminate sliver polygons". No idea
>> how to calculate that, though. How does the "Advanced python field
>> caluclator work"?
>>
>> Bernhard
>>
>> Am 10.01.2014 15:18, schrieb Andreas Neumann:
>>>
>>> Hi,
>>>
>>> I don't have a solution for the problem.
>>>
>>> But I can confirm that the whole analysis chain is a bit problematic
>>> with all these precision issues. As an example if you test intersections
>>> of buildings against parcels (2 different layers) and the building
>>> touches the parcel borders you may get very tiny intersects with parcels
>>> (only a few square cms) and you wouldn't want to include these
>>> intersections in your analysis.
>>>
>>> So it would be cool if for geometry tests there could be a notion of
>>> threshold values. If the area of an intersected polygon is below this
>>> value it wouldn't be taken into account during the analysis.
>>>
>>> These issues are really kind of show-stoppers and almost always require
>>> intermediate steps to sort out these edge cases. It would be very handy
>>> if the tools could handle this precision/uncertainty problems without
>>> having to do a lot of intermediate steps.
>>>
>>> Andreas
>>>
>>> Am 10.01.2014 15:01, schrieb Paolo Cavallini:
>>>>
>>>> Hi all.
>>>> I got into an interesting problem, before opening a few tickets I'd like
>>>> to discuss a line of action.
>>>> 1. Some sw (namely geomedia) produces shapefiles with very slight
>>>> differences (same layer, modified and exported several times); I suppose
>>>> this is due to truncation/approximation in coordinate precision.
>>>> 2. As a result, the diff between these layers produces a number of
>>>> virtually 0 width polygons, and some topological errors.
>>>> 3. This in turn leads to 2 problems:
>>>> 3.1. subsequent analyses fail because of the errors, and the user has no
>>>> clue about the reasons
>>>> 3.2. The microareas are tricky and time consuming to remove (if they are
>>>> isolated, a possible solution is to select and remove those smaller than
>>>> an arbitrary threshold, but if they are linked to some "real" polygons,
>>>> this will not work).
>>>> I would therefore suggest a few improvements over the toolchain, i.e.:
>>>> * add a parameter in analyses, to either snap original data within a
>>>> threshold before running the analysis, or to clean up the results
>>>> afterwards
>>>> * check&   warn the user of topo errors in source layers, and of possible
>>>>
>>>> wrong results; maybe this should be optional, as this will slow down the
>>>> analysis, and may be useless after first cleanup.
>>>>
>>>> Sample data available for those interested.
>>>>
>>>> All the best.
>>>>
>>>


__________ Information from ESET Mail Security, version of virus signature database 9281 (20140112) __________

The message was checked by ESET Mail Security.
http://www.eset.com