I just tested an omerc_michigan PROJ_INFO file with the alternative projection parameters and it does not work - the alpha: key-value pair mysteriously disappers somewhere in the subroutines that construct the proj command.
As a matter of fact /any/ key-value pair in the PROJ_INFO file starting with either "a" or "f" will fail to show up in the constructed proj commmand, except "a:" and "f: of course". Could this have something to do with the routines extracting ellipse parameters? Like discarding or not looking further into the projinfo stucture if first char of a key is "a" or "f"?
Before staring to trace through the routines I would like to ask if someone might have an idea where this happens.
rgds
Morten
PS. The PROJ_INFO file I tested:
name: Oblique Mercator
datum: nad83
towgs84: 0.000,0.000,0.000
proj: omerc
ellps: grs80
a: 6378137.0000000000
es: 0.0066943800
f: 298.2572221010
lat_0: 45.3091666667
lonc: -86.0000000000
alpha: 337.25556
k_0: 0.9996000000
x_0: 2546731.496
y_0: -4354009.816
no_rot: defined
no_uoff: defined
rot_conv: defined
Morten Hulden wrote:
Dave Kindem wrote:
From what I can tell, the Proj4 OMERC program accepts parameter information in a two ways:
--the two point method and
--the central point and azimuth method.
Currently, the GRASS seems to accept only two point information, and the State of Michigan publishes central point and azimuth parameters.
Is there a way to set up an OMERC-based location within GRASS using the data I have? Or, alternatively, can the OMERC interface be modified to accept central point and azimuth parameters in a future release?
Not quite sure, but I think this restriction only concerns the g.setproj program, normally used only when the location is created. After creating an omerc-location you should be able to edit the PROJ_INFO file to conform to the other method.
Remove the lines starting with lon_1, lon_2, lat_1 and lat_2 and instead add two lines with your central point and azimuth parameters:
lonc: <central point longitude>
alpha: <azimuth value>
Don't do this if you already have imported data into your location - create another location for testing.
After this change [rv].proj tools /should/ work as normal.
Please let us know if this worked or what error messages you get.
rgds
Morten
Hello Morten
On Wed, 24 Aug 2005, Morten Hulden wrote:
I just tested an omerc_michigan PROJ_INFO file with the alternative projection parameters and it does not work - the alpha: key-value pair mysteriously disappers somewhere in the subroutines that construct the proj command.
As a matter of fact /any/ key-value pair in the PROJ_INFO file starting with either "a" or "f" will fail to show up in the constructed proj commmand, except "a:" and "f: of course". Could this have something to do with the routines extracting ellipse parameters? Like discarding or not looking further into the projinfo stucture if first char of a key is "a" or "f"?
Yes indeed I think you're right---and it looks like this bug has been there for 10-15 years!
The problem is the use of strncmp() in lib/proj/get_proj.c which only checks the first few characters of a string for a match--resulting in a matching any parameter beginning with a, etc.
I have committed a fix to CVS; please test.
Paul
name: Oblique Mercator
datum: nad83
towgs84: 0.000,0.000,0.000
proj: omerc
ellps: grs80
a: 6378137.0000000000
es: 0.0066943800
f: 298.2572221010
lat_0: 45.3091666667
lonc: -86.0000000000
alpha: 337.25556
k_0: 0.9996000000
x_0: 2546731.496
y_0: -4354009.816
no_rot: defined
no_uoff: defined
rot_conv: defined
On Wed, 24 Aug 2005, Paul Kelly wrote:
As a matter of fact /any/ key-value pair in the PROJ_INFO file starting with either "a" or "f" will fail to show up in the constructed proj commmand, except "a:" and "f: of course". Could this have something to do with the routines extracting ellipse parameters? Like discarding or not looking further into the projinfo stucture if first char of a key is "a" or "f"?
Yes indeed I think you're right---and it looks like this bug has been there for 10-15 years!
A correction: the use of strncmp where strcmp would have done the job has
probably been there for that long, but initially it didn't specifically check for the "a" parameter using the strncmp function, so the bug involving losing the alpha parameter will only have appeared in the last few years.
Paul
Paul Kelly wrote:
On Wed, 24 Aug 2005, Morten Hulden wrote:
I just tested an omerc_michigan PROJ_INFO file with the alternative projection parameters and it does not work - the alpha: key-value pair mysteriously disappers somewhere in the subroutines that construct the proj command.
As a matter of fact /any/ key-value pair in the PROJ_INFO file starting with either "a" or "f" will fail to show up in the constructed proj commmand, except "a:" and "f: of course". Could this have something to do with the routines extracting ellipse parameters? Like discarding or not looking further into the projinfo stucture if first char of a key is "a" or "f"?
Yes indeed I think you're right---and it looks like this bug has been there for 10-15 years!
The problem is the use of strncmp() in lib/proj/get_proj.c which only checks the first few characters of a string for a match--resulting in a matching any parameter beginning with a, etc.
I have committed a fix to CVS; please test.
OK, proj-tools working now. I don't have any good maps of Michigan to play around with so I'm not sure if the no_rot, no_uoff, rot_conv booleans should be defined or not. But I guess Dave will find out once he gets his Grass fixed.
Thanks
Morten
name: Oblique Mercator
datum: nad83
towgs84: 0.000,0.000,0.000
proj: omerc
ellps: grs80
a: 6378137.0000000000
es: 0.0066943800
f: 298.2572221010
lat_0: 45.3091666667
lonc: -86.0000000000
alpha: 337.25556
k_0: 0.9996000000
x_0: 2546731.496
y_0: -4354009.816
no_rot: defined
no_uoff: defined
rot_conv: defined