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