[GRASS5] [bug #3876] (grass) g.proj: proj4= fails, wkt= works partialy

[Markus Neteler]

On Thu, Feb 09, 2006 at 11:30:42AM +0000, Paul Kelly wrote:
> On Mon, 6 Feb 2006, Maciek Sieczka via RT wrote:
> 
> >Creating new location from an EPSG code fails. Maybe due to Paul's recent
> >changes? This problem could be populate to 6.02 candidate as well then.
> >
> >I tried to create a location from EPSG code 2180. There was no error, 
> >location
> >was created. My path to /usr/local/share/proj/epsg is ok. However the 
> >location
> >is not projected:
> 
> The EPSG codes are read from $(GISBASE)/etc/ogr_csv/pcs.csv and not 
> /usr/local/share/proj/epsg, if that makes any difference.
> 
> Something to try to be sure is g.proj -p proj4=+init=epsg:2180 and it 
> should print the correct co-ordinate system in GRASS format.
> 
> The conversion logic is mostly in OGR. The PROJ.4 string is never 
> interpreted by PROJ in this case but by OGR.

This
 g.proj -p proj4=+init=epsg:2180
works again (tested in Spearfish).

v.in.ogr still fails (here it should display the contents of the .prj
file, not 0):

GRASS 6.1.cvs (spearfish60):~/data/vmap0 > v.in.ogr polbnda_italy_GB_ovest.shp out=test
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.

GRASS 6.1.cvs (spearfish60):~/data/vmap0 > cat polbnda_italy_GB_ovest.prj
PROJCS["Transverse Mercator",GEOGCS["international",DATUM["D_Monte_Mario",SPHEROID["international",6378388,297]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",1500000],PARAMETER["false_northing",0],UNIT["Meter",1]]

Maybe it has to do with the definition of
OGRSpatialReferenceH
?

Markus