[Qgis-developer] Approximation and geoprocessing

[Bernhard Ströbl]

Hi,

it depends...
Processing works as follows: take input layer(s) - do a process - create 
output layer
So if the "process" is a selection the result is an output layer with 
only the selected features included.
Therefore for "eliminate" I included a simple logical selection based on 
a field in the layer. Thus to use eliminate in a model you first have to 
create an input layer with a field that somehow marks all features to be 
eliminated (e.g. caluclate area/perimeter). Currently I do not know how 
this can be achieved. :-(
Any hints welcome.

Bernhard

Am 10.01.2014 16:04, schrieb kimaidou:
> Hi all,
>
> If I understood correctly, someone added very recently the support of
> QgsExpressions in the processing toolbox. This could help I suppose ?
>
> Michael
>
>
> 2014/1/10 Alexander Bruy <alexander.bruy at gmail.com
> <mailto:alexander.bruy at gmail.com>>
>
>     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
>     <mailto: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
>     <mailto: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
>     <mailto:Qgis-developer at lists.osgeo.org>
>      > http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
>     --
>     Alexander Bruy
>     _______________________________________________
>     Qgis-developer mailing list
>     Qgis-developer at lists.osgeo.org <mailto:Qgis-developer at lists.osgeo.org>
>     http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>



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

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