[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.
Gerald I. Evenden wrote:
> My immediate question is why not use a geodesic program rather than
> 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
> geodesic computation would be needed to determine optimal midpoint
> between the
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
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.
Proj mailing list
Proj at lists.maptools.org
More information about the Proj