Hi,
I have just noticed that a new interpolation module has arrived Grass
CVS. It is great to have it, many thanks to the authors!
I was wondering if the name shouldn't be changed to conform to other
Grass interpolation modules. We have v.surf.* and r.surf.* . Shouldn't
the bspline follow? For the user's and clarity sake.
Maciek
Maciej Sieczka napisa?(a):
I have just noticed that a new interpolation module has arrived Grass
CVS. It is great to have it, many thanks to the authors!I was wondering if the name shouldn't be changed to conform to other
Grass interpolation modules. We have v.surf.* and r.surf.* . Shouldn't
the bspline follow? For the user's and clarity sake.
I really think this is an issue so I'll let myself insist a bit on a reply.
I'm quoting Paul Kelly from a thread where another module-candidate name
is disussed, as I fully second his opinion:
"I actually think that serious discussion of potential names for new
modules is very worthwhile and makes a big difference to how easy it is
for users to find the module in the future"
Maciek
Maciej Sieczka wrote:
Again, let me rise it. This is not a trivial issue. Soon v.bspline will
become a part of user scripts, GUI menu and stuff. Then it will be too
late to rename the module for Grass 6.3 not to break comptatibility.
Why isn't anybody replying? Hey, Grass PSC!
Maciek
Hi,
I agree with you, the module should be renamed.
Martin
2006/9/2, Maciej Sieczka <tutey@o2.pl>:
Maciej Sieczka wrote:
Again, let me rise it. This is not a trivial issue. Soon v.bspline will
become a part of user scripts, GUI menu and stuff. Then it will be too
late to rename the module for Grass 6.3 not to break comptatibility.Why isn't anybody replying? Hey, Grass PSC!
Maciek
_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *
On Sat, 2006-09-02 at 12:01 +0200, Maciej Sieczka wrote:
Maciej Sieczka wrote:
Again, let me rise it. This is not a trivial issue. Soon v.bspline will
become a part of user scripts, GUI menu and stuff. Then it will be too
late to rename the module for Grass 6.3 not to break comptatibility.Why isn't anybody replying? Hey, Grass PSC!
I must have missed the original discussion. I agree that v.bspline
should be renamed to v.surf.bspline for the sake of consistency.
Also, I believe it would be better to move it to 'vector/' instead of
'vector/lidar/' as it is not particularly specific to LIDAR.
--
Brad Douglas <rez touchofmadness com> KB8UYR
Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785
On Sat, Sep 02, 2006 at 04:39:06AM -0700, Brad Douglas wrote:
On Sat, 2006-09-02 at 12:01 +0200, Maciej Sieczka wrote:
> Maciej Sieczka wrote:
>
> Again, let me rise it. This is not a trivial issue. Soon v.bspline will
> become a part of user scripts, GUI menu and stuff. Then it will be too
> late to rename the module for Grass 6.3 not to break comptatibility.
>
> Why isn't anybody replying? Hey, Grass PSC!I must have missed the original discussion. I agree that v.bspline
should be renamed to v.surf.bspline for the sake of consistency.Also, I believe it would be better to move it to 'vector/' instead of
'vector/lidar/' as it is not particularly specific to LIDAR.
I have written twice to the author(s) but didn't receive a
response on this issue.
It is now VERY urgent since we have already done 6.2.0.beta2.
Or we decide to keep the name in 6.2 and change it in 6.3.
Or we just change it without listening to the author(s).
However, moding code around in CVS isn't nice, so I don't
know if it must be really moved out of vector/lidar/.
Markus
On Sep 2, 2006, at 8:42 AM, Markus Neteler wrote:
On Sat, Sep 02, 2006 at 04:39:06AM -0700, Brad Douglas wrote:
On Sat, 2006-09-02 at 12:01 +0200, Maciej Sieczka wrote:
Maciej Sieczka wrote:
Again, let me rise it. This is not a trivial issue. Soon v.bspline will
become a part of user scripts, GUI menu and stuff. Then it will be too
late to rename the module for Grass 6.3 not to break comptatibility.Why isn't anybody replying? Hey, Grass PSC!
I must have missed the original discussion. I agree that v.bspline
should be renamed to v.surf.bspline for the sake of consistency.Also, I believe it would be better to move it to 'vector/' instead of
'vector/lidar/' as it is not particularly specific to LIDAR.I have written twice to the author(s) but didn't receive a
response on this issue.
It is now VERY urgent since we have already done 6.2.0.beta2.Or we decide to keep the name in 6.2 and change it in 6.3.
Or we just change it without listening to the author(s).
However, moding code around in CVS isn't nice, so I don't
know if it must be really moved out of vector/lidar/.
Markus most of the code for lidar data processing is useful for many other things (r.in.xyz
is a good example) so agree with Brad that it should be just under vector rather
than vector/lidar.
Helena
Markus
_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
v.bspline should be renamed to v.surf.bspline for the sake of
consistency.
I haven't actually used the module, but in theory I agree it should be
renamed.
>> Also, I believe it would be better to move it to 'vector/' instead
>> of 'vector/lidar/' as it is not particularly specific to LIDAR.
it uses vector/lidar/lidarlib/, so you might have to move
vector/lidar/lidarlib/ to lib/lidar/ as well. I think moving v.bspline
without moving lidarlib/ is a mistake.
> I have written twice to the author(s) but didn't receive a
> response on this issue.
> It is now VERY urgent since we have already done 6.2.0.beta2.
>
> Or we decide to keep the name in 6.2 and change it in 6.3.
>
> Or we just change it without listening to the author(s).
note this is a port from GRASS 5. The according to the help page the
original authors are Maria Antonia Brovelli, Massimiliano Cannata,
Ulisse Longoni, and Mirko Reguzzoni. That module was
grass/src.contrib/POLIMICO/s.bspline.reg/
my thoughts:
* hopefully we get an "ok" from the authors soon.
* if not, the code is in our care & we do what we need to do.
* it is easy enough to change the name now, just:
RCS file:
/home/grass/grassrepository/grass6/vector/lidar/v.bspline/Makefile,v
retrieving revision 1.3
diff -u -r1.3 Makefile
--- Makefile 22 Aug 2006 20:03:35 -0000 1.3
+++ Makefile 4 Sep 2006 04:36:15 -0000
@@ -1,6 +1,6 @@
MODULE_TOPDIR = ../../..
-PGM = v.bspline
+PGM = v.surf.bspline
LIBES = $(LIDARLIB) $(VECTLIB) $(DBMILIB) $(GISLIB) $(MATHLIB) $(SEGMENTLIB) $(GMATHLIB)
DEPENDENCIES= $(LIDARDEP) $(VECTDEP) $(DBMIDEP) $(GISDEP) $(BSPLINE_ARCH_OBJ) $(GMATHDEP)
It is easy to change the name later: make v.bspline a symlink for
backwards compatibility*, but much better to do now it before
release IMO.
[*] see d.paint.labels -> d.labels rename; CVS dir structure unchanged
lidarlib/PolimiFunct.h defines structs "Point" and "element". I suggest
these be changed to something less likely to collide with something else.
Also PolimiFunct.h re-#defines TRUE, FALSE, after #including gis.h.
> However, moding code around in CVS isn't nice, so I don't
> know if it must be really moved out of vector/lidar/.
This depends on what happens to lidarlib/ I think.
We do have raster/simwe/ and raster/wildfire/ without complaint.
my vote is to rename it in the Makefile now and consider reverting it
if the authors object. We can move it later in CVS if wanted without
affecting anything as far as the user.
btw, it's missing from the TclTk menu, so are the other v.lidar.*.
Hamish
On Mon, Sep 04, 2006 at 06:26:52PM +1200, Hamish wrote:
...
> >> Also, I believe it would be better to move it to 'vector/' instead
> >> of 'vector/lidar/' as it is not particularly specific to LIDAR.it uses vector/lidar/lidarlib/, so you might have to move
vector/lidar/lidarlib/ to lib/lidar/ as well. I think moving v.bspline
without moving lidarlib/ is a mistake.
If so, we have to do the same also with SIMWE and others.
I am not really sure if we want to do that. lidarlib/ seems
to apply only to vector/lidar/*. If there are functions
of wider interest, we could simply move it to gmathlib or
other appropriate libs.
> > I have written twice to the author(s) but didn't receive a
> > response on this issue.
> > It is now VERY urgent since we have already done 6.2.0.beta2.
> >
> > Or we decide to keep the name in 6.2 and change it in 6.3.
> >
> > Or we just change it without listening to the author(s).note this is a port from GRASS 5. The according to the help page the
original authors are Maria Antonia Brovelli, Massimiliano Cannata,
Ulisse Longoni, and Mirko Reguzzoni. That module was
grass/src.contrib/POLIMICO/s.bspline.reg/
Yes, I am aware of that (I also added src.contrib/POLIMICO/* in
those days). But Roberto answered recently.
[Makefile change]
It is easy to change the name later: make v.bspline a symlink for
backwards compatibility*, but much better to do now it before
release IMO.
Yes.
[*] see d.paint.labels -> d.labels rename; CVS dir structure unchanged
lidarlib/PolimiFunct.h defines structs "Point" and "element". I suggest
these be changed to something less likely to collide with something else.
Also PolimiFunct.h re-#defines TRUE, FALSE, after #including gis.h.
I hope that Roberto is listening...
> > However, moding code around in CVS isn't nice, so I don't
> > know if it must be really moved out of vector/lidar/.This depends on what happens to lidarlib/ I think.
We do have raster/simwe/ and raster/wildfire/ without complaint.
Right - see my comments above.
my vote is to rename it in the Makefile now and consider reverting it
if the authors object. We can move it later in CVS if wanted without
affecting anything as far as the user.
Sounds like a plan 
btw, it's missing from the TclTk menu, so are the other v.lidar.*.
Yes.
Markus
These kind of popped up out of nowhere. I recently noticed them appearing in
the source. There has been a lot of interesting new stuff recently. Let me
know what is going to actually to into 6.2 and I can add it to the menu.
Also, I seem to remember something going by the list recently (it's been
busy here) about some functions on the menu that are no longer compiled. If
anyone remembers what they are, they can be removed.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
From: Hamish <hamish_nospam@yahoo.com>
Date: Mon, 4 Sep 2006 18:26:52 +1200
To: Helena Mitasova <hmitaso@unity.ncsu.edu>
Cc: <neteler@itc.it>, <maria.brovelli@polimi.it>, <grass-dev@grass.itc.it>,
<roberto@geomatica.como.polimi.it>, <rez@touchofmadness.com>
Subject: Re: [GRASS-dev] v.bspline -> v.surf.bspline ?btw, it's missing from the TclTk menu, so are the other v.lidar.*.
On Mon, Sep 04, 2006 at 09:37:35AM -0700, Michael Barton wrote:
These kind of popped up out of nowhere.
Michael,
not really from nowhere :-). An earlier version already exists in
GRASS 5 since 2002. There is a related paper in "Transactions in GIS".
At Lausanne, we'll give a workshop which covers the new Lidar
tools:
http://www.foss4g2006.org/sessionDisplay.py?sessionId=59&confId=1
-> [48] Power User Workshop: GRASS image processing
I recently noticed them appearing in
the source. There has been a lot of interesting new stuff recently. Let me
know what is going to actually to into 6.2 and I can add it to the menu.
They are present in 6.2, so it would be nice to have them added.
If added in 6.3, I can backport that.
For the flow of processing, I have added a short paragraph at
bottom of
http://grass.itc.it/grass63/manuals/html63_user/vectorintro.html
-> Lidar data processing
Also, I seem to remember something going by the list recently (it's been
busy here) about some functions on the menu that are no longer compiled. If
anyone remembers what they are, they can be removed.
Hamish has removed them.
Markus
I wrote:
> my vote is to rename it in the Makefile now and consider reverting
> it if the authors object. We can move it later in CVS if wanted
> without affecting anything as far as the user.
I have now done this in GRASS 6.3 and the GRASS 6.2-release branch.
Michael Barton wrote:
These kind of popped up out of nowhere. I recently noticed them
appearing in the source. There has been a lot of interesting new stuff
recently.
AFAICT, they were not announced to the -dev list when added to CVS. I
didn't know they existed until about 3 days ago (I missed earlier
discusions).
Let me know what is going to actually to into 6.2 and I can add it to
the menu.
Yes, they are tagged to be in the 6.2 release, so menu items should be
added & backported for that. (thanks)
also, I notice the help page says the original version was from 5.4 with
various authors, but the main.c copyright statement mentions nothing
about this. If any code from the GRASS 5 version made it into GRASS 6
then the copyright statements in the original code must be presented as
well.
Hamish