[GRASS5] Projection transform

GRASS GRASS developer
1

Hi ,

I am working on projection Latitude and Longitude , I
want to transform these Latitude&Longitude to Albers
Equal Area Conic projection, could anybody give me
some hint on how to do it? (I can not find the m.geo
in the grass I installed), if you can give me some
c/c++ code working on that, it will be very helpful to
me.

Thanks in advance,
shifeng zhang

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

2

On Tuesday 22 January 2002 20:02, zhang ji wrote:

I am working on projection Latitude and Longitude , I
want to transform these Latitude&Longitude to Albers
Equal Area Conic projection, could anybody give me
some hint on how to do it? (I can not find the m.geo
in the grass I installed), if you can give me some
c/c++ code working on that, it will be very helpful to
me.

Use r.proj, v.proj or s.proj depending on whether your data are in raster
files, vector files or sites files. There is also an m.proj function for
miscellaneous data.

To use these programs you need two database "locations". The first location
uses a latitude longitude projection. Your original data are stored in that
location. The second location uses an albers projection defined to suit your
needs. Start GRASS and make the albers location your current location, then
use r.proj, v.proj or s.proj to copy data from the latitude-longitude
database location to your albers locations. The projection is performed in
the process of copying the data.

Roger Miller
Lee Wilson and Associates.

3

On Tue, Jan 22, 2002 at 09:27:23PM -0700, Roger Miller wrote:

On Tuesday 22 January 2002 20:02, zhang ji wrote:

> I am working on projection Latitude and Longitude , I
> want to transform these Latitude&Longitude to Albers
> Equal Area Conic projection, could anybody give me
> some hint on how to do it? (I can not find the m.geo
> in the grass I installed), if you can give me some
> c/c++ code working on that, it will be very helpful to
> me.

Use r.proj, v.proj or s.proj depending on whether your data are in raster
files, vector files or sites files. There is also an m.proj function for
miscellaneous data.

...just an addition: There is also m.proj2 which is the command line
version of m.proj. See
http://grass.itc.it/gdp/html_grass5/html/m.proj2.html

how to use it for ASCII coordinates lists.

Markus

4

Markus Neteler wrote:

...just an addition: There is also m.proj2 which is the command line
version of m.proj.

Is there any significant reason why these aren't cmd/inter versions of
a single program?

Certainly, they have a lot of common code (geo_func.c and get_deg.c
are identical, process.c differs only in whitespace, get_stp.c differs
only due to debugging statements).

--
Glynn Clements <glynn.clements@virgin.net>

5

On Wed, Jan 23, 2002 at 09:44:20AM +0000, Glynn Clements wrote:

Markus Neteler wrote:

> ...just an addition: There is also m.proj2 which is the command line
> version of m.proj.

Is there any significant reason why these aren't cmd/inter versions of
a single program?

Certainly, they have a lot of common code (geo_func.c and get_deg.c
are identical, process.c differs only in whitespace, get_stp.c differs
only due to debugging statements).

I assume that the m.proj2 is intended to replace the m.proj
(hi Bob). A cleanup is needed, such clones are not desired.

Markus

6

Markus Neteler wrote:

On Wed, Jan 23, 2002 at 09:44:20AM +0000, Glynn Clements wrote:
>
> Markus Neteler wrote:
>
> > ...just an addition: There is also m.proj2 which is the command line
> > version of m.proj.
>
> Is there any significant reason why these aren't cmd/inter versions of
> a single program?
>
> Certainly, they have a lot of common code (geo_func.c and get_deg.c
> are identical, process.c differs only in whitespace, get_stp.c differs
> only due to debugging statements).

I assume that the m.proj2 is intended to replace the m.proj
(hi Bob). A cleanup is needed, such clones are not desired.

Markus
_______________________________________________

Markus & Glynn;

Yes, m.proj2 was intended to replace m.proj. However, it does still need
lots of debugging and code cleaning. An inter version of it (seperate
directory) should not be necessary as the current version (m.proj2)
should work both ways. In other words with no options it will walk you
through the arguments.

Also, I should mention that m.ll2db is another coordinate conversion
program I added. It is based on m.ll2u, but instead gets proj info from
the current GRASS projection. It can replace m.ll2u, m.u2ll, and
possibly others. Essentially it will convert GRASS database units to and
from Lat. Long.. The idea was that where m.ll2db could not work (eg. XY,
or Lat. Long. proj) the user could use m.proj2. The code for this
program should (hopefully) be alot cleaner than m.proj2.

Hope this helps.

--
Bob Covill

Tekmap Consulting
P.O. Box 2016 Fall River, N.S.
B2T 1K6
Canada

E-Mail: bcovill@tekmap.ns.ca
Phone: 902-860-1496
Fax: 902-860-1498

7

On Wed, 23 Jan 2002, Markus Neteler wrote:

On Wed, Jan 23, 2002 at 09:44:20AM +0000, Glynn Clements wrote:
>
> Markus Neteler wrote:
>
> > ...just an addition: There is also m.proj2 which is the command line
> > version of m.proj.
>
> Is there any significant reason why these aren't cmd/inter versions of
> a single program?
>
> Certainly, they have a lot of common code (geo_func.c and get_deg.c
> are identical, process.c differs only in whitespace, get_stp.c differs
> only due to debugging statements).

I assume that the m.proj2 is intended to replace the m.proj
(hi Bob). A cleanup is needed, such clones are not desired.

Markus
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

I hope anyone who tackles m.proj[2] will consider that there also is
common code with g.setproj.

A few years ago when I added support for more projections in g.setproj, I
also made corresponding changes in m.proj and merged the init routines
into the gis library. Now these program have started to drift apart again
- basic datum shift support has partially been added to g.setproj but not
to m.proj.

I believe , based on the similarity of the code and some old module
no longer present in the current distro, that in the ancient past (long
before I started to use grass) g.setproj and m.proj was the same program.

Morten Hulden

8

Morten Hulden wrote:

I hope anyone who tackles m.proj[2] will consider that there also is
common code with g.setproj.

A few years ago when I added support for more projections in g.setproj, I
also made corresponding changes in m.proj and merged the init routines
into the gis library. Now these program have started to drift apart again
- basic datum shift support has partially been added to g.setproj but not
to m.proj.

I believe , based on the similarity of the code and some old module
no longer present in the current distro, that in the ancient past (long
before I started to use grass) g.setproj and m.proj was the same program.

Now g.setproj and m.proj don't even perform similar tasks. g.setproj
lets the user set the projection information associated with a database
location and m.proj converts coordinates between different projections.
I guess I don't see much reason why these tasks should be merged.

Roger Miller
Lee Wilson and Associates

Morten Hulden

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

9

On Wed, 23 Jan 2002, Lee Wilson and Associates wrote:

Morten Hulden wrote:

> I hope anyone who tackles m.proj[2] will consider that there also is
> common code with g.setproj.
>
> A few years ago when I added support for more projections in g.setproj, I
> also made corresponding changes in m.proj and merged the init routines
> into the gis library. Now these program have started to drift apart again
> - basic datum shift support has partially been added to g.setproj but not
> to m.proj.
>
> I believe , based on the similarity of the code and some old module
> no longer present in the current distro, that in the ancient past (long
> before I started to use grass) g.setproj and m.proj was the same program.

Now g.setproj and m.proj don't even perform similar tasks. g.setproj
lets the user set the projection information associated with a database
location and m.proj converts coordinates between different projections.
I guess I don't see much reason why these tasks should be merged.

Please don't misunderstand. I don't mean they should be merged. They
_were_ merged, but there were obvious reasons to split them. Nevertheless,
there is a lot of common code. Both use geo.h and geo_init.c, and main.c
(in g.setproj) is very similar to process.c (in m.proj).

What I mean is they should be maintained in sync and common code should be
put in a library. If g.setproj asks questions on datum settings, same
questions should be asked in m.proj.

They perform different tasks, yes, but both programs generate proj-options
based on user input and default settings for the projection in question.
They differ in that g.setproj uses the settings to generate a PROJ_INFO
file, while m.proj uses them directly to do a projection of a single
point.

Morten Hulden

10

Morten Hulden wrote:

On Wed, 23 Jan 2002, Lee Wilson and Associates wrote:

...

> Now g.setproj and m.proj don't even perform similar tasks. g.setproj
> lets the user set the projection information associated with a database
> location and m.proj converts coordinates between different projections.
> I guess I don't see much reason why these tasks should be merged.

Please don't misunderstand. I don't mean they should be merged. They
_were_ merged, but there were obvious reasons to split them. Nevertheless,
there is a lot of common code. Both use geo.h and geo_init.c, and main.c
(in g.setproj) is very similar to process.c (in m.proj).

What I mean is they should be maintained in sync and common code should be
put in a library. If g.setproj asks questions on datum settings, same
questions should be asked in m.proj.

They perform different tasks, yes, but both programs generate proj-options
based on user input and default settings for the projection in question.
They differ in that g.setproj uses the settings to generate a PROJ_INFO
file, while m.proj uses them directly to do a projection of a single
point.

Hi all,

i have to underline what Morten said.
The problem is that much of the projection setup is now hardcoded into
g.setproj.
For example, it is hardcoded into g.setproj that some projections have
fixed ellipsoids:
if ((proj_index == ALSK) || (proj_index == GS48) || (proj_index ==
GS50)) {
  sprintf(spheroid, "%s", "clark66");
...
}

This has to be hardcoded for obvious reasons into m.proj, too.

This is very bad design. We need to implement a new database, which
contains projections, names, ellipsoids/spheroids, datum shift
parameters and all the dependencies. (it comes to my mind that this is
also a candidate for new library, as the key/value processing for the
etc tables is cloned several times in the gis libray code).
Then we need to implement a set of library functions that manage/setup
all this and call the proj library for the actual processing.

I am open to any ideas,

Andreas

--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
url: http://mitglied.tripod.de/AndreasLange
mail: Andreas.Lange_at_Rhein-Main.de - A.C.Lange_at_GMX.net

11

Andreas Lange wrote:

Hi all,

i have to underline what Morten said. The problem is that much of the projection setup is now hardcoded into
g.setproj.
For example, it is hardcoded into g.setproj that some projections have
fixed ellipsoids:
if ((proj_index == ALSK) || (proj_index == GS48) || (proj_index ==
GS50)) {
  sprintf(spheroid, "%s", "clark66");
...
}

This has to be hardcoded for obvious reasons into m.proj, too.

This is very bad design. We need to implement a new database, which
contains projections, names, ellipsoids/spheroids, datum shift
parameters and all the dependencies. (it comes to my mind that this is
also a candidate for new library, as the key/value processing for the
etc tables is cloned several times in the gis libray code). Then we need to implement a set of library functions that manage/setup
all this and call the proj library for the actual processing.

Folks,

I agree with the above. I would only add that I would like to see as much as
possible of this done in an integrated fashion with PROJ.4. Obviously some
of the interactive functions to ask for projection parameters will be grass
specific, but I would like to see any required tables of datums, ellipsoids
and so forth handled from within PROJ.4. I am happy to extend PRO.4 to make
more of it's internal lists accessable to applications, and to extend them.

One of the problems I have now writing translators between GRASS and other
systems is some of the ideosyncratic projection issues in GRASS.

Best regards,

--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

12

Hi Andreas, (Cc to Grass5)

From a computer engineering perspective, the migration of functionality
in a program can be handled by allowing the old code to co-exist
during development and testing of a library based replacement. This
is the best alternative for users dependent upon the original
function.

Create a new name that best fits this projection procedure, migrate
the original code into a database/library, leave the original code
intact. Once testing is completed, phase out the old code, and
perhaps create an alias name from the original name to the new name.

John Huddleston

-----Original Message-----
From: grass5-admin@grass.itc.it [mailto:grass5-admin@grass.itc.it]On
Behalf Of Andreas Lange
Sent: Thursday, January 24, 2002 9:09 AM
To: Morten Hulden
Cc: Lee Wilson and Associates; grass5@grass.itc.it
Subject: Re: [GRASS5] Projection transform

Morten Hulden wrote:

On Wed, 23 Jan 2002, Lee Wilson and Associates wrote:

...

> Now g.setproj and m.proj don't even perform similar tasks. g.setproj
> lets the user set the projection information associated with a database
> location and m.proj converts coordinates between different projections.
> I guess I don't see much reason why these tasks should be merged.

Please don't misunderstand. I don't mean they should be merged. They
_were_ merged, but there were obvious reasons to split them. Nevertheless,
there is a lot of common code. Both use geo.h and geo_init.c, and main.c
(in g.setproj) is very similar to process.c (in m.proj).

What I mean is they should be maintained in sync and common code should be
put in a library. If g.setproj asks questions on datum settings, same
questions should be asked in m.proj.

They perform different tasks, yes, but both programs generate proj-options
based on user input and default settings for the projection in question.
They differ in that g.setproj uses the settings to generate a PROJ_INFO
file, while m.proj uses them directly to do a projection of a single
point.

Hi all,

i have to underline what Morten said.
The problem is that much of the projection setup is now hardcoded into
g.setproj.
For example, it is hardcoded into g.setproj that some projections have
fixed ellipsoids:
if ((proj_index == ALSK) || (proj_index == GS48) || (proj_index ==
GS50)) {
  sprintf(spheroid, "%s", "clark66");
...
}

This has to be hardcoded for obvious reasons into m.proj, too.

This is very bad design. We need to implement a new database, which
contains projections, names, ellipsoids/spheroids, datum shift
parameters and all the dependencies. (it comes to my mind that this is
also a candidate for new library, as the key/value processing for the
etc tables is cloned several times in the gis libray code).
Then we need to implement a set of library functions that manage/setup
all this and call the proj library for the actual processing.

I am open to any ideas,

Andreas

--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
url: http://mitglied.tripod.de/AndreasLange
mail: Andreas.Lange_at_Rhein-Main.de - A.C.Lange_at_GMX.net
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

13

On Thu, 24 Jan 2002 17:09:10 +0100, Andreas Lange <Andreas.Lange@Rhein-Main.de> wrote:

[snip]

i have to underline what Morten said.
The problem is that much of the projection setup is now hardcoded into
g.setproj.
For example, it is hardcoded into g.setproj that some projections have
fixed ellipsoids:
if ((proj_index == ALSK) || (proj_index == GS48) || (proj_index ==
GS50)) {
  sprintf(spheroid, "%s", "clark66");
...
}

This has to be hardcoded for obvious reasons into m.proj, too.

This is very bad design. We need to implement a new database, which
contains projections, names, ellipsoids/spheroids, datum shift
parameters and all the dependencies. (it comes to my mind that this is
also a candidate for new library, as the key/value processing for the
etc tables is cloned several times in the gis libray code).
Then we need to implement a set of library functions that manage/setup
all this and call the proj library for the actual processing.

I am open to any ideas,

I think we could start off by differentiating between projections and
coordinate systems. A projection is only a mathematical function. A
coordinate systems has the additional constraints of projection
parameters, map units, datum or ellipsoid, etc...

UTM, GS50, ALSK, State Plane, etc. are coordinate systems (or families
of coordinate systems). For instance, UTM 10N - WGS 84, is sufficient
to define a coordinate system, Lambert Conformal Conic is not.

We have three types of coordinate systems to think about:

  1. Unreferenced (X-Y), unitless
  2. A Geographic or Geodetic Coordinate system
  3. A Projected Coordinate system

I don't see why we shouldn't use the same nomenclature being used by
ESRI, PostGIS (PostgreSQL extension), and others. Believe it's
an OpenGIS spec now (unsure). But it captures the salient information.
Obviously, we need lookup tables to cross walk to PROJ 4 nomenclature,
but I suspect Frank already has most of that done.

Example matching my neck of the woods, ripped from PostGIS SQL.

--
-- NAD_1927_StatePlane_California_IV_FIPS_0404
--
INSERT INTO SPATIAL_REF_SYS (SRID, AUTH_NAME, AUTH_SRID, SRTEXT) VALUES
(26744,'ESRI',26744,'PROJCS["NAD_1927_StatePlane_California_IV_FIPS_0404",
GEOGCS["GCS_North_American_1927",DATUM["D_North_American_1927",
SPHEROID["Clarke_1866",6378206.4,294.9786982]],PRIMEM["Greenwich",0],
UNIT["Degree",0.017453292519943295]],PROJECTION["Lambert_Conformal_Conic"],
PARAMETER["False_Easting",2000000],PARAMETER["False_Northing",0],
PARAMETER["Central_Meridian",-119],PARAMETER["Standard_Parallel_1",36],
PARAMETER["Standard_Parallel_2",37.25],
PARAMETER["Latitude_Of_Origin",35.33333333333334],
UNIT["Foot_US",0.30480060960121924]]');

User's can of course, define their own systems.

--
Eric G. Miller <egm2@jps.net>