[GRASS5] PROJ_INFO and prime meridian

Markus Neteler neteler at itc.it
Wed Jun 4 15:36:58 EDT 2003

On Wed, Jun 04, 2003 at 08:16:54PM +0100, Paul Kelly wrote:
> Hello Markus
> Below are a few ideas about the problem
> On Wed, 4 Jun 2003, Markus Neteler wrote:
> ...
> > Using the latest CVS version, I created a location with LCC:
> > name: Lambert Conformal Conic
> > towgs84: -104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68
> > proj: lcc
> > ellps: bessel
> > a: 6377397.1550000003
> > es: 0.0066743722
> > f: 299.1528128000
> > lat_0: 45.9000000000   <- given 45:54N
> > lat_1: 33.0000000000   <- calculated by GRASS, given 'return'
> > lat_2: 45.0000000000   <- calculated by GRASS, given 'return'
> I am actually not sure this is right at all; you could try deleting these
> two extra lines. I think lcc should have EITHER lat_0 OR (lat_1 AND lat_2)
> but NOT all 3. In fact this looks like a bug in g.setproj as 33 and 45 are
> the default values for lat_1 and lat_2 (in src/libes/gis/geo_init.c) and
> have not been 'calculated'. Perhaps someone more familiar with the lcc
> projection could comment.

In fact it is not obvious (yet) how to define LCC 1SP or LCC 2SP.
So I left it empty.

New test:
"old" PROJ_INFO:

g.region -l
long: 11.31206 lat: 46.51243 (north/west corner)
long: 11.51722 lat: 46.51646 (north/east corner)
long: 11.52172 lat: 46.40260 (south/east corner)
long: 11.31693 lat: 46.39858 (south/west corner)
rows:       127
cols:       158
Center Longitude: 11:25:01.148843E [11.41699]
Center latitude:  46:27:27.066733N [46.45752]

 lat_1: 33.0000000000
 lat_2: 45.0000000000

g.region -l
Unable to initialise PROJ.4 with the following parameter list:
 proj=lcc lat_0=45.9000000000 lon_0=14.0000000000 x_0=800000.0000000000
y_0=601000.0000000000 a=6377397.155000 rf=299.152813
The error message was 'conic lat_1 = -lat_2'
ERROR: Can't get projection key values of current location

-> LCC 1SP
 +proj=lcc   +lat_1=Latitude of natural origin
             +lon_0=Longitude of natural origin
             +k_0=Scale factor at natural origin
             +x_0=False Origin Easting
             +y_0=False Origin Northing

So this should work, but... (I didn't try yet with 'proj' nor cs2cs).
> > lon_0: 14.0000000000   <- given 14E
> > x_0: 800000.0000000000
> > y_0: 601000.0000000000
> >
> ...
> > Problems:
> > - how to define a different prime meridian (monte Mario old/new)?
> If the longitude of origin is given relative to the Monte Mario prime
> meridian, then you would need to add the two together to give the
> longitude of origin relative to Greenwich, i.e. 14d0 + 12d27'7.1 =
> 26d27'7.1"E Is this anywhere near the area covered by the map?

No, the area is at 11dsomething' E (see above).

According to:
"pm - Prime Meridian

 A prime meridian may be declared indicating the offset between the prime
meridian of the declared coordinate system and that of greenwich. A prime
meridian is clared using the "pm" parameter, and may be assigned a symbolic
name, or the longitude of the alternative prime meridian relative to

Currently prime meridian declarations are only utilized by the
pj_transform() API call, not the pj_inv() and pj_fwd() calls. Consequently
the user utility cs2cs does honour prime meridians but the proj user utility
ignores them. "

Monte Mario prime meridian is hardcoded in PROJ4:

grep rome *.c
pj_datums.c:    "rome",      "12d27'8.4\"E",

(where I would need 12d27'7.1). Maybe proj4 needs a custom prime
meridian (couldn't find if it is already there).

> Or maybe the Monte Mario pm simply means the map is referenced to the
> rome40 datum, in which case..
> > - the towgs84 may be wrong (no idea what to use, I selected rome40)
> these parameters would be right but the ellipsoid would be wrong, as
> rome40 uses international. Is there some other reason it should be bessel?

Right, rome40 uses international, but the US Army defined Bessel.
So it might be a wrong datum. Probably I have to ask on the PROJ4
list as well (tomorrow).

> ...
> > Ideas (comments welcome):
> > - Lambert Conic Orthomorphic != LCC (I hope not)
> I think they are the same
> > - the Gauss-boaga location with recent GIS data is wrong (I hope not)
> If it also is rome40 does it use the same towgs84 parameters?

In fact the reference location in Gauss-Boaga uses rome40 datum
with international ellipsoid. So, yes, the same towgs84 which could
indicate a problem.

Thanks for your comments,


More information about the grass-dev mailing list