FW: Michigan Georef Projection Problems in Proj4

Clever, Max Maxc at SPICERGROUP.COM
Sat Jul 15 14:32:09 EDT 2006


Hi,

 

Did anyone see this the last time I sent it?  It relates to Mapserver as
well since Mapserver uses Proj4 for its projections.  

 

  _____  

From: Clever, Max 
Sent: Wednesday, July 12, 2006 2:03 AM
To: Frank Warmerdam; MAPSERVER-USERS at LISTS.UMN.EDU
Subject: Michigan Georef Projection Problems in Proj4

 

Hello Everyone,

Two years ago, I ran into a problem with the Michigan Georef Projection
and the way that proj identified it.  I had sent emails back and forth
for a while until someone sent a temporary solution of providing false
parameters that worked.. for the most part.  This temporary solution, of
course, did not actually solve the problem, but instead delayed the
fixing of the methods that proj identifies projections and translates
them.  For that I am sorry for not remaining vigilant in seeing a true
solution being devised.  But now, since I have just now installed the
latest version of GRASS 6.1, I have come full circle and face this
problem again.  To provide a quick access to the background of what has
already been said on this projection please note the previous emails
below.  I believe, at this time still, that the omerc projection and its
parameters as used by proj cannot correctly describe or transform a
omerc projection with a "natural origin".  From what I understand,
Hotine oblique mercator and Rectified Skew Orthomorphic are one and the
same or depend on where the skew is corrected.  Has there been a
solution determined for this projection?  If not, maybe a solution to
this problem would be to have Proj have oblique mercators split between
"natural origins" and cartesian center point origins.  I hope, maybe,
someone has been looking at this lately but I doubt it.  Any comments or
solutions would be very welcome.  Thanks.

Max Clever

 

Gerald Evenden gerald.evenden at verizon.net
<mailto:proj%40lists.maptools.org?Subject=%5BFwd%3A%20Re%3A%20%5BProj%5D
%20Re%3A%20The%20Michigan%20Georef%20Projection%20Problem%5D&In-Reply-To
=> 
Wed Dec 22 16:00:32 EST 2004 

*	Previous message: [Fwd: Re: [Proj] Re: The Michigan Georef
Projection Problem]
<http://lists.maptools.org/pipermail/proj/2004-December/001440.html> 
*	Next message: [Proj] A problem with this list
<http://lists.maptools.org/pipermail/proj/2004-December/001442.html> 
*	Messages sorted by: [ date ]
<http://lists.maptools.org/pipermail/proj/2004-December/date.html#1441>
[ thread ]
<http://lists.maptools.org/pipermail/proj/2004-December/thread.html#1441
>  [ subject ]
<http://lists.maptools.org/pipermail/proj/2004-December/subject.html#144
1>  [ author ]
<http://lists.maptools.org/pipermail/proj/2004-December/author.html#1441
>  

  _____  

Just to add my own two cents: the biggest problem with omerc is that 
there
are no universal standards for specifying this projection.  Indeed, 
Hotine
may have had a specific method in mind but various uses have created
their own systems and that's why there is 4 pages of description on the
projection in the file omerc.pdf on:
 
http://members.verizon.net/~vze2hc4d/proj4/
<http://members.verizon.net/%7Evze2hc4d/proj4/> 
 
This applies to libproj4 but some applies to old proj4.
_____________________________________
Jerry and the low riders: Daisy Mae and Joshua.
"The whole religious complexion of the modern world is due to the
absence from Jerusalem of a lunatic asylum." Havelock Ellis, 1914
 
 
Max -
 
Thanks; I guess my concern is that it would be odd for proj to "misuse"
this particular set of false easting and northing values, since it is
known to correctly use such values in all sorts of cases.  I just don't
like accepting answers that appear to work "for whatever reason", and I
will try to find time to look into this.
 
I'm reminded of the last two chapters of Isaac Asimov's "Second
Foundation".  They're titled "The Answer that Satisfied", followed by
"The Answer that was True"!
 
        - Ed
 
Ed McNierney
President and Chief Mapmaker
TopoZone.com / Maps a la carte, Inc.
73 Princeton Street, Suite 305
North Chelmsford, MA  01863
Phone: +1 978 251-4242   Fax: +1 978 251-1396 
 
-----Original Message-----
From: Clever, Max [mailto:Maxc at spicergroup.com
<http://lists.maptools.org/mailman/listinfo/proj> ] 
Sent: Wednesday, December 22, 2004 1:21 PM
To: Ed McNierney
Cc: proj at xserve.flids.com
<http://lists.maptools.org/mailman/listinfo/proj> 
Subject: RE: [Fwd: Re: [Proj] Re: The Michigan Georef Projection
Problem]
 
Ed,
 
the False Northings and Eastings defined in the Original Michigan Georef
EPSG file are the true parameters, but Proj does not handle them
properly for whatever reason.  The new Northings and Eastings that
Melita provided make up for Proj's miscalculation, at least to a certain
degree.  The problems that proj had originally created SEEM to me to
only be of a translational manner, other characteristics such as
azimuths and distances were very close to what they should be.  However,
I have not looked at the code that Proj uses for this projection.  So,
all in all, I guess I would say that the problem with proj and this EPSG
102123 is not really fixed.  But the new false Northing and Eastings
that Melita provided will work for what I intend to do for now.  I don't
consider myself an expert on transformation algorithms, even though I've
written a few before.  All I know is what the epsg parameters stand for
and that in this case, proj seems to be misusing them.
 
Max Clever
 
-----Original Message-----
From: Ed McNierney [mailto:ed at topozone.com
<http://lists.maptools.org/mailman/listinfo/proj> ]
Sent: Tuesday, December 21, 2004 7:04 PM
To: Clever, Max
Subject: RE: [Fwd: Re: [Proj] Re: The Michigan Georef Projection
Problem]
 
 
Max -
 
Yes, I saw that message - it just wasn't obvious what her changes were.
So you're saying that the False Northing and False Easting values are
incorrect, and that's it?  So now we have to figure out WHY they're
incorrect.  The values shown below:
 
 +x_0=2546731.496 +y_0=-4354009.816
 +x_0=499839.8337 +y_0=528600.2398
 
look completely different from one another.  Why?  I'm very concerned
that if you don't really understand why this change "fixed" the problem,
then it might not really fix it in the general case.
 
        - Ed
 
-----Original Message-----
From: Clever, Max [mailto:Maxc at spicergroup.com
<http://lists.maptools.org/mailman/listinfo/proj> ]
Sent: Tuesday, December 21, 2004 5:40 PM
To: Ed McNierney
Subject: RE: [Fwd: Re: [Proj] Re: The Michigan Georef Projection
Problem]
 
Ed,
 
this is the message that Dylan forwarded me today.  It solved my problem
of trying to project data with UTM and Michigan State Plane coordinates
onto a mapfile defined with the Michigan Georef Projection.  It gets the
image within about 0.5 meters of where it ought to be I think.  Here's
the message containing the parameters.  Really the only thing that ought
to be changed is the False Easting and False Northing, she rounded the
latitude and longitude to not enough decimal places but if you use what
she shows for that then its pretty close. 
 
-------- Original Message --------
Subject: Re: [Proj] Re: The Michigan Georef Projection Problem
Date: Mon, 20 Dec 2004 12:39:54 -0800 (PST)
From: Melita Kennedy [ESRI-Redlands] <mkennedy at esri.com
<http://lists.maptools.org/mailman/listinfo/proj> >
Reply-To: Melita Kennedy [ESRI-Redlands] <mkennedy at esri.com
<http://lists.maptools.org/mailman/listinfo/proj> >
To: gerald.evenden at verizon.net
<http://lists.maptools.org/mailman/listinfo/proj> , mkennedy2 at
earthlink.net <http://lists.maptools.org/mailman/listinfo/proj> ,
<http://lists.maptools.org/mailman/listinfo/proj> 
keon at nacse.org <http://lists.maptools.org/mailman/listinfo/proj> 
CC: mkennedy at esri.com
<http://lists.maptools.org/mailman/listinfo/proj> 
 
Hi Dylan, Jerry, and Frank
 
I'm not cc'ing to the list as I don't think I can post from this e-mail
account. Dylan, feel free to post all or part of my reply on the list if
you wish.
 
I think I understand what's happening, although I'm bit confused because
it means that the State Plane zone, Alaska zone 1, probably isn't
working either.
 
First off, here are a few test points from PROJ using this defn.
 
proj +proj=omerc +lat_0=45.309166667 +lonc=-86.0 +alpha=337.255555556
+k=0.9996 +x_0=2546731.496 +y_0=-4354009.816 +ellps=GRS80 +datum=NAD83 
+units=m
 
86W 43N
2546756.16 -4610501.20
86W 44N
2626908.90 -4498940.28
86W 45.309166667N
0.00 0.00
 
and now the results from the ESRI Projection Engine
 
cymru{melita}: forward91 102123
Projection Engine Version 9.0 (Dec 15 2004)
-86 43
-85 44
-86 45.309166667
499864.50  272108.86
580017.24  383669.77
499839.83  528600.24
 
Quite a difference, eh?
 
Hotine, "Oblique Mercator", RSO, and whatever other names are in use
confused me for quite a while. The ESRI Projection Engine now has
6 variants to try to support this map projection. Partially, that's
because we've added different versions at different times as we've come
to understand the projection better.
 
Hotine 2 Pt Natural Origin
Hotine 2 Point Center
Hotine Azimuth Natural Origin
Hotine Azimuth Center
 
Rectified Skew Orthomorphic - Natural Origin Rectified Skew Orthomorphic
- Center
 
PROJ supports Two Point and Point/Azimuth cases. From what I'm seeing in
the results and in the documentation, they are what ESRI calls the
'Center' cases. That is, the cartesian origin is located at the 'center'
of the projection, lonc and lat_0.
 
The ESRI Natural Origin cases have the cartesian origin where the
central line crosses the aposphere. This is almost the ellipsoid's
equator. Alaska zone 1 and Michigan GeoRef both use the natural origin
case of Point/Azimuth. That's why they have such large negative false
northings and large positive false eastings.
 
The ESRI version (and the PROJ versions) also rectify the projection
back to 'north'. The default proj setting is +no_rot (no rotation).
The azimuth is used for the rectifying angle.
 
Hmmm, I get different results if I use +no_rot versus when I omit it. So
perhaps +no_rot is a rectifying angle of zero.
 
The ESRI RSO implementation have the same Hotine parameters, plus a
rectifying angle. Although I haven't tested it, I believe this is the
same parameter as the +no_rot parameter. The standard RSO definitions
must have this parameter set, as the rectifying angle is not the same as
the azimuth.
 
Snyder talks somewhat about this in a footnote in _Map Projections:
A Working Manual_, but I (and the projection programmers here find the
entire section to be difficult to follow.
 
I think you can get the results you expect with these parameters:
 
proj +proj=omerc +lat_0=45.309166667 +lonc=-86.0 +alpha=337.255555556
+k=0.9996 +x_0=499839.8337 +y_0=528600.2398 +ellps=GRS80 +datum=NAD83 
+units=m
 
Melita
 
--
Melita Kennedy
Product Specialist
ESRI, Inc.
mkennedy at esri.com <http://lists.maptools.org/mailman/listinfo/proj> 
 
 
-----Original Message-----
From: Ed McNierney [mailto:ed at topozone.com
<http://lists.maptools.org/mailman/listinfo/proj> ]
Sent: Tuesday, December 21, 2004 1:20 PM
To: Clever, Max; proj at xserve.flids.com
<http://lists.maptools.org/mailman/listinfo/proj> 
Subject: RE: [Fwd: Re: [Proj] Re: The Michigan Georef Projection
Problem]
 
 
Max -
 
I didn't have time to closely read Melita's email - what exactly was the
correction?  If the EPSG parameters for this projection are incorrect,
we should get that reported and fixed.  Thanks!
 
        - Ed
 
Ed McNierney
President and Chief Mapmaker
TopoZone.com / Maps a la carte, Inc.
73 Princeton Street, Suite 305
North Chelmsford, MA  01863
ed at topozone.com <http://lists.maptools.org/mailman/listinfo/proj> 
(978) 251-4242  
 
-----Original Message-----
From: proj-bounces at xserve.flids.com
<http://lists.maptools.org/mailman/listinfo/proj> 
[mailto:proj-bounces at xserve.flids.com
<http://lists.maptools.org/mailman/listinfo/proj> ] On Behalf Of Clever,
Max
Sent: Tuesday, December 21, 2004 1:23 PM
To: proj at xserve.flids.com
<http://lists.maptools.org/mailman/listinfo/proj> 
Subject: RE: [Fwd: Re: [Proj] Re: The Michigan Georef Projection
Problem]
 
Hello Everyone,
 
I just wanted to say thanks to everybody for the fix of the EPSG.
Melita, those new translational parameters worked great for what we are
doing with Michigan Georef, thanks to everyone who put time into
figuring out what was going wrong.  This forum definitely has some
collective brainpower.
 
Happy Holidays Everyone
 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-users/attachments/20060715/6afedc6d/attachment.html


More information about the mapserver-users mailing list