On 02/26/2013 01:32 PM, José María Michia Roberts wrote:
José María Michia Roberts:
[...]
many elements disappear after importing the layer,
and more elements disappear after applying "v.transform"
[...]
In reply to myself: I now remember that I had solve this by adding
"-c" to "v.in.ogr", so the output layer is not cleaned and all source
elements are imported. But "v.transform" don't have such option. ¿May
be this implemented? ¿May be useful?
Many GRASS modules expect topologically
clean input data ("level 2" data).
The cleaning functions will run automatically
if the data is not clean.
A "fix" might be to introduce a new GRASS env
variable that can be set to suppress the cleaning
functions. While it would probably be trivial to
implement this, it would also break with GRASS'
basic design and the assumptions that its vector
processing modules make (namely that the input
data is topologically correct).
Ben
Hamish:
try running v.split on the largest of the polygons.
search the mailing list archives for "the florida coastline
problem".
I've found a thread named "speeding up v.in.ogr". It is a bit complex.
I gave him a look, but I think it not applies to my case, since I have
many polygons, with many small overlaps. Also, each polygon have a
database record, so I need to preserve at least an numeric field (an
ID), so split the polygons seems to be problematic to me.
On the other hand, revisiting the man page for "v.transform" I've
noted the ST_Affine PostGIS function. If I'm right, by taking the
transformation matrix reported by "v.transform" (applied to any
element) and entering their values in ST_Affine, I could transform a
whole PostGIS table (within a PostGIS table, polygons can be
overlapped). I tried that way, but I get an incorrect result. I
suspect the problem is in the transformation matrix values reported by
GRASS. I will refer to this in a new thread.
Thanks all!
José
_______________________________________________
grass-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
[email protected]
_______________________________________________
grass-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user
