[GRASS5] compiling code

GRASS GRASS developer
1

I am trying to compile a piece of code outside grass. It comes
from code with the following includes:

(from v.in.tig.basic)
#include <string.h>
#include <unistd.h>
#include <stdlib.h>
#include "gis.h"
#include "CC.h"
#include "dig_atts.h"
#include "Vect.h"

When I try to compile outside of grass, fseek, fopen
printf, etc need stdio.h.

gcc -g -Wall -D__USE_FIXED_PROTOTYPES__ -ansi test.c

How is that being included in Grass code?

Also, the coordinate conversion library "CC.h", has
this usage changed now that we are going to use the standard
proj4 library? Do you call proj4 routines directly?

John

2

On Tue, 6 May 2003, John Gillette wrote:

When I try to compile outside of grass, fseek, fopen
printf, etc need stdio.h.

gcc -g -Wall -D__USE_FIXED_PROTOTYPES__ -ansi test.c

How is that being included in Grass code?

stdio.h is included in gis.h. But in my experience lots of GRASS programs
are missing header files. It is usually more recent additions however, not the
older ones.

Also, the coordinate conversion library "CC.h", has
this usage changed now that we are going to use the standard
proj4 library? Do you call proj4 routines directly?

In my opinion any module that uses the CC_ functions is seriously
out-of-date and a candidate for updating, possibly in other ways as well.
You may look at d.where in the CVS for an example of upgrading a module
from coorcnv to proj usage, which I did recently. The programmers'
manual is currently a little out-of-date on proj usage. It is suspicious
also that an import module should use coorcnv as it should really import
the data into a location that matches the projection of the original data
and then v.proj can be used to re-project it if needed.

If we have a list of which modules that currently use coorcnv are going to be
kept in GRASS 5.1 (i.e. it is worthwhile updating them) I could maybe work
at changing them over to using proj instead, although it may take a while
to get round to them all.

Paul

3

John Gillette wrote:

I am trying to compile a piece of code outside grass. It comes
from code with the following includes:

(from v.in.tig.basic)
#include <string.h>
#include <unistd.h>
#include <stdlib.h>
#include "gis.h"
#include "CC.h"
#include "dig_atts.h"
#include "Vect.h"

When I try to compile outside of grass, fseek, fopen
printf, etc need stdio.h.

gis.h includes stdio.h, as many of the prototypes refer to "FILE *".

gcc -g -Wall -D__USE_FIXED_PROTOTYPES__ -ansi test.c

How is that being included in Grass code?

Could you rephrase that?

Also, the coordinate conversion library "CC.h", has
this usage changed now that we are going to use the standard
proj4 library? Do you call proj4 routines directly?

I'll let Paul Kelly answer that one; he probably has a better idea as
to how the projection stuff is meant to be used now.

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

4

On Tue, May 06, 2003 at 07:28:19PM +0100, Paul Kelly wrote:

On Tue, 6 May 2003, John Gillette wrote:

> When I try to compile outside of grass, fseek, fopen
> printf, etc need stdio.h.
>
> gcc -g -Wall -D__USE_FIXED_PROTOTYPES__ -ansi test.c
>
> How is that being included in Grass code?

stdio.h is included in gis.h. But in my experience lots of GRASS programs
are missing header files. It is usually more recent additions however, not the
older ones.

... this is an invitation to compile GRASS with -Wall. All
developers may eliminate compiler warnings whenever possible
(delete unused variables, add missing headers etc).

Thanks,

Markus

5

On Tue, May 06, 2003 at 07:28:19PM +0100, Paul Kelly wrote:

On Tue, 6 May 2003, John Gillette wrote:

[...]

> Also, the coordinate conversion library "CC.h", has
> this usage changed now that we are going to use the standard
> proj4 library? Do you call proj4 routines directly?

In my opinion any module that uses the CC_ functions is seriously
out-of-date and a candidate for updating, possibly in other ways as well.
You may look at d.where in the CVS for an example of upgrading a module
from coorcnv to proj usage, which I did recently. The programmers'
manual is currently a little out-of-date on proj usage. It is suspicious
also that an import module should use coorcnv as it should really import
the data into a location that matches the projection of the original data
and then v.proj can be used to re-project it if needed.

If we have a list of which modules that currently use coorcnv are going to be
kept in GRASS 5.1 (i.e. it is worthwhile updating them) I could maybe work
at changing them over to using proj instead, although it may take a while
to get round to them all.

At time GRASS 5.1 is free of CC_ routines.

I GRASS 5.0 I found:
./src/mapdev/v.apply.census/
./src/mapdev/v.in.tig.basic/
./src/mapdev/v.in.tig.lndmk/
./src/mapdev/v.mkgrid/
./src/mapdev/v.mkquads/
./src/imagery/i.tape.tm3/
./src/misc/m.datum.shift/
./src/misc/m.gc2ll/cmd/
./src/misc/m.ll2gc/cmd/
./src/misc/m.ll2u/cmd/
./src/misc/m.region.ll/
./src/misc/m.tiger.region/
./src/misc/m.u2ll/
./src/raster/r.in.dem/
./src/raster/r.in.ll/
./src/sites/s.datum.shift/
./src.contrib/NPS/
./src.contrib/SCS/display/d.fix.ortho/
./src.contrib/SCS/vector/v.mkquads.scs/
./src.contrib/SDTS/mapdev/v.out.sdts/
./src.garden/grass.hdf/hdf5/r.in.hdf/
./src.garden/grass.tig.rim/v.in.tig.rim/

but which of above modules should reach 5.1?

Markus

6

Markus Neteler wrote:

> > When I try to compile outside of grass, fseek, fopen
> > printf, etc need stdio.h.
> >
> > gcc -g -Wall -D__USE_FIXED_PROTOTYPES__ -ansi test.c
> >
> > How is that being included in Grass code?
>
> stdio.h is included in gis.h. But in my experience lots of GRASS programs
> are missing header files. It is usually more recent additions however, not the
> older ones.

... this is an invitation to compile GRASS with -Wall. All
developers may eliminate compiler warnings whenever possible
(delete unused variables, add missing headers etc).

But don't just "make the warnings go away". Unless you are sure that
you are fixing the actual problem, it's better that the warning
remains; it may be the only clue that there's a bug.

In particular, don't add type casts unless you have a *good*
understanding of C, especially portability issues (e.g. alignment,
aliasing, sizes of primitive types).

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

7

On Wed, May 07, 2003 at 11:05:25AM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> > > When I try to compile outside of grass, fseek, fopen
> > > printf, etc need stdio.h.
> > >
> > > gcc -g -Wall -D__USE_FIXED_PROTOTYPES__ -ansi test.c
> > >
> > > How is that being included in Grass code?
> >
> > stdio.h is included in gis.h. But in my experience lots of GRASS programs
> > are missing header files. It is usually more recent additions however, not the
> > older ones.
>
> ... this is an invitation to compile GRASS with -Wall. All
> developers may eliminate compiler warnings whenever possible
> (delete unused variables, add missing headers etc).

But don't just "make the warnings go away". Unless you are sure that
you are fixing the actual problem, it's better that the warning
remains; it may be the only clue that there's a bug.

I was thinking of unused variables and cases where e.g. fprintf()
is used but <string.h> not included, the same for exit() and
so on.

In particular, don't add type casts unless you have a *good*
understanding of C, especially portability issues (e.g. alignment,
aliasing, sizes of primitive types).

I won't do that :slight_smile:

Markus

8

Markus Neteler wrote:

> > ... this is an invitation to compile GRASS with -Wall. All
> > developers may eliminate compiler warnings whenever possible
> > (delete unused variables, add missing headers etc).
>
> But don't just "make the warnings go away". Unless you are sure that
> you are fixing the actual problem, it's better that the warning
> remains; it may be the only clue that there's a bug.

I was thinking of unused variables and cases where e.g. fprintf()
is used but <string.h> not included,

fprintf() is in <stdio.h>, not <string.h>. Ditto for sprintf().

the same for exit() and so on.

OK; including the appropriate header files is definitely the right
thing to do.

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

9

Well here is what I think of all those modules that use the coorcnv
library.

On Wed, 7 May 2003, Markus Neteler wrote:

On Tue, May 06, 2003 at 07:28:19PM +0100, Paul Kelly wrote:
> If we have a list of which modules that currently use coorcnv are going to be
> kept in GRASS 5.1 (i.e. it is worthwhile updating them) I could maybe work
> at changing them over to using proj instead, although it may take a while
> to get round to them all.

At time GRASS 5.1 is free of CC_ routines.

I GRASS 5.0 I found:
./src/mapdev/v.apply.census/
./src/mapdev/v.in.tig.basic/
./src/mapdev/v.in.tig.lndmk/

Are these used regularly and do they work reliably? In GRASS 5.1 is there
a general vector import utility that would handle these formats like GDAL
for raster? Or maybe they should be fixed up. The comments from John
Gillette suggest they leave a lot to be desired.

./src/mapdev/v.mkgrid/
./src/mapdev/v.mkquads/

Seem to perform a worthwhile function (generating vector grids) although I
can't see where they would be used. Maybe should be kept and fixed.

./src/imagery/i.tape.tm3/

Does r.in.gdal do the same thing as this?

./src/misc/m.datum.shift/
./src/misc/m.gc2ll/cmd/
./src/misc/m.ll2gc/cmd/
./src/misc/m.ll2u/cmd/
./src/misc/m.region.ll/
./src/misc/m.tiger.region/
./src/misc/m.u2ll/

None of these operate on files in the GRASS database so I think they
should all be removed. cs2cs from PROJ.4 does the same thing as most of
them; m.tiger.region sounds like something similar to gdalinfo for vector
files; does such a program exist?

./src/raster/r.in.dem/

This program seems not that ancient (date in 1996 given). Is the format it
handles not supported by r.in.gdal? Again I think import programs
shouldn't try to re-project data.

./src/raster/r.in.ll/

This looks like it is very specific to a certain type of data import.
Almost seems to do the same thing as r.proj but I don't really understand
the man page.

./src/sites/s.datum.shift/

Isn't needed now s.proj can do datum shifts

./src.contrib/NPS/r.in.utm/

Sounds like another specialised import/re-projection utility that isn't
needed now.

./src.contrib/SCS/display/d.fix.ortho/

Description:
Shifts raster map to position specified by mouse
Is this useful? Might be and only uses coorcnv for reporting co-ordinates
in lat/long to user so would be easy to fix.

./src.contrib/SCS/vector/v.mkquads.scs/

Maybe just an older version of v.mkquads?

./src.contrib/SDTS/mapdev/v.out.sdts/
./src.garden/grass.hdf/hdf5/r.in.hdf/
./src.garden/grass.tig.rim/v.in.tig.rim/

More specialised import/export utilities probably; are any of them really
needed or have they been replaced by something better.

but which of above modules should reach 5.1?

Markus

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

10

On Wed, May 07, 2003 at 03:35:42PM +0100, Paul Kelly wrote:

Well here is what I think of all those modules that use the coorcnv
library.

On Wed, 7 May 2003, Markus Neteler wrote:

> On Tue, May 06, 2003 at 07:28:19PM +0100, Paul Kelly wrote:
> > If we have a list of which modules that currently use coorcnv are going to be
> > kept in GRASS 5.1 (i.e. it is worthwhile updating them) I could maybe work
> > at changing them over to using proj instead, although it may take a while
> > to get round to them all.
>
> At time GRASS 5.1 is free of CC_ routines.
>
> I GRASS 5.0 I found:
> ./src/mapdev/v.apply.census/
> ./src/mapdev/v.in.tig.basic/
> ./src/mapdev/v.in.tig.lndmk/
Are these used regularly and do they work reliably? In GRASS 5.1 is there
a general vector import utility that would handle these formats like GDAL
for raster? Or maybe they should be fixed up. The comments from John
Gillette suggest they leave a lot to be desired.

There are v.in.ogr and v.out.ogr which support these formats:
http://gdal.velocet.ca/projects/opengis/ogrhtml/ogr_formats.html
+ GML which is not in above list

> ./src/mapdev/v.mkgrid/
> ./src/mapdev/v.mkquads/
Seem to perform a worthwhile function (generating vector grids) although I
can't see where they would be used. Maybe should be kept and fixed.

Yes, they may be interesting.

> ./src/imagery/i.tape.tm3/
Does r.in.gdal do the same thing as this?

Yep. And above i.tape.tm3 might be hopeless outdated. r.in.gdal
supports CEOS and LSAT FAST format (and more).

> ./src/misc/m.datum.shift/
> ./src/misc/m.gc2ll/cmd/
> ./src/misc/m.ll2gc/cmd/
> ./src/misc/m.ll2u/cmd/
> ./src/misc/m.region.ll/
> ./src/misc/m.tiger.region/
> ./src/misc/m.u2ll/
None of these operate on files in the GRASS database so I think they
should all be removed. cs2cs from PROJ.4 does the same thing as most of
them;

Yes, there is not much point in replicating cs2cs functionality.

m.tiger.region sounds like something similar to gdalinfo for vector
files; does such a program exist?

Yes: ogrinfo:
http://gdal.velocet.ca/projects/opengis/ogrhtml/ogr_utilities.html

so it's not needed (OGR supports TIGER).

> ./src/raster/r.in.dem/
This program seems not that ancient (date in 1996 given). Is the format it
handles not supported by r.in.gdal? Again I think import programs
shouldn't try to re-project data.

From it's README:
" Looking closer at the program and at the USGS DEM standard I found that
large parts of the header are actually supposed to be FORTRAN double
precision values. I'm surprised that r.in.dem works for anyone."

GDAL supports:
http://www.remotesensing.org/gdal/frmt_various.html#SDTS

> ./src/raster/r.in.ll/
This looks like it is very specific to a certain type of data import.
Almost seems to do the same thing as r.proj but I don't really understand
the man page.

Maybe also left to r.in.gdal?

> ./src/sites/s.datum.shift/
Isn't needed now s.proj can do datum shifts

ok

> ./src.contrib/NPS/r.in.utm/
Sounds like another specialised import/re-projection utility that isn't
needed now.

ok

> ./src.contrib/SCS/display/d.fix.ortho/
Description:
Shifts raster map to position specified by mouse
Is this useful? Might be and only uses coorcnv for reporting co-ordinates
in lat/long to user so would be easy to fix.

It's more dangerous than useful as it modifies the cell_header of a
raster file. With that module you can move raster images by mouse click.
But in a GIS that issue is probably better left to i.rectify and related
modules.

> ./src.contrib/SCS/vector/v.mkquads.scs/
Maybe just an older version of v.mkquads?

... or a "private" SCS version?

> ./src.contrib/SDTS/mapdev/v.out.sdts/

no idea

> ./src.garden/grass.hdf/hdf5/r.in.hdf/

r.in.gdal supports HDF much better, so r.in.hdf is not needed.

> ./src.garden/grass.tig.rim/v.in.tig.rim/
More specialised import/export utilities probably; are any of them really
needed or have they been replaced by something better.

RIM doesn't exist in GRASS any more.

Markus