[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