<div dir="ltr"><div>Hi all,<br><br>If I understood correctly, someone added very recently the support of QgsExpressions in the processing toolbox. This could help I suppose ?<br><br></div>Michael<br></div><div class="gmail_extra">
<br><br><div class="gmail_quote">2014/1/10 Alexander Bruy <span dir="ltr"><<a href="mailto:alexander.bruy@gmail.com" target="_blank">alexander.bruy@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Bernhard,<br>
<br>
there is a good article about Advanced Field Calculator [0], but<br>
only in Russian (there is a Google Translate in the right sidebar).<br>
Hope this helps a bit<br>
<br>
[0] <a href="http://gis-lab.info/qa/fieldpyculator.html" target="_blank">http://gis-lab.info/qa/fieldpyculator.html</a><br>
<br>
2014/1/10 Bernhard Ströbl <<a href="mailto:bernhard.stroebl@jena.de">bernhard.stroebl@jena.de</a>>:<br>
<div class="HOEnZb"><div class="h5">> Hi,<br>
><br>
> I provided "eliminate sliver polygons" in the processing framework some<br>
> months ago (thanks for your help, Victor!). Eliminate is based on a certain<br>
> field. You would have to calculate the area (or area/perimeter) for all<br>
> polygons and use that as a threshold in "Eliminate sliver polygons". No idea<br>
> how to calculate that, though. How does the "Advanced python field<br>
> caluclator work"?<br>
><br>
> Bernhard<br>
><br>
> Am 10.01.2014 15:18, schrieb Andreas Neumann:<br>
>><br>
>> Hi,<br>
>><br>
>> I don't have a solution for the problem.<br>
>><br>
>> But I can confirm that the whole analysis chain is a bit problematic<br>
>> with all these precision issues. As an example if you test intersections<br>
>> of buildings against parcels (2 different layers) and the building<br>
>> touches the parcel borders you may get very tiny intersects with parcels<br>
>> (only a few square cms) and you wouldn't want to include these<br>
>> intersections in your analysis.<br>
>><br>
>> So it would be cool if for geometry tests there could be a notion of<br>
>> threshold values. If the area of an intersected polygon is below this<br>
>> value it wouldn't be taken into account during the analysis.<br>
>><br>
>> These issues are really kind of show-stoppers and almost always require<br>
>> intermediate steps to sort out these edge cases. It would be very handy<br>
>> if the tools could handle this precision/uncertainty problems without<br>
>> having to do a lot of intermediate steps.<br>
>><br>
>> Andreas<br>
>><br>
>> Am 10.01.2014 15:01, schrieb Paolo Cavallini:<br>
>>><br>
>>> Hi all.<br>
>>> I got into an interesting problem, before opening a few tickets I'd like<br>
>>> to discuss a line of action.<br>
>>> 1. Some sw (namely geomedia) produces shapefiles with very slight<br>
>>> differences (same layer, modified and exported several times); I suppose<br>
>>> this is due to truncation/approximation in coordinate precision.<br>
>>> 2. As a result, the diff between these layers produces a number of<br>
>>> virtually 0 width polygons, and some topological errors.<br>
>>> 3. This in turn leads to 2 problems:<br>
>>> 3.1. subsequent analyses fail because of the errors, and the user has no<br>
>>> clue about the reasons<br>
>>> 3.2. The microareas are tricky and time consuming to remove (if they are<br>
>>> isolated, a possible solution is to select and remove those smaller than<br>
>>> an arbitrary threshold, but if they are linked to some "real" polygons,<br>
>>> this will not work).<br>
>>> I would therefore suggest a few improvements over the toolchain, i.e.:<br>
>>> * add a parameter in analyses, to either snap original data within a<br>
>>> threshold before running the analysis, or to clean up the results<br>
>>> afterwards<br>
>>> * check&  warn the user of topo errors in source layers, and of possible<br>
>>><br>
>>> wrong results; maybe this should be optional, as this will slow down the<br>
>>> analysis, and may be useless after first cleanup.<br>
>>><br>
>>> Sample data available for those interested.<br>
>>><br>
>>> All the best.<br>
>>><br>
>><br>
>> _______________________________________________<br>
>> Qgis-developer mailing list<br>
>> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
>> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>><br>
>><br>
>> __________ Information from ESET Mail Security, version of virus signature<br>
>> database 9274 (20140110) __________<br>
>><br>
>> The message was checked by ESET Mail Security.<br>
>> <a href="http://www.eset.com" target="_blank">http://www.eset.com</a><br>
>><br>
>><br>
><br>
><br>
><br>
> __________ Information from ESET Mail Security, version of virus signature<br>
> database 9274 (20140110) __________<br>
><br>
> The message was checked by ESET Mail Security.<br>
> <a href="http://www.eset.com" target="_blank">http://www.eset.com</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Qgis-developer mailing list<br>
> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Alexander Bruy<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a></div></div></blockquote></div><br></div>