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