5 Jul 03:52 2006

### Re: Re: Dozier's TM method---my summary

```On Thursday 29 June 2006 3:30 pm, Strebe <at> aol.com wrote:
...
> > Note that the cusp (poorly displayed in the previously mention gif url)
> > appears to be the beginning of the multiple root solution.  I say poorly
> > displayed as the gradation of the equitorial parallel should *smoothly*
> > begin
> > a swing to the north OR (importantly) to the south.
>
> The cusp is poorly observed, not poorly displayed. The illustration is
> exact to sub-pixel resolution and it matches Lee's illustration precisely
> despite using a different method of calculation. It seems you do not know a
> continuously differentiable curve when you see one.

My goodness, such a cranky old man!

I know you don't like me but I have tried to be civil.  Can we bury the
hatchet sometime.  I am getting too old for this bullshit.

--

--
Jerry and the low-riders: Daisy Mae and Joshua
"Cogito cogito ergo cogito sum"
Ambrose Bierce, The Devil's Dictionary

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

```
5 Jul 04:14 2006

### Re: New ellipsoid

```With any level of the proj4 software you can change the ellipsoid to any value
you wish within "reasonable" limits.  Major axis is not a problem in any case
as internally the projections are evaluated for a "unit ellipsoid" and the
results multiplied by the real major axis.  A problem may occur if the
eccentricity increases significantly over the range of the earth's value
because many calculations are approximations that assume a value of e^2 in
the range of 0.006.  I would suspect that for e^2 < 0.01 would work but I
would be careful beyond that range.  Smaller e should never be a problem.

Note: in most cases the computational factor involving eccentricity is in the
form of e^2 or e (eccentricity) so that is what I must referred to here.  To
phrase the range in terms of flattening, minor axis, etc. you will need to do
a little math with the equations given in the documentation relating them to
eccentricity.

On Friday 30 June 2006 3:33 pm, Fabrizio Bernardini wrote:
> I am new in this list and I do not know if this topic has been discussed
> yet. I tried to search for it but got no useful results.
>
> My question is:
> How can I change ellipsoid and specify a completely
> new one, for instance for a planet which is NOT Earth.
> Will the projection library still work in this case?
>
> Did anybody ever discussed this issue?
> Is there a reference to that anywhere?
>
> Thanks,
>
> Fabrizio
```

5 Jul 04:42 2006

### Re: Command line conversion problem

```Mike,

The EPSG code 26711 is for UTM Zone 11 NAD 27. By the looks of your
input coordinates you should have used EPSG code 4267 (Lat/Lon NAD 27)

The other thing to look out for is that you're giving the coordinates
to cs2cs in the correct order. Usually cs2cs requires longitude
followed by latitude as the input order.

Anthony.

--- Mike D'Ambrogia <miked <at> jamagination.com> wrote:

> Trying to convert NAD27 DD.DDDDD to WGS84 UTM
>
> I use:
>
> cs2cs +init=epsg:26711 +to +init=epsg:32611
>
> Trying to convert 38.1703 -119.7385 and all I can get out is "*
> *
> 0.00", I should get 260102E 4228255N
>
> I'm goofing something up, hoping it's simple and someone can quickly
> point me in the right direction
>
>
> Mike
```

5 Jul 05:10 2006

### Re: Re: Dozier's TM method---my summary

```On Thursday 29 June 2006 3:30 pm, Strebe <at> aol.com wrote:
> In a message dated 6/29/06 08:45:00, gerald.evenden <at> verizon.net writes:
> (Full text of message at end.)
>
> > ...is the Newton-Raphson method employed.  He has expanded the
> > basic real function and applied it to a complex variable.  I am not sure
> > that
> > this is appropriate...
>
> I haven't looked at Dozier in depth, but in general there is nothing less
> appropriate about Newton-Raphson when applied to complex variables than
> there is when applied to real-valued variables. It's quite easy to get
> yourself into trouble when finding roots even of real-valued functions.
> While the function in question has problematic regions, that has nothing to
> do with the fact that it is complex-valued.

Isn't that what I just said???  At this point I am picking on Dozier, not you
nor anyone else.

> > plane.  Also, it looks like we are also dealing with multiple roots,
> > especially when longitude exceeds a certain value   (suggested to be
> > (pi/2)*(1-k))---a factor not addressed in Dozier's solution
>
> I do not understand why you think the fact of multiple roots supports your
> notion of the intractability of the solution.

Where did I say the solution did not exist nor the plot was not basically
correct---just poorly done.

... material previously commented on
```

5 Jul 14:31 2006

### Re: Re: Dozier's TM method---my summary

```> From: "Gerald I. Evenden"

> Stating it another way, my surrender was to the Dozier article that while the
> method sounds interesting the execution falls short.  The code had several
> errors and some methodology is in question.  I have spent an additional week
> rooting out a complex Bulirsch routine from the old Bell lab site and spent
> several days relating Jacobi's form to Legendre in order to test against
> Abramowitz tables and GSL software for at least real arguments---they now
> agree.  But Dozier's code does not agree to better than the third or forth
> place (I am not saying Dozier's code is wrong yet).
>
> And I still have no handle on a replacement for Newton-Raphson.

What surprises me is that I gave an alternative twice, once in a posting on
this list dated 2006-06-13, once in a private email dated 2006-06-23,
including a web reference.
It's about ACM TOMS algorithm 365 from H. Bach. Fortran code can be found at
netlib.org and one can buy a copy of the peer reviewed TOMS article at ACM
(acm.org).
I am not happy with the method because it is horribly slow, but it is a very
robust method, at least if one knows how to tweak its control parameters.

As for a replacement of complex Jacobi elliptic functions and a complex
elliptic integral: it can be done without too much effort. I provided in the
same manner (list posting and private email) references.
I do admit that working with complex elliptics is no trivial endeavor
without knowledge or experience.

_______________________________________________
Proj mailing list
```

5 Jul 16:38 2006

### Re: Re: Dozier's TM method---my summary

```On Wednesday 05 July 2006 8:31 am, Oscar van Vlijmen wrote:
> > From: "Gerald I. Evenden"
> >
> > Stating it another way, my surrender was to the Dozier article that while
> > the method sounds interesting the execution falls short.  The code had
> > several errors and some methodology is in question.  I have spent an
> > additional week rooting out a complex Bulirsch routine from the old Bell
> > lab site and spent several days relating Jacobi's form to Legendre in
> > order to test against Abramowitz tables and GSL software for at least
> > real arguments---they now agree.  But Dozier's code does not agree to
> > better than the third or forth place (I am not saying Dozier's code is
> > wrong yet).
> >
> > And I still have no handle on a replacement for Newton-Raphson.
>
> What surprises me is that I gave an alternative twice, once in a posting on
> this list dated 2006-06-13, once in a private email dated 2006-06-23,
> including a web reference.
> It's about ACM TOMS algorithm 365 from H. Bach. Fortran code can be found
> at netlib.org and one can buy a copy of the peer reviewed TOMS article at
> ACM (acm.org).
> I am not happy with the method because it is horribly slow, but it is a
> very robust method, at least if one knows how to tweak its control
> parameters.
>
> As for a replacement of complex Jacobi elliptic functions and a complex
> elliptic integral: it can be done without too much effort. I provided in
> the same manner (list posting and private email) references.
> I do admit that working with complex elliptics is no trivial endeavor
> without knowledge or experience.
```

5 Jul 21:20 2006

### Re: Re: Dozier's TM method---my summary

```On Wednesday 05 July 2006 8:31 am, Oscar van Vlijmen wrote:
...
> What surprises me is that I gave an alternative twice, once in a posting on
> this list dated 2006-06-13, once in a private email dated 2006-06-23,
> including a web reference.
> It's about ACM TOMS algorithm 365 from H. Bach. Fortran code can be found
> at netlib.org and one can buy a copy of the peer reviewed TOMS article at
> ACM (acm.org).
> I am not happy with the method because it is horribly slow, but it is a
> very robust method, at least if one knows how to tweak its control
> parameters.

Not sure what you meant by slow but the example clocked in at 2ms real time
and did not show on the millisecond user/system clocks.

Sorta looks like a steepest descent routine with no analysis from derivatives
so it is likely to be sluggish.

So much for Dozier's idea of a speedy method.

I stupidly missed all the control in the file so had to do about three whacks
at getting it to compile.  Once the junk was removed it went fine.

--

--
Jerry and the low-riders: Daisy Mae and Joshua
"Cogito cogito ergo cogito sum"
Ambrose Bierce, The Devil's Dictionary
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
```

6 Jul 00:57 2006

### Datum conversion

```Hi,

I am interested in doing point coordinate conversions from WGS84 lat/long points to SAD69. The SAD69 datum
does not appear to be natively supported in proj or cs2cs. Can someone tell me where to find the parameters
to use for this conversion?

Dr. Edward J. Hyer
Post-Doctoral Researcher
Naval Research Laboratory
Marine Meteorology Division
7 Grace Hopper Avenue, Stop 2
Monterey, California 93940
831-656-4023
FAX 831-656-4769
edward.hyer <at> nrlmry.navy.mil

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

```
6 Jul 02:32 2006

### Re: Datum conversion

```The SAD69 datum is not directly supported so you just have to provide
the ellipsoid parameters and the "towgs84" conversion values.

The following command will convert from lat/lon WGS74 to lat/lon SAD69:

cs2cs +proj=latlong +datum=WGS84 +to +proj=latlong +a=6378160.0
+rf=298.25 +towgs84=-57,1.0,-41

Anthony

--- "Hyer, Dr. Edward (Post Doc)" <edward.hyer <at> nrlmry.navy.mil> wrote:

> Hi,
>
> I am interested in doing point coordinate conversions from WGS84
> lat/long points to SAD69. The SAD69 datum does not appear to be
> natively supported in proj or cs2cs. Can someone tell me where to
> find the parameters to use for this conversion?
>
>
> Dr. Edward J. Hyer
> Post-Doctoral Researcher
> Naval Research Laboratory
> Marine Meteorology Division
> 7 Grace Hopper Avenue, Stop 2
> Monterey, California 93940
> 831-656-4023
> FAX 831-656-4769
> edward.hyer <at> nrlmry.navy.mil
```

6 Jul 01:50 2006

### Re: Datum conversion

```
Look in TR 8350.2 at:

http://earth-info.nga.mil/GandG/publications/

Note that this information is considered obsolete for operational use.  For
further information, contact the good folks at the Arnold, MO office of
NGA.

Note that South America is now on SIRGAS and not SAD69.  SAD69 was "thunk
up" by Dr. Irene Fischer, a very nice lady.  She's in her 80s or 90s now,
is about 4'10", and I once watched her chew out a three-star Admiral during
a classified symposium at Cameron Station some 38+ years ago!

Good luck,

Clifford J. Mugnier, C.P., C.M.S.
National Director (2006-2008),
Photogrammetric Applications Division
American Society for Photogrammetry and Remote Sensing
and
Chief of Geodesy,
CENTER FOR GEOINFORMATICS
Department of Civil Engineering
CEBA 3223A
LOUISIANA STATE UNIVERSITY
Baton Rouge, LA  70803
Voice and Facsimile:  (225) 578-8536 [Academic]
Voice and Facsimile:  (225) 578-4474 [Research]
Honorary Life Member of the
```