[GRASS5] v.in.ogr behaviour

[Stephan Holl]

Hello marcos, 

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

> 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()!!

?! but why do I have this in my output?

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

Exactly. This is what it should state.

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

only one odditiy here. AFAIK GRASS was known to figure out the correct
data.projection. In your case this is obviosly not the case since it
states unreferenced/unknown instead of LatLon which should be correct.

e.g. 
name: Lat/lon
proj: ll
...
for the used dataset.

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

no problem at all. I have learned a lot in this thread, but acctually
it did not solve my problem.

I am going to investigate the whole software chain starting from proj,
geos, gdal, pg, oci, grass

Thanks for your help marcos.

Stephan


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