[GRASS5] datum shifts

Folks,

I have upgraded the proj library in my installation to version 4.5.5--it
may actually have been at that level to start with, I don't know. I
added some code to the library and modified r.proj, v.proj and s.proj to
perform the nad27<->nad83 datum change in a pretty seamless manner. For
our North American users, I'd like to get this capability into
GRASS5.0.0 before the feature freeze.

For now the datum shift is limited to the changes between the two nad
data. I hope the mechanism is sufficiently general that other datum
shifts can be added with relatively little change.

I need some help to get the changes installed in GRASS before the
feature freeze. My biggest problems are:

The nad27<->nad83 conversions are based on data tables. The data tables
are shipped in ascii form. They have to be interpreted to binary by a
program that ships with the package and then placed somewhere in the
$GRASSBASE hierarchy. Currently I have them in $GRASSBASE/etc/nad. It
would make more sense to me to put them in $GRASSBASE/lib/nad. Your
input would be appreciated.

The user modules must know where the data tables are stored, and that
information should be compiled into the modules. I think that would be
done by configure, but I don't know enough to say, much less enough to
make the change myself.

I don't know how to go about doing either of those tasks. Help?

I will also have to commit and/or add the library code. I think I can
figure that out.

There are some outstanding tasks.

I probably need to get the proj library list of projections in sync with
the GRASS 5 list.

At this point the modules are hardwired to perform the nad conversion
only in the conterminous US and adjacent areas and only at regular
precision. That needs to be changed. I would need either to install
the ability for the modules to determine which table they should use for
the input area or I need to make that an argument. Using the high
precision tables (maybe not necessary) would require another argument.
Added arguments make the datum change less seamless, so users outside NA
might find that annoying.

I have not upgraded m.proj to complete the datum change. I don't regard
that as a high priority.

Your input and help would be much appreciated.

Roger Miller

On Fri, Apr 19, 2002 at 12:19:33PM -0700, rgrmill@rt66.com wrote:

I have upgraded the proj library in my installation to version 4.5.5--it
may actually have been at that level to start with, I don't know. I
added some code to the library and modified r.proj, v.proj and s.proj to
perform the nad27<->nad83 datum change in a pretty seamless manner. For
our North American users, I'd like to get this capability into
GRASS5.0.0 before the feature freeze.

It is hard for me to judge if this might be a cause for more bugs
or can be savely done.
We have the possibility to schedule this addition for 5.0.1
depending on the answer.

The nad27<->nad83 conversions are based on data tables. The data tables
are shipped in ascii form. They have to be interpreted to binary by a
program that ships with the package and then placed somewhere in the
$GRASSBASE hierarchy.

What does " They have to be interpreted to binary by a program" mean?

The user modules must know where the data tables are stored, and that
information should be compiled into the modules. I think that would be
done by configure, but I don't know enough to say, much less enough to
make the change myself.

Is there a possibility to make this relative to
an environment variable the GRASS installation is using anyway?
We should not have fixed paths compiled in that prohibit that
the GRASS installation can be moved. So I guess relative to other
GRASS files should be fine. Maybe you don't even need configure for this.

rgrmill@rt66.com wrote:

The nad27<->nad83 conversions are based on data tables. The data tables
are shipped in ascii form. They have to be interpreted to binary by a
program that ships with the package and then placed somewhere in the
$GRASSBASE hierarchy. Currently I have them in $GRASSBASE/etc/nad. It
would make more sense to me to put them in $GRASSBASE/lib/nad. Your
input would be appreciated.

$GISBASE/etc is probably more correct. Presently, $GISBASE/lib only
contains libraries; all data tables are under $GISBASE/etc.

The user modules must know where the data tables are stored, and that
information should be compiled into the modules. I think that would be
done by configure, but I don't know enough to say, much less enough to
make the change myself.

With one exception[1], everything uses $GISBASE to determine
pathnames. That should be the case for the data tables, if at all
possible.

[1] The locale message catalogues don't, but I'll fix that now that
I've been reminded of it.

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