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<[email protected]>:
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
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
