I have hacked together the attached code to add units and vertical datum
metadata to raster maps. It still needs some cleanup before going into
CVS, but right now I am interested in comments on the approach taken.
[it works]
TODO: buffer overflow checking
TODO: create a fn in r.info to take care of G_asprint() work, right now
the "fancy output" section of the module is an ugly mess.
[non-functional code, due to me being lost WRT passing pointers]
I have hacked together the attached code to add units and vertical datum
metadata to raster maps. It still needs some cleanup before going into
CVS, but right now I am interested in comments on the approach taken.
[it works]
I remember Helena saying something about wanting a module to be able to check what units an input raster map was in, so it could warn the user if there was a subtle error. But if the units are totally free-form then this is likely to be unreliable. I'm wondering if there is some kind of standard for specifying units in an ASCII text string, and if we should investigate this and add wrapper functions to these new functions that try to ensure the units are in a prescribed format where possible. Of course people could still put anything in using your functions directly, if they had special requirements. But perhaps the modules Helena identified as having a serious need for storing and checking units should have some higher level functions to do that for them?
TODO: buffer overflow checking
TODO: create a fn in r.info to take care of G_asprint() work, right now
the "fancy output" section of the module is an ugly mess.
[non-functional code, due to me being lost WRT passing pointers]
G_asprintf() takes a pointer to a pointer for the first argument, and the compose_line() function takes a pointer for the first argument. But below compose_line is being passed a pointer to a pointer (& operator used on
something that was already a pointer) and G_asprintf() is only being passed a pointer. I think changing it so "line" is passed to compose_line and "&line" to G_asprintf would work.
> I have hacked together the attached code to add units and vertical
> datum metadata to raster maps. It still needs some cleanup before
> going into CVS, but right now I am interested in comments on the
> approach taken. [it works]
Paul Kelly wrote:
I remember Helena saying something about wanting a module to be able
to check what units an input raster map was in, so it could warn the
user if there was a subtle error. But if the units are totally
free-form then this is likely to be unreliable. I'm wondering if
there is some kind of standard for specifying units in an ASCII text
string, and if we should investigate this and add wrapper functions
to these new functions that try to ensure the units are in a
prescribed format where possible. Of course people could still put
anything in using your functions directly, if they had special
requirements. But perhaps the modules Helena identified as having a
serious need for storing and checking units should have some higher
level functions to do that for them?
units must be free form, as the possibilities are endless.
(for example I have many µg/l raster maps)
$ units
2084 units, 71 prefixes, 32 nonlinear units
^D
modules like r.slope.aspect can set "units=degrees" if they want,
and modules like r.shaded.relief and NVIZ can check, e.g.,
strcmp(tolower(units), "meters")
for hinting about scaling (Lat/Lon). I don't think it is practical to be
seriously checked, but it can be useful for hinting when available and
also for rendering d.legend and ps.map scale bar labels automatically.
> TODO: create a fn in r.info to take care of G_asprint() work, right
> now the "fancy output" section of the module is an ugly mess.
> [non-functional code, due to me being lost WRT passing pointers]
Paul Kelly wrote:
G_asprintf() takes a pointer to a pointer for the first argument, and
the compose_line() function takes a pointer for the first argument.
But below compose_line is being passed a pointer to a pointer (&
operator used on something that was already a pointer) and
G_asprintf() is only being passed a pointer. I think changing it so
"line" is passed to compose_line and "&line" to G_asprintf would
work.
Nope, still doesn't work. main()'s "line" does not get updated, ie
pointer is not returned from compose_line(). In the output I see the
previous "Mapset:" line twice.
(new diff attached)
how/where to use G_free(line)? need to move printline(line) into
compose_line() to avoid having to repeat G_free() in main() for every
call to compose_line()?
Trying that approach (2.diff) and passing the output stream to
compose_line() mostly works, but then I get va_* stdarg errors:
| Location: ðàÿ¿ .... |
I have hacked together the attached code to add units and vertical datum
metadata to raster maps. It still needs some cleanup before going into
CVS, but right now I am interested in comments on the approach taken.
[it works]
TODO: buffer overflow checking
TODO: create a fn in r.info to take care of G_asprint() work, right now
the "fancy output" section of the module is an ugly mess.
[non-functional code, due to me being lost WRT passing pointers]
> TODO: create a fn in r.info to take care of G_asprint() work, right now
> the "fancy output" section of the module is an ugly mess.
> [non-functional code, due to me being lost WRT passing pointers]
>
> /*
> if (G_asprintf(&line, "Location: %s", G_location()) > 0)
> printline(line);
> else
> G_fatal_error(_("Cannot allocate memory for string"));
> */
> compose_line( &line, "Location: %s", G_location() );
> printline(line);
> ....
>
> void compose_line(char *line, const char *fmt, ...)
> {
> va_list ap;
>
> line = NULL;
> va_start(ap, fmt);
>
> if( G_asprintf(line, fmt, ap) <= 0 )
This won't work; we need a G_vasprintf() function which takes a
va_list.
> > TODO: create a fn in r.info to take care of G_asprint() work,
> > right now the "fancy output" section of the module is an ugly
> > mess.
Glynn:
I've added G_vasprintf().
r.info cleaned. Thanks.
I have now added in support for raster map units and vertical datum
metadatas in 6.3 cvs. Settable with r.support, viewable with r.info.
All other modules currently ignore these, it is expected that in future
modules like r.shaded.relief and NVIZ may use the units values for
conversion hinting in lat/lon locations, and modules like r.patch might
produce a warning if the units or vertical datums don't match. Both are
freeform in nature, so it is not recommended to code against them for
anything critical. (ie don't expect them to be set to anything already)
For now r.info will be quiet about units and vertical datum unless they
have been set.
I also added in r.support a couple new options to set other r.info
fields, and renamed the new organization= option to source1= (as now
there is a source2= too, and "data source" may well be a satellite
name or published dataset).
All non-interactive r.support options can now be used in one call to the
program as well.
Any chance that vertical units will show up in g.proj? That's where your
current code grabs the horizontal units for display in measurement and
profiles (very nice in fact, so I'm redoing it in wxgrass too).
Michael
On 5/21/07 3:53 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:
Hamish:
TODO: create a fn in r.info to take care of G_asprint() work,
right now the "fancy output" section of the module is an ugly
mess.
Glynn:
I've added G_vasprintf().
r.info cleaned. Thanks.
I have now added in support for raster map units and vertical datum
metadatas in 6.3 cvs. Settable with r.support, viewable with r.info.
All other modules currently ignore these, it is expected that in future
modules like r.shaded.relief and NVIZ may use the units values for
conversion hinting in lat/lon locations, and modules like r.patch might
produce a warning if the units or vertical datums don't match. Both are
freeform in nature, so it is not recommended to code against them for
anything critical. (ie don't expect them to be set to anything already)
For now r.info will be quiet about units and vertical datum unless they
have been set.
I also added in r.support a couple new options to set other r.info
fields, and renamed the new organization= option to source1= (as now
there is a source2= too, and "data source" may well be a satellite
name or published dataset).
All non-interactive r.support options can now be used in one call to the
program as well.
Hamish
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Any chance that vertical units will show up in g.proj? That's where your
Vertical units apply only to a particular map in a particular mapset, not to all the mapsets in a location like horizontal units (i.e. the location's co-ordinate system do). And it's perfectly valid to have different elevation maps in different units in the same mapset and to have to convert between them (e.g. ellipsoidal height from GPS and geoid height above sea level). I can't really see how the location co-ordinate system definition could easily be extended to support units for the 3rd dimension
This makes perfect sense. I didn't think it through.
Michael
On 5/21/07 1:28 PM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:
On Mon, 21 May 2007, Michael Barton wrote:
Any chance that vertical units will show up in g.proj? That's where your
Vertical units apply only to a particular map in a particular mapset, not
to all the mapsets in a location like horizontal units (i.e. the
location's co-ordinate system do). And it's perfectly valid to have
different elevation maps in different units in the same mapset and to
have to convert between them (e.g. ellipsoidal height from GPS and geoid
height above sea level). I can't really see how the location co-ordinate
system definition could easily be extended to support units for the 3rd
dimension
Paul
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University
