(moved here from grass-user)
On Fri, Apr 24, 2009 at 11:51 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Wed, Apr 22, 2009 at 10:58 PM, Jack Lonsdale <lonsdale@unbc.ca> wrote:
I am continuing to try and use Grass to process my LiDAR data. However,
having completed v.lidar.edgedetect successfully I am unable to complete
v.lidar.growing
firstly, just to check, the 'first' parameter is the raw dataset? If not
how do I create the first return dataset?
Secondly, if I run the following:
v.lidar.growing input=alrf_subs_edge@lonsdale output=alrf_subs_grow
first=alrf_subs_raw tj=0.2 td=0.6
All I get is a dbmi:Protocol error, It was impossible to open this
table!
ha! I guess I found the error.
Please try again *without* specifying the mapset (@lonsdale). If it is
not in the path, use g.mapsets (-s for GUI) to add it.
Runs, right?
The bug is here:
sprintf(buf, "SELECT Interp,ID FROM %s_edge_Interpolation",
in_opt->answer);
db_append_string(&sql, buf);
in_opt->answer contains (in your case) the @mapset part which causes
the DBMI engine to crash. So that should be easy to fix in the module.
@devs: how to strip off the mapset part of a name? Don't remember...
Fix proposal attached, using G__name_is_fully_qualified().
I still don't like to use a G__ function but it seems to work.
Submit?
Markus
(attachments)
v.lidar.growing.diff (1.51 KB)
On Sun, Apr 26, 2009 at 10:02 AM, Markus Neteler<neteler@osgeo.org> wrote:
(moved here from grass-user)
On Fri, Apr 24, 2009 at 11:51 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Wed, Apr 22, 2009 at 10:58 PM, Jack Lonsdale <lonsdale@unbc.ca> wrote:
I am continuing to try and use Grass to process my LiDAR data. However,
having completed v.lidar.edgedetect successfully I am unable to complete
v.lidar.growing
firstly, just to check, the 'first' parameter is the raw dataset? If not
how do I create the first return dataset?
Secondly, if I run the following:
v.lidar.growing input=alrf_subs_edge@lonsdale output=alrf_subs_grow
first=alrf_subs_raw tj=0.2 td=0.6
All I get is a dbmi:Protocol error, It was impossible to open this
table!
ha! I guess I found the error.
Please try again *without* specifying the mapset (@lonsdale). If it is
not in the path, use g.mapsets (-s for GUI) to add it.
Runs, right?
The bug is here:
sprintf(buf, "SELECT Interp,ID FROM %s_edge_Interpolation",
in_opt->answer);
db_append_string(&sql, buf);
in_opt->answer contains (in your case) the @mapset part which causes
the DBMI engine to crash. So that should be easy to fix in the module.
@devs: how to strip off the mapset part of a name? Don't remember...
Fix proposal attached, using G__name_is_fully_qualified().
I still don't like to use a G__ function but it seems to work.
Submit?
Done.
Markus
Markus Neteler wrote:
>> @devs: how to strip off the mapset part of a name? Don't remember...
In 7.0, use G__unqualified_name().
[That probably shouldn't use a G__ prefix.]
--
Glynn Clements <glynn@gclements.plus.com>
Hi,
2009/8/2 Glynn Clements <glynn@gclements.plus.com>:
In 7.0, use G__unqualified_name().
[That probably shouldn't use a G__ prefix.]
+1 & done in r38594.
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa