[Proj] Mercator Problem

[Ron Russell]

What about using the Lat and Long of the endpoints to define the central
line of an Oblique Mercator, with a scale factor of 1.0 on the central line?
Then the distance can be calculated by Pythagoras, and other useful
operations can easily be calculated - mid point, distance of a third point
from the line and even the calculation of a buffer zone, all of which seem
horrendous when working on the ellipsoid. (OK, the mid point is not too
bad). 

Ron Russell
Tel : 01823 270308 email : ron at russfam.freeserve.co.uk 
-----Original Message-----
From: proj-bounces at lists.maptools.org
[mailto:proj-bounces at lists.maptools.org] On Behalf Of Clifford J Mugnier
Sent: 17 October 2005 20:52
To: PROJ.4 and general Projections Discussions
Subject: Re: [Proj] Mercator Problem





The Normal Aspect of the Mercator projection has only one practical
application, and that is for computing a Loxodrome or Rhumb Line with the
associated geometric manipulations/intersections of that line with the
graticule, etc.  Computing distances is a folly on the Normal Aspect
Mercator.  With two endpoints, just compute the inverse of the cartesian
coordinates back into latitude and longitude and then compute the correct
distance with a geodesic inverse.

I do not know how to perform that with PROJ4 commands.

Clifford J. Mugnier
Chief of Geodesy and
Associate Director,
CENTER FOR GEOINFORMATICS
Department of Civil Engineering
LOUISIANA STATE UNIVERSITY
Baton Rouge, LA 70803
Voice and Facsimile: (225) 578-8536 [Academic]
Voice and Facsimile: (225) 578-4474 [Research]
================================
http://www.ASPRS.org/resources/GRIDS
http://www.cee.lsu.edu/facultyStaff/mugnier/index.html
================================




Perhaps this is not the place for this questions and I should be posting
this observation to a different list . . . in any case input would be
appreciated. Sorry in advance if this observation is out of place.

Recently I reminded myself that measuring distance on maps is a difficult
matter, and I have observed some errors regarding the distance measuring
tools in mapServer (in particular with the use of the Mercator
projection).

After a little research, the problem regarding measuring distances when
using the standard Mercator projection would be a variable issue based on
lattitude. This is fairly obvious if we think about the way the Mercator
projection works, and perhaps my best solution is to choose a better
projection for my area of interest (California - perhaps a version of UTM
would give me better measurments - in fact I am reasonably certain it
would).

But the big questions for me is - since there are errors within the
distance measuring tools, do the same errors exist in the scalebar tools??

After measuring a few scalebars and comparing them to paper maps of
California it would seem that the answer is yes. All of the scalebars
drawn through mapServer are short (using the Standard Mercator between
lattitudes 33 and 38).

Even though the answer is that there is an error using distances with the
Standard Mercator with my system, I am, to say the least, unclear as to
where this problem lies . . . PROJ4 problem?? . . . a compile problem??  .
. . a GDAL problem?? some other issue???

I am sure that I can fudge a workaround for this, but at the same time . .
. any guidance for an eleant solution would be greatly appreciated . . .

for reference the following were my build steps:

for Proj4
[root at maps proj-4.4.9]# ./configure
[root at maps proj-4.4.9]# make
[root at maps proj-4.4.9]# make install

[root at maps proj-4.4.9]# cp ~/epsg /usr/local/share/proj/epsg

for GDAL
[root at maps gdal-1.2.6]# make clean
[root at maps gdal-1.2.6]# ./configure  --with-ogr --without-python
--with-xerces
[root at maps gdal-1.2.6]# make
[root at maps gdal-1.2.6]# make install
[root at maps gdal-1.2.6]# /sbin/ldconfig

for mapserver
[root at tuna mapserver4.4.2]# rm -f config.cache
[root at tuna mapserver4.4.2]# ./configure --without-tiff --with-threads
--with-proj --with-gdal=/usr/local/bin/gdal-config --with-ogr
--with-php=../php-5.0.4 --with-gd=/usr/local  --with-freetype=/usr/bin
--with-pdf --with-wmsclient --with-wfs --with-wfsclient
[root at tuna mapserver4.4.2]# make clean
[root at tuna mapserver4.4.2]# make
[root at tuna mapserver4.4.2]# cp mapserv /var/www/cgi-bin/mapserv_40
[root at tuna mapserver4.4.2]# cp mapscript/php3/php_mapscript.so
/usr/local/php/extensions/php_mapscript_40.so

I am using mapServer with PHP mapscript on a Fedora/apache system and all
my data is MapInfo (through OGR) - other than this problem, mapServer with
PROJ4 has performed much better than commercial software that I have used
in the past.

thanks
tim

Tim Norris

ps This has also been posted to the mapServer listserv.
_______________________________________________
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