Mercator Problem

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Mercator Problem

Tim Norris
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@maps proj-4.4.9]# ./configure
[root@maps proj-4.4.9]# make
[root@maps proj-4.4.9]# make install

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

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

for mapserver
[root@tuna mapserver4.4.2]# rm -f config.cache
[root@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@tuna mapserver4.4.2]# make clean
[root@tuna mapserver4.4.2]# make
[root@tuna mapserver4.4.2]# cp mapserv /var/www/cgi-bin/mapserv_40
[root@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
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Mercator Problem

Clifford J Mugnier




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@maps proj-4.4.9]# ./configure
[root@maps proj-4.4.9]# make
[root@maps proj-4.4.9]# make install

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

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

for mapserver
[root@tuna mapserver4.4.2]# rm -f config.cache
[root@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@tuna mapserver4.4.2]# make clean
[root@tuna mapserver4.4.2]# make
[root@tuna mapserver4.4.2]# cp mapserv /var/www/cgi-bin/mapserv_40
[root@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
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Mercator Problem

Paul Ramsey-2
In reply to this post by Tim Norris
Tim,

For a Mercator map of all of California, there is no *right* scale  
bar.  The scale at the top will be different from the scale at the  
bottom.  This is true of any Mercator map, just actually visible on  
maps of larger areas.  So the scale bar Mapserver is generating is  
probably right for *one* part of the map (perhaps the top or bottom?)  
and the scale bar from your paper map is right for *one* part of the  
map (the middle, maybe? or maybe for right where it is?).

For interactive things, like desktop user interfaces, it is possible  
to quietly cheat.  The measuring tool in uDig, for example, projects  
back into geographic coordinates, and does length calculations on the  
spheroid, rather than naively returning the length in the projected  
plane.  In this way it is possible to measure distances in meters  
while looking at a map in geographics, or get correct distances from  
a map in mercator.

Paul

On 17-Oct-05, at 12:35 PM, [hidden email] wrote:

> 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@maps proj-4.4.9]# ./configure
> [root@maps proj-4.4.9]# make
> [root@maps proj-4.4.9]# make install
>
> [root@maps proj-4.4.9]# cp ~/epsg /usr/local/share/proj/epsg
>
> for GDAL
> [root@maps gdal-1.2.6]# make clean
> [root@maps gdal-1.2.6]# ./configure  --with-ogr --without-python
> --with-xerces
> [root@maps gdal-1.2.6]# make
> [root@maps gdal-1.2.6]# make install
> [root@maps gdal-1.2.6]# /sbin/ldconfig
>
> for mapserver
> [root@tuna mapserver4.4.2]# rm -f config.cache
> [root@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@tuna mapserver4.4.2]# make clean
> [root@tuna mapserver4.4.2]# make
> [root@tuna mapserver4.4.2]# cp mapserv /var/www/cgi-bin/mapserv_40
> [root@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
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/proj
>

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

RE: Mercator Problem

Craig Miller-2
In reply to this post by Tim Norris
To get correct distances, you will need to calculated great-circle distance.

--Craig


-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Monday, October 17, 2005 12:36 PM
To: [hidden email]
Subject: [Proj] Mercator Problem

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@maps proj-4.4.9]# ./configure
[root@maps proj-4.4.9]# make
[root@maps proj-4.4.9]# make install

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

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

for mapserver
[root@tuna mapserver4.4.2]# rm -f config.cache
[root@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@tuna mapserver4.4.2]# make clean
[root@tuna mapserver4.4.2]# make
[root@tuna mapserver4.4.2]# cp mapserv /var/www/cgi-bin/mapserv_40
[root@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
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj




_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

RE: Mercator Problem

Ron Russell
In reply to this post by Clifford J Mugnier
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 : [hidden email]
-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] 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@maps proj-4.4.9]# ./configure
[root@maps proj-4.4.9]# make
[root@maps proj-4.4.9]# make install

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

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

for mapserver
[root@tuna mapserver4.4.2]# rm -f config.cache
[root@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@tuna mapserver4.4.2]# make clean
[root@tuna mapserver4.4.2]# make
[root@tuna mapserver4.4.2]# cp mapserv /var/www/cgi-bin/mapserv_40
[root@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
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj




_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

RE: Mercator Problem

Clifford J Mugnier
In reply to this post by Tim Norris




Ron,

You're proposing a piecewise-integration along a grid line.  With that,
you'd also have to include the correction for scale factor at a point, as
integrated by so many points of choice along the projected line.  Scale
factor along the Central Line of an Oblique Mercator is not going to
obviate that need.

It's far simpler to just call the subroutine in PROJ4 for an ellipsoidal
geodesic between the two end points.  (Once called the "Principal Problem
of Geodesy" in the 19th Century).

Assuming you know how to program the subroutine calls, it's easier done
than said.

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



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 : [hidden email]
-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] 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@maps proj-4.4.9]# ./configure
[root@maps proj-4.4.9]# make
[root@maps proj-4.4.9]# make install

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

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

for mapserver
[root@tuna mapserver4.4.2]# rm -f config.cache
[root@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@tuna mapserver4.4.2]# make clean
[root@tuna mapserver4.4.2]# make
[root@tuna mapserver4.4.2]# cp mapserv /var/www/cgi-bin/mapserv_40
[root@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
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj




_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Mercator Problem

strebe
In reply to this post by Tim Norris

Ron's proposal is perfectly sound on a spherical earth. Since the oblique Mercator central line runs through the two points of interest, and since the scale is constant and correct along that great circle, there's no need for integration or scale factor corrections. Obviously it's more problematic on the ellipsoid, given that none of the usual oblique formulations carry constant scale along the transformed equator (and if I recall correctly, it's not possible whilst retaining conformality), but even so, Hotine is close enough to constant scale that it might suffice, depending on the accuracy needs and assuming the two points are reasonably short of antipodal.

If other calculations that Ron mentions aren't needed then clearly Cliff's suggestion is the way to go. Why go out on a... erm... tangent?

Regards,
daan Strebe


In a message dated 10/17/2005 2:42:58 PM 太平洋夏時間, [hidden email] writes:

Ron,

You're proposing a piecewise-integration along a grid line.  With that,
you'd also have to include the correction for scale factor at a point, as
integrated by so many points of choice along the projected line.  Scale
factor along the Central Line of an Oblique Mercator is not going to
obviate that need.

It's far simpler to just call the subroutine in PROJ4 for an ellipsoidal
geodesic between the two end points.  (Once called the "Principal Problem
of Geodesy" in the 19th Century).

Assuming you know how to program the subroutine calls, it's easier done
than said.

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



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 : [hidden email]
-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Clifford J Mugnier
Sent: 17 October 2005 20:52
To: PROJ.4 and general Projections Discussions
Subject: Re: [Proj] Mercator Problem




_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

RE: Mercator Problem

Tim Norris
In reply to this post by Craig Miller-2
Many thanks for all the feedback on this . . . after some poking around in
the MapSever source code I think I found the reason for the measurement
problems in MapServer with the Standard Mercator projection (most of the
measurments for all projections are done with cartesian coordinates and not
any kind of spherical or geoid calculations). If I am to find a solution it
will be within MapServer.

thanks again
tim

Tim Norris

At 02:59 PM 10/17/2005, Craig Miller wrote:

>To get correct distances, you will need to calculated great-circle distance.
>
>--Craig
>
>
>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]]
>Sent: Monday, October 17, 2005 12:36 PM
>To: [hidden email]
>Subject: [Proj] Mercator Problem
>
>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@maps proj-4.4.9]# ./configure
>[root@maps proj-4.4.9]# make
>[root@maps proj-4.4.9]# make install
>
>[root@maps proj-4.4.9]# cp ~/epsg /usr/local/share/proj/epsg
>
>for GDAL
>[root@maps gdal-1.2.6]# make clean
>[root@maps gdal-1.2.6]# ./configure  --with-ogr --without-python
>--with-xerces
>[root@maps gdal-1.2.6]# make
>[root@maps gdal-1.2.6]# make install
>[root@maps gdal-1.2.6]# /sbin/ldconfig
>
>for mapserver
>[root@tuna mapserver4.4.2]# rm -f config.cache
>[root@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@tuna mapserver4.4.2]# make clean
>[root@tuna mapserver4.4.2]# make
>[root@tuna mapserver4.4.2]# cp mapserv /var/www/cgi-bin/mapserv_40
>[root@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
>[hidden email]
>http://lists.maptools.org/mailman/listinfo/proj
>
>
>
>
>_______________________________________________
>Proj mailing list
>[hidden email]
>http://lists.maptools.org/mailman/listinfo/proj


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

RE: Re: Mercator Problem

Ron Russell
In reply to this post by strebe

Daan, Clifford,

 

Of course, deep down, I knew that the scale varies along the central line of an oblique Mercator projection and I suppose my suggestion was not theoretically sound. I should also say that I get as much satisfaction as anybody when I get the chance to use Vincenty!

 

Even Vincenty does not deal with antipodal points, however!

 

In my defence I would say that we were talking about points scaled off a paper map!

 

In my days as a surveyor in the early 70s – do you remember Peter’s Tables and Facit mechanical calculators? – we used to use the mean of the scale factors at the end points of lines to reduce measured distances to the projection, and for the very longest lines we sometimes used Simpson’s rule (but I never remember it making a sensible difference). That was on at the edge of UTM zones. In those days it was really important to be able compute on the projection. I once computed a traverse using the Mid Latitude formulae – it took me two days, and I got the wrong answer!

 

I bet the scale change on the central line of a Hotine Oblique Mercator projection, even across California, could be treated the same way! Do you have any figures?

 

Regards,

 

Ron Russell
Tel : 01823 270308 email : [hidden email]


From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: 17 October 2005 22:56
To: [hidden email]
Subject: [Proj] Re: Mercator Problem

 


Ron's proposal is perfectly sound on a spherical earth. Since the oblique Mercator central line runs through the two points of interest, and since the scale is constant and correct along that great circle, there's no need for integration or scale factor corrections. Obviously it's more problematic on the ellipsoid, given that none of the usual oblique formulations carry constant scale along the transformed equator (and if I recall correctly, it's not possible whilst retaining conformality), but even so, Hotine is close enough to constant scale that it might suffice, depending on the accuracy needs and assuming the two points are reasonably short of antipodal.

If other calculations that Ron mentions aren't needed then clearly Cliff's suggestion is the way to go. Why go out on a... erm... tangent?

Regards,
daan Strebe


In a message dated 10/17/2005 2:42:58 PM
太平洋夏時間, [hidden email] writes:


Ron,

You're proposing a piecewise-integration along a grid line.  With that,
you'd also have to include the correction for scale factor at a point, as
integrated by so many points of choice along the projected line.  Scale
factor along the Central Line of an Oblique Mercator is not going to
obviate that need.

It's far simpler to just call the subroutine in PROJ4 for an ellipsoidal
geodesic between the two end points.  (Once called the "Principal Problem
of Geodesy" in the 19th Century).

Assuming you know how to program the subroutine calls, it's easier done
than said.

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



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 : [hidden email]
-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Clifford J Mugnier
Sent: 17 October 2005 20:52
To: PROJ.4 and general Projections Discussions
Subject: Re: [Proj] Mercator Problem




_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Mercator Problem

Gerald I. Evenden-2
In reply to this post by Clifford J Mugnier
I've tried to stay out of this problem but it persists.  Mugnier's statement
below is the best response to the original problem although it should be
added that the normal Mercator is useful as a conformal projection of areas
with east-west extent near the equator.

The only viable means of determining distance between points is by means of
any one of the geodesic formulas available.  The program 'geod' in the old
proj4 distribution uses one of these methods.  Vincenti's from the Geodetic
Survey is a slightly better method and is available as FORTRAN code.

If the points involved are in a local grid system or from a map, invert them
to geodetic coordinates and use above methods.

With current computing equipment and methods I don't think we need to resort
to good-old-day methods for computing the distance between points.

On Monday 17 October 2005 03:51 pm, Clifford J Mugnier wrote:
> 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.

--
Jerry and the low riders:Daisy May and Joshua
"The being cannot be termed rational or virtuous,
who obeys any authority, but that of reason."
---Mary Wollstonecraft 1792
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj