[Qgis-developer] Approximation and geoprocessing

[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.
>>>
>>
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>> __________ Information from ESET Mail Security, version of virus signature
>> database 9274 (20140110) __________
>>
>> The message was checked by ESET Mail Security.
>> http://www.eset.com
>>
>>
>
>
>
> __________ Information from ESET Mail Security, version of virus signature
> database 9274 (20140110) __________
>
> The message was checked by ESET Mail Security.
> http://www.eset.com
>
>
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer



-- 
Alexander Bruy