[Qgis-developer] Approximation and geoprocessing

kimaidou kimaidou at gmail.com
Fri Jan 10 07:04:53 PST 2014


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>

> 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>:
> > 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
> >> 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
> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> --
> Alexander Bruy
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20140110/a75eddfa/attachment.html>


More information about the Qgis-developer mailing list