[Qgis-developer] Approximation and geoprocessing

[Bernhard Ströbl]

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