[GRASS-user] v.generalize failing on some geoms
markus.metz.giswork at gmail.com
Tue Feb 13 00:30:00 PST 2018
On Tue, Feb 13, 2018 at 9:02 AM, Paolo Cavallini <cavallini at faunalia.it>
> Hi Markus,
> Il 12/02/2018 21:46, Markus Metz ha scritto:
> > The original data in EPSG:3003 and EPSG:3857 are not identical. The
> > original data in EPSG:3003 are topologically correct, while the original
> > data in EPSG:3857 are not.
> interesting. so reprojecting creates errors (tiny gaps, in fact). just
> to document, the process was importing a shapefile into PostGIS, at the
> same time reprojecting from 3003 to 3857
This is the reason why neighboring polygons no longer match each other
> > Further on, the original data in EPSG:3857
> > contain features that are not present in the original data in EPSG:3003
> > which is quite strange.
> forget about this, polygons added after import
> > Reprojecting the original data in EPSG:3003 to EPSG:3857 within GRASS
> > works fine, also with subsequent v.generalize.
> > That means that the original data in EPSG:3857 are some reprojected
> > version of the original original data (which are these?). The
> > reprojection step, apparently performed on polygons, not GRASS areas
> > (how did you reproject?), introduced topological errors. Please use
> > native GRASS v.in.ogr + v.proj to reproject polygons.
> right; an easy alternative when working with QGIS Processing is to add a
> snap param, which cures the small gaps.
v.in.ogr suggests a range of snapping values specific for the data to be
imported if something goes wrong. In this case snap=0.0001 helps.
> All the best, and thanks again.
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the grass-user