Details Ticket 3876


Comment | Reply | Take | Open


Serial Number 3876
Subject g.proj: proj4= fails, wkt= works partialy
Area grass6
Queue grass
Requestors werchowyna@epf.pl
Owner none
Status resolved
Last User Contact Mon Feb 13 10:22:44 2006 (3 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Wed Sep 27 01:25:41 2006 (2 yr ago)
Created Sat Dec 3 21:38:32 2005 (3 yr ago)

Transaction History Ticket 3876


Sat, Dec 3 2005 21:38:32    Request created by guest  
Subject: g.proj: proj4= fails, wkt= works partialy

Platform: GNU/Linux/i386
GRASS Version: CVS 2005-11-16

Here is my initial projection:

GRASS 6.1.cvs (huha2):~ > g.proj -p
-PROJ_INFO-------------------------------------------------
name       : Latitude-Longitude
datum      : S-42
towgs84    : 33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84
proj       : ll
ellps      : krassovsky
-PROJ_UNITS------------------------------------------------
unit       : degree
units      : degrees
meters     : 1.0


I wanted to change it with "g.proj wkt=wkt_file". It kindoff works, but:
1. the PERMANENT/WIND and PERMANENT/DEFAULT_WIND are left unchanged (still refer
to latlong).
2. only the WIND in working mapset is changed properly
3. surprisingly, a correct DEFAULT_WIND appears in current working mapset - but
it should go to PERMANENT.




Trying to change a projection to a following PROJ.4 description:

GRASS 6.1.cvs (huha2):~ > cat puwg1965_IV.prf
+proj=sterea +lat_0=50.625 +lon_0=21.08333333333333 +k=0.9998 +x_0=4637000 +y_0=5467000
+ellps=krass +towgs84=33.4297,-146.5746,-76.2865,-0.35867,-0.05283,0.84354,-0.84077
+units=m



It fails, no change is done:

GRASS 6.1.cvs (huha2):~ > g.proj -c proj4=puwg1965_IV.prf


WARNING!  A projection file already exists for this location

This file contains all the parameters for the
location's projection: ll

    Overriding this information implies that the old projection parameters
    were incorrect.  If you change the parameters, all existing data will be
interpreted differently by the projection software.
    GRASS will not re-project your data automatically

Would you still like to overwrite the current projection information (y/n) [n]
yProjection information updated!

GRASS 6.1.cvs (huha2):~ > g.proj -p
-PROJ_INFO-------------------------------------------------
name       : Latitude-Longitude
datum      : S-42
towgs84    : 33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84
proj       : ll
ellps      : krassovsky
-PROJ_UNITS------------------------------------------------
unit       : degree
units      : degrees
meters     : 1.0



Maciek
Sun, Dec 4 2005 17:20:20    Mail sent by paul-grass@stjohnspoint.co.uk  
Return-Path <paul-grass@stjohnspoint.co.uk>
Delivered-To grass-bugs@lists.intevation.de
Message-ID <439316DB.8000208@stjohnspoint.co.uk>
Date Sun, 04 Dec 2005 16:18:35 +0000
From Paul Kelly <paul-grass@stjohnspoint.co.uk>
User-Agent Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language en-us, en
MIME-Version 1.0
To Request Tracker <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [GRASS5] [bug #3876] (grass) g.proj: proj4= fails, wkt= works partialy
References <20051203203833.082F61006B6@lists.intevation.de>
In-Reply-To <20051203203833.082F61006B6@lists.intevation.de>
Content-Type text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Request Tracker wrote:
> I wanted to change it with "g.proj wkt=wkt_file". It kindoff works, but:
> 1. the PERMANENT/WIND and PERMANENT/DEFAULT_WIND are left unchanged (still
refer to latlong).
> 2. only the WIND in working mapset is changed properly
> 3. surprisingly, a correct DEFAULT_WIND appears in current working mapset -
but it should go to PERMANENT.

I take it you mean "g.proj -c wkt=wkt_file". You are right in that it 
won't work properly if you are not in the PERMANENT mapset. You need to 
have write access to the PERMANENT mapset anyway if you are going to 
change the projection files. I think changing the projection is a 
dramatic-enough thing to do to require the user to have selected the 
PERMANENT mapset before doing this, so I have changed g.proj to exit 
with an error if the user is not in PERMANENT.

This functionality (overwrite existing projection files) was not well 
tested; I have noticed also that the region was overwritten every time 
regardless of whether it had changed or not (if projection changed 
between UTM, XY, latlong or other, or if the zone changed {i.e. to or 
from UTM or changing UTM zone}). So if none of those change then the 
region file doesn't need to be changed and it won't change it. (Ideally 
of course the region file should not hold projection information but it 
is a legacy "feature" that it does and it is not really feasible to 
change it at this stage.)

If you have more multiple mapsets and the default region changes, you 
will need to run "g.region -d" in each mapset to update the region. This 
is another "feature" and also holds for g.setproj. I've changed g.proj 
so it will output a warning if you're likely to need to run g.region -d.

> Trying to change a projection to a following PROJ.4 description:
> 
> GRASS 6.1.cvs (huha2):~ > cat puwg1965_IV.prf
> +proj=sterea +lat_0=50.625 +lon_0=21.08333333333333 +k=0.9998 +x_0=4637000
+y_0=5467000 +ellps=krass +towgs84=33.4297,-146.5746,-76.2865,-0.35867,-0.05283,0.84354,-0.84077
+units=m
> 
> 
> 
> It fails, no change is done:
> 
> GRASS 6.1.cvs (huha2):~ > g.proj -c proj4=puwg1965_IV.prf

That should not work and should give an error (but would not have). I've 
fixed the return code checking so that it does. You need to run it like:
cat puwg1965_IV.prf | g.proj -c proj4=-
it is like that because PROJ.4-style descriptions are likely to be much 
shorter and more feasible to type on the command line than to read in 
from a file, and means you can do neat things with init codes and EPSG 
numbers easily. With the input wkt option that would of course work (it 
reads from a file there).
See the man page for more examples:
http://grass.itc.it/grass61/manuals/html61_user/g.proj.html

Paul


Sun, Dec 4 2005 21:36:20    Mail sent by werchowyna@epf.pl  
Return-Path <werchowyna@epf.pl>
Delivered-To grass-bugs@lists.intevation.de
Subject Re: [GRASS5] [bug #3876] (grass) g.proj: proj4= fails, wkt= works partialy
From Maciek Sieczka <werchowyna@epf.pl>
To Paul Kelly <paul-grass@stjohnspoint.co.uk>
Cc Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
In-Reply-To <439316DB.8000208@stjohnspoint.co.uk>
References <20051203203833.082F61006B6@lists.intevation.de> <439316DB.8000208@stjohnspoint.co.uk>
Content-Type text/plain
Date Sun, 04 Dec 2005 21:36:29 +0100
Message-Id <1133728590.11907.9.camel@localhost.localdomain>
Mime-Version 1.0
X-Mailer Evolution 2.2.1.1
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Paul,

Thanks for your fixes.

There are more possible bugs:

1.
GRASS 6.1.cvs (poloniny_ll):~ > g.proj location=poloniny_65
wkt=puwg1965_IV.prj



New location is not created, no error output, no information. What
happens actually (if anything)?



2.
GRASS 6.1.cvs (poloniny_ll):~ > g.proj --help

Description:
 Prints and manipulates GRASS projection information files.

Usage:
 g.proj [-pdjwefc] [georef=name] [wkt=name] [proj4=name]
   [location=name]
						^
					        |
				That's propably why I assumed I
				should specify a file name here
				(part of my initial bug report).


Maciek


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


Sun, Dec 4 2005 21:54:41    Mail sent by werchowyna@epf.pl  
Return-Path <werchowyna@epf.pl>
Delivered-To grass-bugs@lists.intevation.de
Subject Re: [GRASS5] [bug #3876] (grass) g.proj: proj4= fails, wkt= works partialy
From Maciek Sieczka <werchowyna@epf.pl>
To Paul Kelly <paul-grass@stjohnspoint.co.uk>
Cc Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
In-Reply-To <1133728590.11907.9.camel@localhost.localdomain>
References <20051203203833.082F61006B6@lists.intevation.de> <439316DB.8000208@stjohnspoint.co.uk> <1133728590.11907.9.camel@localhost.localdomain>
Content-Type text/plain
Date Sun, 04 Dec 2005 21:54:55 +0100
Message-Id <1133729695.12347.2.camel@localhost.localdomain>
Mime-Version 1.0
X-Mailer Evolution 2.2.1.1
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Another one:

3.
when the current location is xy, "g.proj -c wkt=" doesn't make any
change and no error is printed:

GRASS 6.1.cvs (poloniny_65):~ > g.proj -p
XY location (unprojected)
GRASS 6.1.cvs (poloniny_65):~ > g.proj -c wkt=puwg1965_IV.prj
GRASS 6.1.cvs (poloniny_65):~ > g.proj -p
XY location (unprojected)

Maciek


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


Sun, Dec 4 2005 22:09:06    Mail sent by paul-grass@stjohnspoint.co.uk  
Return-Path <paul-grass@stjohnspoint.co.uk>
Delivered-To grass-bugs@lists.intevation.de
Message-ID <43935A84.6080705@stjohnspoint.co.uk>
Date Sun, 04 Dec 2005 21:07:16 +0000
From Paul Kelly <paul-grass@stjohnspoint.co.uk>
User-Agent Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language en-us, en
MIME-Version 1.0
To Maciek Sieczka <werchowyna@epf.pl>
Cc Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #3876] (grass) g.proj: proj4= fails, wkt= works partialy
References <20051203203833.082F61006B6@lists.intevation.de> <439316DB.8000208@stjohnspoint.co.uk> <1133728590.11907.9.camel@localhost.localdomain> <1133729695.12347.2.camel@localhost.localdomain>
In-Reply-To <1133729695.12347.2.camel@localhost.localdomain>
Content-Type text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Maciek Sieczka wrote:
> Another one:
> 
> 3.
> when the current location is xy, "g.proj -c wkt=" doesn't make any
> change and no error is printed:

I can see how that would have happened before but I think the second 
change I made this afternoon should have fixed that. Have you tried with 
the latest version?

Paul


Sun, Dec 4 2005 22:12:30    Mail sent by paul-grass@stjohnspoint.co.uk  
Return-Path <paul-grass@stjohnspoint.co.uk>
Delivered-To grass-bugs@lists.intevation.de
Message-ID <43935B57.4070505@stjohnspoint.co.uk>
Date Sun, 04 Dec 2005 21:10:47 +0000
From Paul Kelly <paul-grass@stjohnspoint.co.uk>
User-Agent Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language en-us, en
MIME-Version 1.0
To Maciek Sieczka <werchowyna@epf.pl>
Cc Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #3876] (grass) g.proj: proj4= fails, wkt= works partialy
References <20051203203833.082F61006B6@lists.intevation.de> <439316DB.8000208@stjohnspoint.co.uk> <1133728590.11907.9.camel@localhost.localdomain>
In-Reply-To <1133728590.11907.9.camel@localhost.localdomain>
Content-Type text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Maciek Sieczka wrote:
> Paul,
> 
> Thanks for your fixes.
> 
> There are more possible bugs:
> 
> 1.
> GRASS 6.1.cvs (poloniny_ll):~ > g.proj location=poloniny_65
> wkt=puwg1965_IV.prj
> 
> 
> 
> New location is not created, no error output, no information. What
> happens actually (if anything)?

In theory it should verify the input file (puwg1965_IV.prj) is 
correct/acceptable and then not do anything because you haven't 
specified any flags. None of the flags are required, but I suppose it is 
required to have at least one or else nothing happens. I don't know if 
there's an easy way to program it in the parser though. If there isn't 
it could be done in the module with just a little bit more work.

> 2.
> GRASS 6.1.cvs (poloniny_ll):~ > g.proj --help
> 
> Description:
>  Prints and manipulates GRASS projection information files.
> 
> Usage:
>  g.proj [-pdjwefc] [georef=name] [wkt=name] [proj4=name]
>    [location=name]
> 						^
> 					        |
> 				That's propably why I assumed I
> 				should specify a file name here
> 				(part of my initial bug report).

Hmm I didn't realise it was possible to change the text shown there. But 
it is (using the key_desc option) and I have.

Paul


Sun, Dec 4 2005 23:00:34    Mail sent by werchowyna@epf.pl  
Return-Path <werchowyna@epf.pl>
Delivered-To grass-bugs@lists.intevation.de
Subject Re: [bug #3876] (grass) g.proj: proj4= fails, wkt= works
From Maciek Sieczka <werchowyna@epf.pl>
To Paul Kelly via RT <grass-bugs@intevation.de>
In-Reply-To <20051204210906.10B2A1005AF@lists.intevation.de>
References <20051204210906.10B2A1005AF@lists.intevation.de>
Content-Type text/plain
Date Sun, 04 Dec 2005 23:00:46 +0100
Message-Id <1133733647.13686.1.camel@localhost.localdomain>
Mime-Version 1.0
X-Mailer Evolution 2.2.1.1
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
On nie, 2005-12-04 at 22:09 +0100, Paul Kelly via RT wrote:
> Maciek Sieczka wrote:
> > Another one:
> > 
> > 3.
> > when the current location is xy, "g.proj -c wkt=" doesn't make any
> > change and no error is printed:
> 
> I can see how that would have happened before but I think the second 
> change I made this afternoon should have fixed that. Have you tried with 
> the latest version?

Nope, I haven't. I'll get back to you if it shows the problem remains.

Maciek


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


Tue, Dec 6 2005 11:13:10    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Tue, 6 Dec 2005 23:12:54 +1300
From Hamish <hamish_nospam@yahoo.com>
To Paul Kelly <paul-grass@stjohnspoint.co.uk>
Cc werchowyna@epf.pl, grass-bugs@intevation.de, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #3876] (grass) g.proj: proj4= fails, wkt= works partialy
Message-Id <20051206231254.54446519.hamish_nospam@yahoo.com>
In-Reply-To <43935B57.4070505@stjohnspoint.co.uk>
References <20051203203833.082F61006B6@lists.intevation.de> <439316DB.8000208@stjohnspoint.co.uk> <1133728590.11907.9.camel@localhost.localdomain> <43935B57.4070505@stjohnspoint.co.uk>
X-Mailer Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
X-Face M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
X-Spam-Level
> > GRASS 6.1.cvs (poloniny_ll):~ > g.proj --help
> > 
> > Description:
> >  Prints and manipulates GRASS projection information files.
> > 
> > Usage:
> >  g.proj [-pdjwefc] [georef=name] [wkt=name] [proj4=name]
> >    [location=name]
> > 						^
> > 					        |
> > 				That's propably why I assumed I
> > 				should specify a file name here
> > 				(part of my initial bug report).
> 
> Hmm I didn't realise it was possible to change the text shown there.
> But  it is (using the key_desc option) and I have.


changed "name" to "string" in lib/gis/parser.c. The auto-gen help pages
and TCL dialogs already use that.


Hamish


Mon, Feb 6 2006 16:52:42    Mail sent by msieczka  
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
Mon, Feb 6 2006 20:12:12    Mail sent by werchowyna@epf.pl  
Return-Path <werchowyna@epf.pl>
Delivered-To grass-bugs@lists.intevation.de
Date Mon, 6 Feb 2006 20:12:00 +0100
From Maciek Sieczka <werchowyna@epf.pl>
To Maciek Sieczka via RT <grass-bugs@intevation.de>
Cc grass5@grass.itc.it, paul-grass@stjohnspoint.co.uk
Subject Re: [GRASS5] [bug #3876] (grass) g.proj: proj4= fails, wkt= works partialy
Message-Id <20060206201200.533928fc.werchowyna@epf.pl>
In-Reply-To <20060206155242.58EC2101EE8@lists.intevation.de>
References <20060206155242.58EC2101EE8@lists.intevation.de>
X-Mailer Sylpheed version 2.1.1 (GTK+ 2.8.6; i486-pc-linux-gnu)
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
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/


Thu, Feb 9 2006 12:20:34    Mail sent by msieczka  
Another update:

Using newer Grass 61 (CVS 2006-02-07) and newer GDAL (CVS 2006-02-09) the
error is different. No longer xy location is created, but a latlong (which is
still not what should be). Read below.



### Creating a location from EPSG code 2180 I get a latlong on WGS84:

$ g.proj -p
-PROJ_INFO-------------------------------------------------
name       : Lat/Lon
proj       : ll
no_defs    : defined
-PROJ_UNITS------------------------------------------------
unit       : degree
units      : degrees
meters     : 1.0



### While I expect (and used to get always before) a tmerc on GRS80, see:

$ epsg_tr.py -proj4 2180
# ETRS89 / Poland CS92
<2180> +proj=tmerc +lat_0=0 +lon_0=19 +k=0.999300 +x_0=500000 +y_0=-5300000
+ellps=GRS80 +units=m +no_defs  <>

Maciek
Thu, Feb 9 2006 12:30:58    Mail sent by paul-grass@stjohnspoint.co.uk  
Return-Path <paul-grass@stjohnspoint.co.uk>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 9 Feb 2006 11:30:42 +0000 (GMT)
From Paul Kelly <paul-grass@stjohnspoint.co.uk>
To Maciek Sieczka via RT <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [GRASS5] [bug #3876] (grass) g.proj: proj4= fails, wkt= works partialy
In-Reply-To <20060206155242.58EC2101EE8@lists.intevation.de>
Message-ID <Pine.LNX.4.60.0602091126480.31264@agrippa.ukshells.co.uk>
References <20060206155242.58EC2101EE8@lists.intevation.de>
MIME-Version 1.0
Content-Type TEXT/PLAIN; charset=US-ASCII; format=flowed
X-SA-Do-Not-Run Yes
X-SA-Exim-Connect-IP 217.10.143.90
X-SA-Exim-Mail-From paul-grass@stjohnspoint.co.uk
X-SA-Exim-Scanned No (on customer-relay-1.mail.uksolutions.net); SAEximRunCond expanded to false
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
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.


Thu, Feb 9 2006 14:51:35    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 9 Feb 2006 14:51:30 +0100
From Markus Neteler <neteler@itc.it>
To Paul Kelly <paul-grass@stjohnspoint.co.uk>
Cc Maciek Sieczka via RT <grass-bugs@intevation.de>, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #3876] (grass) g.proj: proj4= fails, wkt= works partialy
Message-ID <20060209135130.GT19361@bartok.itc.it>
Mail-Followup-To Paul Kelly <paul-grass@stjohnspoint.co.uk>, Maciek Sieczka via RT <grass-bugs@intevation.de>, grass5@grass.itc.it
References <20060206155242.58EC2101EE8@lists.intevation.de> <Pine.LNX.4.60.0602091126480.31264@agrippa.ukshells.co.uk>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
In-Reply-To <Pine.LNX.4.60.0602091126480.31264@agrippa.ukshells.co.uk>
User-Agent Mutt/1.4.1i
X-PGP-Key http://www.gdf-hannover.de/neteler/markus_gpgkey.asc
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
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",6
378388,297]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Merca
tor"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARAMETER["scale_factor",0.9
996],PARAMETER["false_easting",1500000],PARAMETER["false_northing",0],UNIT["Meter",1]]
Maybe it has to do with the definition of
OGRSpatialReferenceH
?

Markus


Thu, Feb 9 2006 18:00:06    Mail sent by grass4u@gmail.com  
Return-Path <grass4u@gmail.com>
Delivered-To grass-bugs@lists.intevation.de
DomainKey-Signature a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=Umh9+XvGjZOH63ebkPERK8CElEk7PsT/Lmg67oCB9i1Szjems0cF4oSQShXGu3QF6/LBxHn4QnvgKp6oeKkpLG8hWu5d13PyeiesJEQrn8DNgdoIfk2B3FuCDK5VOFbHtRteZVo4QBdB/uIU48J6XOcMOh5+uc6VwmpbKSjpiCw=
Date Thu, 9 Feb 2006 10:59:49 -0600
From Huidae Cho <grass4u@gmail.com>
To Paul Kelly <paul-grass@stjohnspoint.co.uk>, Maciek Sieczka via RT <grass-bugs@intevation.de>, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #3876] (grass) g.proj: proj4= fails, wkt= works partialy
Message-ID <20060209165949.GA1029@localhost.tamu.edu>
References <20060206155242.58EC2101EE8@lists.intevation.de> <Pine.LNX.4.60.0602091126480.31264@agrippa.ukshells.co.uk> <20060209135130.GT19361@bartok.itc.it>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
In-Reply-To <20060209135130.GT19361@bartok.itc.it>
User-Agent mutt-ng/devel (FreeBSD)
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
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_Mer
cator"],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


Thu, Feb 9 2006 18:07:24    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 9 Feb 2006 18:07:19 +0100
From Markus Neteler <neteler@itc.it>
To Huidae Cho <grass4u@gmail.com>
Cc Maciek Sieczka via RT <grass-bugs@intevation.de>, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #3876] (grass) g.proj: proj4= fails, wkt= works partialy
Message-ID <20060209170719.GQ9770@bartok.itc.it>
Mail-Followup-To Huidae Cho <grass4u@gmail.com>, Maciek Sieczka via RT <grass-bugs@intevation.de>, grass5@grass.itc.it
References <20060206155242.58EC2101EE8@lists.intevation.de> <Pine.LNX.4.60.0602091126480.31264@agrippa.ukshells.co.uk> <20060209135130.GT19361@bartok.itc.it> <20060209165949.GA1029@localhost.tamu.edu>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
In-Reply-To <20060209165949.GA1029@localhost.tamu.edu>
User-Agent Mutt/1.4.1i
X-PGP-Key http://www.gdf-hannover.de/neteler/markus_gpgkey.asc
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
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


Thu, Feb 9 2006 18:20:39    Mail sent by grass4u@gmail.com  
Return-Path <grass4u@gmail.com>
Delivered-To grass-bugs@lists.intevation.de
DomainKey-Signature a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=THG1+mbGlJUEIAkEkzAe6I8a0a7T1XO4d6fZ/bSmpaiipeTZji2r8Ts6PueFDXRvzId7YVr/yMJ3svorPkRoC4s7UPQdy42qv/zinoe1k0oXkABZ1qnuRQf0it+DQoqRLuDN/JZOGtn+KI3V3hBJq++yHi8ungkJZXYP9L+6gqA=
Date Thu, 9 Feb 2006 11:20:26 -0600
From Huidae Cho <grass4u@gmail.com>
To Maciek Sieczka via RT <grass-bugs@intevation.de>, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #3876] (grass) g.proj: proj4= fails, wkt= works partialy
Message-ID <20060209172026.GA1340@localhost.tamu.edu>
References <20060206155242.58EC2101EE8@lists.intevation.de> <Pine.LNX.4.60.0602091126480.31264@agrippa.ukshells.co.uk> <20060209135130.GT19361@bartok.itc.it> <20060209165949.GA1029@localhost.tamu.edu> <20060209170719.GQ9770@bartok.itc.it>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
In-Reply-To <20060209170719.GQ9770@bartok.itc.it>
User-Agent mutt-ng/devel (FreeBSD)
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
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


Thu, Feb 9 2006 18:42:30    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 9 Feb 2006 18:42:25 +0100
From Markus Neteler <neteler@itc.it>
To Huidae Cho <grass4u@gmail.com>
Cc Maciek Sieczka via RT <grass-bugs@intevation.de>, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #3876] (grass) g.proj: proj4= fails, wkt= works partialy
Message-ID <20060209174225.GS9770@bartok.itc.it>
Mail-Followup-To Huidae Cho <grass4u@gmail.com>, Maciek Sieczka via RT <grass-bugs@intevation.de>, grass5@grass.itc.it
References <20060206155242.58EC2101EE8@lists.intevation.de> <Pine.LNX.4.60.0602091126480.31264@agrippa.ukshells.co.uk> <20060209135130.GT19361@bartok.itc.it> <20060209165949.GA1029@localhost.tamu.edu> <20060209170719.GQ9770@bartok.itc.it> <20060209172026.GA1340@localhost.tamu.edu>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
In-Reply-To <20060209172026.GA1340@localhost.tamu.edu>
User-Agent Mutt/1.4.1i
X-PGP-Key http://www.gdf-hannover.de/neteler/markus_gpgkey.asc
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
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


Fri, Feb 10 2006 11:02:27    Mail sent by werchowyna@epf.pl  
Return-Path <werchowyna@epf.pl>
Delivered-To grass-bugs@lists.intevation.de
Date Fri, 10 Feb 2006 11:02:22 +0100
From Maciek Sieczka <werchowyna@epf.pl>
To Markus Neteler <neteler@itc.it>
Cc grass4u@gmail.com, grass-bugs@intevation.de, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #3876] (grass) g.proj: proj4= fails, wkt= works partialy
Message-Id <20060210110222.792916f3.werchowyna@epf.pl>
In-Reply-To <20060209174225.GS9770@bartok.itc.it>
References <20060206155242.58EC2101EE8@lists.intevation.de> <Pine.LNX.4.60.0602091126480.31264@agrippa.ukshells.co.uk> <20060209135130.GT19361@bartok.itc.it> <20060209165949.GA1029@localhost.tamu.edu> <20060209170719.GQ9770@bartok.itc.it> <20060209172026.GA1340@localhost.tamu.edu> <20060209174225.GS9770@bartok.itc.it>
X-Mailer Sylpheed version 2.1.1 (GTK+ 2.8.6; i486-pc-linux-gnu)
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
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/


Fri, Feb 10 2006 20:09:46    Mail sent by msieczka  
BTW this issue with creating projection from EPSG code, which is OK now, I
re-tested all the g.proj stuff which I complained about in my original bug
report. Looks all works fine, however I have one question about differences in
units names in case when wkt or proj4 option is used.

# When I override current projection using a wkt file, the projection units
# are in small letters:

$ g.proj -c wkt=puwg1965_I.prj
$ g.proj -p
-PROJ_INFO-------------------------------------------------
name       : sterea
proj       : sterea
a          : 6378245
es         : 0.006693421622965943
lat_0      : 50.625
lon_0      : 21.08333333333333
k          : 0.999800
x_0        : 4637000
y_0        : 5467000
towgs84    : 33.4297,-146.5746,-76.2865,-0.35867,-0.05283,0.84354,-0.84077
no_defs    : defined
-PROJ_UNITS------------------------------------------------
unit       : metre
units      : metres
meters     : 1



# But when I specify the same projection in proj4 syntax unit and units names
# start with a capital letter:

$ g.proj -c proj4="+proj=sterea +lat_0=50.625 +lon_0=21.08333333333333
+k=0.999800 +x_0=4637000 +y_0=5647000 +ellps=krass
+towgs84=33.4297,-146.5746,-76.2865,-0.35867,-0.05283,0.84354,-0.84077 +units=m"
$ g.proj -p
-PROJ_INFO-------------------------------------------------
name       : sterea
proj       : sterea
a          : 6378245
es         : 0.006693421622965943
lat_0      : 50.625
lon_0      : 21.08333333333333
k          : 0.999800
x_0        : 4637000
y_0        : 5647000
towgs84    : 33.4297,-146.5746,-76.2865,-0.35867,-0.05283,0.84354,-0.84077
no_defs    : defined
-PROJ_UNITS------------------------------------------------
unit       : Meter
units      : Meters
meters     : 1


Why the difference? Any problems possible due to this? Even if not, could the
naming convention be unified?

Maciek
Mon, Feb 13 2006 10:22:44    Mail sent by paul-grass@stjohnspoint.co.uk  
Return-Path <paul-grass@stjohnspoint.co.uk>
Delivered-To grass-bugs@lists.intevation.de
Date Mon, 13 Feb 2006 09:22:37 +0000 (GMT)
From Paul Kelly <paul-grass@stjohnspoint.co.uk>
To Maciek Sieczka via RT <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [bug #3876] (grass) g.proj: proj4= fails, wkt= works partialy
In-Reply-To <20060210190947.0218D100161@lists.intevation.de>
Message-ID <Pine.LNX.4.60.0602130907030.20767@agrippa.ukshells.co.uk>
References <20060210190947.0218D100161@lists.intevation.de>
MIME-Version 1.0
Content-Type TEXT/PLAIN; charset=US-ASCII; format=flowed
X-SA-Do-Not-Run Yes
X-SA-Exim-Connect-IP 217.10.143.90
X-SA-Exim-Mail-From paul-grass@stjohnspoint.co.uk
X-SA-Exim-Scanned No (on customer-relay-1.mail.uksolutions.net); SAEximRunCond expanded to false
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Hello Maciek

On Fri, 10 Feb 2006, Maciek Sieczka via RT wrote:

> BTW this issue with creating projection from EPSG code, which is OK now, I
> re-tested all the g.proj stuff which I complained about in my original bug
> report. Looks all works fine,

That's good to hear :) I'm sure there'll still be many more issues though.

> however I have one question about differences in
> units names in case when wkt or proj4 option is used.
>
> # When I override current projection using a wkt file, the projection units
> # are in small letters:

Does the WKT file specifically specify the units? If so then the value for 
"unit" will be taken from there. The WKT format doesn't have a way to 
specify a separate word for the plural like GRASS does so the letter 's' 
is simply added to the end for that. You can edit the PROJ_UNITS file 
later if you want.

I think that the unit names in PROJ_UNITS are only used for display 
purposes, e.g. in some d.* modules.

> # But when I specify the same projection in proj4 syntax unit and units names
> # start with a capital letter:

And also, American spelling. Well the PROJ-style string doesn't contain a 
word for the unit name, so presumably some default is coming from 
somewhere within GDAL/OGR. (I think I said this before but just to be 
clear, PROJ.4 isn't involved at all in parsing this string; it is all done 
in GDAL/OGR, which "interprets" the string.)

> Why the difference? Any problems possible due to this? Even if not, could the
> naming convention be unified?

The unit names are not coming from within GRASS so I don't think this is 
possible. I also don't see it as a big problem. You can also manually edit 
the PROJ_UNITS file if you really want to fix it. It is designed to be 
easily human-readable and editable.

It is just a by-product of the convenience of creating GRASS-native 
projection files from other sources, which don't always have as much 
information as the GRASS files do so "reasonable defaults" have to be 
filled in, and these can vary, as you have seen.

Paul


Mon, Feb 13 2006 19:34:39    Mail sent by werchowyna@epf.pl  
Return-Path <werchowyna@epf.pl>
Delivered-To grass-bugs@lists.intevation.de
Date Mon, 13 Feb 2006 19:34:29 +0100
From Maciek Sieczka <werchowyna@epf.pl>
To Paul Kelly via RT <grass-bugs@intevation.de>
Cc paul-grass@stjohnspoint.co.uk
Subject Re: [bug #3876] (grass) g.proj: proj4= fails, wkt= works partialy
Message-Id <20060213193429.90ee615d.werchowyna@epf.pl>
In-Reply-To <20060213092244.7446D1006A4@lists.intevation.de>
References <20060213092244.7446D1006A4@lists.intevation.de>
X-Mailer Sylpheed version 2.1.1 (GTK+ 2.8.6; i486-pc-linux-gnu)
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
On Mon, 13 Feb 2006 10:22:44 +0100 (CET)
Paul Kelly via RT <grass-bugs@intevation.de> wrote:

> On Fri, 10 Feb 2006, Maciek Sieczka via RT wrote:

<snip>

> > however I have one question about differences in
> > units names in case when wkt or proj4 option is used.
> >
> > # When I override current projection using a wkt file, the
> > # projection units are in small letters:
 
> Does the WKT file specifically specify the units?

Yes it does, "metre".

<snip>

> > # But when I specify the same projection in proj4 syntax unit and
> > # units names start with a capital letter:

<snip>

> > Why the difference? Any problems possible due to this? Even if
> > not, could the naming convention be unified?
 
> The unit names are not coming from within GRASS so I don't think this
> is possible. I also don't see it as a big problem. You can also
> manually edit the PROJ_UNITS file if you really want to fix it. It is
> designed to be easily human-readable and editable.

OK. If there is really not going to be any problem whether metre,
meter, Metre or Meter is put in the PROJ_INFO let it be. Although still
a pity this is not unfified. But I understand now it is not up to Grass.

Maciek

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


Thu, Feb 16 2006 14:38:58    Status changed to resolved by msieczka  
Tue, Sep 26 2006 18:35:47    Comments added by guest  
Good Luck! http://xoomer.alice.it/pik0/poker-rooms/
Tue, Sep 26 2006 22:40:40    Comments added by guest  
Cool design http://xoomer.alice.it/pik0/razz-poker/
Wed, Sep 27 2006 01:25:41    Comments added by guest  
Great work on website. <a href="http://xoomer.alice.it/pik0/rules-of-poker/">rules
of poker</a> [url=http://xoomer.alice.it/pik0/rules-of-poker/]rules of poker[/url]
http://xoomer.alice.it/pik0/rules-of-poker/
Comment | Reply | Take | Open

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request