Hello Stephan,
Our outputs differ again!
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
Very strange, because program flow shouldn't arrive to OSRExportToProj4()!!
I downloaded the db you provided, EPSG 4326 latlon, successfully
imported to postgis database, run v.in.ogr and the command
consistently warned about a different projection:
In postgresql+postgis server (see the 4326 SRID?):
geoprueba=# select * from geometry_columns where f_table_name='cntry98';
f_table_catalog | f_table_schema | f_table_name | f_geometry_column |
coord_dimension | srid | type | attrelid | varattnum | stats
-----------------+----------------+--------------+-------------------+-----------------+------+--------------+----------+-----------+-------
| public | cntry98 | the_geom |
2 | 4326 | MULTIPOLYGON | | |
In local machine, grass 6.1:
GRASS 6.1.cvs (spearfish60):~/cvsgrass/grass6 > v.in.ogr
dsn="PG:host=escaton dbname=geoprueba user=postgres" layer=cntry98
output=test1 type=point
comparing "meters"
to "unit"
to "units"
to "meters"
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.
Outputs from g.region and ogrinfo is the same as yours. Investigating
command flow in the source code, I can see in file
grass6/vector/v.in.ogr/main.c, lines 244+ ..
/* Open OGR DSN */
Ogr_ds = OGROpen( dsn_opt->answer, FALSE, NULL );
...
for ( i = 0; i < navailable_layers; i++ ) {
Ogr_layer = OGR_DS_GetLayer( Ogr_ds, i );
Ogr_featuredefn = OGR_L_GetLayerDefn( Ogr_layer );
available_layer_names[i] = G_store ( (char *)OGR_FD_GetName(
Ogr_featuredefn ) );
}
...
Ogr_projection = OGR_L_GetSpatialRef(Ogr_layer);
...
if ( GPJ_osr_to_grass( &cellhd, &proj_info,
&proj_units, Ogr_projection, 1) < 0 )
...
where Ogr_projection becomes a NULL pointer before calling
GPJ_osr_to_grass(). It seems to be the correct behaviour. Then, in
file grass6/lib/proj/convert.c, lines 227+ ...
int GPJ_osr_to_grass(struct Cell_head *cellhd, struct Key_Value **projinfo,
struct Key_Value **projunits, OGRSpatialReferenceH hSRS,
int interactive)
{
struct Key_Value *temp_projinfo;
char *pszProj4 = NULL, *pszRemaining;
char *pszProj = NULL;
if( hSRS == NULL )
goto default_to_xy;
...
default_to_xy:
if( cellhd != NULL )
{
cellhd->proj = PROJECTION_XY;
cellhd->zone = 0;
}
...
return 1;
}
So, when receiving a NULL hSRS (the Ogr_projection value), the
function GPJ_osr_to_grass() automatically assume LatLon and exit, and
the string message about OSRExportToProj4() shouldn't appear at all as
the hSRS==NULL is the very first thing checked.
What's happening here? No idea, but it seems to be an issue in your
GRASS install, not in code in CVS. Sorry.
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...
Yes, standard behaviour when using a NULL value in strcmp() function
(file key_value1.c, line 107). The question is, why do we get a null
for "key" value? The "key" parameter is always assigned to a static
string, except in the following files:
general/g.setproj/get_stp.c, lib/g3d/g3dkeys.c and lib/gis/get_projname.c.
It can't be in the first one: calling G_find_key_value(answer, ...) is
preceded by a strcmp(answer, ...) without producing segfault. The same
happens for the third one: strcmp(answer, ...) doesn't segfault, then
answer is not null. And no use of g3d code, so second file is also
descarted.
Again, I'm afraid the error is attached to your install. I can't
reproduce your results from my fresh GRASS 6.1 cvs install (from
yesterday) using your own data.
Sorry, but I quit. Regards,
M.
--
-- marcos boullón magán