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

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 can see means of minimizing the use of floating point but elimination would be quite
difficult.

If the geodesic formula is all you need then I suggest trying to take the geometric
mean of the ellipsoid radii at one point and using the spherical geodesic to compute
the distance/azimuth to the other point.  Test these values with an ellipsoid geodesic
function such as program geod or Vincenti's method.  One might be able to get
half meter accuracy at 50km.  If not, then I recommend Vincenti's method which
will mean a moderate amount of double precision math.

On Sun, 2005-08-07 at 11:02 +0200, Patrick Mézard wrote:

Hello, I have a function performing distance calculations between points defined in WGS-84 and perhaps some angular computations too. The input dataset is always restricted to an area of at most 20km around a center point, and usually 10km. The area center is unspecified, but extreme cases (earth poles) are excluded. For every function call, I would like to reproject the input dataset into a euclidian space where I could perform metric computations. Accuracy is important but not critical (I could cope with offsets of 2/3m), computation speed is important too since the function is implemented on mobile devices where floating-point computations are rather slow. Could you give me advices to select a projection in PROJ.4 I could configure with a center point (x,y), matching the constraints above. Thank you for any hint. Patrick Mézard

-- -- _____________________________________________________________ Jerry and the Low Riders: Daisy Mae and Joshua "The most certain test by which we judge whether a country is really free is the amount of security enjoyed by minorities" ---Lord Acton, 1907

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

On Sun, 2005-08-07 at 18:02 +0200, Patrick Mézard wrote:
...

I suppose I can ignore the False Easting and Northing. Latitude and

Yes, indeed

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

Assuming that most of the points are within so many meters (ie. 50m) of the central point
(lat_0, lon_0) then select a k_0 factor that would make the scale factor 1
half way between the center point and projection limit.  The center's true scale will be
somewhat larger than 1. and the rim slightly smaller.  Start with about +k_0=.99999 .
Use the -V option to experiment.

If you are keeping within 50km. scale errors should probably kept to within much better than 1 part in
100000 or close to your 2/3 meter.

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 ?

The Cartesian coordinates are the same as the ellipsoid major axis units.  If 'a' is in
meters then the x-y values are in meters.  There is also a scaling parameter.
...

-- -- _____________________________________________________________ Jerry and the Low Riders: Daisy Mae and Joshua "The most certain test by which we judge whether a country is really free is the amount of security enjoyed by minorities" ---Lord Acton, 1907

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

On Sun, 2005-08-07 at 21:47 +0200, Patrick Mézard wrote:
...

Ok, and how do I compute the "real" scale factor? By comparing the "projected" and geodesic distance of two points ? It would make sense and given the geodesic functions in PROJ.4, I could generate the k_0 from any defined limit radius with some kind of minimization heuristic. But you are right, I will stay with k_0=1.0 for now.

I would pick a scale factor that works for  the 50km case and apply it to all computation.

To figure an appropriate scale factor use the -V option which shows scale error.
For example:

[l]proj -I -proj=sterea +ellps=whatever lat_0=45 lon_0=0 k_0=1. -V

which is the inverse projection.  Give some xy values like 0 50000 or 50000 0
and see what the scale error is.  From this select a value of k_0 which reduces
this error by half.

For Clarke '66 50km shows a scale error of 1.00001536.  Take the fractional part
and divide by two and subtract that from 1 to get 0.99999232 for k_0.  The scale
error is now 0.99999232 at the center and 1.00000768 at 50km.  The scale
error is about 1 at 37km from the center.

Changing the ellipsoid won't make that much difference for k_0 so one could
use the above value for all ellipsoids.

One might want to do the above experiment at various latitudes to check
on that effect.

To see true error between hypotenuse of Cartesian triangle and geodesic, compare
with program 'geod' distributed with the old PROJ.4 package or use Vincenti's FORTRAN
program available from NGS.

...

-- -- _____________________________________________________________ Jerry and the Low Riders: Daisy Mae and Joshua "The most certain test by which we judge whether a country is really free is the amount of security enjoyed by minorities" ---Lord Acton, 1907

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj