[GRASS-user] Importing vectors (polygons) without building topology

GRASS GRASS user
,
1

Dear list,

I have a bunch of PostGIS layers (polygons) that I want to import into GRASS.
These polygons represent palaeogeographic features and therefore they
necessarily overlap over some regions (different entities are distinguished
by attributes in the attribute table). Since v.in.ogr automatically builds
topology by default, a secondary layer is generated during import where the
the overlapping sectors of the polygons are cut and stored. Whereas this
might be useful for a wide range of applications it is certainly not
desirable in my case, since it destroys the palaeogeographic representation.
My question is therefore: how can I import these shapefiles and avoid topology
building at the same time? I understand that exporting the tables as text and
importing them using v.in.ascii might be an option, but I would rather prefer
to preserve the carefuly designed attribute tables as they are, without
having to regenerate them.

I have been thinking in this problem during a couple of days without coming to
a decent solution, so I hope someone can give me a hint on this.

I am using GRASS 6.0.2 RC4 in OpenSuSE 10.0.

Thanks in advance

Hernán

2

Hernán De Angelis wrote:

how can I import these shapefiles and avoid topology building at the
same time?

v.in.ogr -c

?
Hamish

3

Hernán De Angelis napisa?(a):

Dear list,

I have a bunch of PostGIS layers (polygons) that I want to import into GRASS. These polygons represent palaeogeographic features and therefore they necessarily overlap over some regions (different entities are distinguished by attributes in the attribute table). Since v.in.ogr automatically builds topology by default, a secondary layer is generated during import where the the overlapping sectors of the polygons are cut and stored. Whereas this might be useful for a wide range of applications it is certainly not desirable in my case, since it destroys the palaeogeographic representation. My question is therefore: how can I import these shapefiles and avoid topology building at the same time? I understand that exporting the tables as text and importing them using v.in.ascii might be an option, but I would rather prefer to preserve the carefuly designed attribute tables as they are, without having to regenerate them.

I have been thinking in this problem during a couple of days without coming to a decent solution, so I hope someone can give me a hint on this.

I am using GRASS 6.0.2 RC4 in OpenSuSE 10.0.

Thanks in advance

Hernán

_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser
  

v.external

4

El Viernes 23 Junio 2006 03.28, Hamish escribió:

Hernán De Angelis wrote:
> how can I import these shapefiles and avoid topology building at the
> same time?

v.in.ogr -c

?
Hamish

Sorry, but the -c option doesn't help in this.

5

El Viernes 23 Junio 2006 10.14, Hernán De Angelis escribió:

El Viernes 23 Junio 2006 03.28, Hamish escribió:
> Hernán De Angelis wrote:
> > how can I import these shapefiles and avoid topology building at the
> > same time?
>
> v.in.ogr -c
>
>
> ?
> Hamish

Sorry, but the -c option doesn't help in this.

Hamish, sorry for the last message. I tried with a test file and worked
(although in a different machine), so I have to dig out if the problem is in
my installation or in my file.

Thanks

Hernán

6

On Fri, 23 Jun 2006 07:28:05 +0200
Jarek Jasiewicz <jarekj@amu.edu.pl> wrote:

Hernán De Angelis napisa?(a):
> Dear list,
>
> I have a bunch of PostGIS layers (polygons) that I want to import
> into GRASS. These polygons represent palaeogeographic features and
> therefore they necessarily overlap over some regions (different
> entities are distinguished by attributes in the attribute table).
> Since v.in.ogr automatically builds topology by default, a
> secondary layer is generated during import where the the
> overlapping sectors of the polygons are cut and stored. Whereas
> this might be useful for a wide range of applications it is
> certainly not desirable in my case, since it destroys the
> palaeogeographic representation. My question is therefore: how can
> I import these shapefiles and avoid topology building at the same
> time?

v.external

Or v.in.ogr -c, ?

Maciek

------------------------------------------------------------------------
CIEP£E KRAJE - CIEP£E MORZA. Szukasz atrakcyjnego wypoczynku w przystêpnej cenie, zapoznaj siê z nasz± ofert±.
ZAPRASZAMY

www.skarpatravel.pl

7

On Fri, Jun 23, 2006 at 12:44:13AM +0200, we recorded a bogon-computron collision of the <hernan.deangelis@glocalnet.net> flavor, containing:

Dear list,

I have a bunch of PostGIS layers (polygons) that I want to import into GRASS.
These polygons represent palaeogeographic features and therefore they
necessarily overlap over some regions (different entities are distinguished
by attributes in the attribute table). Since v.in.ogr automatically builds
topology by default, a secondary layer is generated during import where the
the overlapping sectors of the polygons are cut and stored. Whereas this
might be useful for a wide range of applications it is certainly not
desirable in my case, since it destroys the palaeogeographic representation.
My question is therefore: how can I import these shapefiles and avoid topology
building at the same time? I understand that exporting the tables as text and
importing them using v.in.ascii might be an option, but I would rather prefer
to preserve the carefuly designed attribute tables as they are, without
having to regenerate them.

If it were me, I think I would probably do it in stages by using the GDAL tool
"ogr2ogr" to make separate files of non-overlapping polygons before attempting
to pull them into GRASS. That is, pull out files filled only with
polygons representing the same type of entity using an SQL-like select on
the attributes. Once you have such things, each should be easily importable
into GRASS as separate vector files.

I don't use PostGIS, so am not familiar with the correct way to specify
PostGIS layers in OGR commands. If the layer were already in a shapefile
format, you'd do something like this, assuming for example that the
distinguishing attribute was called "entity_type" and had string values:

ogr2ogr -where 'entity_type="SomeParticularType"' reduced.shp original_full.shp

which would produce a new shapefile reduced.shp containing only features with
entity_type having value SomeParticularType.

You could construct considerably more complex "where" clauses to taste, so
long as when you do so you're only selecting non-overlapping polygons. Doing
this you should be able to import all your data without having GRASS impose
topological restrictions on it, but also without having to resort to skipping
the topology building.

Naturally, you'll wind up with many different polygon vector files instead of
just one, but each will only represent one type of entity.

--
Tom Russo KM5VY SAR502 DM64ux http://www.swcp.com/~russo/
Tijeras, NM QRPL#1592 K2#398 SOC#236 SKCC#2002
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
one trick, rational thinking, but when you're good and crazy, oooh, oooh,
oooh, the sky is the limit!" --- The Tick

8

On Sun, Jun 25, 2006 at 01:08:00PM -0600, we recorded a bogon-computron collision of the <russo@bogodyn.org> flavor, containing:

I don't use PostGIS, so am not familiar with the correct way to specify
PostGIS layers in OGR commands. If the layer were already in a shapefile
format, you'd do something like this, assuming for example that the
distinguishing attribute was called "entity_type" and had string values:

ogr2ogr -where 'entity_type="SomeParticularType"' reduced.shp original_full.shp

Sorry, that's wrong. The correct usage would be:
ogr2ogr -where "entity_type='SomeParticularType'" reduced.shp original_full.shp

(the single and double quotes need to be in that order)

Also, for postgis input and shape output you'd just do:

ogr2ogr -f "ESRI Shapefile" -where "enity_type='SomeParticularType" output.shp \
     PG:'dbname=russo' input_table_name

HTH,
T.

--
Tom Russo KM5VY SAR502 DM64ux http://www.swcp.com/~russo/
Tijeras, NM QRPL#1592 K2#398 SOC#236 SKCC#2002
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
one trick, rational thinking, but when you're good and crazy, oooh, oooh,
oooh, the sky is the limit!" --- The Tick