[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
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?

- 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
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

Thank you for your help.

Patrick Mézard

Proj mailing list
Proj at lists.maptools.org

More information about the Proj mailing list