Details Ticket 3630


Comment | Reply | Resolve


Serial Number 3630
Subject error in v.proj/r.proj in gnomonic projection
Area grass6
Queue grass
Requestors salek@chmi.cz
Owner pkelly
Status open
Last User Contact Mon Oct 24 10:58:11 2005 (3 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Mon Oct 31 09:27:33 2005 (3 yr ago)
Created Mon Sep 12 16:04:22 2005 (3 yr ago)

Transaction History Ticket 3630


Mon, Sep 12 2005 16:04:22    Request created by guest  
Subject: error in v.proj/r.proj in gnomonic projection

Platform: GNU/Linux/i386
grass obtained from: Trento Italy site
grass binary for platform: Downloaded precompiled Binaries
GRASS Version: 6.0.1

If gnomonic projection is set up, using the v.proj and r.proj in order to reproject
maps from various projection (lat-lon, S-42 etc)  results in erroneous north-south
shift of about 20-30 km (cca 0.2 degree od latitude). When using 'd.where', typical
points shows latitude souther than it should. The east-west coordinates are OK.
I have spent a lot of time searching for an error of mine, but was not successful.
In the grass version 5.0.3 it worked OK. Unfortunately, the system does not allow
to install the old version again. Before i start working on a workaround, I'd
like to make sure if it cannot be fixed here. I still cannot exclude my error.
If data are importet to the 'gnomonic' location from external source, 'd.where'
shows exact location in lat-lon, exactly as 'proj' itself computes.

I repeated the problem also on Spearfish dataset; I set up location spearfish_gnom,
here is the projection info:

GRASS 6.0.1 (spearfish_gnom):~ > g.proj -p -d -j -w -e   
-PROJ_INFO-------------------------------------------------
name       : Gnomonic
proj       : gnom
a          : 6379000.0000000000
es         : 0.0
f          : 0.0
lat_0      : 44.4600000000
lon_0      : -103.8500000000
-PROJ_UNITS------------------------------------------------
unit       : meter
units      : meters
meters     : 1.0
Datum name not present
Datum parameters not present
+proj=gnom
+lat_0=44.4600000000
+lon_0=-103.8500000000
+a=6379000
+b=6379000
+no_defs
PROJCS["Gnomonic",
    GEOGCS["Unknown",
        DATUM["D_unknown",
            SPHEROID["Unknown",6379000,"inf"]],
        PRIMEM["Greenwich",0],
        UNIT["Degree",0.017453292519943295]],
    PROJECTION["Gnomonic"],
    PARAMETER["latitude_of_origin",44.46],
    PARAMETER["central_meridian",-103.85],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]
-------------------------------

I set up a new location spearfish_gnom with following parameters 
(for faster calculation I chose coarser resolution than orig. Spearfish dataset):
$cat PROJ_INFO:
name: Gnomonic
proj: gnom
a: 6379000.0000000000
es: 0.0
f: 0.0
lat_0: 44.4600000000
lon_0: -103.8500000000

$cat DEFAULT_WIND:
proj:       99
zone:       0
north:      5000
south:      -30000
east:       20000
west:       -2000
cols:       220
rows:       350
e-w resol:  100
n-s resol:  100
top:        1
bottom:     0
cols3:      1
rows3:      1
depths:     1
e-w resol3: 1
n-s resol3: 1
t-b resol:  1

I reprojected elevation.dem from spearfish to spearfish_gnom and found that 
there was an evident shift in NS (y) direction of about 0.20 degree. East-west
direction was OK. 

I repeated the error shift on 3 PC, two of them running Mandrake 10.1 and one
Mandrake 10.0. 

If you find my error, sorry for that. Anyway, thank you very much for your work.
Milan Salek
Wed, Oct 19 2005 14:55:36    Owner changed to pkelly by mneteler  
Wed, Oct 19 2005 14:55:36    Mail sent by mneteler  
Milan,
(cc Paul)

I quickly inspected the report and found that "sphere" is
used here (6379000). Are we sure that d.where operates
properly? Which flags/parameters did you use for d.where (please
post)?

The problem may be related to sphere versus ellipsoid.

Markus
Thu, Oct 20 2005 09:17:46    Comments added by mneteler  
[message was trapped due to attachment - reposted by MN]

Subject: Re: [bug #3630] (grass) error in v.proj/r.proj in gnomonic projection
From: Milan Salek <salek chmi.cz>
Date: Wed, 19 Oct 2005 18:22:25 +0200

Markus,

it is not the problem of reference body. I am sending you a zip file in which
grassdata and one file for import are stored. In grassdata database you can find
location rad_m (with correct gnomonic projection on sphere which is defined for
our radar maps) and rad_ellps with gnomonic projection on ellipsoid wgs84. On
both locations the problem persists  - only differs by several minutes which
is
apparently caused by the different reference body. You can import and reproject
the test data easy using the command history.

Below I am perhaps describing the problem better (I am copying a portion of my
previous mail to Morten). Several people are trying to deal with it but so far
without any result. Morten Hulden spent some time on it but now he is probably
quite busy.

Here is the description of the problem (moreover, I have added the rad_ellps
location to the zip file):

[ http://mpa.itc.it/markus/tmp/rt3630_grassdata_etc.zip ]

---------------------------------------------------------------------------------
Enclosed you will find two locations, rad_m and fi_lambda, both roughly for the
same region, the former in gnomonic projection and the latter in lat/lon.

In the gnomonic projection there is an artificial array with some distinct
values creating a cross at a given location (it is the reference point of the
projection but it could be any arbitrary point)

d.proj -l -d works nicely, the point/cross gives accurate values:

          EAST:             NORTH:               LON:               LAT:
          -62.5              237.5        14.44612648        50.01013321


When using proj for the LON/LAT:
proj  +proj=gnom +lat_0=50.008 +lon_0=14.447 +a=6379000 +x_0=301500 +y_0=-217500
+es=0. +no_defs -f %6.0f <<EOF
14.44612648        50.01013321

it gives
301438  -217262 which, in respect to above mentioned results of d.proj -l -d,
and the false easting/northing given by proj parameters, gives nice match.

Here it works OK.

But, when I am in location fi_lambda and want to reproject 00test map into it,
it imports it OK but everything is by 0.2 degree to north.

Reprojection:
r.proj input=00test location=rad_m mapset=salek output=00test method=nearest
Then, when pointing to the little point/cross:

d.where -l -d
              LON:               LAT:

         14.447125        50.20371875
                          ------------

The little difference in LON does not bother me, but the LAT does.

The same results are in Spearfish area, the difference is about the same.

If you want to import the data yourself, try in rad_m:

r.in.bin input=$HOME/4grass_import/input_gnom.int output=00test bytes=2
north=217500 south=-310500 east=426500 west=-301500 rows=528 cols=728
---------------------------------------------------------------------------------
I still cannot exclude the "problem between the keyboard and my chair" but I
have been dealing with it since August without any success. So far I am
employing a "filthy" workaround - when reprojecting, I am using alternate
PROJ_INFO file (named PROJ_INFO.4reproj in location rad_m) with shifted
reference point, but it is not satisfactory solution.

Anyway, thank you for your assistance. Me and several my colleagues are using
grass and I'd like to promote it further. With this unresolved problem it it
rather complicated.

Best regards

Milan


-- ___________ \ o o / Milan Salek \ ^ / Regionalni predpovedni pracoviste \
~
/ Regional Forecasting Office Brno ( ( ) ) Czech Hydrometeorological Institute
( ( . ) ) Kroftova 43, 616 67 Brno, Czech Republic ( ( . ) ) (____________) )
tel.: +420-541 421 072 //// fax : +420-541 421 018 //// E-mail: salek chmi.cz
cell phone: +420-724 185 618 http://www.chmi.cz Ceska meteor. spolecnost /
Czech Meteorological Society: http://www.chmi.cz/poboc/BR/metspol/metspol.html
Sat, Oct 22 2005 19:07:14    Mail sent by morten@untamo.net  
Return-Path <morten@untamo.net>
Delivered-To grass-bugs@lists.intevation.de
Message-ID <435A71B5.2070507@untamo.net>
Date Sat, 22 Oct 2005 19:07:01 +0200
From Morten Hulden <morten@untamo.net>
User-Agent Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513)
X-Accept-Language en-us, en
MIME-Version 1.0
To Milan Salek <salek@chmi.cz>
Cc Markus Neteler via RT <grass-bugs@intevation.de>, unucka.j@chmi.cz, David Kral <kral@chmi.cz>
Subject Re: [bug #3630] (grass) error in v.proj/r.proj in gnomonic projection
References <20051019125537.487141006A8@lists.intevation.de> <435672C1.3030501@chmi.cz>
In-Reply-To <435672C1.3030501@chmi.cz>
Content-Type text/plain; charset=ISO-8859-2; 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
Milan,

I think I found it. My first input on this issue (and Markus') seems to 
be correct: It's the ellipsoid definition that causes the discrepancy in 
latitude. Just a hint, you may be able to go on from here yourself. 
Maybe you are expecting to see the longlat values for your reference 
points as they would show up on a Krassovsky ellipsoid, but d.where will 
give you the values on the same ellipsoid as the input.

To test, try the following with the external cs2cs program (not with 
proj) and you will find a difference in latitude that roughly 
corresponds to the discrepancy you see with d.where:

cs2cs +proj=latlong +a=6379000 +es=0 +to +proj=latlong +ellps=krass -f %.6f
14 50

and you should see:
14.000000       50.188967 13328.489324


So, no problem with proj and [vr].proj in Grass, its just that d.where 
(using proj) does not act as cartographic co-ordinate system filter like 
  cs2cs (latlong output from d.where seems to be disabled in latest cvs 
though).

If you use the Krassovsky ellipsoid in your Gnonomic location instead of 
the spheric model do you get the the expected latlong values for your 
reference points?

rgds
Morten


Milan Salek wrote:
> Markus,
> 
> it is not the problem of reference body. I am sending you a zip file in which
> grassdata and one file for import are stored. In grassdata database you can
find
> location rad_m (with correct gnomonic projection on sphere which is defined
for
> our radar maps) and rad_ellps with gnomonic projection on ellipsoid wgs84.
On
> both locations the problem persists  - only differs by several minutes which
is
> apparently caused by the different reference body. You can import and reproject
> the test data easy using the command history.
> 
> Below I am perhaps describing the problem better (I am copying a portion of
my
> previous mail to Morten). Several people are trying to deal with it but so
far
> without any result. Morten Hulden spent some time on it but now he is probably
> quite busy.
> 
> Here is the description of the problem (moreover, I have added the rad_ellps
> location to the zip file):
> 
> ---------------------------------------------------------------------------------
> Enclosed you will find two locations, rad_m and fi_lambda, both roughly for
the
> same region, the former in gnomonic projection and the latter in lat/lon.
> 
> In the gnomonic projection there is an artificial array with some distinct
> values creating a cross at a given location (it is the reference point of the
> projection but it could be any arbitrary point)
> 
> d.proj -l -d works nicely, the point/cross gives accurate values:
> 
>           EAST:             NORTH:               LON:               LAT:
>           -62.5              237.5        14.44612648        50.01013321
> 
> 
> When using proj for the LON/LAT:
> proj  +proj=gnom +lat_0=50.008 +lon_0=14.447 +a=6379000 +x_0=301500 +y_0=-217500
> +es=0. +no_defs -f %6.0f <<EOF
> 14.44612648        50.01013321
> 
> it gives
> 301438  -217262 which, in respect to above mentioned results of d.proj -l -d,
> and the false easting/northing given by proj parameters, gives nice match.
> 
> Here it works OK.
> 
> But, when I am in location fi_lambda and want to reproject 00test map into
it,
> it imports it OK but everything is by 0.2 degree to north.
> 
> Reprojection:
> r.proj input=00test location=rad_m mapset=salek output=00test method=nearest
> 
> Then, when pointing to the little point/cross:
> 
> d.where -l -d
>               LON:               LAT:
> 
>          14.447125        50.20371875
>                           ------------
> 
> The little difference in LON does not bother me, but the LAT does.
> 
> The same results are in Spearfish area, the difference is about the same.
> 
> If you want to import the data yourself, try in rad_m:
> 
> r.in.bin input=$HOME/4grass_import/input_gnom.int output=00test bytes=2
> north=217500 south=-310500 east=426500 west=-301500 rows=528 cols=728
> ---------------------------------------------------------------------------------
> 
> I still cannot exclude the "problem between the keyboard and my chair" but
I
> have been dealing with it since August without any success. So far I am
> employing a "filthy" workaround - when reprojecting, I am using alternate
> PROJ_INFO file (named PROJ_INFO.4reproj in location rad_m) with shifted
> reference point, but it is not satisfactory solution.
> 
> Anyway, thank you for your assistance. Me and several my colleagues are using
> grass and I'd like to promote it further. With this unresolved problem it it
> rather complicated.
> 
> Best regards
> 
> Milan
> 
> 
> 
> Markus Neteler via RT napsal(a):
> 
>>Milan,
>>(cc Paul)
>>
>>I quickly inspected the report and found that "sphere" is
>>used here (6379000). Are we sure that d.where operates
>>properly? Which flags/parameters did you use for d.where (please
>>post)?
>>
>>The problem may be related to sphere versus ellipsoid.
>>
>>Markus
>>
>>-------------------------------------------- Managed by Request Tracker
>>
> 
> 
> 


Sun, Oct 23 2005 18:37:07    Mail sent by salek@chmi.cz  
Return-Path <salek@chmi.cz>
Delivered-To grass-bugs@lists.intevation.de
Message-ID <435BBC22.4090502@chmi.cz>
Date Sun, 23 Oct 2005 18:36:50 +0200
From =?ISO-8859-2?Q?Milan_=A9=E1lek?= <salek@chmi.cz>
User-Agent Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language cs, en-us, en
MIME-Version 1.0
To Morten Hulden <morten@untamo.net>
Cc Markus Neteler via RT <grass-bugs@intevation.de>, unucka.j@chmi.cz, David Kral <kral@chmi.cz>
Subject Re: [bug #3630] (grass) error in v.proj/r.proj in gnomonic projection
References <20051019125537.487141006A8@lists.intevation.de> <435672C1.3030501@chmi.cz> <435A71B5.2070507@untamo.net>
In-Reply-To <435A71B5.2070507@untamo.net>
X-Enigmail-Version 0.92.1.0
Content-Type text/plain; charset=ISO-8859-2
Content-Transfer-Encoding 7bit
X-Virus-Scanned by amavisd-new-20030616-p10 (Debian) at relay.netbox.cz
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Morten,

thank you for your answer. I will definitely test it in the following
days as the time permits (I have several other duties, too) and will
send you the results.

Milan

Morten Hulden napsal(a):

> Milan,
>
> I think I found it. My first input on this issue (and Markus') seems
> to be correct: It's the ellipsoid definition that causes the
> discrepancy in latitude. Just a hint, you may be able to go on from
> here yourself. Maybe you are expecting to see the longlat values for
> your reference points as they would show up on a Krassovsky ellipsoid,
> but d.where will give you the values on the same ellipsoid as the input.
>
> To test, try the following with the external cs2cs program (not with
> proj) and you will find a difference in latitude that roughly
> corresponds to the discrepancy you see with d.where:
>
> cs2cs +proj=latlong +a=6379000 +es=0 +to +proj=latlong +ellps=krass -f
> %.6f
> 14 50
>
> and you should see:
> 14.000000       50.188967 13328.489324
>
>
> So, no problem with proj and [vr].proj in Grass, its just that d.where
> (using proj) does not act as cartographic co-ordinate system filter
> like  cs2cs (latlong output from d.where seems to be disabled in
> latest cvs though).
>
> If you use the Krassovsky ellipsoid in your Gnonomic location instead
> of the spheric model do you get the the expected latlong values for
> your reference points?
>
> rgds
> Morten
>
>
> Milan Salek wrote:
>
>> Markus,
>>
>> it is not the problem of reference body. I am sending you a zip file
>> in which
>> grassdata and one file for import are stored. In grassdata database
>> you can find
>> location rad_m (with correct gnomonic projection on sphere which is
>> defined for
>> our radar maps) and rad_ellps with gnomonic projection on ellipsoid
>> wgs84. On
>> both locations the problem persists  - only differs by several
>> minutes which is
>> apparently caused by the different reference body. You can import and
>> reproject
>> the test data easy using the command history.
>>
>> Below I am perhaps describing the problem better (I am copying a
>> portion of my
>> previous mail to Morten). Several people are trying to deal with it
>> but so far
>> without any result. Morten Hulden spent some time on it but now he is
>> probably
>> quite busy.
>>
>> Here is the description of the problem (moreover, I have added the
>> rad_ellps
>> location to the zip file):
>>
>> ---------------------------------------------------------------------------------
>>
>> Enclosed you will find two locations, rad_m and fi_lambda, both
>> roughly for the
>> same region, the former in gnomonic projection and the latter in
>> lat/lon.
>>
>> In the gnomonic projection there is an artificial array with some
>> distinct
>> values creating a cross at a given location (it is the reference
>> point of the
>> projection but it could be any arbitrary point)
>>
>> d.proj -l -d works nicely, the point/cross gives accurate values:
>>
>>           EAST:             NORTH:               LON:               LAT:
>>           -62.5              237.5        14.44612648        50.01013321
>>
>>
>> When using proj for the LON/LAT:
>> proj  +proj=gnom +lat_0=50.008 +lon_0=14.447 +a=6379000 +x_0=301500
>> +y_0=-217500
>> +es=0. +no_defs -f %6.0f <<EOF
>> 14.44612648        50.01013321
>>
>> it gives
>> 301438  -217262 which, in respect to above mentioned results of
>> d.proj -l -d,
>> and the false easting/northing given by proj parameters, gives nice
>> match.
>>
>> Here it works OK.
>>
>> But, when I am in location fi_lambda and want to reproject 00test map
>> into it,
>> it imports it OK but everything is by 0.2 degree to north.
>>
>> Reprojection:
>> r.proj input=00test location=rad_m mapset=salek output=00test
>> method=nearest
>>
>> Then, when pointing to the little point/cross:
>>
>> d.where -l -d
>>               LON:               LAT:
>>
>>          14.447125        50.20371875
>>                           ------------
>>
>> The little difference in LON does not bother me, but the LAT does.
>>
>> The same results are in Spearfish area, the difference is about the
>> same.
>>
>> If you want to import the data yourself, try in rad_m:
>>
>> r.in.bin input=$HOME/4grass_import/input_gnom.int output=00test bytes=2
>> north=217500 south=-310500 east=426500 west=-301500 rows=528 cols=728
>> ---------------------------------------------------------------------------------
>>
>>
>> I still cannot exclude the "problem between the keyboard and my
>> chair" but I
>> have been dealing with it since August without any success. So far I am
>> employing a "filthy" workaround - when reprojecting, I am using
>> alternate
>> PROJ_INFO file (named PROJ_INFO.4reproj in location rad_m) with shifted
>> reference point, but it is not satisfactory solution.
>>
>> Anyway, thank you for your assistance. Me and several my colleagues
>> are using
>> grass and I'd like to promote it further. With this unresolved
>> problem it it
>> rather complicated.
>>
>> Best regards
>>
>> Milan
>>
>>
>>
>> Markus Neteler via RT napsal(a):
>>
>>> Milan,
>>> (cc Paul)
>>>
>>> I quickly inspected the report and found that "sphere" is
>>> used here (6379000). Are we sure that d.where operates
>>> properly? Which flags/parameters did you use for d.where (please
>>> post)?
>>>
>>> The problem may be related to sphere versus ellipsoid.
>>>
>>> Markus
>>>
>>> -------------------------------------------- Managed by Request Tracker
>>>
>>
>>
>>
>
>


Mon, Oct 24 2005 02:11:21    Mail sent by morten@untamo.net  
Return-Path <morten@untamo.net>
Delivered-To grass-bugs@lists.intevation.de
Message-ID <435C26A4.6050002@untamo.net>
Date Mon, 24 Oct 2005 02:11:16 +0200
From Morten Hulden <morten@untamo.net>
User-Agent Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513)
X-Accept-Language en-us, en
MIME-Version 1.0
To =?ISO-8859-2?Q?Milan_=A9=E1lek?= <salek@chmi.cz>
Cc Markus Neteler via RT <grass-bugs@intevation.de>, unucka.j@chmi.cz, David Kral <kral@chmi.cz>
Subject Re: [bug #3630] (grass) error in v.proj/r.proj in gnomonic projection
References <20051019125537.487141006A8@lists.intevation.de> <435672C1.3030501@chmi.cz> <435A71B5.2070507@untamo.net> <435BBC22.4090502@chmi.cz>
In-Reply-To <435BBC22.4090502@chmi.cz>
Content-Type text/plain; charset=ISO-8859-2; 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
Milan,

more exactly, or in other words, I think you are expecting to see the 
latitude of your reference points as geodetic latitudes on the 
Krassovsky ellipsoid, not as Cartesian latitudes, which is what d.where 
will give you.

There is a small difference. The geodetic latitude of a point on the 
ellipsoid surface is defined as the angle from the equatorial plane of 
the line normal through the point. For an ellipse the line normal is not 
passing through origo of the co-ordinate system, except for latitudes 
-90, 0 and 90. For your location the difference in latitude between a 
spherical earth model and the Krassovksy ellipsoid is about 0.19 
degrees, roughly equal to what you reported, which led me to suspect 
this explanation.

rgds
Morten


Mon, Oct 24 2005 10:17:04    Mail sent by morten@untamo.net  
Return-Path <morten@untamo.net>
Delivered-To grass-bugs@lists.intevation.de
Message-ID <435C9874.4030001@untamo.net>
Date Mon, 24 Oct 2005 10:16:52 +0200
From Morten Hulden <morten@untamo.net>
User-Agent Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513)
X-Accept-Language en-us, en
MIME-Version 1.0
To Morten Hulden <morten@untamo.net>
Cc =?ISO-8859-2?Q?Milan_=A9=E1lek?= <salek@chmi.cz>, Markus Neteler via RT <grass-bugs@intevation.de>, unucka.j@chmi.cz, David Kral <kral@chmi.cz>
Subject Re: [bug #3630] (grass) error in v.proj/r.proj in gnomonic projection
References <20051019125537.487141006A8@lists.intevation.de> <435672C1.3030501@chmi.cz> <435A71B5.2070507@untamo.net> <435BBC22.4090502@chmi.cz> <435C26A4.6050002@untamo.net>
In-Reply-To <435C26A4.6050002@untamo.net>
Content-Type text/plain; charset=ISO-8859-2; 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
Morten Hulden wrote:

> spherical earth model and the Krassovksy ellipsoid is about 0.19 

should be 0.019, of course

M.


Mon, Oct 24 2005 10:58:11    Mail sent by pkelly  
According to the output of the "proj -lP" command:
gnom : Gnomonic
        Azi, Sph.
gnomonic projection can only be used with a spherical earth model. So you 
are going to get undefined behaviour / errors if re-projecting between an 
ellipsoid and a sphere.

Unfortunately I don't know enough to be able to explain it any better than 
that.

One last thing you could try to get the results you want would be to add the
line
towgs84: 0,0,0
to both the PROJ_INFO files for your two locations you are re-projecting 
from/to, before running v.proj. It might fool PROJ into doing some extra 
ellipsoid/sphere conversions; I don't know.
Mon, Oct 24 2005 16:55:23    Mail sent by salek@chmi.cz  
Return-Path <salek@chmi.cz>
Delivered-To grass-bugs@lists.intevation.de
Message-ID <435CF6BF.4090506@chmi.cz>
Date Mon, 24 Oct 2005 14:59:11 +0000
From Milan Salek <salek@chmi.cz>
User-Agent Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language cs, en-us, en
MIME-Version 1.0
To Morten Hulden <morten@untamo.net>
Cc Markus Neteler via RT <grass-bugs@intevation.de>, unucka.j@chmi.cz, David Kral <kral@chmi.cz>
Subject Re: [bug #3630] (grass) error in v.proj/r.proj in gnomonic projection
References <20051019125537.487141006A8@lists.intevation.de> <435672C1.3030501@chmi.cz> <435A71B5.2070507@untamo.net> <435BBC22.4090502@chmi.cz> <435C26A4.6050002@untamo.net>
In-Reply-To <435C26A4.6050002@untamo.net>
X-Enigmail-Version 0.92.1.0
Content-Type text/plain; charset=ISO-8859-2
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Just verified:

In grass 5.0.3 the problem DOES NOT EXIST. The match is OK in version 5.0.3.
Milan Salek


Mon, Oct 31 2005 09:27:33    Mail sent by salek@chmi.cz  
Return-Path <salek@chmi.cz>
Delivered-To grass-bugs@lists.intevation.de
Message-ID <4365D565.7030806@chmi.cz>
Date Mon, 31 Oct 2005 09:27:17 +0100
From Milan Salek <salek@chmi.cz>
User-Agent Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language cs, en-us, en
MIME-Version 1.0
To Morten Hulden via RT <grass-bugs@intevation.de>
Subject Re: [bug #3630] (grass) error in v.proj/r.proj in gnomonic projection
References <20051022170714.4AE101005A9@lists.intevation.de>
In-Reply-To <20051022170714.4AE101005A9@lists.intevation.de>
X-Enigmail-Version 0.92.1.0
Content-Type text/plain; charset=ISO-8859-2
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Morten,

to sum up, in GRASS 5.0.3 it works OK, no problem with the sphere/ellipsoid
issue, no problem with d.where -d -l. In version 6.0.1 it exhibits the error
obviously stemming from the ellipsoid-sphere difference. It sounds to me that
the [vr].proj does not take into account (or mix up) the reference body in the
new version(s). I have downgraded to GRASS 5.0.3 at one of my computer which
is
one of the solutions besides the "dirty" shifting the lat_0-lon_0 reference
point when reprojecting in version 6.*.

We developed another workaround - explicit reprojection routine which transfers
the gnomonic projection into lat-lon.

However, the deficiency should be acknowledged so that other colleagues do not
lose time then encountering this issue.

I'd appreciate that latlon output of 'd.where' be NOT disabled in the future
releases because the discussed problem is not the fault of d.where. Without
reprojecting from/in gnomonic projection, d.where shows nicely the lat&lon. If
the 'gnomonic problem' is the only reason why to disable it, I'd regret it.

Anyway, I thank you very much for your help, it clarified the situation for me.
Milan


Comment | Reply | Resolve

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