[GRASS5] v.in.ogr behaviour

[marcos boullón magán]

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