[GRASS5] v.overlay errors

GRASS GRASS developer
1

[today's 5.7]

While running v.overlay I'm getting a zillion errors that look
like this:

...
WARNING: Cannot insert new row: insert into coast_bound6h values ( 2552,
         null, 3054 )
DBMI-DBF driver error:
SQL parser error in statement:
insert into coast_bound6h values ( 1, 14011, null )
Error in db_execute_immediate()
SQL parser error in statement:
insert into coast_bound6h values ( 2, 1, null )
Error in db_execute_immediate()
SQL parser error in statement:
insert into coast_bound6h values ( 3, 14265, null )
Error in db_execute_immediate()
SQL parser error in statement:
insert into coast_bound6h values ( 4, 1, null )
Error in db_execute_immediate()
SQL parser error in statement:
insert into coast_bound6h values ( 5, 14304, null )
Error in db_execute_immediate()
SQL parser error in statement:
insert into coast_bound6h values ( 6, 1, null )
Error in db_execute_immediate()
SQL parser error in statement:
insert into coast_bound6h values ( 7, null, 1 )
Error in db_execute_immediate()
SQL parser error in statement:
insert into coast_bound6h values ( 8, null, 109 )
Error in db_execute_immediate()
SQL parser error in statement:
insert into coast_bound6h values ( 9, null, 110 )
Error in db_execute_immediate()
SQL parser error in statement:
insert into coast_bound6h values ( 10, null, 111 )
Error in db_execute_immediate()
...

(14011, 14265, and 14304 are my 3 area categories in vect_A)

The command line looks something like:

v.overlay ain=vect_A bin=vect_B op=xor out=coast_bound6h

I don't think vect_A is connected to a database; don't know about
vect_B.

The other odd thing is vect_A's coor file is ~5.7mb, vect_B's coor file
is ~6.2mb, and currentlt vect_C's coor file is up to 14.2mb .. shouldn't
it be smaller than the sum of the two inputs?

It's still running now, the coor file is slowly growing in size..

?

Hamish

2

On Tue, May 11, 2004 at 09:58:32PM +1200, Hamish wrote:

[today's 5.7]

While running v.overlay I'm getting a zillion errors that look
like this:

...
WARNING: Cannot insert new row: insert into coast_bound6h values ( 2552,
         null, 3054 )
DBMI-DBF driver error:
SQL parser error in statement:
insert into coast_bound6h values ( 1, 14011, null )

[...]

As far as I know there is no 'null' support in DBMI-DBF (yet).
You will have to either extend DBMI-DBF or use mySQL or PostgreSQL.

Markus

3

On Tuesday 11 May 2004 11:58, Hamish wrote:

[today's 5.7]

While running v.overlay I'm getting a zillion errors that look
like this:

...
WARNING: Cannot insert new row: insert into coast_bound6h values ( 2552,
         null, 3054 )
DBMI-DBF driver error:
SQL parser error in statement:
insert into coast_bound6h values ( 1, 14011, null )

On Thursday 06 May 2004 11:05, Radim Blazek wrote:

< 21.5. - remove Shapefile and PostGIS from vector library (substituted by
           OGR) - remove shp DB driver
         - add support for 'NULL' in dbf DB driver

Use -t flag if you don't need the table.

The other odd thing is vect_A's coor file is ~5.7mb, vect_B's coor file
is ~6.2mb, and currentlt vect_C's coor file is up to 14.2mb .. shouldn't
it be smaller than the sum of the two inputs?

It's still running now, the coor file is slowly growing in size..

The output vector is used as working space (until temporary vector is implemented).
v.overlay breaks all boundaries, but only 2 lines are broken at time,
old lines are deleted and broken parts are written at the end of the vector,
so vect_C contains also many 'dead' lines.

Radim

4

On Mon, 22 Mar 2004 16:31:36 +0100
Markus Neteler <neteler@itc.it> wrote:

the spatial filter in v.in.ogr is fixed in CVS.

> Stephan wrote:
> I am trying to import some vector-datasets into GRASS via v.in.ogr.
> The spatial switch does not work as expected, I guess.

This still doesn't work for me:

v.in.ogr dsn=. layer=rivers output=rivers \
  spatial=1084000,4847000,1224000,5092000

It imports everything.

G5.7> v.info rivers
| Layer: rivers
...
| Map Scale: 1:1
| Map format: native
...
| Type of Map: Vector (level: 2)
...
| Number of points: 0 Number of areas: 0 |
| Number of lines: 749453 Number of islands: 0 |
| Number of boundaries: 0 Number of faces: 0 |
| Number of centroids: 0 Number of kernels: 0 |
...
| Map is 3D: 0
...
| Number of dblinks: 1
...
| Projection: Transverse Mercator (zone 0)
| N: 6221336.075 S: 4748882.679
| E: 2088905.215 W: 1090205.719
| B: 0.000 T: 0.000

?
Hamish

5

On Thu, May 13, 2004 at 02:00:04PM +1200, Hamish wrote:

On Mon, 22 Mar 2004 16:31:36 +0100
Markus Neteler <neteler@itc.it> wrote:

> the spatial filter in v.in.ogr is fixed in CVS.
>
> > Stephan wrote:
> > I am trying to import some vector-datasets into GRASS via v.in.ogr.
> > The spatial switch does not work as expected, I guess.

This still doesn't work for me:

v.in.ogr dsn=. layer=rivers output=rivers \
  spatial=1084000,4847000,1224000,5092000

It imports everything.

" Works for me ..."

Here an example: (using the Spearfish5.7 database)

[If using Spearfish 5.0/5.3:
  v.convert soils out=soils ]

g.region -dp
v.out.ogr in=soils dsn=soils.shp lay=soils typ=area
d.zoom
g.region -g
v.in.ogr dsn=soils.shp out=soils_cut spatial=598260,4920600,601920,4923300
d.erase
d.vect soils_cut
d.zoom
#unzoom
-> result is correct.

Note: Maybe you have a problem with the OGR behaviour to cut/intersect.
All vector features which fall within the spatial subset region, are
imported *completely*. Above example demonstrates it.

Solution:
g.region n=yyy s=yyy2 w=xxx e=xxx2 -p
v.in.region out=cutter
v.overlay ....

So this is not a problem of v.in.ogr but of the way how OGR handles it.

Markus