Folks,
I updated the proj library in the GRASS cvs to proj4.4.5.
There is a potential problem. The Gmakefile in the CVS was recently updated
and the updated file did not compile the library.; it compiled the
(alphabetically) first *.c file in the directory and stopped. The file that
I committed is the Gmakefile that I downloaded a couple days ago and modified
to compile the added functions.
Roger Miller
Roger Miller wrote:
I updated the proj library in the GRASS cvs to proj4.4.5.
There is a potential problem. The Gmakefile in the CVS was recently updated
and the updated file did not compile the library.; it compiled the
(alphabetically) first *.c file in the directory and stopped. The file that
I committed is the Gmakefile that I downloaded a couple days ago and modified
to compile the added functions.
I suspect that you were trying to use the new Gmakefile with the old
versions of src/CMD/head/head.in and src/CMD/generic/make.mid.
The new Gmakefile *does* work with the new versions of those files;
the version which you committed wouldn't have ("$(AR)" is now the name
of the "ar" program, not the complete rule for building a library).
I've fixed the Gmakefile (i.e. re-applied the changes between versions
1.1 and 1.4), so it should work.
However, as a general rule, don't overwrite updated versions of files
with versions which were generated from an older version. "cvs commit"
should complain if you try to commit a file which is based upon an
older version than the one currently in the repository.
Instead, run "cvs update"; this will attempt to merge the changes into
the working version, and will tell you if a conflict arises.
--
Glynn Clements <glynn.clements@virgin.net>
Roger Miller wrote:
I updated the proj library in the GRASS cvs to proj4.4.5.
There is a potential problem. The Gmakefile in the CVS was recently updated
and the updated file did not compile the library.; it compiled the
(alphabetically) first *.c file in the directory and stopped. The file that
I committed is the Gmakefile that I downloaded a couple days ago and modified
to compile the added functions.
There's a more serious problem; src/include/projects.h hasn't been
updated, but the new code won't compile with the existing projects.h
file. The projects.h file from PROJ 4.4.5 can't be used as is, because
there are some GRASS-specific functions which need to be added.
Also, the "UV" structure has been renamed to "projUV", which impacts
upon programs which use the library (primarily v.proj; the other
occurrences are in src.contrib/SCS, in code which appears to be unused
at present).
--
Glynn Clements <glynn.clements@virgin.net>
Roger,
On Sat, Apr 20, 2002 at 11:39:36AM -0600, Roger Miller wrote:
Folks,
I updated the proj library in the GRASS cvs to proj4.4.5.
please also apply your change(s) to
- m.proj
- m.proj2
if needed to have the projection tools consistent.
There is a potential problem. The Gmakefile in the CVS was recently updated
and the updated file did not compile the library.; it compiled the
(alphabetically) first *.c file in the directory and stopped. The file that
I committed is the Gmakefile that I downloaded a couple days ago and modified
to compile the added functions.
Is that related to PJ_krovak.c which was recently added to PROJ4 (and
needed for the Czech users)? I am currently working on added Krovak
to GRASS, tried that for the old GRASS/PROJ and will retry for the
updated 4.4.5.
Markus
Roger Miller wrote:
> There's a more serious problem; src/include/projects.h hasn't been
> updated, but the new code won't compile with the existing projects.h
> file. The projects.h file from PROJ 4.4.5 can't be used as is, because
> there are some GRASS-specific functions which need to be added.I just committed "projects.h" for 4.4.5 w/GRASS-specific additions. I forgot
to do that earlier.
The new "projects.h" file includes "proj_api.h", which doesn't exist.
--
Glynn Clements <glynn.clements@virgin.net>
On Saturday 20 April 2002 23:38, Markus Neteler wrote:
Is that related to PJ_krovak.c which was recently added to PROJ4 (and
needed for the Czech users)? I am currently working on added Krovak
to GRASS, tried that for the old GRASS/PROJ and will retry for the
updated 4.4.5.
I have no problems with PJ_krovak.c. That file was not in the material I
have been using.
Roger Miller
On Sunday 21 April 2002 04:24, Glynn Clements wrote:
The new "projects.h" file includes "proj_api.h", which doesn't exist.
I added and committed proj_api.h. I don't think the library or the GRASS
additions use the api at all. It is a relatively recent addition to the lib.
Perhaps it's good to include it for future use.
Anything else?
Roger Miller
On Sun, Apr 21, 2002 at 06:09:01AM -0600, Roger Miller wrote:
On Saturday 20 April 2002 23:38, Markus Neteler wrote:
> Is that related to PJ_krovak.c which was recently added to PROJ4 (and
> needed for the Czech users)? I am currently working on added Krovak
> to GRASS, tried that for the old GRASS/PROJ and will retry for the
> updated 4.4.5.I have no problems with PJ_krovak.c. That file was not in the material I
have been using.
Ah, I see. I was refering to the latest CVS version.
After your recent submission the proj lib compiles well.
Markus
Roger Miller wrote:
> The new "projects.h" file includes "proj_api.h", which doesn't exist.
I added and committed proj_api.h. I don't think the library or the GRASS
additions use the api at all. It is a relatively recent addition to the lib.
Perhaps it's good to include it for future use.Anything else?
It's probably worth updating the version information in
src/libes/proj/README.
The datum tables (and their compiler) also need to be added at some
point.
--
Glynn Clements <glynn.clements@virgin.net>
On Sunday 21 April 2002 13:31, Glynn Clements wrote:
It's probably worth updating the version information in
src/libes/proj/README.
done
The datum tables (and their compiler) also need to be added at some
point.
Where? the program nad2bin depends on projects.h, but is otherwise a
standalone program. It needs to be run at installation time but then is no
longer needed. The ascii tables should be shipped with the distribution.
nad2bin should be used during installation to convert them to binary and
store them in $GISBASE/etc/nad, after that the ascii form is no longer needed.
So, where do the nad2bin.c code and the ascii data tables need to be placed
in the CVS tree?
Roger Miller
On Sat, Apr 20, 2002 at 11:39:36AM -0600, Roger Miller wrote:
I updated the proj library in the GRASS cvs to proj4.4.5.
In the long run we have to separate that library out of
the GRASS source tree.
Roger Miller wrote:
> The datum tables (and their compiler) also need to be added at some
> point.Where? the program nad2bin depends on projects.h, but is otherwise a
standalone program. It needs to be run at installation time but then is no
longer needed. The ascii tables should be shipped with the distribution.
nad2bin should be used during installation to convert them to binary and
store them in $GISBASE/etc/nad, after that the ascii form is no longer needed.So, where do the nad2bin.c code and the ascii data tables need to be placed
in the CVS tree?
If they're shipped with, and used by, the PROJ library, then
src/libes/proj would be the logical place.
--
Glynn Clements <glynn.clements@virgin.net>
On Sunday 21 April 2002 15:12, Glynn Clements wrote:
If they're shipped with, and used by, the PROJ library, then
src/libes/proj would be the logical place.
As you wish. It's done; src/libes/proj now contains 12 data files titled
*.lla, one titled ntv1_can.dat and the pogram file nad2bin.c.
When run, nad2bin takes two arguments. First is the input file name and
second is the output file name. I have assumed that the output filles will
all use the name of the corresponding input file without the last four
characters. The commands to build the binary data would be something like:
nad2bin <name>.lla $GISBASE/etc/nad/<name>
and
nad2bin ntv1_can.dat $GISBASE/etc/nad/ntv1_can
(assuming that nad2bin is run with src/libes/proj as the current directory)
I think that puts all of the necessary code and data in place.
Roger Miller
Roger Miller wrote:
nad2bin ntv1_can.dat $GISBASE/etc/nad/ntv1_can
(assuming that nad2bin is run with src/libes/proj as the current directory)
Roger,
Unlike the US files, I am pretty sure that ntv1_can.dat does not need to
be run through nad2bin.
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
On Sunday 21 April 2002 19:12, Frank Warmerdam wrote:
Unlike the US files, I am pretty sure that ntv1_can.dat does not need to
be run through nad2bin.
Frank,
I hadn't checked previously. I see the file is already a binary. Is there
no problem using the same binary across multiple platforms, or will the data
work correctly on only specific platforms?
Roger Miller
Roger Miller wrote:
> Unlike the US files, I am pretty sure that ntv1_can.dat does not need to
> be run through nad2bin.I hadn't checked previously. I see the file is already a binary. Is there
no problem using the same binary across multiple platforms, or will the data
work correctly on only specific platforms?
The output from nad2bin is platform-specific. It's basically the
CTABLE struct followed by an array of FLP structs, written in the
platform's native format.
AFAICT, ntv1_can.dat isn't in the same format as the output from
nad2bin. It's listed separately in nad/README (from proj-4.4.5):
Other grid shift files
ntv1_can.dat --- Canadian NTv1 grid shift file (NAD27-->NAD83)
--
Glynn Clements <glynn.clements@virgin.net>