[GRASS5] v.in.ogr behaviour

Stephan Holl holl at gdf-hannover.de
Fri Mar 24 11:19:04 EST 2006


Hello marcos,

On Fri, 24 Mar 2006 15:32:14 +0100 "marcos boullón magán"
<marcosboullon at gmail.com> wrote:

> 2006/3/24, Stephan Holl <holl at gdf-hannover.de>:
> > Using other datasources are getting more difficult.
> > I have a PostGIS-Point-dataset (EPSG:4326 -> latlon)
> >
> > ogrinfo -al -summary "PG:dbname=postgis user=gdf" grass_users
> > INFO: Open of `PG:dbname=postgis user=gdf'
> > using driver `PostgreSQL' successful.
> > [...]
> > which imports just fine into spearfish60 ?! This is aparently wrong.
> > Please see the debugging output attached (v.in.ogr_pgis.dmp).
> > So apparently GRASS identifies the dataset as utm (which is not true
> > as shown above from ogrinfo).
> 
> Sorry, but my skills in geoprocessing are rather low. I'm a recent
> arrival to this field and get lost easily with projection, datum,
> coord system... vocabulary. Maybe with an equivalent sample database I
> could reproduce and trace back this error to the origin, maybe not.

OK, I could provide another dataset for you as SQL-Dump, which is in
EPSG:4326 for postGIS.
I put it on my website for you to download[1] (4 MB), a world-dataset
grabbed from here[2]. You could import the data using 
psql -U <youuser> -h <yourhost> postgisdatabase < cntr98.sql (You need
a postgis-enabled database of course).

> Which SQL commands create point geometry datasets in EPSG:4326 latlon?
> 
> Anyway, as seen in dump, the importing driver finds the token "utm" in
> the string returned by OSRExportToProj4() function call (file
> lib/proj/convert.c, line 277), commented as "Get the coordinate system
> definition in PROJ.4 format". Reference system appears as utm before
> the conversion code. Did you double check you were importing the right
> table? Sorry, no more ideas without all data.

Yes, strange. After your patch was applied I got this output:
v.in.ogr dsn="PG:dbname=postgis user=gdf" layer=cntry98 out=test14
comparing "meters"
to "unit"
to "units"
to "meters"
OSRExportToProj4() returned "+proj=utm +zone=13 +ellps=clrk66
+datum=NAD27 +units=m +no_defs "

According to the ogrinfo-output the projection should at least be 
EPSG 4326 which is latlon

ogrinfo -al -summary "PG:dbname=postgis user=gdf" cntry98
Layer name: cntry98
Geometry: Multi Polygon
Feature Count: 251
Extent: (-180.000000, -90.000000) - (180.000000, 83.623596)
Layer SRS WKT:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.01745329251994328,
        AUTHORITY["EPSG","9122"]],
    AUTHORITY["EPSG","4326"]]
gid: Integer (0.0)
fips_cntry: String (0.0)
gmi_cntry: String (0.0)
iso_2digit: String (0.0)
iso_3digit: String (0.0)
cntry_name: String (0.0)
sovereign: String (0.0)
pop_cntry: Integer (0.0)
sqkm_cntry: Real (0.0)
sqmi_cntry: Real (0.0)
curr_type: String (0.0)
curr_code: String (0.0)
landlocked: String (0.0)
color_map: String (0.0)

Which is definetly the projection of the current location I am in, and
not the data-projection.
g.region -p
projection: 1 (UTM)
zone:       13
datum:      nad27
ellipsoid:  clark66
north:      5345694.68966235
south:      5324945.25464811
west:       4452539.52677299
east:       4479502.31502616
nsres:      29.89832135
ewres:      29.92540317
rows:       694
cols:       901

I do not understand what is going on in there, so I need to leave this
to you and others to find out. *?!*

> > I have found another strange behaviour when trying to access
> > oracle-spatial through v.in.ogr. ogrinfo reports the correct
> > projection-information, but v.in.ogr segfaults while trying to
> > compare (null) -> segfault. (see v.in.ogr_oracle.dmp)
> 
> Again, not enough data to say what's wrong with the import process:
> apparently the key value in struct Key_Value is incorrect because null
> value (file key_value1.c, line 107); going back to its last
> assignement (incarnated as pszProj in file lib/proj/convert.c, line
> 675 I guess), it was... NULL: string pszProj is only different to NULL
> when token "proj=something" is present in OSRExportToProj4() return
> string.

I see, so my Oracle_dataset does not provide the correct proj-string
apparently, which is quite strange, because ogr2ogr shows everything is
correct... See my last mail for ogrinfo-output.

The segfault somes from here:

comparing "meters"
to "unit"
to "units"
to "meters"
OSRExportToProj4() returned "+ellps=bessel +units=m +no_defs "
comparing "(null)"
to "ll"
Segmentation fault

So comparing (null) to something results in a segfault...

> 
> Please add the following code to show what OSRExportToProj4() does (no
> diff file because a single change). In file grass6/lib/convert.c, line
> 277 and 278, change
> 
>     if( OSRExportToProj4( hSRS, &pszProj4 ) != OGRERR_NONE )
>         goto default_to_xy;
> 
> to
> 
>     if( OSRExportToProj4( hSRS, &pszProj4 ) != OGRERR_NONE )
>         goto default_to_xy;
>     fprintf(stderr, "OSRExportToProj4() returned \"%s\"\n", pszProj4);
>     fflush(stderr);
> 
> and recompile. Maybe useful info arises.

Yes, definetly. Thank you. 

Best 
	Stephan


[1] http://www.gdf-hannover.de/holl/tmp/cntry98.sql.gz
[2] http://www.mappinghacks.com/data/cntry98.zip


-- 
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