dkindem at chartermi.net
Wed Aug 24 09:48:34 EDT 2005
I tested an omerc file last night also. Here's the info on my mine:
name: Oblique Mercator
I was able to import and display a shape file, but when I try to re-
project the vector information into another location, I get the
v.proj input=ottawa location=OttawaOMERC output=county
Unable to initialise PROJ.4 with the following parameter list:
+proj=omerc +lat_0=45.3091666667 +lonc=-86.0000000000
+k_0=0.9996000000 +rot_conv +a=6378137 +rf=298.257222101 +no_defs
The error message was 'lat_1=lat_2 or lat_1=0 or lat_2=90'
As you noticed, the alpha value is missing. I'm also curious about
the f= value, which is evidently derived, since I did not enter it.
It also seems that the displayed image is basically an x-y plot, with
no connection to a particular location. Running d.where will return
the northing and easting of any location on the image, but the
program returns errors when asked for the lat/long location. In
order to make the connection, wouldn't GRASS need to use the false
northing/easting (or perhaps the lat/long location of the point of
origin) information supplied in the documentation?
Thanks for your help sorting through this.
On Aug 24, 2005, at 8:50 AM, 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"?
> Before staring to trace through the routines I would like to ask if
> someone might have an idea where this happens.
> 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
>>> 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.
More information about the grass-user