# [Proj] Local Projection Selection

Clifford J Mugnier cjmce at lsu.edu
Sun Aug 7 18:23:44 EDT 2005

```

I don't see why an Azimuthal Equidistant would not be the simplest way to
go.  Since the projection is essentially a  conversion between true azimuth
with a true geodesic as polar coordinates, and ordinary cartesian
coordinates that will accommodate the search algorithms - what's wrong with
KISS?  It's simple polar to rectangular and vice versa.

Cliff Mugnier
LSU
---------------------
Gerald I. Evenden wrote:

> My immediate question is why not use a geodesic program rather than
> projecting
> the data and using a plane system with its inherent distortions?

Because:
- I did not know there was code in PROJ.4 to do that and I have not much
time to test/integrate new stuff. Unfortunately, it seems the geodesic
computations are again using global variables everywhere to configure
the ellipsoid as well as to pass and retrieve parameters.
- I clearly overlooked the problem, and pure distance computations are
not enough. Sorry, I made you lose your time with this, I keep your
remarks about the geodesic calculations. The processing code really
needs the points to be projected in a plane to perform all sorts of
computations like nearest neighbour search using bounding box trees, and
other things which are just easier to do in an euclidian space.

>
> If one insists on using a projection, then Stereographic is probably
> most appropriate.
> Determining the center optimal central point is a problem as a
> inverse/forward
> geodesic computation would be needed to determine optimal midpoint
> between the
> points.

I understand it is not the optimal but I do think the mean center will
do. I have looked at the documentation about the Stereographic
projection in in PROJ.4 documentation and in
<http://www.remotesensing.org/geotiff/proj_list/oblique_stereographic.html>.
I suppose I can ignore the False Easting and Northing. Latitude and
longitude of natural origin would be the projection center point.
Remains the scale factor. I could let it at 1.0. But maybe there is a
way to generate it programmatically given a center point, and ellipsoid
and a working area radius. It probably does not worth the pain however.
Are the output coordinate units naturally in meters or have I missed
other parameters ?

>
> I can see means of minimizing the use of floating point but
> elimination would be quite
> difficult.

And premature optimization is evil. I will measure first. I listed this
constraint in case there were several alternative projections to choose
among.