[GRASS5] v.in.ogr behaviour

[Stephan Holl]

Hello Stephan,

[replying to myself again]

On Wed, 15 Mar 2006 09:37:26 +0100 Stephan Holl <holl at gdf-hannover.de>
wrote:

> Hello Lists,
> 
> [crosspost again]
> 
> On Mon, 13 Mar 2006 12:09:15 +0100 Stephan Holl <holl at gdf-hannover.de>
> wrote:
> 
> > Dear list,
> > 
> > [sorry for crossposting, but perhaps this is interesting for the
> > GDAL-folks as well]
> > 
> > I am working with GRASS6_CVS and Oracle 9i which is compiled into
> > GDAL/OGR 1.3.1. Everything works if the tables in Oracle are owned
> > by the given user. 
> > v.in.ogr reports the available layers as follows:
> > v.in.ogr -l dsn="OCI:owneroftables/pw at OCI" layer=DATA1 out=data1
> > Data source contains 2 layers:
> > DATA1, DATA2
> > 
> > Removing the -l-switch imports the data nicly and creates dataset
> > data1 inside GRASS.
> > 
> > When I create another oracle-user with only
> > SELECT-privileges on that table, the tables inside Oracle are shown
> > like this:
> > 
> > v.in.ogr -l dsn="OCI:readonlyuser/pw at OCI" layer=OWNEROFTABLES.DATA1
> > out=data1
> > Data source contains 2 layers:
> > OWNEROFTABLES.DATA1, OWNEROFTABLES.DATA2
> > 
> > Trying to import now, this results in a Segmentation fault.
> > v.in.ogr dsn="OCI:readonlyuser/pw at OCI" layer=OWNEROFTABLES.DATA1
> > out=data1
> > 
> > So I assume the dot between user and table produces this?! Perhaps
> > anybody can give me a hint where to look at.
> > 
> > Using ogr2ogr works with both users and exports e.g. a shapefile
> > correct.
> > 
> > Thanks in advance for any pointers.
> 
> Apparently noone has stumbled over this I will provide as much
> information for the developers. 
> I have created a full gdb backtrace[1] of the segfault. But again, I
> do not know where to dig into the problem since I do know what is
> going on there...
> 
> Thank you for having a look what might go wrong here.

Learning to use DDD with Markus help got further information for me.
When I run v.in.ogr through ddd I have severel stacks which can be
investigated.

1.UP: key_value1.c:107
2.UP: key_value4.c:49
3.UP: convert.c:352
4.UP: /v.in.ogr/main.c:384

It currently segfaults in key_value1.c:107 (strcmp).
When I put the lines into comments, recompile and run v.in.ogr with
-o-flag, the dataset gets imported with warning, at least it gets
imported.

So now I know, that there must be something wrong with the
projection-stuff. It seems to me that Markus has investigated something
similar in the bugtracker[1] also dealing with projection-stuff.

I have tried to find some hints in the CVS changelogs for key_value1.c
but I am not sure if they are relevant.

2006-01-04 12:40  markus G_malloc(); alloc() -> G_alloc(); calloc() ->
		G_calloc();realloc() -> G_realloc()

and

2006-02-09 04:08  glynn Use <grass/gis.h> etc rather than <gis.h>


Probably this problem is also relevant with the following changes:

2006-02-12 22:41  cho v.in.ogr segmentation fault fixed
          argument type fixed: OGRSpatialReferenceH * =>
          OGRSpatialReferenceH         OGRSpatialReferenceH is already a
          pointer to void.

2006-02-09 17:58  cho vector/v.in.ogr/main.c: bug fixed: wrong argument
type passed

Does anybody know if this changes require any CVS-versions of GDAL/OGR
or PROJ.4?

?!

Thanks for any comments on this.

	Stephan
	

[1] https://intevation.de/rt/webrt?display=History&serial_num=4190


-- 
GDF Hannover - Solutions for spatial data analysis and remote sensing
Hannover Office      -     Mengendamm 16d      -     D-30177 Hannover
Internet: www.gdf-hannover.de      -      Email: holl at gdf-hannover.de
Phone : ++49-(0)511.39088507       -        Fax: ++49-(0)511.39088508