I would like to start including two modules from GIPE into main svn:
i.qc.modis: classifies binary Quality flags from MODIS reflectance
products (250 & 500m) into values.
i.albedo: reflectance to albedo for Modis, Landsat5/7, aster, avhrr
----------
Michael, how do we integrate the gipe modules in the GUI?
I have an example of gmmenu.tcl and menudata.py in Addons-svn
----------
> i.qc.modis: classifies binary Quality flags from MODIS reflectance
> products (250 & 500m) into values.
compilation still fails:
CKAGE=\""grassmods"\"
-I/home/martin/src/grass_trunk/dist.i686-pc-linux-gnu/include -o
OBJ.i686-pc-linux-gnu/qc250a.o -c qc250a.c
qc250a.c: In function 'qc250a':
qc250a.c:14: error: implicit declaration of function 'swab'
make: *** [OBJ.i686-pc-linux-gnu/qc250a.o] Error 1
Right; you need <unistd.h> for swab().
BTW, what purpose does making qc250chan an "unsigned int" serve? CELL
is an "int" and the "unsigned" qualifier doesn't make any difference
to the operations which are actually being performed upon the values.
Also, the fact that the swab() calls are there seems to imply that the
data was imported incorrectly in the first place. If any byte swapping
needs to be done, it should normally be done when the data is
imported.
BTW, what purpose does making qc250chan an "unsigned int" serve? CELL
is an "int" and the "unsigned" qualifier doesn't make any difference
to the operations which are actually being performed upon the values.
The functions were designed out of GRASS, with stronger restrictions
on reading in data.
This should be obsolete in GRASS now indeed.
Also, the fact that the swab() calls are there seems to imply that the
data was imported incorrectly in the first place. If any byte swapping
needs to be done, it should normally be done when the data is
imported.
My mastering of binary reading is weak, so I guess you make sense,
but technically I would feel weak to modify it. For what I undestand
it was initially meant
(outside of GRASS) to isolate a small number of bits for & comparison.
I am using also
-fno-common
which helps to catch stuff. Earlier I used even
-Werror-implicit-function-declaration
but at some point it was to restricted (didn't try recently).
> Right; you need <unistd.h> for swab().
>
are there forgiving compilers around, so that this was not required explicitely?
By default, "implicit declaration of function ..." only generates a
warning, not an error. However, the resulting binary is likely to
crash if the compiler guesses the function's prototype incorrectly.
IIRC, Markus normally compiles with
-Werror-implicit-function-declaration, which will cause implicit
function definitions to generate an error.
> Also, the fact that the swab() calls are there seems to imply that the
> data was imported incorrectly in the first place. If any byte swapping
> needs to be done, it should normally be done when the data is
> imported.
>
My mastering of binary reading is weak, so I guess you make sense,
but technically I would feel weak to modify it. For what I undestand
it was initially meant (outside of GRASS) to isolate a small number
of bits for & comparison.
In that case, I'm guessing that the code was designed for a specific
architecture, one whose byte order is opposite to that used by the
data.
Ultimately, if you don't understand the format, or how the code is
supposed to work, it's probably better not to commit it.
I am using also
-fno-common
which helps to catch stuff. Earlier I used even
-Werror-implicit-function-declaration
but at some point it was to restricted (didn't try recently).
I've been using
CFLAGS="-ggdb -Wall -Werror-implicit-function-declaration" ./configure ...
are there forgiving compilers around, so that this was not required explicitely?
By default, "implicit declaration of function ..." only generates a
warning, not an error. However, the resulting binary is likely to
crash if the compiler guesses the function's prototype incorrectly.
IIRC, Markus normally compiles with
-Werror-implicit-function-declaration, which will cause implicit
function definitions to generate an error.
I have made that my default compile option now.
> Also, the fact that the swab() calls are there seems to imply that the
> data was imported incorrectly in the first place. If any byte swapping
> needs to be done, it should normally be done when the data is
> imported.
>
My mastering of binary reading is weak, so I guess you make sense,
but technically I would feel weak to modify it. For what I undestand
it was initially meant (outside of GRASS) to isolate a small number
of bits for & comparison.
In that case, I'm guessing that the code was designed for a specific
architecture, one whose byte order is opposite to that used by the
data.
Ultimately, if you don't understand the format, or how the code is
supposed to work, it's probably better not to commit it.
I agree.
Let me try to remove swab(). It should help clarify things.