[Proj] NAD problems on OSX 10.5 Leopard

Ed McNierney ed at topozone.com
Thu Jan 17 22:28:42 EST 2008


Rich -

The one thing that significantly surprised me was how well that code
performed on low-end machines.  I think I released it in 2002 - maybe
2001 - and there were plenty of "slow" computers visiting TopoZone.  I
realize it's just math (other than updating the status bar with the
formatted coordinate text), but I was really expecting to see some kind
of lag if you waved the mouse quickly on a slow machine, but I never saw
the slightest delay.  I have found that I sometimes worry excessively
about performance!

	- Ed

-----Original Message-----
From: proj-bounces at lists.maptools.org
[mailto:proj-bounces at lists.maptools.org] On Behalf Of Richard Greenwood
Sent: Thursday, January 17, 2008 8:34 PM
To: PROJ.4 and general Projections Discussions
Subject: Re: [Proj] NAD problems on OSX 10.5 Leopard

Ed,

Thanks for the detailed explanation. Nice, clean solution (I'd expect
no less fro you)!

I've done a bit of work on porting cs2cs to JavaScript. Grid shift
transformations pose an interesting challenge if you want to transfer
a minimum of data to the browser. Which is why I was curious as to
what you were doing.

Rich



On Jan 17, 2008 10:58 AM, Ed McNierney <ed at topozone.com> wrote:
> Rich -
>
> It's actually not much, and is pretty hardwired for NAD27/NAD83
support
> and converting UTM to lat/lon coordinates.
>
> All maps displayed on TopoZone are in the UTM projection.  I calculate
> the bounding box coordinates for each map in NAD27 UTM and NAD83 UTM,
> and pre-load that data on the page, accessible to JavaScript (just
some
> global variables).  As a subscriber moves the mouse over the map, the
> coordinates of the point under the cursor are displayed in the browser
> status bar.  For UTM coordinates, it's simple linear interpolation
> across the image extent.  If the user chooses lat/lon display, I use
the
> JavaScript code below to convert on the fly as the mouse is moved over
> the map. It's a one-way conversion from UTM to LL, and relies on a
> global variable (datumFlag) to indicate NAD27 (0) or NAD83 (1).
>
> Please remember that this is not a general solution but is designed
only
> to work properly for valid NAD27 (North American) coordinates.
>
>         - Ed
>
> function UTMtoLL(UTMNorthing, UTMEasting, UTMZone)
> {
>         var deg2rad = Math.PI / 180;
>         var rad2deg = 180.0 / Math.PI;
>
>         var k0 = 0.9996;
>         var a;
>         var eccSquared;
>         var eccPrimeSquared;
>         var e1;
>         var N1, T1, C1, R1, D, M;
>         var LongOrigin;
>         var mu, phi1, phi1Rad;
>         var x, y;
>         var ZoneNumber;
>
>         if (datumFlag == 0)
>         {
>                 a = 6378206;
>                 eccSquared = 0.006768658;
>         } else
>         {
>                 a = 6378137;
>                 eccSquared = 0.00669438;
>         }
>
>         e1 = (1-Math.sqrt(1-eccSquared))/(1+Math.sqrt(1-eccSquared));
>         x = UTMEasting - 500000.0; //remove 500,000 meter offset for
> longitude
>         y = UTMNorthing;
>
>         ZoneNumber = UTMZone;
>
>         LongOrigin = (ZoneNumber - 1)*6 - 180 + 3;  //+3 puts origin
in
> middle of zone
>
>         eccPrimeSquared = (eccSquared)/(1-eccSquared);
>
>         M = y / k0;
>         mu =
>
M/(a*(1-eccSquared/4-3*eccSquared*eccSquared/64-5*eccSquared*eccSquared*
> eccSquared/256));
>
>         phi1Rad = mu    + (3*e1/2-27*e1*e1*e1/32)*Math.sin(2*mu)
>                                 +
> (21*e1*e1/16-55*e1*e1*e1*e1/32)*Math.sin(4*mu)
>                                 +(151*e1*e1*e1/96)*Math.sin(6*mu);
>         phi1 = phi1Rad*rad2deg;
>
>         N1 =
> a/Math.sqrt(1-eccSquared*Math.sin(phi1Rad)*Math.sin(phi1Rad));
>         T1 = Math.tan(phi1Rad)*Math.tan(phi1Rad);
>         C1 = eccPrimeSquared*Math.cos(phi1Rad)*Math.cos(phi1Rad);
>         R1 =
>
a*(1-eccSquared)/Math.pow(1-eccSquared*Math.sin(phi1Rad)*Math.sin(phi1Ra
> d), 1.5);
>         D = x/(N1*k0);
>
>         Lat = phi1Rad -
>
(N1*Math.tan(phi1Rad)/R1)*(D*D/2-(5+3*T1+10*C1-4*C1*C1-9*eccPrimeSquared
> )*D*D*D*D/24
>
>
+(61+90*T1+298*C1+45*T1*T1-252*eccPrimeSquared-3*C1*C1)*D*D*D*D*D*D/720)
> ;
>         Lat = Lat * rad2deg;
>         LatS = formatDeg (Lat,0) + "N";
>
>         Long =
>
(D-(1+2*T1+C1)*D*D*D/6+(5-2*C1+28*T1-3*C1*C1+8*eccPrimeSquared+24*T1*T1)
>
> *D*D*D*D*D/120)/Math.cos(phi1Rad);
>         Long = LongOrigin + Long * rad2deg;
>         LongS = formatDeg (Long,0) + "W";
> }
>
> -----Original Message-----
> From: proj-bounces at lists.maptools.org
> [mailto:proj-bounces at lists.maptools.org] On Behalf Of Richard
Greenwood
> Sent: Wednesday, January 16, 2008 11:13 PM
> To: PROJ.4 and general Projections Discussions
> Subject: Re: [Proj] NAD problems on OSX 10.5 Leopard
>
>
> On Jan 16, 2008 9:09 AM, Ed McNierney <ed at topozone.com> wrote:
> > William -
> >
> > I wouldn't claim to be "definitive" but I get the same results as
you
> report on PROJ 4.5.0 running on Windows, and with my interactive
> JavaScript coordinate/datum converter on the TopoZone site (which uses
> PROJ behind the scenes for datum shifts).
> >
> >      - Ed
>
> Ed,
>
> I curious about your JavaScript coordinate converted because I've done
> a little work on one myself. I took a quick look on TopoZone and
> didn't see it. Could you point me to it?
>
> Rich
>
> --
> Richard Greenwood
> richard.greenwood at gmail.com
> www.greenwoodmap.com
>
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>



-- 
Richard Greenwood
richard.greenwood at gmail.com
www.greenwoodmap.com
_______________________________________________
Proj mailing list
Proj at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj



More information about the Proj mailing list