[GRASS-user] Apply "v.transform" in polygons with overlays

GRASS GRASS user
1

Hi all!

I need to use "v.transform" over layers that are "topologically
incorrect" (so they have overlapped polygons, and it is not a
problem). Of course, many elements disappear after importing the
layer, and more elements disappear after applying "v.transform".

To solve this, I wrote a python script "very" configurable, that
"import/transform/export" the elements one-on-one , from/to a
non-topological data source.

Problem: I am not satisfied with the performance. The datasource has
hundreds of thousands of elements and the process takes many hours to
complete.

Question: is there a better approach to solve the overlapped polygons
processing?

Note that I have to keep overlapping polygons.

Thanks in advance!
José

2

José wrote:

Problem: I am not satisfied with the performance. The
datasource has hundreds of thousands of elements and the
process takes many hours to complete.

try running v.split on the largest of the polygons.

search the mailing list archives for "the florida coastline
problem".

Hamish

3

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?

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é

4

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
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

   benducke@fastmail.fm

5

2013/2/26 Benjamin Ducke <benducke@fastmail.fm>:

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).

Yes, I know. But I think that there are some cases, like this, where
the overlaps between polygons are part of the information and need to
be preserved.

And I understand that a situation like this would limit the
application of other modules.

Maybe I'm totally wrong: I still have so much to study about GRASS!
(english too... right?) :smiley:

Thanks,
Jose

6

On Tue, Feb 26, 2013 at 2:36 PM, Jose M Michia Roberts
<jose.maria.michia@gmail.com> wrote:

2013/2/26 Benjamin Ducke <benducke@fastmail.fm>:

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).

Yes, I know. But I think that there are some cases, like this, where
the overlaps between polygons are part of the information and need to
be preserved.

The overlaps between polygons are only preserved if you do not use the
-c flag for v.in.ogr. Each original polygon can then be recreated with
v.extract -d cat=X. If you use the -c flag with v.in.ogr, you are on
your own.

BTW, v.transform simply transforms coordinates, it does not do any
cleaning. v.transform should actually work without topology, building
topology on the output is optional (in GRASS 7).

And I understand that a situation like this would limit the
application of other modules.

Maybe I'm totally wrong: I still have so much to study about GRASS!

For this particular problem (georectifying overlapping polygons) there
is probably an easier solution outside GRASS. Maybe QGIS supports
coordinate transformation/rectification using GCPs?

Markus M

(english too... right?) :smiley:

Thanks,
Jose
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

7

On 26/02/13 13:50, Benjamin Ducke wrote:

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).

-1

I'm strongly opposed to that option. As you mention, this would fundamentally undermine the data logic in GRASS.

To answer José's issue: If you want to keep on working in GRASS, you should not try to do so with overlapping polygones.

If all you want to do in GRASS is v.transform, you should be able to import with cleaning. Wherever there is overlap, you will get new polygones which have all the category numbers of the original polygones. You can then v.transform the file and if you need to get the original polygones you should be able reconstruct them based on the common category numbers.

Moritz

8

2013/2/26 Markus Metz <markus.metz.giswork@gmail.com>:

BTW, v.transform simply transforms coordinates, it does not do any
cleaning. v.transform should actually work without topology, building
topology on the output is optional (in GRASS 7).
[...]
For this particular problem (georectifying overlapping polygons) there
is probably an easier solution outside GRASS. Maybe QGIS supports
coordinate transformation/rectification using GCPs?

Looks like you're right. I will try a newer version of GDAL / OGR. I
will also update GRASS, to use "v.rectify", so I can check the values
of the transformation matrix, and explore the possibility of working
without topology.

In QGIS, I could not find an equivalent function. Maybe it exist, but
I have looked very little. I know there is a plugin for GCP based
transformations, but it is for rasters. Anyway, some of the above
alternatives will surely solve my problem.

2013/2/26 Moritz Lennert <mlennert@club.worldonline.be>:

-1

I'm strongly opposed to that option. As you mention, this would
fundamentally undermine the data logic in GRASS.

To answer José's issue: If you want to keep on working in GRASS, you should
not try to do so with overlapping polygones.

Thanks Moritz, I hope fully understand all implications of this topic
someday! For now, I promise to not propose something like that
anymore.

If all you want to do in GRASS is v.transform, you should be able to import
with cleaning. Wherever there is overlap, you will get new polygones which
have all the category numbers of the original polygones. You can then
v.transform the file and if you need to get the original polygones you
should be able reconstruct them based on the common category numbers.

I considered doing this at first. But when I checked the maps
imported, I could not find all the information necessary to perform
the task. I will follow your instructions if only as an exercise to
learn a little more.

Thank you very much!
Jose

9

Hello all,

I am a member of a group of farmers and agribusinesses that would like to explore using grass or other open source gis as a replacement for the commercial ag gis platforms out there. Most of the desktop software is not being updated and the new systems are web based. These require us to allow sensitive data to leave our control. We are located around the Midwest but concentrated in eastern iowa. We would like to find some talented developers to help us explore/develop this (on a paid basis).

Is grass fairly adaptable?

If anyone has any advice I would love to hear from you
Thank you,

John. Mcgillicuddy

Sent from my iPad

On Feb 26, 2013, at 2:51 AM, José María Michia Roberts <jose.maria.michia@gmail.com> wrote:

Hi all!

I need to use "v.transform" over layers that are "topologically
incorrect" (so they have overlapped polygons, and it is not a
problem). Of course, many elements disappear after importing the
layer, and more elements disappear after applying "v.transform".

To solve this, I wrote a python script "very" configurable, that
"import/transform/export" the elements one-on-one , from/to a
non-topological data source.

Problem: I am not satisfied with the performance. The datasource has
hundreds of thousands of elements and the process takes many hours to
complete.

Question: is there a better approach to solve the overlapped polygons
processing?

Note that I have to keep overlapping polygons.

Thanks in advance!
José
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

10

On Tue, Feb 26, 2013 at 5:35 PM, John Mcgillicuddy <jkmcgil@mchsi.com> wrote:

Hello all,

I am a member of a group of farmers and agribusinesses that would like to explore using grass or other open source gis as a replacement for the commercial ag gis platforms out there. Most of the desktop software is not being updated and the new systems are web based. These require us to allow sensitive data to leave our control. We are located around the Midwest but concentrated in eastern iowa. We would like to find some talented developers to help us explore/develop this (on a paid basis).

There is a very incomplete Wiki page:
http://grasswiki.osgeo.org/wiki/Support
* Commercial support: Freelancers who offer GRASS Support
* Commercial support: Companies and Institutions which offer GRASS Support

Is grass fairly adaptable?

Definitely yes. See also
http://grasswiki.osgeo.org/wiki/Software_requirements_specification

Markus

--
http://gis.cri.fmach.it/neteler/