[GRASS5] v.in.ogr behaviour
Stephan Holl
holl at gdf-hannover.de
Thu Mar 23 05:33:24 EST 2006
Hello Stephan,
On Wed, 22 Mar 2006 11:10:58 +0100 Stephan Holl <holl at gdf-hannover.de>
wrote:
> 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.
OK, further updates. I have started over with a fresh checkout of
GRASS today, and noticed, that the nasty segfault-bug in v.in.ogr is
still there.
What I am curious is, that a fix from Cho[1] from 2006-02-09 is not in
CVS. I can see the commit-mail, where it gets included[1], but when
I do cvs diff to look where it gets lost again, I cannot find the
revision...
When I add this manuall, recompile the module, v.in.ogr
does not segfault anymore, but does not determine the correct projection
information of the dataset in any case...
I have stripped down a spearfish-example where you can reproduce this.
1. Applying the patch from attachment (and recompile v.in.ogr)
2. start grass in spearfish-location
3. export soils dataset to shape
v.out.ogr in=soils type=area dsn=/tmp/ olayer=soils
4. show projection of shape
ogrinfo -ro -al -summary /tmp/soils.shp
Layer name: soils
Geometry: Polygon
Feature Count: 737
Extent: (589443.780000, 4913923.480000) - (609546.170000,
4928105.880000)
Layer SRS WKT:
PROJCS["UTM Zone 13, Northern Hemisphere",
GEOGCS["clark66",
DATUM["North_American_Datum_1927",
SPHEROID["clark66",6378206.4,294.9786982]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",-105],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",500000],
PARAMETER["false_northing",0],
UNIT["meter",1]]
cat: Real (11.0)
label: String (80.0)
seems OK so far.
5. try to reimport from shape
v.in.ogr dsn=/tmp/soils.shp out=test1
ERROR: Projection of dataset does not appear to match current location.
LOCATION PROJ_INFO is:
name: UTM
datum: nad27
nadgrids: conus
proj: utm
ellps: clark66
a: 6378206.4000000004
es: 0.0067686580
f: 294.9786982000
zone: 13
cellhd.proj = 0 (unreferenced/unknown)
You can use the -o flag to v.in.ogr to override this check.
Consider to generate a new location with 'location' parameter
from input data set.
Can anybody reproduce this?
if I do not apply this patch, the shapefile gets imported, but I can
import any projected data, every data gets accepted and it seems that
the -o switch is given.
I think, there is something is wrong inside the
projection/datum-recognition.
Thank you for looking into this.
cheers
Stephan
[1] http://grass.itc.it/pipermail/grass-commit/2006-February/020656.html
--
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
More information about the grass-dev
mailing list