headers
Mikael Rittri | 1 Feb 2007 11:43
Picon

Converting EPSG (Hotine) Oblique Mercator definitions to PROJ lines

Hello,
I have thought about the relation between the Hotine Oblique Mercators
of EPSG and PROJ.4.  
I'll explain my current understanding in the form of two design
questions.
(This concerns only Hotine Oblique Mercator == Rectified Skew
Orthomorphic; not 
 Swiss/Hungarian Oblique Mercator or Laborde Oblique Mercator.)

1) Where is the point located, whose projected coordinates are x_0, y_0
(false easting, false northing)?  
   This question has two possible answers.
a) At the projection center (which has the central longitude and the
central latitude, and is
   on the central line).  
   EPSG calls this choice "Oblique Mercator", with coordinate operation
method code 9815,
   and the x_0 and y_0 are called EC and NC (Easting at projection
center, Northing at projection center).
   In PROJ.4, this corresponds to +proj=omerc, without using +no_uoff.

b) At the so-called natural origin, which is the nearest intersection of
the central line and the
   aposphere equator.  (It is enough to know that this will be pretty
near the ordinary equator of the earth.)
   This answer was apparently preferred by Hotine, as it simplifies the
formulas a little, and the countries
   he mapped were near the equator anyway.  
   EPSG calls this choice "Hotine Oblique Mercator", with coordinate
operation method code 9812,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Oscar van Vlijmen | 1 Feb 2007 16:45
Picon

Re: Converting EPSG (Hotine) Oblique Mercator definitions to PROJ lines

> From: "Mikael Rittri"
> Date: Thu, 1 Feb 2007 11:43:28 +0100
> Subject: Converting EPSG (Hotine) Oblique Mercator definitions to PROJ lines
> 
> Hello,
> I have thought about the relation between the Hotine Oblique Mercators
> of EPSG and PROJ.4.

What I can contribute to the discussion is a more practical view as in "how
do we calculate it?"

There aren't that many Oblique Mercator projections in actual use. In some
cases omerc is used as an ugly approximation to a projection not to be found
in some applications, like the Swiss grid, Hungarian EOV, Laborde Madagascar
and some others.
Then we have Snyder's technique of providing two points on the centerline
instead of central point and azimuth of the centerline.
The central point/azimuth method is the most common.

In developing my code I started with the libproj code and added merely a
couple of tweaks, found in GCTP (like more overshooting correction with
adj_lon) and a very important one: the alfa_c = 90 deg case. The latter is
not supported in libproj and the EPSG Guidance note 7-2 tells how to deal
with this situation. I'm not impressed by the rest of the omerc code in the
Guidance note however. The alfa_c = 90 case is important for some
approximations done with the aid of omerc.

A relatively simple solution for the 'true' Oblique Mercator projections (as
opposed to approximations): if you encounter an RSO, there are 2 options:
(1) Use omerc with no_offset.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christopher Portka | 1 Feb 2007 18:42

Converting Mercator Meters to Degrees

I'm trying to convert a UTM easting value to an easting in mercator meters and
then to its correct longitude.  The conversion from UTM to mercator is fine and
defined in the following way using the OGR library (I'm given a proper UTM
easting, northing, and zone):

   OGRSpatialReference utm;
   OGRSpatialReference mm;
   OGRCoordinateTransformation *transform;

   utm.SetProjCS("UTM / WGS84");
   utm.SetWellKnownGeogCS("WGS84");
   utm.SetUTM(UTMzone, TRUE);

   mm.SetMercator(0, 0, 1, 0, 0);
   mm.SetWellKnownGeogCS("WGS84");

   transform = OGRCreateCoordinateTransformation(&utm, &mm);
   if (transform == NULL) ...

   double x = UTMEasting;
   double y = UTMNorthing;
   if (!transform->Transform(1, &x, &y))  ...

However, now I want to convert the easting (only the easting) to its appropriate
longitude value.  Looking up the conversion from mercator meters easting to
longitude I get the following conversion:

   longitude = (MMEasting / 6356752.3142) * 57.295779513082322;
   OR longitude = (easting / earthRadius) * RadToDeg;
(Continue reading)

Permalink | Reply | 2 comments |
headers
Eric Miller | 1 Feb 2007 21:36
Favicon

Re: Converting Mercator Meters to Degrees


>>> On 2/1/2007 at 9:42 AM, Christopher Portka
<cportka <at> newwireless.com> wrote:
[snip]
> However, now I want to convert the easting (only the easting) to its

> appropriate
> longitude value.  Looking up the conversion from mercator meters
easting to
> longitude I get the following conversion:
> 
>    longitude = (MMEasting / 6356752.3142) * 57.295779513082322;
>    OR longitude = (easting / earthRadius) * RadToDeg;
> 
> But this gives me a slightly different value (about .1 degrees
smaller) than 
> if
> did the conversion with OGR like this:
[snip]
> I don't want to do this whole conversion though because I only need
the
> longitude.  Does anyone have an idea what I could be doing wrong in
my 
> longitude
> conversion?  Is there some kind of false easting or something that
gets set 
> in
> SetMercator that could be giving me differing values? I tried looking
at the
> source for SetMercator, but it doesn't look like it sets anything
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mikael Rittri | 2 Feb 2007 12:57
Picon

RE: Converting Mercator Meters to Degrees

I suspect your direct formula doesn't use the appropriate value for the
Earth radius.

CP>   longitude = (MMEasting / 6356752.3142) * 57.295779513082322;
CP>   OR longitude = (easting / earthRadius) * RadToDeg;

That value looks like some kind of average earth radius for a spherical
earth model.  
But I think you must use the equatorial radius of the WGS84 ellipsoid,
which is 

   6378137.0 meters

see, for example, http://home.online.no/~sigurdhu/WGS84_Eng.html

Best regards, 
  Mikael Rittri, Carmenta, Sweden. 

-----Original Message-----
From: proj-bounces <at> lists.maptools.org
[mailto:proj-bounces <at> lists.maptools.org] On Behalf Of Christopher Portka
Sent: den 1 februari 2007 18:43
To: proj <at> lists.maptools.org
Subject: [Proj] Converting Mercator Meters to Degrees

I'm trying to convert a UTM easting value to an easting in mercator
meters and then to its correct longitude.  
[ ... ] 

_______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sergey Spiridonov | 6 Feb 2007 10:59

Re: C API to calculate distances

Hi, Oliver

Oliver Eichler wrote:

> Yeah, that's what I need. I guess my pseudo code was misleading. Does
> proj4 implement such an API? Or do I have to make my own C function of
> Vincenty’s formula as described at

http://bugzilla.remotesensing.org/show_bug.cgi?id=1378

Are you looking for this?
--

-- 
Best regards, Sergey Spiridonov

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Permalink | Reply | 3 comments |
headers
Oliver Eichler | 6 Feb 2007 11:25
Picon

Re: Re: C API to calculate distances

Sergey Spiridonov wrote:
> Hi, Oliver
> 
> Oliver Eichler wrote:
> 
>> Yeah, that's what I need. I guess my pseudo code was misleading. Does
>> proj4 implement such an API? Or do I have to make my own C function of
>> Vincenty’s formula as described at
> 
> 
> http://bugzilla.remotesensing.org/show_bug.cgi?id=1378
> 
> Are you looking for this?

Yes I do :) Are those changes in the 4.5.0 release? Or just in the CVS?

Oliver

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Permalink | Reply | 2 comments |
headers
Frank Warmerdam | 6 Feb 2007 19:11
Picon
Favicon
Gravatar

Re: Re: C API to calculate distances

Oliver Eichler wrote:
> Sergey Spiridonov wrote:
>> Hi, Oliver
>>
>> Oliver Eichler wrote:
>>
>>> Yeah, that's what I need. I guess my pseudo code was misleading. Does
>>> proj4 implement such an API? Or do I have to make my own C function of
>>> Vincenty’s formula as described at
>>
>> http://bugzilla.remotesensing.org/show_bug.cgi?id=1378
>>
>> Are you looking for this?
> 
> Yes I do :) Are those changes in the 4.5.0 release? Or just in the CVS?

Oliver,

Those changes have not been applied in CVS yet.  You should be able to
patch your local copy of 4.5.0 based on the instructions in the report.
I'd appreciate a note if it works well.

Best regards,
--

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam <at> pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

_______________________________________________
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Childs | 7 Feb 2007 18:50

Rectified Skew Orthomorphic...

I am trying to use Proj4 v4.4.9 to implement RSO support as described below from a 2004 thread, but it does not appear that the changes discussed in the thread ever made it into Proj4. Am I missing something or did these changes never get made? Does anyone have a copy of the code that implemented the 'gamma_c' parameter for the 'omerc' projection? Thanks, MikeGlobal Mapper Software LLCmike <at> globalmapper.com ------------------------------------- An update: The forward script: opts="+proj=omerc +a=6377298.556 +rf=300.8017 +lat_0=4 +lonc=115 \   +alpha=53d18'56.9537 +gamma_c=53d7'48.3685 +k_0=0.99984 \   +x_0=590476.87 +y_0=442857.65" replicates the example for Borneo in EPSG #7 and opts="+proj=omerc  +a=6378206.4 +es=.006768657997291094 \+k=.9999 +lonc=-133d40 +lat_0=57 +alpha=-36d52'11.6315 \+x_0=818585.5672270928 +y_0=575219.2451072642 +units=us-ft" replicates the fortran version of gctp to 0.0005 us-ft. You can see that +gamma_c is the only difference in the usage. I would appreciate Malaysia specs and bench values as well as morebench values for Borneo. Thanks. About another weeks work to check inverse and other options andclean up documentation.

 

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Permalink | Reply | 6 comments |
headers
Oscar van Vlijmen | 7 Feb 2007 22:38
Picon

Re: Rectified Skew Orthomorphic...

> From: "Michael Childs"
> Date: Wed, 7 Feb 2007 11:50:50 -0600
> Subject: [Proj] Rectified Skew Orthomorphic...

> I am trying to use Proj4 v4.4.9 to implement RSO support as described below
> from a 2004 thread, but it does not appear that the changes discussed in the
> thread ever made it into Proj4. Am I missing something or did these changes
> never get made? Does anyone have a copy of the code that implemented the
> 'gamma_c' parameter for the 'omerc' projection?

I am inclined to believe that all useful omerc RSOs can be done with
libproj/proj with the natural x_0, y_0 and the no_off/no_uoff flag set.
Libproj is more flexible (or transparent) with respect to the alpha and
gamma parameters, but proj does its best.
Point is, as mr. Evenden pointed out in a posting dated Feb 6, 2004, that
you don't need both alpha and gamma. Manuals and parameter files often
specify both, but for reasonable projections you only need one; the other is
calculated automatically.
It could be that proj is somewhat more difficult to handle because it
doesn't recognize a gamma. But the gamma is calculated from the specified
alpha. If you need to rotate the u,v coordinates over gamma instead of
alpha, you can use the rot_conv flag in proj. One might want to study Table
4 in the proj manual proj.4.3.pdf.

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Permalink | Reply | 5 comments |

Gmane