[GRASS5] v.in.ogr behaviour
marcos boullón magán
marcosboullon at gmail.com
Thu Mar 23 07:01:54 EST 2006
Hello Stephan,
After applying the patch, the output is:
marcos at venux:~/cvsgrass$ cd grass6/vector/v.in.ogr/
marcos at venux:~/cvsgrass/grass6/vector/v.in.ogr$ patch < ~/cho.patch
marcos at venux:~/cvsgrass/grass6/vector/v.in.ogr$ make
marcos at venux:~/cvsgrass/grass6/vector/v.in.ogr$ cd ../..
marcos at venux:~/cvsgrass/grass6/vector/v.in.ogr$ su
venux:/home/marcos/cvsgrass/grass6/vector/v.in.ogr# make install
marcos at venux:~/cvsgrass/grass6/vector/v.in.ogr$ grass61
GRASS 6.1.cvs (spearfish60):~/cvsgrass/grass6/vector/v.in.ogr >
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):~/cvsgrass/grass6/vector/v.in.ogr >
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.
M.
2006/3/23, Stephan Holl <holl at gdf-hannover.de>:
> Hello marcos,
>
> On Thu, 23 Mar 2006 12:31:43 +0100 "marcos boullón magán"
> <marcosboullon at gmail.com> wrote:
>
> > Hi,
> >
> > I'm unable to reproduce your error using GRASS 61. cvs updated today,
> > nor a segfault. Does it help you? Trace follows:
>
> OK, thanks for your report.
> I just realized that I have forgotten to attach the small patch.
>
> Could you try with the patch again (which should be in CVS already when
> I look at the changelogs).
>
> Thanks for testing.
>
> Stephan
>
> >
> > 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
>
>
>
> --
> 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
>
>
>
--
-- marcos boullón magán
More information about the grass-dev
mailing list