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

GRASS GIS GRASS GIS developer
1

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:

g.proj -p
XY location (unprojected)

Maciek

-------------------------------------------- Managed by Request Tracker

2

On Mon, 6 Feb 2006 16:52:42 +0100 (CET)
Maciek Sieczka via RT <grass-bugs@intevation.de> wrote:

Creating new location from an EPSG code fails.

I forgot to add I'm referring to a pretty fresh 61 cvs, 2006-02-01.

Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/

3

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.

4

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

5

Now v.in.ogr should work. Markus, you're right. GPJ_osr_to_grass requires a
pointer to OGRSpatialReferenceH.

Huidae Cho

On Thu, Feb 09, 2006 at 02:51:30PM +0100, Markus Neteler wrote:

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

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

6

Thanks, Huidae,

I was trying the same but missed the second one.
Now it works.

Finally (?) r.in.gdal suffers from the same problem.
Any ideas also there?

thanks

Markus

7

I've committed some bug fixes, so could you test new gproj library and related
modules?

Thanks
Huidae Cho

On Thu, Feb 09, 2006 at 06:07:19PM +0100, Markus Neteler wrote:

Thanks, Huidae,

I was trying the same but missed the second one.
Now it works.

Finally (?) r.in.gdal suffers from the same problem.
Any ideas also there?

thanks

Markus

8

Great, also r.in.gdal works again (detection of data set
projection).

Thanks!

Markus

On Thu, Feb 09, 2006 at 11:20:26AM -0600, Huidae Cho wrote:

I've committed some bug fixes, so could you test new gproj library and related
modules?

Thanks
Huidae Cho

On Thu, Feb 09, 2006 at 06:07:19PM +0100, Markus Neteler wrote:
> Thanks, Huidae,
>
> I was trying the same but missed the second one.
> Now it works.
>
> Finally (?) r.in.gdal suffers from the same problem.
> Any ideas also there?
>
> thanks
>
> Markus

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

--
Markus Neteler <neteler itc it> http://mpa.itc.it
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy

9

Thanks Markus and Huidae for taking care of this!

Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/