7 Aug 2005 11:02

Local Projection Selection

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

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

```
7 Aug 2005 16:39

Re: Local Projection Selection

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```
7 Aug 2005 18:02

Re: Local Projection Selection

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

Patrick Mézard

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

```
7 Aug 2005 19:02

Re: Local Projection Selection

```Partick,

Is this a 3D problem?  Is it important for your "nearest neighbour search
using bounding box trees, and other things which are just easier to do in an
euclidian space" that the vertical dimension be preserved?

If so, you might consider using Earth-Centered Earth-Fixed 3D coordinates or
some local-horizontal or local-vertical flavor thereof.

Noel

----- Original Message -----
From: "Patrick Mézard" <pmezard <at> gmail.com>
To: "PROJ.4 and general Projections Discussions" <proj <at> lists.maptools.org>
Sent: Sunday, August 07, 2005 11:02 AM
Subject: Re: [Proj] Local Projection Selection

> 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
> 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.
>
> Thank you for your help.
>
> Patrick Mézard
>
> _______________________________________________
> Proj mailing list
> Proj <at> lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>

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

```
7 Aug 2005 20:43

Re: Local Projection Selection

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
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```
7 Aug 2005 21:38

Re: Local Projection Selection

```I am considering points on earth surface without elevation.
I have not thought about a full fledge 3D cartesian space. However, the
distances I have to compute are "geodesic" ones (or maybe "geoidic") not
euclidian distances. And I assumed that approximating in a 3D space
instead of a projective plane would be worse in term of accuracy, but I
may be wrong. It may be faster to computer however, but I am not even
sure since WGS84 => stereo-whatever has no reason to perform a cartesian
space rountrip as it is done when datum shifts are required.

Patrick Mézard

Noel Zinn wrote:

> Partick,
>
> Is this a 3D problem?  Is it important for your "nearest neighbour
> search using bounding box trees, and other things which are just
> easier to do in an euclidian space" that the vertical dimension be
> preserved?
>
> If so, you might consider using Earth-Centered Earth-Fixed 3D
> coordinates or some local-horizontal or local-vertical flavor thereof.
>
> Noel
>
> ----- Original Message ----- From: "Patrick Mézard" <pmezard <at> gmail.com>
> To: "PROJ.4 and general Projections Discussions"
> <proj <at> lists.maptools.org>
> Sent: Sunday, August 07, 2005 11:02 AM
> Subject: Re: [Proj] Local Projection Selection
>
>
>> 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
>> 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.
>

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

```
7 Aug 2005 21:47

Re: Local Projection Selection

```Gerald I. Evenden wrote:

> On Sun, 2005-08-07 at 18:02 +0200, Patrick Mézard wrote:
>
>>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
> 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.

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.

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

Great, thank you.

Patrick Mézard

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

```
8 Aug 2005 00:23

Re: Local Projection Selection

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

Patrick Mézard

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

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

```
8 Aug 2005 03:06

Re: Local Projection Selection

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```
8 Aug 2005 17:41

php_proj.dll - Not anymore included on PHP/MapScript package?

```Hi,

As far as I remember, the last package of MapServer/PHPMapScript from
MapTools
which included php_proj.dll was version 4.4.1

Why is this *php_proj.dll* not included anymore at 4.6 package?

Can I use this version using latest PHP 4.x or PHP 5.x?

Or is there a way to build it without needing *Micro\$oft Expensive
Studio* ? I mean,
is it possible to do it using the free *MS Visual C++ Toolkit 2003* or
another free compiler?

best regards

--

--
Eduardo Patto Kanegae
http://www.webmapit.com.br

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

```

Gmane