[GRASS5] m.proj Difference?

GRASS GRASS developer
1

Greetings all,

I am trying convert some Albers Equal Area coordinates to UTM coordinates, as I did with Grass Beta 11 and perhaps with earlier builds (beta 8?).

It seems as I am doing everything the same way I did with Beta 11, and yet I am getting slightly different results with Pre 4 then I did with Beta 11.

I entered all of the same projection values as I did before, and when I attempt to convert the same values I converted with Beta 11, I get results in the Y within 0.7 meters, and the X is off by about 510 meters. I get similar results with adjacent coordinates being off by a slight amount positively or negatively based on the direction traversed from the first test point.

All of the coordinates that I converted with Beta 11 are on the money, and I need to convert some more because of a data loss.

It seems like it must be a datum shift or some slight difference in the ellipsoid parameters.

Following are the projection parameters I am using:

m.proj2 inproj="+proj=aea +a=6378206.4 +es=0.0067686580 +lat_0=0.0000000000 +lat_1=34.0000000000 +lat_2=40.5000000000 +lon_0=-120.0000000000 +x_0=0.0000000000 +y_0=-4000000.0000000000 +unfact=1.0000000000" outproj="+proj=utm +a=6378206.4 +es=0.0067686580 +zone=11 +unfact=1.0000000000" input=test.coord output=results.coord

These are the AEA coordinates (in test.coord):

54460.32787477583042 -28942.57618516702496
43488.83566543841880 -29097.67753145935785

Which with Pre4 is converts to:

290240.740383 4181213.128503
279250.751623 4181409.678191

The values that Beta 11 correctly converted from the same AEA coords above are:

289729.04706660 4181213.82628647
278734.48157092 4181410.37628647

The values that Beta 11 converted are exactly aligned with other outside data sources.

Note that I used m.proj in beta 11, entered the same values in Pre 4 with m.proj to get the syntax for the proj2 call above. In Pre 4, both proj and proj2 give me the values which are slightly off from old successful conversions.

Am I just missing something? I greatly appreciate any help.

Here are the parameters I originally used in beta 11 (and in my Pre 4 attempts):

                   Coordinate Conversions

    1- Conversion 2- Input/Output Selection
    3- Quit

    Enter your selection [3] : 1

Initializing INPUT PROJECTION:

Please specify projection name
Enter 'list' for the list of available projections
Hit RETURN to cancel request
>aea

Initializing INPUT projection ELLIPSOID:
Please specify ellipsoid name
Enter 'list' for the list of available ellipsoids
Hit RETURN to cancel request
>clark66

  Enter INPUT Central Parallel [lat_0] (23N) : 0

  Enter INPUT First Standard Parallel [lat_1] (29:30N) : 34.0

  Enter INPUT Second Standard Parallel [lat_2] (45:30N) : 40.5

  Enter INPUT Central Meridian [lon_0] (96W) : -120

    Enter INPUT False Easting [x_0] (0.000000) :

    Enter INPUT False Northing [y_0] (0.000000) : -4000000.0
Enter plural for INPUT units [meters]:

Parameters used in INPUT projection:
         +proj=aea +a=6378206.4000000004 +es=0.0067686580 +lat_0=0.0000000000 +lat_1=34.0000000000 +lat_2=40.5000000000 +lon_0=-120.0000000000 +x_0=0.0000000000 +y_0=-4000000.0000000000 +unfact=1.0000000000

Initializing OUTPUT PROJECTION:

Please specify projection name
Enter 'list' for the list of available projections
Hit RETURN to cancel request
>utm

Initializing OUTPUT projection ELLIPSOID:
Please specify ellipsoid name
Enter 'list' for the list of available ellipsoids
Hit RETURN to cancel request
>clark66

    Enter OUTPUT Projection Zone [zone] : 11

OUTPUT Projection: Would you like to use South Hemisphere (y/[n]) ?
Enter plural for OUTPUT units [meters]:

Parameters used in OUTPUT projection:
         +proj=utm +a=6378206.4000000004 +es=0.0067686580 +zone=11 +unfact=1.0000000000

                   Coordinate Conversions

                 Coord->Lat/Long Conversion

With thanks,

Jeshua Lacock __________________________
Programmer/Owner Phone: 760.935.4736
http://OpenOSX.com Fax: 760.935.4845
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_

2

Jeshua Lacock wrote:

I entered all of the same projection values as I did before, and when I
attempt to convert the same values I converted with Beta 11, I get
results in the Y within 0.7 meters, and the X is off by about 510
meters. I get similar results with adjacent coordinates being off by a
slight amount positively or negatively based on the direction traversed
from the first test point.

All of the coordinates that I converted with Beta 11 are on the money,
and I need to convert some more because of a data loss.

It seems like it must be a datum shift or some slight difference in the
ellipsoid parameters.

Unlike earlier versions, the pre4 version of the proj library performs
datum shifts. Ensure that both locations have the correct datum.

--
Glynn Clements <glynn.clements@virgin.net>

3

On Fri, Jun 07, 2002 at 12:43:26PM +0100, Glynn Clements wrote:

Jeshua Lacock wrote:

> I entered all of the same projection values as I did before, and when I
> attempt to convert the same values I converted with Beta 11, I get
> results in the Y within 0.7 meters, and the X is off by about 510
> meters. I get similar results with adjacent coordinates being off by a
> slight amount positively or negatively based on the direction traversed
> from the first test point.
>
> All of the coordinates that I converted with Beta 11 are on the money,
> and I need to convert some more because of a data loss.
>
> It seems like it must be a datum shift or some slight difference in the
> ellipsoid parameters.

Unlike earlier versions, the pre4 version of the proj library performs
datum shifts. Ensure that both locations have the correct datum.

Am I right that datum shifts are only performed between NAD27 and NAD83
but not for, say, European datums?

Markus

4

On Friday 07 June 2002 06:23, Markus Neteler wrote:

> Unlike earlier versions, the pre4 version of the proj library performs
> datum shifts. Ensure that both locations have the correct datum.

Am I right that datum shifts are only performed between NAD27 and NAD83
but not for, say, European datums?

That is correct. Further, I never altered m.proj to do datum shifts. Those
changes were limited to the [rsv].proj group. Unless someone else made that
change then datum shifts shouldn't be the problem.

To the best of my knowledge there have been no changes to m.proj since the
earlier release other than now compiling it with an updated version of the
proj library.

Roger Miller
on vacation

5

On Fri, 7 Jun 2002, Jeshua Lacock wrote:

m.proj2 inproj="+proj=aea +a=6378206.4 +es=0.0067686580
+lat_0=0.0000000000 +lat_1=34.0000000000 +lat_2=40.5000000000
+lon_0=-120.0000000000 +x_0=0.0000000000 +y_0=-4000000.0000000000
+unfact=1.0000000000" outproj="+proj=utm +a=6378206.4 +es=0.0067686580
+zone=11 +unfact=1.0000000000" input=test.coord output=results.coord

These are the AEA coordinates (in test.coord):

54460.32787477583042 -28942.57618516702496
43488.83566543841880 -29097.67753145935785

Which with Pre4 is converts to:

290240.740383 4181213.128503
279250.751623 4181409.678191

Tested with external proj and get exactly the same results. This means
m.proj is performing correctly, and the difference must come from
different a and es values in your previous (beta 11) conversions.

The values that Beta 11 correctly converted from the same AEA coords
above are:

289729.04706660 4181213.82628647
278734.48157092 4181410.37628647

m.proj reads the a and es values from GRASS's ellipse table
(etc/ellipse.table). The current ellipse.table does not have an es value
for clark66, but an f-value instead, from which es is calculated. An older
version of ellipse.table might have had hardcoded es-values and this may
account for the differences you see.

Anybody able to say if ellipse.table has changed between beta11 and
pre4? Is the f-value given for clark66 in current ellipse.table correct?
Is the conversion routine f->es correct?

Morten Hulden

6

On Friday, June 7, 2002, at 04:43 AM, Glynn Clements wrote:

I entered all of the same projection values as I did before, and when I
attempt to convert the same values I converted with Beta 11, I get
results in the Y within 0.7 meters, and the X is off by about 510
meters. I get similar results with adjacent coordinates being off by a
slight amount positively or negatively based on the direction traversed
from the first test point.

All of the coordinates that I converted with Beta 11 are on the money,
and I need to convert some more because of a data loss.

It seems like it must be a datum shift or some slight difference in the
ellipsoid parameters.

Unlike earlier versions, the pre4 version of the proj library performs
datum shifts. Ensure that both locations have the correct datum.

Hi Glynn,

They are both in the NAD 27 datum, spheroid Clark66, 6378206.4, 294.9786982.

Do you know how I can ensure that I am entering the datum parameters correctly?

Thanks,

Jeshua Lacock __________________________
Programmer/Owner Phone: 760.935.4736
http://OpenOSX.com Fax: 760.935.4845
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_

7

Greetings,

I have diagnosed my problem to user error!

Why does that not surprise me? : )

After installing beta 11 on a machine, I got the same results! So that could only mean that I am converting different coordinates then I did before.

I apologize for wasting everyone's time.

Thanks,

Jeshua Lacock __________________________
Programmer/Owner Phone: 760.935.4736
http://OpenOSX.com Fax: 760.935.4845
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_