Shouldn't this be done at GRASS compile time, so to have the
right binary tables for the platform?
Or will the format change with proj library versions
that have the same binary interface?
Yes, it does need to be done when GRASS is compiled.
> I think the data tables
> have to go under $GISBASE somewhere.
That is not hardcoded, though...
It providing an option to specify a non-default path a good idea?
That part that has to be hard coded is the part after $GISBASE, probably
"/etc/nad/". No more than I know now, it looks easier for me to code
this if there is no user option.
> Wherever they do go has to be
> coded into the proj library.
This confuses me a bit, is it an addition to proj then?
I guess I could be more specific. A program that uses the nad<->nad
conversion in the proj library has to call a function called "nad_init".
"nad_init" takes one argument, and that is the fully qualified file name
for the data table that it will use for the conversions. "nad_init" is
part of the proj distribution. It looks now like the name should be
'getenv("GISBASE")/etc/nad/<table name>'. GISBASE is set during GRASS
installation and hopefully is available during execution. "/etc/nad/"
will probably be hard coded; I suppose there are options. <table name>
is currently hardcoded to name the table that covers most of the US and
the more populated areas of Canada, but it actually needs to be set at
run time to any of 8 (13 including high precision data) different
tables.
Roger
On Fri, Apr 19, 2002 at 02:15:05PM -0700, rgrmill@rt66.com wrote:
> Shouldn't this be done at GRASS compile time, so to have the
> right binary tables for the platform?
> Or will the format change with proj library versions
> that have the same binary interface?
Yes, it does need to be done when GRASS is compiled.
We need a Makefile entry for this.
Maybe Glynn can help if you give him the commands?
> > I think the data tables
> > have to go under $GISBASE somewhere.
>
> That is not hardcoded, though...
> It providing an option to specify a non-default path a good idea?
That part that has to be hard coded is the part after $GISBASE, probably
"/etc/nad/". No more than I know now, it looks easier for me to code
this if there is no user option.
Usually I do not call a fixed relative path hardcoded... 
> > Wherever they do go has to be
> > coded into the proj library.
>
> This confuses me a bit, is it an addition to proj then?
I guess I could be more specific. A program that uses the nad<->nad
conversion in the proj library has to call a function called "nad_init".
"nad_init" takes one argument, and that is the fully qualified file name
for the data table that it will use for the conversions. "nad_init" is
part of the proj distribution.
Okay, thus you have to specify it when initialising proj.
No need to "code" it into library itself.
It looks now like the name should be
'getenv("GISBASE")/etc/nad/<table name>'.
Sounds reasonable to me.
Bernhard Reiter wrote:
> > Shouldn't this be done at GRASS compile time, so to have the
> > right binary tables for the platform?
> > Or will the format change with proj library versions
> > that have the same binary interface?
>
> Yes, it does need to be done when GRASS is compiled.
We need a Makefile entry for this.
Maybe Glynn can help if you give him the commands?
Sure.
> > > Wherever they do go has to be
> > > coded into the proj library.
> >
> > This confuses me a bit, is it an addition to proj then?
>
> I guess I could be more specific. A program that uses the nad<->nad
> conversion in the proj library has to call a function called "nad_init".
> "nad_init" takes one argument, and that is the fully qualified file name
> for the data table that it will use for the conversions. "nad_init" is
> part of the proj distribution.
Okay, thus you have to specify it when initialising proj.
No need to "code" it into library itself.
> It looks now like the name should be
> 'getenv("GISBASE")/etc/nad/<table name>'.
Sounds reasonable to me.
FWIW, the "official" mechanism is G_gisbase(), e.g.
sprintf(pathname, "%s/etc/nad/%s", G_gisbase(), table_name);
--
Glynn Clements <glynn.clements@virgin.net>
Roger,
sorry to put another burden on you: to complete the proj update,
please also add notes in the related HTML pages ([mrsv].proj.html).
Thanks,
Markus