# [netCDFJava #FQF-323932]: Help on AlbersEqualArea

• Subject: [netCDFJava #FQF-323932]: Help on AlbersEqualArea
• Date: Tue, 09 Jan 2018 13:58:15 -0700

```Hi Nihat,

> To summarize, based on the reference document, computeTheta(double lon)
> should return

Okay, and currently we have: n * Math.toRadians(dlon)

If we "expand" the Math.toRadians method call, we have:

n * (dlon / 180 * PI)   // Current
vs
n * dlon / 180 * PI     // Proposed

Multiplication is associative, so these are actually equivalent expressions.
Doesn't look like a bug to me here.

However, here's something interesting:
http://spatialreference.org/ref/esri/usa-contiguous-albers-equal-area-conic/

That page defines Albers Equal Area Conic Projection parameters for several
popular implementations of the projection. Most of them define
"latitude_of_center" as 37.5. However, by default, we use 23 instead (see
https://github.com/Unidata/thredds/blob/master/cdm/src/main/java/ucar/unidata/geoloc/projection/AlbersEqualArea.java#L79).
Interesting. So, I tried both values:

AlbersEqualArea aea1 = new AlbersEqualArea();
System.out.println(aea1.latLonToProj(new LatLonPointImpl(36.975512,
-121.978782)));  // -2257 1863

AlbersEqualArea aea2 = new AlbersEqualArea(37.5, -96, 29.5, 45.5);
System.out.println(aea2.latLonToProj(new LatLonPointImpl(36.975512,
-121.978782)));  // -2257 251.5

Does aea2 give a better coordinate for that lat/lon?

Cheers,
Christian

> Hi Again
>
> Despite the fact that computeTheta() may have a bug, its ramifications are
> miniscule.  My issue of about 30km N-S displacement still remains. Apologies
> for assuming that in the earlier email.
>
> One way for you to reproduce the issue is the following
>
> 1) Read the shapefile at
>
> http://www.fire.ca.gov/fire_prevention/fire_prevention_wildland_statewide
>
> 2) Pick a random point over California (lat,lon) and try to see where it
> lands over this shapefile.
>
> For example, if I you pick (36.975512       -121.978782), after projecting
> this onto AlbersEqualArea, this point will be at X mark I placed on the
> picture below.  About 0.3-0.4deg north of where it is supposed to be.  There
> are a lot of moving parts here so it is hard to know where the problem is. It
> could be that .prj information associated with the shapefile is wrong or it
> may be that AlbersEqualArea.java is using different datum. But nothing should
> cause this big of a displacement. The fact that the google earth is putting
> the shapefile onto right plane makes me think that AlbersEqualArea.java is
> not doing its job. Any help here is greatly appreciated.
>
> Thanks
> Nihat Cubukcu
>
> -----Original Message-----
> From: Cubukcu, Nihat
> Sent: Tuesday, January 9, 2018 12:33 PM
> Subject: RE: [netCDFJava #FQF-323932]: Help on AlbersEqualArea
>
> Hi Christian,
>
> I wasn't sure how to produce this issue since I did not have  another trusted
> projection utility handy. I went with what you have provided (source code and
> the reference doc) and I think I found the issue. In the document
> https://pubs.usgs.gov/bul/1532/report.pdf, page 95 defines Theta as
> n*(Lambda-Lambda0) in Eq 12-4. This is computed in method computeTheta(double
> lon) in AlbersEqualArea.java. computeTheta first calculates the difference
> (dlon) but then converts "dlon" to radians. I believe the conversion has to
> be done after multiplying by "n". I did couple of test with my shapefile and
> in places along California coast and this correction indeed places the point
> in their rightful locations.
>
> To summarize, based on the reference document, computeTheta(double lon)
> should return
>
>
> //Original  return n * Math.toRadians(dlon);
>
> Regards,
> Nihat Cubukcu

Ticket Details
===================
Ticket ID: FQF-323932
Department: Support netCDF Java
Priority: High
Status: Closed
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata
inquiry tracking system and then made publicly available through the web.  If
you do not want to have your interactions made available in this way, you must
let us know in each email you send to us.

```

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.