[GRASS5] v.in.ogr behaviour

[marcos boullón magán]

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

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

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.

Regards,

M.

--
-- marcos boullón magán