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.stro...@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@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@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Alexander Bruy _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer