[GRASS5] v.in.ogr behaviour
marcos boullón magán
marcosboullon at gmail.com
Thu Mar 23 06:31:43 EST 2006
Hi,
I'm unable to reproduce your error using GRASS 61. cvs updated today,
nor a segfault. Does it help you? Trace follows:
GRASS 6.1.cvs (spearfish60):~ > v.out.ogr in=soils type=area dsn=/tmp/
olayer=soils
Exporting 737 areas (may take some time) ...
100%
737 features written
WARNING: 1 features without attributes written
GRASS 6.1.cvs (spearfish60):~ > v.in.ogr dsn=/tmp/soils.shp out=test1
A datum name nad27 (North_American_Datum_1927) was specified without
transformation parameters.
WARNING: Non-interactive mode: the GRASS default for nad27 is
towgs84=-22.000,157.000,176.000.
Projection of input dataset and current location appear to match.
Proceeding with import...
Layer: soils
WARNING: Column name changed: 'cat' -> 'cat_'
Importing map 737 features...
-----------------------------------------------------
Building topology ...
778 primitives registered
Building areas: 100%
534 areas built
529 isles built
Attaching islands: 100%
Attaching centroids: 100%
Topology was built.
Number of nodes : 652
Number of primitives: 778
Number of points : 0
Number of lines : 0
Number of boundaries: 778
Number of centroids : 0
Number of areas : 534
Number of isles : 529
Number of incorrect boundaries : 247
Number of areas without centroid : 534
-----------------------------------------------------
WARNING: Cleaning polygons, result is not guaranteed!
Building topology ...
Topology was built.
Number of nodes : 652
Number of primitives: 778
Number of points : 0
Number of lines : 0
Number of boundaries: 778
Number of centroids : 0
Number of areas : -
Number of isles : -
-----------------------------------------------------
Break polygons:
Registering points ... 34778
All points (vertices): 71509
Registered points (unique coordinates): 34778
Points marked for break: 1418
Breaks: 4008
-----------------------------------------------------
Remove duplicates:
Duplicates: 1965
-----------------------------------------------------
Break boundaries:
Intersections: 0
-----------------------------------------------------
Remove duplicates:
Duplicates: 0
-----------------------------------------------------
Clean boundaries at nodes:
Modifications: 0
-----------------------------------------------------
Change dangles to lines:
Removed dangles: 0 removed lines: 0
-----------------------------------------------------
Remove bridges:
Removed bridges: 0 removed lines: 0
-----------------------------------------------------
Building topology ...
Building areas: 100%
737 areas built
42 isles built
Attaching islands: 100%
Topology was built.
Number of nodes : 1418
Number of primitives: 4786
Number of points : 0
Number of lines : 0
Number of boundaries: 4786
Number of centroids : 0
Number of areas : 737
Number of isles : 42
Number of areas without centroid : 737
Layer: soils
-----------------------------------------------------
-----------------------------------------------------
Building topology ...
2850 primitives registered
Building areas: 100%
737 areas built
42 isles built
Attaching islands: 100%
Attaching centroids: 100%
Topology was built.
Number of nodes : 2155
Number of primitives: 2850
Number of points : 0
Number of lines : 0
Number of boundaries: 2113
Number of centroids : 737
Number of areas : 737
Number of isles : 42
-----------------------------------------------------
737 input polygons
total area: 2.762475e+08 (737 areas)
overlapping area: 0.000000e+00 (0 areas)
area without category: 0.000000e+00 (0 areas)
M.
2006/3/23, Stephan Holl <holl at gdf-hannover.de>:
> 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
>
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>
--
-- marcos boullón magán
-- universidade de Santiago de Compostela
More information about the grass-dev
mailing list