[GRASS5] v.in.ogr behaviour
Stephan Holl
holl at gdf-hannover.de
Thu Mar 23 06:39:41 EST 2006
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cho.patch
Type: text/x-patch
Size: 1072 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20060323/086bedc9/cho.bin
More information about the grass-dev
mailing list