From glynn at gclements.plus.com Fri Sep 1 00:04:36 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Sep 1 00:04:44 2006 Subject: [GRASS-dev] Re: [GRASS-user] invoking d.vect and d.rast from CLI In-Reply-To: <0E5A77B55A57D511BB3F0002A537C26208C55B57@s5-dar-r1.nrn.nrcan.gc.ca> References: <0E5A77B55A57D511BB3F0002A537C26208C55B57@s5-dar-r1.nrn.nrcan.gc.ca> Message-ID: <17655.23796.523484.461546@cerise.gclements.plus.com> Patton, Eric wrote: > I'm having trouble getting d.rast and d.vect working on the command line. > Here's a step-by-step to reproduce using Spearfish: > > After initial Grass 6.3 startup finishes: > > >d.mon -L > # Shouldn't gism be shown as running here? No. The gism monitor is no longer used; even when gis.m did use it, it would start and stop it as necessary. > >d.mon start=gism The gism monitor is "reserved" for gis.m. Don't attempt to use it yourself. Now that gis.m no longer uses it, it is likely to be removed. > ~ >d.mon -L > # I seem to remember before that gism was shown as being selected immediately > # upon starting Grass... It used to be, but isn't any more. But that doesn't matter. > ~ >g.region rast=elevation.10m > ~ >d.rast -o map=elevation.10m > 100% > > # Nothing draws in the gis.m map display! Even when gis.m used the gism monitor, this wouldn't have worked. gis.m will only attempt to display the images which are generated at its request. Any other images generated by the monitor will be ignored. > # Let's try a vector instead... > > ~ >g.region vect=soils > ~ >d.vect soils > > Again, nothing displays. > > Any ideas on what's going on here? You appear to have misunderstood what gis.m does and how it works. Currently, there is no mechanism by which another process can control what is displayed in gis.m. Such a feature would be useful, but implementing it would be non-trivial. -- Glynn Clements From glynn at gclements.plus.com Fri Sep 1 00:15:16 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Sep 1 00:19:49 2006 Subject: [GRASS-dev] [bug #4905] (grass) gis.m: d.text.freetype does not allow spaces in text In-Reply-To: <20060831141636.CA4271006D7@lists.intevation.de> References: <20060831141636.CA4271006D7@lists.intevation.de> Message-ID: <17655.24436.422287.500971@cerise.gclements.plus.com> Maciek Sieczka via RT wrote: > > With the difference that you do > > > > text='Population total' in bourne shell > > > > but > > > > {text=Population totale} > > > > > > The backslash solution works and seems more intuitive. > > I'll add a hint in the gis.m description.html. > > Do you think that d.text.freetype (and other modules that may require {} or \ > for attributes to work properly from gis.m) could put {} or \ automatically > for the user? No. Well, gis.m *could* add braces or backslashes based upon some arbitrary heuristics, but there's no way that it can be done reliably. E.g. the following: d.text.freetype text=text color=string can be legtimately interpreted as either: d.text.freetype {text=text} {color=red} ... or: d.text.freetype {text=text color=red} ... The former draws the string "text" in red, while the latter draws the string "text color=red" in the default colour. Computers cannot read minds; that isn't a bug, that's just how it is. If you want a space to be treated as a literal character rather than as an argument separator, you have to say so. -- Glynn Clements From paul-grass at stjohnspoint.co.uk Fri Sep 1 01:22:48 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Fri Sep 1 01:25:00 2006 Subject: [GRASS-dev] grass63 -text startup screen In-Reply-To: <20060830215351.0157767d@localhost.localdomain> References: <44F5917C.2050001@o2.pl> <20060830082128.7538458a@localhost.localdomain> <20060830215351.0157767d@localhost.localdomain> Message-ID: <44F76F48.8070504@stjohnspoint.co.uk> Trevor Wiens wrote: [...] > The wording looks great. But I did think of one more thing (sorry > Paul). Looking at the text interface to check your comment about > Spearfish, I remembered that when I first used GRASS (some years ago > now) I thought the ordering of fields was odd. Wouldn't it be more > logical to put the DATABASE first and the associated entry field also > first? Since locations are dependent on databases? Thus the order of > description and input would be from the largest unit to the smallest. > It would also place the comment about the region default directly under > the MAPSET description. Well I guess the thinking with the Database at the bottom is it isn't something you're going to change very much. The cursor is automatically placed in the Location box which is fairly user-friendly. The order of the descriptions could be changed though as it is most likely to be read by a new user and ease of introduction should be more important here. I'm going to be away for a few days so will look at it next week. The wording of the database description would need to be slightly changed to avoid it looking out of place at the top. Paul From paul-grass at stjohnspoint.co.uk Fri Sep 1 01:23:56 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Fri Sep 1 01:26:04 2006 Subject: [GRASS-dev] grass63 -text startup screen In-Reply-To: <20060831165853.09559de6.hamish_nospam@yahoo.com> References: <44F5917C.2050001@o2.pl> <20060830082128.7538458a@localhost.localdomain> <20060831165853.09559de6.hamish_nospam@yahoo.com> Message-ID: <44F76F8C.5070104@stjohnspoint.co.uk> Hamish wrote: > > sorry if I missed the answer, but what became of the idea to use multi- > sentence tool-tips to explain each field? Well Helena said it was a good idea but I didn't receive any further replies. Have to admit I wouldn't actually know where to look to change it myself. Paul From hmitaso at unity.ncsu.edu Fri Sep 1 02:52:41 2006 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Fri Sep 1 02:52:48 2006 Subject: [GRASS-dev] grass63 -text startup screen In-Reply-To: <44F76F8C.5070104@stjohnspoint.co.uk> References: <44F5917C.2050001@o2.pl> <20060830082128.7538458a@localhost.localdomain> <20060831165853.09559de6.hamish_nospam@yahoo.com> <44F76F8C.5070104@stjohnspoint.co.uk> Message-ID: On Aug 31, 2006, at 7:23 PM, Paul Kelly wrote: > Hamish wrote: >> sorry if I missed the answer, but what became of the idea to use >> multi- >> sentence tool-tips to explain each field? > > Well Helena said it was a good idea but I didn't receive any > further replies. Have to admit I wouldn't actually know where to > look to change it myself. Hamish, this discussion is about the text that shows-up with the old, text-based interface. The suggestion for tool-tips was for the startup GUI. After the FOSS4G conference we should start looking into the startup GUI again, as creating a new location is still problematic, Helena > > Paul > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From hamish_nospam at yahoo.com Fri Sep 1 05:17:40 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Sep 1 05:17:59 2006 Subject: [GRASS-dev] Re: [GRASS-user] [bug #3041] nviz max resolution ppm image dump In-Reply-To: <17654.56613.600780.723615@cerise.gclements.plus.com> References: <44F32EC1.7080908@fire.esd.ornl.gov> <20060829141340.7e01582d.hamish_nospam@yahoo.com> <44F3ABA0.4050200@fire.esd.ornl.gov> <20060829180608.72176063.hamish_nospam@yahoo.com> <1156852657.8124.9.camel@linuxmain.localhost> <20060830171428.76de4e89.hamish_nospam@yahoo.com> <17653.35468.666861.57261@cerise.gclements.plus.com> <20060831154810.287856fc.hamish_nospam@yahoo.com> <17654.56613.600780.723615@cerise.gclements.plus.com> Message-ID: <20060901151740.29b45429.hamish_nospam@yahoo.com> Glynn Clements wrote: > > With off-screen rendering disabled, I get good results with either > > of the above var_i calculations. > > The off-screen rendering draws to the back-buffer, GS_write_zoom() > dumps the front buffer. Also, Create_OS_Ctx() hides the Togl canvas > (presumably to prevent expose events from trashing the OpenGL state > during off-screen rendering), so it probably isn't usable for > rendering. > > Does this help? > > diff -u -r2.6 do_zoom.c > --- visualization/nviz/src/do_zoom.c 9 Jul 2006 08:58:40 -0000 2.6 > +++ visualization/nviz/src/do_zoom.c 31 Aug 2006 12:58:16 -0000 > @@ -325,6 +325,9 @@ > } > #endif > > + if (!pbuffer && !glxpixmap) > + return 1; > + > /* hide togl canvas before init_ctx > * This prevents bindings from re-initializing > * togl */ Nope. No change. Does max res PPM dump work for anybody? (ie is it a platform dependent thing) Shall we disable offscreen rendering for the 6.2 release branch in case it doesn't get fixed in time for release? Hamish From glynn at gclements.plus.com Fri Sep 1 05:50:37 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Sep 1 05:50:45 2006 Subject: [GRASS-dev] Re: [GRASS-user] [bug #3041] nviz max resolution ppm image dump In-Reply-To: <20060901151740.29b45429.hamish_nospam@yahoo.com> References: <44F32EC1.7080908@fire.esd.ornl.gov> <20060829141340.7e01582d.hamish_nospam@yahoo.com> <44F3ABA0.4050200@fire.esd.ornl.gov> <20060829180608.72176063.hamish_nospam@yahoo.com> <1156852657.8124.9.camel@linuxmain.localhost> <20060830171428.76de4e89.hamish_nospam@yahoo.com> <17653.35468.666861.57261@cerise.gclements.plus.com> <20060831154810.287856fc.hamish_nospam@yahoo.com> <17654.56613.600780.723615@cerise.gclements.plus.com> <20060901151740.29b45429.hamish_nospam@yahoo.com> Message-ID: <17655.44557.390080.801898@cerise.gclements.plus.com> Hamish wrote: > > > With off-screen rendering disabled, I get good results with either > > > of the above var_i calculations. > > > > The off-screen rendering draws to the back-buffer, GS_write_zoom() > > dumps the front buffer. Also, Create_OS_Ctx() hides the Togl canvas > > (presumably to prevent expose events from trashing the OpenGL state > > during off-screen rendering), so it probably isn't usable for > > rendering. > > > > Does this help? > > > > diff -u -r2.6 do_zoom.c > > --- visualization/nviz/src/do_zoom.c 9 Jul 2006 08:58:40 -0000 2.6 > > +++ visualization/nviz/src/do_zoom.c 31 Aug 2006 12:58:16 -0000 > > @@ -325,6 +325,9 @@ > > } > > #endif > > > > + if (!pbuffer && !glxpixmap) > > + return 1; > > + > > /* hide togl canvas before init_ctx > > * This prevents bindings from re-initializing > > * togl */ > > Nope. No change. Did you try with GRASS_NO_GLX_{PBUFFERS,PIXMAPS} set? With those set, and the above patch, Create_OS_Ctx() should essentially be a no-op. > Does max res PPM dump work for anybody? (ie is it a platform dependent > thing) > > Shall we disable offscreen rendering for the 6.2 release branch in case > it doesn't get fixed in time for release? It should suffice to ensure that it can be disabled at run time. -- Glynn Clements From hamish_nospam at yahoo.com Fri Sep 1 07:36:34 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Sep 1 07:36:40 2006 Subject: [GRASS-dev] Re: [bug #4905] (grass) gis.m: d.text.freetype does not allow spaces in text In-Reply-To: <44F6F1CE.6080509@o2.pl> References: <20060830151604.541d4f89.hamish_nospam@yahoo.com> <17653.37525.758455.944196@cerise.gclements.plus.com> <20060830174856.GC8438@localhost.tamu.edu> <17653.53497.833664.664895@cerise.gclements.plus.com> <20060830181307.GA43424@localhost.tamu.edu> <44F6F1CE.6080509@o2.pl> Message-ID: <20060901173634.51f7b73b.hamish_nospam@yahoo.com> Maciej Sieczka wrote: > >> Is there any reason why those features can't be added to d.text? > > > No, it's simply because nobody did it. Hopefully, I'll sometime. > > Would that let us drop d.text.freetype then? The module must remain until GRASS 7. Some people may have scripts/apps that depend on it. Having said that, warnings can easily be added to the help page etc letting users know there are better options. If can of course be removed from the GUI (already has been AFAIK). Hamish From hamish_nospam at yahoo.com Fri Sep 1 07:31:49 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Sep 1 07:37:03 2006 Subject: [GRASS-dev] Re: [GRASS-user] [bug #3041] nviz max resolution ppm image dump In-Reply-To: <17655.44557.390080.801898@cerise.gclements.plus.com> References: <44F32EC1.7080908@fire.esd.ornl.gov> <20060829141340.7e01582d.hamish_nospam@yahoo.com> <44F3ABA0.4050200@fire.esd.ornl.gov> <20060829180608.72176063.hamish_nospam@yahoo.com> <1156852657.8124.9.camel@linuxmain.localhost> <20060830171428.76de4e89.hamish_nospam@yahoo.com> <17653.35468.666861.57261@cerise.gclements.plus.com> <20060831154810.287856fc.hamish_nospam@yahoo.com> <17654.56613.600780.723615@cerise.gclements.plus.com> <20060901151740.29b45429.hamish_nospam@yahoo.com> <17655.44557.390080.801898@cerise.gclements.plus.com> Message-ID: <20060901173149.5b403a05.hamish_nospam@yahoo.com> > > > > With off-screen rendering disabled, I get good results with > > > > either of the above var_i calculations. > > > > > > The off-screen rendering draws to the back-buffer, GS_write_zoom() > > > dumps the front buffer. Also, Create_OS_Ctx() hides the Togl > > > canvas (presumably to prevent expose events from trashing the > > > OpenGL state during off-screen rendering), so it probably isn't > > > usable for rendering. > > > > > > Does this help? > > > > > > diff -u -r2.6 do_zoom.c > > > --- visualization/nviz/src/do_zoom.c 9 Jul 2006 08:58:40 -0000 2.6 > > > +++ visualization/nviz/src/do_zoom.c 31 Aug 2006 12:58:16 -0000 > > > @@ -325,6 +325,9 @@ > > > } > > > #endif > > > > > > + if (!pbuffer && !glxpixmap) > > > + return 1; > > > + > > > /* hide togl canvas before init_ctx > > > * This prevents bindings from re-initializing > > > * togl */ > > > > Nope. No change. > > Did you try with GRASS_NO_GLX_{PBUFFERS,PIXMAPS} set? > > With those set, and the above patch, Create_OS_Ctx() should > essentially be a no-op. I didn't. I have now and it renders correctly; you see each panel being rendered in the NVIZ window. i.e. : This works + if (!pbuffer && !glxpixmap) + return 1; and export GRASS_NO_GLX_PIXMAPS=TRUE export GRASS_NO_GLX_PBUFFERS=TRUE OR making this test always false makes it work: /* create off-screen context if possible */ #if defined(OPENGL_X11) && (defined(HAVE_PBUFFERS) || defined(HAVE_PIXMAPS)) it fails with: (random bits of old windows in built panels) + if (!pbuffer && !glxpixmap) + return 1; and unset GRASS_NO_GLX_PIXMAPS export GRASS_NO_GLX_PBUFFERS=TRUE it fails with: (mostly black with some color stripes in built panels) + if (!pbuffer && !glxpixmap) + return 1; and export GRASS_NO_GLX_PIXMAPS=TRUE unset GRASS_NO_GLX_PBUFFERS > > Does max res PPM dump work for anybody? (ie is it a platform > > dependent thing) > > > > Shall we disable offscreen rendering for the 6.2 release branch in > > case it doesn't get fixed in time for release? > > It should suffice to ensure that it can be disabled at run time. or by packagers (say if it's broken for all MacOSX) Hamish From grass-bugs at intevation.de Fri Sep 1 09:11:57 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Fri Sep 1 09:12:00 2006 Subject: [GRASS-dev] [bug #4905] (grass) gis.m: d.text.freetype does not allow spaces in text Message-ID: <20060901071157.95D241006DA@lists.intevation.de> glynn@gclements.plus.com wrote (Fri, Sep 1 2006 00:19:56): > Computers cannot read minds; that isn't a bug, that's just how it is. > > If you want a space to be treated as a literal character rather than > as an argument separator, you have to say so. OK, Moritz volunteered for documenting it. Moritz, please send me the patch and I'll apply it. Maciek -------------------------------------------- Managed by Request Tracker From tutey at o2.pl Fri Sep 1 09:13:39 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Fri Sep 1 09:13:42 2006 Subject: [GRASS-dev] Re: [bug #4905] (grass) gis.m: d.text.freetype does not allow spaces in text In-Reply-To: <20060901173634.51f7b73b.hamish_nospam@yahoo.com> References: <20060830151604.541d4f89.hamish_nospam@yahoo.com> <17653.37525.758455.944196@cerise.gclements.plus.com> <20060830174856.GC8438@localhost.tamu.edu> <17653.53497.833664.664895@cerise.gclements.plus.com> <20060830181307.GA43424@localhost.tamu.edu> <44F6F1CE.6080509@o2.pl> <20060901173634.51f7b73b.hamish_nospam@yahoo.com> Message-ID: <44F7DDA3.20003@o2.pl> Hamish wrote: > Maciej Sieczka wrote: > >>>> Is there any reason why those features can't be added to d.text? >>> No, it's simply because nobody did it. Hopefully, I'll sometime. >> Would that let us drop d.text.freetype then? > > > The module must remain until GRASS 7. That's how I understanding it too. I have added a note to Grass 7 ideas on WIKI. Maciek From tutey at o2.pl Fri Sep 1 10:31:41 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Fri Sep 1 10:31:45 2006 Subject: [GRASS-dev] Re: gis.m: another 2 region bugs [was: gis.m: 2 region handling bugs] In-Reply-To: References: Message-ID: <44F7EFED.1020000@o2.pl> Michael Barton wrote: > Maciej, > > Not saying I don't believe you. But I zoomed in and out multiple times on 2 > different maps open at the same time (I used roads and elevation_dem in > Spearfish to have a raster and a vector). Maybe you're doing some other > operation you didn't mention? Michael, Offlist I'm sending you a sample swf video where you can see all the operations that lead to a bogus zoom-in when two Map Displays are active. Maybe now the bug is obvious enough. Let me know if I should eleborate further. To play the video, just double-click the html file included (given that your browser has a flash plugin installed). I could transform it to mpeg, but the picture will be blury. The file is 3MB. Let me know if too big, I'try to send it some other way then. Cheers, Maciek P.S. The swf was produced using vncserver and vncviewer on the same machine, while pyvnc2swf-0.8.2 http://www.unixuser.org/~euske/vnc2swf/ was recording the vncviewer window. Nice stuff for screencasting. From neteler at itc.it Fri Sep 1 11:01:26 2006 From: neteler at itc.it (Markus Neteler) Date: Fri Sep 1 11:01:28 2006 Subject: [GRASS-dev] Re: Grass 6.1 In-Reply-To: References: Message-ID: <20060901090126.GB12905@bartok.itc.it> Hi, I got a request where a client of IRST wants to use GRASS via FreeNX (Linux Terminal server) on Windows machines. When starting GRASS, a TclTk problem appears: [citing his mail] ... > Starting GRASS ... > Application initialization failed: this isn't a Tk applicationunknown > color name "Black" > Error in startup script: can't invoke "image" command: application > has been des troyed > while executing > "image create photo -data > "R0lGODlhIAAgALP/AP///8DAwP8A/7+/v39/f38AfwD//wB/AAAA/ > wAAfwAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAAEALAAAAAAgACAAAAT/kMhJq50h60yA/2Ao..." > (in namespace eval "::help" script line 27) > invoked from within > "namespace eval help { > variable w > variable abort 0 > variable showing 0 > variable stat "" > variable curfilename "" > variable data > variable history ""..." > (file "/usr/local/grass-6.1.0/etc/help.tcl" line 61) > invoked from within > "source $env(GISBASE)/etc/help.tcl" > (file "/usr/local/grass-6.1.0/etc/gis_set.tcl" line 38) > /home/manganelll///.gislock: No such file or directory > ERROR: /usr/local/grass-6.1.0/etc/lock: Any hint would be welcome. thanks, Markus From mlennert at club.worldonline.be Fri Sep 1 11:30:24 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Sep 1 11:30:04 2006 Subject: [GRASS-dev] Re: Grass 6.1 In-Reply-To: <20060901090126.GB12905@bartok.itc.it> References: <20060901090126.GB12905@bartok.itc.it> Message-ID: <44F7FDB0.2010304@club.worldonline.be> Markus Neteler wrote: > Hi, > > I got a request where a client of IRST wants to use GRASS via > FreeNX (Linux Terminal server) on Windows machines. When > starting GRASS, a TclTk problem appears: > > [citing his mail] > > ... >> Starting GRASS ... >> Application initialization failed: this isn't a Tk applicationunknown >> color name "Black" >> Error in startup script: can't invoke "image" command: application >> has been des troyed >> while executing >> "image create photo -data >> "R0lGODlhIAAgALP/AP///8DAwP8A/7+/v39/f38AfwD//wB/AAAA/ >> wAAfwAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAAEALAAAAAAgACAAAAT/kMhJq50h60yA/2Ao..." >> (in namespace eval "::help" script line 27) >> invoked from within >> "namespace eval help { >> variable w >> variable abort 0 >> variable showing 0 >> variable stat "" >> variable curfilename "" >> variable data >> variable history ""..." >> (file "/usr/local/grass-6.1.0/etc/help.tcl" line 61) >> invoked from within >> "source $env(GISBASE)/etc/help.tcl" >> (file "/usr/local/grass-6.1.0/etc/gis_set.tcl" line 38) >> /home/manganelll///.gislock: No such file or directory >> ERROR: /usr/local/grass-6.1.0/etc/lock: > > > Any hint would be welcome. The problem is actually with wish: $ wish Application initialization failed: this isn't a Tk applicationunknown color name "Black" So any tk application seems to fail with freenx. Best bet would be to ask on the the freenx-knx mailing list: https://mail.kde.org/mailman/listinfo/freenx-knx I would also be interested in the answer ;-) Moritz Moritz From grass-bugs at intevation.de Fri Sep 1 11:50:29 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Fri Sep 1 11:50:32 2006 Subject: [GRASS-dev] [bug #5083] (grass) v.clean tcl/tk dialog is too narrow Message-ID: <20060901095029.D2B891006C6@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5083 ------------------------------------------------------------------------- Subject: v.clean tcl/tk dialog is too narrow Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: 6.2_cvs_snapshot_08_31 By default v.clean tcl/tk dialog is too narrow to fit all "Cleaning tool:" options and - more important - no horizontal scrolling mechanism or hints about options outside window (invisible). Resizing window fixes problem. Other modules may also be affected, as it looks like bug in determining required window width (wrong container for selectable options?). Better would be if there was some line wrapping mechanism enabled if option list is wider than window. This bug exists in 6.1, 6.2 and 6.3. tcl/tk: 8.4.12 -------------------------------------------- Managed by Request Tracker From neteler at itc.it Fri Sep 1 12:43:08 2006 From: neteler at itc.it (Markus Neteler) Date: Fri Sep 1 12:43:10 2006 Subject: [GRASS-dev] Re: Grass 6.1 In-Reply-To: <44F7FDB0.2010304@club.worldonline.be> References: <20060901090126.GB12905@bartok.itc.it> <44F7FDB0.2010304@club.worldonline.be> Message-ID: <20060901104308.GF5866@bartok.itc.it> On Fri, Sep 01, 2006 at 11:30:24AM +0200, Moritz Lennert wrote: ... > The problem is actually with wish: > > $ wish > Application initialization failed: this isn't a Tk applicationunknown > color name "Black" > > So any tk application seems to fail with freenx. Best bet would be to > ask on the the freenx-knx mailing list: > > https://mail.kde.org/mailman/listinfo/freenx-knx > > I would also be interested in the answer ;-) I have posted the question there, let's see! thanks Markus From glynn at gclements.plus.com Fri Sep 1 17:59:16 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Sep 1 17:59:34 2006 Subject: [GRASS-dev] Re: [GRASS-user] [bug #3041] nviz max resolution ppm image dump In-Reply-To: <20060901173149.5b403a05.hamish_nospam@yahoo.com> References: <44F32EC1.7080908@fire.esd.ornl.gov> <20060829141340.7e01582d.hamish_nospam@yahoo.com> <44F3ABA0.4050200@fire.esd.ornl.gov> <20060829180608.72176063.hamish_nospam@yahoo.com> <1156852657.8124.9.camel@linuxmain.localhost> <20060830171428.76de4e89.hamish_nospam@yahoo.com> <17653.35468.666861.57261@cerise.gclements.plus.com> <20060831154810.287856fc.hamish_nospam@yahoo.com> <17654.56613.600780.723615@cerise.gclements.plus.com> <20060901151740.29b45429.hamish_nospam@yahoo.com> <17655.44557.390080.801898@cerise.gclements.plus.com> <20060901173149.5b403a05.hamish_nospam@yahoo.com> Message-ID: <17656.22740.864086.721594@cerise.gclements.plus.com> Hamish wrote: > > > > > With off-screen rendering disabled, I get good results with > > > > > either of the above var_i calculations. > > > > > > > > The off-screen rendering draws to the back-buffer, GS_write_zoom() > > > > dumps the front buffer. Also, Create_OS_Ctx() hides the Togl > > > > canvas (presumably to prevent expose events from trashing the > > > > OpenGL state during off-screen rendering), so it probably isn't > > > > usable for rendering. > > > > > > > > Does this help? > > > > > > > > diff -u -r2.6 do_zoom.c > > > > --- visualization/nviz/src/do_zoom.c 9 Jul 2006 08:58:40 -0000 2.6 > > > > +++ visualization/nviz/src/do_zoom.c 31 Aug 2006 12:58:16 -0000 > > > > @@ -325,6 +325,9 @@ > > > > } > > > > #endif > > > > > > > > + if (!pbuffer && !glxpixmap) > > > > + return 1; > > > > + > > > > /* hide togl canvas before init_ctx > > > > * This prevents bindings from re-initializing > > > > * togl */ > > > > > > Nope. No change. > > > > Did you try with GRASS_NO_GLX_{PBUFFERS,PIXMAPS} set? > > > > With those set, and the above patch, Create_OS_Ctx() should > > essentially be a no-op. > > > I didn't. I have now and it renders correctly; you see each panel being > rendered in the NVIZ window. > > i.e. : This works > + if (!pbuffer && !glxpixmap) > + return 1; > and > export GRASS_NO_GLX_PIXMAPS=TRUE > export GRASS_NO_GLX_PBUFFERS=TRUE > > > OR making this test always false makes it work: > > /* create off-screen context if possible */ > #if defined(OPENGL_X11) && (defined(HAVE_PBUFFERS) || defined(HAVE_PIXMAPS)) > > it fails with: (random bits of old windows in built panels) > + if (!pbuffer && !glxpixmap) > + return 1; > and > unset GRASS_NO_GLX_PIXMAPS > export GRASS_NO_GLX_PBUFFERS=TRUE > > > it fails with: (mostly black with some color stripes in built panels) > + if (!pbuffer && !glxpixmap) > + return 1; > and > export GRASS_NO_GLX_PIXMAPS=TRUE > unset GRASS_NO_GLX_PBUFFERS IOW, neither pBuffers nor GLX Pixmaps work. FWIW, they don't work for me either. The existing code (minus the patch) doesn't correctly handle the case where off-screen rendering is requested but both mechanisms fail (or are disabled by the environment variables). I'll commit the patch, so that disabling off-screen rendering at run time works. I could invert the sense of the tests, so that you have to specifically request it. However, that essentially guarantees that the off-screen rendering won't get any significant amount of testing. > > > Does max res PPM dump work for anybody? (ie is it a platform > > > dependent thing) > > > > > > Shall we disable offscreen rendering for the 6.2 release branch in > > > case it doesn't get fixed in time for release? > > > > It should suffice to ensure that it can be disabled at run time. > > or by packagers (say if it's broken for all MacOSX) There's no way of knowing that. Even if you tested it on every possible software/hardware combination currently available, you don't know whether it will start working with the next update. So long as might work for someone, and everyone for whom it doesn't work can effectively disable it, it should remain. The only valid reason for using compile-time tests is to prevent errors which cannot be prevented at run-time, i.e. loading errors due to the use of functions which may not exist on specific systems. -- Glynn Clements From glynn at gclements.plus.com Fri Sep 1 18:00:43 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Sep 1 18:00:44 2006 Subject: [GRASS-dev] Re: [bug #4905] (grass) gis.m: d.text.freetype does not allow spaces in text In-Reply-To: <20060901173634.51f7b73b.hamish_nospam@yahoo.com> References: <20060830151604.541d4f89.hamish_nospam@yahoo.com> <17653.37525.758455.944196@cerise.gclements.plus.com> <20060830174856.GC8438@localhost.tamu.edu> <17653.53497.833664.664895@cerise.gclements.plus.com> <20060830181307.GA43424@localhost.tamu.edu> <44F6F1CE.6080509@o2.pl> <20060901173634.51f7b73b.hamish_nospam@yahoo.com> Message-ID: <17656.22827.104106.597162@cerise.gclements.plus.com> Hamish wrote: > > >> Is there any reason why those features can't be added to d.text? > > > > > No, it's simply because nobody did it. Hopefully, I'll sometime. > > > > Would that let us drop d.text.freetype then? > > The module must remain until GRASS 7. Some people may have scripts/apps > that depend on it. Having said that, warnings can easily be added to the > help page etc letting users know there are better options. If can of > course be removed from the GUI (already has been AFAIK). If d.font/d.text are extended to provide the relevant functionality, d.text.freetype could probably be replaced with a script. -- Glynn Clements From rez at touchofmadness.com Fri Sep 1 18:01:53 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Fri Sep 1 18:02:12 2006 Subject: [GRASS-dev] v.in.ogr broken (\w shp) Message-ID: <1157126513.17352.65.camel@devel> Is there an easy fix for this? I'm trying to import a shapefile and I'm not terribly familiar with this part of the GRASS architecture. GRASS 6.3.cvs (hamilton):~/hamilton > v.in.ogr dsn=. output=roads layer=17 Projection of input dataset and current location appear to match. Proceeding with import... Layer: 17 DBMI-DBF driver error: Column 'ADMIN_CLAS' already exists (duplicate name) Cannot create table. Error in db_execute_immediate() ERROR: Cannot create table: create table roads (cat integer, PREFIX varchar ( 2 ), NAME varchar ( 30 ), TYPE varchar ( 4 ), SUFFIX varchar ( 2 ), FCC varchar ( 3 ), FIPS varchar ( 11 ), ID integer, FULL_NAME varchar ( 40 ), ADMIN_CLAS varchar ( 40 ), CATEGORY integer, ST_CNTY_FI varchar ( 11 ), RD_CLASS varchar ( 4 ), RTE_NUM1 varchar ( 4 ), RTE_NUM2 varchar ( 4 ), ADMIN_CLAS integer, AREA double precision, LEN double precision) GRASS 6.3.cvs (hamilton):~/hamilton > -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From dsampson at NRCan.gc.ca Fri Sep 1 18:55:16 2006 From: dsampson at NRCan.gc.ca (Sampson, David) Date: Fri Sep 1 18:55:23 2006 Subject: [GRASS-dev] GRASS PSC..... Next steps Message-ID: <2FAA57395C1F914DB27CAA4C376058F267EFA5@S0-OTT-X2.nrn.nrcan.gc.ca> Hey gang Ahhhh, the beginning of September is upon us. For those in my part of the world this meeans the days are getting shorter, nights are cooler and air conditioners can start being shut down. For many of the people on this list this also means you are getting a new load of students at your school... to you profs and teachers I bid you luck. September also brings some great new opportunities for the GRASS community and a step forward in the PSC process and following through on our commitment to some things OSGEO related. While I was away on vacation I received a few more confirmed nominations for the PSC. By the time I tallied it all up we came out with an even 10. This is great for many reasons. First it is a list of people who have been quite active in many things GRASS. Even if you have not seen them active on the mailing list they have helped progress the GRASS project, tie it in through education, develop ways to use grass with other software, build tutorials and many other contributions. Thanks to all those who accepted nominations. Furthermore I want to thank everyone who took the time to offer a nomination or cast a vote (in the early days at least). Without you we would not have a great list of members. Also I want to thank the GRASS community at large for helping me through the organization of the process over the past weeks. I received many e-mails sugesting how to make the process more open, stream lined, and democratic while respecting peoples wishes of their level of involvement. And of course thanks to Markus for starting the PSC process and providing the RFC materials that will help the PSC get started. So, The original plan was to now open the process of voting for your preffered nominees. What I propose is that 10 people is a good number and the general feel is that the GRASS community supports these nominations. I would like to propose that the GRASS PSC is formed from the 10 members listed bellow. Unless there are justified reasons from the GRASS community to do otherwise and we prefer to have a vote. Drop me a line privately if you wish and I will consider the voting stage if needed) So unless I am notified otherwise I would like to take this opportunity to formaly introduce the GRASS PSC consisting of the following members The GRASS Project Steering Committee (PSC) ================================== Dylan Baudette Michael Barton Maciej Sieczka Helena Mitasova Markus Neteler Scott Mitchell Massimiliano Cannata Brad Douglas Hamish Paul Kelly CONGRATS........ So what's next? It has been brought up many times that it is unclear exactly what the PSC was going to do. Well that is exactly what the PSC gets to work out, they are the egg that gets to create the chicken (or is that backwards?). But of course they are not thrown into the cage without anything to start with. So I propose the first steps of the GRASS PSC (after they have a chance to introduce themselves to each other and raise a virtual toast of course) might include 1. Take a look at the Mapserver PSC and examine some other examples as well (can't find the link) 2. Determine a main PSC representative that can bridge the PSC to OSGEO 3. Have someone that can be a point contact for users 4. have someone that can be a point contact for developers 5. Review original letters to the community http://grass.gdf-hannover.de/wiki/GRASS_Project_Steering_Commitee 6. Create/revise an RFC (Request for comment) for the GRASS community to consider 7. Update WIKI pages Throughout this process I am assuming the GRASS commuity will be able to offer additional support, feedback and ideas of how to address concerns and challenges. I wish you all good luck and I look forward to seeing the GRASS PSC move forward and following their progress. Cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060901/7b8a4227/attachment-0001.html From glynn at gclements.plus.com Fri Sep 1 19:12:15 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Sep 1 19:13:37 2006 Subject: [GRASS-dev] Re: [bug #4905] (grass) gis.m: d.text.freetype does not allow spaces in text In-Reply-To: <17655.512.892921.746949@cerise.gclements.plus.com> References: <20060830151604.541d4f89.hamish_nospam@yahoo.com> <17653.37525.758455.944196@cerise.gclements.plus.com> <20060830174856.GC8438@localhost.tamu.edu> <17653.53497.833664.664895@cerise.gclements.plus.com> <20060830181307.GA43424@localhost.tamu.edu> <44F6F1CE.6080509@o2.pl> <20060831150145.GB8640@localhost.tamu.edu> <17655.512.892921.746949@cerise.gclements.plus.com> Message-ID: <17656.27119.705966.637113@cerise.gclements.plus.com> Glynn Clements wrote: > > > >> Is there any reason why those features can't be added to d.text? > > > > > > > No, it's simply because nobody did it. Hopefully, I'll sometime. > > > > > > Would that let us drop d.text.freetype then? > > > > Yes. And I'm thinking about merging d.font and d.font.freetype, if > > feasible. > > I'd like to propose merging freetype and stroke fonts, so that > R_font() is used for both, with the type being detected automatically. > This would allow the use of FreeType fonts in all modules. By which, I didn't mean "go ahead and do it without discussing it with anyone, including the person who has done 95% of the recent work on the display architecture and will probably be doing a similar proportion of future work in that area". Patch reverted. Again. The right place to have done this would be lib/driver/Font.c. lib/raster is supposed to be the bare minimum needed to dispatch R_* calls to either the local or remote driver. All of the actual functionality is supposed to go into either lib/driver or the individual drivers (lib/pngdriver or display/drivers/XDRIVER). I'm currently testing the corresponding changes to lib/driver. -- Glynn Clements From grass4u at gmail.com Fri Sep 1 20:36:59 2006 From: grass4u at gmail.com (Huidae Cho) Date: Fri Sep 1 20:37:50 2006 Subject: [GRASS-dev] Re: [bug #4905] (grass) gis.m: d.text.freetype does not allow spaces in text In-Reply-To: <17656.27119.705966.637113@cerise.gclements.plus.com> References: <20060830151604.541d4f89.hamish_nospam@yahoo.com> <17653.37525.758455.944196@cerise.gclements.plus.com> <20060830174856.GC8438@localhost.tamu.edu> <17653.53497.833664.664895@cerise.gclements.plus.com> <20060830181307.GA43424@localhost.tamu.edu> <44F6F1CE.6080509@o2.pl> <20060831150145.GB8640@localhost.tamu.edu> <17655.512.892921.746949@cerise.gclements.plus.com> <17656.27119.705966.637113@cerise.gclements.plus.com> Message-ID: <20060901183040.GA6853@localhost> On Fri, Sep 01, 2006 at 06:12:15PM +0100, Glynn Clements wrote: > > Glynn Clements wrote: > > > > > >> Is there any reason why those features can't be added to d.text? > > > > > > > > > No, it's simply because nobody did it. Hopefully, I'll sometime. > > > > > > > > Would that let us drop d.text.freetype then? > > > > > > Yes. And I'm thinking about merging d.font and d.font.freetype, if > > > feasible. > > > > I'd like to propose merging freetype and stroke fonts, so that > > R_font() is used for both, with the type being detected automatically. > > This would allow the use of FreeType fonts in all modules. > > By which, I didn't mean "go ahead and do it without discussing it with > anyone, including the person who has done 95% of the recent work on > the display architecture and will probably be doing a similar > proportion of future work in that area". > > Patch reverted. Again. > > The right place to have done this would be lib/driver/Font.c. > > lib/raster is supposed to be the bare minimum needed to dispatch R_* > calls to either the local or remote driver. All of the actual > functionality is supposed to go into either lib/driver or the > individual drivers (lib/pngdriver or display/drivers/XDRIVER). > > I'm currently testing the corresponding changes to lib/driver. > Glynn, I see. Lessons learned. I didn't mean to bother you with this. Maybe, I forgot you have a better insight in the overall architecture of the raster library. I've reverted the changes that I made recently. One thing that I want to suggest is to replace freetypecap with something better. Keeping the font alias functionality is important for portable scripting because each system has different directory structure for TrueType fonts. But because of this, freetypecap is also different from system to system, which is annoying. One option could be to auto-generate freetypecap. While looking into lib/raster, I found something strange. select_font(), *_font_freetype(), *_charset(), and *_font_freetype_release() return 1 on success while the others return 0. Is this intended? Huidae From glynn at gclements.plus.com Fri Sep 1 21:45:05 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Sep 1 21:46:50 2006 Subject: [GRASS-dev] Re: [bug #4905] (grass) gis.m: d.text.freetype does not allow spaces in text In-Reply-To: <20060901183040.GA6853@localhost> References: <20060830151604.541d4f89.hamish_nospam@yahoo.com> <17653.37525.758455.944196@cerise.gclements.plus.com> <20060830174856.GC8438@localhost.tamu.edu> <17653.53497.833664.664895@cerise.gclements.plus.com> <20060830181307.GA43424@localhost.tamu.edu> <44F6F1CE.6080509@o2.pl> <20060831150145.GB8640@localhost.tamu.edu> <17655.512.892921.746949@cerise.gclements.plus.com> <17656.27119.705966.637113@cerise.gclements.plus.com> <20060901183040.GA6853@localhost> Message-ID: <17656.36289.837856.967927@cerise.gclements.plus.com> Huidae Cho wrote: > > > > > >> Is there any reason why those features can't be added to d.text? > > > > > > > > > > > No, it's simply because nobody did it. Hopefully, I'll sometime. > > > > > > > > > > Would that let us drop d.text.freetype then? > > > > > > > > Yes. And I'm thinking about merging d.font and d.font.freetype, if > > > > feasible. > > > > > > I'd like to propose merging freetype and stroke fonts, so that > > > R_font() is used for both, with the type being detected automatically. > > > This would allow the use of FreeType fonts in all modules. > > > > By which, I didn't mean "go ahead and do it without discussing it with > > anyone, including the person who has done 95% of the recent work on > > the display architecture and will probably be doing a similar > > proportion of future work in that area". > > > > Patch reverted. Again. > > > > The right place to have done this would be lib/driver/Font.c. > > > > lib/raster is supposed to be the bare minimum needed to dispatch R_* > > calls to either the local or remote driver. All of the actual > > functionality is supposed to go into either lib/driver or the > > individual drivers (lib/pngdriver or display/drivers/XDRIVER). > > > > I'm currently testing the corresponding changes to lib/driver. > > Glynn, I see. Lessons learned. I didn't mean to bother you with this. > Maybe, I forgot you have a better insight in the overall architecture of > the raster library. I've reverted the changes that I made recently. I've now made corresponding changes to lib/driver/Font.c. COM_Font_get (which is where R_font() always ends up, one way or another) accepts either names or full paths. For full paths, if the path begins with $GISBASE/fonts, it's treated as a stroke font, otherwise a FreeType font (it's unlikely that anyone will have any suitable stroke fonts which aren't part of GRASS). COM_Font_freetype_release() is now a no-op. Unless some reason is found why that needs to remain (and which isn't essentially a bug elsewhere), it (and its corresponding infrastructure) can be removed. Once the merged R_font() has had sufficient testing, R_font_freetype() and its infrastructure can also be removed. I've also re-instated the updated behaviour of d.font, so that it will accept either type of font for both font= and path=. I also fixed a bug (missing NUL-terminator; memory returned from G_{malloc,realloc} isn't guaranteed to be zeroed). > One thing that I want to suggest is to replace freetypecap with > something better. Keeping the font alias functionality is important for > portable scripting because each system has different directory structure > for TrueType fonts. Agreed. > But because of this, freetypecap is also different > from system to system, which is annoying. One option could be > to auto-generate freetypecap. Easier said than done. There isn't any automatic way to figure out where fonts live. The X server just uses the FontPath settings from xorg.conf (formerly XF86Config); on my system (Gentoo), they're in /usr/share/fonts (although there is a symlink from /usr/lib/X11/fonts to ../../share/fonts). Currently, the freetypecap file is still coming from the display/d.text.freetype directory, although it can be moved to lib/driver if necessary. > While looking into lib/raster, I found something strange. > select_font(), *_font_freetype(), *_charset(), and > *_font_freetype_release() return 1 on success while the others return 0. > Is this intended? Sort of, probably. By which, I mean that there was probably some rationale for the original behaviour. In the past, I've just preserved the behaviour whenever I have updated anything. Although almost nothing actually tests the status of most R_* functions, actually checking for any exceptions is too much work for too little gain. However, I did make one change in this area (to a function not used outside of lib/driver): font_is_freetype() now returns 1/0, so that "if (font_is_freetype(...)) ..." behaves as it reads. Generally speaking, functions which are explicitly intended to test some property should return 1/0. It's success/failure status returns which are ambiguous. Programs return 0 for success, non-zero for failure, although the shell reflects this in the way that "if", "||", "&&" etc are handled (i.e. a zero exit code represents "true"). System calls normally return negative values for failure, as calls which also return useful information (descriptor, PID, etc) normally return non-negative values (descriptors, UIDs, PIDs etc are never negative, although some can be zero). graphics.h defines OK as 0, with positive values used for errors. Most graphics operations don't actually return any status. The only R_* functions whose return value actually reflects a status code from the driver are: R_open_driver R_color_table_float R_color_table_fixed R_font R_font_freetype R_charset R_font_freetype_release [R_screen_* return a value, not status (they can't fail), while R_get_num_colors and R_get_location_with_* store the values via pointers which are passed as arguments.] Of the above, R_open_driver is probably the only case where programs generally bother to check the value. Actually, there's no "probably"; I've just checked, and everything which uses one of the above font/colour-table functions ignores the return code. Also, only two programs (d.text.freetype and i.class) use R_color_table_fixed. As nothing uses R_color_table_float (d.colormode isn't present in 6.x), and the driver starts in fixed mode, both of those functions are redundant. In that case: 1. I intend to remove the status returns from all R_* functions except for R_open_driver. 2. Unless someone objects, I also intend to remove R_color_table_* and their associated infrastructure, including all of the driver code related to floating colour mode. That will remove a significant chunk of the complexity of the display architecture, and make it significantly easier to understand. -- Glynn Clements From grass4u at gmail.com Fri Sep 1 22:55:26 2006 From: grass4u at gmail.com (Huidae Cho) Date: Fri Sep 1 22:56:06 2006 Subject: [GRASS-dev] Re: [bug #4905] (grass) gis.m: d.text.freetype does not allow spaces in text In-Reply-To: <17656.36289.837856.967927@cerise.gclements.plus.com> References: <17653.37525.758455.944196@cerise.gclements.plus.com> <20060830174856.GC8438@localhost.tamu.edu> <17653.53497.833664.664895@cerise.gclements.plus.com> <20060830181307.GA43424@localhost.tamu.edu> <44F6F1CE.6080509@o2.pl> <20060831150145.GB8640@localhost.tamu.edu> <17655.512.892921.746949@cerise.gclements.plus.com> <17656.27119.705966.637113@cerise.gclements.plus.com> <20060901183040.GA6853@localhost> <17656.36289.837856.967927@cerise.gclements.plus.com> Message-ID: <20060901205526.GA1043@localhost.tamu.edu> Removing the font_hold variable from lib/driver affects the behaviour of freetype fonts. All modules with font= option still assume "romans" as default font and it keeps the user from using freetype fonts with them. d.font font=luximr d.vect map=vector_map will use "romans" not "luximr". Maybe we need to use GRASS_FT_* GRASS_FONT varibles to let d.* modules know the default font the user wants. Adding R_get_font_list() would be great. Its code can be simply cut and pasted from d.font. Huidae On Fri, Sep 01, 2006 at 08:45:05PM +0100, Glynn Clements wrote: > > Huidae Cho wrote: > > > > > > > >> Is there any reason why those features can't be added to d.text? > > > > > > > > > > > > > No, it's simply because nobody did it. Hopefully, I'll sometime. > > > > > > > > > > > > Would that let us drop d.text.freetype then? > > > > > > > > > > Yes. And I'm thinking about merging d.font and d.font.freetype, if > > > > > feasible. > > > > > > > > I'd like to propose merging freetype and stroke fonts, so that > > > > R_font() is used for both, with the type being detected automatically. > > > > This would allow the use of FreeType fonts in all modules. > > > > > > By which, I didn't mean "go ahead and do it without discussing it with > > > anyone, including the person who has done 95% of the recent work on > > > the display architecture and will probably be doing a similar > > > proportion of future work in that area". > > > > > > Patch reverted. Again. > > > > > > The right place to have done this would be lib/driver/Font.c. > > > > > > lib/raster is supposed to be the bare minimum needed to dispatch R_* > > > calls to either the local or remote driver. All of the actual > > > functionality is supposed to go into either lib/driver or the > > > individual drivers (lib/pngdriver or display/drivers/XDRIVER). > > > > > > I'm currently testing the corresponding changes to lib/driver. > > > > Glynn, I see. Lessons learned. I didn't mean to bother you with this. > > Maybe, I forgot you have a better insight in the overall architecture of > > the raster library. I've reverted the changes that I made recently. > > I've now made corresponding changes to lib/driver/Font.c. > > COM_Font_get (which is where R_font() always ends up, one way or > another) accepts either names or full paths. For full paths, if the > path begins with $GISBASE/fonts, it's treated as a stroke font, > otherwise a FreeType font (it's unlikely that anyone will have any > suitable stroke fonts which aren't part of GRASS). > > COM_Font_freetype_release() is now a no-op. Unless some reason is > found why that needs to remain (and which isn't essentially a bug > elsewhere), it (and its corresponding infrastructure) can be removed. > > Once the merged R_font() has had sufficient testing, R_font_freetype() > and its infrastructure can also be removed. > > I've also re-instated the updated behaviour of d.font, so that it will > accept either type of font for both font= and path=. I also fixed a > bug (missing NUL-terminator; memory returned from G_{malloc,realloc} > isn't guaranteed to be zeroed). > > > One thing that I want to suggest is to replace freetypecap with > > something better. Keeping the font alias functionality is important for > > portable scripting because each system has different directory structure > > for TrueType fonts. > > Agreed. > > > But because of this, freetypecap is also different > > from system to system, which is annoying. One option could be > > to auto-generate freetypecap. > > Easier said than done. There isn't any automatic way to figure out > where fonts live. The X server just uses the FontPath settings from > xorg.conf (formerly XF86Config); on my system (Gentoo), they're in > /usr/share/fonts (although there is a symlink from /usr/lib/X11/fonts > to ../../share/fonts). > > Currently, the freetypecap file is still coming from the > display/d.text.freetype directory, although it can be moved to > lib/driver if necessary. > > > While looking into lib/raster, I found something strange. > > select_font(), *_font_freetype(), *_charset(), and > > *_font_freetype_release() return 1 on success while the others return 0. > > Is this intended? > > Sort of, probably. By which, I mean that there was probably some > rationale for the original behaviour. > > In the past, I've just preserved the behaviour whenever I have updated > anything. Although almost nothing actually tests the status of most > R_* functions, actually checking for any exceptions is too much work > for too little gain. > > However, I did make one change in this area (to a function not used > outside of lib/driver): font_is_freetype() now returns 1/0, so that > "if (font_is_freetype(...)) ..." behaves as it reads. Generally > speaking, functions which are explicitly intended to test some > property should return 1/0. > > It's success/failure status returns which are ambiguous. > > Programs return 0 for success, non-zero for failure, although the > shell reflects this in the way that "if", "||", "&&" etc are handled > (i.e. a zero exit code represents "true"). > > System calls normally return negative values for failure, as calls > which also return useful information (descriptor, PID, etc) normally > return non-negative values (descriptors, UIDs, PIDs etc are never > negative, although some can be zero). > > graphics.h defines OK as 0, with positive values used for errors. > > Most graphics operations don't actually return any status. The only > R_* functions whose return value actually reflects a status code from > the driver are: > > R_open_driver > > R_color_table_float > R_color_table_fixed > > R_font > R_font_freetype > R_charset > R_font_freetype_release > > [R_screen_* return a value, not status (they can't fail), while > R_get_num_colors and R_get_location_with_* store the values via > pointers which are passed as arguments.] > > Of the above, R_open_driver is probably the only case where programs > generally bother to check the value. > > Actually, there's no "probably"; I've just checked, and everything > which uses one of the above font/colour-table functions ignores the > return code. > > Also, only two programs (d.text.freetype and i.class) use > R_color_table_fixed. As nothing uses R_color_table_float (d.colormode > isn't present in 6.x), and the driver starts in fixed mode, both of > those functions are redundant. > > In that case: > > 1. I intend to remove the status returns from all R_* functions except > for R_open_driver. > > 2. Unless someone objects, I also intend to remove R_color_table_* and > their associated infrastructure, including all of the driver code > related to floating colour mode. That will remove a significant chunk > of the complexity of the display architecture, and make it > significantly easier to understand. > > -- > Glynn Clements From glynn at gclements.plus.com Fri Sep 1 23:25:23 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Sep 1 23:30:15 2006 Subject: [GRASS-dev] Re: [bug #4905] (grass) gis.m: d.text.freetype does not allow spaces in text In-Reply-To: <20060901205526.GA1043@localhost.tamu.edu> References: <17653.37525.758455.944196@cerise.gclements.plus.com> <20060830174856.GC8438@localhost.tamu.edu> <17653.53497.833664.664895@cerise.gclements.plus.com> <20060830181307.GA43424@localhost.tamu.edu> <44F6F1CE.6080509@o2.pl> <20060831150145.GB8640@localhost.tamu.edu> <17655.512.892921.746949@cerise.gclements.plus.com> <17656.27119.705966.637113@cerise.gclements.plus.com> <20060901183040.GA6853@localhost> <17656.36289.837856.967927@cerise.gclements.plus.com> <20060901205526.GA1043@localhost.tamu.edu> Message-ID: <17656.42307.375154.246397@cerise.gclements.plus.com> Huidae Cho wrote: > Removing the font_hold variable from lib/driver affects the behaviour of > freetype fonts. All modules with font= option still assume "romans" as > default font and it keeps the user from using freetype fonts with them. > > d.font font=luximr > d.vect map=vector_map > > will use "romans" not "luximr". Maybe we need to use GRASS_FT_* > GRASS_FONT varibles to let d.* modules know the default font the user > wants. That's a bug in the module. If the user doesn't explicitly specify a font, the module should use the current font, not some arbitrary default. Especially as any setting which the module makes will persist for subsequent modules. If you can identify specific modules which behave this way, I'll fix them (starting with d.vect). > Adding R_get_font_list() would be great. Its code can be simply cut and > pasted from d.font. I'm not sure that's a good idea. If we were to replace freetype with a font path, the list could become huge (my WinXP system has 120 .ttf files in C:/WINDOWS/Fonts, and that's just what comes with the OS or with other packages which I've installed; I haven't explicitly installed any additional fonts). Instead, I'd suggest just removing the ->options field. -- Glynn Clements From grass4u at gmail.com Fri Sep 1 23:40:57 2006 From: grass4u at gmail.com (Huidae Cho) Date: Fri Sep 1 23:41:35 2006 Subject: [GRASS-dev] Re: [bug #4905] (grass) gis.m: d.text.freetype does not allow spaces in text In-Reply-To: <17656.42307.375154.246397@cerise.gclements.plus.com> References: <17653.53497.833664.664895@cerise.gclements.plus.com> <20060830181307.GA43424@localhost.tamu.edu> <44F6F1CE.6080509@o2.pl> <20060831150145.GB8640@localhost.tamu.edu> <17655.512.892921.746949@cerise.gclements.plus.com> <17656.27119.705966.637113@cerise.gclements.plus.com> <20060901183040.GA6853@localhost> <17656.36289.837856.967927@cerise.gclements.plus.com> <20060901205526.GA1043@localhost.tamu.edu> <17656.42307.375154.246397@cerise.gclements.plus.com> Message-ID: <20060901214057.GA44051@localhost.tamu.edu> On Fri, Sep 01, 2006 at 10:25:23PM +0100, Glynn Clements wrote: > > Huidae Cho wrote: > > > Removing the font_hold variable from lib/driver affects the behaviour of > > freetype fonts. All modules with font= option still assume "romans" as > > default font and it keeps the user from using freetype fonts with them. > > > > d.font font=luximr > > d.vect map=vector_map > > > > will use "romans" not "luximr". Maybe we need to use GRASS_FT_* > > GRASS_FONT varibles to let d.* modules know the default font the user > > wants. > > That's a bug in the module. If the user doesn't explicitly specify a > font, the module should use the current font, not some arbitrary > default. Especially as any setting which the module makes will persist > for subsequent modules. > > If you can identify specific modules which behave this way, I'll fix > them (starting with d.vect). > > > Adding R_get_font_list() would be great. Its code can be simply cut and > > pasted from d.font. > > I'm not sure that's a good idea. If we were to replace freetype with a > font path, the list could become huge (my WinXP system has 120 .ttf > files in C:/WINDOWS/Fonts, and that's just what comes with the OS or > with other packages which I've installed; I haven't explicitly > installed any additional fonts). I didn't mean to list all fonts in the system. Instead, showing the list of freetypecap fonts and stroke fonts will be enough like d.font does. > > Instead, I'd suggest just removing the ->options field. Yes, it's sometimes annoying, sometimes useful. Having separate font= and path= options looks ugly. Huidae From michael.barton at asu.edu Sat Sep 2 00:02:18 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sat Sep 2 00:02:31 2006 Subject: [GRASS-dev] r.univar -e In-Reply-To: Message-ID: Hoorah! Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Martin Landa > Date: Thu, 31 Aug 2006 09:42:00 +0200 > To: grass-dev > Subject: [GRASS-dev] r.univar -e > > Hi all, > > I have added '-e' flag to r.univar according to r.univar.sh. See the > attached patch. Please look at the code, any comments welcomed... > (before committing to CVS - if desired...). > > Best, Martin > > GRASS 6.3.cvs (spearfish60):~ > r.univar help > > Description: > Calculates univariate statistics from the non-null cells of a raster map. > > Keywords: > raster, statistics > > Usage: > r.univar [-qge] map=name [percentile=value] > > Flags: > -q Quiet mode > -g Print the stats in shell script style > -e Calculate extended statistics (quartiles and percentile) > > Parameters: > map Name of input raster map > percentile Percentile to calculate (requires -e flag) > default: 90 > > Just simple test: > > * for DCELL: > GRASS 6.3.cvs (spearfish60):~ > g.region rast=elevation.10m;r.univar > elevation.10m -e > 100% > total null and non-null cells: 2654802 > total null cells : 0 > > Of the non-null cells: > ---------------------- > Number of cells (excluding NULL cells): 2654802 > Minimum : 1061.06 > Maximum : 1846.74 > Range : 785.679 > Arithmetic mean : 1348.37 > Arithmetic mean of absolute values : 1348.37 > Standard deviation : 175.494 > Variance : 30798.3 > Variation coefficient : 13.0153 % > Sum : 3579659211.6848597527 > 1st Quartile : 1196.8 > Median (even number of cells) : 1309.37 > 3st Quartile : 1480.29 > 90 Percentile : 1613.6 > > * for FCELL: > GRASS 6.3.cvs (spearfish60):~ > g.region rast=slope;r.univar slope -e > 100% > total null and non-null cells: 303052 > total null cells : 12929 > > Of the non-null cells: > ---------------------- > Number of cells (excluding NULL cells): 290123 > Minimum : 0 > Maximum : 52.5202 > Range : 52.5202 > Arithmetic mean : 11.5277 > Arithmetic mean of absolute values : 11.5277 > Standard deviation : 7.64516 > Variance : 58.4484 > Variation coefficient : 66.3198 % > Sum : 3344457.5523851216 > 1st Quartile : 5.38598 > Median (odd number of cells) : 9.97027 > 3st Quartile : 16.3104 > 90 Percentile : 22.4337 > > * for CELL: > GRASS 6.3.cvs (spearfish60):~ > g.region rast=roads;r.univar roads -e > 100% > total null and non-null cells: 302418 > total null cells : 291124 > > Of the non-null cells: > ---------------------- > Number of cells (excluding NULL cells): 11294 > Minimum : 1 > Maximum : 5 > Range : 4 > Arithmetic mean : 3.8091 > Arithmetic mean of absolute values : 3.8091 > Standard deviation : 1.29705 > Variance : 1.68235 > Variation coefficient : 34.0514 % > Sum : 43020 > 1st Quartile : 3 > Median (even number of cells) : 4 > 3st Quartile : 5 > 90 Percentile : 5 > > -- > Martin Landa * http://gama.fsv.cvut.cz/~landa * From glynn at gclements.plus.com Sat Sep 2 00:57:19 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Sep 2 01:01:36 2006 Subject: [GRASS-dev] Re: [bug #4905] (grass) gis.m: d.text.freetype does not allow spaces in text In-Reply-To: <20060901214057.GA44051@localhost.tamu.edu> References: <17653.53497.833664.664895@cerise.gclements.plus.com> <20060830181307.GA43424@localhost.tamu.edu> <44F6F1CE.6080509@o2.pl> <20060831150145.GB8640@localhost.tamu.edu> <17655.512.892921.746949@cerise.gclements.plus.com> <17656.27119.705966.637113@cerise.gclements.plus.com> <20060901183040.GA6853@localhost> <17656.36289.837856.967927@cerise.gclements.plus.com> <20060901205526.GA1043@localhost.tamu.edu> <17656.42307.375154.246397@cerise.gclements.plus.com> <20060901214057.GA44051@localhost.tamu.edu> Message-ID: <17656.47823.813402.1887@cerise.gclements.plus.com> Huidae Cho wrote: > > > Removing the font_hold variable from lib/driver affects the behaviour of > > > freetype fonts. All modules with font= option still assume "romans" as > > > default font and it keeps the user from using freetype fonts with them. > > > > > > d.font font=luximr > > > d.vect map=vector_map > > > > > > will use "romans" not "luximr". Maybe we need to use GRASS_FT_* > > > GRASS_FONT varibles to let d.* modules know the default font the user > > > wants. > > > > That's a bug in the module. If the user doesn't explicitly specify a > > font, the module should use the current font, not some arbitrary > > default. Especially as any setting which the module makes will persist > > for subsequent modules. > > > > If you can identify specific modules which behave this way, I'll fix > > them (starting with d.vect). > > > > > Adding R_get_font_list() would be great. Its code can be simply cut and > > > pasted from d.font. > > > > I'm not sure that's a good idea. If we were to replace freetype with a > > font path, the list could become huge (my WinXP system has 120 .ttf > > files in C:/WINDOWS/Fonts, and that's just what comes with the OS or > > with other packages which I've installed; I haven't explicitly > > installed any additional fonts). > > I didn't mean to list all fonts in the system. Instead, showing the list > of freetypecap fonts and stroke fonts will be enough like d.font does. If we eliminate the need to explicitly specify individual fonts in the freetypecap file (which is desirable, IMHO) in favour of e.g. a font path, then the list of available fonts will typically be all of the FreeType fonts on the system. Or, to look at it from a different perspective, I don't want to make it so that we can't do: for dir in $fontdirs ; do \ ls "$dir" | \ fgrep .ttf | \ awk -vdir=$dir '{sub("\\.ttf$","") ; print $0":"dir"/"$0".ttf:iso-8859-1:" }' ; \ done > $GISBASE/etc/freetypecap I don't particularly want to add an R_font_list(), change all of the relevant modules to use it, then have to remove it because it's causing huge option lists (or, alternatively, create a situation where we cannot remove the freetypecap requirement solely because of the effect upon the size of option lists). -- Glynn Clements From grass4u at gmail.com Sat Sep 2 01:25:21 2006 From: grass4u at gmail.com (Huidae Cho) Date: Sat Sep 2 01:26:00 2006 Subject: [GRASS-dev] Re: [bug #4905] (grass) gis.m: d.text.freetype does not allow spaces in text In-Reply-To: <17656.47823.813402.1887@cerise.gclements.plus.com> References: <44F6F1CE.6080509@o2.pl> <20060831150145.GB8640@localhost.tamu.edu> <17655.512.892921.746949@cerise.gclements.plus.com> <17656.27119.705966.637113@cerise.gclements.plus.com> <20060901183040.GA6853@localhost> <17656.36289.837856.967927@cerise.gclements.plus.com> <20060901205526.GA1043@localhost.tamu.edu> <17656.42307.375154.246397@cerise.gclements.plus.com> <20060901214057.GA44051@localhost.tamu.edu> <17656.47823.813402.1887@cerise.gclements.plus.com> Message-ID: <20060901232521.GA65061@localhost.tamu.edu> On Fri, Sep 01, 2006 at 11:57:19PM +0100, Glynn Clements wrote: > > Huidae Cho wrote: > > > > > Removing the font_hold variable from lib/driver affects the behaviour of > > > > freetype fonts. All modules with font= option still assume "romans" as > > > > default font and it keeps the user from using freetype fonts with them. > > > > > > > > d.font font=luximr > > > > d.vect map=vector_map > > > > > > > > will use "romans" not "luximr". Maybe we need to use GRASS_FT_* > > > > GRASS_FONT varibles to let d.* modules know the default font the user > > > > wants. > > > > > > That's a bug in the module. If the user doesn't explicitly specify a > > > font, the module should use the current font, not some arbitrary > > > default. Especially as any setting which the module makes will persist > > > for subsequent modules. > > > > > > If you can identify specific modules which behave this way, I'll fix > > > them (starting with d.vect). > > > > > > > Adding R_get_font_list() would be great. Its code can be simply cut and > > > > pasted from d.font. > > > > > > I'm not sure that's a good idea. If we were to replace freetype with a > > > font path, the list could become huge (my WinXP system has 120 .ttf > > > files in C:/WINDOWS/Fonts, and that's just what comes with the OS or > > > with other packages which I've installed; I haven't explicitly > > > installed any additional fonts). > > > > I didn't mean to list all fonts in the system. Instead, showing the list > > of freetypecap fonts and stroke fonts will be enough like d.font does. > > If we eliminate the need to explicitly specify individual fonts in the > freetypecap file (which is desirable, IMHO) in favour of e.g. a font > path, then the list of available fonts will typically be all of the > FreeType fonts on the system. Then we may need a flag like -l to see font aliases since no one can remember all the font names. > > Or, to look at it from a different perspective, I don't want to make > it so that we can't do: > > for dir in $fontdirs ; do \ > ls "$dir" | \ > fgrep .ttf | \ > awk -vdir=$dir '{sub("\\.ttf$","") ; print $0":"dir"/"$0".ttf:iso-8859-1:" }' ; \ > done > $GISBASE/etc/freetypecap Do we really need the charset field in freetypecap? AFAIK, TrueType font itself is not tied to any specific encoding. Charset has to do with the terminal or input method in use and the display driver converts to Unicode for TrueType fonts. For example, I can use one TrueType font for UTF-8 and EUC-KR charsets. iso-8859-1 fonts cannot be used with CJK fonts, of course, but this is because the font files do not have corresponding glyphs not because of their native encoding. Huidae From glynn at gclements.plus.com Sat Sep 2 02:03:05 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Sep 2 02:04:17 2006 Subject: [GRASS-dev] Re: [bug #4905] (grass) gis.m: d.text.freetype does not allow spaces in text In-Reply-To: <20060901232521.GA65061@localhost.tamu.edu> References: <44F6F1CE.6080509@o2.pl> <20060831150145.GB8640@localhost.tamu.edu> <17655.512.892921.746949@cerise.gclements.plus.com> <17656.27119.705966.637113@cerise.gclements.plus.com> <20060901183040.GA6853@localhost> <17656.36289.837856.967927@cerise.gclements.plus.com> <20060901205526.GA1043@localhost.tamu.edu> <17656.42307.375154.246397@cerise.gclements.plus.com> <20060901214057.GA44051@localhost.tamu.edu> <17656.47823.813402.1887@cerise.gclements.plus.com> <20060901232521.GA65061@localhost.tamu.edu> Message-ID: <17656.51769.868835.800662@cerise.gclements.plus.com> Huidae Cho wrote: > Do we really need the charset field in freetypecap? It's not essential. AIUI, the original purpose was so that you could just use font= to specify both a font and an encoding. But then, freetypecap originally contained a lot of other fields, e.g. size and colour, so the font= option really specified a complete "style". -- Glynn Clements From grass4u at gmail.com Sat Sep 2 03:05:19 2006 From: grass4u at gmail.com (Huidae Cho) Date: Sat Sep 2 03:05:57 2006 Subject: [GRASS-dev] Re: [bug #4905] (grass) gis.m: d.text.freetype does not allow spaces in text In-Reply-To: <17656.51769.868835.800662@cerise.gclements.plus.com> References: <17655.512.892921.746949@cerise.gclements.plus.com> <17656.27119.705966.637113@cerise.gclements.plus.com> <20060901183040.GA6853@localhost> <17656.36289.837856.967927@cerise.gclements.plus.com> <20060901205526.GA1043@localhost.tamu.edu> <17656.42307.375154.246397@cerise.gclements.plus.com> <20060901214057.GA44051@localhost.tamu.edu> <17656.47823.813402.1887@cerise.gclements.plus.com> <20060901232521.GA65061@localhost.tamu.edu> <17656.51769.868835.800662@cerise.gclements.plus.com> Message-ID: <20060902010519.GA88878@localhost.tamu.edu> On Sat, Sep 02, 2006 at 01:03:05AM +0100, Glynn Clements wrote: > > Huidae Cho wrote: > > > Do we really need the charset field in freetypecap? > > It's not essential. > > AIUI, the original purpose was so that you could just use font= > to specify both a font and an encoding. But then, freetypecap > originally contained a lot of other fields, e.g. size and colour, so > the font= option really specified a complete "style". Right, that's why I removed all those settings. As I know, charset does not need to be changed during one session or even in one's system as long as they do not change their encodings such as LC_CTYPE. Why would one want to use character sets other than their terminal's encoding (LC_CTYPE)? That being said, maybe, we can drop charset= option and, instead, use the GRASS_FT_ENCODING environment variable. Huidae From glynn at gclements.plus.com Sat Sep 2 07:53:50 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Sep 2 07:54:00 2006 Subject: [GRASS-dev] Re: [bug #4905] (grass) gis.m: d.text.freetype does not allow spaces in text In-Reply-To: <20060902010519.GA88878@localhost.tamu.edu> References: <17655.512.892921.746949@cerise.gclements.plus.com> <17656.27119.705966.637113@cerise.gclements.plus.com> <20060901183040.GA6853@localhost> <17656.36289.837856.967927@cerise.gclements.plus.com> <20060901205526.GA1043@localhost.tamu.edu> <17656.42307.375154.246397@cerise.gclements.plus.com> <20060901214057.GA44051@localhost.tamu.edu> <17656.47823.813402.1887@cerise.gclements.plus.com> <20060901232521.GA65061@localhost.tamu.edu> <17656.51769.868835.800662@cerise.gclements.plus.com> <20060902010519.GA88878@localhost.tamu.edu> Message-ID: <17657.7278.485016.663280@cerise.gclements.plus.com> Huidae Cho wrote: > > > Do we really need the charset field in freetypecap? > > > > It's not essential. > > > > AIUI, the original purpose was so that you could just use font= > > to specify both a font and an encoding. But then, freetypecap > > originally contained a lot of other fields, e.g. size and colour, so > > the font= option really specified a complete "style". > > Right, that's why I removed all those settings. As I know, charset does > not need to be changed during one session or even in one's system as > long as they do not change their encodings such as LC_CTYPE. Why would > one want to use character sets other than their terminal's encoding > (LC_CTYPE)? The text may come from a file which uses a different encoding. In some cases, it may contain characters which cannot be represented in the locale's encoding. > That being said, maybe, we can drop charset= option and, > instead, use the GRASS_FT_ENCODING environment variable. Note that $GRASS_FONT, $GRASS_FT_FONT and $GRASS_FT_ENCODING are currently only used for immediate rendering, where d.font[.freetype] won't work (every d.* command is self-contained; the actions performed by one command cannot affect subsequent commands). -- Glynn Clements From grass4u at gmail.com Sat Sep 2 08:32:19 2006 From: grass4u at gmail.com (Huidae Cho) Date: Sat Sep 2 08:33:02 2006 Subject: [GRASS-dev] gis.m patch Message-ID: <20060902063219.GA78577@localhost.tamu.edu> Hi, I've patched gis.m so that it can run on Windows natively with the help of direct rendering. PDCurses lets the user to start in text mode, but since there are no monitors available, gis.m is the only option for now. http://geni.ath.cx/grass/native_wingrass.png shows gis.m running on MS-Windows (not Cygwin). Huidae GRASS is now configured for: i686-pc-mingw32 Source directory: /home/song/usr/grass/grass6 Build directory: /home/song/usr/grass/grass6 Installation directory: /usr/local/grass-6.3.cvs Startup script in directory: ${exec_prefix}/bin C compiler: gcc -g -O2 -D__W98__ C++ compiler: c++ -g -O2 FORTRAN compiler: Building shared libraries: yes 64bit support: no OpenGL platform: Windows NVIZ: yes BLAS support: no C++ support: yes DWG support: no FFMPEG support: no FFTW support: yes FreeType support: yes GDAL support: yes GLw support: no JPEG support: yes LAPACK support: no Large File Support (LFS): no Motif support: no MySQL support: no NLS support: no ODBC support: no OGR support: yes OpenGL support: yes PNG support: yes PostgreSQL support: yes Python support: no Readline support: yes SQLite support: yes Tcl/Tk support: yes TIFF support: yes X11 support: yes Index: gui/tcltk/gis.m/gm.tcl =================================================================== RCS file: /grassrepository/grass6/gui/tcltk/gis.m/gm.tcl,v retrieving revision 1.25 diff -u -r1.25 gm.tcl --- gui/tcltk/gis.m/gm.tcl 24 Aug 2006 18:04:57 -0000 1.25 +++ gui/tcltk/gis.m/gm.tcl 2 Sep 2006 06:00:41 -0000 @@ -69,6 +69,12 @@ set execom "spawn" } +if {[info exists env(MSYSCON)]} { + set mingw "1" +} { + set mingw "0" +} + #fetch GRASS Version number: set fp [open $env(GISBASE)/etc/VERSIONNUMBER r] set GRASSVERSION [read -nonewline $fp] @@ -188,7 +194,13 @@ # Determine if an element already exists proc Gm::element_exists {elem name} { - set failure [catch {exec [list "|g.findfile" "element=$elem" "file=$name"] >& /dev/null}] + global mingw + + if { $mingw == "1" } { + set failure [catch {exec [list "|g.findfile" "element=$elem" "file=$name"] >& nul}] + } { + set failure [catch {exec [list "|g.findfile" "element=$elem" "file=$name"] >& /dev/null}] + } return [expr {! $failure}] } Index: gui/tcltk/gis.m/gmmenu.tcl =================================================================== RCS file: /grassrepository/grass6/gui/tcltk/gis.m/gmmenu.tcl,v retrieving revision 1.15 diff -u -r1.15 gmmenu.tcl --- gui/tcltk/gis.m/gmmenu.tcl 20 Jul 2006 17:43:19 -0000 1.15 +++ gui/tcltk/gis.m/gmmenu.tcl 2 Sep 2006 06:00:41 -0000 @@ -19,6 +19,7 @@ global mon global filename global env +global mingw # Put this at the top of the file menu. set GuiMenu::Menu_File_Top [subst { @@ -48,10 +49,20 @@ lappend descmenu all lappend descmenu options lappend descmenu $tmenu -lappend descmenu [subst { - {command {[G_msg "GRASS help"]} {} "g.manual" {} -command { exec g.manual -i > /dev/null & } } - {command {[G_msg "GIS Manager &help"]} {} {[G_msg "GIS Manager help"]} {} -command { exec g.manual gis.m > /dev/null & } } - {command {[G_msg "About &GRASS"]} {} {[G_msg "About GRASS"]} {} -command { source $env(GISBASE)/etc/gm/grassabout.tcl} } - {command {[G_msg "About &System"]} {} {[G_msg "About System"]} {} -command { exec $env(GRASS_WISH) $env(GISBASE)/etc/gm/tksys.tcl --tcltk & }} - }] +# MinGW +if { $mingw == "1" } { + lappend descmenu [subst { + {command {[G_msg "GRASS help"]} {} "g.manual" {} -command { exec g.manual -i >& nul } } + {command {[G_msg "GIS Manager &help"]} {} {[G_msg "GIS Manager help"]} {} -command { exec g.manual gis.m >& nul } } + {command {[G_msg "About &GRASS"]} {} {[G_msg "About GRASS"]} {} -command { source $env(GISBASE)/etc/gm/grassabout.tcl} } + {command {[G_msg "About &System"]} {} {[G_msg "About System"]} {} -command { exec $env(GRASS_WISH) $env(GISBASE)/etc/gm/tksys.tcl --tcltk & }} + }] +} { + lappend descmenu [subst { + {command {[G_msg "GRASS help"]} {} "g.manual" {} -command { exec g.manual -i > /dev/null & } } + {command {[G_msg "GIS Manager &help"]} {} {[G_msg "GIS Manager help"]} {} -command { exec g.manual gis.m > /dev/null & } } + {command {[G_msg "About &GRASS"]} {} {[G_msg "About GRASS"]} {} -command { source $env(GISBASE)/etc/gm/grassabout.tcl} } + {command {[G_msg "About &System"]} {} {[G_msg "About System"]} {} -command { exec $env(GRASS_WISH) $env(GISBASE)/etc/gm/tksys.tcl --tcltk & }} + }] +} Index: gui/tcltk/gis.m/runandoutput.tcl =================================================================== RCS file: /grassrepository/grass6/gui/tcltk/gis.m/runandoutput.tcl,v retrieving revision 1.12 diff -u -r1.12 runandoutput.tcl --- gui/tcltk/gis.m/runandoutput.tcl 27 Aug 2006 21:19:26 -0000 1.12 +++ gui/tcltk/gis.m/runandoutput.tcl 2 Sep 2006 06:00:41 -0000 @@ -169,11 +169,17 @@ ############################################################################### proc run {cmd args} { + global mingw + # This and runcmd are being used to run command in the background # These used to go to stdout and stderr # but we don't want to pollute that console. # eval exec -- $cmd $args >@ stdout 2>@ stderr - eval [list exec -- $cmd] $args >& /dev/null + if { $mingw == "1" } { + eval [list exec -- $cmd] $args >& nul + } { + eval [list exec -- $cmd] $args >& /dev/null + } } ############################################################################### Index: lib/gtcltk/gronsole.tcl =================================================================== RCS file: /grassrepository/grass6/lib/gtcltk/gronsole.tcl,v retrieving revision 1.6 diff -u -r1.6 gronsole.tcl --- lib/gtcltk/gronsole.tcl 27 Aug 2006 21:19:26 -0000 1.6 +++ lib/gtcltk/gronsole.tcl 2 Sep 2006 06:00:43 -0000 @@ -425,10 +425,16 @@ proc Gronsole::execout {path cmd ci execcmd} { global env + global mingw + set mark cmdinsert$ci # Actually run the program - set cmd [concat | $cmd 2>@ stdout] + if { $mingw == "1" } { + set cmd [concat | $cmd] + } { + set cmd [concat | $cmd 2>@ stdout] + } set message_env [exec g.gisenv get=GRASS_MESSAGE_FORMAT] set env(GRASS_MESSAGE_FORMAT) gui Index: lib/gtcltk/options.tcl =================================================================== RCS file: /grassrepository/grass6/lib/gtcltk/options.tcl,v retrieving revision 1.7 diff -u -r1.7 options.tcl --- lib/gtcltk/options.tcl 19 May 2006 21:19:16 -0000 1.7 +++ lib/gtcltk/options.tcl 2 Sep 2006 06:00:43 -0000 @@ -98,3 +98,9 @@ if { $osxaqua == "1"} { set keycontrol "Command" } + +if {[info exists env(MSYSCON)]} { + set mingw "1" +} else { + set mingw "0" +} From grass-bugs at intevation.de Sat Sep 2 10:09:46 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sat Sep 2 10:09:47 2006 Subject: [GRASS-dev] [bug #5085] (grass) gis.m & = eror; d.m & = O.K. Message-ID: <20060902080946.04D091005D4@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5085 ------------------------------------------------------------------------- Subject: gis.m & = eror; d.m & = O.K. Platform: GNU/Linux/x86_64 grass obtained from: Trento Italy site grass binary for platform: Downloaded precompiled Binaries GRASS Version: grass 6.3 Please enter your name and error description here. Don't write general statements such as "this could be better" - please explain in details how a certain problem can be solved or a feature be added/improved. Send different report for different problems. Thanks! elcome to GRASS 6.3.cvs (2006) GRASS homepage: http://grass.itc.it/ This version running thru: Bash Shell (/bin/bash) Help is available with the command: g.manual -i See the licence terms with: g.version -c Start the graphical user interface with: gis.m & When ready to quit enter: exit GRASS 6.3.cvs (d2133):/home/md/grass > gis.m & [1] 20263 GRASS 6.3.cvs (d2133):/home/md/grass > PROJ_INFO file not found for location d2133 PROJ_INFO file not found for location d2133 while executing "close $input" (procedure "MapCanvas::runprograms" line 37) invoked from within "MapCanvas::runprograms $mon [expr {$mymodified != 0}]" (procedure "MapCanvas::drawmap" line 38) invoked from within "MapCanvas::drawmap $mon" (procedure "MapCanvas::display_server" line 9) invoked from within "MapCanvas::display_server" ("after" script) -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Sat Sep 2 11:36:42 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Sat Sep 2 11:36:46 2006 Subject: [GRASS-dev] [bug #5085] (grass) gis.m & = eror; d.m & = O.K. Message-ID: <20060902093642.C49B71006B3@lists.intevation.de> Thanks for your report. Does gis.m fail to start in all your locations? Can you reproduce it with spearfish60 sample data set? (http://grass.itc.it/sampledata/spearfish_grass60data-0.3.tar.gz) Maciek -------------------------------------------- Managed by Request Tracker From tutey at o2.pl Sat Sep 2 11:39:58 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Sat Sep 2 11:40:03 2006 Subject: [GRASS-dev] gis.m patch In-Reply-To: <20060902063219.GA78577@localhost.tamu.edu> References: <20060902063219.GA78577@localhost.tamu.edu> Message-ID: <44F9516E.5060805@o2.pl> Huidae Cho wrote: > Hi, > > I've patched gis.m so that it can run on Windows natively with the help > of direct rendering. PDCurses lets the user to start in text mode, but > since there are no monitors available, gis.m is the only option for now. > > http://geni.ath.cx/grass/native_wingrass.png shows gis.m running on > MS-Windows (not Cygwin). Oh shoot, great! Can you re-send the patch as an attachment? Michael, Aply it? Maciek From tutey at o2.pl Sat Sep 2 12:01:58 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Sat Sep 2 12:02:03 2006 Subject: [GRASS-dev] v.bspline -> v.surf.bspline ? In-Reply-To: <44ED7041.3090505@o2.pl> References: <44DD0000.8000301@o2.pl> <44ED7041.3090505@o2.pl> Message-ID: <44F95696.2020902@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 From landa.martin at gmail.com Sat Sep 2 12:09:13 2006 From: landa.martin at gmail.com (Martin Landa) Date: Sat Sep 2 12:09:16 2006 Subject: [GRASS-dev] v.bspline -> v.surf.bspline ? In-Reply-To: <44F95696.2020902@o2.pl> References: <44DD0000.8000301@o2.pl> <44ED7041.3090505@o2.pl> <44F95696.2020902@o2.pl> Message-ID: Hi, I agree with you, the module should be renamed. Martin 2006/9/2, Maciej Sieczka : > 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 * http://gama.fsv.cvut.cz/~landa * From rez at touchofmadness.com Sat Sep 2 13:39:06 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Sat Sep 2 13:39:34 2006 Subject: [GRASS-dev] v.bspline -> v.surf.bspline ? In-Reply-To: <44F95696.2020902@o2.pl> References: <44DD0000.8000301@o2.pl> <44ED7041.3090505@o2.pl> <44F95696.2020902@o2.pl> Message-ID: <1157197146.5122.40.camel@devel> 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 KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From neteler at itc.it Sat Sep 2 14:42:57 2006 From: neteler at itc.it (Markus Neteler) Date: Sat Sep 2 14:43:01 2006 Subject: [GRASS-dev] v.bspline -> v.surf.bspline ? In-Reply-To: <1157197146.5122.40.camel@devel> References: <44DD0000.8000301@o2.pl> <44ED7041.3090505@o2.pl> <44F95696.2020902@o2.pl> <1157197146.5122.40.camel@devel> Message-ID: <20060902124257.GA4023@bartok.itc.it> 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 From hmitaso at unity.ncsu.edu Sat Sep 2 14:47:57 2006 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Sat Sep 2 14:48:05 2006 Subject: [GRASS-dev] v.bspline -> v.surf.bspline ? In-Reply-To: <20060902124257.GA4023@bartok.itc.it> References: <44DD0000.8000301@o2.pl> <44ED7041.3090505@o2.pl> <44F95696.2020902@o2.pl> <1157197146.5122.40.camel@devel> <20060902124257.GA4023@bartok.itc.it> Message-ID: 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 From grass4u at gmail.com Sat Sep 2 17:54:25 2006 From: grass4u at gmail.com (Huidae Cho) Date: Sat Sep 2 17:56:33 2006 Subject: [GRASS-dev] gis.m patch In-Reply-To: <44F9516E.5060805@o2.pl> References: <20060902063219.GA78577@localhost.tamu.edu> <44F9516E.5060805@o2.pl> Message-ID: <20060902155425.GA1295@localhost> Find attached the patch. Huidae On Sat, Sep 02, 2006 at 11:39:58AM +0200, Maciej Sieczka wrote: > Huidae Cho wrote: > > Hi, > > > > I've patched gis.m so that it can run on Windows natively with the help > > of direct rendering. PDCurses lets the user to start in text mode, but > > since there are no monitors available, gis.m is the only option for now. > > > > http://geni.ath.cx/grass/native_wingrass.png shows gis.m running on > > MS-Windows (not Cygwin). > > Oh shoot, great! > > Can you re-send the patch as an attachment? > > Michael, > > Aply it? > > Maciek -------------- next part -------------- Index: gui/tcltk/gis.m/gm.tcl =================================================================== RCS file: /grassrepository/grass6/gui/tcltk/gis.m/gm.tcl,v retrieving revision 1.25 diff -u -r1.25 gm.tcl --- gui/tcltk/gis.m/gm.tcl 24 Aug 2006 18:04:57 -0000 1.25 +++ gui/tcltk/gis.m/gm.tcl 2 Sep 2006 06:00:41 -0000 @@ -69,6 +69,12 @@ set execom "spawn" } +if {[info exists env(MSYSCON)]} { + set mingw "1" +} { + set mingw "0" +} + #fetch GRASS Version number: set fp [open $env(GISBASE)/etc/VERSIONNUMBER r] set GRASSVERSION [read -nonewline $fp] @@ -188,7 +194,13 @@ # Determine if an element already exists proc Gm::element_exists {elem name} { - set failure [catch {exec [list "|g.findfile" "element=$elem" "file=$name"] >& /dev/null}] + global mingw + + if { $mingw == "1" } { + set failure [catch {exec [list "|g.findfile" "element=$elem" "file=$name"] >& nul}] + } { + set failure [catch {exec [list "|g.findfile" "element=$elem" "file=$name"] >& /dev/null}] + } return [expr {! $failure}] } Index: gui/tcltk/gis.m/gmmenu.tcl =================================================================== RCS file: /grassrepository/grass6/gui/tcltk/gis.m/gmmenu.tcl,v retrieving revision 1.15 diff -u -r1.15 gmmenu.tcl --- gui/tcltk/gis.m/gmmenu.tcl 20 Jul 2006 17:43:19 -0000 1.15 +++ gui/tcltk/gis.m/gmmenu.tcl 2 Sep 2006 06:00:41 -0000 @@ -19,6 +19,7 @@ global mon global filename global env +global mingw # Put this at the top of the file menu. set GuiMenu::Menu_File_Top [subst { @@ -48,10 +49,20 @@ lappend descmenu all lappend descmenu options lappend descmenu $tmenu -lappend descmenu [subst { - {command {[G_msg "GRASS help"]} {} "g.manual" {} -command { exec g.manual -i > /dev/null & } } - {command {[G_msg "GIS Manager &help"]} {} {[G_msg "GIS Manager help"]} {} -command { exec g.manual gis.m > /dev/null & } } - {command {[G_msg "About &GRASS"]} {} {[G_msg "About GRASS"]} {} -command { source $env(GISBASE)/etc/gm/grassabout.tcl} } - {command {[G_msg "About &System"]} {} {[G_msg "About System"]} {} -command { exec $env(GRASS_WISH) $env(GISBASE)/etc/gm/tksys.tcl --tcltk & }} - }] +# MinGW +if { $mingw == "1" } { + lappend descmenu [subst { + {command {[G_msg "GRASS help"]} {} "g.manual" {} -command { exec g.manual -i >& nul } } + {command {[G_msg "GIS Manager &help"]} {} {[G_msg "GIS Manager help"]} {} -command { exec g.manual gis.m >& nul } } + {command {[G_msg "About &GRASS"]} {} {[G_msg "About GRASS"]} {} -command { source $env(GISBASE)/etc/gm/grassabout.tcl} } + {command {[G_msg "About &System"]} {} {[G_msg "About System"]} {} -command { exec $env(GRASS_WISH) $env(GISBASE)/etc/gm/tksys.tcl --tcltk & }} + }] +} { + lappend descmenu [subst { + {command {[G_msg "GRASS help"]} {} "g.manual" {} -command { exec g.manual -i > /dev/null & } } + {command {[G_msg "GIS Manager &help"]} {} {[G_msg "GIS Manager help"]} {} -command { exec g.manual gis.m > /dev/null & } } + {command {[G_msg "About &GRASS"]} {} {[G_msg "About GRASS"]} {} -command { source $env(GISBASE)/etc/gm/grassabout.tcl} } + {command {[G_msg "About &System"]} {} {[G_msg "About System"]} {} -command { exec $env(GRASS_WISH) $env(GISBASE)/etc/gm/tksys.tcl --tcltk & }} + }] +} Index: gui/tcltk/gis.m/runandoutput.tcl =================================================================== RCS file: /grassrepository/grass6/gui/tcltk/gis.m/runandoutput.tcl,v retrieving revision 1.12 diff -u -r1.12 runandoutput.tcl --- gui/tcltk/gis.m/runandoutput.tcl 27 Aug 2006 21:19:26 -0000 1.12 +++ gui/tcltk/gis.m/runandoutput.tcl 2 Sep 2006 06:00:41 -0000 @@ -169,11 +169,17 @@ ############################################################################### proc run {cmd args} { + global mingw + # This and runcmd are being used to run command in the background # These used to go to stdout and stderr # but we don't want to pollute that console. # eval exec -- $cmd $args >@ stdout 2>@ stderr - eval [list exec -- $cmd] $args >& /dev/null + if { $mingw == "1" } { + eval [list exec -- $cmd] $args >& nul + } { + eval [list exec -- $cmd] $args >& /dev/null + } } ############################################################################### Index: lib/gtcltk/gronsole.tcl =================================================================== RCS file: /grassrepository/grass6/lib/gtcltk/gronsole.tcl,v retrieving revision 1.6 diff -u -r1.6 gronsole.tcl --- lib/gtcltk/gronsole.tcl 27 Aug 2006 21:19:26 -0000 1.6 +++ lib/gtcltk/gronsole.tcl 2 Sep 2006 06:00:43 -0000 @@ -425,10 +425,16 @@ proc Gronsole::execout {path cmd ci execcmd} { global env + global mingw + set mark cmdinsert$ci # Actually run the program - set cmd [concat | $cmd 2>@ stdout] + if { $mingw == "1" } { + set cmd [concat | $cmd] + } { + set cmd [concat | $cmd 2>@ stdout] + } set message_env [exec g.gisenv get=GRASS_MESSAGE_FORMAT] set env(GRASS_MESSAGE_FORMAT) gui Index: lib/gtcltk/options.tcl =================================================================== RCS file: /grassrepository/grass6/lib/gtcltk/options.tcl,v retrieving revision 1.7 diff -u -r1.7 options.tcl --- lib/gtcltk/options.tcl 19 May 2006 21:19:16 -0000 1.7 +++ lib/gtcltk/options.tcl 2 Sep 2006 06:00:43 -0000 @@ -98,3 +98,9 @@ if { $osxaqua == "1"} { set keycontrol "Command" } + +if {[info exists env(MSYSCON)]} { + set mingw "1" +} else { + set mingw "0" +} From michael.barton at asu.edu Sat Sep 2 19:26:22 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sat Sep 2 19:26:35 2006 Subject: [GRASS-dev] Incorrect stuff coming through stderr? In-Reply-To: <17654.57386.176593.670128@cerise.gclements.plus.com> Message-ID: We are linking GRASS modules with a Java agent-based modeling environment. The lack of consistency in GRASS output is an issue here, as it is with trying to link GRASS with an interface building platform. Because GRASS is a suite of command-line tools, it is an ideal platform to be used by other platform for sophisticated modeling (Python, Java, etc) as well as be wrapped in an interface platform to serve as a full-featured GIS. However, GRASS was originally designed to be used by a person sitting at a terminal, typing commands, and reading the output off the screen. That's why there is output of the type produced by r.info and r.report. It's also why it didn't matter about inconsistencies between the information provided by r.display in different kinds of maps or between g.region -p and g.region -g However, these become issues that range from annoyances (parsing r.info) to impossibilities (parsing r.describe) when you try to use GRASS from another environment than a user at a terminal. There is nothing wrong with nicely formatted output (though it usually depends on fixed-width fonts, and looks ugly otherwise). However, it would be very useful (maybe even increasingly essential) that we also have a standard, easy to parse output format that is consistent across all modules. Standardized input is equally important, but we are in much better shape there. We already have a good start one kind of standardized output format, usually called "shell-script style", but sometimes also called "terse" or other things. This takes the format of "key=value" followed by a new line. It would also be very helpful, however, to simply have commands return a list of values in an order given in the command docs. So I'd like to propose the following as a goal in future version of GRASS. All commands that return values of some kind (i.e, that do not create or modify maps) have the option to return ALL of their values (not just a subset as is the case with g.region) in "shell-script" or "terse" format of "key=value". This option should be controlled by a standard flag for all modules for consistency. All commands that return values should also be able to return values as a list of values "value value value...". Again, this should be controlled by a standard flag for all modules. ... Snip snip ... >> 56% 60% 64% 68% 72% 76% 80% >> 84% 88% 92% 96% 100% >> CREATING SUPPORT FILES FOR managed.2.6 >> >> It occurs when I create the new maps using r.in.ascii and is sent via >> standard error. > > What's the problem? Progress messages are normal, and are supposed to > be written to stderr. > It seems odd to me that progress messages are written to stderr. However, if that is the norm across C programs, then I guess that's were they belong. But does " CREATING SUPPORT FILES FOR managed.2.6" also go there? We also need a "quiet" option for all commands to suppress all stdout except the actual output values. There is a lot of verbage produced some GRASS commands that might be nice for a user at a terminal to read, but that is problematic when GRASS modules are being used in other environments. This is available for some modules, but has variable effects (i.e., sometimes it only suppresses some of the extraneous verbage). I'm open to suggestion for how to modify this proposal. The objective is to offer standardized output that would make it easier to use GRASS in non-interactive environments. 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 hmitaso at unity.ncsu.edu Sat Sep 2 19:46:10 2006 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Sat Sep 2 19:47:01 2006 Subject: [GRASS-dev] Incorrect stuff coming through stderr? In-Reply-To: References: Message-ID: <312CD6A6-0AF0-47CA-9BD7-D9738653FD91@unity.ncsu.edu> Michael, you may want to put this into wiki for GRASS7, it will get lost in the email list. http://grass.gdf-hannover.de/wiki/GRASS_7_ideas_collection Helena On Sep 2, 2006, at 1:26 PM, Michael Barton wrote: > We are linking GRASS modules with a Java agent-based modeling > environment. > The lack of consistency in GRASS output is an issue here, as it is > with > trying to link GRASS with an interface building platform. > > Because GRASS is a suite of command-line tools, it is an ideal > platform to > be used by other platform for sophisticated modeling (Python, Java, > etc) as > well as be wrapped in an interface platform to serve as a full- > featured GIS. > > However, GRASS was originally designed to be used by a person > sitting at a > terminal, typing commands, and reading the output off the screen. > That's why > there is output of the type produced by r.info and r.report. It's > also why > it didn't matter about inconsistencies between the information > provided by > r.display in different kinds of maps or between g.region -p and > g.region -g > > However, these become issues that range from annoyances (parsing > r.info) to > impossibilities (parsing r.describe) when you try to use GRASS from > another > environment than a user at a terminal. > > There is nothing wrong with nicely formatted output (though it usually > depends on fixed-width fonts, and looks ugly otherwise). However, > it would > be very useful (maybe even increasingly essential) that we also have a > standard, easy to parse output format that is consistent across all > modules. > Standardized input is equally important, but we are in much better > shape > there. > > We already have a good start one kind of standardized output > format, usually > called "shell-script style", but sometimes also called "terse" or > other > things. This takes the format of "key=value" followed by a new > line. It > would also be very helpful, however, to simply have commands return > a list > of values in an order given in the command docs. So I'd like to > propose the > following as a goal in future version of GRASS. > > All commands that return values of some kind (i.e, that do not > create or > modify maps) have the option to return ALL of their values (not just a > subset as is the case with g.region) in "shell-script" or "terse" > format of > "key=value". > > This option should be controlled by a standard flag for all modules > for > consistency. > > All commands that return values should also be able to return > values as a > list of values "value value value...". > > Again, this should be controlled by a standard flag for all modules. > > ... Snip snip ... >>> 56% 60% 64% 68% 72% 76% 80% >>> 84% 88% 92% 96% 100% >>> CREATING SUPPORT FILES FOR managed.2.6 >>> >>> It occurs when I create the new maps using r.in.ascii and is sent >>> via >>> standard error. >> >> What's the problem? Progress messages are normal, and are supposed to >> be written to stderr. >> > > It seems odd to me that progress messages are written to stderr. > However, if > that is the norm across C programs, then I guess that's were they > belong. > But does " CREATING SUPPORT FILES FOR managed.2.6" also go there? > > We also need a "quiet" option for all commands to suppress all > stdout except > the actual output values. There is a lot of verbage produced some > GRASS > commands that might be nice for a user at a terminal to read, but > that is > problematic when GRASS modules are being used in other > environments. This is > available for some modules, but has variable effects (i.e., > sometimes it > only suppresses some of the extraneous verbage). > > I'm open to suggestion for how to modify this proposal. The > objective is to > offer standardized output that would make it easier to use GRASS in > non-interactive environments. > > 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 > > > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From michael.barton at asu.edu Sat Sep 2 19:50:14 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sat Sep 2 19:50:20 2006 Subject: [GRASS-dev] Re: [GRASS-user] invoking d.vect and d.rast from CLI In-Reply-To: <0E5A77B55A57D511BB3F0002A537C26208C55B57@s5-dar-r1.nrn.nrcan.gc.ca> Message-ID: Gism now uses GRASS_RENDER_IMMEDIATE mode. This causes any d.* command to send its output to a PPM file rather than to the d.mon display driver. This is only invoked just before a d.* command is issued and turned off afterwards. So d.mon start=gism is no longer used. This leaves the display driver free for whatever you want to use it for, but you'll have to set d.mon manually. In any case, you couldn't just set d.mon start=gism, type a display command, and have the map display in the canvas. This is a TclTk canvas, whose display is controlled by TclTk scripts, not GRASS commands. It is not a simple display window like an xterminal. 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: "Patton, Eric" > Date: Thu, 31 Aug 2006 15:15:44 -0300 > To: "'grassuser@grass.itc.it'" > Cc: "'grass-dev@grass.itc.it'" > Subject: [GRASS-user] invoking d.vect and d.rast from CLI > > I'm having trouble getting d.rast and d.vect working on the command line. > Here's a step-by-step to reproduce using Spearfish: > > After initial Grass 6.3 startup finishes: > >> d.mon -L > name description status > ---- ----------- ------ > PNG Create PNG Map not running > png1 Create PNG Map not running > png2 Create PNG Map not running > png3 Create PNG Map not running > png4 Create PNG Map not running > png5 Create PNG Map not running > png6 Create PNG Map not running > png7 Create PNG Map not running > gism Create PNG Map for gis.m not running > x0 X-windows graphics display not running > x1 X-windows graphics display not running > x2 X-windows graphics display not running > x3 X-windows graphics display not running > x4 X-windows graphics display not running > x5 X-windows graphics display not running > x6 X-windows graphics display not running > x7 X-windows graphics display not running > > # Shouldn't gism be shown as running here? > >> d.mon start=gism > PNG: GRASS_TRUECOLOR status: FALSE > PNG: collecting to file: map.png, > GRASS_WIDTH=640, GRASS_HEIGHT=480 > Graphics driver [gism] started > > ~ >d.mon -L > name description status > ---- ----------- ------ > PNG Create PNG Map not running > png1 Create PNG Map not running > png2 Create PNG Map not running > png3 Create PNG Map not running > png4 Create PNG Map not running > png5 Create PNG Map not running > png6 Create PNG Map not running > png7 Create PNG Map not running > gism Create PNG Map for gis.m running (selected) > x0 X-windows graphics display not running > x1 X-windows graphics display not running > x2 X-windows graphics display not running > x3 X-windows graphics display not running > x4 X-windows graphics display not running > x5 X-windows graphics display not running > x6 X-windows graphics display not running > x7 X-windows graphics display not running > > # I seem to remember before that gism was shown as being selected > immediately > # upon starting Grass... > > ~ >g.region rast=elevation.10m > ~ >d.rast -o map=elevation.10m > 100% > > # Nothing draws in the gis.m map display! > # Let's try a vector instead... > > ~ >g.region vect=soils > ~ >d.vect soils > > Again, nothing displays. > > Any ideas on what's going on here? > > ~ Eric. > > > > > > From glynn at gclements.plus.com Sat Sep 2 19:56:00 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Sep 2 19:56:11 2006 Subject: [GRASS-dev] gis.m patch In-Reply-To: <20060902063219.GA78577@localhost.tamu.edu> References: <20060902063219.GA78577@localhost.tamu.edu> Message-ID: <17657.50608.700812.568137@cerise.gclements.plus.com> Huidae Cho wrote: > I've patched gis.m so that it can run on Windows natively with the help > of direct rendering. PDCurses lets the user to start in text mode, but > since there are no monitors available, gis.m is the only option for now. > + if { $mingw == "1" } { > + set failure [catch {exec [list "|g.findfile" "element=$elem" "file=$name"] >& nul}] > + } { > + set failure [catch {exec [list "|g.findfile" "element=$elem" "file=$name"] >& /dev/null}] > + } Rather than duplicate entire commands, I would be inclined to create a global variable, e.g.: set devnull [expr {$mingw == 1 ? "nul" : "/dev/null"}] then use: global devnull ... set failure [catch {exec "|g.findfile" "element=$elem" "file=$name" >& $devnull}] [Note that the original exec command was broken.] -- Glynn Clements From michael.barton at asu.edu Sat Sep 2 21:34:29 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sat Sep 2 21:34:35 2006 Subject: [GRASS-dev] Backporting question In-Reply-To: <20060831145838.GA8640@localhost.tamu.edu> Message-ID: Once all the freetype and font changes are in effect and I get/make a new binary to work from, I can test these on my Mac (unless someone else wants to do it). If there is an advantage of putting a GRASS generated text layer (the new combined d.text/d.text.freetype?) back into gism instead of the TclTk-generated text, I can do that. However, it will take a bit of time to redo the options panel and change the rest of the code. There is no point in doing this until: 1) all the changes to text layer control and rendering are done (more to do or is that all?), and 2) we know that freetype text renders on the Mac (the TclTk text shows up fine on all systems). I don't know whether you want to try and do this for 6.2 or not, given the timing. 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: Huidae Cho > Date: Thu, 31 Aug 2006 09:58:38 -0500 > To: GRASS developers list > Subject: Re: [GRASS-dev] Backporting question > > On Thu, Aug 31, 2006 at 04:12:57PM +0200, Markus Neteler wrote: >> Hi Huidae, all, >> >> freetype done (is gis.m not affected for this?) as indicated >> below. > > No. gis.m does not have d.text.freetype support. > > Huidae > From neteler at itc.it Sat Sep 2 21:38:50 2006 From: neteler at itc.it (Markus Neteler) Date: Sat Sep 2 21:38:52 2006 Subject: [GRASS-dev] Backporting question In-Reply-To: References: <20060831145838.GA8640@localhost.tamu.edu> Message-ID: <20060902193850.GH5164@bartok.itc.it> On Sat, Sep 02, 2006 at 12:34:29PM -0700, Michael Barton wrote: [freetype] > I don't know whether you want to try and do this for 6.2 or not, given the > timing. My suggestion is to not do it for 6.2. It is almost published. Next week I can do the proposed change of v.bspline to v.surf.bspline but I would not do heavy (yet untested) changes. Markus From michael.barton at asu.edu Sat Sep 2 21:40:01 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sat Sep 2 21:40:07 2006 Subject: [GRASS-dev] grass63 -text startup screen In-Reply-To: <44F76F8C.5070104@stjohnspoint.co.uk> Message-ID: You can't use tooltips on a text startup screen. For the TclTk startup, the widgets don't support this kind of help. Rewriting the startup to allow mouseover help is possible but non-trivial. 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: Paul Kelly > Date: Fri, 01 Sep 2006 00:23:56 +0100 > To: Hamish > Cc: > Subject: Re: [GRASS-dev] grass63 -text startup screen > > Hamish wrote: >> >> sorry if I missed the answer, but what became of the idea to use multi- >> sentence tool-tips to explain each field? > > Well Helena said it was a good idea but I didn't receive any further > replies. Have to admit I wouldn't actually know where to look to change > it myself. > > Paul > > From woklist at kyngchaos.com Sat Sep 2 21:45:50 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Sat Sep 2 21:45:57 2006 Subject: [GRASS-dev] GRASS 6.2.0beta2 published In-Reply-To: <20060830222916.GB3746@bartok.itc.it> References: <20060830222916.GB3746@bartok.itc.it> Message-ID: <7D24706A-D252-4F89-A62B-55AA947F9297@kyngchaos.com> I have a Mac OS X app available for download now for 6.2b2 (and also for today's 6.3 snapshot). http://www.kyngchaos.com/ I added a build template similar to GEM for building addon modules. It doesn't require the module to be setup for GEM by the author (I didn't see any that were in the few that I looked at), but only an easy change to the module's makefile. It doesn't have a registry or add the module to the GUI menus. Just a quick-n-dirty hack for now - I'm not trying to replace GEM. There is also an Application Support configuration for adding the modules so the app package doesn't need to be changed. This brings me to a point about extending GRASS in a Mac environment. An installed application should not be changed, and for an unprivileged user it probably _can't_ be changed (goes for other OS's also). Also, with drag-n-drop installs and updates, one can easily forget and wipe out addons in the app package. GRASS needs more support for external configuration and expansion. Module binaries are easily handled by the GRASS_ADDON_PATH env. Modules that have their own libraries can use DYLD_LIBRARY_PATH (or LD_LIBRARY_PATH) to point to an external library location. What is missing is how to integrate extra documentation from an external location, and how to handle GUI extras like adding the modules to menus without changing the base menus. Module etc/ stuff could also be a problem. ... Something to think about. I'll probably add something to the GRASS 7 Idea page. On Aug 30, 2006, at 5:29 PM, Markus Neteler wrote: > Dear all, > > I have put online the next beta at > http://grass.itc.it/grass62/source/ > > Please test! > > The changes are listed here: > http://grass.gdf-hannover.de/wiki/GRASS_6.2_Feature_Plan > > Thanks, > Markus > ----- William Kyngesburye http://www.kyngchaos.com/ "Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life." - Marvin ----- William Kyngesburye http://www.kyngchaos.com/ Theory of the Universe There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened. -Hitchhiker's Guide to the Galaxy 2nd season intro From michael.barton at asu.edu Sat Sep 2 22:06:50 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sat Sep 2 22:06:57 2006 Subject: [GRASS-dev] gis.m patch In-Reply-To: <20060902063219.GA78577@localhost.tamu.edu> Message-ID: This is GREAT. Thanks very much. I have a couple questions. 1. Is there a binary version of this available for people to try? 2. Do your changes affect how gism runs on any other platform? 3. Could you give me a brief one-liner of what each change to gism is intended to do so I can find a way to keep this in the code if it does have issues on other platforms? 4. Does NVIZ work? Great news (even though I don't use Windows) 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: Huidae Cho > Date: Sat, 2 Sep 2006 01:32:19 -0500 > To: > Subject: [GRASS-dev] gis.m patch > > Hi, > > I've patched gis.m so that it can run on Windows natively with the help > of direct rendering. PDCurses lets the user to start in text mode, but > since there are no monitors available, gis.m is the only option for now. > > http://geni.ath.cx/grass/native_wingrass.png shows gis.m running on > MS-Windows (not Cygwin). > > Huidae > > GRASS is now configured for: i686-pc-mingw32 > > Source directory: /home/song/usr/grass/grass6 > Build directory: /home/song/usr/grass/grass6 > Installation directory: /usr/local/grass-6.3.cvs > Startup script in directory: ${exec_prefix}/bin > C compiler: gcc -g -O2 -D__W98__ > C++ compiler: c++ -g -O2 > FORTRAN compiler: > Building shared libraries: yes > 64bit support: no > OpenGL platform: Windows > > NVIZ: yes > > BLAS support: no > C++ support: yes > DWG support: no > FFMPEG support: no > FFTW support: yes > FreeType support: yes > GDAL support: yes > GLw support: no > JPEG support: yes > LAPACK support: no > Large File Support (LFS): no > Motif support: no > MySQL support: no > NLS support: no > ODBC support: no > OGR support: yes > OpenGL support: yes > PNG support: yes > PostgreSQL support: yes > Python support: no > Readline support: yes > SQLite support: yes > Tcl/Tk support: yes > TIFF support: yes > X11 support: yes > > > Index: gui/tcltk/gis.m/gm.tcl > =================================================================== > RCS file: /grassrepository/grass6/gui/tcltk/gis.m/gm.tcl,v > retrieving revision 1.25 > diff -u -r1.25 gm.tcl > --- gui/tcltk/gis.m/gm.tcl 24 Aug 2006 18:04:57 -0000 1.25 > +++ gui/tcltk/gis.m/gm.tcl 2 Sep 2006 06:00:41 -0000 > @@ -69,6 +69,12 @@ > set execom "spawn" > } > > +if {[info exists env(MSYSCON)]} { > + set mingw "1" > +} { > + set mingw "0" > +} > + > #fetch GRASS Version number: > set fp [open $env(GISBASE)/etc/VERSIONNUMBER r] > set GRASSVERSION [read -nonewline $fp] > @@ -188,7 +194,13 @@ > # Determine if an element already exists > > proc Gm::element_exists {elem name} { > - set failure [catch {exec [list "|g.findfile" "element=$elem" "file=$name"] > >& /dev/null}] > + global mingw > + > + if { $mingw == "1" } { > + set failure [catch {exec [list "|g.findfile" "element=$elem" "file=$name"] > >& nul}] > + } { > + set failure [catch {exec [list "|g.findfile" "element=$elem" "file=$name"] > >& /dev/null}] > + } > > return [expr {! $failure}] > } > Index: gui/tcltk/gis.m/gmmenu.tcl > =================================================================== > RCS file: /grassrepository/grass6/gui/tcltk/gis.m/gmmenu.tcl,v > retrieving revision 1.15 > diff -u -r1.15 gmmenu.tcl > --- gui/tcltk/gis.m/gmmenu.tcl 20 Jul 2006 17:43:19 -0000 1.15 > +++ gui/tcltk/gis.m/gmmenu.tcl 2 Sep 2006 06:00:41 -0000 > @@ -19,6 +19,7 @@ > global mon > global filename > global env > +global mingw > > # Put this at the top of the file menu. > set GuiMenu::Menu_File_Top [subst { > @@ -48,10 +49,20 @@ > lappend descmenu all > lappend descmenu options > lappend descmenu $tmenu > -lappend descmenu [subst { > - {command {[G_msg "GRASS help"]} {} "g.manual" {} -command { exec g.manual -i > > /dev/null & } } > - {command {[G_msg "GIS Manager &help"]} {} {[G_msg "GIS Manager help"]} {} > -command { exec g.manual gis.m > /dev/null & } } > - {command {[G_msg "About &GRASS"]} {} {[G_msg "About GRASS"]} {} -command { > source $env(GISBASE)/etc/gm/grassabout.tcl} } > - {command {[G_msg "About &System"]} {} {[G_msg "About System"]} {} -command { > exec $env(GRASS_WISH) $env(GISBASE)/etc/gm/tksys.tcl --tcltk & }} > - }] > > +# MinGW > +if { $mingw == "1" } { > + lappend descmenu [subst { > + {command {[G_msg "GRASS help"]} {} "g.manual" {} -command { exec g.manual > -i >& nul } } > + {command {[G_msg "GIS Manager &help"]} {} {[G_msg "GIS Manager help"]} {} > -command { exec g.manual gis.m >& nul } } > + {command {[G_msg "About &GRASS"]} {} {[G_msg "About GRASS"]} {} -command { > source $env(GISBASE)/etc/gm/grassabout.tcl} } > + {command {[G_msg "About &System"]} {} {[G_msg "About System"]} {} -command > { exec $env(GRASS_WISH) $env(GISBASE)/etc/gm/tksys.tcl --tcltk & }} > + }] > +} { > + lappend descmenu [subst { > + {command {[G_msg "GRASS help"]} {} "g.manual" {} -command { exec g.manual > -i > /dev/null & } } > + {command {[G_msg "GIS Manager &help"]} {} {[G_msg "GIS Manager help"]} {} > -command { exec g.manual gis.m > /dev/null & } } > + {command {[G_msg "About &GRASS"]} {} {[G_msg "About GRASS"]} {} -command { > source $env(GISBASE)/etc/gm/grassabout.tcl} } > + {command {[G_msg "About &System"]} {} {[G_msg "About System"]} {} -command > { exec $env(GRASS_WISH) $env(GISBASE)/etc/gm/tksys.tcl --tcltk & }} > + }] > +} > Index: gui/tcltk/gis.m/runandoutput.tcl > =================================================================== > RCS file: /grassrepository/grass6/gui/tcltk/gis.m/runandoutput.tcl,v > retrieving revision 1.12 > diff -u -r1.12 runandoutput.tcl > --- gui/tcltk/gis.m/runandoutput.tcl 27 Aug 2006 21:19:26 -0000 1.12 > +++ gui/tcltk/gis.m/runandoutput.tcl 2 Sep 2006 06:00:41 -0000 > @@ -169,11 +169,17 @@ > > > ##############################################################################> # > proc run {cmd args} { > + global mingw > + > # This and runcmd are being used to run command in the background > # These used to go to stdout and stderr > # but we don't want to pollute that console. > # eval exec -- $cmd $args >@ stdout 2>@ stderr > - eval [list exec -- $cmd] $args >& /dev/null > + if { $mingw == "1" } { > + eval [list exec -- $cmd] $args >& nul > + } { > + eval [list exec -- $cmd] $args >& /dev/null > + } > } > > > ##############################################################################> # > Index: lib/gtcltk/gronsole.tcl > =================================================================== > RCS file: /grassrepository/grass6/lib/gtcltk/gronsole.tcl,v > retrieving revision 1.6 > diff -u -r1.6 gronsole.tcl > --- lib/gtcltk/gronsole.tcl 27 Aug 2006 21:19:26 -0000 1.6 > +++ lib/gtcltk/gronsole.tcl 2 Sep 2006 06:00:43 -0000 > @@ -425,10 +425,16 @@ > > proc Gronsole::execout {path cmd ci execcmd} { > global env > + global mingw > + > set mark cmdinsert$ci > > # Actually run the program > - set cmd [concat | $cmd 2>@ stdout] > + if { $mingw == "1" } { > + set cmd [concat | $cmd] > + } { > + set cmd [concat | $cmd 2>@ stdout] > + } > > set message_env [exec g.gisenv get=GRASS_MESSAGE_FORMAT] > set env(GRASS_MESSAGE_FORMAT) gui > Index: lib/gtcltk/options.tcl > =================================================================== > RCS file: /grassrepository/grass6/lib/gtcltk/options.tcl,v > retrieving revision 1.7 > diff -u -r1.7 options.tcl > --- lib/gtcltk/options.tcl 19 May 2006 21:19:16 -0000 1.7 > +++ lib/gtcltk/options.tcl 2 Sep 2006 06:00:43 -0000 > @@ -98,3 +98,9 @@ > if { $osxaqua == "1"} { > set keycontrol "Command" > } > + > +if {[info exists env(MSYSCON)]} { > + set mingw "1" > +} else { > + set mingw "0" > +} > > From michael.barton at asu.edu Sun Sep 3 01:23:33 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sun Sep 3 01:23:38 2006 Subject: [GRASS-dev] Freetype on Mac Message-ID: I just tried William Kyngesbury?s new 6.3 binaries. d.text.freetype works OK on my PB G4 Mac now. But I see that the discussed changes to d.text have not yet been implemented. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060902/79686496/attachment.html From glynn at gclements.plus.com Sun Sep 3 07:49:08 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Sep 3 07:49:16 2006 Subject: [GRASS-dev] Freetype on Mac In-Reply-To: References: Message-ID: <17658.27860.994094.40610@cerise.gclements.plus.com> Michael Barton wrote: > I just tried William Kyngesbury?s new 6.3 binaries. > > d.text.freetype works OK on my PB G4 Mac now. > > But I see that the discussed changes to d.text have not yet been > implemented. Note that there is now a d.text.new command which, AFAICT, provides the same functionality as d.text.freetype in terms of options and formatting codes, but works with both FreeType and stroke fonts. d.text itself remains unchanged. Apart from the addition of d.text.new, the main externally-visible change is that d.font can be used to set either a stroke or FreeType font. Either type of font can be specified either by name (via font=) or via a full path (via path=), and the encoding can be set by the charset= option. AFAICT, d.font.freetype and d.text.freetype are essentially redundant. -- Glynn Clements From hamish_nospam at yahoo.com Sun Sep 3 07:58:16 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Sep 3 07:58:43 2006 Subject: [GRASS-dev] Re: [GRASS-user] [bug #3041] nviz max resolution ppm image dump In-Reply-To: <17656.22740.864086.721594@cerise.gclements.plus.com> References: <44F32EC1.7080908@fire.esd.ornl.gov> <20060829141340.7e01582d.hamish_nospam@yahoo.com> <44F3ABA0.4050200@fire.esd.ornl.gov> <20060829180608.72176063.hamish_nospam@yahoo.com> <1156852657.8124.9.camel@linuxmain.localhost> <20060830171428.76de4e89.hamish_nospam@yahoo.com> <17653.35468.666861.57261@cerise.gclements.plus.com> <20060831154810.287856fc.hamish_nospam@yahoo.com> <17654.56613.600780.723615@cerise.gclements.plus.com> <20060901151740.29b45429.hamish_nospam@yahoo.com> <17655.44557.390080.801898@cerise.gclements.plus.com> <20060901173149.5b403a05.hamish_nospam@yahoo.com> <17656.22740.864086.721594@cerise.gclements.plus.com> Message-ID: <20060903175816.19d51d1c.hamish_nospam@yahoo.com> > > > > > > With off-screen rendering disabled, I get good results .. > IOW, neither pBuffers nor GLX Pixmaps work. FWIW, they don't work for > me either. The NO_GLX_PIXMAPS case comes close (see attached, made up of 36 tiles) export GRASS_NO_GLX_PIXMAPS=TRUE unset GRASS_NO_GLX_PBUFFERS > I'll commit the patch, so that disabling off-screen rendering at > run time works. Ok, tested. now it is possible to get good output if you know those envi. vars. > I could invert the sense of the tests, so that you have to > specifically request it. However, that essentially guarantees that the > off-screen rendering won't get any significant amount of testing. For the release branch the default mode could be on-screen but probably working, and for 6.3-HEAD it could be left with off-screen rendering enabled & FIXME? Hamish -------------- next part -------------- A non-text attachment was scrubbed... Name: no_glx_pixmaps_6x6.png Type: image/png Size: 12338 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060903/bdd7c197/no_glx_pixmaps_6x6.png From glynn at gclements.plus.com Sun Sep 3 08:12:56 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Sep 3 08:13:19 2006 Subject: [GRASS-dev] Incorrect stuff coming through stderr? In-Reply-To: References: <17654.57386.176593.670128@cerise.gclements.plus.com> Message-ID: <17658.29288.655037.767589@cerise.gclements.plus.com> Michael Barton wrote: > >> 56% 60% 64% 68% 72% 76% 80% > >> 84% 88% 92% 96% 100% > >> CREATING SUPPORT FILES FOR managed.2.6 > >> > >> It occurs when I create the new maps using r.in.ascii and is sent via > >> standard error. > > > > What's the problem? Progress messages are normal, and are supposed to > > be written to stderr. > > It seems odd to me that progress messages are written to stderr. However, if > that is the norm across C programs, then I guess that's were they belong. > But does " CREATING SUPPORT FILES FOR managed.2.6" also go there? It should. As a general rule, human-readable output goes to stderr while machine-readable output goes to stdout. There are two main reasons for this approach: 1. If you have a pipleine such as: foo | bar | baz > out.txt the data piped between commands and written to the file consists solely of machine-readable data. Writing diagnostics or status message to stdout would confuse programs further down the pipeline, or programs reading the resulting text file. In the above example, none of the redirections affect stderr, so it would continue to refer to the terminal. 2. At program startup, stdout is line-buffered if it refers to a terminal and fully-buffered otherwise (e.g. for files, pipes or sockets), while stderr is unbuffered. Writing to a fully-buffered stream won't produce any externally-visible results until either the buffer is full or an explicit fflush() is used. If stdout is a terminal, you will only see complete lines of output, so output where lines are composed over time (e.g. percentage output, or "doing something ..... ... done") will appear all at once upon completion. Worse, if stdout is a pipe (or file being monitored with "tail -f ..." from another terminal), you will only see output in complete blocks (typically 4KiB). > We also need a "quiet" option for all commands to suppress all stdout except > the actual output values. There is a lot of verbage produced some GRASS > commands that might be nice for a user at a terminal to read, but that is > problematic when GRASS modules are being used in other environments. This is > available for some modules, but has variable effects (i.e., sometimes it > only suppresses some of the extraneous verbage). That isn't hard to implement, although it's a fair amount of (rather tedious) work. There are two parts: 1. Change individual modules to use G_message() rather than [f]printf() for all progress messages. 2. Add a G_INFO_FORMAT_QUIET option to G_info_format() and change G_message() to take note of it. -- Glynn Clements From hamish_nospam at yahoo.com Sun Sep 3 08:19:03 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Sep 3 08:19:11 2006 Subject: [GRASS-dev] grass63 -text startup screen In-Reply-To: References: <44F5917C.2050001@o2.pl> <20060830082128.7538458a@localhost.localdomain> <20060831165853.09559de6.hamish_nospam@yahoo.com> <44F76F8C.5070104@stjohnspoint.co.uk> Message-ID: <20060903181903.03768fe7.hamish_nospam@yahoo.com> Helena Mitasova wrote: > The suggestion for tool-tips was for the startup GUI. > After the FOSS4G conference we should start looking into the startup > GUI again, as creating a new location is still problematic, Indeed, maybe folks can start working on a replacement WxPython GUI welcome screen and new location wizard for 6.3 as a small project. My hope is that the various WxGUI components can be worked on somewhat separately by several teams of devels, so the load is not all on 2-4 people. Hopefully in some coordinated way so that we don't get 5 different styles. Hamish From hamish_nospam at yahoo.com Sun Sep 3 09:59:33 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Sep 3 09:59:39 2006 Subject: [GRASS-dev] v.in.ogr broken (\w shp) In-Reply-To: <1157126513.17352.65.camel@devel> References: <1157126513.17352.65.camel@devel> Message-ID: <20060903195933.39429ed5.hamish_nospam@yahoo.com> Brad Douglas wrote: > Is there an easy fix for this? I'm trying to import a shapefile and > I'm not terribly familiar with this part of the GRASS architecture. > > GRASS 6.3.cvs (hamilton):~/hamilton > v.in.ogr dsn=. output=roads > layer=17 > Projection of input dataset and current location appear to match. > Proceeding with import... > Layer: 17 > DBMI-DBF driver error: > Column 'ADMIN_CLAS' already exists (duplicate name) > Cannot create table. > Error in db_execute_immediate() > > ERROR: Cannot create table: create table roads (cat integer, PREFIX > varchar > ( 2 ), NAME varchar ( 30 ), TYPE varchar ( 4 ), SUFFIX varchar > ( 2 > ), FCC varchar ( 3 ), FIPS varchar ( 11 ), ID integer, > FULL_NAME varchar ( 40 ), ADMIN_CLAS varchar ( 40 ), CATEGORY > integer, ST_CNTY_FI varchar ( 11 ), RD_CLASS varchar ( 4 ), > RTE_NUM1 > varchar > ( 4 ), RTE_NUM2 varchar ( 4 ), ADMIN_CLAS integer, AREA double > precision, LEN double precision) > GRASS 6.3.cvs (hamilton):~/hamilton > DBF limits column names to 10 chars; you end up with "ADMIN_CLAS" twice in the above list. Either change DB column names or user the v.in.ogr cnames= option to rename columns to something unique. (hint, cut & paste above list with modification). Maybe changing DB to SQLite or something helps too? Hamish From grass-bugs at intevation.de Sun Sep 3 12:27:25 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Sun Sep 3 12:27:27 2006 Subject: [GRASS-dev] [bug #3167] (grass) g.setproj is leaving DEFAULT_WIND files in user mapsets Message-ID: <20060903102725.457F51006A1@lists.intevation.de> Hi Paul, Could you possibly take a look at this bug? Thanks, Maciek -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Sun Sep 3 13:05:30 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sun Sep 3 13:05:33 2006 Subject: [GRASS-dev] [bug #5089] (grass) complete text file Message-ID: <20060903110530.9F2891005DE@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5089 ------------------------------------------------------------------------- ------=_Part_96603_15034519.1157281527913 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Here is the complete text file: ****************************************************************************************** Subject: gis.m & = error; d.m & = O.K. Platform: GNU/Linux/x86_64 grass obtained from: Trento Italy site grass binary for platform: Downloaded precompiled Binaries GRASS Version: grass 6.3 Please enter your name and error description here. Don't write general statements such as "this could be better" - please explain in details how a certain problem can be solved or a feature be added/improved. Send different report for different problems. Thanks! Welcome to GRASS 6.3.cvs (2006) GRASS homepage: http://grass.itc.it/ This version running thru: Bash Shell (/bin/bash) Help is available with the command: g.manual -i See the licence terms with: g.version -c Start the graphical user interface with: gis.m & When ready to quit enter: exit GRASS 6.3.cvs (d2133):/home/md/grass > gis.m & [1] 20263 GRASS 6.3.cvs (d2133):/home/md/grass > PROJ_INFO file not found for location d2133 PROJ_INFO file not found for location d2133 while executing "close $input" (procedure "MapCanvas::runprograms" line 37) invoked from within "MapCanvas::runprograms $mon [expr {$mymodified != 0}]" (procedure "MapCanvas::drawmap" line 38) invoked from within "MapCanvas::drawmap $mon" (procedure "MapCanvas::display_server" line 9) invoked from within "MapCanvas::display_server" ("after" script) THE SAME ERROR MESSAGE FOR MY OTHER LOCATONS *********************************************************** Welcome to GRASS 6.3.cvs (2006) GRASS homepage: http://grass.itc.it/ This version running thru: Bash Shell (/bin/bash) Help is available with the command: g.manual -i See the licence terms with: g.version -c Start the graphical user interface with: gis.m & When ready to quit enter: exit GRASS 6.3.cvs (d2133):/home/md/grass > gis.m & [1] 20263 GRASS 6.3.cvs (d2133):/home/md/grass > PROJ_INFO file not found for location d2133 PROJ_INFO file not found for location d2133 while executing "close $input" (procedure "MapCanvas::runprograms" line 37) invoked from within "MapCanvas::runprograms $mon [expr {$mymodified != 0}]" (procedure "MapCanvas::drawmap" line 38) invoked from within "MapCanvas::drawmap $mon" (procedure "MapCanvas::display_server" line 9) invoked from within "MapCanvas::display_server" ("after" script) ******************************************************************** Welcome to GRASS 6.3.cvs (2006) GRASS homepage: http://grass.itc.it/ This version running thru: Bash Shell (/bin/bash) Help is available with the command: g.manual -i See the licence terms with: g.version -c Start the graphical user interface with: gis.m & When ready to quit enter: exit GRASS 6.3.cvs (spearfish60):/home/md/grass-data/spearfish60/PERMANENT/vector > gis.m & [1] 2744 GRASS 6.3.cvs (spearfish60):/home/md/grass-data/spearfish60/PERMANENT/vector > d.mon start=gism PNG: GRASS_TRUECOLOR status: FALSE PNG: collecting to file: map.png, GRASS_WIDTH=640, GRASS_HEIGHT=480 Graphics driver [gism] started [1]+ Done gis.m GRASS 6.3.cvs (spearfish60):/home/md/grass-data/spearfish60/PERMANENT/vector > d.vect map=roads GRASS 6.3.cvs (spearfish60):/home/md/grass-data/spearfish60/PERMANENT/vector > NO ERRORS, NO RESULTS -- Jonas Mockus e-mail: jmockus@gmail.com ------=_Part_96603_15034519.1157281527913 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Here is the complete text file:
 ******************************************************************************************
Subject: gis.m & = error; d.m & = O.K.

Platform: GNU/Linux/x86_64
grass obtained from: Trento Italy site
grass binary for platform: Downloaded precompiled Binaries
GRASS Version: grass 6.3

Please enter your name and error description here. Don't
write general statements
such as "this could be better" - please explain in
details how a certain problem can be solved or a feature be
added/improved. Send
different report for different problems. Thanks!

Welcome to GRASS 6.3.cvs (2006)
GRASS homepage:
http://grass.itc.it/
This version running thru:               Bash Shell
(/bin/bash)
Help is available with the command:      g.manual -i
See the licence terms with:              g.version -c
Start the graphical user interface with: gis.m &
When ready to quit enter:                exit
GRASS 6.3.cvs (d2133):/home/md/grass > gis.m &
[1] 20263
GRASS 6.3.cvs (d2133):/home/md/grass >


PROJ_INFO file not found for location d2133
PROJ_INFO file not found for location d2133
    while executing
"close $input"
    (procedure "MapCanvas::runprograms" line 37)
    invoked from within
"MapCanvas::runprograms $mon [expr {$mymodified != 0}]"
    (procedure "MapCanvas::drawmap" line 38)
    invoked from within
"MapCanvas::drawmap $mon"
    (procedure "MapCanvas::display_server" line 9)
    invoked from within
"MapCanvas::display_server"
    ("after" script)

THE SAME ERROR MESSAGE FOR MY OTHER  LOCATONS

***********************************************************
Welcome to GRASS 6.3.cvs (2006)
GRASS homepage:
http://grass.itc.it/
This version running thru:               Bash Shell
(/bin/bash)
Help is available with the command:      g.manual -i
See the licence terms with:              g.version -c
Start the graphical user interface with: gis.m &
When ready to quit enter:                exit
GRASS 6.3.cvs (d2133):/home/md/grass > gis.m &
[1] 20263
GRASS 6.3.cvs (d2133):/home/md/grass >


PROJ_INFO file not found for location d2133
PROJ_INFO file not found for location d2133
    while executing
"close $input"
    (procedure "MapCanvas::runprograms" line 37)
    invoked from within
"MapCanvas::runprograms $mon [expr {$mymodified != 0}]"
    (procedure "MapCanvas::drawmap" line 38)
    invoked from within
"MapCanvas::drawmap $mon"
    (procedure "MapCanvas::display_server" line 9)
    invoked from within
"MapCanvas::display_server"
    ("after" script)

********************************************************************

Welcome to GRASS 6.3.cvs (2006)
GRASS homepage:                          http://grass.itc.it/
This version running thru:               Bash Shell (/bin/bash)
Help is available with the command:      g.manual -i
See the licence terms with:              g.version -c
Start the graphical user interface with: gis.m &
When ready to quit enter:                exit
GRASS 6.3.cvs
(spearfish60):/home/md/grass-data/spearfish60/PERMANENT/vector >
gis.m
&
[1] 2744
GRASS 6.3.cvs
(spearfish60):/home/md/grass-data/spearfish60/PERMANENT/vector >
d.mon
start=gism
PNG: GRASS_TRUECOLOR status: FALSE
PNG: collecting to file: map.png,
     GRASS_WIDTH=640, GRASS_HEIGHT=480
Graphics driver [gism] started
[1]+  Done                    gis.m
GRASS 6.3.cvs
(spearfish60):/home/md/grass-data/spearfish60/PERMANENT/vector >
d.vect map=roads
GRASS 6.3.cvs
(spearfish60):/home/md/grass-data/spearfish60/PERMANENT/vector >

NO ERRORS, NO RESULTS
--
Jonas Mockus
e-mail:
jmockus@gmail.com ------=_Part_96603_15034519.1157281527913-- --- Headers Follow --- >From jmockus@gmail.com Sun Sep 3 13:05:30 2006 Return-Path: Delivered-To: grass-bugs@lists.intevation.de Received: from kolab.intevation.de (aktaia [212.95.126.10]) by lists.intevation.de (Postfix) with ESMTP id 48C0E1005DB for ; Sun, 3 Sep 2006 13:05:30 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 32BB2111F4E for ; Sun, 3 Sep 2006 13:05:30 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 1C46B140427 for ; Sun, 3 Sep 2006 13:05:30 +0200 (CEST) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.239]) by kolab.intevation.de (Postfix) with ESMTP id 398AB111F4E for ; Sun, 3 Sep 2006 13:05:28 +0200 (CEST) Received: by wx-out-0506.google.com with SMTP id t15so1521085wxc for ; Sun, 03 Sep 2006 04:05:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=cECDdAzl/DILCufVc6yXNPF/zqcdC9Qe68BuvU7VyjHlqxyqno5u2wvsJULmNHTPd3GYfG57m40/xKFTj38QdPdjB9UfNtV8aMzINQxEvtYAYArmN3EaKZE1meX4r876F9iSKVXYkGonoXZ/0f0Nm+H3wFKkUBElMfwaf7woXG4= Received: by 10.70.118.4 with SMTP id q4mr3497129wxc; Sun, 03 Sep 2006 04:05:27 -0700 (PDT) Received: by 10.70.11.18 with HTTP; Sun, 3 Sep 2006 04:05:27 -0700 (PDT) Message-ID: <9140b6030609030405v6cdf48ddt37afc5f2c11326d@mail.gmail.com> Date: Sun, 3 Sep 2006 14:05:27 +0300 From: "jonas mockus" To: "Maciek Sieczka via RT" Subject: complete text file MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_96603_15034519.1157281527913" X-Virus-Scanned: by amavisd-new at intevation.de X-Spam-Status: No, hits=-4.398 tagged_above=-999 required=3 tests=[BAYES_00=-5, HTML_40_50=0.035, HTML_MESSAGE=0.5, RCVD_BY_IP=0.067] X-Spam-Level: -------------------------------------------- Managed by Request Tracker From tutey at o2.pl Sun Sep 3 13:45:36 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Sun Sep 3 13:45:41 2006 Subject: [GRASS-dev] v.proj transforming z co-ordinates In-Reply-To: References: <20060830153110.GT1046@bartok.itc.it> Message-ID: <44FAC060.1010306@o2.pl> Paul, I tried reprojecting a 3D points vector (3 arcsec strm) with v.proj, from latlong WGS84 to UTM 34, and I see *no difference* in either x,y or z coordinate, no matter whether the new implemented -z flag is used or not. Is this OK? Maciek From grass-bugs at intevation.de Sun Sep 3 14:08:58 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Sun Sep 3 14:08:59 2006 Subject: [GRASS-dev] [bug #5085] (grass) gis.m & = eror; d.m & = O.K. Message-ID: <20060903120858.020341005DB@lists.intevation.de> jmockus@gmail.com wrote (Sun, Sep 3 2006 13:05:30): You have created another BT entry by chagnig the replies subject. I merged it into your report, but please don't again, just reply to the old one. > GRASS 6.3.cvs > (spearfish60):/home/md/grass-data/spearfish60/PERMANENT/vector > > gis.m > & Notes: 1. You don't have to issue "gis.m &"; "gis.m" alone is enough, it will go to the background automatically. 2. If you issued plain "cd" before copying/pasting here, your path would be shortened to "GRASS 6.3.cvs (spearfish60): ", which would make your meassage more readable. And you don't have to "cd /home/md/grass-data/spearfish60/PERMANENT/vector" before staring Grass, if that's not obvious. > d.mon start=gism ? This will not work. See eg. this thread to learn why: http://grass.itc.it/pipermail/grass-dev/2006-September/025478.html > PNG: GRASS_TRUECOLOR status: FALSE > PNG: collecting to file: map.png, > GRASS_WIDTH=640, GRASS_HEIGHT=480 > Graphics driver [gism] started > [1]+ Done gis.m > GRASS 6.3.cvs > (spearfish60):/home/md/grass-data/spearfish60/PERMANENT/vector > > d.vect map=roads > GRASS 6.3.cvs > (spearfish60):/home/md/grass-data/spearfish60/PERMANENT/vector > > > NO ERRORS, NO RESULTS Correct. Nothing should happen. What happens if you use gis.m like you should, ie. add a layer and display it (in spearfish60)? You haven't answered to my previous question: Are your precompiled binaries downloaded from Grass website or else? Is the bug still reproducible with current CVS snapshot? Maciek P.S. Again, please don't write in html. -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Sun Sep 3 15:12:47 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sun Sep 3 15:12:52 2006 Subject: [GRASS-dev] [bug #5090] (grass) [No Subject Given] Message-ID: <20060903131247.F0FE81005DE@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5090 ------------------------------------------------------------------------- ------=_Part_97359_26405397.1157289162711 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Thanks for additional information: Currently, there is no mechanism by which another process can control what is displayed in gis.m. Such a feature would be useful, but implementing it would be non-trivial. So now I will use d.m that works well and gis.m not too friendly. Best regards -- Jonas Mockus e-mail: jmockus@gmail.com ------=_Part_97359_26405397.1157289162711 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,
Thanks for additional information:
Currently, there is no mechanism by which another process can control
what is displayed in gis.m. Such a feature would be useful, but
implementing it would be non-trivial.
So now I will use d.m that works well and gis.m not too friendly.
Best regards

--
Jonas Mockus
e-mail:
jmockus@gmail.com ------=_Part_97359_26405397.1157289162711-- --- Headers Follow --- >From jmockus@gmail.com Sun Sep 3 15:12:47 2006 Return-Path: Delivered-To: grass-bugs@lists.intevation.de Received: from kolab.intevation.de (aktaia [212.95.126.10]) by lists.intevation.de (Postfix) with ESMTP id D2FD61005DB for ; Sun, 3 Sep 2006 15:12:47 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id BC11B111F4E for ; Sun, 3 Sep 2006 15:12:47 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 9CF11110BBF for ; Sun, 3 Sep 2006 15:12:47 +0200 (CEST) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.232]) by kolab.intevation.de (Postfix) with ESMTP id D949010DFE3 for ; Sun, 3 Sep 2006 15:12:46 +0200 (CEST) Received: by wx-out-0506.google.com with SMTP id t15so1539754wxc for ; Sun, 03 Sep 2006 06:12:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=hvVxeAHGvcXFje1xDmFWtettgdNhqFgNYslODCAsC3ophDamWxH07fHUICyYPdzC1T8w9n2ozf66VVZ06EzD1KGkJ3/MW9zTV1gfusFE7m9kdtC97L+MQfwIOZpbAsE5gfBEw8Q9rRX9mK7iqHKdV4N2BBsSvS3vkuKNafFO6nk= Received: by 10.70.129.5 with SMTP id b5mr5809226wxd; Sun, 03 Sep 2006 06:12:42 -0700 (PDT) Received: by 10.70.11.18 with HTTP; Sun, 3 Sep 2006 06:12:42 -0700 (PDT) Message-ID: <9140b6030609030612o7c6aeec9qf2ceca846f1b6125@mail.gmail.com> Date: Sun, 3 Sep 2006 16:12:42 +0300 From: "jonas mockus" To: "Maciek Sieczka via RT" Subject: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_97359_26405397.1157289162711" X-Virus-Scanned: by amavisd-new at intevation.de X-Spam-Status: No, hits=-2.981 tagged_above=-999 required=3 tests=[BAYES_00=-5, HTML_20_30=0.226, HTML_MESSAGE=0.5, MISSING_SUBJECT=1.226, RCVD_BY_IP=0.067] X-Spam-Level: -------------------------------------------- Managed by Request Tracker From grass4u at gmail.com Sun Sep 3 19:23:52 2006 From: grass4u at gmail.com (Huidae Cho) Date: Sun Sep 3 19:24:39 2006 Subject: [GRASS-dev] gis.m patch In-Reply-To: References: <20060902063219.GA78577@localhost.tamu.edu> Message-ID: <20060903172352.GA1413@localhost> On Sat, Sep 02, 2006 at 01:06:50PM -0700, Michael Barton wrote: > This is GREAT. Thanks very much. I have a couple questions. > > 1. Is there a binary version of this available for people to try? No, not yet. Since the native winGRASS runs on MSys, users need to install various MSys/GnuWin32 packages as well as GRASS. I want to distribute a whole system including MSys/GnuWin32 binaries, but I'm not sure about license issues related to redistribution. It looks like most of packages are under GPL licenses, so can I? It could be really annoying for non-techy users to choose right packages from their sites (it's not like Cygwin). > 2. Do your changes affect how gism runs on any other platform? No. It shouldn't because what I've done is to change /dev/null to nul only if its platform is MSys. > 3. Could you give me a brief one-liner of what each change to gism is > intended to do so I can find a way to keep this in the code if it does have > issues on other platforms? As mentioned above, the only problem was the null device. On Windows, it's called "nul" and that's the only change that I made. > 4. Does NVIZ work? > No. The configure message below is misleading because I tried to use libW11, which WAS part of grass5. > Great news (even though I don't use Windows) Me neither except for building winGRASS :-(. Huidae > > 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: Huidae Cho > > Date: Sat, 2 Sep 2006 01:32:19 -0500 > > To: > > Subject: [GRASS-dev] gis.m patch > > > > Hi, > > > > I've patched gis.m so that it can run on Windows natively with the help > > of direct rendering. PDCurses lets the user to start in text mode, but > > since there are no monitors available, gis.m is the only option for now. > > > > http://geni.ath.cx/grass/native_wingrass.png shows gis.m running on > > MS-Windows (not Cygwin). > > > > Huidae > > > > GRASS is now configured for: i686-pc-mingw32 > > > > Source directory: /home/song/usr/grass/grass6 > > Build directory: /home/song/usr/grass/grass6 > > Installation directory: /usr/local/grass-6.3.cvs > > Startup script in directory: ${exec_prefix}/bin > > C compiler: gcc -g -O2 -D__W98__ > > C++ compiler: c++ -g -O2 > > FORTRAN compiler: > > Building shared libraries: yes > > 64bit support: no > > OpenGL platform: Windows > > > > NVIZ: yes > > > > BLAS support: no > > C++ support: yes > > DWG support: no > > FFMPEG support: no > > FFTW support: yes > > FreeType support: yes > > GDAL support: yes > > GLw support: no > > JPEG support: yes > > LAPACK support: no > > Large File Support (LFS): no > > Motif support: no > > MySQL support: no > > NLS support: no > > ODBC support: no > > OGR support: yes > > OpenGL support: yes > > PNG support: yes > > PostgreSQL support: yes > > Python support: no > > Readline support: yes > > SQLite support: yes > > Tcl/Tk support: yes > > TIFF support: yes > > X11 support: yes > > > > > > Index: gui/tcltk/gis.m/gm.tcl > > =================================================================== > > RCS file: /grassrepository/grass6/gui/tcltk/gis.m/gm.tcl,v > > retrieving revision 1.25 > > diff -u -r1.25 gm.tcl > > --- gui/tcltk/gis.m/gm.tcl 24 Aug 2006 18:04:57 -0000 1.25 > > +++ gui/tcltk/gis.m/gm.tcl 2 Sep 2006 06:00:41 -0000 > > @@ -69,6 +69,12 @@ > > set execom "spawn" > > } > > > > +if {[info exists env(MSYSCON)]} { > > + set mingw "1" > > +} { > > + set mingw "0" > > +} > > + > > #fetch GRASS Version number: > > set fp [open $env(GISBASE)/etc/VERSIONNUMBER r] > > set GRASSVERSION [read -nonewline $fp] > > @@ -188,7 +194,13 @@ > > # Determine if an element already exists > > > > proc Gm::element_exists {elem name} { > > - set failure [catch {exec [list "|g.findfile" "element=$elem" "file=$name"] > > >& /dev/null}] > > + global mingw > > + > > + if { $mingw == "1" } { > > + set failure [catch {exec [list "|g.findfile" "element=$elem" "file=$name"] > > >& nul}] > > + } { > > + set failure [catch {exec [list "|g.findfile" "element=$elem" "file=$name"] > > >& /dev/null}] > > + } > > > > return [expr {! $failure}] > > } > > Index: gui/tcltk/gis.m/gmmenu.tcl > > =================================================================== > > RCS file: /grassrepository/grass6/gui/tcltk/gis.m/gmmenu.tcl,v > > retrieving revision 1.15 > > diff -u -r1.15 gmmenu.tcl > > --- gui/tcltk/gis.m/gmmenu.tcl 20 Jul 2006 17:43:19 -0000 1.15 > > +++ gui/tcltk/gis.m/gmmenu.tcl 2 Sep 2006 06:00:41 -0000 > > @@ -19,6 +19,7 @@ > > global mon > > global filename > > global env > > +global mingw > > > > # Put this at the top of the file menu. > > set GuiMenu::Menu_File_Top [subst { > > @@ -48,10 +49,20 @@ > > lappend descmenu all > > lappend descmenu options > > lappend descmenu $tmenu > > -lappend descmenu [subst { > > - {command {[G_msg "GRASS help"]} {} "g.manual" {} -command { exec g.manual -i > > > /dev/null & } } > > - {command {[G_msg "GIS Manager &help"]} {} {[G_msg "GIS Manager help"]} {} > > -command { exec g.manual gis.m > /dev/null & } } > > - {command {[G_msg "About &GRASS"]} {} {[G_msg "About GRASS"]} {} -command { > > source $env(GISBASE)/etc/gm/grassabout.tcl} } > > - {command {[G_msg "About &System"]} {} {[G_msg "About System"]} {} -command { > > exec $env(GRASS_WISH) $env(GISBASE)/etc/gm/tksys.tcl --tcltk & }} > > - }] > > > > +# MinGW > > +if { $mingw == "1" } { > > + lappend descmenu [subst { > > + {command {[G_msg "GRASS help"]} {} "g.manual" {} -command { exec g.manual > > -i >& nul } } > > + {command {[G_msg "GIS Manager &help"]} {} {[G_msg "GIS Manager help"]} {} > > -command { exec g.manual gis.m >& nul } } > > + {command {[G_msg "About &GRASS"]} {} {[G_msg "About GRASS"]} {} -command { > > source $env(GISBASE)/etc/gm/grassabout.tcl} } > > + {command {[G_msg "About &System"]} {} {[G_msg "About System"]} {} -command > > { exec $env(GRASS_WISH) $env(GISBASE)/etc/gm/tksys.tcl --tcltk & }} > > + }] > > +} { > > + lappend descmenu [subst { > > + {command {[G_msg "GRASS help"]} {} "g.manual" {} -command { exec g.manual > > -i > /dev/null & } } > > + {command {[G_msg "GIS Manager &help"]} {} {[G_msg "GIS Manager help"]} {} > > -command { exec g.manual gis.m > /dev/null & } } > > + {command {[G_msg "About &GRASS"]} {} {[G_msg "About GRASS"]} {} -command { > > source $env(GISBASE)/etc/gm/grassabout.tcl} } > > + {command {[G_msg "About &System"]} {} {[G_msg "About System"]} {} -command > > { exec $env(GRASS_WISH) $env(GISBASE)/etc/gm/tksys.tcl --tcltk & }} > > + }] > > +} > > Index: gui/tcltk/gis.m/runandoutput.tcl > > =================================================================== > > RCS file: /grassrepository/grass6/gui/tcltk/gis.m/runandoutput.tcl,v > > retrieving revision 1.12 > > diff -u -r1.12 runandoutput.tcl > > --- gui/tcltk/gis.m/runandoutput.tcl 27 Aug 2006 21:19:26 -0000 1.12 > > +++ gui/tcltk/gis.m/runandoutput.tcl 2 Sep 2006 06:00:41 -0000 > > @@ -169,11 +169,17 @@ > > > > > > > ##############################################################################> > # > > proc run {cmd args} { > > + global mingw > > + > > # This and runcmd are being used to run command in the background > > # These used to go to stdout and stderr > > # but we don't want to pollute that console. > > # eval exec -- $cmd $args >@ stdout 2>@ stderr > > - eval [list exec -- $cmd] $args >& /dev/null > > + if { $mingw == "1" } { > > + eval [list exec -- $cmd] $args >& nul > > + } { > > + eval [list exec -- $cmd] $args >& /dev/null > > + } > > } > > > > > > > ##############################################################################> > # > > Index: lib/gtcltk/gronsole.tcl > > =================================================================== > > RCS file: /grassrepository/grass6/lib/gtcltk/gronsole.tcl,v > > retrieving revision 1.6 > > diff -u -r1.6 gronsole.tcl > > --- lib/gtcltk/gronsole.tcl 27 Aug 2006 21:19:26 -0000 1.6 > > +++ lib/gtcltk/gronsole.tcl 2 Sep 2006 06:00:43 -0000 > > @@ -425,10 +425,16 @@ > > > > proc Gronsole::execout {path cmd ci execcmd} { > > global env > > + global mingw > > + > > set mark cmdinsert$ci > > > > # Actually run the program > > - set cmd [concat | $cmd 2>@ stdout] > > + if { $mingw == "1" } { > > + set cmd [concat | $cmd] > > + } { > > + set cmd [concat | $cmd 2>@ stdout] > > + } > > > > set message_env [exec g.gisenv get=GRASS_MESSAGE_FORMAT] > > set env(GRASS_MESSAGE_FORMAT) gui > > Index: lib/gtcltk/options.tcl > > =================================================================== > > RCS file: /grassrepository/grass6/lib/gtcltk/options.tcl,v > > retrieving revision 1.7 > > diff -u -r1.7 options.tcl > > --- lib/gtcltk/options.tcl 19 May 2006 21:19:16 -0000 1.7 > > +++ lib/gtcltk/options.tcl 2 Sep 2006 06:00:43 -0000 > > @@ -98,3 +98,9 @@ > > if { $osxaqua == "1"} { > > set keycontrol "Command" > > } > > + > > +if {[info exists env(MSYSCON)]} { > > + set mingw "1" > > +} else { > > + set mingw "0" > > +} > > > > > From glynn at gclements.plus.com Sun Sep 3 23:07:35 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Sep 3 23:07:46 2006 Subject: [GRASS-dev] gis.m patch In-Reply-To: <20060903172352.GA1413@localhost> References: <20060902063219.GA78577@localhost.tamu.edu> <20060903172352.GA1413@localhost> Message-ID: <17659.17431.352958.556962@cerise.gclements.plus.com> Huidae Cho wrote: > > This is GREAT. Thanks very much. I have a couple questions. > > > > 1. Is there a binary version of this available for people to try? > > No, not yet. Since the native winGRASS runs on MSys, users need to > install various MSys/GnuWin32 packages as well as GRASS. I want to > distribute a whole system including MSys/GnuWin32 binaries, but I'm not > sure about license issues related to redistribution. It looks like most > of packages are under GPL licenses, so can I? It could be really > annoying for non-techy users to choose right packages from their sites > (it's not like Cygwin). Most of the packages you are likely to need will allow bundling with GRASS in a single installer or archive. The only case which might be problematic is if you are using ActiveState Tcl/Tk; the licencing conditions for that looked like they might be problematic, so I've been using the standard Tcl/Tk packages built from source instead. > > 3. Could you give me a brief one-liner of what each change to gism is > > intended to do so I can find a way to keep this in the code if it does have > > issues on other platforms? > > As mentioned above, the only problem was the null device. On Windows, > it's called "nul" and that's the only change that I made. There is also this one: # Actually run the program - set cmd [concat | $cmd 2>@ stdout] + if { $mingw == "1" } { + set cmd [concat | $cmd] + } { + set cmd [concat | $cmd 2>@ stdout] + } What happens without that change? > > 4. Does NVIZ work? > > No. The configure message below is misleading because I tried to use > libW11, which WAS part of grass5. Note that NVIZ does work natively under Windows (using MinGW/MSys); the only problem I ran into was that you need to redirect NVIZ' stdin from /dev/null otherwise "exec" hangs (redirect stdin within the exec command doesn't work). -- Glynn Clements From landa.martin at gmail.com Sun Sep 3 23:41:59 2006 From: landa.martin at gmail.com (Martin Landa) Date: Sun Sep 3 23:42:04 2006 Subject: [GRASS-dev] r.info -g Message-ID: Hi all, r.info module has a lot of flags [1] which print *given* information to stdout. From my point of view it would be better (maybe) to have only *one* flag for this purpose, e.g. -g Print basic information in shell script style What do you think about it? It should not break any scripts in CVS tree (maybe Add-ons?). Sure, it is not a good way -- to break backward compatibility... on the other hand, just adding new flag -g is not also nice solution. Best, Martin [1] -r Print range only -s Print raster map resolution (NS-res, EW-res) only -t Print raster map type only -g Print raster map region only -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From david.p.finlayson at gmail.com Mon Sep 4 02:48:09 2006 From: david.p.finlayson at gmail.com (David Finlayson) Date: Mon Sep 4 02:48:14 2006 Subject: [GRASS-dev] v.proj transforming z co-ordinates In-Reply-To: <44FAC060.1010306@o2.pl> References: <20060830153110.GT1046@bartok.itc.it> <44FAC060.1010306@o2.pl> Message-ID: Did you change datum? On 9/3/06, Maciej Sieczka wrote: > > Paul, > > I tried reprojecting a 3D points vector (3 arcsec strm) with v.proj, > from latlong WGS84 to UTM 34, and I see *no difference* in either x,y > or z coordinate, no matter whether the new implemented -z flag is used > or not. Is this OK? > > Maciek > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- David Finlayson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060903/3fdda1c3/attachment.html From hamish_nospam at yahoo.com Mon Sep 4 04:16:42 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Sep 4 04:18:30 2006 Subject: [GRASS-dev] Incorrect stuff coming through stderr? In-Reply-To: References: <17654.57386.176593.670128@cerise.gclements.plus.com> Message-ID: <20060904141642.7360df11.hamish_nospam@yahoo.com> Michael Barton wrote: > We are linking GRASS modules with a Java agent-based modeling > environment. The lack of consistency in GRASS output is an issue here, > as it is with trying to link GRASS with an interface building > platform. > > Because GRASS is a suite of command-line tools, it is an ideal > platform to be used by other platform for sophisticated modeling > (Python, Java, etc) as well as be wrapped in an interface platform to > serve as a full-featured GIS. Implement Java bindings for the SWIG interface? See QGIS<->GRASS module glue? > However, these become issues that range from annoyances (parsing > r.info) to impossibilities (parsing r.describe) when you try to use > GRASS from another environment than a user at a terminal. With r.info you have a point (although extending the -g flag as suggested by Martin could help that). For me r.info has all the flags I need (because we've added them as needed...), but v.info could use a parsable version of lines= boundaries= etc. What's so hard about parsing "r.describe -q1"? > It seems odd to me that progress messages are written to stderr. If you redirect stderr with "2> /dev/null" all that should be left is parsable output from stdout. > We also need a "quiet" option for all commands to suppress all stdout > except the actual output values. or otherwise stated, only parsable output should be sent to stdout. I agree with your basic tenet that as much functionalily as possible should be able to be dealt with by scripts or wrapper functions (i.e. generalized interoperability). I think we are well on our way to this already, certainly more so than the competition. Hamish From grass-bugs at intevation.de Mon Sep 4 04:51:05 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Mon Sep 4 04:51:07 2006 Subject: [GRASS-dev] [bug #5094] (grass) r.support from the GUI is broken Message-ID: <20060904025105.1D2781005B4@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5094 ------------------------------------------------------------------------- Subject: r.support from the GUI is broken Hi, If you launch r.support (r.support.sh actually) from the gis.m menu, you get to pick a map and then launch r.support in an xterm. As soon as you enter "y" or "n" at the prompt the xterm disappears. Replace "execute r.support.sh" with "term r.support" on line ~421 of menu.tcl for comparison with what should happen. The grass-run.sh script pauses if the module exited with an error. Maybe grass-xterm-wrapper should too? (this doesn't seem to help with the r.support problem though) Hamish -------------------------------------------- Managed by Request Tracker From Michael.Barton at asu.edu Mon Sep 4 06:10:11 2006 From: Michael.Barton at asu.edu (Michael Barton) Date: Mon Sep 4 06:11:32 2006 Subject: [GRASS-dev] Incorrect stuff coming through stderr? In-Reply-To: <20060904141642.7360df11.hamish_nospam@yahoo.com> Message-ID: > From: Hamish > Date: Mon, 4 Sep 2006 14:16:42 +1200 > To: Michael Barton > Cc: , > Subject: Re: [GRASS-dev] Incorrect stuff coming through stderr? > > Implement Java bindings for the SWIG interface? > See QGIS<->GRASS module glue? Actually, we don't even need SWIG. > >> However, these become issues that range from annoyances (parsing >> r.info) to impossibilities (parsing r.describe) when you try to use >> GRASS from another environment than a user at a terminal. > > With r.info you have a point (although extending the -g flag as > suggested by Martin could help that). For me r.info has all the flags I > need (because we've added them as needed...), but v.info could use a > parsable version of lines= boundaries= etc. But you can just get all the r.info data at once, and one flag seems to cancel out the others, so you can't accumulate them either. > > What's so hard about parsing "r.describe -q1"? Because the output varies depending on whether the map is latlon or projected, all positive or negative values, or some positive and some negative values. > > >> It seems odd to me that progress messages are written to stderr. > > If you redirect stderr with "2> /dev/null" all that should be left is > parsable output from stdout. > >> We also need a "quiet" option for all commands to suppress all stdout >> except the actual output values. > > or otherwise stated, only parsable output should be sent to stdout. > > > I agree with your basic tenet that as much functionalily as possible > should be able to be dealt with by scripts or wrapper functions (i.e. > generalized interoperability). I think we are well on our way to this > already, certainly more so than the competition. > I agree. It seems an opportune time to try to regularize across all of GRASS 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 tutey at o2.pl Mon Sep 4 07:47:29 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Sep 4 07:47:33 2006 Subject: [GRASS-dev] v.proj transforming z co-ordinates In-Reply-To: References: <20060830153110.GT1046@bartok.itc.it> <44FAC060.1010306@o2.pl> Message-ID: <44FBBDF1.50403@o2.pl> David Finlayson wrote: > Did you change datum? Dylan, No. I reprojected from latlon on WGS84 to UTM zone 34, which is also based on WGS84 datum. Maciek From hamish_nospam at yahoo.com Mon Sep 4 08:26:52 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Sep 4 08:27:13 2006 Subject: [GRASS-dev] v.bspline -> v.surf.bspline ? In-Reply-To: References: <44DD0000.8000301@o2.pl> <44ED7041.3090505@o2.pl> <44F95696.2020902@o2.pl> <1157197146.5122.40.camel@devel> <20060902124257.GA4023@bartok.itc.it> Message-ID: <20060904182652.19cf659e.hamish_nospam@yahoo.com> > 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: Index: Makefile =================================================================== 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 From rez at touchofmadness.com Mon Sep 4 09:28:14 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Mon Sep 4 09:28:19 2006 Subject: [GRASS-dev] v.proj transforming z co-ordinates In-Reply-To: References: Message-ID: <1157354894.5122.137.camel@devel> On Sun, 2006-08-27 at 00:00 +0100, Paul Kelly wrote: > I suspected v.proj was doing this for years (since the introduction of the > new vector format) but never got round to verifying the behaviour until > yesterday. When re-projecting a 3-D vector file, if datum transformation > parameters are specified using towgs84= notation (rather than nadgrids=), > v.proj will assume the z co-ordinates are ellipsoidal heights and > transform them accordingly. > > I think there are probably very few circumstances in which this behaviour > would be desirable. It is much more common for height data to be specified > relative to a vertical datum, e.g. mean sea level, than relative to the > ellipsoid (which is normally only used for horizontal distances). This is definitely desirable. I would almost consider not being able to project Z data a bug. > GPS data is more likely to include ellipsoidal height, but again it is > (IMHO) of questionable usefulness to transform it to another ellipsoid: > the geoid models that exist to transform GPS data to the local vertical > datum in regular use (OSGM02 for Great Britain and Northern Ireland is the > one I'm familiar with) convert directly from WGS84 ellipsoidal height data > to height above mean sea level. I would reject projections involving different geoids. Otherwise, Z data may be corrupted. At a minimum, a big fat disclaimer, but I would prefer checking geoids and error if needed. > I propose the attached patch to add a specific flag to v.proj to enable > the current behaviour, otherwise the z co-ordinates are always left > untouched. I thought it was worth explaining and discussing properly > because it changes the current behaviour and will give different results > in certain circumstances, but IMHO the current behaviour is wrong. Does your patch lacks output of Z data (I see it does calculate values)? Other than the comments above, I'd like to see it applied. Great job! -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From Michael.Barton at asu.edu Mon Sep 4 09:28:04 2006 From: Michael.Barton at asu.edu (Michael Barton) Date: Mon Sep 4 09:29:22 2006 Subject: [GRASS-dev] r.info -g In-Reply-To: Message-ID: I very much agree. This the very thing I was posting about yesterday. 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: Martin Landa > Date: Sun, 3 Sep 2006 23:41:59 +0200 > To: grass-dev > Subject: [GRASS-dev] r.info -g > > Hi all, > > r.info module has a lot of flags [1] which print *given* information > to stdout. From my point of view it would be better (maybe) to have > only *one* flag for this purpose, e.g. > > -g Print basic information in shell script style > > What do you think about it? It should not break any scripts in CVS > tree (maybe Add-ons?). Sure, it is not a good way -- to break backward > compatibility... on the other hand, just adding new flag -g is not > also nice solution. > > Best, Martin > > [1] > -r Print range only > -s Print raster map resolution (NS-res, EW-res) only > -t Print raster map type only > -g Print raster map region only > > -- > Martin Landa * http://gama.fsv.cvut.cz/~landa * > > From rez at touchofmadness.com Mon Sep 4 10:57:10 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Mon Sep 4 10:57:17 2006 Subject: [GRASS-dev] r.info -g In-Reply-To: References: Message-ID: <1157360230.5122.161.camel@devel> I also agree. Output everything in a machine readable format that isn't visually difficult to navigate. It's only a few lines of information at the most. However, it may be beneficial to some to have '-r' remain separate (may break user scripts?). On Mon, 2006-09-04 at 00:28 -0700, Michael Barton wrote: > I very much agree. This the very thing I was posting about yesterday. > > 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: Martin Landa > > Date: Sun, 3 Sep 2006 23:41:59 +0200 > > To: grass-dev > > Subject: [GRASS-dev] r.info -g > > > > Hi all, > > > > r.info module has a lot of flags [1] which print *given* information > > to stdout. From my point of view it would be better (maybe) to have > > only *one* flag for this purpose, e.g. > > > > -g Print basic information in shell script style > > > > What do you think about it? It should not break any scripts in CVS > > tree (maybe Add-ons?). Sure, it is not a good way -- to break backward > > compatibility... on the other hand, just adding new flag -g is not > > also nice solution. > > > > Best, Martin > > > > [1] > > -r Print range only > > -s Print raster map resolution (NS-res, EW-res) only > > -t Print raster map type only > > -g Print raster map region only > > > > -- > > Martin Landa * http://gama.fsv.cvut.cz/~landa * -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From neteler at itc.it Mon Sep 4 11:33:57 2006 From: neteler at itc.it (Markus Neteler) Date: Mon Sep 4 11:33:59 2006 Subject: [GRASS-dev] v.bspline -> v.surf.bspline ? In-Reply-To: <20060904182652.19cf659e.hamish_nospam@yahoo.com> References: <44DD0000.8000301@o2.pl> <44ED7041.3090505@o2.pl> <44F95696.2020902@o2.pl> <1157197146.5122.40.camel@devel> <20060902124257.GA4023@bartok.itc.it> <20060904182652.19cf659e.hamish_nospam@yahoo.com> Message-ID: <20060904093357.GA17705@bartok.itc.it> 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 From grass-bugs at intevation.de Mon Sep 4 11:41:27 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Mon Sep 4 11:41:30 2006 Subject: [GRASS-dev] [bug #5095] (grass) gis.m: non-existant column name in thematic layer leads to non-existant gismlegend.txt error and frozen display Message-ID: <20060904094127.4D7281005AD@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5095 ------------------------------------------------------------------------- Subject: gis.m: non-existant column name in thematic layer leads to non-existant gismlegend.txt error and frozen display Platform: GNU/Linux/x86 grass obtained from: CVS grass binary for platform: Compiled from Sources GRASS Version: cvs_head_20060829 As gis.m doesn't trap the error of a wrong column name in d.vect.thematic, it then goes on to try to create a legend, but cannot find gismlegend.txt. It then freezes the display. To reproduce in spearfish: - in gis.m, add thematic layer - chose any of the relevant vector files (I used landcover) - give a ficticious column name in the attribute column field - launch display The problem seems to be in commonlayer.tcl which doesn't seem to trap error messages from the command (although I don't have the time to try to understand all the code there) and in thematic.tcl (line 536) where the legend is created even if the command was unsuccessful. Moritz -------------------------------------------- Managed by Request Tracker From hamish_nospam at yahoo.com Mon Sep 4 11:47:11 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Sep 4 11:47:18 2006 Subject: [GRASS-dev] backwards sliders in NVIZ Message-ID: <20060904214711.65c991e2.hamish_nospam@yahoo.com> Hi, I'm working on a longstanding annoyance in NVIZ: many of the sliders are presented backwards. (e.g. lighting levels) this fix isn't complete though: if you type in a new out of range value & hit (e.g. Red=1.5) it goes backwards. More importantly, the vector points size slider gets stuck until you type in a new out of range value. ?? ideas? Hamish Index: widgets.tcl =================================================================== RCS file: /home/grass/grassrepository/grass6/visualization/nviz/scripts/widgets.tcl,v retrieving revision 1.2 diff -u -r1.2 widgets.tcl --- widgets.tcl 1 Aug 2005 17:57:15 -0000 1.2 +++ widgets.tcl 4 Sep 2006 09:33:38 -0000 @@ -165,10 +165,10 @@ } if {[expr $val < $min]} then { - $S.scale configure -to $val + $S.scale configure -from $val } if {[expr $val > $max]} then { - $S.scale configure -from $val + $S.scale configure -to $val } if {$val != 0} { if {[expr abs($val)] < [expr abs($res)]} { Index: panel_lights.tcl =================================================================== RCS file: /home/grass/grassrepository/grass6/visualization/nviz/scripts/panel_lights.tcl,v retrieving revision 2.0 diff -u -r2.0 panel_lights.tcl --- panel_lights.tcl 9 Nov 2004 14:18:38 -0000 2.0 +++ panel_lights.tcl 4 Sep 2006 09:33:38 -0000 @@ -41,15 +41,15 @@ -variable Nv_(FollowView) -command follow -onvalue 1 -offvalue 0 checkbutton $BASE.top.left.show -relief flat -text "Show Model" \ -variable Nv_(ShowModel) - Nv_mkScale $BASE.top.left.bright h Brightness 100 0 80 set_brt 2 - Nv_mkScale $BASE.top.left.ambient h Ambient 100 0 20 set_amb 2 + Nv_mkScale $BASE.top.left.bright h Brightness 0 100 80 set_brt 2 + Nv_mkScale $BASE.top.left.ambient h Ambient 0 100 20 set_amb 2 pack $BASE.top.left.follow $BASE.top.left.show \ $BASE.top.left.bright $BASE.top.left.ambient \ -side top -fill x -expand 1 - Nv_mkScale $BASE.top.right.red h Red 100 0 100 set_red 2 - Nv_mkScale $BASE.top.right.green h Green 100 0 100 set_green 2 - Nv_mkScale $BASE.top.right.blue h Blue 100 0 100 set_blue 2 + Nv_mkScale $BASE.top.right.red h Red 0 100 100 set_red 2 + Nv_mkScale $BASE.top.right.green h Green 0 100 100 set_green 2 + Nv_mkScale $BASE.top.right.blue h Blue 0 100 100 set_blue 2 pack $BASE.top.right.red $BASE.top.right.green $BASE.top.right.blue \ -side top -expand 1 From rez at touchofmadness.com Mon Sep 4 12:54:07 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Mon Sep 4 12:54:15 2006 Subject: [GRASS-dev] v.in.ogr broken (\w shp) In-Reply-To: <20060903195933.39429ed5.hamish_nospam@yahoo.com> References: <1157126513.17352.65.camel@devel> <20060903195933.39429ed5.hamish_nospam@yahoo.com> Message-ID: <1157367247.5122.188.camel@devel> On Sun, 2006-09-03 at 19:59 +1200, Hamish wrote: > Brad Douglas wrote: > > Is there an easy fix for this? I'm trying to import a shapefile and > > I'm not terribly familiar with this part of the GRASS architecture. > > > > GRASS 6.3.cvs (hamilton):~/hamilton > v.in.ogr dsn=. output=roads > > layer=17 > > Projection of input dataset and current location appear to match. > > Proceeding with import... > > Layer: 17 > > DBMI-DBF driver error: > > Column 'ADMIN_CLAS' already exists (duplicate name) > > Cannot create table. > > Error in db_execute_immediate() > > > > ERROR: Cannot create table: create table roads (cat integer, PREFIX > > varchar > > ( 2 ), NAME varchar ( 30 ), TYPE varchar ( 4 ), SUFFIX varchar > > ( 2 > > ), FCC varchar ( 3 ), FIPS varchar ( 11 ), ID integer, > > FULL_NAME varchar ( 40 ), ADMIN_CLAS varchar ( 40 ), CATEGORY > > integer, ST_CNTY_FI varchar ( 11 ), RD_CLASS varchar ( 4 ), > > RTE_NUM1 > > varchar > > ( 4 ), RTE_NUM2 varchar ( 4 ), ADMIN_CLAS integer, AREA double > > precision, LEN double precision) > > GRASS 6.3.cvs (hamilton):~/hamilton > > > > DBF limits column names to 10 chars; you end up with "ADMIN_CLAS" twice > in the above list. Either change DB column names or user the v.in.ogr > cnames= option to rename columns to something unique. (hint, cut & paste > above list with modification). Maybe changing DB to SQLite or something > helps too? Ahh! Thanks! However, this does present a usability issue. This is a problem many, people will encounter. I was trying to import a standard USGS product. How about when v.in.ogr encounters this, offer a suggestion to fix, rather than simply erroring out? We could almost cut and paste your answer above. At least something a little less terse than, "ERROR: Cannot create table: [SQL statement]". That describes nothing about the problem encountered (duplicate columns)[1]. What do you think? [1] Yes, I do [now] realize that upon close inspection and decent knowledge of SQL92, one can readily solve the problem. :-) -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From grass-bugs at intevation.de Mon Sep 4 13:18:14 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Mon Sep 4 13:18:16 2006 Subject: [GRASS-dev] [bug #5096] (grass) can't read "_data(.gronsole.gronsole, 4, donecmd)": no such element in array Message-ID: <20060904111814.A6ED51005AD@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5096 ------------------------------------------------------------------------- Subject: can't read "_data(.gronsole.gronsole,4,donecmd)": no such element in array Platform: Mac OSX grass obtained from: Other (CDROM etc) grass binary for platform: Compiled from Sources GRASS Version: 6.2.b2 Using the MacOSX universal binaries from William's web site, I get the following error when I try to display a map from the GIS manager. The GUI is then frozen and I have to leave GRASS and restart it to be able to use the GUI again: can't read "_data(.gronsole.gronsole,4,donecmd)": no such element in array can't read "_data(.gronsole.gronsole,4,donecmd)": no such element in array while executing "set donecmd $_data($path,$ci,donecmd)" (procedure "Gronsole::done_command" line 3) invoked from within "Gronsole::done_command $path $ci" (procedure "Gronsole::execout" line 19) invoked from within "Gronsole::execout $path $cmd $ci Gronsole::execwait" (procedure "Gronsole::run_wait" line 6) invoked from within "Gronsole::run_wait .gronsole.gronsole {d.vect map=communes@PERMANENT color=0:0:0 lcolor=0:0:0 fcolor=170:170:170 display=shape type=point,line,boundar..." ("eval" body line 1) invoked from within "eval Gronsole::$cmd .gronsole.gronsole $args" (procedure ".gronsole.gronsole" line 1) invoked from within "$gronsole run_wait $cmd gism" (procedure "run_panel" line 4) invoked from within "run_panel $cmd" (procedure "GmCommonLayer::display_commands" line 28) invoked from within "GmCommonLayer::display_commands $namespace $id [list $cmd]" (procedure "GmCommonLayer::display_command" line 2) invoked from within "GmCommonLayer::display_command [namespace current] $id $cmd" (procedure "GmVector::display" line 113) invoked from within "GmVector::display $node $mod" ("vector" arm line 2) invoked from within "switch $type { group { GmGroup::display $node $mod } raster { GmRaster::display $node $mod } labels { GmLabels::disp..." (procedure "GmTree::display_node" line 7) invoked from within "GmTree::display_node $n $mod" (procedure "GmGroup::display" line 25) invoked from within "GmGroup::display "root" $mod" (procedure "MapCanvas::runprograms" line 69) invoked from within "MapCanvas::runprograms $mon [expr {$mymodified != 0}]" (procedure "MapCanvas::drawmap" line 38) invoked from within "MapCanvas::drawmap $mon" (procedure "MapCanvas::display_server" line 9) invoked from within "MapCanvas::display_server" ("after" script) My system: Imac Intel 1,83GHz 1,5RAM OSX 10.4.7 -------------------------------------------- Managed by Request Tracker From neteler at itc.it Mon Sep 4 13:24:21 2006 From: neteler at itc.it (Markus Neteler) Date: Mon Sep 4 13:24:23 2006 Subject: [GRASS-dev] v.in.ogr broken (\w shp) In-Reply-To: <1157367247.5122.188.camel@devel> References: <1157126513.17352.65.camel@devel> <20060903195933.39429ed5.hamish_nospam@yahoo.com> <1157367247.5122.188.camel@devel> Message-ID: <20060904112420.GD17705@bartok.itc.it> On Mon, Sep 04, 2006 at 03:54:07AM -0700, Brad Douglas wrote: > On Sun, 2006-09-03 at 19:59 +1200, Hamish wrote: > > Brad Douglas wrote: > > > Is there an easy fix for this? I'm trying to import a shapefile and > > > I'm not terribly familiar with this part of the GRASS architecture. > > > > > > GRASS 6.3.cvs (hamilton):~/hamilton > v.in.ogr dsn=. output=roads > > > layer=17 > > > Projection of input dataset and current location appear to match. > > > Proceeding with import... > > > Layer: 17 > > > DBMI-DBF driver error: > > > Column 'ADMIN_CLAS' already exists (duplicate name) > > > Cannot create table. > > > Error in db_execute_immediate() > > > > > > ERROR: Cannot create table: create table roads (cat integer, PREFIX > > > varchar > > > ( 2 ), NAME varchar ( 30 ), TYPE varchar ( 4 ), SUFFIX varchar > > > ( 2 > > > ), FCC varchar ( 3 ), FIPS varchar ( 11 ), ID integer, > > > FULL_NAME varchar ( 40 ), ADMIN_CLAS varchar ( 40 ), CATEGORY > > > integer, ST_CNTY_FI varchar ( 11 ), RD_CLASS varchar ( 4 ), > > > RTE_NUM1 > > > varchar > > > ( 4 ), RTE_NUM2 varchar ( 4 ), ADMIN_CLAS integer, AREA double > > > precision, LEN double precision) > > > GRASS 6.3.cvs (hamilton):~/hamilton > > > > > > > DBF limits column names to 10 chars; you end up with "ADMIN_CLAS" twice > > in the above list. Either change DB column names or user the v.in.ogr > > cnames= option to rename columns to something unique. (hint, cut & paste > > above list with modification). Maybe changing DB to SQLite or something > > helps too? > > Ahh! Thanks! > > However, this does present a usability issue. This is a problem many, > people will encounter. I was trying to import a standard USGS product. > > How about when v.in.ogr encounters this, offer a suggestion to fix, > rather than simply erroring out? We could almost cut and paste your > answer above. At least something a little less terse than, "ERROR: > Cannot create table: [SQL statement]". That describes nothing about the > problem encountered (duplicate columns)[1]. > > What do you think? Such a message would be very useful. > [1] Yes, I do [now] realize that upon close inspection and decent > knowledge of SQL92, one can readily solve the problem. :-) Another option is to change the last char of the offending col(s) to an incrementing number: ADMIN_CLAS ADMIN_CLA1 ... Markus From hmitaso at unity.ncsu.edu Mon Sep 4 16:03:33 2006 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Mon Sep 4 16:03:40 2006 Subject: [GRASS-dev] v.in.ogr broken (\w shp) In-Reply-To: <1157367247.5122.188.camel@devel> References: <1157126513.17352.65.camel@devel> <20060903195933.39429ed5.hamish_nospam@yahoo.com> <1157367247.5122.188.camel@devel> Message-ID: On Sep 4, 2006, at 6:54 AM, Brad Douglas wrote: > On Sun, 2006-09-03 at 19:59 +1200, Hamish wrote: >> Brad Douglas wrote: >>> Is there an easy fix for this? I'm trying to import a shapefile and >>> I'm not terribly familiar with this part of the GRASS architecture. >>> >>> GRASS 6.3.cvs (hamilton):~/hamilton > v.in.ogr dsn=. output=roads >>> layer=17 >>> Projection of input dataset and current location appear to match. >>> Proceeding with import... >>> Layer: 17 >>> DBMI-DBF driver error: >>> Column 'ADMIN_CLAS' already exists (duplicate name) >>> Cannot create table. >>> Error in db_execute_immediate() >>> >>> ERROR: Cannot create table: create table roads (cat integer, PREFIX >>> varchar >>> ( 2 ), NAME varchar ( 30 ), TYPE varchar ( 4 ), SUFFIX >>> varchar >>> ( 2 >>> ), FCC varchar ( 3 ), FIPS varchar ( 11 ), ID integer, >>> FULL_NAME varchar ( 40 ), ADMIN_CLAS varchar ( 40 ), CATEGORY >>> integer, ST_CNTY_FI varchar ( 11 ), RD_CLASS varchar ( 4 ), >>> RTE_NUM1 >>> varchar >>> ( 4 ), RTE_NUM2 varchar ( 4 ), ADMIN_CLAS integer, AREA >>> double >>> precision, LEN double precision) >>> GRASS 6.3.cvs (hamilton):~/hamilton > >> >> >> DBF limits column names to 10 chars; you end up with "ADMIN_CLAS" >> twice >> in the above list. Either change DB column names or user the v.in.ogr >> cnames= option to rename columns to something unique. (hint, cut & >> paste >> above list with modification). Maybe changing DB to SQLite or >> something >> helps too? > > Ahh! Thanks! > > However, this does present a usability issue. This is a problem many, > people will encounter. I was trying to import a standard USGS > product. I wanted to ask about it as I had exactly the same problem just few days ago - I believe I was importing USGS roads too. > > How about when v.in.ogr encounters this, offer a suggestion to fix, > rather than simply erroring out? We could almost cut and paste your > answer above. At least something a little less terse than, "ERROR: > Cannot create table: [SQL statement]". That describes nothing > about the > problem encountered (duplicate columns)[1]. it actually says that, but it does not explain that the duplicate column is due to the 10chars limit so I was rather confused too. >>> Column 'ADMIN_CLAS' already exists (duplicate name) so a suggestion for a solution would be helpful. If DBF does not work directly with a standard USGS product it is one more reason to change the default DBMS in future (GRASS7?) Helena > > What do you think? > > [1] Yes, I do [now] realize that upon close inspection and decent > knowledge of SQL92, one can readily solve the problem. :-) > > -- > Brad Douglas KB8UYR > Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From grass-bugs at intevation.de Mon Sep 4 16:52:02 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Mon Sep 4 16:52:03 2006 Subject: [GRASS-dev] [bug #5097] (grass) d.vect.chart: add where option Message-ID: <20060904145202.0EDC71005C5@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5097 ------------------------------------------------------------------------- Subject: d.vect.chart: add where option Platform: GNU/Linux/x86 grass obtained from: CVS grass binary for platform: Compiled from Sources GRASS Version: cvs_head_20060904 It would be great to have a 'where' option in d.vect.chart. Moritz -------------------------------------------- Managed by Request Tracker From tutey at o2.pl Mon Sep 4 18:09:53 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Sep 4 18:09:58 2006 Subject: [GRASS-dev] v.in.ogr broken (\w shp) In-Reply-To: <20060903195933.39429ed5.hamish_nospam@yahoo.com> References: <1157126513.17352.65.camel@devel> <20060903195933.39429ed5.hamish_nospam@yahoo.com> Message-ID: <44FC4FD1.80207@o2.pl> Hamish wrote: > Brad Douglas wrote: >> Is there an easy fix for this? I'm trying to import a shapefile and >> I'm not terribly familiar with this part of the GRASS architecture. >> >> GRASS 6.3.cvs (hamilton):~/hamilton > v.in.ogr dsn=. output=roads >> layer=17 >> Projection of input dataset and current location appear to match. >> Proceeding with import... >> Layer: 17 >> DBMI-DBF driver error: >> Column 'ADMIN_CLAS' already exists (duplicate name) >> Cannot create table. >> Error in db_execute_immediate() >> >> ERROR: Cannot create table: create table roads (cat integer, PREFIX >> varchar >> ( 2 ), NAME varchar ( 30 ), TYPE varchar ( 4 ), SUFFIX varchar >> ( 2 >> ), FCC varchar ( 3 ), FIPS varchar ( 11 ), ID integer, >> FULL_NAME varchar ( 40 ), ADMIN_CLAS varchar ( 40 ), CATEGORY >> integer, ST_CNTY_FI varchar ( 11 ), RD_CLASS varchar ( 4 ), >> RTE_NUM1 >> varchar >> ( 4 ), RTE_NUM2 varchar ( 4 ), ADMIN_CLAS integer, AREA double >> precision, LEN double precision) >> GRASS 6.3.cvs (hamilton):~/hamilton > > DBF limits column names to 10 chars; Brad, Just curious: Hamish is right. And you are importing a shapefile, correct? So how could a column name longer than 10 chars be in the dbf shipped with that shapefile? ? Maciek From grass-bugs at intevation.de Mon Sep 4 18:13:15 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Mon Sep 4 18:13:17 2006 Subject: [GRASS-dev] [bug #5098] (grass) gis.m; tcltk error when zooming to map with name which exists in more than one mapset Message-ID: <20060904161315.D81B31005C5@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5098 ------------------------------------------------------------------------- Subject: gis.m; tcltk error when zooming to map with name which exists in more than one mapset Platform: GNU/Linux/x86 grass obtained from: CVS grass binary for platform: Compiled from Sources GRASS Version: cvs_head_20060904 When there are two maps with the same name in more than one of the accessible mapsets, then gis.m throws below tcltk error when I try to "zoom to selected map". To reproduce in spearfish, just copy any map from the PERMANENT mapset to the user1 mapset using the same name and then display it and zoom to it. If I enter @mapsetname (i.e. @user1) after the map name zooming to the map works. It is probably just a question of catching the WARNING message and ignoring it, or of adding the @mapsetname automatically (default to current mapset if not set otherwise). BTW, I find the warning message a bit weird: when I display roads from user1 I get the message "WARNING: 'vector/roads' was found in more mapsets (also found in user1)". In my understanding this should read "... (also found in PERMANENT)... WARNING: 'vector/roads' was found in more mapsets (also found in user1). WARNING: 'vector/roads' was found in more mapsets (also found in user1). while executing "close $input" (procedure "MapCanvas::zoom_gregion" line 11) invoked from within "MapCanvas::zoom_gregion $mon [list "vect=$map"]" (procedure "MapCanvas::zoom_map" line 48) invoked from within "MapCanvas::zoom_map $mon" invoked from within ".mapcan(1).mf.topf.tb0.mapzoom.zm invoke active" ("uplevel" body line 1) invoked from within "uplevel #0 [list $w invoke active]" (procedure "tk::MenuInvoke" line 50) invoked from within "tk::MenuInvoke .mapcan(1).mf.topf.tb0.mapzoom.zm 1" (command bound to event) Moritz -------------------------------------------- Managed by Request Tracker From neteler at itc.it Mon Sep 4 18:34:06 2006 From: neteler at itc.it (Markus Neteler) Date: Mon Sep 4 18:34:08 2006 Subject: [GRASS-dev] NVIZ volume revisited Message-ID: <20060904163406.GG17705@bartok.itc.it> Hi, with help from Roberto Flor (analysing the togl changes), I have modified togl_flythrough.c to avoid atoi() crash, a rather simple change. Testing with Slovakia3d [1], now it - goes into endless loop (but no longer crashes) with nviz el=dem500 vol=precip3d.500z50 Maybe easy to fix? - works fine with nviz el=dem500 and loading the volume from menu. Note: the volume rendering is MUCH faster now. Funny. We are getting close(r)... Markus [1] http://mpa.itc.it/grasstutor/data7/slovakia3d.tar.gz From michael.barton at asu.edu Mon Sep 4 18:37:35 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 4 18:38:08 2006 Subject: [GRASS-dev] v.bspline -> v.surf.bspline ? In-Reply-To: <20060904182652.19cf659e.hamish_nospam@yahoo.com> Message-ID: 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 > Date: Mon, 4 Sep 2006 18:26:52 +1200 > To: Helena Mitasova > Cc: , , , > , > Subject: Re: [GRASS-dev] v.bspline -> v.surf.bspline ? > > btw, it's missing from the TclTk menu, so are the other v.lidar.*. > > From michael.barton at asu.edu Mon Sep 4 18:44:45 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 4 18:45:22 2006 Subject: [GRASS-dev] backwards sliders in NVIZ In-Reply-To: <20060904214711.65c991e2.hamish_nospam@yahoo.com> Message-ID: I'm doing a bunch of bug fixes in gism. But I can take a look at this afterwards. Do you need to change the resolution setting? This sets the increment interval. Command-Line Name: -resolution Database Name: resolution Database Class: Resolution A real value specifying the resolution for the scale. If this value is greater than zero then the scale's value will always be rounded to an even multiple of this value, as will tick marks and the endpoints of the scale. If the value is less than zero then no rounding occurs. Defaults to 1 (i.e., the value will be integral). 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 > Date: Mon, 4 Sep 2006 21:47:11 +1200 > To: grass5 > Subject: [GRASS-dev] backwards sliders in NVIZ > > Hi, > > I'm working on a longstanding annoyance in NVIZ: many of the sliders are > presented backwards. (e.g. lighting levels) > > this fix isn't complete though: if you type in a new out of range value > & hit (e.g. Red=1.5) it goes backwards. More importantly, the vector > points size slider gets stuck until you type in a new out of range value. ?? > > ideas? > > Hamish > > > > Index: widgets.tcl > =================================================================== > RCS file: > /home/grass/grassrepository/grass6/visualization/nviz/scripts/widgets.tcl,v > retrieving revision 1.2 > diff -u -r1.2 widgets.tcl > --- widgets.tcl 1 Aug 2005 17:57:15 -0000 1.2 > +++ widgets.tcl 4 Sep 2006 09:33:38 -0000 > @@ -165,10 +165,10 @@ > } > > if {[expr $val < $min]} then { > - $S.scale configure -to $val > + $S.scale configure -from $val > } > if {[expr $val > $max]} then { > - $S.scale configure -from $val > + $S.scale configure -to $val > } > if {$val != 0} { > if {[expr abs($val)] < [expr abs($res)]} { > Index: panel_lights.tcl > =================================================================== > RCS file: > /home/grass/grassrepository/grass6/visualization/nviz/scripts/panel_lights.tcl > ,v > retrieving revision 2.0 > diff -u -r2.0 panel_lights.tcl > --- panel_lights.tcl 9 Nov 2004 14:18:38 -0000 2.0 > +++ panel_lights.tcl 4 Sep 2006 09:33:38 -0000 > @@ -41,15 +41,15 @@ > -variable Nv_(FollowView) -command follow -onvalue 1 -offvalue 0 > checkbutton $BASE.top.left.show -relief flat -text "Show Model" \ > -variable Nv_(ShowModel) > - Nv_mkScale $BASE.top.left.bright h Brightness 100 0 80 set_brt 2 > - Nv_mkScale $BASE.top.left.ambient h Ambient 100 0 20 set_amb 2 > + Nv_mkScale $BASE.top.left.bright h Brightness 0 100 80 set_brt 2 > + Nv_mkScale $BASE.top.left.ambient h Ambient 0 100 20 set_amb 2 > pack $BASE.top.left.follow $BASE.top.left.show \ > $BASE.top.left.bright $BASE.top.left.ambient \ > -side top -fill x -expand 1 > > - Nv_mkScale $BASE.top.right.red h Red 100 0 100 set_red 2 > - Nv_mkScale $BASE.top.right.green h Green 100 0 100 set_green 2 > - Nv_mkScale $BASE.top.right.blue h Blue 100 0 100 set_blue 2 > + Nv_mkScale $BASE.top.right.red h Red 0 100 100 set_red 2 > + Nv_mkScale $BASE.top.right.green h Green 0 100 100 set_green 2 > + Nv_mkScale $BASE.top.right.blue h Blue 0 100 100 set_blue 2 > pack $BASE.top.right.red $BASE.top.right.green $BASE.top.right.blue \ > -side top -expand 1 > > From neteler at itc.it Mon Sep 4 18:50:34 2006 From: neteler at itc.it (Markus Neteler) Date: Mon Sep 4 18:50:36 2006 Subject: [GRASS-dev] v.bspline -> v.surf.bspline ? In-Reply-To: References: <20060904182652.19cf659e.hamish_nospam@yahoo.com> Message-ID: <20060904165034.GI17705@bartok.itc.it> 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 From glynn at gclements.plus.com Mon Sep 4 19:32:57 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Sep 4 19:33:01 2006 Subject: [GRASS-dev] [bug #5094] (grass) r.support from the GUI is broken In-Reply-To: <20060904025105.1D2781005B4@lists.intevation.de> References: <20060904025105.1D2781005B4@lists.intevation.de> Message-ID: <17660.25417.983800.547612@cerise.gclements.plus.com> Request Tracker wrote: > this bug's URL: http://intevation.de/rt/webrt?serial_num=5094 > Subject: r.support from the GUI is broken > The grass-run.sh script pauses if the module exited with an error. Maybe > grass-xterm-wrapper should too? (this doesn't seem to help with the r.support > problem though) There is no point doing it in grass-xterm-wrapper, for several reasons: 1. grass-xterm-wrapper's stdout will typically be the pipe set up by Tcl's "exec" or "open |..." commands, its stderr will either refer to the same pipe or be redirected to /dev/null, and it won't have a stdin. 2. Once $GRASS_XTERM completes, the terminal window has gone; there doesn't seem to be much point pausing here. 3. xterm's exit code doesn't reflect the exit code of the program which is run via -e, so grass-xterm-wrapper doesn't know whether the command succeeded or failed. 4. Anything which d.m/gis.m run via an xterm needs to use grass-run.sh (otherwise the program may be unable to find the GRASS shared libraries), which already includes the pause. -- Glynn Clements From glynn at gclements.plus.com Mon Sep 4 19:37:06 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Sep 4 19:37:11 2006 Subject: [GRASS-dev] r.info -g In-Reply-To: References: Message-ID: <17660.25666.420259.755744@cerise.gclements.plus.com> Martin Landa wrote: > r.info module has a lot of flags [1] which print *given* information > to stdout. From my point of view it would be better (maybe) to have > only *one* flag for this purpose, e.g. > > -g Print basic information in shell script style > > What do you think about it? It should not break any scripts in CVS > tree (maybe Add-ons?). Sure, it is not a good way -- to break backward > compatibility... on the other hand, just adding new flag -g is not > also nice solution. We shouldn't remove existing flags, but an additional flag to print all available information in a parsable format would be a useful addition. -- Glynn Clements From glynn at gclements.plus.com Mon Sep 4 19:41:59 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Sep 4 19:42:02 2006 Subject: [GRASS-dev] [bug #5098] (grass) gis.m; tcltk error when zooming to map with name which exists in more than one mapset In-Reply-To: <20060904161315.D81B31005C5@lists.intevation.de> References: <20060904161315.D81B31005C5@lists.intevation.de> Message-ID: <17660.25959.874889.172137@cerise.gclements.plus.com> Request Tracker wrote: > this bug's URL: http://intevation.de/rt/webrt?serial_num=5098 > ------------------------------------------------------------------------- > > Subject: gis.m; tcltk error when zooming to map with name which exists in more than one mapset > > Platform: GNU/Linux/x86 > grass obtained from: CVS > grass binary for platform: Compiled from Sources > GRASS Version: cvs_head_20060904 > > When there are two maps with the same name in more than one of the > accessible mapsets, then gis.m throws below tcltk error when I try to > "zoom to selected map". To reproduce in spearfish, just copy any map > from the PERMANENT mapset to the user1 mapset using the same name and > then display it and zoom to it. If I enter @mapsetname (i.e. @user1) > after the map name zooming to the map works. > > It is probably just a question of catching the WARNING message and > ignoring it, or of adding the @mapsetname automatically (default to > current mapset if not set otherwise). Whenever any Tcl/Tk code runs a GRASS command, it needs to use "2>@stdout". Tcl treats it as an error if anything is written to stderr. Genuine errors will still be detected by a non-zero exit code. -- Glynn Clements From tutey at o2.pl Mon Sep 4 19:57:44 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Sep 4 19:57:49 2006 Subject: [GRASS-dev] r.info -g In-Reply-To: <17660.25666.420259.755744@cerise.gclements.plus.com> References: <17660.25666.420259.755744@cerise.gclements.plus.com> Message-ID: <44FC6918.3040604@o2.pl> Glynn Clements wrote: > Martin Landa wrote: > >> r.info module has a lot of flags [1] which print *given* information >> to stdout. From my point of view it would be better (maybe) to have >> only *one* flag for this purpose, e.g. >> >> -g Print basic information in shell script style >> >> What do you think about it? It should not break any scripts in CVS >> tree (maybe Add-ons?). Sure, it is not a good way -- to break backward >> compatibility... on the other hand, just adding new flag -g is not >> also nice solution. > > We shouldn't remove existing flags, but an additional flag to print > all available information in a parsable format would be a useful > addition. Glynn's right. But I hope that in Grass 7 the flag for a *complete*, parsable r.info output could be changed to -g anyway (since g.region, v.univar, v.db.connect, v.category, r.univar, r.sunmask, r.in.xyz use it already). Should it go to Grass 7 plans WIKI? Maciek From grass4u at gmail.com Mon Sep 4 20:13:57 2006 From: grass4u at gmail.com (Huidae Cho) Date: Mon Sep 4 20:14:35 2006 Subject: [GRASS-dev] gis.m patch In-Reply-To: <17659.17431.352958.556962@cerise.gclements.plus.com> References: <20060902063219.GA78577@localhost.tamu.edu> <20060903172352.GA1413@localhost> <17659.17431.352958.556962@cerise.gclements.plus.com> Message-ID: <20060904181357.GA2355@localhost.tamu.edu> On Sun, Sep 03, 2006 at 10:07:35PM +0100, Glynn Clements wrote: > > Huidae Cho wrote: > > > > This is GREAT. Thanks very much. I have a couple questions. > > > > > > 1. Is there a binary version of this available for people to try? > > > > No, not yet. Since the native winGRASS runs on MSys, users need to > > install various MSys/GnuWin32 packages as well as GRASS. I want to > > distribute a whole system including MSys/GnuWin32 binaries, but I'm not > > sure about license issues related to redistribution. It looks like most > > of packages are under GPL licenses, so can I? It could be really > > annoying for non-techy users to choose right packages from their sites > > (it's not like Cygwin). > > Most of the packages you are likely to need will allow bundling with > GRASS in a single installer or archive. > > The only case which might be problematic is if you are using > ActiveState Tcl/Tk; the licencing conditions for that looked like they > might be problematic, so I've been using the standard Tcl/Tk packages > built from source instead. Then the MSys version should be fine? > > > > 3. Could you give me a brief one-liner of what each change to gism is > > > intended to do so I can find a way to keep this in the code if it does have > > > issues on other platforms? > > > > As mentioned above, the only problem was the null device. On Windows, > > it's called "nul" and that's the only change that I made. > > There is also this one: > > # Actually run the program > - set cmd [concat | $cmd 2>@ stdout] > + if { $mingw == "1" } { > + set cmd [concat | $cmd] > + } { > + set cmd [concat | $cmd 2>@ stdout] > + } > > What happens without that change? I get the same error as http://intevation.de/rt/webrt?serial_num=5096. $ret is set to 1 and it cannot make it to $execcmd. > > > > 4. Does NVIZ work? > > > > No. The configure message below is misleading because I tried to use > > libW11, which WAS part of grass5. > > Note that NVIZ does work natively under Windows (using MinGW/MSys); > the only problem I ran into was that you need to redirect NVIZ' stdin > from /dev/null otherwise "exec" hangs (redirect stdin within the exec > command doesn't work). OK, I'll try. Huidae From michael.barton at asu.edu Mon Sep 4 20:23:05 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 4 20:26:34 2006 Subject: [GRASS-dev] v.in.ogr broken (\w shp) In-Reply-To: Message-ID: I'd vote for in GRASS 6.3 if it's doable. 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: Helena Mitasova > Date: Mon, 4 Sep 2006 10:03:33 -0400 > To: > Cc: Hamish , GRASS Devel > Subject: Re: [GRASS-dev] v.in.ogr broken (\w shp) > > it is one more reason to change the default DBMS in future (GRASS7?) > From michael.barton at asu.edu Mon Sep 4 20:31:59 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 4 20:32:57 2006 Subject: [GRASS-dev] [bug #5098] (grass) gis.m; tcltk error when zooming to map with name which exists in more than one mapset In-Reply-To: <20060904161315.D81B31005C5@lists.intevation.de> Message-ID: Maceij has reported this too. I'm trying to do a bunch of comprehensive bug fixes (they never seem to end) to gism. I think I've fixed this one. I was finally able to reproduce a strange one that he also reported about zooming when 2 or more map display are visible. Reproducing it on my Mac was difficult, but fixing this was much harder. But I think I got it. This has involved changing most of the many global variables floating around to ones tied to local name spaces, and replacing other variables with arrays indexed by active display monitor. I hope to get this committed either tomorrow or Wednesday. Hopefully, this will make the whole system more robust. 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: Request Tracker > Reply-To: Request Tracker > Date: Mon, 4 Sep 2006 18:13:15 +0200 (CEST) > To: > Subject: [GRASS-dev] [bug #5098] (grass) gis.m; tcltk error when zooming to > map with name which exists in more than one mapset > > this bug's URL: http://intevation.de/rt/webrt?serial_num=5098 > ------------------------------------------------------------------------- > > Subject: gis.m; tcltk error when zooming to map with name which exists in more > than one mapset > > Platform: GNU/Linux/x86 > grass obtained from: CVS > grass binary for platform: Compiled from Sources > GRASS Version: cvs_head_20060904 > > When there are two maps with the same name in more than one of the accessible > mapsets, then gis.m throws below tcltk error when I try to "zoom to selected > map". To reproduce in spearfish, just copy any map from the PERMANENT mapset > to the user1 mapset using the same name and then display it and zoom to it. If > I enter @mapsetname (i.e. @user1) after the map name zooming to the map works. > > It is probably just a question of catching the WARNING message and ignoring > it, or of adding the @mapsetname automatically (default to current mapset if > not set otherwise). > > BTW, I find the warning message a bit weird: when I display roads from user1 I > get the message "WARNING: 'vector/roads' was found in more mapsets (also found > in user1)". In my understanding this should read "... (also found in > PERMANENT)... > > WARNING: 'vector/roads' was found in more mapsets (also found in user1). > WARNING: 'vector/roads' was found in more mapsets (also found in user1). > while executing > "close $input" > (procedure "MapCanvas::zoom_gregion" line 11) > invoked from within > "MapCanvas::zoom_gregion $mon [list "vect=$map"]" > (procedure "MapCanvas::zoom_map" line 48) > invoked from within > "MapCanvas::zoom_map $mon" > invoked from within > ".mapcan(1).mf.topf.tb0.mapzoom.zm invoke active" > ("uplevel" body line 1) > invoked from within > "uplevel #0 [list $w invoke active]" > (procedure "tk::MenuInvoke" line 50) > invoked from within > "tk::MenuInvoke .mapcan(1).mf.topf.tb0.mapzoom.zm 1" > (command bound to event) > > Moritz > > -------------------------------------------- Managed by Request Tracker > > From tutey at o2.pl Mon Sep 4 20:41:44 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Sep 4 20:41:49 2006 Subject: [GRASS-dev] [bug #5098] (grass) gis.m; tcltk error when zooming to map with name which exists in more than one mapset In-Reply-To: References: Message-ID: <44FC7368.1050605@o2.pl> Michael Barton wrote: > Maceij has reported this too. > > I'm trying to do a bunch of comprehensive bug fixes (they never seem to end) > to gism. ;) > I think I've fixed this one. > > I was finally able to reproduce a strange one that he also reported about > zooming when 2 or more map display are visible. Reproducing it on my Mac was > difficult, but fixing this was much harder. But I think I got it. > > This has involved changing most of the many global variables floating around > to ones tied to local name spaces, and replacing other variables with arrays > indexed by active display monitor. > > I hope to get this committed either tomorrow or Wednesday. I will be glad to test it but I'm away 05-09 Sept. and *propably* will not have an Internet connection during that time. Yet if the meeting is boring and there's net available I could entertain myself a bit testing the gis.m :). We'll see. Cheers, Maciek From michael.barton at asu.edu Mon Sep 4 20:38:46 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 4 20:44:07 2006 Subject: [GRASS-dev] [bug #5098] (grass) gis.m; tcltk error when zooming to map with name which exists in more than one mapset In-Reply-To: <20060904161315.D81B31005C5@lists.intevation.de> Message-ID: I'm doing a bunch of fixes (they never seem to end do they?) prompted by a weird bug report by Maciej about odd behavior zooming between two map displays. This was tricky to reproduce on my Mac and much more difficult to fix. I think I got it, but it involved changing most of the many global variables floating around to variables within local namespaces, and indexing more variables by active display monitor. I also found and dispatched a few other hidden bugs and bugs waiting to happen. I've fixed this one too I hope. Maciej and other have reported it before, but it has been intermittent on my Mac--making a fix difficult. This cleanup should make the whole application more robust. I want to commit all this tomorrow or on Wednesday (depending on my schedule and access to the cvs tomorrow). 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: Request Tracker > Reply-To: Request Tracker > Date: Mon, 4 Sep 2006 18:13:15 +0200 (CEST) > To: > Subject: [GRASS-dev] [bug #5098] (grass) gis.m; tcltk error when zooming to > map with name which exists in more than one mapset > > BTW, I find the warning message a bit weird: when I display roads from user1 I > get the message "WARNING: 'vector/roads' was found in more mapsets (also found > in user1)". In my understanding this should read "... (also found in > PERMANENT)... From michael.barton at asu.edu Mon Sep 4 20:53:51 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 4 20:54:23 2006 Subject: [GRASS-dev] [bug #5095] (grass) gis.m: non-existant column name in thematic layer leads to non-existant gismlegend.txt error and frozen display In-Reply-To: <20060904094127.4D7281005AD@lists.intevation.de> Message-ID: I think I've got this one fixed too. Will commit this next week. 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: Request Tracker > Reply-To: Request Tracker > Date: Mon, 4 Sep 2006 11:41:27 +0200 (CEST) > To: > Subject: [GRASS-dev] [bug #5095] (grass) gis.m: non-existant column name in > thematic layer leads to non-existant gismlegend.txt error and frozen display > > this bug's URL: http://intevation.de/rt/webrt?serial_num=5095 > ------------------------------------------------------------------------- > > Subject: gis.m: non-existant column name in thematic layer leads to > non-existant gismlegend.txt error and frozen display > > Platform: GNU/Linux/x86 > grass obtained from: CVS > grass binary for platform: Compiled from Sources > GRASS Version: cvs_head_20060829 > > As gis.m doesn't trap the error of a wrong column name in d.vect.thematic, it > then goes on to try to create a legend, but cannot find gismlegend.txt. It > then freezes the display. > > To reproduce in spearfish: > > - in gis.m, add thematic layer > - chose any of the relevant vector files (I used landcover) > - give a ficticious column name in the attribute column field > - launch display > > > The problem seems to be in commonlayer.tcl which doesn't seem to trap error > messages from the command (although I don't have the time to try to understand > all the code there) and in thematic.tcl (line 536) where the legend is created > even if the command was unsuccessful. > > Moritz > > -------------------------------------------- Managed by Request Tracker > > From michael.barton at asu.edu Mon Sep 4 21:08:11 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 4 21:09:18 2006 Subject: [GRASS-dev] New xterm wrapper not working on Mac build Message-ID: I just discovered that the xterm wrapper script does not work for Willaim Kyngesburye?s framework build binaries for the Mac, and won?t work for Lorenzo?s binaries either in some circumstances. The issue is that the Mac BASH terminal is used as the GRASS terminal rather than an xterm. The Mac terminal is much easier to use. But when grass-xterm-wrapper.sh is run from the BASH terminal, it doesn?t realize that x is running and returns a command not found error. This is not a problem when an xterm is launched from TclTk, which IS running in X-windows. Solutions? 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060904/ea6eb3f2/attachment.html From woklist at kyngchaos.com Mon Sep 4 23:16:46 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Sep 4 23:16:53 2006 Subject: [GRASS-dev] Re: New xterm wrapper not working on Mac build In-Reply-To: References: Message-ID: Hmm, when I saw the xterm wrapper thread, I kinda wondered how it might affect GRASS running from a Mac Terminal. I'm not sure about the details on how the wrapper is used, but when an xterm is needed, would a Mac Terminal work? One thing I added to my custom GRASS.app startup is a GRASS_OS_STARTUP env var. I set it to "Mac.app" and it was initially used when I added to the existing grass6 startup shell, but now I use a completely custom grass startup shell because I couldn't figure out how to pass args from the open command. I left GRASS_OS_STARTUP in the startup, so maybe grass-xterm-wrapper can use this to set GRASS_XTERM to open a Terminal instead of an xterm? It would be kinda tricky - exec'ing a Terminal directly would actually run Terminal.app again instead of creating a new window in an already-running Terminal (not good, most Mac apps are only meant to be run once), instead it would need to be run from 'open' (this is how I start GRASS in my python startup). But this will only work to run a script from a file, not open an empty Terminal window, unless there is no window currently open. For running a script in a new window (open doesn't need to run from exec, and returns immediately without waiting for the script to run - it's just 'opening' a file in an application): /usr/bin/open -a Terminal some_script_file.sh Without a script file, it just opens the Terminal, and if there is no window open, it will open a new one (what we want), but if there is already one open (there is because GRASS was started in one) it will just activate the frontmost window. I thought about doing an inline AppleScript, but the Terminal's scriptability is surprisingly limited - there is no way to open a new window. It could be done with the System Events scripting to manually choose a menu item, but that's messy and requires a user to activate Universal Access. If the xterm usage needs specific xterm options, then a Terminal probably won't work, since it doesn't have startup options except for running a script. Which makes me wonder - if an xterm is explicitly needed, that makes it difficult to separate the GUI from X11 if a user wanted to use Tcl/Tk Aqua (or a native Windows TclTk, if that option works). Or, if the GUI is running in an X11 Tcl/Tk, you probably want xterms for a consistent look. For running from the CLI, I did a search and the only place an xterm is used is r[3].mapcalculator, to run in 'expert' mode (and without grass-run.sh). That doesn't sound right - won't it be missing the GRASS running environment? Why should it run in a separate window in the first place? Do you have a specific example of grass-xterm-wrapper use in the CLI that fails? On Sep 4, 2006, at 2:08 PM, Michael Barton wrote: > I just discovered that the xterm wrapper script does not work for > Willaim Kyngesburye?s framework build binaries for the Mac, and > won?t work for Lorenzo?s binaries either in some circumstances. > > The issue is that the Mac BASH terminal is used as the GRASS > terminal rather than an xterm. The Mac terminal is much easier to > use. But when grass-xterm-wrapper.sh is run from the BASH terminal, > it doesn?t realize that x is running and returns a command not > found error. This is not a problem when an xterm is launched from > TclTk, which IS running in X-windows. > > Solutions? > > Michael > ----- William Kyngesburye http://www.kyngchaos.com/ "We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty." "Don't you even hate 'em?" "What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the ____ it wouldn't kill one ___ nor shorten the war one day." "And it might give 'em all stomach ulcers." - Tarzan, on war From grass4u at gmail.com Mon Sep 4 23:47:57 2006 From: grass4u at gmail.com (Huidae Cho) Date: Mon Sep 4 23:48:36 2006 Subject: [GRASS-dev] gis.m patch In-Reply-To: <20060904181357.GA2355@localhost.tamu.edu> References: <20060902063219.GA78577@localhost.tamu.edu> <20060903172352.GA1413@localhost> <17659.17431.352958.556962@cerise.gclements.plus.com> <20060904181357.GA2355@localhost.tamu.edu> Message-ID: <20060904214757.GA28131@localhost.tamu.edu> On Mon, Sep 04, 2006 at 01:13:57PM -0500, Huidae Cho wrote: > On Sun, Sep 03, 2006 at 10:07:35PM +0100, Glynn Clements wrote: > > > > Huidae Cho wrote: > > > > > > This is GREAT. Thanks very much. I have a couple questions. > > > > > > > > 1. Is there a binary version of this available for people to try? > > > > > > No, not yet. Since the native winGRASS runs on MSys, users need to > > > install various MSys/GnuWin32 packages as well as GRASS. I want to > > > distribute a whole system including MSys/GnuWin32 binaries, but I'm not > > > sure about license issues related to redistribution. It looks like most > > > of packages are under GPL licenses, so can I? It could be really > > > annoying for non-techy users to choose right packages from their sites > > > (it's not like Cygwin). > > > > Most of the packages you are likely to need will allow bundling with > > GRASS in a single installer or archive. > > > > The only case which might be problematic is if you are using > > ActiveState Tcl/Tk; the licencing conditions for that looked like they > > might be problematic, so I've been using the standard Tcl/Tk packages > > built from source instead. > > Then the MSys version should be fine? > > > > > > > 3. Could you give me a brief one-liner of what each change to gism is > > > > intended to do so I can find a way to keep this in the code if it does have > > > > issues on other platforms? > > > > > > As mentioned above, the only problem was the null device. On Windows, > > > it's called "nul" and that's the only change that I made. > > > > There is also this one: > > > > # Actually run the program > > - set cmd [concat | $cmd 2>@ stdout] > > + if { $mingw == "1" } { > > + set cmd [concat | $cmd] > > + } { > > + set cmd [concat | $cmd 2>@ stdout] > > + } > > > > What happens without that change? > > I get the same error as http://intevation.de/rt/webrt?serial_num=5096. > $ret is set to 1 and it cannot make it to $execcmd. > > > > > > > 4. Does NVIZ work? > > > > > > No. The configure message below is misleading because I tried to use > > > libW11, which WAS part of grass5. > > > > Note that NVIZ does work natively under Windows (using MinGW/MSys); > > the only problem I ran into was that you need to redirect NVIZ' stdin > > from /dev/null otherwise "exec" hangs (redirect stdin within the exec > > command doesn't work). > > OK, I'll try. > How did you compile nviz without the lib/form library? The library cannot be built currently because it requires fork(). Maybe, I'm missing something? Huidae From michael.barton at asu.edu Tue Sep 5 01:36:16 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Sep 5 01:36:50 2006 Subject: [GRASS-dev] Re: New xterm wrapper not working on Mac build In-Reply-To: Message-ID: Fiddling around I found out that the following command will open a new terminal window (assuming that it's where Apple put it), though it's kind of messy. open /applications/utilities/terminal.app/contents/macos/Terminal __________________________________________ 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: William Kyngesburye > Reply-To: William Kyngesburye > Date: Mon, 4 Sep 2006 16:16:46 -0500 > To: Michael Barton > Cc: > Subject: Re: New xterm wrapper not working on Mac build > > Hmm, when I saw the xterm wrapper thread, I kinda wondered how it > might affect GRASS running from a Mac Terminal. I'm not sure about > the details on how the wrapper is used, but when an xterm is needed, > would a Mac Terminal work? > > One thing I added to my custom GRASS.app startup is a > GRASS_OS_STARTUP env var. I set it to "Mac.app" and it was initially > used when I added to the existing grass6 startup shell, but now I use > a completely custom grass startup shell because I couldn't figure out > how to pass args from the open command. I left GRASS_OS_STARTUP in > the startup, so maybe grass-xterm-wrapper can use this to set > GRASS_XTERM to open a Terminal instead of an xterm? > > It would be kinda tricky - exec'ing a Terminal directly would > actually run Terminal.app again instead of creating a new window in > an already-running Terminal (not good, most Mac apps are only meant > to be run once), instead it would need to be run from 'open' (this is > how I start GRASS in my python startup). But this will only work to > run a script from a file, not open an empty Terminal window, unless > there is no window currently open. > > For running a script in a new window (open doesn't need to run from > exec, and returns immediately without waiting for the script to run - > it's just 'opening' a file in an application): > > /usr/bin/open -a Terminal some_script_file.sh > > Without a script file, it just opens the Terminal, and if there is no > window open, it will open a new one (what we want), but if there is > already one open (there is because GRASS was started in one) it will > just activate the frontmost window. > > I thought about doing an inline AppleScript, but the Terminal's > scriptability is surprisingly limited - there is no way to open a new > window. It could be done with the System Events scripting to > manually choose a menu item, but that's messy and requires a user to > activate Universal Access. > > > If the xterm usage needs specific xterm options, then a Terminal > probably won't work, since it doesn't have startup options except for > running a script. Which makes me wonder - if an xterm is explicitly > needed, that makes it difficult to separate the GUI from X11 if a > user wanted to use Tcl/Tk Aqua (or a native Windows TclTk, if that > option works). > > > Or, if the GUI is running in an X11 Tcl/Tk, you probably want xterms > for a consistent look. > > > For running from the CLI, I did a search and the only place an xterm > is used is r[3].mapcalculator, to run in 'expert' mode (and without > grass-run.sh). That doesn't sound right - won't it be missing the > GRASS running environment? Why should it run in a separate window in > the first place? > > > Do you have a specific example of grass-xterm-wrapper use in the CLI > that fails? > > > On Sep 4, 2006, at 2:08 PM, Michael Barton wrote: > >> I just discovered that the xterm wrapper script does not work for >> Willaim Kyngesburye?s framework build binaries for the Mac, and >> won?t work for Lorenzo?s binaries either in some circumstances. >> >> The issue is that the Mac BASH terminal is used as the GRASS >> terminal rather than an xterm. The Mac terminal is much easier to >> use. But when grass-xterm-wrapper.sh is run from the BASH terminal, >> it doesn?t realize that x is running and returns a command not >> found error. This is not a problem when an xterm is launched from >> TclTk, which IS running in X-windows. >> >> Solutions? >> >> Michael >> > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > "We are at war with them. Neither in hatred nor revenge and with no > particular pleasure I shall kill every ___ I can until the war is > over. That is my duty." > > "Don't you even hate 'em?" > > "What good would it do if I did? If all the many millions of people > of the allied nations devoted an entire year exclusively to hating > the ____ it wouldn't kill one ___ nor shorten the war one day." > > "And it might give 'em all stomach ulcers." > > - Tarzan, on war > From woklist at kyngchaos.com Tue Sep 5 01:49:21 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Tue Sep 5 01:49:27 2006 Subject: [GRASS-dev] Re: New xterm wrapper not working on Mac build In-Reply-To: References: Message-ID: <8A5780BB-9D62-4098-B273-41F523883D5A@kyngchaos.com> See my reply just minutes ago (forgot to cc the list). But this form here really tries to open Terminal as a document. It really should be (and it uses some magic to find Terminal.app): open -a Terminal But, like I said, it only opens a new window if one already isn't open. It will if a script is run. And it returns immediately, without waiting for the script to finish. On Sep 4, 2006, at 6:36 PM, Michael Barton wrote: > open /applications/utilities/terminal.app/contents/macos/Terminal ----- William Kyngesburye http://www.kyngchaos.com/ All generalizations are dangerous, even this one. From hamish_nospam at yahoo.com Tue Sep 5 02:18:37 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Sep 5 02:18:54 2006 Subject: [GRASS-dev] r.info -g In-Reply-To: <44FC6918.3040604@o2.pl> References: <17660.25666.420259.755744@cerise.gclements.plus.com> <44FC6918.3040604@o2.pl> Message-ID: <20060905121837.282c1f1a.hamish_nospam@yahoo.com> Martin wrote: > >> r.info module has a lot of flags [1] which print *given* > >information > to stdout. From my point of view it would be better > >(maybe) to have > only *one* flag for this purpose, e.g. > >> > >> -g Print basic information in shell script style > >> > >> What do you think about it? It should not break any scripts in CVS > >> tree (maybe Add-ons?). Sure, it is not a good way -- to break > >backward > compatibility... on the other hand, just adding new flag > >-g is not > also nice solution. Glynn wrote: > > We shouldn't remove existing flags, but an additional flag to print > > all available information in a parsable format would be a useful > > addition. Maciej Sieczka wrote: > Glynn's right. But I hope that in Grass 7 the flag for a *complete*, > parsable r.info output could be changed to -g anyway (since g.region, > v.univar, v.db.connect, v.category, r.univar, r.sunmask, r.in.xyz use > it already). consistency is good. > Should it go to Grass 7 plans WIKI? Let's just do this in 6.3-HEAD. Adding more lines to the "r.info -g" shouldn't be too damaging. The only problem it could cause (that I can think of) is if someone used something like `r.info -g | tail -1` in a script. I think that's minor enough and poorly written enough to not be a major concern. Hamish From rez at touchofmadness.com Tue Sep 5 03:21:48 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Tue Sep 5 03:21:55 2006 Subject: [GRASS-dev] v.in.ogr broken (\w shp) In-Reply-To: <44FC4FD1.80207@o2.pl> References: <1157126513.17352.65.camel@devel> <20060903195933.39429ed5.hamish_nospam@yahoo.com> <44FC4FD1.80207@o2.pl> Message-ID: <1157419308.5122.216.camel@devel> On Mon, 2006-09-04 at 18:09 +0200, Maciej Sieczka wrote: > Hamish wrote: > > Brad Douglas wrote: > >> Is there an easy fix for this? I'm trying to import a shapefile and > >> I'm not terribly familiar with this part of the GRASS architecture. > >> > >> GRASS 6.3.cvs (hamilton):~/hamilton > v.in.ogr dsn=. output=roads > >> layer=17 > >> Projection of input dataset and current location appear to match. > >> Proceeding with import... > >> Layer: 17 > >> DBMI-DBF driver error: > >> Column 'ADMIN_CLAS' already exists (duplicate name) > >> Cannot create table. > >> Error in db_execute_immediate() > >> > >> ERROR: Cannot create table: create table roads (cat integer, PREFIX > >> varchar > >> ( 2 ), NAME varchar ( 30 ), TYPE varchar ( 4 ), SUFFIX varchar > >> ( 2 > >> ), FCC varchar ( 3 ), FIPS varchar ( 11 ), ID integer, > >> FULL_NAME varchar ( 40 ), ADMIN_CLAS varchar ( 40 ), CATEGORY > >> integer, ST_CNTY_FI varchar ( 11 ), RD_CLASS varchar ( 4 ), > >> RTE_NUM1 > >> varchar > >> ( 4 ), RTE_NUM2 varchar ( 4 ), ADMIN_CLAS integer, AREA double > >> precision, LEN double precision) > >> GRASS 6.3.cvs (hamilton):~/hamilton > > > > DBF limits column names to 10 chars; > > Brad, > > Just curious: > > Hamish is right. And you are importing a shapefile, correct? So how > could a column name longer than 10 chars be in the dbf shipped with > that shapefile? After looking at the DBF, it appears that they've extracted from another source to a shapefile. During the extraction, it truncates the column names at 10 characters, leaving duplicate column names. It's *really* bad practice on their part. I have confirmed this with a new dataset. -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From glynn at gclements.plus.com Tue Sep 5 04:46:10 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Sep 5 04:47:55 2006 Subject: [GRASS-dev] gis.m patch In-Reply-To: <20060904181357.GA2355@localhost.tamu.edu> References: <20060902063219.GA78577@localhost.tamu.edu> <20060903172352.GA1413@localhost> <17659.17431.352958.556962@cerise.gclements.plus.com> <20060904181357.GA2355@localhost.tamu.edu> Message-ID: <17660.58610.165021.323507@cerise.gclements.plus.com> Huidae Cho wrote: > > > > This is GREAT. Thanks very much. I have a couple questions. > > > > > > > > 1. Is there a binary version of this available for people to try? > > > > > > No, not yet. Since the native winGRASS runs on MSys, users need to > > > install various MSys/GnuWin32 packages as well as GRASS. I want to > > > distribute a whole system including MSys/GnuWin32 binaries, but I'm not > > > sure about license issues related to redistribution. It looks like most > > > of packages are under GPL licenses, so can I? It could be really > > > annoying for non-techy users to choose right packages from their sites > > > (it's not like Cygwin). > > > > Most of the packages you are likely to need will allow bundling with > > GRASS in a single installer or archive. > > > > The only case which might be problematic is if you are using > > ActiveState Tcl/Tk; the licencing conditions for that looked like they > > might be problematic, so I've been using the standard Tcl/Tk packages > > built from source instead. > > Then the MSys version should be fine? Probably. I didn't actually realise there *was* an MSys version until you mentioned it. > > > > 3. Could you give me a brief one-liner of what each change to gism is > > > > intended to do so I can find a way to keep this in the code if it does have > > > > issues on other platforms? > > > > > > As mentioned above, the only problem was the null device. On Windows, > > > it's called "nul" and that's the only change that I made. > > > > There is also this one: > > > > # Actually run the program > > - set cmd [concat | $cmd 2>@ stdout] > > + if { $mingw == "1" } { > > + set cmd [concat | $cmd] > > + } { > > + set cmd [concat | $cmd 2>@ stdout] > > + } > > > > What happens without that change? > > I get the same error as http://intevation.de/rt/webrt?serial_num=5096. > $ret is set to 1 and it cannot make it to $execcmd. Odd. Or maybe not; assuming that there even *is* a stdout is a bad idea for a Windows program, particularly as gis.m runs itself in the background by default. The problem with simply removing the "2>@ stdout" is that "exec" generates an error if the command writes anything to an unredirected stderr. It might be better to unconditionally use: set cmd [concat | $cmd |& cat] so that both stdout and stderr go to the console widget (AFAIK, Tcl's exec/open don't provide an equivalent of "2>&1"). Also, on Unix the 2>@stdout may cause gis.m to be suspended (with SIGTTOU) if the TOSTOP mode ("stty tostop") is in force. In any case, bug #5096 indicates that there is an error in the error-handling code in gronsole.tcl. That needs to be fixed regardless of how stderr is handled; there are other reasons why open might fail. -- Glynn Clements From glynn at gclements.plus.com Tue Sep 5 05:00:30 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Sep 5 05:01:10 2006 Subject: [GRASS-dev] gis.m patch In-Reply-To: <20060904214757.GA28131@localhost.tamu.edu> References: <20060902063219.GA78577@localhost.tamu.edu> <20060903172352.GA1413@localhost> <17659.17431.352958.556962@cerise.gclements.plus.com> <20060904181357.GA2355@localhost.tamu.edu> <20060904214757.GA28131@localhost.tamu.edu> Message-ID: <17660.59470.358198.283527@cerise.gclements.plus.com> Huidae Cho wrote: > > > Note that NVIZ does work natively under Windows (using MinGW/MSys); > > > the only problem I ran into was that you need to redirect NVIZ' stdin > > > from /dev/null otherwise "exec" hangs (redirect stdin within the exec > > > command doesn't work). > > > > OK, I'll try. > > How did you compile nviz without the lib/form library? The library > cannot be built currently because it requires fork(). Maybe, I'm > missing something? I built with static libraries. NVIZ requires F_generate, from lib/form/generate.c, but doesn't require anything from lib/form/open.c, so open.o from libgrass_form won't get linked. To get shared libraries to work, you'll need to conditionalise the fork() in F_open(). -- Glynn Clements From glynn at gclements.plus.com Tue Sep 5 05:11:36 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Sep 5 05:12:27 2006 Subject: [GRASS-dev] New xterm wrapper not working on Mac build In-Reply-To: References: Message-ID: <17660.60136.979751.709252@cerise.gclements.plus.com> Michael Barton wrote: > I just discovered that the xterm wrapper script does not work for Willaim > Kyngesburye?s framework build binaries for the Mac, and won?t work for > Lorenzo?s binaries either in some circumstances. > > The issue is that the Mac BASH terminal is used as the GRASS terminal rather > than an xterm. The Mac terminal is much easier to use. But when > grass-xterm-wrapper.sh is run from the BASH terminal, it doesn?t realize > that x is running and returns a command not found error. This is not a > problem when an xterm is launched from TclTk, which IS running in X-windows. > > Solutions? export PATH=$PATH:/usr/X11R6/bin export DISPLAY=:0 Or set GRASS_XTERM to a command which will work as a substitute for xterm. BUT ... William Kyngesburye wrote: > Hmm, when I saw the xterm wrapper thread, I kinda wondered how it > might affect GRASS running from a Mac Terminal. I'm not sure about > the details on how the wrapper is used, but when an xterm is needed, > would a Mac Terminal work? Any xterm substitute will need to accept whatever options and switches are used by commands which were originally written for an xterm. It's free to ignore them, but it has to figure out that the command is whatever follows the -e switch. E.g. #!/bin/sh while true ; do if [ "$1" = -e ] ; then break ; fi shift done shift exec someotherterminal "$@" Also, be careful about quoting; some of the commands use -title with an argument which contains spaces. -- Glynn Clements From hamish_nospam at yahoo.com Tue Sep 5 05:21:18 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Sep 5 05:22:01 2006 Subject: [GRASS-dev] v.bspline -> v.surf.bspline ? In-Reply-To: <20060904093357.GA17705@bartok.itc.it> References: <44DD0000.8000301@o2.pl> <44ED7041.3090505@o2.pl> <44F95696.2020902@o2.pl> <1157197146.5122.40.camel@devel> <20060902124257.GA4023@bartok.itc.it> <20060904182652.19cf659e.hamish_nospam@yahoo.com> <20060904093357.GA17705@bartok.itc.it> Message-ID: <20060905152118.28711dd5.hamish_nospam@yahoo.com> 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 From hamish_nospam at yahoo.com Tue Sep 5 05:41:14 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Sep 5 05:42:10 2006 Subject: [GRASS-dev] gis.m patch In-Reply-To: <20060904181357.GA2355@localhost.tamu.edu> References: <20060902063219.GA78577@localhost.tamu.edu> <20060903172352.GA1413@localhost> <17659.17431.352958.556962@cerise.gclements.plus.com> <20060904181357.GA2355@localhost.tamu.edu> Message-ID: <20060905154114.6f5bd960.hamish_nospam@yahoo.com> Huidae Cho wrote: > > > No, not yet. Since the native winGRASS runs on MSys, users need > > > to install various MSys/GnuWin32 packages as well as GRASS. I > > > want to distribute a whole system including MSys/GnuWin32 > > > binaries, but I'm not sure about license issues related to > > > redistribution. It looks like most of packages are under GPL > > > licenses, so can I? It could be really annoying for non-techy > > > users to choose right packages from their sites (it's not like > > > Cygwin). Glynn: > > Most of the packages you are likely to need will allow bundling with > > GRASS in a single installer or archive. > > > > The only case which might be problematic is if you are using > > ActiveState Tcl/Tk; the licencing conditions for that looked like > > they might be problematic, so I've been using the standard Tcl/Tk > > packages built from source instead. Huidae Cho wrote: > Then the MSys version should be fine? MSys is put out by MinGW, and the the first sentence of www.mingw.org reads "MinGW: A collection of freely available and freely distributable Windows specific header files and import libraries combined with GNU toolsets that allow one to produce native Windows programs that do not rely on any 3rd-party C runtime DLLs." further, the "G" in MinGW is GNU.... we can't get much more free software than that. http://www.mingw.org/licensing.shtml says the MinGW specific parts are placed in the public domain. but to be sure I've just downloaded the MSys source code. in msys/1.0/10/rt/src there is: COPYING (the GPL) COPYING.LIB (the LGPL) CYGWIN_LICENSE (the GPL + non-viral clause for linking software) and... ======================================== File: MSYS_LICENSE Copyright (C): 2001, Earnie Boyd File $Revision: $ File Revision $Date: $ MSYS Release: 1.0.2 MSYS Release Date: November 30th, 2001 The software, both source and binary forms, are covered via differing licenses. Each license has it's own set of rules so please make sure you read them carefully to see how it applies to you, particularly if you're going to distribute the software. The MSYS runtime software source can found in the winsup/cygwin directory. The existing code portions of this source is covered by the CYGWIN_LICENSE which can be found in this directory in a file by the name of CYGWIN_LICENSE. MSYS specific software code added regardless of existing license is covered by the ESPL which can be found in a file by the same name. ======================================== There is no ESPL file there, but a web search found something called the "EcoSpold Public License v1.0 (ESPL 1.0)". I've asked on the MSys mailing list for this to be fixed/clarified. As it only affects "MSYS specific software code" [whatever that means], I guess it doesn't apply to us. Hamish From hamish_nospam at yahoo.com Tue Sep 5 05:45:57 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Sep 5 05:46:02 2006 Subject: [GRASS-dev] adding files to the release branch? Message-ID: <20060905154557.5c5f191e.hamish_nospam@yahoo.com> Hi, I'm trying to add the v.dissolve and v.centroids scripts to the 6.2 release branch but can't figure out how to add files to the branch. I get: 6.2branch/grass6/scripts$ cvs add v.centroids/Makefile cvs add: cannot open CVS/Entries for reading: No such file or directory cvs [add aborted]: no repository 6.2branch$ cvs add grass6/scripts/v.centroids/Makefile cvs add: in directory `.': cvs [add aborted]: there is no version here; do `cvs checkout' first (doing this without a full checkout of the whole 6.2 branch [but scripts/ is checked out], dirs+files exist in HEAD) ?? thanks, Hamish From hamish_nospam at yahoo.com Tue Sep 5 07:16:50 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Sep 5 07:16:56 2006 Subject: [GRASS-dev] v.in.ogr broken (\w shp) In-Reply-To: <20060904112420.GD17705@bartok.itc.it> References: <1157126513.17352.65.camel@devel> <20060903195933.39429ed5.hamish_nospam@yahoo.com> <1157367247.5122.188.camel@devel> <20060904112420.GD17705@bartok.itc.it> Message-ID: <20060905171650.31efc41b.hamish_nospam@yahoo.com> Brad: > > However, this does present a usability issue. This is a problem > > many, people will encounter. I was trying to import a standard USGS > > product. > > > > How about when v.in.ogr encounters this, offer a suggestion to fix, > > rather than simply erroring out? We could almost cut and paste your > > answer above. At least something a little less terse than, "ERROR: > > Cannot create table: [SQL statement]". That describes nothing about > > the problem encountered (duplicate columns)[1]. The error message talks about duplicate column names already. The issue is mentioned in one of the SQL or DBF help pages already (?), but I have added a note to the v.in.ogr help page as well (+6.2). Markus: > Another option is to change the last char of the offending > col(s) to an incrementing number: > > ADMIN_CLAS > ADMIN_CLA1 > ... maybe rare, but what happens if you have more than 10 similar column names? need to code for ADMIN_CL10, ADMIN_CL11, ..., ADMIN_C100, Hamish From hamish_nospam at yahoo.com Tue Sep 5 07:30:50 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Sep 5 07:32:03 2006 Subject: [GRASS-dev] v.in.ogr broken (\w shp) In-Reply-To: References: Message-ID: <20060905173050.670bf800.hamish_nospam@yahoo.com> Helena: > > it is one more reason to change the default DBMS in future (GRASS7?) Michael: > I'd vote for in GRASS 6.3 if it's doable. ... and SQLite is probably the only alternative to DBF that is simple enough not to cause undue installation headaches for new users. discussed this recently, http://thread.gmane.org/gmane.comp.gis.grass.devel/14634/ As William's points out there, all vector attributes are stored in one file per mapset. This is problematic for: - backups or easy transfer of a single map to another system - disk error etc would trash all vectors in mapset, not just the one map - with many vector maps in the same mapset 32bit users will rapidly hit the 2gb file size limit. Is per-map $MAPSET/vector/$MAPNAME/sqlite.db (or similar) possible? Hamish From hmitaso at unity.ncsu.edu Tue Sep 5 07:39:20 2006 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Tue Sep 5 07:39:39 2006 Subject: [GRASS-dev] v.in.ogr broken (\w shp) In-Reply-To: <20060905173050.670bf800.hamish_nospam@yahoo.com> References: <20060905173050.670bf800.hamish_nospam@yahoo.com> Message-ID: <440FAD06-A33E-480D-92F6-10B041015F1B@unity.ncsu.edu> On Sep 5, 2006, at 1:30 AM, Hamish wrote: > Helena: >>> it is one more reason to change the default DBMS in future (GRASS7?) > > Michael: >> I'd vote for in GRASS 6.3 if it's doable. > > ... and SQLite is probably the only alternative to DBF that is simple > enough not to cause undue installation headaches for new users. > > discussed this recently, > http://thread.gmane.org/gmane.comp.gis.grass.devel/14634/ > > As William's points out there, all vector attributes are stored in one > file per mapset. This is problematic for: > - backups or easy transfer of a single map to another system > - disk error etc would trash all vectors in mapset, not just the > one map > - with many vector maps in the same mapset 32bit users will > rapidly hit > the 2gb file size limit. Isn't there a better alternative? This does not sound good at all. Helena > > Is per-map $MAPSET/vector/$MAPNAME/sqlite.db (or similar) possible? > > > Hamish From grass-bugs at intevation.de Tue Sep 5 07:39:55 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Tue Sep 5 07:39:56 2006 Subject: [GRASS-dev] [bug #5101] (grass) NVIZ: horizontal sliders are backwards Message-ID: <20060905053955.094DA1005B6@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5101 ------------------------------------------------------------------------- Subject: NVIZ: horizontal sliders are backwards [fwd from -dev list] Hi, I'm working on a longstanding annoyance in NVIZ: many of the sliders are presented backwards. (e.g. lighting levels) this fix isn't complete though: if you type in a new out of range value & hit (e.g. Red=1.5) it goes backwards. More importantly, the vector points size slider gets stuck until you type in a new out of range value. ?? ideas? Hamish Index: widgets.tcl =================================================================== RCS file: /home/grass/grassrepository/grass6/visualization/nviz/scripts/widgets.tcl,v retrieving revision 1.2 diff -u -r1.2 widgets.tcl --- widgets.tcl 1 Aug 2005 17:57:15 -0000 1.2 +++ widgets.tcl 4 Sep 2006 09:33:38 -0000 @@ -165,10 +165,10 @@ } if {[expr $val < $min]} then { - $S.scale configure -to $val + $S.scale configure -from $val } if {[expr $val > $max]} then { - $S.scale configure -from $val + $S.scale configure -to $val } if {$val != 0} { if {[expr abs($val)] < [expr abs($res)]} { Index: panel_lights.tcl =================================================================== RCS file: /home/grass/grassrepository/grass6/visualization/nviz/scripts/panel_lights.tcl,v retrieving revision 2.0 diff -u -r2.0 panel_lights.tcl --- panel_lights.tcl 9 Nov 2004 14:18:38 -0000 2.0 +++ panel_lights.tcl 4 Sep 2006 09:33:38 -0000 @@ -41,15 +41,15 @@ -variable Nv_(FollowView) -command follow -onvalue 1 -offvalue 0 checkbutton $BASE.top.left.show -relief flat -text "Show Model" \ -variable Nv_(ShowModel) - Nv_mkScale $BASE.top.left.bright h Brightness 100 0 80 set_brt 2 - Nv_mkScale $BASE.top.left.ambient h Ambient 100 0 20 set_amb 2 + Nv_mkScale $BASE.top.left.bright h Brightness 0 100 80 set_brt 2 + Nv_mkScale $BASE.top.left.ambient h Ambient 0 100 20 set_amb 2 pack $BASE.top.left.follow $BASE.top.left.show \ $BASE.top.left.bright $BASE.top.left.ambient \ -side top -fill x -expand 1 - Nv_mkScale $BASE.top.right.red h Red 100 0 100 set_red 2 - Nv_mkScale $BASE.top.right.green h Green 100 0 100 set_green 2 - Nv_mkScale $BASE.top.right.blue h Blue 100 0 100 set_blue 2 + Nv_mkScale $BASE.top.right.red h Red 0 100 100 set_red 2 + Nv_mkScale $BASE.top.right.green h Green 0 100 100 set_green 2 + Nv_mkScale $BASE.top.right.blue h Blue 0 100 100 set_blue 2 pack $BASE.top.right.red $BASE.top.right.green $BASE.top.right.blue \ -side top -expand 1 -------------------------------------------- Managed by Request Tracker From radim.blazek at gmail.com Tue Sep 5 10:50:37 2006 From: radim.blazek at gmail.com (Radim Blazek) Date: Tue Sep 5 10:50:41 2006 Subject: [GRASS-dev] v.in.ogr broken (\w shp) In-Reply-To: <20060905173050.670bf800.hamish_nospam@yahoo.com> References: <20060905173050.670bf800.hamish_nospam@yahoo.com> Message-ID: <340505ef0609050150m2483b575wb403a06f6c06ca1d@mail.gmail.com> On 9/5/06, Hamish wrote: > discussed this recently, > http://thread.gmane.org/gmane.comp.gis.grass.devel/14634/ > > As William's points out there, all vector attributes are stored in one > file per mapset. This is problematic for: > - backups or easy transfer of a single map to another system > - disk error etc would trash all vectors in mapset, not just the one map > - with many vector maps in the same mapset 32bit users will rapidly hit > the 2gb file size limit. > > Is per-map $MAPSET/vector/$MAPNAME/sqlite.db (or similar) possible? Yes. This is discussed in my vector TODO, maybe you can look at http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass6/doc/vector/TODO?rev=1.2 Chapter 1.2 Attributes. The problem with db per map is that you cannot do joins from tables in more maps and you cannot use db.* commands without database option. Radim From glynn at gclements.plus.com Tue Sep 5 19:47:41 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Sep 5 19:47:44 2006 Subject: [GRASS-dev] adding files to the release branch? In-Reply-To: <20060905154557.5c5f191e.hamish_nospam@yahoo.com> References: <20060905154557.5c5f191e.hamish_nospam@yahoo.com> Message-ID: <17661.47165.914178.235341@cerise.gclements.plus.com> Hamish wrote: > I'm trying to add the v.dissolve and v.centroids scripts to the 6.2 > release branch but can't figure out how to add files to the branch. > I get: > > 6.2branch/grass6/scripts$ cvs add v.centroids/Makefile > cvs add: cannot open CVS/Entries for reading: No such file or directory > cvs [add aborted]: no repository cvs update -j HEAD v.centroids cvs commit v.centroids -- Glynn Clements From michael.barton at asu.edu Tue Sep 5 19:58:58 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Sep 5 19:59:09 2006 Subject: [GRASS-dev] v.in.ogr broken (\w shp) In-Reply-To: <340505ef0609050150m2483b575wb403a06f6c06ca1d@mail.gmail.com> Message-ID: This no more limiting than we have now, but with a more robust database and SQL. These issues are the same if we use PostgreSQL or MySQL too. I'm assuming that there is a way to export a table from an SQLite database and import it into another one. If so, they people who wanted to do joins could make a database where it is possible. 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: Radim Blazek > Date: Tue, 5 Sep 2006 10:50:37 +0200 > To: Hamish > Cc: Michael Barton , , > > Subject: Re: [GRASS-dev] v.in.ogr broken (\w shp) > > On 9/5/06, Hamish wrote: >> discussed this recently, >> http://thread.gmane.org/gmane.comp.gis.grass.devel/14634/ >> >> As William's points out there, all vector attributes are stored in one >> file per mapset. This is problematic for: >> - backups or easy transfer of a single map to another system >> - disk error etc would trash all vectors in mapset, not just the one map >> - with many vector maps in the same mapset 32bit users will rapidly hit >> the 2gb file size limit. >> >> Is per-map $MAPSET/vector/$MAPNAME/sqlite.db (or similar) possible? > > Yes. This is discussed in my vector TODO, maybe you can look at > http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass6/doc/vector/TODO?rev=1 > .2 > Chapter 1.2 Attributes. > The problem with db per map is that you cannot do joins from tables in > more maps and you cannot use db.* commands without database option. > > Radim From neteler at itc.it Wed Sep 6 00:00:05 2006 From: neteler at itc.it (Markus Neteler) Date: Wed Sep 6 00:00:07 2006 Subject: [GRASS-dev] Re: Grass 6.1 In-Reply-To: <20060901104308.GF5866@bartok.itc.it> References: <20060901090126.GB12905@bartok.itc.it> <44F7FDB0.2010304@club.worldonline.be> <20060901104308.GF5866@bartok.itc.it> Message-ID: <20060905220005.GA6437@bartok.itc.it> On Fri, Sep 01, 2006 at 12:43:08PM +0200, Markus Neteler wrote: > On Fri, Sep 01, 2006 at 11:30:24AM +0200, Moritz Lennert wrote: > ... > > The problem is actually with wish: > > > > $ wish > > Application initialization failed: this isn't a Tk applicationunknown > > color name "Black" > > > > So any tk application seems to fail with freenx. Best bet would be to > > ask on the the freenx-knx mailing list: > > > > https://mail.kde.org/mailman/listinfo/freenx-knx > > > > I would also be interested in the answer ;-) > > I have posted the question there, let's see! For the record: Found this one: http://jugboy.wordpress.com/2006/06/21/freenx-rgbtxt-configuration/ sudo ln -s /etc/X11/rgb.txt /usr/X11R6/lib/X11/ This solves the problem. Markus From glynn at gclements.plus.com Wed Sep 6 02:35:26 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Sep 6 02:35:30 2006 Subject: [GRASS-dev] Use of non-ANSI features Message-ID: <17662.6094.855310.241581@cerise.gclements.plus.com> Working file: lib/ogsf/gsd_img_tif.c ---------------------------- revision 2.9 date: 2006/09/04 21:07:08; author: cho; state: Exp; lines: +5 -1 typedefs for MinGW +#ifdef __MINGW32__ +typedef unsigned char u_char; +typedef unsigned short u_short; +#endif In general, gratuitous use of non-ANSI features should be eliminated altogether, rather than worked around. -- Glynn Clements From hamish_nospam at yahoo.com Wed Sep 6 07:08:09 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Sep 6 07:08:34 2006 Subject: [GRASS-dev] r.univar -e In-Reply-To: References: Message-ID: <20060906170809.73926b72.hamish_nospam@yahoo.com> Martin Landa wrote: > Hi all, > > I have added '-e' flag to r.univar according to r.univar.sh. See the > attached patch. Please look at the code, any comments welcomed... > (before committing to CVS - if desired...). Nice work! I have merged your patch locally with a few minor changes: http://bambi.otago.ac.nz/hamish/grass/r.univar_ext.c or if you prefer, http://bambi.otago.ac.nz/hamish/grass/r.univar_ext.diff A few comments/questions before putting it in CVS: * It is quite a bit faster than r.univar.sh! (I guess this is to be expected, but it's always nice to see) * qsort() comparison functions are declared as static int. a) shouldn't they just be int? b) could/should these fns be inlined for speed? * GRASS 5's s.cellstats uses something called qisort() instead of qsort(), which claims to be faster. Comments from the crowd? http://freegis.org/cgi-bin/viewcvs.cgi/grass/src/sites/s.cellstats/qisort.c?rev=HEAD&content-type=text/vnd.viewcvs-markup * Are there any issues with having shell variables (-g flag) which start with a number? * I've held off on reformatting the output. Your patch assumes that the font will be monospaced, while the new GUI(s) may prefer to use a proportional font. * fabsf() removed as it's non-POSIX. fabs() used instead. * Kept "Mean" instead of "Arithmetic mean". Sample, population, geometric means don't apply in this context, so keep it simple. TODOs easy: mean of squares (if anyone needs this just ask & I'll put it in) harder: mode, skewness, kurtosis (begging required, file a wish) thanks, Hamish From landa.martin at gmail.com Wed Sep 6 08:37:15 2006 From: landa.martin at gmail.com (Martin Landa) Date: Wed Sep 6 08:37:43 2006 Subject: [GRASS-dev] r.univar -e In-Reply-To: <20060906170809.73926b72.hamish_nospam@yahoo.com> References: <20060906170809.73926b72.hamish_nospam@yahoo.com> Message-ID: Hamish, 2006/9/6, Hamish : > I have merged your patch locally with a few minor changes: > http://bambi.otago.ac.nz/hamish/grass/r.univar_ext.c > or if you prefer, > http://bambi.otago.ac.nz/hamish/grass/r.univar_ext.diff > > A few comments/questions before putting it in CVS: > > * It is quite a bit faster than r.univar.sh! (I guess this is to be > expected, but it's always nice to see) It should be:-) > * qsort() comparison functions are declared as static int. > a) shouldn't they just be int? > b) could/should these fns be inlined for speed? Not sure, ... > * GRASS 5's s.cellstats uses something called qisort() instead of > qsort(), which claims to be faster. Comments from the crowd? > http://freegis.org/cgi-bin/viewcvs.cgi/grass/src/sites/s.cellstats/qisort.c?rev=HEAD&content-type=text/vnd.viewcvs-markup Hm, I have simply tested time r.univar elevation.10m -e 2>/dev/null| grep s$ real 0m0.817s user 0m0.764s sys 0m0.052s time r.univar elevation.10m -e 2>/dev/null| grep s$ real 0m0.532s user 0m0.516s sys 0m0.016s Not sure, should be qisort function part of GRASS library? > * Are there any issues with having shell variables (-g flag) which start > with a number? > > * I've held off on reformatting the output. Your patch assumes that the > font will be monospaced, while the new GUI(s) may prefer to use a > proportional font. > > * fabsf() removed as it's non-POSIX. fabs() used instead. > > * Kept "Mean" instead of "Arithmetic mean". Sample, population, > geometric means don't apply in this context, so keep it simple. Agreed > > > TODOs > easy: mean of squares (if anyone needs this just ask & I'll put it in) > harder: mode, skewness, kurtosis (begging required, file a wish) Nice to know:-) Best, Martin > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From rez at touchofmadness.com Wed Sep 6 08:59:05 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Wed Sep 6 08:59:41 2006 Subject: [GRASS-dev] r.univar -e In-Reply-To: <20060906170809.73926b72.hamish_nospam@yahoo.com> References: <20060906170809.73926b72.hamish_nospam@yahoo.com> Message-ID: <1157525945.14319.110.camel@devel> On Wed, 2006-09-06 at 17:08 +1200, Hamish wrote: > Martin Landa wrote: > > Hi all, > > > > I have added '-e' flag to r.univar according to r.univar.sh. See the > > attached patch. Please look at the code, any comments welcomed... > > (before committing to CVS - if desired...). > > Nice work! > > I have merged your patch locally with a few minor changes: > http://bambi.otago.ac.nz/hamish/grass/r.univar_ext.c > or if you prefer, > http://bambi.otago.ac.nz/hamish/grass/r.univar_ext.diff Great work guys! > A few comments/questions before putting it in CVS: > > * qsort() comparison functions are declared as static int. > a) shouldn't they just be int? static is the best declaration. Declaring the function static means it is "bound" to that file. As long as qsort() is called [only] from that file, it will work as designed. > b) could/should these fns be inlined for speed? Not 100% sure. I would assume that it is legal, but ignored. > * GRASS 5's s.cellstats uses something called qisort() instead of > qsort(), which claims to be faster. Comments from the crowd? > http://freegis.org/cgi-bin/viewcvs.cgi/grass/src/sites/s.cellstats/qisort.c?rev=HEAD&content-type=text/vnd.viewcvs-markup It seems that there exists a number of replacements for specific applications (the glibc qsort() is a one-stop-shop and not always "efficient"). Here is another similar example: http://www.corpit.ru/mjt/qsort.html I'll defer to Glynn... -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From glynn at gclements.plus.com Wed Sep 6 09:59:46 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Sep 6 09:59:57 2006 Subject: [GRASS-dev] r.univar -e In-Reply-To: <20060906170809.73926b72.hamish_nospam@yahoo.com> References: <20060906170809.73926b72.hamish_nospam@yahoo.com> Message-ID: <17662.32754.371401.211885@cerise.gclements.plus.com> Hamish wrote: > > I have added '-e' flag to r.univar according to r.univar.sh. See the > > attached patch. Please look at the code, any comments welcomed... > > (before committing to CVS - if desired...). > > Nice work! > > I have merged your patch locally with a few minor changes: > http://bambi.otago.ac.nz/hamish/grass/r.univar_ext.c > or if you prefer, > http://bambi.otago.ac.nz/hamish/grass/r.univar_ext.diff > > > A few comments/questions before putting it in CVS: > * qsort() comparison functions are declared as static int. > a) shouldn't they just be int? They aren't used from outside the file in which they are defined, so they should be declared "static". Note that "static" is a storage specifier; it isn't part of the type. > b) could/should these fns be inlined for speed? Indirect function calls (e.g. qsort() callbacks) cannot be inlined. > * GRASS 5's s.cellstats uses something called qisort() instead of > qsort(), which claims to be faster. Comments from the crowd? > http://freegis.org/cgi-bin/viewcvs.cgi/grass/src/sites/s.cellstats/qisort.c?rev=HEAD&content-type=text/vnd.viewcvs-markup It claims to be faster than some specific qsort() implementations on a specific system for specific test cases. Unless there is empirical evidence that qisort() beats the system's qsort() on the majority of systems with representative test data, I would recommend sticking with the system's qsort() routine. > * Are there any issues with having shell variables (-g flag) which start > with a number? Yes; at least, bash doesn't allow them. -- Glynn Clements From hamish_nospam at yahoo.com Wed Sep 6 12:11:05 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Sep 6 12:11:22 2006 Subject: [GRASS-dev] adding files to the release branch? In-Reply-To: <17661.47165.914178.235341@cerise.gclements.plus.com> References: <20060905154557.5c5f191e.hamish_nospam@yahoo.com> <17661.47165.914178.235341@cerise.gclements.plus.com> Message-ID: <20060906221105.143df9ae.hamish_nospam@yahoo.com> > Hamish wrote: > > I'm trying to add the v.dissolve and v.centroids scripts to the 6.2 > > release branch but can't figure out how to add files to the branch. > > I get: > > > > 6.2branch/grass6/scripts$ cvs add v.centroids/Makefile > > cvs add: cannot open CVS/Entries for reading: No such file or > > directory cvs [add aborted]: no repository Glynn Clements wrote: > cvs update -j HEAD v.centroids > cvs commit v.centroids I'm not sure if I'm using -j correctly; however, I got it done. what worked: cd 6.2branch/grass6/scripts/ cvs update -j HEAD v.centroids cvs tag -r HEAD releasebranch_6_2 v.centroids/ thanks, Hamish From grass-bugs at intevation.de Wed Sep 6 13:45:55 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Wed Sep 6 13:45:58 2006 Subject: [GRASS-dev] [bug #5103] (grass) Message-ID: <20060906114555.E58EA1005BE@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5103 ------------------------------------------------------------------------- Subject: -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Wed Sep 6 13:45:55 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Wed Sep 6 13:46:00 2006 Subject: [GRASS-dev] [bug #5104] (grass) Message-ID: <20060906114555.E6BB61005C0@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5104 ------------------------------------------------------------------------- Subject: -------------------------------------------- Managed by Request Tracker From mlennert at club.worldonline.be Wed Sep 6 14:17:23 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Sep 6 14:16:56 2006 Subject: [GRASS-dev] trying to amend d.vect.chart - need for advice Message-ID: <44FEBC53.8060903@club.worldonline.be> Hello, With a colleague we are trying to amend d.vect.chart in order to 1) speed it up 2) allow a where clause Currently, d.vect.chart loops through each vector feature and opens a new db cursor to fetch the column information. On a map with a fair amount of features (20464 centroids) with the table in Postgresql it seems that the db connection is what takes the most of the time (even worse obviously when the map is linked to a view which needs to be recalculated for every feature). So currently, the program's logic is as follows (in display/d.vect.chart/plot.c): - get number of features (little aside question: why is this done with Vect_get_num_lines() which should return number of lines, not number of features - as you can see I'm very new to the vector library) - loop through each feature: - get cat of feature - open cursor selecting columns [and sizecol] for this feature according to cat - close cursor - plot with this info We would like to modify this according to the following logic: - add a 'where' option - open a cursor selecting cat, columns [and sizecol] limited by the where option - loop through the cursor: - find x,y values according to cat - plot with this info - close cursor I have two main questions about this: 1) Does this sound reasonable ? Anything we are missing ? 2) Is there a function to get x,y point values according to cat value ? Thanks, Moritz From grass-bugs at intevation.de Wed Sep 6 16:14:56 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Wed Sep 6 16:14:58 2006 Subject: [GRASS-dev] [bug #5105] (grass) jesus bermudez Message-ID: <20060906141456.152931005B6@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5105 ------------------------------------------------------------------------- Subject: jesus bermudez Platform: WindowsNT/2000/XP grass binary for platform: Compiled from Sources Please enter your name and error description here. Don't write general statements such as "this could be better" - please explain in details how a certain problem can be solved or a feature be added/improved. Send different report for different problems. Thanks! -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Wed Sep 6 16:19:35 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Wed Sep 6 16:19:37 2006 Subject: [GRASS-dev] [bug #5106] (grass) Message-ID: <20060906141935.AF55C1005B6@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5106 ------------------------------------------------------------------------- Subject: -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Wed Sep 6 16:22:37 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Wed Sep 6 16:22:39 2006 Subject: [GRASS-dev] [bug #5107] (grass) jesus bermudez Message-ID: <20060906142237.AB9BA1005B6@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5107 ------------------------------------------------------------------------- Subject: jesus bermudez Platform: WindowsNT/2000/XP grass binary for platform: Compiled from Sources Please enter your name and error description here. Don't write general statements such as "this could be better" - please explain in details how a certain problem can be solved or a feature be added/improved. Send different report for different problems. Thanks! -------------------------------------------- Managed by Request Tracker From mlennert at club.worldonline.be Wed Sep 6 16:32:58 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Sep 6 16:32:32 2006 Subject: [GRASS-dev] ps.map: pattern for vpoints ? Message-ID: <44FEDC1A.1010608@club.worldonline.be> Hello all, but especially Hamish, How difficult would it be to enable the pat option for vpoints in ps.map ? We would like to be able to use patterns in circles of differents sizes. Moritz From neteler at itc.it Wed Sep 6 17:24:52 2006 From: neteler at itc.it (Markus Neteler) Date: Wed Sep 6 17:26:07 2006 Subject: [GRASS-dev] Re: Non-fatal bug fix In-Reply-To: References: <20060906144236.GK9848@bartok.itc.it> Message-ID: <20060906152452.GM9848@bartok.itc.it> Michael, (cc list to keep people informed) applying the recent diffs from you to 6.2 is not possible since it fails at many positions. There must be more differences to 6.3 than expected. I was hoping to present 6.2.0 at the Lausanne conference but now I hesitate. It's better to wait than publish broken software. For the liveCD we have a working version which is fine. Also, the available time is close to zero at my end. Suggestion: We stabilize gis.m in 6.3-CVS HEAD and ask folks to heavily test it. No new features for 1-2 weeks. Then, when I am back from Lausanne (17th) I will copy the entire gis.m changes to 6.2 and freeze it there. Does this sound reasonable? Markus On Wed, Sep 06, 2006 at 08:13:29AM -0700, Michael Barton wrote: > Markus, > > The big diff I sent should go into 6.2 if possible. > > The change in the email text needs to go into vector.tcl, and should also go > into 6.2 as a bug fix if possible. > > However, I can't send you a diff with JUST that change because the big > multifile diff has not yet been applied. I'll be in the office in an hour > and can put all into the CVS if you want, though it will be a bit > complicated for me given that I'm not sure what changes have been applied > over the past 3 days. > > 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 mlennert at club.worldonline.be Wed Sep 6 17:56:16 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Sep 6 17:55:49 2006 Subject: [GRASS-dev] v.what and spatial index In-Reply-To: <44DAE895.4060809@club.worldonline.be> References: <44DAE895.4060809@club.worldonline.be> Message-ID: <44FEEFA0.2050703@club.worldonline.be> Moritz Lennert wrote: > Hello, > > Trying to use v.what on a fairly large file (124658 areas) I noticed > that it rebuilds the spatial index at every usage, obviously making it > extremely inefficient. > > This is discussed briefly in bug #3193: > > http://www.intevation.de/rt/webrt?serial_num=3193&display=History > > And Radim mentions spatial index in his Vector ToDo document: > > http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup > > > This is a serious issue when you have to query such large maps frequently. > > > Radim wrote at the time: > > "Writing of the index to disk could be enabled by GRASS variable and/or > v.build option. But that changes vector format which must be supported > in all next version. Before we enable writing of spatial index, it > should be revised if the format can be changed to save some space." > > I think that seen the fact that we are quickly moving to new releases > and then to further development, it might be the time to take this up > again in order to plan ahead. > > In the bug report, Hamish proposes to create the spatial index once per > session and erase it when leaving the session. I don't know if space is > such as problem, but for me even this seems inefficient. Once the index > is created it should stay there even when leaving the session. Or at > least there should be a configurable option (maybe a GRASS environment > variable) to leave the index files in place. > > Any reactions ? > I have looked into the issue a bit more, and I see the following: v.what calls Vect_build_spatial_index() This function checks whether the spatial index is already available in memory (checking whether Map->plus.Spidx_built is set) and if not, goes on to call Vect_build_sidx_from_topo() which builds the actual index. IIUC, the memory holding the index is released automatically when v.what calls exit(). This means that for every v.what call the index needs to be rebuilt. The discussion so far has been about putting the spatial index into a file and then either erasing that file when the GRASS session is closed, or even keeping it across sessions. But, would it be possible to keep it in memory after v.what exits (or whatever program is first to build the index in a session) and erase it at the end of the GRASS session ? Or this is impossible with GRASS' modular structure ? Moritz From grass-bugs at intevation.de Wed Sep 6 18:09:30 2006 From: grass-bugs at intevation.de (Paul Kelly via RT) Date: Wed Sep 6 18:09:32 2006 Subject: [GRASS-dev] [bug #3167] (grass) g.setproj is leaving DEFAULT_WIND files in user mapsets Message-ID: <20060906160930.C40291005C9@lists.intevation.de> You need to have the PERMANENT mapset selected to run g.setproj successfully. I have added a crude check so it will stop if the mapset is not PERMANENT. See also bug 3876. Paul -------------------------------------------- Managed by Request Tracker From glynn at gclements.plus.com Wed Sep 6 19:58:51 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Sep 6 19:58:54 2006 Subject: [GRASS-dev] adding files to the release branch? In-Reply-To: <20060906221105.143df9ae.hamish_nospam@yahoo.com> References: <20060905154557.5c5f191e.hamish_nospam@yahoo.com> <17661.47165.914178.235341@cerise.gclements.plus.com> <20060906221105.143df9ae.hamish_nospam@yahoo.com> Message-ID: <17663.3163.5991.823648@cerise.gclements.plus.com> Hamish wrote: > > > I'm trying to add the v.dissolve and v.centroids scripts to the 6.2 > > > release branch but can't figure out how to add files to the branch. > > > I get: > > > > > > 6.2branch/grass6/scripts$ cvs add v.centroids/Makefile > > > cvs add: cannot open CVS/Entries for reading: No such file or > > > directory cvs [add aborted]: no repository > > Glynn Clements wrote: > > cvs update -j HEAD v.centroids > > cvs commit v.centroids > > I'm not sure if I'm using -j correctly; however, I got it done. > > what worked: > > cd 6.2branch/grass6/scripts/ > cvs update -j HEAD v.centroids > cvs tag -r HEAD releasebranch_6_2 v.centroids/ The "cvs tag" command should be unnecessary. The main difference between "cvs update -j" and "cvs update -r" is that -r tags the updated version with the tag used to retrieve it, while -j will use the current tag (i.e existing files will retain their tag, new files will get the tag from the CVS/Tag file). -- Glynn Clements From glynn at gclements.plus.com Wed Sep 6 20:28:17 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Sep 6 20:28:23 2006 Subject: [GRASS-dev] v.what and spatial index In-Reply-To: <44FEEFA0.2050703@club.worldonline.be> References: <44DAE895.4060809@club.worldonline.be> <44FEEFA0.2050703@club.worldonline.be> Message-ID: <17663.4929.559488.267433@cerise.gclements.plus.com> Moritz Lennert wrote: > v.what calls Vect_build_spatial_index() > > This function checks whether the spatial index is already available in > memory (checking whether Map->plus.Spidx_built is set) and if not, goes > on to call Vect_build_sidx_from_topo() which builds the actual index. > > IIUC, the memory holding the index is released automatically when v.what > calls exit(). > > This means that for every v.what call the index needs to be rebuilt. > > The discussion so far has been about putting the spatial index into a > file and then either erasing that file when the GRASS session is closed, > or even keeping it across sessions. > > But, would it be possible to keep it in memory after v.what exits (or > whatever program is first to build the index in a session) and erase it > at the end of the GRASS session ? Or this is impossible with GRASS' > modular structure ? Keeping it in memory isn't a practical solution; all of the standard shared memory mechanisms are relatively complex to use and not particularly portable. If a file is used often enough, and the system has enough unused memory, the OS will cache the file in memory. The main point about storing the spatial index is that the functionality needs to be integrated into the vector libraries and/or core modules, so that the index is either updated or deleted if the map is changed. Any mechanism which requires the user to manually synchronise the index with the map isn't acceptable, IMHO. -- Glynn Clements From michael.barton at asu.edu Wed Sep 6 21:24:08 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Sep 6 21:25:09 2006 Subject: [GRASS-dev] trying to amend d.vect.chart - need for advice In-Reply-To: <44FEBC53.8060903@club.worldonline.be> Message-ID: I know I may be asking a lot. But if you are successful with this project, what do you think about turning d.vect.thematic into a C-code module too? Many of the functions might be similar to those in d.vect.chart. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Moritz Lennert > Date: Wed, 06 Sep 2006 14:17:23 +0200 > To: Grass Developers List > Subject: [GRASS-dev] trying to amend d.vect.chart - need for advice > > Hello, > > With a colleague we are trying to amend d.vect.chart in order to > > 1) speed it up > 2) allow a where clause > > Currently, d.vect.chart loops through each vector feature and opens a > new db cursor to fetch the column information. On a map with a fair > amount of features (20464 centroids) with the table in Postgresql it > seems that the db connection is what takes the most of the time (even > worse obviously when the map is linked to a view which needs to be > recalculated for every feature). > > So currently, the program's logic is as follows (in > display/d.vect.chart/plot.c): > > - get number of features (little aside question: why is this done with > Vect_get_num_lines() which should return number of lines, not number of > features - as you can see I'm very new to the vector library) > - loop through each feature: > - get cat of feature > - open cursor selecting columns [and sizecol] for this feature > according to cat > - close cursor > - plot with this info > > We would like to modify this according to the following logic: > > - add a 'where' option > - open a cursor selecting cat, columns [and sizecol] limited by the > where option > - loop through the cursor: > - find x,y values according to cat > - plot with this info > - close cursor > > I have two main questions about this: > > 1) Does this sound reasonable ? Anything we are missing ? > 2) Is there a function to get x,y point values according to cat value ? > > Thanks, > > Moritz > > From mlennert at club.worldonline.be Wed Sep 6 21:44:14 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Sep 6 21:43:46 2006 Subject: [GRASS-dev] trying to amend d.vect.chart - need for advice In-Reply-To: References: Message-ID: <45467.85.10.65.35.1157571854.squirrel@geog-pc40.ulb.ac.be> On Wed, September 6, 2006 21:24, Michael Barton wrote: > I know I may be asking a lot. But if you are successful with this project, > what do you think about turning d.vect.thematic into a C-code module too? > Many of the functions might be similar to those in d.vect.chart. In the discussions about how to amend d.vect.chart, we have actually come to the conclusion that what you suggest is what we need ideally. It just is a larger project, so we might start with amending d.vect.chart. The biggest problem is actually to learn the vector library. I have to admit that I don't find the programmer's manual the most intuitive to find what I am looking for. Moritz > > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics and Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > >> From: Moritz Lennert >> Date: Wed, 06 Sep 2006 14:17:23 +0200 >> To: Grass Developers List >> Subject: [GRASS-dev] trying to amend d.vect.chart - need for advice >> >> Hello, >> >> With a colleague we are trying to amend d.vect.chart in order to >> >> 1) speed it up >> 2) allow a where clause >> >> Currently, d.vect.chart loops through each vector feature and opens a >> new db cursor to fetch the column information. On a map with a fair >> amount of features (20464 centroids) with the table in Postgresql it >> seems that the db connection is what takes the most of the time (even >> worse obviously when the map is linked to a view which needs to be >> recalculated for every feature). >> >> So currently, the program's logic is as follows (in >> display/d.vect.chart/plot.c): >> >> - get number of features (little aside question: why is this done with >> Vect_get_num_lines() which should return number of lines, not number of >> features - as you can see I'm very new to the vector library) >> - loop through each feature: >> - get cat of feature >> - open cursor selecting columns [and sizecol] for this feature >> according to cat >> - close cursor >> - plot with this info >> >> We would like to modify this according to the following logic: >> >> - add a 'where' option >> - open a cursor selecting cat, columns [and sizecol] limited by the >> where option >> - loop through the cursor: >> - find x,y values according to cat >> - plot with this info >> - close cursor >> >> I have two main questions about this: >> >> 1) Does this sound reasonable ? Anything we are missing ? >> 2) Is there a function to get x,y point values according to cat value ? >> >> Thanks, >> >> Moritz >> >> > > From neteler at itc.it Wed Sep 6 22:37:35 2006 From: neteler at itc.it (Markus Neteler) Date: Wed Sep 6 22:37:36 2006 Subject: [GRASS-dev] trying to amend d.vect.chart - need for advice In-Reply-To: <45467.85.10.65.35.1157571854.squirrel@geog-pc40.ulb.ac.be> References: <45467.85.10.65.35.1157571854.squirrel@geog-pc40.ulb.ac.be> Message-ID: <20060906203735.GC14706@bartok.itc.it> On Wed, Sep 06, 2006 at 09:44:14PM +0200, Moritz Lennert wrote: ... > The biggest problem is actually to learn the vector library. I have to > admit that I don't find the programmer's manual the most intuitive to find > what I am looking for. Hi Moritz, ... but what are you looking for? :-) To make it better, we need concrete questions to be asked which could then be answered in the manual. Don't hesiate to post it here, or better, do that in the Wiki. Later we can transfer that into the doxygen pages. If we through knowledge together, we may get a reasonable progman soon. Markus From hamish_nospam at yahoo.com Thu Sep 7 06:43:08 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Sep 7 06:43:30 2006 Subject: [GRASS-dev] ps.map: pattern for vpoints ? In-Reply-To: <44FEDC1A.1010608@club.worldonline.be> References: <44FEDC1A.1010608@club.worldonline.be> Message-ID: <20060907164308.7be16110.hamish_nospam@yahoo.com> Moritz Lennert wrote: > How difficult would it be to enable the pat option for vpoints in > ps.map ? We would like to be able to use patterns in circles of > differents sizes. I guess not difficult, just copy over the .eps code from vareas. I don't have time to work on this right now, but feel free to file a wish. an easy work-around is to use "v.buffer bufcol=" to create circles then use ps.map's vareas with the pat instruction. Hamish From hamish_nospam at yahoo.com Thu Sep 7 06:50:08 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Sep 7 06:50:26 2006 Subject: [GRASS-dev] v.what and spatial index In-Reply-To: <17663.4929.559488.267433@cerise.gclements.plus.com> References: <44DAE895.4060809@club.worldonline.be> <44FEEFA0.2050703@club.worldonline.be> <17663.4929.559488.267433@cerise.gclements.plus.com> Message-ID: <20060907165008.4b8fc991.hamish_nospam@yahoo.com> > Moritz Lennert wrote: > > v.what calls Vect_build_spatial_index() note that originally the spatial index *was* written to disk; try running GRASS 5.7.0 and see (?? not sure exactly when it was removed). Anyway it was removed after 1-2 years of running with it. Not a technical answer or argument against it, but be aware that it was removed with a lot of experience doing it the other way. further detail can be found in the mailing list archives from the time it was removed. (maybe same time v.build.all was added?) Hamish From hamish_nospam at yahoo.com Thu Sep 7 09:35:48 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Sep 7 09:36:06 2006 Subject: [GRASS-dev] trying to amend d.vect.chart - need for advice In-Reply-To: <44FEBC53.8060903@club.worldonline.be> References: <44FEBC53.8060903@club.worldonline.be> Message-ID: <20060907193548.0fc040af.hamish_nospam@yahoo.com> Moritz Lennert wrote: > > With a colleague we are trying to amend d.vect.chart in order to > > 1) speed it up > 2) allow a where clause > > Currently, d.vect.chart loops through each vector feature and opens a > new db cursor to fetch the column information. On a map with a fair > amount of features (20464 centroids) with the table in Postgresql it > seems that the db connection is what takes the most of the time (even > worse obviously when the map is linked to a view which needs to be > recalculated for every feature). > > So currently, the program's logic is as follows (in > display/d.vect.chart/plot.c): > > - get number of features (little aside question: why is this done with > > Vect_get_num_lines() which should return number of lines, not number > of features - as you can see I'm very new to the vector library) > - loop through each feature: > - get cat of feature > - open cursor selecting columns [and sizecol] for this feature > according to cat > - close cursor > - plot with this info > > We would like to modify this according to the following logic: > > - add a 'where' option > - open a cursor selecting cat, columns [and sizecol] limited by the > where option > - loop through the cursor: > - find x,y values according to cat > - plot with this info > - close cursor plotting to the screen is probably the slowest part; having that inside the loop is probably a slow down .. as a prototype could you write a shell script that runs v.extract + d.vect.chart? But it shouldn't be to hard to do as you suggest, and I imagine if you leave the actual close driver/stabilize call until after the loop it shouldn't be much slower. Hamish From mlennert at club.worldonline.be Thu Sep 7 10:09:28 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Sep 7 10:08:59 2006 Subject: [GRASS-dev] trying to amend d.vect.chart - need for advice In-Reply-To: <20060906203735.GC14706@bartok.itc.it> References: <45467.85.10.65.35.1157571854.squirrel@geog-pc40.ulb.ac.be> <20060906203735.GC14706@bartok.itc.it> Message-ID: <44FFD3B8.60303@club.worldonline.be> Markus Neteler wrote: > On Wed, Sep 06, 2006 at 09:44:14PM +0200, Moritz Lennert wrote: > ... >> The biggest problem is actually to learn the vector library. I have to >> admit that I don't find the programmer's manual the most intuitive to find >> what I am looking for. > > Hi Moritz, > > ... but what are you looking for? :-) > To make it better, we need concrete questions to be asked > which could then be answered in the manual. Just as an example: I was trying to find the definition of the Map_info structure. It's not in data structures... In its current form, you need to know in which file a function is and where this file is in the directory structure to easily find it. ... well I just saw that if you go into "Globals" you have an index, I have to admit that I never thought of looking there... (but still no Map_info structure definition) > > Don't hesiate to post it here, or better, do that > in the Wiki. Where do want me to post development questions in the Wiki ? > Later we can transfer that into the > doxygen pages. > > If we through knowledge together, we may get a reasonable > progman soon. I guess, I'll just have to find that time to really dig into it more and get used to GRASS' library structure. Moritz From rez at touchofmadness.com Thu Sep 7 10:31:55 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Thu Sep 7 10:32:02 2006 Subject: [GRASS-dev] nviz broken Message-ID: <1157617915.14319.161.camel@devel> Hello, The recent changes in the last couple days has broken nviz for at least 64bit platforms: GRASS 6.3.cvs (hamilton2):/usr/src/grass6 > nviz srtm.dem *** glibc detected *** nviz: realloc(): invalid pointer: 0x00007fff570221c8 *** ======= Backtrace: ========= /lib64/libc.so.6(__libc_realloc+0x323)[0x369486f9e3] /lib64/libc.so.6(__libc_realloc+0x3e)[0x369486f6fe] /opt/gis/grass-6.3.cvs/lib/libgrass_gis.so(G_realloc +0x42)[0x2aaaaaf69309] nviz(main+0x6a)[0x41f222] /lib64/libc.so.6(__libc_start_main+0xf4)[0x369481c784] -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From grass4u at gmail.com Thu Sep 7 11:21:01 2006 From: grass4u at gmail.com (Huidae Cho) Date: Thu Sep 7 11:21:45 2006 Subject: [GRASS-dev] nviz broken In-Reply-To: <1157617915.14319.161.camel@devel> References: <1157617915.14319.161.camel@devel> Message-ID: <20060907092101.GA29237@localhost.tamu.edu> Fixed in CVS. Thanks. On Thu, Sep 07, 2006 at 01:31:55AM -0700, Brad Douglas wrote: > Hello, > > The recent changes in the last couple days has broken nviz for at least > 64bit platforms: > > GRASS 6.3.cvs (hamilton2):/usr/src/grass6 > nviz srtm.dem > *** glibc detected *** nviz: realloc(): invalid pointer: > 0x00007fff570221c8 *** > ======= Backtrace: ========= > /lib64/libc.so.6(__libc_realloc+0x323)[0x369486f9e3] > /lib64/libc.so.6(__libc_realloc+0x3e)[0x369486f6fe] > /opt/gis/grass-6.3.cvs/lib/libgrass_gis.so(G_realloc > +0x42)[0x2aaaaaf69309] > nviz(main+0x6a)[0x41f222] > /lib64/libc.so.6(__libc_start_main+0xf4)[0x369481c784] > > > -- > Brad Douglas KB8UYR > Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From hamish_nospam at yahoo.com Thu Sep 7 12:02:39 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Sep 7 12:02:48 2006 Subject: [GRASS-dev] r.univar -e In-Reply-To: <17662.32754.371401.211885@cerise.gclements.plus.com> References: <20060906170809.73926b72.hamish_nospam@yahoo.com> <17662.32754.371401.211885@cerise.gclements.plus.com> Message-ID: <20060907220239.543cc0b2.hamish_nospam@yahoo.com> Martin: > > > I have added '-e' flag to r.univar according to r.univar.sh. See > > > the attached patch. Please look at the code, any comments > > > welcomed... (before committing to CVS - if desired...). Hamish: > > I have merged your patch locally with a few minor changes: now in 6.3-CVS. > > A few comments/questions before putting it in CVS: > > > * qsort() comparison functions are declared as static int. > > a) shouldn't they just be int? Brad: > static is the best declaration. Declaring the function static means > it is "bound" to that file. As long as qsort() is called [only] from > that file, it will work as designed. Glynn: > They aren't used from outside the file in which they are defined, so > they should be declared "static". > > Note that "static" is a storage specifier; it isn't part of the type. ok, I was thinking about the "global variable" use of that memory space. I guess the multi-file thing precludes qisort.c becoming a fast G_qsort()? fwiw, r.terraflow defines comparison functions in a similar way. > > b) could/should these fns be inlined for speed? > > Indirect function calls (e.g. qsort() callbacks) cannot be inlined. > > > * GRASS 5's s.cellstats uses something called qisort() instead of > > qsort(), which claims to be faster. Comments from the crowd? > > http://freegis.org/cgi-bin/viewcvs.cgi/grass/src/sites/s.cellstats/qisort.c?rev=HEAD&content-type=text/vnd.viewcvs-markup > > It claims to be faster than some specific qsort() implementations on a > specific system for specific test cases. > > Unless there is empirical evidence that qisort() beats the system's > qsort() on the majority of systems with representative test data, I > would recommend sticking with the system's qsort() routine. Martin: real 0m0.817s .. real 0m0.532s But I suppose the gcc/glibc people have their [good] reasons.......... > > * Are there any issues with having shell variables (-g flag) which > > start with a number? > > Yes; at least, bash doesn't allow them. ok, changed 1st_quartile= to first_quartile=, etc. I have updated i.landsat.rgb in CVS to use the new r.univar. For my sample imagery, processing now takes 4.0 seconds instead of 31.5! 8x win! Hamish From rez at touchofmadness.com Thu Sep 7 13:12:18 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Thu Sep 7 13:12:31 2006 Subject: [GRASS-dev] Vector file naming Message-ID: <1157627538.14319.185.camel@devel> GRASS 6.3.cvs (hamilton2):/usr/src/grass6 > r.to.vect in=elizabeth.los out=elizabeth.los feature=area Illegal vector map name . Character <.> not allowed. ERROR: Map name is not SQL compliant. How do file names conflict with SQL92? I thought SQL92 only applied to file contents. Is this also being used as a workaround for DBF limitations? What I'm getting at is: Why is '.' not allowed? Doing a quick archive search failed to illuminate any light bulbs in the immediate vicinity. -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From rez at touchofmadness.com Thu Sep 7 13:18:06 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Thu Sep 7 13:18:11 2006 Subject: [GRASS-dev] GL + PPM + nviz Message-ID: <1157627886.14319.189.camel@devel> We had tracked this down and fixed it once already. It's back: Creating PBuffer Using GLX 1.3 X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 21 Current serial number in output stream: 22 This happens specifically when trying to export high resolution PPM from nviz. http://grass.itc.it/pipermail/grass5/2006-June/023868.html -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From neteler at itc.it Thu Sep 7 13:20:37 2006 From: neteler at itc.it (Markus Neteler) Date: Thu Sep 7 13:20:39 2006 Subject: [GRASS-dev] r.univar -e In-Reply-To: <20060907220239.543cc0b2.hamish_nospam@yahoo.com> References: <20060906170809.73926b72.hamish_nospam@yahoo.com> <17662.32754.371401.211885@cerise.gclements.plus.com> <20060907220239.543cc0b2.hamish_nospam@yahoo.com> Message-ID: <45000085.1050506@itc.it> Hamish wrote on 09/07/2006 12:02 PM: > Martin: > >>>> I have added '-e' flag to r.univar according to r.univar.sh. See >>>> the attached patch. Please look at the code, any comments >>>> welcomed... (before committing to CVS - if desired...). > I have updated i.landsat.rgb in CVS to use the new r.univar. For my > sample imagery, processing now takes 4.0 seconds instead of 31.5! 8x win! > Wow, this is really great. Thanks so much for the long awaited improvement. Markus From neteler at itc.it Thu Sep 7 13:35:54 2006 From: neteler at itc.it (Markus Neteler) Date: Thu Sep 7 13:35:56 2006 Subject: [GRASS-dev] Vector file naming In-Reply-To: <1157627538.14319.185.camel@devel> References: <1157627538.14319.185.camel@devel> Message-ID: <20060907113554.GG18639@bartok.itc.it> On Thu, Sep 07, 2006 at 11:12:18AM +0000, Brad Douglas wrote: > GRASS 6.3.cvs (hamilton2):/usr/src/grass6 > r.to.vect in=elizabeth.los > out=elizabeth.los feature=area > Illegal vector map name . Character <.> not allowed. > ERROR: Map name is not SQL compliant. > > How do file names conflict with SQL92? I thought SQL92 only applied to > file contents. Is this also being used as a workaround for DBF > limitations? What I'm getting at is: Why is '.' not allowed? Doing a > quick archive search failed to illuminate any light bulbs in the > immediate vicinity. Hi Brad, AFAIK '.' is reserved for joins. '_' will work. See http://grass.itc.it/grass63/manuals/html63_user/sql.html -> NOTES It would be nice to have the naiming constraints relaxed but I am not sure if that's really possible. Markus From rez at touchofmadness.com Thu Sep 7 14:40:46 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Thu Sep 7 14:40:51 2006 Subject: [GRASS-dev] Vector file naming In-Reply-To: <20060907113554.GG18639@bartok.itc.it> References: <1157627538.14319.185.camel@devel> <20060907113554.GG18639@bartok.itc.it> Message-ID: <1157632846.14319.218.camel@devel> On Thu, 2006-09-07 at 13:35 +0200, Markus Neteler wrote: > On Thu, Sep 07, 2006 at 11:12:18AM +0000, Brad Douglas wrote: > > GRASS 6.3.cvs (hamilton2):/usr/src/grass6 > r.to.vect in=elizabeth.los > > out=elizabeth.los feature=area > > Illegal vector map name . Character <.> not allowed. > > ERROR: Map name is not SQL compliant. > > > > How do file names conflict with SQL92? I thought SQL92 only applied to > > file contents. Is this also being used as a workaround for DBF > > limitations? What I'm getting at is: Why is '.' not allowed? Doing a > > quick archive search failed to illuminate any light bulbs in the > > immediate vicinity. > > Hi Brad, > > AFAIK '.' is reserved for joins. '_' will work. > > See > http://grass.itc.it/grass63/manuals/html63_user/sql.html > -> NOTES > > It would be nice to have the naiming constraints relaxed but > I am not sure if that's really possible. '_' is also reserved for matching, so that can't be it. Maybe a better question is: Why doesn't GRASS distinguish between tables and files (database)? I would much prefer to have GRASS automatically substitute '_' for '.' in the table name so I can keep consistent naming conventions across rasters and vectors. It's a usability issue and somewhat annoying. :-) I guess the real question is: How big of a job would this be? Radim? If it isn't an overwhelming job, I'd like to propose it for 7.x. -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From paul-grass at stjohnspoint.co.uk Thu Sep 7 14:56:43 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Thu Sep 7 14:56:47 2006 Subject: [GRASS-dev] Vector file naming In-Reply-To: <20060907113554.GG18639@bartok.itc.it> References: <1157627538.14319.185.camel@devel> <20060907113554.GG18639@bartok.itc.it> Message-ID: On Thu, 7 Sep 2006, Markus Neteler wrote: > On Thu, Sep 07, 2006 at 11:12:18AM +0000, Brad Douglas wrote: >> GRASS 6.3.cvs (hamilton2):/usr/src/grass6 > r.to.vect in=elizabeth.los >> out=elizabeth.los feature=area >> Illegal vector map name . Character <.> not allowed. >> ERROR: Map name is not SQL compliant. >> >> How do file names conflict with SQL92? I thought SQL92 only applied to >> file contents. Is this also being used as a workaround for DBF >> limitations? What I'm getting at is: Why is '.' not allowed? Doing a >> quick archive search failed to illuminate any light bulbs in the >> immediate vicinity. > > Hi Brad, > > AFAIK '.' is reserved for joins. '_' will work. > > See > http://grass.itc.it/grass63/manuals/html63_user/sql.html > -> NOTES > > It would be nice to have the naiming constraints relaxed but > I am not sure if that's really possible. IIUC this is related to the earlier discussion about database files? With the current situation of having one database per mapset, each vector map has its own table in the database which matches the name of the map. And so the name of the map must conform to SQL table naming rules. If it was changed to have one database file per map then the SQL naming rules wouldn't be a problem. But TBH it does seem logical to have one database per mapset, as Radim said for queries over multiple maps etc. In fact really, one database for the whole location seems most logical. And some kind of relation to relate the table names in the database to the mapset and map they corresponded with. That would require a terrible lot of programming though I'm sure. Just thinking out loud. Paul From twiens at interbaun.com Thu Sep 7 16:29:57 2006 From: twiens at interbaun.com (Trevor Wiens) Date: Thu Sep 7 16:30:03 2006 Subject: [GRASS-dev] Vector file naming In-Reply-To: <1157632846.14319.218.camel@devel> References: <1157627538.14319.185.camel@devel> <20060907113554.GG18639@bartok.itc.it> <1157632846.14319.218.camel@devel> Message-ID: <20060907082957.03500ced@localhost.localdomain> On Thu, 07 Sep 2006 12:40:46 +0000 Brad Douglas wrote: > On Thu, 2006-09-07 at 13:35 +0200, Markus Neteler wrote: > > On Thu, Sep 07, 2006 at 11:12:18AM +0000, Brad Douglas wrote: > > > GRASS 6.3.cvs (hamilton2):/usr/src/grass6 > r.to.vect in=elizabeth.los > > > out=elizabeth.los feature=area > > > Illegal vector map name . Character <.> not allowed. > > > ERROR: Map name is not SQL compliant. > > > > > > How do file names conflict with SQL92? I thought SQL92 only applied to > > > file contents. Is this also being used as a workaround for DBF > > > limitations? What I'm getting at is: Why is '.' not allowed? Doing a > > > quick archive search failed to illuminate any light bulbs in the > > > immediate vicinity. > > > > Hi Brad, > > > > AFAIK '.' is reserved for joins. '_' will work. > > > > See > > http://grass.itc.it/grass63/manuals/html63_user/sql.html > > -> NOTES > > > > It would be nice to have the naiming constraints relaxed but > > I am not sure if that's really possible. > > '_' is also reserved for matching, so that can't be it. > > Maybe a better question is: Why doesn't GRASS distinguish between tables > and files (database)? I would much prefer to have GRASS automatically > substitute '_' for '.' in the table name so I can keep consistent naming > conventions across rasters and vectors. It's a usability issue and > somewhat annoying. :-) Well... To my knowledge standard SQL requires a letter as the first character of a table name, and after that letters, numbers, or underscores are permitted without quotation. If you want to break those rules double quotes are required. So the error message is correct. Using a period in a table name without double quoting is a violation of SQL naming rules. Normally a period is used to related columns to tables, aliases etc. For example select a.x, b.y from schema_one.table_x a, schema_two.table_y b where a.q = b.q Thus it is impossible for SQL to know how to parse this without quotes. > I guess the real question is: How big of a job would this be? Radim? > If it isn't an overwhelming job, I'd like to propose it for 7.x. Since we want to improve database support it seems reasonable to provide subtle education for GRASS users about SQL sticking with SQL naming restrictions. Therefore, it would be more logical to require rasters to fit the same naming restrictions as vectors for the 7.x line. There will be many users who will hate this idea as they are used to using periods in their raster file names, but this would be consistent. That said, you are correct that we could implement quoting of table names to allow rule breaking naming, but considering the difficulties with quotes and bash, this is just a place we don't want to go, AFAIC. So for 7.x we should do one of two things. One, do nothing, as relaxing the naming rules for vectors wouldn't be difficult, but it would be unwise and would introduce all new levels frustration for users not familiar with SQL. Two, enforce SQL and thus vector naming restrictions for rasters for the sake of consistency. T -- Trevor Wiens twiens@interbaun.com The significant problems that we face cannot be solved at the same level of thinking we were at when we created them. (Albert Einstein) From rez at touchofmadness.com Thu Sep 7 16:46:25 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Thu Sep 7 16:46:46 2006 Subject: [GRASS-dev] Vector file naming In-Reply-To: <20060907082957.03500ced@localhost.localdomain> References: <1157627538.14319.185.camel@devel> <20060907113554.GG18639@bartok.itc.it> <1157632846.14319.218.camel@devel> <20060907082957.03500ced@localhost.localdomain> Message-ID: <1157640385.14319.274.camel@devel> On Thu, 2006-09-07 at 08:29 -0600, Trevor Wiens wrote: > On Thu, 07 Sep 2006 12:40:46 +0000 > Brad Douglas wrote: > > > On Thu, 2006-09-07 at 13:35 +0200, Markus Neteler wrote: > > > On Thu, Sep 07, 2006 at 11:12:18AM +0000, Brad Douglas wrote: > > > > GRASS 6.3.cvs (hamilton2):/usr/src/grass6 > r.to.vect in=elizabeth.los > > > > out=elizabeth.los feature=area > > > > Illegal vector map name . Character <.> not allowed. > > > > ERROR: Map name is not SQL compliant. > > > > > > > > How do file names conflict with SQL92? I thought SQL92 only applied to > > > > file contents. Is this also being used as a workaround for DBF > > > > limitations? What I'm getting at is: Why is '.' not allowed? Doing a > > > > quick archive search failed to illuminate any light bulbs in the > > > > immediate vicinity. > > > > > > Hi Brad, > > > > > > AFAIK '.' is reserved for joins. '_' will work. > > > > > > See > > > http://grass.itc.it/grass63/manuals/html63_user/sql.html > > > -> NOTES > > > > > > It would be nice to have the naiming constraints relaxed but > > > I am not sure if that's really possible. > > > > '_' is also reserved for matching, so that can't be it. > > > > Maybe a better question is: Why doesn't GRASS distinguish between tables > > and files (database)? I would much prefer to have GRASS automatically > > substitute '_' for '.' in the table name so I can keep consistent naming > > conventions across rasters and vectors. It's a usability issue and > > somewhat annoying. :-) > > Well... To my knowledge standard SQL requires a letter as the first > character of a table name, and after that letters, numbers, or > underscores are permitted without quotation. If you want to break those > rules double quotes are required. So the error message is correct. > Using a period in a table name without double quoting is a violation of > SQL naming rules. Normally a period is used to related columns to > tables, aliases etc. > > For example > > select a.x, b.y > from schema_one.table_x a, schema_two.table_y b > where a.q = b.q > > Thus it is impossible for SQL to know how to parse this without quotes. Who says the *file name* has to be the same as the table name? No SQL spec governs that...it's up to the DBMS. GRASS just doesn't give me that option, currently. -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From neteler at itc.it Thu Sep 7 16:48:28 2006 From: neteler at itc.it (Markus Neteler) Date: Thu Sep 7 16:48:30 2006 Subject: [GRASS-dev] Vector file naming In-Reply-To: <1157640385.14319.274.camel@devel> References: <1157627538.14319.185.camel@devel> <20060907113554.GG18639@bartok.itc.it> <1157632846.14319.218.camel@devel> <20060907082957.03500ced@localhost.localdomain> <1157640385.14319.274.camel@devel> Message-ID: <4500313C.3060801@itc.it> Brad Douglas wrote on 09/07/2006 04:46 PM: > Who says the *file name* has to be the same as the table name? No SQL > spec governs that...it's up to the DBMS. GRASS just doesn't give me > that option, currently. > > I think it does: v.db.connect... Markus From mlennert at club.worldonline.be Thu Sep 7 17:43:45 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Sep 7 17:43:19 2006 Subject: [GRASS-dev] v.what and spatial index In-Reply-To: <20060907165008.4b8fc991.hamish_nospam@yahoo.com> References: <44DAE895.4060809@club.worldonline.be> <44FEEFA0.2050703@club.worldonline.be> <17663.4929.559488.267433@cerise.gclements.plus.com> <20060907165008.4b8fc991.hamish_nospam@yahoo.com> Message-ID: <45003E31.1070800@club.worldonline.be> Hamish wrote: >> Moritz Lennert wrote: >>> v.what calls Vect_build_spatial_index() > > > note that originally the spatial index *was* written to disk; try running > GRASS 5.7.0 and see (?? not sure exactly when it was removed). > > Anyway it was removed after 1-2 years of running with it. > > Not a technical answer or argument against it, but be aware that it was > removed with a lot of experience doing it the other way. > > further detail can be found in the mailing list archives from the time > it was removed. (maybe same time v.build.all was added?) http://grass.itc.it/pipermail/grass-dev/2004-November/016036.html and http://grass.itc.it/pipermail/grass-dev/2004-November/016045.html and http://grass.itc.it/pipermail/grass-commit/2004-November/015712.html ff The main reasoning behind this seems to have been for the needs of large point datasets. Radim's tests here http://grass.itc.it/pipermail/grass-dev/2004-November/016036.html seem to indicate that when the spatial index is reused several times by the module, the overhead of building it on the fly is not so important. However, v.what does not have an interactive mode (that's the whole idea of v.what so it fits better into the GUI). This means that since it builds the spatial index everytime you call it, everytime you use the query tool you get the building of the spatial index. Now, I see several options from here: - Change the query tool in the GUI so that it collects points and then sends the whole series to v.what. This has the big disadvantage that you don't see the results of your clicks immediately (i.e. you "blindly" click on a series of points and then push "go" to see the results for all of these points). It still means that whenever you resuse the query tool spatial index gets rebuilt which can be very annoying if you have to query information out of a map. So, even though this might be a temporary "solution", I don't find it very satisfactory. - Reimplement an interactive version of v.what, or rather make it possible to use d.what.vect from the GUI. This would probably mean recoding d.what.vect in whatever the GUI language and call GRASS library functions from there. - Reuse spatial index on disk, possibly making it optional on a per-location or even per-mapset basis, so that those that need can use it and those that would find it annoying could just ignore it. Moritz From mlennert at club.worldonline.be Thu Sep 7 17:47:49 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Sep 7 17:47:21 2006 Subject: [GRASS-dev] Vector file naming In-Reply-To: <4500313C.3060801@itc.it> References: <1157627538.14319.185.camel@devel> <20060907113554.GG18639@bartok.itc.it> <1157632846.14319.218.camel@devel> <20060907082957.03500ced@localhost.localdomain> <1157640385.14319.274.camel@devel> <4500313C.3060801@itc.it> Message-ID: <45003F25.1060802@club.worldonline.be> Markus Neteler wrote: > Brad Douglas wrote on 09/07/2006 04:46 PM: >> Who says the *file name* has to be the same as the table name? No SQL >> spec governs that...it's up to the DBMS. GRASS just doesn't give me >> that option, currently. >> >> > I think it does: v.db.connect... Yes, but r.to.vect doesn't allow you _not_ to create the table...unless you work with point data. Moritz From rez at touchofmadness.com Thu Sep 7 17:55:51 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Thu Sep 7 17:56:01 2006 Subject: [GRASS-dev] Vector file naming In-Reply-To: <4500313C.3060801@itc.it> References: <1157627538.14319.185.camel@devel> <20060907113554.GG18639@bartok.itc.it> <1157632846.14319.218.camel@devel> <20060907082957.03500ced@localhost.localdomain> <1157640385.14319.274.camel@devel> <4500313C.3060801@itc.it> Message-ID: <1157644551.14319.308.camel@devel> On Thu, 2006-09-07 at 16:48 +0200, Markus Neteler wrote: > Brad Douglas wrote on 09/07/2006 04:46 PM: > > Who says the *file name* has to be the same as the table name? No SQL > > spec governs that...it's up to the DBMS. GRASS just doesn't give me > > that option, currently. > > > > > I think it does: v.db.connect... Vect_legal_filename() says no. :( I understand that I could move entirely to a spacial database, but then I'm exclusively working with table names because that's where the geometry is stored. There is no geometry in a DBF, which allows us the ability to relax out file naming standards a bit by being able to reference the table and calling something else (the geometry file) the intended name. To illustrate: mv hamilton2/PERMANENT/vector/elizabeth_los/ hamilton2/PERMANENT/vector/elizabeth.los mv hamilton2/PERMANENT/dbf/elizabeth_los.dbf hamilton2/PERMANENT/dbf/elizabeth.los.dbf [brad@] > grass63 GRASS 6.3.cvs (hamilton2): > v.info elizabeth.los +----------------------------------------------------------------------------+ | Layer: elizabeth.los Organization: | | Mapset: PERMANENT Source Date: Thu Sep 7 03:00:55 | | Location: hamilton2 Name of creator: brad | ... [file behaves normally]. Either way, it isn't that big of a deal. :-) -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From hmitaso at unity.ncsu.edu Thu Sep 7 18:15:45 2006 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Thu Sep 7 18:14:23 2006 Subject: [GRASS-dev] Vector file naming In-Reply-To: <20060907082957.03500ced@localhost.localdomain> References: <1157627538.14319.185.camel@devel> <20060907113554.GG18639@bartok.itc.it> <1157632846.14319.218.camel@devel> <20060907082957.03500ced@localhost.localdomain> Message-ID: <450045B1.5080700@unity.ncsu.edu> Trevor Wiens wrote: > On Thu, 07 Sep 2006 12:40:46 +0000 > Brad Douglas wrote: > > >> On Thu, 2006-09-07 at 13:35 +0200, Markus Neteler wrote: >> >>> On Thu, Sep 07, 2006 at 11:12:18AM +0000, Brad Douglas wrote: >>> >>>> GRASS 6.3.cvs (hamilton2):/usr/src/grass6 > r.to.vect in=elizabeth.los >>>> out=elizabeth.los feature=area >>>> Illegal vector map name . Character <.> not allowed. >>>> ERROR: Map name is not SQL compliant. >>>> >>>> How do file names conflict with SQL92? I thought SQL92 only applied to >>>> file contents. Is this also being used as a workaround for DBF >>>> limitations? What I'm getting at is: Why is '.' not allowed? Doing a >>>> quick archive search failed to illuminate any light bulbs in the >>>> immediate vicinity. >>>> >>> Hi Brad, >>> >>> AFAIK '.' is reserved for joins. '_' will work. >>> >>> See >>> http://grass.itc.it/grass63/manuals/html63_user/sql.html >>> -> NOTES >>> >>> It would be nice to have the naiming constraints relaxed but >>> I am not sure if that's really possible. >>> >> '_' is also reserved for matching, so that can't be it. >> >> Maybe a better question is: Why doesn't GRASS distinguish between tables >> and files (database)? I would much prefer to have GRASS automatically >> substitute '_' for '.' in the table name so I can keep consistent naming >> conventions across rasters and vectors. It's a usability issue and >> somewhat annoying. :-) >> > > Well... To my knowledge standard SQL requires a letter as the first > character of a table name, and after that letters, numbers, or > underscores are permitted without quotation. If you want to break those > rules double quotes are required. So the error message is correct. > Using a period in a table name without double quoting is a violation of > SQL naming rules. Normally a period is used to related columns to > tables, aliases etc. > > For example > > select a.x, b.y > from schema_one.table_x a, schema_two.table_y b > where a.q = b.q > > Thus it is impossible for SQL to know how to parse this without quotes. > > >> I guess the real question is: How big of a job would this be? Radim? >> If it isn't an overwhelming job, I'd like to propose it for 7.x. >> > > Since we want to improve database support it seems reasonable to > provide subtle education for GRASS users about SQL sticking with SQL > naming restrictions. Therefore, it would be more logical to require > rasters to fit the same naming restrictions as vectors for the 7.x > line. There will be many users who will hate this idea as they are > used to using periods in their raster file names, but this would be > consistent. > Count me among those who really hate this idea as I have dot in about every single raster file name. And there are a lot of scripts around that use dots in raster names. It is already a pain to have that restriction in vector data. I am with Brad on this one, Helena > That said, you are correct that we could implement quoting > of table names to allow rule breaking naming, but considering the > difficulties with quotes and bash, this is just a place we don't want > to go, AFAIC. > > So for 7.x we should do one of two things. One, do nothing, as > relaxing the naming rules for vectors wouldn't be difficult, but it > would be unwise and would introduce all new levels frustration for > users not familiar with SQL. Two, enforce SQL and thus vector naming > restrictions for rasters for the sake of consistency. > > T > -- Helena Mitasova Department of Marine, Earth and Atmospheric Sciences North Carolina State University 1125 Jordan Hall NCSU Box 8208 Raleigh, NC 27695-8208 http://skagit.meas.ncsu.edu/~helena/ email: hmitaso@unity.ncsu.edu ph: 919-513-1327 (no voicemail) fax 919 515-7802 From paul-grass at stjohnspoint.co.uk Thu Sep 7 18:18:44 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Thu Sep 7 18:18:48 2006 Subject: [GRASS-dev] v.proj transforming z co-ordinates In-Reply-To: <44FAC060.1010306@o2.pl> References: <20060830153110.GT1046@bartok.itc.it> <44FAC060.1010306@o2.pl> Message-ID: Hello Maciek That is very strange. Can you post the output from v.proj please to see if there are any clues? Paul On Sun, 3 Sep 2006, Maciej Sieczka wrote: > Paul, > > I tried reprojecting a 3D points vector (3 arcsec strm) with v.proj, > from latlong WGS84 to UTM 34, and I see *no difference* in either x,y > or z coordinate, no matter whether the new implemented -z flag is used > or not. Is this OK? > > Maciek > From paul-grass at stjohnspoint.co.uk Thu Sep 7 18:25:26 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Thu Sep 7 18:25:28 2006 Subject: [GRASS-dev] v.proj transforming z co-ordinates In-Reply-To: <1157354894.5122.137.camel@devel> References: <1157354894.5122.137.camel@devel> Message-ID: Hello Brad On Mon, 4 Sep 2006, Brad Douglas wrote: > On Sun, 2006-08-27 at 00:00 +0100, Paul Kelly wrote: >> I suspected v.proj was doing this for years (since the introduction of the >> new vector format) but never got round to verifying the behaviour until >> yesterday. When re-projecting a 3-D vector file, if datum transformation >> parameters are specified using towgs84= notation (rather than nadgrids=), >> v.proj will assume the z co-ordinates are ellipsoidal heights and >> transform them accordingly. >> >> I think there are probably very few circumstances in which this behaviour >> would be desirable. It is much more common for height data to be specified >> relative to a vertical datum, e.g. mean sea level, than relative to the >> ellipsoid (which is normally only used for horizontal distances). > > This is definitely desirable. I would almost consider not being able to > project Z data a bug. Do you mean it was desirable the way the default behaviour was or the way it is now? If the former, have you any examples? Just out of interest. I really couldn't think of any but I am neither a geographer nor a geodisist... >> GPS data is more likely to include ellipsoidal height, but again it is >> (IMHO) of questionable usefulness to transform it to another ellipsoid: >> the geoid models that exist to transform GPS data to the local vertical >> datum in regular use (OSGM02 for Great Britain and Northern Ireland is the >> one I'm familiar with) convert directly from WGS84 ellipsoidal height data >> to height above mean sea level. > > I would reject projections involving different geoids. Otherwise, Z > data may be corrupted. At a minimum, a big fat disclaimer, but I would > prefer checking geoids and error if needed. But the problem is there is no way of telling what the z data is relative to; it might even mean nothing height-related at all. At present there is nowhere that this information is stored. I suggested in an earlier e-mail that perhaps it could be stored as part of the metadata with each vector map, but it is a big job I think. >> I propose the attached patch to add a specific flag to v.proj to enable >> the current behaviour, otherwise the z co-ordinates are always left >> untouched. I thought it was worth explaining and discussing properly >> because it changes the current behaviour and will give different results >> in certain circumstances, but IMHO the current behaviour is wrong. > > Does your patch lacks output of Z data (I see it does calculate values)? No; the z data passes straight through untouched. pj_do_transform() modifies only the x and y co-ordinates (it has pointers to these passed to it). > Other than the comments above, I'd like to see it applied. Great job! Already done a little while ago :) Paul From michael.barton at asu.edu Thu Sep 7 19:07:08 2006 From: michael.barton at asu.edu (Michael Barton) Date: Thu Sep 7 19:08:49 2006 Subject: [GRASS-dev] [bug #5098] (grass) gis.m; tcltk error when zooming to map with name which exists in more than one mapset In-Reply-To: <45003674.4020704@biol.uni.wroc.pl> Message-ID: Maciej, Thanks for the comments. I'm glad that the fixes were successful. I agree with you about the one click zooming out, only that it is intermittent. Sometimes I can click and it works perfectly and other times it does exactly what you show. I've spent some hours on this and remain baffled. I wanted to deal with the other issues first, but will certainly return to this puzzling one. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Maciej Sieczka > Date: Thu, 07 Sep 2006 17:10:44 +0200 > To: Michael Barton > Cc: grass-dev > Subject: Re: [GRASS-dev] [bug #5098] (grass) gis.m; tcltk error when zooming > to map with name which exists in more than one mapset > > Emailing you from another address having problems with my usual one. > > Michael Barton wrote: >> Here is something for times of boredom. >> >> This is the $GISBASE/etc/gm folder with all the new files for you to try >> out. >> >> Enjoy! > > So I did ;). > > The bug in zooming on different Map Displays is fixed for me using the > gis.m files you sent. It is also good that zoom/pan tools remain chosen > independently for each Map Display now. > > Also the "error when zooming to map with name which exists in more than > one mapset" bug is solved! Could you fix it for the old good d.m as > well in this regard? > > I think you should put these changes into CVS. > > Now I'd like to rise another issue - zooming out/in with *single mouse > clicks* doesn't work as expected in gis.m. Only the Y axis grows and > shrinks as it should. The X axis does not (if you zoom in/out with > single mouse click). > > Please zoom to the attached "try" region definition in Spearfish and > then zoom-out *using single mouse clicks* several times in gis.m. Then > do the same on the old Grass monitor with d.zoom. > > d.zoom performs OK, gis.m fails. See the attached dzoom2.png to see > what the display should look like after 2 single mouse click zoom outs > and the gism2.png to see how it looks after 2 single-mouse click zoom > outs in gis.m. The same problem applies to single mouse click zoom-in > in gis.m. Obviosly there is something wrong with the way the X axis is > scalled. Could you fix that bug? This, hopefully, is the last bug I > know in gis.m. > > Maciek > > proj: 1 > zone: 13 > north: 4923440 > south: 4922560 > east: 595200 > west: 594600 > cols: 30 > rows: 44 > e-w resol: 20 > n-s resol: 20 > top: 1 > bottom: 0 > cols3: 30 > rows3: 44 > depths: 1 > e-w resol3: 20 > n-s resol3: 20 > t-b resol: 1 > From grass-bugs at intevation.de Thu Sep 7 21:09:11 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Sep 7 21:09:13 2006 Subject: [GRASS-dev] [bug #5110] (grass) Unable to save workspace in gis.m with ps text layer Message-ID: <20060907190911.9DB451005D4@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5110 ------------------------------------------------------------------------- Subject: Unable to save workspace in gis.m with ps text layer Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: grass-6.2.cvs_src_snapshot_2006_08_31 I'm unable to save workspace in gis.m containing ps text layer. Really sucks, as I created some beautiful layout template and was not able to save it :( OS: GNU/Linux TCL/TK: 8.4.12 Error log: can't read "opt(1,east_north)": no such element in array can't read "opt(1,east_north)": no such element in array while executing "GmTree::rc_write $depth "$key $opt($id,$key)"" (procedure "GmCtext::save" line 7) invoked from within "GmCtext::save $tree($mon) $depth $node" ("ctext" arm line 4) invoked from within "switch $type { group { GmTree::rc_write $depth Group $name incr depth GmGroup::save $tree($mon) $depth $node } raster..." (procedure "GmTree::save_node" line 15) invoked from within "GmTree::save_node $depth $n" (procedure "GmGroup::save" line 11) invoked from within "GmGroup::save $tree($mon) 0 "root"" (procedure "GmTree::save" line 11) invoked from within "GmTree::save $filename($mon)" (procedure "Gm::SaveFileBox" line 13) invoked from within "Gm::SaveFileBox " invoked from within ".#menubar.#menubar#file.#menubar#file#menu1 invoke active" ("uplevel" body line 1) invoked from within "uplevel #0 [list $w invoke active]" (procedure "tk::MenuInvoke" line 50) invoked from within "tk::MenuInvoke .#menubar.#menubar#file.#menubar#file#menu1 1" (command bound to event) -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Thu Sep 7 21:19:31 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Sep 7 21:19:34 2006 Subject: [GRASS-dev] [bug #5111] (grass) Unable to rename map if similar exists in PERMANENT Message-ID: <20060907191931.B57FC1005BE@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5111 ------------------------------------------------------------------------- Subject: Unable to rename map if similar exists in PERMANENT Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: grass-6.2.cvs_src_snapshot_2006_08_31 I'm unable to rename raster map if map with same name exists in other mapset. Any manipulations with maps should happen in local mapset IF not specified othervise. PS. It would be nice to add some hint to manual how to rename maps with comma in name i.e. "Lake_25,5". Example: GRASS 6.2.0cvs (archimed):~ > g.gisenv GISDBASE=/home/maris/gis_dati LOCATION_NAME=archimed MAPSET=somijai DEBUG=0 MONITOR=x0 GRASS_GUI=tcltk GRASS 6.2.0cvs (archimed):~ > g.rename rast=MASKA,MASK ERROR: already exists in mapset GRASS 6.2.0cvs (archimed):~ > -------------------------------------------- Managed by Request Tracker From sieczka at biol.uni.wroc.pl Thu Sep 7 17:10:44 2006 From: sieczka at biol.uni.wroc.pl (Maciej Sieczka) Date: Thu Sep 7 23:06:44 2006 Subject: [GRASS-dev] [bug #5098] (grass) gis.m; tcltk error when zooming to map with name which exists in more than one mapset In-Reply-To: References: Message-ID: <45003674.4020704@biol.uni.wroc.pl> Emailing you from another address having problems with my usual one. Michael Barton wrote: > Here is something for times of boredom. > > This is the $GISBASE/etc/gm folder with all the new files for you to try > out. > > Enjoy! So I did ;). The bug in zooming on different Map Displays is fixed for me using the gis.m files you sent. It is also good that zoom/pan tools remain chosen independently for each Map Display now. Also the "error when zooming to map with name which exists in more than one mapset" bug is solved! Could you fix it for the old good d.m as well in this regard? I think you should put these changes into CVS. Now I'd like to rise another issue - zooming out/in with *single mouse clicks* doesn't work as expected in gis.m. Only the Y axis grows and shrinks as it should. The X axis does not (if you zoom in/out with single mouse click). Please zoom to the attached "try" region definition in Spearfish and then zoom-out *using single mouse clicks* several times in gis.m. Then do the same on the old Grass monitor with d.zoom. d.zoom performs OK, gis.m fails. See the attached dzoom2.png to see what the display should look like after 2 single mouse click zoom outs and the gism2.png to see how it looks after 2 single-mouse click zoom outs in gis.m. The same problem applies to single mouse click zoom-in in gis.m. Obviosly there is something wrong with the way the X axis is scalled. Could you fix that bug? This, hopefully, is the last bug I know in gis.m. Maciek -------------- next part -------------- A non-text attachment was scrubbed... Name: dzoom2.png Type: image/png Size: 7334 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060907/c6104954/dzoom2.png -------------- next part -------------- A non-text attachment was scrubbed... Name: gism2.png Type: image/png Size: 6996 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060907/c6104954/gism2.png -------------- next part -------------- proj: 1 zone: 13 north: 4923440 south: 4922560 east: 595200 west: 594600 cols: 30 rows: 44 e-w resol: 20 n-s resol: 20 top: 1 bottom: 0 cols3: 30 rows3: 44 depths: 1 e-w resol3: 20 n-s resol3: 20 t-b resol: 1 From neteler.osgeo at gmail.com Thu Sep 7 23:01:07 2006 From: neteler.osgeo at gmail.com (Markus Neteler) Date: Thu Sep 7 23:06:45 2006 Subject: [GRASS-dev] Re: [Incubator] Transfering Code Copyright - restart In-Reply-To: <45006BAC.1000908@pobox.com> References: <984940460F2DDF469C80EB0FFB86B80C13DBE6@msgusawmb04.ads.autodesk.com> <44FF7EED.40104@pobox.com> <20060907004221.np4umna4z9qo84kc@richsteele.org> <86782b610609070458p26f1722dl687611796764756f@mail.gmail.com> <20060907120955.fymqg71epgv4kocc@richsteele.org> <45006BAC.1000908@pobox.com> Message-ID: <86782b610609071401w739050cdl5222c6d24dd6b0d1@mail.gmail.com> (cc grass-dev) [@grass-dev: the full thread is here: https://incubator.osgeo.org/servlets/BrowseList?listName=incubator&by=date&from=2006-09-01&to=2006-09-30&first=1&count=23 ] On 9/7/06, Frank Warmerdam wrote: > rich@richsteele.org wrote: > > For GRASS, I think it has been settled that: (i) > > contributions will continue to be owned by the individual developer; > > (ii) those contributions will be licensed by the developer under the > > GPL; and (iii) no CLA will be required by the GRASS PSC. > > Rich, > > The GRASS project has lots of files which are labelled: > > * COPYRIGHT: (C) 2000 by the GRASS Development Team > > If we aren't arrangement assignment should these be corrected to list the > original author and/or some other "real" copyright holder? Frank, we are working on that (slowly, since we have 3000+ files to manually edit). Schuyler was do kind to write a perl script which extracts the contributor names from CVS. So, at least the author names should/ will be *also* there. > Does it affect > this decision that many of the files were originally in the public domain > from CERL? > > I feel ... uncomfortable ... having these files listing an impossible > (from a legal point of view) copyright holder. But on the other hand, I'm > really unclear on what the appropriate resolution to this would be. Probably we need to render "GRASS Development Team" into a legal entity? But: the authors are also listed (if not, we are working on that)! Markus From hamish_nospam at yahoo.com Fri Sep 8 04:21:57 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Sep 8 04:22:13 2006 Subject: [GRASS-dev] Vector file naming In-Reply-To: <45003F25.1060802@club.worldonline.be> References: <1157627538.14319.185.camel@devel> <20060907113554.GG18639@bartok.itc.it> <1157632846.14319.218.camel@devel> <20060907082957.03500ced@localhost.localdomain> <1157640385.14319.274.camel@devel> <4500313C.3060801@itc.it> <45003F25.1060802@club.worldonline.be> Message-ID: <20060908142157.6933b2ca.hamish_nospam@yahoo.com> Moritz Lennert wrote: > > Yes, but r.to.vect doesn't allow you _not_ to create the > table...unless you work with point data. a -t flag could be added, please file as a wish if this is important to your work. Hamish From hamish_nospam at yahoo.com Fri Sep 8 04:38:28 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Sep 8 04:41:39 2006 Subject: [GRASS-dev] [bug #5098] (grass) gis.m; tcltk error when zooming to map with name which exists in more than one mapset In-Reply-To: References: <45003674.4020704@biol.uni.wroc.pl> Message-ID: <20060908143828.3689d8bb.hamish_nospam@yahoo.com> Maciek: > > d.zoom performs OK, gis.m fails. See the attached dzoom2.png to see > > what the display should look like after 2 single mouse click zoom > > outs and the gism2.png to see how it looks after 2 single-mouse > > click zoom outs in gis.m. The same problem applies to single mouse > > click zoom-in in gis.m. Obviosly there is something wrong with the > > way the X axis is scalled. Could you fix that bug? This, hopefully, > > is the last bug I know in gis.m. .. > > cols: 30 > > rows: 44 > > e-w resol: 20 > > n-s resol: 20 Michael: > Thanks for the comments. I'm glad that the fixes were successful. I > agree with you about the one click zooming out, only that it is > intermittent. Sometimes I can click and it works perfectly and other > times it does exactly what you show. I've spent some hours on this and > remain baffled. I wanted to deal with the other issues first, but will > certainly return to this puzzling one. what happens if you try with a finer resolution? Hamish From glynn at gclements.plus.com Fri Sep 8 04:48:32 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Sep 8 04:48:35 2006 Subject: [GRASS-dev] GL + PPM + nviz In-Reply-To: <1157627886.14319.189.camel@devel> References: <1157627886.14319.189.camel@devel> Message-ID: <17664.55808.43523.286832@cerise.gclements.plus.com> Brad Douglas wrote: > We had tracked this down and fixed it once already. It's back: > > Creating PBuffer Using GLX 1.3 > X Error of failed request: GLXUnsupportedPrivateRequest > Major opcode of failed request: 143 (GLX) > Minor opcode of failed request: 16 (X_GLXVendorPrivate) > Serial number of failed request: 21 > Current serial number in output stream: 22 > > This happens specifically when trying to export high resolution PPM from > nviz. > http://grass.itc.it/pipermail/grass5/2006-June/023868.html If they don't work, you can turn them off: export GRASS_NO_GLX_PBUFFERS=1 export GRASS_NO_GLX_PIXMAPS=1 I'm starting to get really curious as to whether either pBuffers or GLX Pixmaps actually work for *anyone*. -- Glynn Clements From glynn at gclements.plus.com Fri Sep 8 05:16:31 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Sep 8 05:16:39 2006 Subject: [GRASS-dev] r.univar -e In-Reply-To: <20060907220239.543cc0b2.hamish_nospam@yahoo.com> References: <20060906170809.73926b72.hamish_nospam@yahoo.com> <17662.32754.371401.211885@cerise.gclements.plus.com> <20060907220239.543cc0b2.hamish_nospam@yahoo.com> Message-ID: <17664.57487.667926.49630@cerise.gclements.plus.com> Hamish wrote: > > > A few comments/questions before putting it in CVS: > > > > > * qsort() comparison functions are declared as static int. > > > a) shouldn't they just be int? > Brad: > > static is the best declaration. Declaring the function static means > > it is "bound" to that file. As long as qsort() is called [only] from > > that file, it will work as designed. > Glynn: > > They aren't used from outside the file in which they are defined, so > > they should be declared "static". > > > > Note that "static" is a storage specifier; it isn't part of the type. > > ok, I was thinking about the "global variable" use of that memory space. > I guess the multi-file thing precludes qisort.c becoming a fast G_qsort()? No. In my comments above, "used" refers to the point where the variable's name appears. If you have e.g. G_qsort(..., cmp_int), cmp_int is "used" in the file in which the call occurs, not the file where G_qsort() is defined. So long as the call occurs in the file where cmp_int is defined, it doesn't matter if it is declared "static". The "static" modifier on a global variable causes the symbol to be omitted from the symbol table of the object file, so the symbol cannot be referenced from another file. The object (variable, function) to which the symbol refers can still be referenced via a pointer, just not by name. > > > b) could/should these fns be inlined for speed? > > > > Indirect function calls (e.g. qsort() callbacks) cannot be inlined. > > > > > * GRASS 5's s.cellstats uses something called qisort() instead of > > > qsort(), which claims to be faster. Comments from the crowd? > > > http://freegis.org/cgi-bin/viewcvs.cgi/grass/src/sites/s.cellstats/qisort.c?rev=HEAD&content-type=text/vnd.viewcvs-markup > > > > It claims to be faster than some specific qsort() implementations on a > > specific system for specific test cases. > > > > Unless there is empirical evidence that qisort() beats the system's > > qsort() on the majority of systems with representative test data, I > > would recommend sticking with the system's qsort() routine. > > Martin: > real 0m0.817s > .. > real 0m0.532s That's a sample population of one, which is a rather small sample. Also, I don't know how representative the test data is. > But I suppose the gcc/glibc people have their [good] reasons.......... The libc qsort() needs to work over a wide range of cases, in terms of element size, number of elements, and whether the data is almost sorted, unsorted almost reverse-sorted etc. Some approaches do better for almost-sorted data at the expense of the general case (or vice-versa), or have better worst-case behaviour at the expense of the general case (or vice-versa). In general terms, a sorting algorithm optimised for specific cases will do better than a general-case one. If we were to add a single G_qsort() function, we would need to consider all use cases rather than choosing an algorithm based upon a specific case. OTOH, if we were to add a selection of sorting functions, each case would need to determine the correct one to use. -- Glynn Clements From glynn at gclements.plus.com Fri Sep 8 05:24:07 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Sep 8 05:24:11 2006 Subject: [GRASS-dev] v.what and spatial index In-Reply-To: <45003E31.1070800@club.worldonline.be> References: <44DAE895.4060809@club.worldonline.be> <44FEEFA0.2050703@club.worldonline.be> <17663.4929.559488.267433@cerise.gclements.plus.com> <20060907165008.4b8fc991.hamish_nospam@yahoo.com> <45003E31.1070800@club.worldonline.be> Message-ID: <17664.57943.168262.726011@cerise.gclements.plus.com> Moritz Lennert wrote: > However, v.what does not have an interactive mode (that's the whole idea > of v.what so it fits better into the GUI). This means that since it > builds the spatial index everytime you call it, everytime you use the > query tool you get the building of the spatial index. > > Now, I see several options from here: > - Change the query tool in the GUI so that it collects points and then > sends the whole series to v.what. This has the big disadvantage that you > don't see the results of your clicks immediately (i.e. you "blindly" > click on a series of points and then push "go" to see the results for > all of these points). It still means that whenever you resuse the query > tool spatial index gets rebuilt which can be very annoying if you have > to query information out of a map. So, even though this might be a > temporary "solution", I don't find it very satisfactory. > > - Reimplement an interactive version of v.what, or rather make it > possible to use d.what.vect from the GUI. This would probably mean > recoding d.what.vect in whatever the GUI language and call GRASS library > functions from there. The obvious approach is to extend v.what to allow coordinates to be read from stdin. BTW, it appears that v.what currently ignores all coordinate pairs other than the first. > - Reuse spatial index on disk, possibly making it optional on a > per-location or even per-mapset basis, so that those that need can use > it and those that would find it annoying could just ignore it. This is a separate issue to making v.what more efficient; other modules may benefit from not having to regenerate the spatial index for each invocation. -- Glynn Clements From glynn at gclements.plus.com Fri Sep 8 05:34:55 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Sep 8 05:35:02 2006 Subject: [GRASS-dev] Vector file naming In-Reply-To: <1157632846.14319.218.camel@devel> References: <1157627538.14319.185.camel@devel> <20060907113554.GG18639@bartok.itc.it> <1157632846.14319.218.camel@devel> Message-ID: <17664.58591.800263.134007@cerise.gclements.plus.com> Brad Douglas wrote: > > > GRASS 6.3.cvs (hamilton2):/usr/src/grass6 > r.to.vect in=elizabeth.los > > > out=elizabeth.los feature=area > > > Illegal vector map name . Character <.> not allowed. > > > ERROR: Map name is not SQL compliant. > > > > > > How do file names conflict with SQL92? I thought SQL92 only applied to > > > file contents. Is this also being used as a workaround for DBF > > > limitations? What I'm getting at is: Why is '.' not allowed? Doing a > > > quick archive search failed to illuminate any light bulbs in the > > > immediate vicinity. > > > > Hi Brad, > > > > AFAIK '.' is reserved for joins. '_' will work. > > > > See > > http://grass.itc.it/grass63/manuals/html63_user/sql.html > > -> NOTES > > > > It would be nice to have the naiming constraints relaxed but > > I am not sure if that's really possible. > > '_' is also reserved for matching, so that can't be it. No, _ is perfectly legal in column and table names. It is used as a wildcard by LIKE, but it isn't significant anywhere else. > Maybe a better question is: Why doesn't GRASS distinguish between tables > and files (database)? Because it isn't limited to the DBF driver. > I would much prefer to have GRASS automatically > substitute '_' for '.' in the table name so I can keep consistent naming > conventions across rasters and vectors. That could create a problem if you have both map.1 and map_1, as they would both have the same name. > It's a usability issue and somewhat annoying. :-) FWIW, these issues were pointed out when the new vector architecture was initially introduced. This isn't an oversight; it was a conscious choice. > I guess the real question is: How big of a job would this be? Radim? > If it isn't an overwhelming job, I'd like to propose it for 7.x. It would appear to be a big enough job that Radim chose not to do it when the issues were originally pointed out. -- Glynn Clements From glynn at gclements.plus.com Fri Sep 8 05:48:28 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Sep 8 05:48:31 2006 Subject: [GRASS-dev] [bug #5111] (grass) Unable to rename map if similar exists in PERMANENT In-Reply-To: <20060907191931.B57FC1005BE@lists.intevation.de> References: <20060907191931.B57FC1005BE@lists.intevation.de> Message-ID: <17664.59404.298963.19385@cerise.gclements.plus.com> Request Tracker wrote: > this bug's URL: http://intevation.de/rt/webrt?serial_num=5111 > Subject: Unable to rename map if similar exists in PERMANENT > > Platform: GNU/Linux/x86 > grass obtained from: Trento Italy site > grass binary for platform: Compiled from Sources > GRASS Version: grass-6.2.cvs_src_snapshot_2006_08_31 > > I'm unable to rename raster map if map with same name exists in other > mapset. Any manipulations with maps should happen in local mapset IF not > specified othervise. Having a warning for a "shadow" is a good idea; an error isn't. > PS. It would be nice to add some hint to manual how to rename maps with > comma in name i.e. "Lake_25,5". You can't; at least not with g.rename. You will have to manually rename the corresponding files/directories with "mv". G_legal_filename() should be changed to prohibit commas in map names. Probably some other characters (e.g. '@') as well. Currently, it allows any byte between 33 and 126 inclusive except for slash, double-quote and single-quote. Some of those will conflict with GRASS syntax (e.g. comma, at, equals), while others aren't legal in Windows filenames (e.g. backslash, query, asterisk). -- Glynn Clements From rez at touchofmadness.com Fri Sep 8 09:12:20 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Fri Sep 8 09:12:27 2006 Subject: [GRASS-dev] Vector file naming In-Reply-To: <17664.58591.800263.134007@cerise.gclements.plus.com> References: <1157627538.14319.185.camel@devel> <20060907113554.GG18639@bartok.itc.it> <1157632846.14319.218.camel@devel> <17664.58591.800263.134007@cerise.gclements.plus.com> Message-ID: <1157699540.14319.383.camel@devel> On Fri, 2006-09-08 at 04:34 +0100, Glynn Clements wrote: > Brad Douglas wrote: > > > > > GRASS 6.3.cvs (hamilton2):/usr/src/grass6 > r.to.vect in=elizabeth.los > > > > out=elizabeth.los feature=area > > > > Illegal vector map name . Character <.> not allowed. > > > > ERROR: Map name is not SQL compliant. > > > > > > > > How do file names conflict with SQL92? I thought SQL92 only applied to > > > > file contents. Is this also being used as a workaround for DBF > > > > limitations? What I'm getting at is: Why is '.' not allowed? Doing a > > > > quick archive search failed to illuminate any light bulbs in the > > > > immediate vicinity. > > > > > > Hi Brad, > > > > > > AFAIK '.' is reserved for joins. '_' will work. > > > > > > See > > > http://grass.itc.it/grass63/manuals/html63_user/sql.html > > > -> NOTES > > > > > > It would be nice to have the naiming constraints relaxed but > > > I am not sure if that's really possible. > > > > '_' is also reserved for matching, so that can't be it. > > No, _ is perfectly legal in column and table names. It is used as a > wildcard by LIKE, but it isn't significant anywhere else. > > > Maybe a better question is: Why doesn't GRASS distinguish between tables > > and files (database)? > > Because it isn't limited to the DBF driver. Perhaps this is what I find most frustrating. DBF is not spatially aware, so why should I be forced to adhere to unnecessary requirements? I find it somewhat embarrassing that I can simply move the directory containing geometry to the name I see fit without negative side effects. > > I would much prefer to have GRASS automatically > > substitute '_' for '.' in the table name so I can keep consistent naming > > conventions across rasters and vectors. > > That could create a problem if you have both map.1 and map_1, as they > would both have the same name. In my experience, I find it much less likely to encounter this error that the former. > > It's a usability issue and somewhat annoying. :-) > > FWIW, these issues were pointed out when the new vector architecture > was initially introduced. This isn't an oversight; it was a conscious > choice. > > > I guess the real question is: How big of a job would this be? Radim? > > If it isn't an overwhelming job, I'd like to propose it for 7.x. > > It would appear to be a big enough job that Radim chose not to do it > when the issues were originally pointed out. I understand the logic behind the present behavior, but I believe that logic would be best served if GRASS ceased to use it's own format and went with a real spatially aware SQL backend (there are several to choose from and SQLite as middleware makes interfacing a breeze). Perhaps, this will be the next incarnation of the vector architecture as spatial databases have matured significantly in recent years. GRASS is plagued with usability issues like this that will prevent it from being a viable competitor to commercial alternatives outside of the research community. Ok. This has been discussed to death. Back to work, everyone. :-) -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From mlennert at club.worldonline.be Fri Sep 8 09:26:43 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Sep 8 09:26:14 2006 Subject: [GRASS-dev] Vector file naming In-Reply-To: <20060908142157.6933b2ca.hamish_nospam@yahoo.com> References: <1157627538.14319.185.camel@devel> <20060907113554.GG18639@bartok.itc.it> <1157632846.14319.218.camel@devel> <20060907082957.03500ced@localhost.localdomain> <1157640385.14319.274.camel@devel> <4500313C.3060801@itc.it> <45003F25.1060802@club.worldonline.be> <20060908142157.6933b2ca.hamish_nospam@yahoo.com> Message-ID: <45011B33.606@club.worldonline.be> Hamish wrote: > Moritz Lennert wrote: >> Yes, but r.to.vect doesn't allow you _not_ to create the >> table...unless you work with point data. > > a -t flag could be added, please file as a wish if this is important to > your work. I actually think that maybe an option defining the table name of the table to be created together with the map might be the best solution. But this is valid for more than just r.to.vect (v.in.ogr jumps to mind). But it has never been a problem for me. Brad wrote: > I understand the logic behind the present behavior, but I believe that > logic would be best served if GRASS ceased to use it's own format and > went with a real spatially aware SQL backend (there are several to > choose from and SQLite as middleware makes interfacing a breeze). > Perhaps, this will be the next incarnation of the vector architecture as > spatial databases have matured significantly in recent years. I don't really understand how this solves your problem. In a spatially aware SQL backend you wouldn't be able to use dots in table/map names either, or ? Moritz From mlennert at club.worldonline.be Fri Sep 8 09:47:16 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Sep 8 09:46:48 2006 Subject: [GRASS-dev] v.what and spatial index In-Reply-To: <17664.57943.168262.726011@cerise.gclements.plus.com> References: <44DAE895.4060809@club.worldonline.be> <44FEEFA0.2050703@club.worldonline.be> <17663.4929.559488.267433@cerise.gclements.plus.com> <20060907165008.4b8fc991.hamish_nospam@yahoo.com> <45003E31.1070800@club.worldonline.be> <17664.57943.168262.726011@cerise.gclements.plus.com> Message-ID: <45012004.8030108@club.worldonline.be> Glynn Clements wrote: > Moritz Lennert wrote: > >> However, v.what does not have an interactive mode (that's the whole idea >> of v.what so it fits better into the GUI). This means that since it >> builds the spatial index everytime you call it, everytime you use the >> query tool you get the building of the spatial index. >> >> Now, I see several options from here: > >> - Change the query tool in the GUI so that it collects points and then >> sends the whole series to v.what. This has the big disadvantage that you >> don't see the results of your clicks immediately (i.e. you "blindly" >> click on a series of points and then push "go" to see the results for >> all of these points). It still means that whenever you resuse the query >> tool spatial index gets rebuilt which can be very annoying if you have >> to query information out of a map. So, even though this might be a >> temporary "solution", I don't find it very satisfactory. >> >> - Reimplement an interactive version of v.what, or rather make it >> possible to use d.what.vect from the GUI. This would probably mean >> recoding d.what.vect in whatever the GUI language and call GRASS library >> functions from there. > > The obvious approach is to extend v.what to allow coordinates to be > read from stdin. > > BTW, it appears that v.what currently ignores all coordinate pairs > other than the first. Didn't even try that, but yes. Shouldn't be too hard to implement, though. Trevor, any reason you left this out ? On the other hand, I just noticed that it allows querying multiple maps. Michael would it be possible to allow some form of multiple map selection in the gui to then call v.what with the names of all of these maps ? > >> - Reuse spatial index on disk, possibly making it optional on a >> per-location or even per-mapset basis, so that those that need can use >> it and those that would find it annoying could just ignore it. > > This is a separate issue to making v.what more efficient; other > modules may benefit from not having to regenerate the spatial index > for each invocation. v.what was just the example I stumbled upon. Although: mlennert@geog-pc40:~/SRC/GRASS/CVS/grass6/vector$ grep -R Vect_build_spatial_index * v.what/main.c: Vect_build_spatial_index ( &Map[i], NULL ); Is there another way of building the spatial index which other models use ? Moritz From mlennert at club.worldonline.be Fri Sep 8 09:54:00 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Sep 8 09:53:31 2006 Subject: [GRASS-dev] trying to amend d.vect.chart - need for advice In-Reply-To: <20060907193548.0fc040af.hamish_nospam@yahoo.com> References: <44FEBC53.8060903@club.worldonline.be> <20060907193548.0fc040af.hamish_nospam@yahoo.com> Message-ID: <45012198.7030601@club.worldonline.be> Hamish wrote: > Moritz Lennert wrote: >> With a colleague we are trying to amend d.vect.chart in order to >> >> 1) speed it up >> 2) allow a where clause >> >> Currently, d.vect.chart loops through each vector feature and opens a >> new db cursor to fetch the column information. On a map with a fair >> amount of features (20464 centroids) with the table in Postgresql it >> seems that the db connection is what takes the most of the time (even >> worse obviously when the map is linked to a view which needs to be >> recalculated for every feature). >> >> So currently, the program's logic is as follows (in >> display/d.vect.chart/plot.c): >> >> - get number of features (little aside question: why is this done with >> >> Vect_get_num_lines() which should return number of lines, not number >> of features - as you can see I'm very new to the vector library) >> - loop through each feature: >> - get cat of feature >> - open cursor selecting columns [and sizecol] for this feature >> according to cat >> - close cursor >> - plot with this info >> >> We would like to modify this according to the following logic: >> >> - add a 'where' option >> - open a cursor selecting cat, columns [and sizecol] limited by the >> where option >> - loop through the cursor: >> - find x,y values according to cat >> - plot with this info >> - close cursor > > plotting to the screen is probably the slowest part; having that inside > the loop is probably a slow down .. Yes, but unless you create a temporary map with the charts as objects, I don't know how you could not plot every chart separately. > as a prototype could you write a > shell script that runs v.extract + d.vect.chart? This would show an implementation of a where clause, but would not change the creation of a new cursor for every chart. But I can do that. > > But it shouldn't be to hard to do as you suggest, and I imagine if you > leave the actual close driver/stabilize call until after the loop it > shouldn't be much slower. Any hints as to a function to get x,y point values according to cat value ? Moritz From neteler at itc.it Fri Sep 8 10:10:47 2006 From: neteler at itc.it (Markus Neteler) Date: Fri Sep 8 10:10:48 2006 Subject: [GRASS-dev] GL + PPM + nviz In-Reply-To: <17664.55808.43523.286832@cerise.gclements.plus.com> References: <1157627886.14319.189.camel@devel> <17664.55808.43523.286832@cerise.gclements.plus.com> Message-ID: <45012587.5020703@itc.it> Glynn Clements wrote on 09/08/2006 04:48 AM: > Brad Douglas wrote: > > >> We had tracked this down and fixed it once already. It's back: >> >> Creating PBuffer Using GLX 1.3 >> X Error of failed request: GLXUnsupportedPrivateRequest >> Major opcode of failed request: 143 (GLX) >> Minor opcode of failed request: 16 (X_GLXVendorPrivate) >> Serial number of failed request: 21 >> Current serial number in output stream: 22 >> >> This happens specifically when trying to export high resolution PPM from >> nviz. >> http://grass.itc.it/pipermail/grass5/2006-June/023868.html >> > > If they don't work, you can turn them off: > > export GRASS_NO_GLX_PBUFFERS=1 > export GRASS_NO_GLX_PIXMAPS=1 > > I'm starting to get really curious as to whether either pBuffers or > GLX Pixmaps actually work for *anyone*. > > It does no longer work for me (it did in the past): [64bit RHEL4] recalculating normals... % Creating PBuffer Using GLX 1.3 Final Assembled Image will be 4096 x 3781 Writing Tile 1 of 1 Cannot open file for output. Assembling Tiles sh: /hardmnt/bartok0/ssi/neteler/software/cvsgrass61//tmp/dddtmp1.ppm: No such file or directory pnmcat failed to create assembled image Check that pnmcat is installed and path is set sh: /hardmnt/bartok0/ssi/neteler/software/cvsgrass61//tmp/ddd.ppm: No such file or directory pnmcat failed to create assembled images Check that pnmcat is installed and path is set GLX -- destroy pbuffer Segmentation fault A pity! Also the volume was broken apparently in May 2006. The quality of NVIZ seems to be continuously decreasing which isn't nice. Markus From hamish_nospam at yahoo.com Fri Sep 8 11:02:22 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Sep 8 11:02:38 2006 Subject: [GRASS-dev] r.univar -e In-Reply-To: <17664.57487.667926.49630@cerise.gclements.plus.com> References: <20060906170809.73926b72.hamish_nospam@yahoo.com> <17662.32754.371401.211885@cerise.gclements.plus.com> <20060907220239.543cc0b2.hamish_nospam@yahoo.com> <17664.57487.667926.49630@cerise.gclements.plus.com> Message-ID: <20060908210222.3e68f3b7.hamish_nospam@yahoo.com> > Hamish wrote: > > I guess the multi-file thing precludes qisort.c becoming a > > fast G_qsort()? > > No. In my comments above, "used" refers to the point where the > variable's name appears. > > If you have e.g. G_qsort(..., cmp_int), cmp_int is "used" in the file > in which the call occurs, not the file where G_qsort() is defined. So > long as the call occurs in the file where cmp_int is defined, it > doesn't matter if it is declared "static". ok. > The libc qsort() needs to work over a wide range of cases, in terms of > element size, number of elements, and whether the data is almost > sorted, unsorted almost reverse-sorted etc. > > Some approaches do better for almost-sorted data at the expense of the > general case (or vice-versa), or have better worst-case behaviour at > the expense of the general case (or vice-versa). > > In general terms, a sorting algorithm optimised for specific cases > will do better than a general-case one. If we were to add a single > G_qsort() function, we would need to consider all use cases rather > than choosing an algorithm based upon a specific case. OTOH, if we > were to add a selection of sorting functions, each case would need to > determine the correct one to use. I suppose our general case is cells which are not fully random. Usually raster data will be clumped, or at least cells will be part of a continous function (nearby cells won't be far off). Highly random raster data is probably pretty unusual. Hamish From radim.blazek at gmail.com Fri Sep 8 11:16:21 2006 From: radim.blazek at gmail.com (Radim Blazek) Date: Fri Sep 8 11:16:24 2006 Subject: [GRASS-dev] v.what and spatial index In-Reply-To: <45003E31.1070800@club.worldonline.be> References: <44DAE895.4060809@club.worldonline.be> <44FEEFA0.2050703@club.worldonline.be> <17663.4929.559488.267433@cerise.gclements.plus.com> <20060907165008.4b8fc991.hamish_nospam@yahoo.com> <45003E31.1070800@club.worldonline.be> Message-ID: <340505ef0609080216g5d39b3b6od507dcd30213e667@mail.gmail.com> On 9/7/06, Moritz Lennert wrote: > Radim's tests here > http://grass.itc.it/pipermail/grass-dev/2004-November/016036.html > > seem to indicate that when the spatial index is reused several times by > the module, the overhead of building it on the fly is not so important. Yes, I think that the best solution is to rewrite the library to store spatial index in a file, i.e. never keep the whole structure in memory and read the tree items directly from the file. That should be relatively simple IMO. That is also described in my vector TODO. It means to add support to read/write Node structures from/to file instead of memory. Currently the nodes are referenced by pointer to memory which could be replaced by file offset. You need to add some functions like struct Node *RTreeReadNode(long offset) and use it in other functions, for example: struct Node *node = RTreeReadNode ( n->branch[i].child ); hitCount += RTreeSearch(node, R, shcb, cbarg); RTreeFreeNode(node); instead of hitCount += RTreeSearch(n->branch[i].child, R, shcb, cbarg); But it will be better to keep both options - file and memory and use it according to vector size. Most of the general problems and suggested solutions are described in the TODO. Radim From hamish_nospam at yahoo.com Fri Sep 8 11:36:33 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Sep 8 11:36:40 2006 Subject: [GRASS-dev] GL + PPM + nviz In-Reply-To: <45012587.5020703@itc.it> References: <1157627886.14319.189.camel@devel> <17664.55808.43523.286832@cerise.gclements.plus.com> <45012587.5020703@itc.it> Message-ID: <20060908213633.26cf9695.hamish_nospam@yahoo.com> > > Brad Douglas wrote: > >> We had tracked this down and fixed it once already. It's back: > >> > >> Creating PBuffer Using GLX 1.3 > >> X Error of failed request: GLXUnsupportedPrivateRequest > >> Major opcode of failed request: 143 (GLX) > >> Minor opcode of failed request: 16 (X_GLXVendorPrivate) > >> Serial number of failed request: 21 > >> Current serial number in output stream: 22 > >> > >> This happens specifically when trying to export high resolution PPM > >from > nviz. Markus, Brad, does this work for you in 6.1.0? In 6.3 if you do: > If they don't work, you can turn them off: > export GRASS_NO_GLX_PBUFFERS=1 > export GRASS_NO_GLX_PIXMAPS=1 ? As the problem appears to be widespread, I propose to disable off- screen rendering for the 6.2 release branch and work on fixing the problem in 6.3-cvs. Hamish From hamish_nospam at yahoo.com Fri Sep 8 12:00:01 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Sep 8 12:00:07 2006 Subject: [GRASS-dev] Re: [bug #2765] v.buffer bug?? Message-ID: <20060908220001.7086d05c.hamish_nospam@yahoo.com> Can someone provide me with a simple vector file where the buffering bug happens? or make it happen with a Speafish map? Maciek: > http://www.biol.uni.wroc.pl/sieczka/udostepnione/grass/corrupted_buffer_of_a_line.png thanks, Hamish From neteler at itc.it Fri Sep 8 15:25:02 2006 From: neteler at itc.it (Markus Neteler) Date: Fri Sep 8 15:25:03 2006 Subject: [GRASS-dev] GL + PPM + nviz In-Reply-To: <20060908213633.26cf9695.hamish_nospam@yahoo.com> References: <1157627886.14319.189.camel@devel> <17664.55808.43523.286832@cerise.gclements.plus.com> <45012587.5020703@itc.it> <20060908213633.26cf9695.hamish_nospam@yahoo.com> Message-ID: <45016F2E.8050307@itc.it> Hamish wrote on 09/08/2006 11:36 AM: >>> Brad Douglas wrote: >>> >>>> We had tracked this down and fixed it once already. It's back: >>>> >>>> Creating PBuffer Using GLX 1.3 >>>> X Error of failed request: GLXUnsupportedPrivateRequest >>>> Major opcode of failed request: 143 (GLX) >>>> Minor opcode of failed request: 16 (X_GLXVendorPrivate) >>>> Serial number of failed request: 21 >>>> Current serial number in output stream: 22 >>>> >>>> This happens specifically when trying to export high resolution PPM >>>> >> >from > nviz. >> > > > Markus, Brad, does this work for you in 6.1.0? > NVIZ volume + NVIZ highres output fail in 6.1.0. I would need a version before May 2006 to see if it was broken by the togl update and related changes. Does anyone have a CVS snapshot from April? Markus From twiens at interbaun.com Fri Sep 8 16:07:16 2006 From: twiens at interbaun.com (Trevor Wiens) Date: Fri Sep 8 16:07:19 2006 Subject: [GRASS-dev] v.what and spatial index In-Reply-To: <45012004.8030108@club.worldonline.be> References: <44DAE895.4060809@club.worldonline.be> <44FEEFA0.2050703@club.worldonline.be> <17663.4929.559488.267433@cerise.gclements.plus.com> <20060907165008.4b8fc991.hamish_nospam@yahoo.com> <45003E31.1070800@club.worldonline.be> <17664.57943.168262.726011@cerise.gclements.plus.com> <45012004.8030108@club.worldonline.be> Message-ID: <20060908080716.5a515447@localhost.localdomain> On Fri, 08 Sep 2006 09:47:16 +0200 Moritz Lennert wrote: > Glynn Clements wrote: > > Moritz Lennert wrote: > > > >> However, v.what does not have an interactive mode (that's the whole idea > >> of v.what so it fits better into the GUI). This means that since it > >> builds the spatial index everytime you call it, everytime you use the > >> query tool you get the building of the spatial index. > >> > >> Now, I see several options from here: > > > >> - Change the query tool in the GUI so that it collects points and then > >> sends the whole series to v.what. This has the big disadvantage that you > >> don't see the results of your clicks immediately (i.e. you "blindly" > >> click on a series of points and then push "go" to see the results for > >> all of these points). It still means that whenever you resuse the query > >> tool spatial index gets rebuilt which can be very annoying if you have > >> to query information out of a map. So, even though this might be a > >> temporary "solution", I don't find it very satisfactory. > >> > >> - Reimplement an interactive version of v.what, or rather make it > >> possible to use d.what.vect from the GUI. This would probably mean > >> recoding d.what.vect in whatever the GUI language and call GRASS library > >> functions from there. > > > > The obvious approach is to extend v.what to allow coordinates to be > > read from stdin. > > > > BTW, it appears that v.what currently ignores all coordinate pairs > > other than the first. > > Didn't even try that, but yes. Shouldn't be too hard to implement, > though. Trevor, any reason you left this out ? > I simply removed the interactive functionality in d.what.vect which Radim wrote. Other than that I made only minimal changes to the code. That could be added however fairly easily. I think however the more pressing issue is some of the re-write stuff that Radim refers to in his TODO. At this time, I don't have the familiarity with the vector library to work on that list of items, sorry. However, once the spatial index is stored in a file and read as needed, this would eliminate the need for entering multiple point sets wouldn't it? If however we need multiple point sets, I'm sure that I could add that relatively quickly if needed. T -- Trevor Wiens twiens@interbaun.com The significant problems that we face cannot be solved at the same level of thinking we were at when we created them. (Albert Einstein) From hmitaso at unity.ncsu.edu Fri Sep 8 16:19:11 2006 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Fri Sep 8 16:19:17 2006 Subject: [GRASS-dev] GL + PPM + nviz In-Reply-To: <45016F2E.8050307@itc.it> References: <1157627886.14319.189.camel@devel> <17664.55808.43523.286832@cerise.gclements.plus.com> <45012587.5020703@itc.it> <20060908213633.26cf9695.hamish_nospam@yahoo.com> <45016F2E.8050307@itc.it> Message-ID: <46881727-3941-4BF8-9D00-B59D926AE247@unity.ncsu.edu> I have a February 2006 CVS on my Mac, but I need to finish my talk first, then I can test, hopefully later today or tomorrow, unless somebody else responds too. Helena Helena Mitasova Dept. of Marine, Earth and Atm. Sciences 1125 Jordan Hall, NCSU Box 8208, Raleigh NC 27695 http://skagit.meas.ncsu.edu/~helena/ On Sep 8, 2006, at 9:25 AM, Markus Neteler wrote: > Hamish wrote on 09/08/2006 11:36 AM: >>>> Brad Douglas wrote: >>>> >>>>> We had tracked this down and fixed it once already. It's back: >>>>> >>>>> Creating PBuffer Using GLX 1.3 >>>>> X Error of failed request: GLXUnsupportedPrivateRequest >>>>> Major opcode of failed request: 143 (GLX) >>>>> Minor opcode of failed request: 16 (X_GLXVendorPrivate) >>>>> Serial number of failed request: 21 >>>>> Current serial number in output stream: 22 >>>>> >>>>> This happens specifically when trying to export high resolution >>>>> PPM >>>>> >>>> from > nviz. >>> >> >> >> Markus, Brad, does this work for you in 6.1.0? >> > > NVIZ volume + NVIZ highres output fail in 6.1.0. > I would need a version before May 2006 to see if it was broken > by the togl update and related changes. > > Does anyone have a CVS snapshot from April? > > Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From glynn at gclements.plus.com Fri Sep 8 21:42:53 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Sep 8 21:42:57 2006 Subject: [GRASS-dev] GL + PPM + nviz In-Reply-To: <45012587.5020703@itc.it> References: <1157627886.14319.189.camel@devel> <17664.55808.43523.286832@cerise.gclements.plus.com> <45012587.5020703@itc.it> Message-ID: <17665.51133.930503.179724@cerise.gclements.plus.com> Markus Neteler wrote: > >> We had tracked this down and fixed it once already. It's back: > >> > >> Creating PBuffer Using GLX 1.3 > >> X Error of failed request: GLXUnsupportedPrivateRequest > >> Major opcode of failed request: 143 (GLX) > >> Minor opcode of failed request: 16 (X_GLXVendorPrivate) > >> Serial number of failed request: 21 > >> Current serial number in output stream: 22 > >> > >> This happens specifically when trying to export high resolution PPM from > >> nviz. > >> http://grass.itc.it/pipermail/grass5/2006-June/023868.html > >> > > > > If they don't work, you can turn them off: > > > > export GRASS_NO_GLX_PBUFFERS=1 > > export GRASS_NO_GLX_PIXMAPS=1 > > > > I'm starting to get really curious as to whether either pBuffers or > > GLX Pixmaps actually work for *anyone*. > > > > > It does no longer work for me (it did in the past): > [64bit RHEL4] > > recalculating normals... > % Creating PBuffer Using GLX 1.3 > Final Assembled Image will be 4096 x 3781 > Writing Tile 1 of 1 > Cannot open file for output. > Assembling Tiles > sh: /hardmnt/bartok0/ssi/neteler/software/cvsgrass61//tmp/dddtmp1.ppm: This is a different issue. I note that Nstart_zoom_cmd() only uses a 64-byte buffer for the prefix; you may be overflowing that. > No such file or directory > pnmcat failed to create assembled image > Check that pnmcat is installed and path is set > sh: /hardmnt/bartok0/ssi/neteler/software/cvsgrass61//tmp/ddd.ppm: No > such file or directory > pnmcat failed to create assembled images > Check that pnmcat is installed and path is set > GLX -- destroy pbuffer > Segmentation fault > > A pity! Also the volume was broken apparently in May 2006. > The quality of NVIZ seems to be continuously decreasing > which isn't nice. That's probably inevitable. The complexity of NVIZ/OGSF is such that I doubt that any GRASS developer really understands it. -- Glynn Clements From grass4u at gmail.com Sat Sep 9 18:37:26 2006 From: grass4u at gmail.com (Huidae Cho) Date: Sat Sep 9 18:38:53 2006 Subject: [GRASS-dev] Re: d.extend In-Reply-To: References: <20060909030324.GA93797@localhost.tamu.edu> Message-ID: <20060909162947.GA80242@localhost> On Sat, Sep 09, 2006 at 07:52:38AM -0700, Michael Barton wrote: > I've never had it work correctly because (if I remember correctly), it uses > display history. This doesn't work well with gism. However, I keep hoping > that someone could fix it. You mean display history doesn't work with gism? Do you know what's wrong with this? Huidae > > 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: Huidae Cho > > Date: Fri, 8 Sep 2006 22:03:24 -0500 > > To: Michael Barton > > Subject: d.extend > > > > Hi, > > > > d.extend (Config->Region->Zoom to maximum...) does not work because > > GRASS_RENDER_IMMEDIATE is unset immediately after displaying maps. It's > > somewhat odd to find this module in Config, not from Map Display with > > other "Zoom to" menus. > > > > Thanks. > > Huidae > From grass-bugs at intevation.de Sun Sep 10 11:40:50 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sun Sep 10 11:40:52 2006 Subject: [GRASS-dev] [bug #5118] (grass) v.db.droptable: an 'ERROR' is always issued though the command completes OK Message-ID: <20060910094050.9620F1005AB@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5118 ------------------------------------------------------------------------- Subject: v.db.droptable: an 'ERROR' is always issued though the command completes OK Platform: GNU/Linux/x86 grass obtained from: CVS grass binary for platform: Compiled from Sources GRASS Version: 2006-09-08 Although v.db.droptable works as expected and removes the reqested table, it always issues an 'ERROR' in the end, which is not good - the user *will* think something went wrong indeed. Example: $ v.db.droptable map=ditches layer=1 Removing following table name connected to selected layer: ditches Removing table linked to layer <1> of vector map Are you sure (y/n)? [n] y Dropping table ... Current attribute table link(s): ERROR: Database connection for map is not defined in DB file Maciek -------------------------------------------- Managed by Request Tracker From tutey at o2.pl Sun Sep 10 12:05:55 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Sun Sep 10 12:05:57 2006 Subject: [GRASS-dev] Re: [bug #2765] v.buffer bug?? In-Reply-To: <20060908220001.7086d05c.hamish_nospam@yahoo.com> References: <20060908220001.7086d05c.hamish_nospam@yahoo.com> Message-ID: <4503E383.7030205@o2.pl> Hamish wrote: > Can someone provide me with a simple vector file where the buffering bug > happens? or make it happen with a Speafish map? Hamish, In a message I just sent to you offlist you'll find an attached Grass location with 2 input vectors: square_rot ditches and 3 output vectors: square_rot_buf30 ditches_buf1 ditches_buf4 which expose the v.buffer's bug, using the following commands, respectively: v.buffer input=square_rot output=square_rot_buf30 type=line buffer=30 v.buffer input=ditches output=ditches_buf1 type=area buffer=1 v.buffer input=ditches output=ditches_buf4 type=area buffer=4 (Zoom to 'ditches_buf' wind file to notice the bug in the latter example.) Good luck, Maciek From tutey at o2.pl Sun Sep 10 13:06:40 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Sun Sep 10 13:06:48 2006 Subject: [GRASS-dev] v.proj transforming z co-ordinates In-Reply-To: References: <20060830153110.GT1046@bartok.itc.it> <44FAC060.1010306@o2.pl> Message-ID: <4503F1C0.2000605@o2.pl> Paul Kelly wrote: > That is very strange. Can you post the output from v.proj please to see > if there are any clues? Hi Paul! Attached are 2 sample Grass locations. zak_ll is latlong on WGS84 and contains an input 'test' 3D points vector (created with 'v.random -z output=test n=10 zmin=0.0 zmax=3000.0'). zak_utm34 is UTM34 on WGS84 and contains 2 v.proj outputs: 'test_reproj_Z_no' and 'test_reproj_Z_yes', created by the following commands, respectively: $ v.proj input=test location=zak_ll mapset=test output=test_reproj_Z_no $ v.proj -z input=test location=zak_ll mapset=test output=test_reproj_Z_yes (You'll find a full v.proj output in the attached text file.) For both output files I have uploaded their x,y,z coordinates into a table, and I find there is *no difference* in either coordinate, although the 1st vector was created using the v.proj with -z switch while the 2nd without this switch. Looks like '-z' doesn't work? Maciek -------------- next part -------------- GRASS 6.3.cvs (zak_utm34):~ > v.proj input=test location=zak_ll mapset=test output=test_reproj_Z_no Input Projection Parameters: +proj=longlat +a=6378137 +rf=298.257223563 +no_defs +towgs84=0.000,0.000,0.000 Input Unit Factor: 1 Output Projection Parameters: +proj=utm +zone=34 +a=6378137 +rf=298.257223563 +no_defs +towgs84=0.000,0.000,0.000 Output Unit Factor: 1 Creating vector file... Building topology ... 10 primitives registered Building areas: 100% 0 areas built 0 isles built Attaching islands: Attaching centroids: 100% Topology was built. Number of nodes : 10 Number of primitives: 10 Number of points : 10 Number of lines : 0 Number of boundaries: 0 Number of centroids : 0 Number of areas : 0 Number of isles : 0 GRASS 6.3.cvs (zak_utm34):~ > v.proj -z input=test location=zak_ll mapset=test output=test_reproj_Z_yes Input Projection Parameters: +proj=longlat +a=6378137 +rf=298.257223563 +no_defs +towgs84=0.000,0.000,0.000 Input Unit Factor: 1 Output Projection Parameters: +proj=utm +zone=34 +a=6378137 +rf=298.257223563 +no_defs +towgs84=0.000,0.000,0.000 Output Unit Factor: 1 Creating vector file... Building topology ... 10 primitives registered Building areas: 100% 0 areas built 0 isles built Attaching islands: Attaching centroids: 100% Topology was built. Number of nodes : 10 Number of primitives: 10 Number of points : 10 Number of lines : 0 Number of boundaries: 0 Number of centroids : 0 Number of areas : 0 Number of isles : 0 -------------- next part -------------- A non-text attachment was scrubbed... Name: zak_ll.tar.bz2 Type: application/x-bzip Size: 2164 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060910/4267ea74/zak_ll.tar.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: zak_utm34.tar.bz2 Type: application/x-bzip Size: 2945 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060910/4267ea74/zak_utm34.tar.bin From grass-bugs at intevation.de Sun Sep 10 23:43:05 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Sun Sep 10 23:43:07 2006 Subject: [GRASS-dev] [bug #5098] (grass) gis.m; tcltk error when zooming to map with name which exists in more than one mapset Message-ID: <20060910214305.2ADBD1005C5@lists.intevation.de> Moritz, This bug is fixed for me using current CVS. Closing it. If you still can reproduce the bug, please reply to this message will wil re-open your report. Thanks, Maciek -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Sun Sep 10 23:51:46 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Sun Sep 10 23:51:47 2006 Subject: [GRASS-dev] [bug #5111] (grass) Unable to rename map if similar exists in PERMANENT Message-ID: <20060910215146.1F2881005C5@lists.intevation.de> maris wrote (Thu, Sep 7 2006 21:19:31): > I'm unable to rename raster map if map with same name exists in other > mapset. Any manipulations with maps should happen in local mapset IF not > specified othervise. > Example: > GRASS 6.2.0cvs (archimed):~ > g.gisenv > GISDBASE=/home/maris/gis_dati > LOCATION_NAME=archimed > MAPSET=somijai > DEBUG=0 > MONITOR=x0 > GRASS_GUI=tcltk > GRASS 6.2.0cvs (archimed):~ > g.rename rast=MASKA,MASK > ERROR: already exists in mapset I confirm. The funny thing about this bug is that if you instead try: g.rename rast=MASKA,MASK@archimed it will work. Why is explicit mapset declaration required - I don't know. Maciek -------------------------------------------- Managed by Request Tracker From hamish_nospam at yahoo.com Mon Sep 11 04:13:56 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Sep 11 04:14:03 2006 Subject: [GRASS-dev] Re: [bug #2765] v.buffer bug?? In-Reply-To: <4503E383.7030205@o2.pl> References: <20060908220001.7086d05c.hamish_nospam@yahoo.com> <4503E383.7030205@o2.pl> Message-ID: <20060911141356.6bc30ab3.hamish_nospam@yahoo.com> me: > > Can someone provide me with a simple vector file where the buffering > > bug happens? or make it happen with a Speafish map? Maciek: > In a message I just sent to you offlist you'll find an attached Grass > location with 2 input vectors: > > square_rot Notice this is not a square of four corners! If you zoom in you find it contains 229 vertices, i.e. this is r.to.vect output with steps at the grid resolution. So not as easy to debug by hand, > ditches I couldn't recreate your buff=1 and 4 errors- buffering works fine for me there. I was however able to extract the attached problematic feature (area 1188), which is a fairly simple example. I reimported the ascii file as a new vector and got the same results, so hopefully others can reproduce with this too (?). I tested with buff=4 and buff=10. Using debug=buffer,clean didn't help, problem happens before that. Hamish -------------- next part -------------- A non-text attachment was scrubbed... Name: bad_buff.vasc Type: application/octet-stream Size: 1623 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060911/94bd49b2/bad_buff.obj From hamish_nospam at yahoo.com Mon Sep 11 07:47:17 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Sep 11 07:47:27 2006 Subject: [GRASS-dev] Re: [bug #2765] v.buffer bug?? In-Reply-To: <20060911141356.6bc30ab3.hamish_nospam@yahoo.com> References: <20060908220001.7086d05c.hamish_nospam@yahoo.com> <4503E383.7030205@o2.pl> <20060911141356.6bc30ab3.hamish_nospam@yahoo.com> Message-ID: <20060911174717.27b76a21.hamish_nospam@yahoo.com> Hamish wrote: > me: > > > Can someone provide me with a simple vector file where the > > > buffering bug happens? or make it happen with a Speafish map? .. > I couldn't recreate your buff=1 and 4 errors- buffering works fine for > me there. I was however able to extract the attached problematic > feature (area 1188), which is a fairly simple example. I reimported > the ascii file as a new vector and got the same results, so hopefully > others can reproduce with this too (?). I tested with buff=4 and > buff=10. > > Using debug=buffer,clean didn't help, problem happens before that. Converting to line and cleaning out excess vertices doesn't help either. Here is a simplified version of a problematic area: ("v.in.ascii -n format=standard") B 26 600039.02641686 5678405.3999173 600077.97320276 5678399.62882899 600086.74267773 5678396.53372018 600165.15210099 5678369.45151806 600169.2571522 5678367.86458082 600321.12416744 5678313.92598028 600329.91897615 5678321.23595115 600333.66876785 5678318.50222813 600324.59956919 5678312.02422909 600321.23100969 5678310.98774925 600167.57287245 5678364.49602132 600085.45304905 5678392.66483416 600077.19942555 5678396.27579444 600036.44715953 5678401.36982765 600030.38590477 5678402.27256772 600010.78354895 5678405.62560227 599996.21074494 5678408.39830396 599987.18334424 5678410.71963557 599979.96142368 5678412.00926424 599968.01258083 5678413.77867984 599954.94262744 5678414.84644733 599949.52618701 5678419.48911054 599968.61269136 5678418.4574076 599998.40311369 5678411.75133851 600001.62800241 5678411.19452149 600039.02641686 5678405.3999173 C 1 1 600232.43677669 5678342.9534263 1 1188 adding a few debug statements to lib/vector/Vlib/buffer.c shows: --> npoints = 26 --> side=0, added 41 points --> dangle=0.283079, PI=3.141593 added 11 arc points --> side=1, added 3 points --> dangle=0.283079, PI=3.141593 in Vect_line_parallel(): For side=1, there are 73 points created by parallel_line(), which if plotted describe the *correct* buffered boundaries that we want. ==> After clean_parallel() there are only 3 points left. <== So the problem is in clean_parallel(). If I comment out the clean_parallel() call, a correct looking output map is created, but this may lead to other problems later on...? for the last loop in side 1, sa=0. after the following sa+1 and two npn++ calls, the number of valid points from that pass ends up as 3. if ( point_in_buf( origPoints, px, py, d ) ){ /* is loop in buffer ? */ npn=sa+1; here is evolution of segments sa and sb. all debug messages are in clean_parallel(). error happens when (sb - sa) != 2, ie when the segment wraps back to the beginning of the polygon? nareas=1 Areas buffers ... 100% --> side 0 D0/0: clean_parallel(): npoints = 54, d = 10.000000, rm_end = 0 D0/0: current = 1, last = 2, lcount = 1 D0/0: //> no_overlap: sa=0 sb=2 first=0 np=54 D0/0: //> add sPoint->n = 1 D0/0: //> after loop sPoint->n = 3 D0/0: //> loop [centroid] is in buffer npn=1 sa=0 sb=2, lcount=1 D0/0: //> just before "move points down": npn=2 D0/0: current = 4, last = 5, lcount = 1 D0/0: //> no_overlap: sa=3 sb=5 first=3 np=54 D0/0: //> add sPoint->n = 1 D0/0: //> after loop sPoint->n = 3 D0/0: //> loop [centroid] is in buffer npn=53 sa=3 sb=5, lcount=1 D0/0: //> just before "move points down": npn=5 D0/0: current = 13, last = 14, lcount = 1 D0/0: //> no_overlap: sa=12 sb=14 first=12 np=54 D0/0: //> add sPoint->n = 1 D0/0: //> after loop sPoint->n = 3 D0/0: //> loop [centroid] is in buffer npn=52 sa=12 sb=14, lcount=1 D0/0: //> just before "move points down": npn=14 D0/0: current = 15, last = 16, lcount = 1 D0/0: //> no_overlap: sa=14 sb=16 first=14 np=54 D0/0: //> add sPoint->n = 1 D0/0: //> after loop sPoint->n = 3 D0/0: //> loop [centroid] is in buffer npn=51 sa=14 sb=16, lcount=1 D0/0: //> just before "move points down": npn=16 D0/0: current = 15, last = 17, lcount = 1 D0/0: //> no_overlap: sa=14 sb=17 first=14 np=54 D0/0: //> add sPoint->n = 1 D0/0: //> after loop sPoint->n = 4 D0/0: //> loop [centroid] is in buffer npn=50 sa=14 sb=17, lcount=1 D0/0: //> just before "move points down": npn=16 D0/0: current = 18, last = 19, lcount = 1 D0/0: //> no_overlap: sa=17 sb=19 first=17 np=54 D0/0: //> add sPoint->n = 1 D0/0: //> after loop sPoint->n = 3 D0/0: //> loop [centroid] is in buffer npn=48 sa=17 sb=19, lcount=1 D0/0: //> just before "move points down": npn=19 D0/0: current = 22, last = 23, lcount = 1 D0/0: //> no_overlap: sa=21 sb=23 first=21 np=54 D0/0: //> add sPoint->n = 1 D0/0: //> after loop sPoint->n = 3 D0/0: //> loop [centroid] is in buffer npn=47 sa=21 sb=23, lcount=1 D0/0: //> just before "move points down": npn=23 D0/0: current = 23, last = 24, lcount = 1 D0/0: //> no_overlap: sa=22 sb=24 first=22 np=54 D0/0: //> add sPoint->n = 1 D0/0: //> after loop sPoint->n = 3 D0/0: //> loop [centroid] is in buffer npn=46 sa=22 sb=24, lcount=1 D0/0: //> just before "move points down": npn=24 D0/0: current = 24, last = 25, lcount = 1 D0/0: //> no_overlap: sa=23 sb=25 first=23 np=54 D0/0: //> add sPoint->n = 1 D0/0: //> after loop sPoint->n = 3 D0/0: //> loop [centroid] is in buffer npn=45 sa=23 sb=25, lcount=1 D0/0: //> just before "move points down": npn=25 D0/0: current = 25, last = 26, lcount = 1 D0/0: //> no_overlap: sa=24 sb=26 first=24 np=54 D0/0: //> add sPoint->n = 1 D0/0: //> after loop sPoint->n = 3 D0/0: //> loop [centroid] is in buffer npn=44 sa=24 sb=26, lcount=1 D0/0: //> just before "move points down": npn=26 D0/0: current = 32, last = 33, lcount = 1 D0/0: //> no_overlap: sa=31 sb=33 first=31 np=54 D0/0: //> add sPoint->n = 1 D0/0: //> after loop sPoint->n = 3 D0/0: //> loop [centroid] is in buffer npn=43 sa=31 sb=33, lcount=1 D0/0: //> just before "move points down": npn=33 D0/0: current = 35, last = 36, lcount = 1 D0/0: //> no_overlap: sa=34 sb=36 first=34 np=54 D0/0: //> add sPoint->n = 1 D0/0: //> after loop sPoint->n = 3 D0/0: //> loop [centroid] is in buffer npn=42 sa=34 sb=36, lcount=1 D0/0: //> just before "move points down": npn=36 D0/0: //> after: npn=41 --> side 1 D0/0: clean_parallel(): npoints = 73, d = -10.000000, rm_end = 0 D0/0: current = 1, last = 71, lcount = 1 D0/0: current = 3, last = 4, lcount = 2 D0/0: //> no_overlap: sa=2 sb=4 first=0 np=73 D0/0: //> add sPoint->n = 1 D0/0: //> after loop sPoint->n = 3 D0/0: //> loop [centroid] is in buffer npn=1 sa=2 sb=4, lcount=2 D0/0: //> just before "move points down": npn=4 D0/0: current = 1, last = 70, lcount = 1 D0/0: current = 6, last = 7, lcount = 2 D0/0: //> no_overlap: sa=5 sb=7 first=0 np=73 D0/0: //> add sPoint->n = 1 D0/0: //> after loop sPoint->n = 3 D0/0: //> loop [centroid] is in buffer npn=72 sa=5 sb=7, lcount=2 D0/0: //> just before "move points down": npn=7 D0/0: current = 1, last = 69, lcount = 1 D0/0: current = 7, last = 8, lcount = 2 D0/0: //> no_overlap: sa=6 sb=8 first=0 np=73 D0/0: //> add sPoint->n = 1 D0/0: //> after loop sPoint->n = 3 D0/0: //> loop [centroid] is in buffer npn=71 sa=6 sb=8, lcount=2 D0/0: //> just before "move points down": npn=8 D0/0: current = 1, last = 68, lcount = 1 D0/0: current = 29, last = 30, lcount = 2 D0/0: //> no_overlap: sa=28 sb=30 first=0 np=73 D0/0: //> add sPoint->n = 1 D0/0: //> after loop sPoint->n = 3 D0/0: //> loop [centroid] is in buffer npn=70 sa=28 sb=30, lcount=2 D0/0: //> just before "move points down": npn=30 D0/0: current = 1, last = 67, lcount = 1 D0/0: current = 32, last = 33, lcount = 2 D0/0: //> no_overlap: sa=31 sb=33 first=0 np=73 D0/0: //> add sPoint->n = 1 D0/0: //> after loop sPoint->n = 3 D0/0: //> loop [centroid] is in buffer npn=69 sa=31 sb=33, lcount=2 D0/0: //> just before "move points down": npn=33 D0/0: current = 1, last = 66, lcount = 1 D0/0: current = 41, last = 42, lcount = 2 D0/0: //> no_overlap: sa=40 sb=42 first=0 np=73 D0/0: //> add sPoint->n = 1 D0/0: //> after loop sPoint->n = 3 D0/0: //> loop [centroid] is in buffer npn=68 sa=40 sb=42, lcount=2 D0/0: //> just before "move points down": npn=42 D0/0: current = 1, last = 65, lcount = 1 D0/0: current = 42, last = 43, lcount = 2 D0/0: //> no_overlap: sa=41 sb=43 first=0 np=73 D0/0: //> add sPoint->n = 1 D0/0: //> after loop sPoint->n = 3 D0/0: //> loop [centroid] is in buffer npn=67 sa=41 sb=43, lcount=2 D0/0: //> just before "move points down": npn=43 D0/0: current = 1, last = 64, lcount = 1 D0/0: current = 43, last = 44, lcount = 2 D0/0: //> no_overlap: sa=42 sb=44 first=0 np=73 D0/0: //> add sPoint->n = 1 D0/0: //> after loop sPoint->n = 3 D0/0: //> loop [centroid] is in buffer npn=66 sa=42 sb=44, lcount=2 D0/0: //> just before "move points down": npn=44 D0/0: current = 1, last = 63, lcount = 1 D0/0: current = 60, last = 61, lcount = 2 D0/0: //> no_overlap: sa=59 sb=61 first=0 np=73 D0/0: //> add sPoint->n = 1 D0/0: //> after loop sPoint->n = 3 D0/0: //> loop [centroid] is in buffer npn=65 sa=59 sb=61, lcount=2 D0/0: //> just before "move points down": npn=61 D0/0: current = 1, last = 62, lcount = 1 D0/0: current = 61, last = 62, lcount = 2 D0/0: //> no_overlap: sa=60 sb=62 first=0 np=73 D0/0: //> add sPoint->n = 1 D0/0: //> after loop sPoint->n = 3 D0/0: //> loop [centroid] is in buffer npn=64 sa=60 sb=62, lcount=2 D0/0: //> just before "move points down": npn=62 D0/0: current = 1, last = 61, lcount = 1 D0/0: //> no_overlap: sa=0 sb=61 first=0 np=73 D0/0: //> add sPoint->n = 1 D0/0: //> after loop sPoint->n = 62 D0/0: //> loop [centroid] is in buffer npn=63 sa=0 sb=61, lcount=1 D0/0: //> just before "move points down": npn=2 D0/0: //> after: npn=3 nisles=0 Hamish From hamish_nospam at yahoo.com Mon Sep 11 09:38:59 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Sep 11 09:39:05 2006 Subject: [GRASS-dev] [bug #5118] (grass) v.db.droptable: an 'ERROR' is always issued though the command completes OK In-Reply-To: <20060910094050.9620F1005AB@lists.intevation.de> References: <20060910094050.9620F1005AB@lists.intevation.de> Message-ID: <20060911193859.0d60336a.hamish_nospam@yahoo.com> > this bug's URL: http://intevation.de/rt/webrt?serial_num=5118 > --------------------------------------------------------------------- > > Subject: v.db.droptable: an 'ERROR' is always issued though the > command completes OK .. > Although v.db.droptable works as expected and removes the reqested > table, it always issues an 'ERROR' in the end, which is not good - the > user *will* think something went wrong indeed. > > Example: > > $ v.db.droptable map=ditches layer=1 Removing following table name > connected to selected layer: ditches Removing table linked > to layer <1> of vector map Are you sure (y/n)? [n] > y > Dropping table ... > Current attribute table link(s): > ERROR: Database connection for map is not defined in DB file I've added a line to the script in CVS to make the error message more instructive. I can't send the "ERROR:" message to /dev/null as "v.db.connect -p" sends its output to stderr. This should probably be changed to stdout. Hamish From grass-bugs at intevation.de Mon Sep 11 14:33:18 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Mon Sep 11 14:33:20 2006 Subject: [GRASS-dev] [bug #4956] (grass) gis.m: transparency setting not saved in .grc file Message-ID: <20060911123318.6A8091006B2@lists.intevation.de> Fixed by Moritz in CVS. Closing it. Maciek -------------------------------------------- Managed by Request Tracker From mlennert at club.worldonline.be Mon Sep 11 14:49:58 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Mon Sep 11 14:49:26 2006 Subject: [GRASS-dev] gis.m: query tool broken Message-ID: <45055B76.3060203@club.worldonline.be> Using current cvs head, the query tool seems to be broken. I can't find the relevant commit which shows how mapcanvas.tcl has been changed, but the following diff solves the problem for me. However, not being sufficiently familiar with the entire gis.m code, I prefer not submitting this to CVS before review by Michael. diff mapcanvas.tcl /usr/lib/grass/etc/gm/mapcanvas.tcl 1494c1494 < variable scr_ew --- > variable scr_lr 1501c1501 < set vdist($mon) [expr 10* {($map_ew($mon) / $scr_ew($mon))} ] --- > set vdist($mon) [expr 10* {($map_ew($mon) / $scr_lr($mon))} ] Moritz From neteler at itc.it Mon Sep 11 15:23:42 2006 From: neteler at itc.it (Markus Neteler) Date: Mon Sep 11 15:23:44 2006 Subject: [GRASS-dev] Re: NVIZ animation In-Reply-To: <1157975150.7269.6.camel@linuxmain.localhost> References: <1157975150.7269.6.camel@linuxmain.localhost> Message-ID: <20060911132342.GD4044@bartok.itc.it> Thanks, Bob, submitted! Markus On Mon, Sep 11, 2006 at 08:45:50AM -0300, Bob Covill wrote: > Hi Markus, > > I was just testing the NVIZ animation stuff when I picked up a new > error. If you try to save an animation you receive an error about an > undefined button. In the packing line of the save animation box, the RGB > button is still included even though it does not exist. The error can be > fixed by removing ".ras_fname.img1" from the packing line of > panel_kanimator.tcl and panel_animation.tcl. > > If you could apply this fix that would be great. > > Thanks. > > -- > Bob From michael.barton at asu.edu Mon Sep 11 16:50:21 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 11 16:50:28 2006 Subject: [GRASS-dev] Re: gis.m: query tool broken In-Reply-To: <45055B76.3060203@club.worldonline.be> Message-ID: I'll look at it today. Thanks. 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: Moritz Lennert > Date: Mon, 11 Sep 2006 14:49:58 +0200 > To: Michael Barton , Grass Developers List > > Subject: gis.m: query tool broken > > Using current cvs head, the query tool seems to be broken. I can't find > the relevant commit which shows how mapcanvas.tcl has been changed, but > the following diff solves the problem for me. However, not being > sufficiently familiar with the entire gis.m code, I prefer not > submitting this to CVS before review by Michael. > > diff mapcanvas.tcl /usr/lib/grass/etc/gm/mapcanvas.tcl > 1494c1494 > < variable scr_ew > --- >> variable scr_lr > 1501c1501 > < set vdist($mon) [expr 10* {($map_ew($mon) / $scr_ew($mon))} ] > --- >> set vdist($mon) [expr 10* {($map_ew($mon) / $scr_lr($mon))} ] > > > Moritz From michael.barton at asu.edu Mon Sep 11 18:53:17 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 11 18:53:26 2006 Subject: [GRASS-dev] problems with thematic mapper (was "added opacity option to grc file") In-Reply-To: <45057D64.8010004@club.worldonline.be> Message-ID: I don't know what's going on, but I just tried to create a thematic map and got the following error: csh: if: Expression Syntax. d.vect.thematic: awk required, please install awk or gawk first I DO have awk installed (I double checked). I made no changes to the d.vect.thematic script that should cause this error. Does anyone have an idea what's going on? Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Moritz Lennert > Date: Mon, 11 Sep 2006 17:14:44 +0200 > To: Michael Barton > Subject: Re: added opacity option to grc file > > Michael Barton wrote: >> Moritz, >> >> This will be nice if it doesn't break anything. >> >> The optlist is used for a variety of things and was designed for options for >> a d.* command. Opacity is not one of those options. It is a value used for >> compositing when g.pnmcomp is run. >> >> I should look to see where optlist is being used again besides in creating a >> list of options for *.grc output. But I'm assuming that it would be obvious >> if this caused a problem. > > Let's hope. Sorry, I should have consulted you before committing. > > I have another problem which is also new: it seems as if the thematic > layer only displays the highest (last) class. Below you see the messages > in the output window. Nothing seems to be going wrong, but in the > display I only see those areas which are in the range 4152.66 - 20174. > > Moritz > > ******output************** > > Thematic map legend for column densite of map communes > > Value range: 0 - 20174 > Mapped by standard deviation units of 1747.52 (mean = 657.62) > > Color(R:G:B) Value > ============ ========== > 0:0:255 0 - 657.62 > PNG: GRASS_TRUECOLOR status: TRUE > PNG: collecting to file: > /home/mlennert/GRASS/DATA/BELGIQUE/mlennert/.tmp/geog-pc40/32172.0.ppm, > GRASS_WIDTH=642, GRASS_HEIGHT=482 > > 'vector/communes' was found in more mapsets (also found in mlennert). > 85:0:170 657.62 - 2405.14 +1sd > PNG: GRASS_TRUECOLOR status: TRUE > PNG: collecting to file: > /home/mlennert/GRASS/DATA/BELGIQUE/mlennert/.tmp/geog-pc40/32172.0.ppm, > GRASS_WIDTH=642, GRASS_HEIGHT=482 > > 'vector/communes' was found in more mapsets (also found in mlennert). > 170:0:85 2405.14 - 4152.66 +2sd > PNG: GRASS_TRUECOLOR status: TRUE > PNG: collecting to file: > /home/mlennert/GRASS/DATA/BELGIQUE/mlennert/.tmp/geog-pc40/32172.0.ppm, > GRASS_WIDTH=642, GRASS_HEIGHT=482 > > 'vector/communes' was found in more mapsets (also found in mlennert). > 255:0:0 4152.66 - 20174 > PNG: GRASS_TRUECOLOR status: TRUE > PNG: collecting to file: > /home/mlennert/GRASS/DATA/BELGIQUE/mlennert/.tmp/geog-pc40/32172.0.ppm, > GRASS_WIDTH=642, GRASS_HEIGHT=482 > > 'vector/communes' was found in more mapsets (also found in mlennert). > > >> >> 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: Moritz Lennert >>> Date: Mon, 11 Sep 2006 12:13:09 +0200 >>> To: Michael Barton >>> Subject: added opacity option to grc file >>> >>> Hello Michael, >>> >>> Just to inform you: I just added support for the opacity option in the >>> .grc file to cvs: >>> >>> http://grass.itc.it/pipermail/grass-commit/2006-September/024186.html >>> >>> Moritz >> > From grass-bugs at intevation.de Mon Sep 11 21:44:00 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Mon Sep 11 21:44:04 2006 Subject: [GRASS-dev] [bug #2765] (grass) v.buffer produces strange results Message-ID: <20060911194400.1FD111005B4@lists.intevation.de> hamish_nospam@yahoo.com wrote (Mon, Sep 11 2006 04:14:07): > Maciek: >> square_rot > Notice this is not a square of four corners! Why the "!", actually? > If you zoom in you find it contains 229 vertices, i.e. this is r.to.vect > output with steps at the grid resolution. So not as easy to debug by hand OK. But this doesn't mean buffering it should be buggy, right? >> ditches > I couldn't recreate your buff=1 and 4 errors- buffering works fine for > me there. I'm wondering why, because I can perfecetly reproduce the bug at any time with exactly the data I sent you. Are you absolutely sure that the output of following v.buffer commands: v.buffer input=ditches output=ditches_buf1 type=area buffer=1 v.buffer input=ditches output=ditches_buf4 type=area buffer=4 looks all OK after you zoom to region 'ditches_buf' included in my sample dataset? For me it's obvious that the output is plain wrong. Maciek -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Mon Sep 11 21:59:09 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Mon Sep 11 21:59:10 2006 Subject: [GRASS-dev] [bug #5127] (grass) v.digit: error after pressing 'Submit' button when the table has only a 'cat' column Message-ID: <20060911195909.335A31005C5@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5127 ------------------------------------------------------------------------- Subject: v.digit: error after pressing 'Submit' button when the table has only a 'cat' column Platform: GNU/Linux/x86 grass obtained from: CVS grass binary for platform: Compiled from Sources GRASS Version: 2006-09-11 $ v.digit -n testing Settings -> Table -> Create table (don't add any other columns!) Digitize something - form window pops up. Press 'Submit'. The error: Cannot update table: DBMI-DBF driver error: SQL parser error in statement: update testing set where cat = 1 Error in db_execute_immediate() How could the situation be better handled to avoid this missleading bogus error? Maybe deactivate 'Submit' button, when only a 'cat' column is present in the table? Maciek -------------------------------------------- Managed by Request Tracker From michael.barton at asu.edu Mon Sep 11 22:41:23 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 11 22:41:29 2006 Subject: [GRASS-dev] d.vect.thematic problem Message-ID: Earlier today, I reported that d.vect.thematic is not running on my Mac, returning the error csh: if: Expression Syntax. d.vect.thematic: awk required, please install awk or gawk first The code in d.vect.thematic that is causing this is the following... #### check if we have awk if [ ! -x "`which awk`" ] ; then echo "$PROG: awk required, please install awk or gawk first" 2>&1 exit 1 fi If I run... >>which awk ...from the a plain vanilla bash Terminal.app window, it returns ... /usr/bin/awk But if I run it from the GRASS Terminal.app window, it returns... csh: if: Expression Syntax. This is with William Kyngesburye?s binaries of 2 Sept. 2006. Any idea what?s wrong? Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060911/fec18674/attachment.html From michael.barton at asu.edu Mon Sep 11 23:05:39 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 11 23:06:05 2006 Subject: [GRASS-dev] Re: added opacity option to grc file In-Reply-To: <45057D64.8010004@club.worldonline.be> Message-ID: Moritz, Now that I finally got thematic mapping working on my Mac again, I was able to look into this. I think switching to immediate mode rendering has broken thematic mapping from the GUI. Looking at it, I'm not sure why it was working before. I'm pretty sure that what is happening is that the thematic mapping script is iteratively running d.vect (actually this IS what is happening). Somehow, this was getting written to a single output PPM that was then composited and displayed with any other map in the layer tree. Perhaps this was happening because of the lag in writing the output PPM allowed all the iterated d.vect writes in the display driver to put it all together before it was output to a file. With immediate mode rendering, the PPM output is considerably faster. So d.vect.thematic is repeatedly writing it's vector displays (one for each theme) to a file directly, rather than to the display driver and then to a file. The unfortunate result is that it is writing each theme to the SAME file, overwriting any previous theme. So you only see the last theme written. At the moment, I can't think of a clever way to fix this so that the script works as a stand alone module and can write in the old way to the display driver, and at the same time work in the GUI environment. I'm loathe to rewrite the whole thing in TclTk and then have to maintain 2 versions. Any suggestions are welcome. Glynn??? Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Moritz Lennert > Date: Mon, 11 Sep 2006 17:14:44 +0200 > To: Michael Barton > Subject: Re: added opacity option to grc file > > I have another problem which is also new: it seems as if the thematic > layer only displays the highest (last) class. Below you see the messages > in the output window. Nothing seems to be going wrong, but in the > display I only see those areas which are in the range 4152.66 - 20174. > > Moritz > > ******output************** > > Thematic map legend for column densite of map communes > > Value range: 0 - 20174 > Mapped by standard deviation units of 1747.52 (mean = 657.62) > > Color(R:G:B) Value > ============ ========== > 0:0:255 0 - 657.62 > PNG: GRASS_TRUECOLOR status: TRUE > PNG: collecting to file: > /home/mlennert/GRASS/DATA/BELGIQUE/mlennert/.tmp/geog-pc40/32172.0.ppm, > GRASS_WIDTH=642, GRASS_HEIGHT=482 > > 'vector/communes' was found in more mapsets (also found in mlennert). > 85:0:170 657.62 - 2405.14 +1sd > PNG: GRASS_TRUECOLOR status: TRUE > PNG: collecting to file: > /home/mlennert/GRASS/DATA/BELGIQUE/mlennert/.tmp/geog-pc40/32172.0.ppm, > GRASS_WIDTH=642, GRASS_HEIGHT=482 > > 'vector/communes' was found in more mapsets (also found in mlennert). > 170:0:85 2405.14 - 4152.66 +2sd > PNG: GRASS_TRUECOLOR status: TRUE > PNG: collecting to file: > /home/mlennert/GRASS/DATA/BELGIQUE/mlennert/.tmp/geog-pc40/32172.0.ppm, > GRASS_WIDTH=642, GRASS_HEIGHT=482 > > 'vector/communes' was found in more mapsets (also found in mlennert). > 255:0:0 4152.66 - 20174 > PNG: GRASS_TRUECOLOR status: TRUE > PNG: collecting to file: > /home/mlennert/GRASS/DATA/BELGIQUE/mlennert/.tmp/geog-pc40/32172.0.ppm, > GRASS_WIDTH=642, GRASS_HEIGHT=482 > > 'vector/communes' was found in more mapsets (also found in mlennert). > From woklist at kyngchaos.com Mon Sep 11 23:15:55 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Sep 11 23:16:01 2006 Subject: [GRASS-dev] d.vect.thematic problem In-Reply-To: References: Message-ID: <610F3558-FCB3-4A2D-9305-58126E3D40A3@kyngchaos.com> d.vect.thematic works for me. If I change that awk check to something that doesn't exist, I get the expected 'awk required' error. No syntax error. And, awk itself from the GRASS Terminal works for me. What's your PATH in GRASS at the time you want to run d.vect.thematic? Even without the user adding anything to the PATH in their bash startup, / usr/bin should be in their PATH. On Sep 11, 2006, at 3:41 PM, Michael Barton wrote: > Earlier today, I reported that d.vect.thematic is not running on my > Mac, returning the error > > csh: if: Expression Syntax. > d.vect.thematic: awk required, please install awk or gawk first > > > The code in d.vect.thematic that is causing this is the following... > > #### check if we have awk > if [ ! -x "`which awk`" ] ; then > echo "$PROG: awk required, please install awk or gawk first" 2>&1 > exit 1 > fi > > If I run... > > >>which awk > > ...from the a plain vanilla bash Terminal.app window, it returns ... > > /usr/bin/awk > > But if I run it from the GRASS Terminal.app window, it returns... > > csh: if: Expression Syntax. > > This is with William Kyngesburye?s binaries of 2 Sept. 2006. Any > idea what?s wrong? > ----- William Kyngesburye http://www.kyngchaos.com/ All generalizations are dangerous, even this one. From michael.barton at asu.edu Mon Sep 11 23:22:09 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 11 23:22:14 2006 Subject: [GRASS-dev] d.vect.thematic problem In-Reply-To: <610F3558-FCB3-4A2D-9305-58126E3D40A3@kyngchaos.com> Message-ID: It IS a path problem. It is getting set incorrectly, without /usr/bin:/usr/local/bin...etc. GRASS 6.3.cvs (spearfish60_test):~ > $PATH bash: /Applications/Grass/GRASS.app/Contents/Resources/bin:/Applications/Grass/GRA SS.app/Contents/Resources/scripts::/Users/cmbarton/Library/Application: No such file or directory I set it manually and all works. Any thoughts? Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: William Kyngesburye > Reply-To: William Kyngesburye > Date: Mon, 11 Sep 2006 16:15:55 -0500 > To: Michael Barton > Cc: > Subject: Re: [GRASS-dev] d.vect.thematic problem > > d.vect.thematic works for me. If I change that awk check to > something that doesn't exist, I get the expected 'awk required' > error. No syntax error. > > And, awk itself from the GRASS Terminal works for me. What's your > PATH in GRASS at the time you want to run d.vect.thematic? Even > without the user adding anything to the PATH in their bash startup, / > usr/bin should be in their PATH. > > > On Sep 11, 2006, at 3:41 PM, Michael Barton wrote: > >> Earlier today, I reported that d.vect.thematic is not running on my >> Mac, returning the error >> >> csh: if: Expression Syntax. >> d.vect.thematic: awk required, please install awk or gawk first >> >> >> The code in d.vect.thematic that is causing this is the following... >> >> #### check if we have awk >> if [ ! -x "`which awk`" ] ; then >> echo "$PROG: awk required, please install awk or gawk first" 2>&1 >> exit 1 >> fi >> >> If I run... >> >>>> which awk >> >> ...from the a plain vanilla bash Terminal.app window, it returns ... >> >> /usr/bin/awk >> >> But if I run it from the GRASS Terminal.app window, it returns... >> >> csh: if: Expression Syntax. >> >> This is with William Kyngesburye?s binaries of 2 Sept. 2006. Any >> idea what?s wrong? >> > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > All generalizations are dangerous, even this one. > > From michael.barton at asu.edu Mon Sep 11 23:39:27 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 11 23:39:33 2006 Subject: [GRASS-dev] Re: added opacity option to grc file In-Reply-To: Message-ID: OK. I DID find a clever way to fix this. At least I hope it is clever and fixes it (seems to with my system). I use the -s flag (now more clearly labeled as using d.vect.thematic with GIS Manager) to cause d.vect.thematic to do the following turn on PNG driver turn off autowrite turn off immediate mode rendering run d.vect interatively put things back the way they were. Please check this. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Michael Barton > Date: Mon, 11 Sep 2006 14:05:39 -0700 > To: Moritz Lennert > Cc: grass-dev > Conversation: added opacity option to grc file > Subject: Re: added opacity option to grc file > > Moritz, > > Now that I finally got thematic mapping working on my Mac again, I was able to > look into this. > > I think switching to immediate mode rendering has broken thematic mapping from > the GUI. Looking at it, I'm not sure why it was working before. > > I'm pretty sure that what is happening is that the thematic mapping script is > iteratively running d.vect (actually this IS what is happening). Somehow, this > was getting written to a single output PPM that was then composited and > displayed with any other map in the layer tree. Perhaps this was happening > because of the lag in writing the output PPM allowed all the iterated d.vect > writes in the display driver to put it all together before it was output to a > file. > > With immediate mode rendering, the PPM output is considerably faster. So > d.vect.thematic is repeatedly writing it's vector displays (one for each > theme) to a file directly, rather than to the display driver and then to a > file. The unfortunate result is that it is writing each theme to the SAME > file, overwriting any previous theme. So you only see the last theme written. > > At the moment, I can't think of a clever way to fix this so that the script > works as a stand alone module and can write in the old way to the display > driver, and at the same time work in the GUI environment. I'm loathe to > rewrite the whole thing in TclTk and then have to maintain 2 versions. > > Any suggestions are welcome. Glynn??? > > Michael > > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics and Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > >> From: Moritz Lennert >> Date: Mon, 11 Sep 2006 17:14:44 +0200 >> To: Michael Barton >> Subject: Re: added opacity option to grc file >> >> I have another problem which is also new: it seems as if the thematic >> layer only displays the highest (last) class. Below you see the messages >> in the output window. Nothing seems to be going wrong, but in the >> display I only see those areas which are in the range 4152.66 - 20174. >> >> Moritz >> >> ******output************** >> >> Thematic map legend for column densite of map communes >> >> Value range: 0 - 20174 >> Mapped by standard deviation units of 1747.52 (mean = 657.62) >> >> Color(R:G:B) Value >> ============ ========== >> 0:0:255 0 - 657.62 >> PNG: GRASS_TRUECOLOR status: TRUE >> PNG: collecting to file: >> /home/mlennert/GRASS/DATA/BELGIQUE/mlennert/.tmp/geog-pc40/32172.0.ppm, >> GRASS_WIDTH=642, GRASS_HEIGHT=482 >> >> 'vector/communes' was found in more mapsets (also found in mlennert). >> 85:0:170 657.62 - 2405.14 +1sd >> PNG: GRASS_TRUECOLOR status: TRUE >> PNG: collecting to file: >> /home/mlennert/GRASS/DATA/BELGIQUE/mlennert/.tmp/geog-pc40/32172.0.ppm, >> GRASS_WIDTH=642, GRASS_HEIGHT=482 >> >> 'vector/communes' was found in more mapsets (also found in mlennert). >> 170:0:85 2405.14 - 4152.66 +2sd >> PNG: GRASS_TRUECOLOR status: TRUE >> PNG: collecting to file: >> /home/mlennert/GRASS/DATA/BELGIQUE/mlennert/.tmp/geog-pc40/32172.0.ppm, >> GRASS_WIDTH=642, GRASS_HEIGHT=482 >> >> 'vector/communes' was found in more mapsets (also found in mlennert). >> 255:0:0 4152.66 - 20174 >> PNG: GRASS_TRUECOLOR status: TRUE >> PNG: collecting to file: >> /home/mlennert/GRASS/DATA/BELGIQUE/mlennert/.tmp/geog-pc40/32172.0.ppm, >> GRASS_WIDTH=642, GRASS_HEIGHT=482 >> >> 'vector/communes' was found in more mapsets (also found in mlennert). >> From woklist at kyngchaos.com Mon Sep 11 23:45:50 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Sep 11 23:45:58 2006 Subject: [GRASS-dev] d.vect.thematic problem In-Reply-To: References: Message-ID: Hmm, that's not a good way to look at the PATH - it's trying to execute it as a command. And the rest is getting cut off at the Application Support part - there's a space in there breaking it up. Try echo $PATH, or env to get everything in the environment. On Sep 11, 2006, at 4:22 PM, Michael Barton wrote: > It IS a path problem. It is getting set incorrectly, without > /usr/bin:/usr/local/bin...etc. > > GRASS 6.3.cvs (spearfish60_test):~ > $PATH > bash: > /Applications/Grass/GRASS.app/Contents/Resources/bin:/Applications/ > Grass/GRA > SS.app/Contents/Resources/scripts::/Users/cmbarton/Library/ > Application: No > such file or directory > > I set it manually and all works. Any thoughts? > ----- William Kyngesburye http://www.kyngchaos.com/ "We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty." "Don't you even hate 'em?" "What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the ____ it wouldn't kill one ___ nor shorten the war one day." "And it might give 'em all stomach ulcers." - Tarzan, on war From glynn at gclements.plus.com Tue Sep 12 01:35:44 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Sep 12 01:36:53 2006 Subject: [GRASS-dev] Re: added opacity option to grc file In-Reply-To: References: <45057D64.8010004@club.worldonline.be> Message-ID: <17669.62160.566078.497931@cerise.gclements.plus.com> Michael Barton wrote: > Now that I finally got thematic mapping working on my Mac again, I was able > to look into this. > > I think switching to immediate mode rendering has broken thematic mapping > from the GUI. Looking at it, I'm not sure why it was working before. > > I'm pretty sure that what is happening is that the thematic mapping script > is iteratively running d.vect (actually this IS what is happening). Somehow, > this was getting written to a single output PPM that was then composited and > displayed with any other map in the layer tree. Perhaps this was happening > because of the lag in writing the output PPM allowed all the iterated d.vect > writes in the display driver to put it all together before it was output to > a file. > > With immediate mode rendering, the PPM output is considerably faster. So > d.vect.thematic is repeatedly writing it's vector displays (one for each > theme) to a file directly, rather than to the display driver and then to a > file. The unfortunate result is that it is writing each theme to the SAME > file, overwriting any previous theme. So you only see the last theme > written. > > At the moment, I can't think of a clever way to fix this so that the script > works as a stand alone module and can write in the old way to the display > driver, and at the same time work in the GUI environment. I'm loathe to > rewrite the whole thing in TclTk and then have to maintain 2 versions. > > Any suggestions are welcome. Glynn??? It has nothing to do with speed. If you use a monitor, each rendering operation is performed on top of what is already on the "screen" (i.e. the image, for the PNG driver). The screen is only cleared if you use d.erase or similar. With direct rendering, each d.* command is self-contained, and starts with a blank image (filled with $GRASS_BACKGROUNDCOLOR, or transparent if $GRASS_TRANSPARENT == TRUE). The behaviour is equivalent to starting the monitor before running each command and stopping it afterwards. If you want a single image which contains the output from multiple d.* commands, either use a monitor, or rename the image file after each operation then composite them with g.pnmcomp. -- Glynn Clements From hamish_nospam at yahoo.com Tue Sep 12 05:29:18 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Sep 12 05:29:26 2006 Subject: [GRASS-dev] Re: [bug #2765] (grass) v.buffer produces strange results In-Reply-To: <20060911194400.1FD111005B4@lists.intevation.de> References: <20060911194400.1FD111005B4@lists.intevation.de> Message-ID: <20060912152918.77a48f94.hamish_nospam@yahoo.com> > this bug's URL: http://intevation.de/rt/webrt?serial_num=2765 > > Maciek: > >> square_rot > > > Notice this is not a square of four corners! > > Why the "!", actually? > > > If you zoom in you find it contains 229 vertices, i.e. this is > > r.to.vect output with steps at the grid resolution. So not as easy > > to debug by hand > > OK. But this doesn't mean buffering it should be buggy, right? This is significant as the bug appears on a complex polygon, not a simple 4 vertex square as it appeared on first look. > >> ditches > > > I couldn't recreate your buff=1 and 4 errors- buffering works fine > > for me there. > > I'm wondering why, because I can perfecetly reproduce the bug at any > time with exactly the data I sent you. > > Are you absolutely sure that the output of following v.buffer > commands: > > v.buffer input=ditches output=ditches_buf1 type=area buffer=1 > v.buffer input=ditches output=ditches_buf4 type=area buffer=4 > > looks all OK after you zoom to region 'ditches_buf' included in my > sample dataset? > > For me it's obvious that the output is plain wrong. attached is a screenshot of the original vector in "aqua" on top of the 1 and 4 meter buffers I've just created. looking at "v.info -h" I see that I did load it into v.digit to have a look at the topology. I've tried again with a fresh copy of the mapset, same (good) results. I don't know why it would be different- but for me that works. But it doesn't matter -- I was looking for a simple example of it going wrong and I think I've found one: Can you try buffering this simple polygon and see if it works correctly for you? (I used a 10m buffer) If we can fix the bug causing that, maybe your area filling bug will go away too. ("v.in.ascii -n format=standard") B 26 600039.02641686 5678405.3999173 600077.97320276 5678399.62882899 600086.74267773 5678396.53372018 600165.15210099 5678369.45151806 600169.2571522 5678367.86458082 600321.12416744 5678313.92598028 600329.91897615 5678321.23595115 600333.66876785 5678318.50222813 600324.59956919 5678312.02422909 600321.23100969 5678310.98774925 600167.57287245 5678364.49602132 600085.45304905 5678392.66483416 600077.19942555 5678396.27579444 600036.44715953 5678401.36982765 600030.38590477 5678402.27256772 600010.78354895 5678405.62560227 599996.21074494 5678408.39830396 599987.18334424 5678410.71963557 599979.96142368 5678412.00926424 599968.01258083 5678413.77867984 599954.94262744 5678414.84644733 599949.52618701 5678419.48911054 599968.61269136 5678418.4574076 599998.40311369 5678411.75133851 600001.62800241 5678411.19452149 600039.02641686 5678405.3999173 C 1 1 600232.43677669 5678342.9534263 1 1188 Hamish -------------- next part -------------- A non-text attachment was scrubbed... Name: ditches014.png Type: image/png Size: 7477 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060912/f56a26cd/ditches014-0001.png From mlennert at club.worldonline.be Tue Sep 12 10:02:05 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Sep 12 10:01:32 2006 Subject: [GRASS-dev] fix to d.vect.thematic rendering [was: Re: added opacity option to grc file] In-Reply-To: References: Message-ID: <4506697D.2050009@club.worldonline.be> Michael Barton wrote: > OK. I DID find a clever way to fix this. At least I hope it is clever and > fixes it (seems to with my system). > > I use the -s flag (now more clearly labeled as using d.vect.thematic with > GIS Manager) to cause d.vect.thematic to do the following > > turn on PNG driver > turn off autowrite > turn off immediate mode rendering > run d.vect interatively > put things back the way they were. > > Please check this. Yep, d.vect.thematic is back where it should be. (Funny, I could have sworn that I had succesfully used it after the switch to direct rendering, but apparently I hadn't.) Thanks, Moritz > > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics and Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > >> From: Michael Barton >> Date: Mon, 11 Sep 2006 14:05:39 -0700 >> To: Moritz Lennert >> Cc: grass-dev >> Conversation: added opacity option to grc file >> Subject: Re: added opacity option to grc file >> >> Moritz, >> >> Now that I finally got thematic mapping working on my Mac again, I was able to >> look into this. >> >> I think switching to immediate mode rendering has broken thematic mapping from >> the GUI. Looking at it, I'm not sure why it was working before. >> >> I'm pretty sure that what is happening is that the thematic mapping script is >> iteratively running d.vect (actually this IS what is happening). Somehow, this >> was getting written to a single output PPM that was then composited and >> displayed with any other map in the layer tree. Perhaps this was happening >> because of the lag in writing the output PPM allowed all the iterated d.vect >> writes in the display driver to put it all together before it was output to a >> file. >> >> With immediate mode rendering, the PPM output is considerably faster. So >> d.vect.thematic is repeatedly writing it's vector displays (one for each >> theme) to a file directly, rather than to the display driver and then to a >> file. The unfortunate result is that it is writing each theme to the SAME >> file, overwriting any previous theme. So you only see the last theme written. >> >> At the moment, I can't think of a clever way to fix this so that the script >> works as a stand alone module and can write in the old way to the display >> driver, and at the same time work in the GUI environment. I'm loathe to >> rewrite the whole thing in TclTk and then have to maintain 2 versions. >> >> Any suggestions are welcome. Glynn??? >> >> Michael >> >> __________________________________________ >> Michael Barton, Professor of Anthropology >> School of Human Evolution & Social Change >> Center for Social Dynamics and Complexity >> Arizona State University >> >> phone: 480-965-6213 >> fax: 480-965-7671 >> www: http://www.public.asu.edu/~cmbarton >> >> >>> From: Moritz Lennert >>> Date: Mon, 11 Sep 2006 17:14:44 +0200 >>> To: Michael Barton >>> Subject: Re: added opacity option to grc file >>> >>> I have another problem which is also new: it seems as if the thematic >>> layer only displays the highest (last) class. Below you see the messages >>> in the output window. Nothing seems to be going wrong, but in the >>> display I only see those areas which are in the range 4152.66 - 20174. >>> >>> Moritz >>> >>> ******output************** >>> >>> Thematic map legend for column densite of map communes >>> >>> Value range: 0 - 20174 >>> Mapped by standard deviation units of 1747.52 (mean = 657.62) >>> >>> Color(R:G:B) Value >>> ============ ========== >>> 0:0:255 0 - 657.62 >>> PNG: GRASS_TRUECOLOR status: TRUE >>> PNG: collecting to file: >>> /home/mlennert/GRASS/DATA/BELGIQUE/mlennert/.tmp/geog-pc40/32172.0.ppm, >>> GRASS_WIDTH=642, GRASS_HEIGHT=482 >>> >>> 'vector/communes' was found in more mapsets (also found in mlennert). >>> 85:0:170 657.62 - 2405.14 +1sd >>> PNG: GRASS_TRUECOLOR status: TRUE >>> PNG: collecting to file: >>> /home/mlennert/GRASS/DATA/BELGIQUE/mlennert/.tmp/geog-pc40/32172.0.ppm, >>> GRASS_WIDTH=642, GRASS_HEIGHT=482 >>> >>> 'vector/communes' was found in more mapsets (also found in mlennert). >>> 170:0:85 2405.14 - 4152.66 +2sd >>> PNG: GRASS_TRUECOLOR status: TRUE >>> PNG: collecting to file: >>> /home/mlennert/GRASS/DATA/BELGIQUE/mlennert/.tmp/geog-pc40/32172.0.ppm, >>> GRASS_WIDTH=642, GRASS_HEIGHT=482 >>> >>> 'vector/communes' was found in more mapsets (also found in mlennert). >>> 255:0:0 4152.66 - 20174 >>> PNG: GRASS_TRUECOLOR status: TRUE >>> PNG: collecting to file: >>> /home/mlennert/GRASS/DATA/BELGIQUE/mlennert/.tmp/geog-pc40/32172.0.ppm, >>> GRASS_WIDTH=642, GRASS_HEIGHT=482 >>> >>> 'vector/communes' was found in more mapsets (also found in mlennert). >>> > From mlennert at club.worldonline.be Tue Sep 12 10:20:19 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Sep 12 10:19:46 2006 Subject: [GRASS-dev] trying to amend d.vect.chart - need for advice In-Reply-To: <44FEBC53.8060903@club.worldonline.be> References: <44FEBC53.8060903@club.worldonline.be> Message-ID: <45066DC3.60905@club.worldonline.be> After an offline discussion with Hamish, I come back to the list, with a revised proposal and still some need for advice. As a reminder, here's the issue: Moritz Lennert wrote: > Hello, > > With a colleague we are trying to amend d.vect.chart in order to > > 1) speed it up > 2) allow a where clause > > Currently, d.vect.chart loops through each vector feature and opens a > new db cursor to fetch the column information. On a map with a fair > amount of features (20464 centroids) with the table in Postgresql it > seems that the db connection is what takes the most of the time (even > worse obviously when the map is linked to a view which needs to be > recalculated for every feature). > > So currently, the program's logic is as follows (in > display/d.vect.chart/plot.c): > > - get number of features (little aside question: why is this done with > Vect_get_num_lines() which should return number of lines, not number of > features - as you can see I'm very new to the vector library) > - loop through each feature: > - get cat of feature > - open cursor selecting columns [and sizecol] for this feature > according to cat > - close cursor > - plot with this info > > We would like to modify this according to the following logic: > > - add a 'where' option > - open a cursor selecting cat, columns [and sizecol] limited by the > where option > - loop through the cursor: > - find x,y values according to cat > - plot with this info > - close cursor > Now, after discussion, there seem to be the following issues with our solution: - If a map is linked to a table containing a lot of lines not linked to an object in the map we have to loop through all these lines, with the search for x,y failing. This might slow things down again. One path towards a solution to this problem would be to get the list of cats from the map and include them in the where clause of the cursor select statement, but if there are a lot of objects this would be a _very_ long where clause which is probably not feasible. - A given cat value may correspond to several objects, and thus to several x,y values. For chart objects, it should probably be considered a bug that the same chart is drawn several times on the map. If you want to see a country's total population, you don't want to see the same circle repeated on every island belonging to this country. But since we cannot automatically tell which object is the "mainland", this has to be left to the user. But at least we should include a warning before painting several times the same chart, so that the user is made aware of the issue and can clean up the map of needed. - The above only works if we have a function that allows us to find the x,y value on the basis of a given cat value. I still haven't been able to find such a function. Does it exist ? Thanks to anyone who can point me in the right direction. Moritz From mlennert at club.worldonline.be Tue Sep 12 10:33:41 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Sep 12 10:33:07 2006 Subject: [GRASS-dev] v.what and spatial index In-Reply-To: <17664.57943.168262.726011@cerise.gclements.plus.com> References: <44DAE895.4060809@club.worldonline.be> <44FEEFA0.2050703@club.worldonline.be> <17663.4929.559488.267433@cerise.gclements.plus.com> <20060907165008.4b8fc991.hamish_nospam@yahoo.com> <45003E31.1070800@club.worldonline.be> <17664.57943.168262.726011@cerise.gclements.plus.com> Message-ID: <450670E5.7020105@club.worldonline.be> Glynn Clements wrote: > Moritz Lennert wrote: > >> However, v.what does not have an interactive mode (that's the whole idea >> of v.what so it fits better into the GUI). This means that since it >> builds the spatial index everytime you call it, everytime you use the >> query tool you get the building of the spatial index. >> >> Now, I see several options from here: > >> - Change the query tool in the GUI so that it collects points and then >> sends the whole series to v.what. This has the big disadvantage that you >> don't see the results of your clicks immediately (i.e. you "blindly" >> click on a series of points and then push "go" to see the results for >> all of these points). It still means that whenever you resuse the query >> tool spatial index gets rebuilt which can be very annoying if you have >> to query information out of a map. So, even though this might be a >> temporary "solution", I don't find it very satisfactory. >> >> - Reimplement an interactive version of v.what, or rather make it >> possible to use d.what.vect from the GUI. This would probably mean >> recoding d.what.vect in whatever the GUI language and call GRASS library >> functions from there. > > The obvious approach is to extend v.what to allow coordinates to be > read from stdin. How would this change from the first approach (if v.what could easily be made to accept multiple coordinates) ? This would again mean 'blindly' collecting points before seeing the results, or having to call v.what multiple times. > > BTW, it appears that v.what currently ignores all coordinate pairs > other than the first. > >> - Reuse spatial index on disk, possibly making it optional on a >> per-location or even per-mapset basis, so that those that need can use >> it and those that would find it annoying could just ignore it. > > This is a separate issue to making v.what more efficient; other > modules may benefit from not having to regenerate the spatial index > for each invocation. Well, for me the main inefficiency in v.what is the rebuilding of the spatial index ... I'll have a look and try to understand the index building code and Radim's suggestions of changing it, but I'm way beyond my knowledge and capacity in C, here... Moritz From tutey at o2.pl Tue Sep 12 10:36:41 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Sep 12 10:36:44 2006 Subject: [GRASS-dev] Re: [bug #2765] (grass) v.buffer produces strange results In-Reply-To: <20060912152918.77a48f94.hamish_nospam@yahoo.com> References: <20060911194400.1FD111005B4@lists.intevation.de> <20060912152918.77a48f94.hamish_nospam@yahoo.com> Message-ID: <45067199.60007@o2.pl> Hamish wrote: > Maciek wrote: >> Are you absolutely sure that the output of following v.buffer >> commands: >> >> v.buffer input=ditches output=ditches_buf1 type=area buffer=1 >> v.buffer input=ditches output=ditches_buf4 type=area buffer=4 >> >> looks all OK after you zoom to region 'ditches_buf' included in my >> sample dataset? >> >> For me it's obvious that the output is plain wrong. > attached is a screenshot of the original vector in "aqua" on top of the > 1 and 4 meter buffers I've just created. Wow, this looks OK indeed. Look at my buf_bugs.png screenshot of the same area - red is 4m buffer, green is 1m buffer. Both are all wrong. I wonder how such a difference between your and my results is possible. > But it doesn't matter -- I was looking for a simple example of it going > wrong and I think I've found one: > Can you try buffering this simple polygon and see if it works correctly > for you? (I used a 10m buffer) If we can fix the bug causing that, > maybe your area filling bug will go away too. I tried. You can see the result of buffering at 10m on the attached screendumps: hamish_area.png - your input area hamish_area_buf10.png - 10m buffer hamish_area_both.png - both, overlayed The 10m buffer is wrong. I'm curious if you obtain *the same* wrong buffer. Maciek -------------- next part -------------- A non-text attachment was scrubbed... Name: buf_bugs.png Type: image/png Size: 4287 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060912/20da7854/buf_bugs-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: hamish_area.png Type: image/png Size: 1425 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060912/20da7854/hamish_area-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: hamish_area_buf10.png Type: image/png Size: 1540 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060912/20da7854/hamish_area_buf10-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: hamish_area_both.png Type: image/png Size: 2043 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060912/20da7854/hamish_area_both-0001.png From glynn at gclements.plus.com Tue Sep 12 11:11:07 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Sep 12 11:11:17 2006 Subject: [GRASS-dev] v.what and spatial index In-Reply-To: <450670E5.7020105@club.worldonline.be> References: <44DAE895.4060809@club.worldonline.be> <44FEEFA0.2050703@club.worldonline.be> <17663.4929.559488.267433@cerise.gclements.plus.com> <20060907165008.4b8fc991.hamish_nospam@yahoo.com> <45003E31.1070800@club.worldonline.be> <17664.57943.168262.726011@cerise.gclements.plus.com> <450670E5.7020105@club.worldonline.be> Message-ID: <17670.31147.266199.289345@cerise.gclements.plus.com> Moritz Lennert wrote: > >> However, v.what does not have an interactive mode (that's the whole idea > >> of v.what so it fits better into the GUI). This means that since it > >> builds the spatial index everytime you call it, everytime you use the > >> query tool you get the building of the spatial index. > >> > >> Now, I see several options from here: > > > >> - Change the query tool in the GUI so that it collects points and then > >> sends the whole series to v.what. This has the big disadvantage that you > >> don't see the results of your clicks immediately (i.e. you "blindly" > >> click on a series of points and then push "go" to see the results for > >> all of these points). It still means that whenever you resuse the query > >> tool spatial index gets rebuilt which can be very annoying if you have > >> to query information out of a map. So, even though this might be a > >> temporary "solution", I don't find it very satisfactory. > >> > >> - Reimplement an interactive version of v.what, or rather make it > >> possible to use d.what.vect from the GUI. This would probably mean > >> recoding d.what.vect in whatever the GUI language and call GRASS library > >> functions from there. > > > > The obvious approach is to extend v.what to allow coordinates to be > > read from stdin. > > How would this change from the first approach (if v.what could easily be > made to accept multiple coordinates) ? This would again mean 'blindly' > collecting points before seeing the results, or having to call v.what > multiple times. v.what would read one coordinate pair, perform the lookup, write out the result(s), repeat until EOF. gis.m would start one v.what process; each time you click the mouse button, it would send the coordinates to the v.what process, read the result, then display it. It would need to restart v.what if the set of maps changed, but could use a single process to look up multiple points. -- Glynn Clements From grass-bugs at intevation.de Tue Sep 12 11:34:54 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Tue Sep 12 11:34:58 2006 Subject: [GRASS-dev] [bug #5129] (grass) ps.map: vpoints with sizecol not sorted to put larger behind smaller icons Message-ID: <20060912093454.3CA8F1005B4@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5129 ------------------------------------------------------------------------- Subject: ps.map: vpoints with sizecol not sorted to put larger behind smaller icons Platform: GNU/Linux/x86 grass obtained from: CVS grass binary for platform: Compiled from Sources GRASS Version: cvs_head_20060912 When creating sizeable point symbols with the vpoints command and the sizecol option, ps.map does not sort the icons so that larger are behind smaller ones. This can make smaller ones invisible sometimes. Moritz -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Tue Sep 12 11:36:25 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Tue Sep 12 11:36:26 2006 Subject: [GRASS-dev] [bug #5130] (grass) d.vect.chart: objects sized with sizecol not sorted to put larger behind smaller icons Message-ID: <20060912093625.0D98B1005B4@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5130 ------------------------------------------------------------------------- Subject: d.vect.chart: objects sized with sizecol not sorted to put larger behind smaller icons Platform: GNU/Linux/x86 grass obtained from: CVS grass binary for platform: Compiled from Sources GRASS Version: cvs_head_20060912 When creating sizeable point symbols with d.vect.chart it does not sort the icons so that larger are behind smaller ones. This can make smaller ones invisible sometimes. Moritz -------------------------------------------- Managed by Request Tracker From hamish_nospam at yahoo.com Tue Sep 12 11:41:21 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Sep 12 11:41:29 2006 Subject: [GRASS-dev] Re: [bug #2765] (grass) v.buffer produces strange results In-Reply-To: <45067199.60007@o2.pl> References: <20060911194400.1FD111005B4@lists.intevation.de> <20060912152918.77a48f94.hamish_nospam@yahoo.com> <45067199.60007@o2.pl> Message-ID: <20060912214121.76120e7a.hamish_nospam@yahoo.com> Maciej Sieczka wrote: > > Wow, this looks OK indeed. Look at my buf_bugs.png screenshot of the > same area - red is 4m buffer, green is 1m buffer. Both are all wrong. > I wonder how such a difference between your and my results is > possible. Unless "ditches" is slightly different, I don't know. The 4m buffer blob seems to me to be the same disease as the lump in "my" area. maybe try v.build.polyline? > > But it doesn't matter -- I was looking for a simple example of it > > going wrong and I think I've found one: > > > Can you try buffering this simple polygon and see if it works > > correctly for you? (I used a 10m buffer) If we can fix the bug > > causing that, maybe your area filling bug will go away too. > > I tried. You can see the result of buffering at 10m on the attached > screendumps: > > hamish_area.png - your input area > hamish_area_buf10.png - 10m buffer > hamish_area_both.png - both, overlayed > > The 10m buffer is wrong. I'm curious if you obtain *the same* wrong > buffer. I get identical results, which is reassuring. (this is cat #1188 or so from the 'ditches' map) Hamish From tutey at o2.pl Tue Sep 12 15:17:24 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Sep 12 15:17:34 2006 Subject: [GRASS-dev] Re: [bug #2765] (grass) v.buffer produces strange results In-Reply-To: <20060912214121.76120e7a.hamish_nospam@yahoo.com> References: <20060911194400.1FD111005B4@lists.intevation.de> <20060912152918.77a48f94.hamish_nospam@yahoo.com> <45067199.60007@o2.pl> <20060912214121.76120e7a.hamish_nospam@yahoo.com> Message-ID: <4506B364.6030108@o2.pl> Hamish wrote: > Maciej Sieczka wrote: >> Wow, this looks OK indeed. Look at my buf_bugs.png screenshot of the >> same area - red is 4m buffer, green is 1m buffer. Both are all wrong. >> I wonder how such a difference between your and my results is >> possible. > > Unless "ditches" is slightly different, I don't know. My "ditches" is *identical* to what I sent you. Very strange. > The 4m buffer blob > seems to me to be the same disease as the lump in "my" area. > > maybe try v.build.polyline? v.build.polylines is buggy, especially for closed lines like area boundaries: http://intevation.de/rt/webrt?serial_num=4249 http://intevation.de/rt/webrt?serial_num=4247 and I avoid using it - not to screw my data. >>> But it doesn't matter -- I was looking for a simple example of it >>> going wrong and I think I've found one: >>> Can you try buffering this simple polygon and see if it works >>> correctly for you? (I used a 10m buffer) If we can fix the bug >>> causing that, maybe your area filling bug will go away too. >> I tried. You can see the result of buffering at 10m on the attached >> screendumps: >> >> hamish_area.png - your input area >> hamish_area_buf10.png - 10m buffer >> hamish_area_both.png - both, overlayed >> >> The 10m buffer is wrong. I'm curious if you obtain *the same* wrong >> buffer. > > I get identical results, which is reassuring. (this is cat #1188 or so > from the 'ditches' map) Some good news! Do you maybe have an idea how to fix that? Maciek From hamish_nospam at yahoo.com Wed Sep 13 06:31:13 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Sep 13 06:31:43 2006 Subject: [GRASS-dev] Re: [bug #2765] (grass) v.buffer produces strange results In-Reply-To: <4506B364.6030108@o2.pl> References: <20060911194400.1FD111005B4@lists.intevation.de> <20060912152918.77a48f94.hamish_nospam@yahoo.com> <45067199.60007@o2.pl> <20060912214121.76120e7a.hamish_nospam@yahoo.com> <4506B364.6030108@o2.pl> Message-ID: <20060913163113.024664fa.hamish_nospam@yahoo.com> Maciej Sieczka wrote: > > I get identical results, which is reassuring. (this is cat #1188 or > > so from the 'ditches' map) > > Some good news! Do you maybe have an idea how to fix that? The loop processing segments sa and sb in clean_parrallel() wraps back to the first segment, and the bug resets the number of points based on the last segment seen (ie sa back to "0"), not the maximum number of points added to the output group. (see debug output in bug history) (clean_parallel() is in lib/vector/Vlib/buffer.c) Hopefully that is enough of a clue for someone to find a solution. I won't have any time to work on it for the next week or two, but would like to see this fixed and tested for the 6.2.0 release. Hamish From mlennert at club.worldonline.be Wed Sep 13 12:24:53 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Sep 13 12:24:20 2006 Subject: [GRASS-dev] v.what and spatial index In-Reply-To: <17670.31147.266199.289345@cerise.gclements.plus.com> References: <44DAE895.4060809@club.worldonline.be> <44FEEFA0.2050703@club.worldonline.be> <17663.4929.559488.267433@cerise.gclements.plus.com> <20060907165008.4b8fc991.hamish_nospam@yahoo.com> <45003E31.1070800@club.worldonline.be> <17664.57943.168262.726011@cerise.gclements.plus.com> <450670E5.7020105@club.worldonline.be> <17670.31147.266199.289345@cerise.gclements.plus.com> Message-ID: <4507DC75.5090001@club.worldonline.be> Glynn Clements wrote: > Moritz Lennert wrote: > >>>> However, v.what does not have an interactive mode (that's the whole idea >>>> of v.what so it fits better into the GUI). This means that since it >>>> builds the spatial index everytime you call it, everytime you use the >>>> query tool you get the building of the spatial index. >>>> >>>> Now, I see several options from here: >>>> - Change the query tool in the GUI so that it collects points and then >>>> sends the whole series to v.what. This has the big disadvantage that you >>>> don't see the results of your clicks immediately (i.e. you "blindly" >>>> click on a series of points and then push "go" to see the results for >>>> all of these points). It still means that whenever you resuse the query >>>> tool spatial index gets rebuilt which can be very annoying if you have >>>> to query information out of a map. So, even though this might be a >>>> temporary "solution", I don't find it very satisfactory. >>>> >>>> - Reimplement an interactive version of v.what, or rather make it >>>> possible to use d.what.vect from the GUI. This would probably mean >>>> recoding d.what.vect in whatever the GUI language and call GRASS library >>>> functions from there. >>> The obvious approach is to extend v.what to allow coordinates to be >>> read from stdin. >> How would this change from the first approach (if v.what could easily be >> made to accept multiple coordinates) ? This would again mean 'blindly' >> collecting points before seeing the results, or having to call v.what >> multiple times. > > v.what would read one coordinate pair, perform the lookup, write out > the result(s), repeat until EOF. > > gis.m would start one v.what process; each time you click the mouse > button, it would send the coordinates to the v.what process, read the > result, then display it. It would need to restart v.what if the set of > maps changed, but could use a single process to look up multiple > points. > Here's my attempt at applying what you suggest. It's not very complicated, and seems to work fine here, but I'd appreciate if someone could check that I didn't do anything wrong before committing. Now we will have to change the query function in the gis manager (from line 1474 of gui/tcltk/gis.m/mapcanvas.tcl) to use v.what with the -s flag and to provide continuous flow of coordinates and an EOF at the end. Michael, can you do this ? Or could someone tell me in rough lines how this can be done ? Moritz -------------- next part -------------- A non-text attachment was scrubbed... Name: v.what.stdin.patch Type: text/x-patch Size: 1916 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060913/618b8241/v.what.stdin.bin From glynn at gclements.plus.com Wed Sep 13 14:20:37 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Sep 13 14:23:36 2006 Subject: [GRASS-dev] v.what and spatial index In-Reply-To: <4507DC75.5090001@club.worldonline.be> References: <44DAE895.4060809@club.worldonline.be> <44FEEFA0.2050703@club.worldonline.be> <17663.4929.559488.267433@cerise.gclements.plus.com> <20060907165008.4b8fc991.hamish_nospam@yahoo.com> <45003E31.1070800@club.worldonline.be> <17664.57943.168262.726011@cerise.gclements.plus.com> <450670E5.7020105@club.worldonline.be> <17670.31147.266199.289345@cerise.gclements.plus.com> <4507DC75.5090001@club.worldonline.be> Message-ID: <17671.63381.317089.820839@cerise.gclements.plus.com> Moritz Lennert wrote: > >> How would this change from the first approach (if v.what could easily be > >> made to accept multiple coordinates) ? This would again mean 'blindly' > >> collecting points before seeing the results, or having to call v.what > >> multiple times. > > > > v.what would read one coordinate pair, perform the lookup, write out > > the result(s), repeat until EOF. > > > > gis.m would start one v.what process; each time you click the mouse > > button, it would send the coordinates to the v.what process, read the > > result, then display it. It would need to restart v.what if the set of > > maps changed, but could use a single process to look up multiple > > points. > > Here's my attempt at applying what you suggest. It's not very > complicated, and seems to work fine here, but I'd appreciate if someone > could check that I didn't do anything wrong before committing. One issue which won't show up when running it directly from the shell, but will if you run it via pipes: you need to explicitly set stdin and stdout to line-buffered operation with e.g.: setvbuf(stdin, NULL, _IOLBF, 0); setvbuf(stdout, NULL, _IOLBF, 0); > Now we will have to change the query function in the gis manager (from > line 1474 of gui/tcltk/gis.m/mapcanvas.tcl) to use v.what with the -s > flag and to provide continuous flow of coordinates and an EOF at the > end. Michael, can you do this ? Or could someone tell me in rough lines > how this can be done ? Ah. Tcl's "open" function doesn't directly support using pipes for both stdin and stdout; you can choose read (stdout is a pipe, stdin is inherited) or write (stdin is a pipe, stdout is inherited), but not both. You will need to create a named pipe (with mkfifo) then explicitly redirect one of the ends to it, e.g. set fifo $tmpdir/$tmpname exec mkfifo $fifo set rfh [open "|v.what map=$maplist <$fifo" r] fconfigure $rfh -buffering line set wfh [open $fifo w] fconfigure $wfh -buffering line -- Glynn Clements From mlennert at club.worldonline.be Wed Sep 13 15:32:00 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Sep 13 15:31:27 2006 Subject: [GRASS-dev] v.what and spatial index In-Reply-To: <17671.63381.317089.820839@cerise.gclements.plus.com> References: <44DAE895.4060809@club.worldonline.be> <44FEEFA0.2050703@club.worldonline.be> <17663.4929.559488.267433@cerise.gclements.plus.com> <20060907165008.4b8fc991.hamish_nospam@yahoo.com> <45003E31.1070800@club.worldonline.be> <17664.57943.168262.726011@cerise.gclements.plus.com> <450670E5.7020105@club.worldonline.be> <17670.31147.266199.289345@cerise.gclements.plus.com> <4507DC75.5090001@club.worldonline.be> <17671.63381.317089.820839@cerise.gclements.plus.com> Message-ID: <45080850.5060203@club.worldonline.be> Glynn Clements wrote: > Moritz Lennert wrote: > >>>> How would this change from the first approach (if v.what could easily be >>>> made to accept multiple coordinates) ? This would again mean 'blindly' >>>> collecting points before seeing the results, or having to call v.what >>>> multiple times. >>> v.what would read one coordinate pair, perform the lookup, write out >>> the result(s), repeat until EOF. >>> >>> gis.m would start one v.what process; each time you click the mouse >>> button, it would send the coordinates to the v.what process, read the >>> result, then display it. It would need to restart v.what if the set of >>> maps changed, but could use a single process to look up multiple >>> points. >> Here's my attempt at applying what you suggest. It's not very >> complicated, and seems to work fine here, but I'd appreciate if someone >> could check that I didn't do anything wrong before committing. > > One issue which won't show up when running it directly from the shell, > but will if you run it via pipes: you need to explicitly set stdin and > stdout to line-buffered operation with e.g.: > > setvbuf(stdin, NULL, _IOLBF, 0); > setvbuf(stdout, NULL, _IOLBF, 0); I assume this can be done anywhere as long as its before the call to stdin ? > >> Now we will have to change the query function in the gis manager (from >> line 1474 of gui/tcltk/gis.m/mapcanvas.tcl) to use v.what with the -s >> flag and to provide continuous flow of coordinates and an EOF at the >> end. Michael, can you do this ? Or could someone tell me in rough lines >> how this can be done ? > > Ah. Tcl's "open" function doesn't directly support using pipes for > both stdin and stdout; you can choose read (stdout is a pipe, stdin is > inherited) or write (stdin is a pipe, stdout is inherited), but not > both. > > You will need to create a named pipe (with mkfifo) then explicitly > redirect one of the ends to it, e.g. > > set fifo $tmpdir/$tmpname > exec mkfifo $fifo > set rfh [open "|v.what map=$maplist <$fifo" r] > fconfigure $rfh -buffering line > set wfh [open $fifo w] > fconfigure $wfh -buffering line Ok, I understand the principle of this, but don't know how and where to apply it in mapcanvas.tcl. Don't have the time to dig into it right now. Michael ? Another question is whether it is worth doing all this (don't know how much work it is to apply Glynn's solution) if we are going to change GUI in a foreseeable future... Thanks, Glynn, for your help. Moritz From hamish_nospam at yahoo.com Wed Sep 13 15:37:14 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Sep 13 15:37:22 2006 Subject: [GRASS-dev] [bug #5037] (grass) GRASS 6.3: d.graph Message-ID: <20060914013714.65b21bb5.hamish_nospam@yahoo.com> > > this bug's URL: http://intevation.de/rt/webrt?serial_num=5037 > > ------------------------------------------------------------------- > > > > Subject: GRASS 6.3: d.graph segfault > > > > d.graph segfaults on startup. (GRASS 6.3-cvs only) .. Glynn: > It segfaults because trans is NULL, because R_RGB_color() > is called before R_open_driver(). > > R_open_driver() or R__open_quiet() must be called before almost any > other R_* functions are called. The only exceptions are: > > R_parse_monitorcap > R_set_update_function > R_call_update_function > R_has_update_function > R_set_cancel > R_get_cancel > R_pad_freelist > R_pad_perror > > The old library would silently ignore any operations performed while > not connected to a driver. There's another problem, G_str_to_color() [lib/gis/color_str.c] returns an error if a color is given as a R:G:B triplet. It seems to work fine with triplets from other modules (d.vect). e.g.: G63> echo "symbol basic/box 16 50 50 green 50:50:50" | d.graph WARNING: [50:50:50]: No such color sscanf() fills red,green,blue with garbage? [which fails >255 test] ret = sscanf (buf, "%d%[,:; ]%d%[,:; ]%d", red, temp, green, temp, blue); I'm having no luck debugging this. R,G,B getting cast to another type somehwhere???? ? thanks, Hamish From twiens at interbaun.com Wed Sep 13 15:50:24 2006 From: twiens at interbaun.com (Trevor Wiens) Date: Wed Sep 13 15:50:28 2006 Subject: [GRASS-dev] v.what and spatial index In-Reply-To: <45080850.5060203@club.worldonline.be> References: <44DAE895.4060809@club.worldonline.be> <44FEEFA0.2050703@club.worldonline.be> <17663.4929.559488.267433@cerise.gclements.plus.com> <20060907165008.4b8fc991.hamish_nospam@yahoo.com> <45003E31.1070800@club.worldonline.be> <17664.57943.168262.726011@cerise.gclements.plus.com> <450670E5.7020105@club.worldonline.be> <17670.31147.266199.289345@cerise.gclements.plus.com> <4507DC75.5090001@club.worldonline.be> <17671.63381.317089.820839@cerise.gclements.plus.com> <45080850.5060203@club.worldonline.be> Message-ID: <20060913075024.7cce58d5@localhost.localdomain> On Wed, 13 Sep 2006 15:32:00 +0200 Moritz Lennert wrote: > Glynn Clements wrote: > > Moritz Lennert wrote: > > > >>>> How would this change from the first approach (if v.what could easily be > >>>> made to accept multiple coordinates) ? This would again mean 'blindly' > >>>> collecting points before seeing the results, or having to call v.what > >>>> multiple times. > >>> v.what would read one coordinate pair, perform the lookup, write out > >>> the result(s), repeat until EOF. > >>> > >>> gis.m would start one v.what process; each time you click the mouse > >>> button, it would send the coordinates to the v.what process, read the > >>> result, then display it. It would need to restart v.what if the set of > >>> maps changed, but could use a single process to look up multiple > >>> points. > >> Here's my attempt at applying what you suggest. It's not very > >> complicated, and seems to work fine here, but I'd appreciate if someone > >> could check that I didn't do anything wrong before committing. > > > > One issue which won't show up when running it directly from the shell, > > but will if you run it via pipes: you need to explicitly set stdin and > > stdout to line-buffered operation with e.g.: > > > > setvbuf(stdin, NULL, _IOLBF, 0); > > setvbuf(stdout, NULL, _IOLBF, 0); > > I assume this can be done anywhere as long as its before the call to stdin ? > > > > >> Now we will have to change the query function in the gis manager (from > >> line 1474 of gui/tcltk/gis.m/mapcanvas.tcl) to use v.what with the -s > >> flag and to provide continuous flow of coordinates and an EOF at the > >> end. Michael, can you do this ? Or could someone tell me in rough lines > >> how this can be done ? > > > > Ah. Tcl's "open" function doesn't directly support using pipes for > > both stdin and stdout; you can choose read (stdout is a pipe, stdin is > > inherited) or write (stdin is a pipe, stdout is inherited), but not > > both. > > > > You will need to create a named pipe (with mkfifo) then explicitly > > redirect one of the ends to it, e.g. > > > > set fifo $tmpdir/$tmpname > > exec mkfifo $fifo > > set rfh [open "|v.what map=$maplist <$fifo" r] > > fconfigure $rfh -buffering line > > set wfh [open $fifo w] > > fconfigure $wfh -buffering line > > Ok, I understand the principle of this, but don't know how and where to > apply it in mapcanvas.tcl. Don't have the time to dig into it right now. > Michael ? > > Another question is whether it is worth doing all this (don't know how > much work it is to apply Glynn's solution) if we are going to change GUI > in a foreseeable future... > Moritz, Thanks for doing this. This change will also be useful for future GUI's. T -- Trevor Wiens twiens@interbaun.com The significant problems that we face cannot be solved at the same level of thinking we were at when we created them. (Albert Einstein) From mlennert at club.worldonline.be Wed Sep 13 16:32:59 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Sep 13 16:32:24 2006 Subject: [GRASS-dev] v.what and spatial index In-Reply-To: <1925F594-4AF8-4E16-8179-726D12A32FEE@asu.edu> References: <44DAE895.4060809@club.worldonline.be> <44FEEFA0.2050703@club.worldonline.be> <17663.4929.559488.267433@cerise.gclements.plus.com> <20060907165008.4b8fc991.hamish_nospam@yahoo.com> <45003E31.1070800@club.worldonline.be> <17664.57943.168262.726011@cerise.gclements.plus.com> <450670E5.7020105@club.worldonline.be> <17670.31147.266199.289345@cerise.gclements.plus.com> <4507DC75.5090001@club.worldonline.be> <17671.63381.317089.820839@cerise.gclements.plus.com> <45080850.5060203@club.worldonline.be> <1925F594-4AF8-4E16-8179-726D12A32FEE@asu.edu> Message-ID: <4508169B.6010208@club.worldonline.be> Michael Barton wrote: > Moritz, > > I'm tied up all day. I'm not exactly sure how you want to change the > behavior of v.what in gism. That is, I don't understand about a stream > of coordinates. Could you explain it a bit better. Sorry if I'm dense. The problem: v.what builds the spatial index everytime it is called. For large files this takes a while making the use of v.what on several points in a row very slow. The query tool of gis.m calls v.what for every query click. The solution: Allow v.what to accept more than one pair of coordinates by listening on stdin until it reveives an EOF call. The query tool in gis.m opens a connection to v.what in the way described by Glynn below, feeds in the coordinates everytime the user clicks on the map, displays the relevant information and continues to wait for the next click unless it receives some sort of EOF (example: user choses different tool in map display window - or a right click, whatever seems the most convenient). That way a user can display a map, click at different points of the map and immediately receive the information, without having to wait for the spatial index to be built because of separate v.what calls. Does that make sense ? If it is not too difficult to implement in gis.m it would be great to have it. Otherwise, it would have to wait for the next gui... Moritz > > Michael > On Sep 13, 2006, at 6:32 AM, Moritz Lennert wrote: > >> Glynn Clements wrote: >>> Moritz Lennert wrote: >>>>>> How would this change from the first approach (if v.what could >>>>>> easily be made to accept multiple coordinates) ? This would again >>>>>> mean 'blindly' collecting points before seeing the results, or >>>>>> having to call v.what multiple times. >>>>> v.what would read one coordinate pair, perform the lookup, write out >>>>> the result(s), repeat until EOF. >>>>> >>>>> gis.m would start one v.what process; each time you click the mouse >>>>> button, it would send the coordinates to the v.what process, read the >>>>> result, then display it. It would need to restart v.what if the set of >>>>> maps changed, but could use a single process to look up multiple >>>>> points. >>>> Here's my attempt at applying what you suggest. It's not very >>>> complicated, and seems to work fine here, but I'd appreciate if >>>> someone could check that I didn't do anything wrong before committing. >>> One issue which won't show up when running it directly from the shell, >>> but will if you run it via pipes: you need to explicitly set stdin and >>> stdout to line-buffered operation with e.g.: >>> setvbuf(stdin, NULL, _IOLBF, 0); >>> setvbuf(stdout, NULL, _IOLBF, 0); >> >> I assume this can be done anywhere as long as its before the call to >> stdin ? >> >>>> Now we will have to change the query function in the gis manager >>>> (from line 1474 of gui/tcltk/gis.m/mapcanvas.tcl) to use v.what with >>>> the -s flag and to provide continuous flow of coordinates and an EOF >>>> at the end. Michael, can you do this ? Or could someone tell me in >>>> rough lines how this can be done ? >>> Ah. Tcl's "open" function doesn't directly support using pipes for >>> both stdin and stdout; you can choose read (stdout is a pipe, stdin is >>> inherited) or write (stdin is a pipe, stdout is inherited), but not >>> both. >>> You will need to create a named pipe (with mkfifo) then explicitly >>> redirect one of the ends to it, e.g. >>> set fifo $tmpdir/$tmpname >>> exec mkfifo $fifo >>> set rfh [open "|v.what map=$maplist <$fifo" r] >>> fconfigure $rfh -buffering line >>> set wfh [open $fifo w] >>> fconfigure $wfh -buffering line >> >> Ok, I understand the principle of this, but don't know how and where >> to apply it in mapcanvas.tcl. Don't have the time to dig into it right >> now. Michael ? >> >> Another question is whether it is worth doing all this (don't know how >> much work it is to apply Glynn's solution) if we are going to change >> GUI in a foreseeable future... >> >> Thanks, Glynn, for your help. >> >> Moritz >> > > ____________________ > C. Michael Barton, Professor of Anthropology > School of Human Evolution and Social Change > PO Box 872402 > Arizona State University > Tempe, AZ 85287-2402 > USA > > Phone: 480-965-6262 > Fax: 480-965-7671 > www: > > From mlennert at club.worldonline.be Wed Sep 13 16:34:12 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Sep 13 16:33:38 2006 Subject: [GRASS-dev] v.what and spatial index In-Reply-To: <17671.63381.317089.820839@cerise.gclements.plus.com> References: <44DAE895.4060809@club.worldonline.be> <44FEEFA0.2050703@club.worldonline.be> <17663.4929.559488.267433@cerise.gclements.plus.com> <20060907165008.4b8fc991.hamish_nospam@yahoo.com> <45003E31.1070800@club.worldonline.be> <17664.57943.168262.726011@cerise.gclements.plus.com> <450670E5.7020105@club.worldonline.be> <17670.31147.266199.289345@cerise.gclements.plus.com> <4507DC75.5090001@club.worldonline.be> <17671.63381.317089.820839@cerise.gclements.plus.com> Message-ID: <450816E4.6040401@club.worldonline.be> Glynn Clements wrote: > Moritz Lennert wrote: > >>>> How would this change from the first approach (if v.what could easily be >>>> made to accept multiple coordinates) ? This would again mean 'blindly' >>>> collecting points before seeing the results, or having to call v.what >>>> multiple times. >>> v.what would read one coordinate pair, perform the lookup, write out >>> the result(s), repeat until EOF. >>> >>> gis.m would start one v.what process; each time you click the mouse >>> button, it would send the coordinates to the v.what process, read the >>> result, then display it. It would need to restart v.what if the set of >>> maps changed, but could use a single process to look up multiple >>> points. >> Here's my attempt at applying what you suggest. It's not very >> complicated, and seems to work fine here, but I'd appreciate if someone >> could check that I didn't do anything wrong before committing. > > One issue which won't show up when running it directly from the shell, > but will if you run it via pipes: you need to explicitly set stdin and > stdout to line-buffered operation with e.g.: > > setvbuf(stdin, NULL, _IOLBF, 0); > setvbuf(stdout, NULL, _IOLBF, 0); Just to show my ignorance: why stdout ? I'm only using stdin, or ? Moritz From tutey at o2.pl Wed Sep 13 16:57:15 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Sep 13 16:57:19 2006 Subject: [GRASS-dev] unofficial Debian testing (Etch) repo with Grass 6.2! Message-ID: <45081C4B.20402@o2.pl> Hi, Niccolo Rigacci has set up a Debian testing (Etch) repo that provides his Grass 6.2 beta 1 packages. Also Gdal 1.3.2 and Qgis 0.8 prev 2 are there. Download from http://debian.gfoss.it/pool/main/ and install by hand, or put the deb http://debian.gfoss.it/ etch main line into your /etc/apt/sources.list to fetch it via apt-get. Great stuff Niccolo! PSC, Shall I put a link on Grass download page? Maciek From grass-bugs at intevation.de Wed Sep 13 18:22:29 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Wed Sep 13 18:22:31 2006 Subject: [GRASS-dev] [bug #5133] (grass) It is no possible to download the 6.1 version for MS Windows. Message-ID: <20060913162229.A4A9610015B@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5133 ------------------------------------------------------------------------- Subject: It is no possible to download the 6.1 version for MS Windows. Platform: WindowsNT/2000/XP grass binary for platform: Compiled from Sources Willington Siabato It is no possible to download the 6.1 version for MS Windows. The link is broken. -------------------------------------------- Managed by Request Tracker From dsampson at NRCan.gc.ca Wed Sep 13 18:51:31 2006 From: dsampson at NRCan.gc.ca (Sampson, David) Date: Wed Sep 13 18:51:38 2006 Subject: [GRASS-dev] Spatial database updating using active contours for multispectral Images Message-ID: <2FAA57395C1F914DB27CAA4C376058F28ED43C@S0-OTT-X2.nrn.nrcan.gc.ca> Hey folks.... I just saw a presentation on using imagery to update vector databases using Deformbale Polygon models based on stats and gradients... it was cool to watch a rough road line fix itself towards a georeferenced image. The issue for me is that the work done ast a masters level is slow to find a comercial niche. So I was wondering if it existed already in the open source realm....Or maybe I can just get people thinking about it so that someone can find a link. The presentation I saw was based on research done at Universite de Sherbrooke: http://www.usherbrooke.ca/ The presenter developed the idea with a bunch of other people that were working on different aspects of a similar approach. Here is the main paper I think: "Spatial database updating using active contours for multispectral Image" http://cs-linux.ubishops.ca/~bentabet/BentabetIsprs.pdf The process has been used in medical research a lot and has lots of application in the geomatics world. I came cross JESS which is a java open source project (Source by request, see software link bellow), an abstarct is availbale here http://adsabs.harvard.edu/abs/2005SPIE.5747.1985M Lots of medical examples found here: http://iacl.ece.jhu.edu/projects/gvf/gvf_cite_abstract.html I am wondering if this is something already availabel in OSSIM or maybe GRASS. Or if it is possible ot implement. The technique was new in that it used previous algorythms to form a + - model based on if success was had using statistics of the image or if they used the gradient of the image for push/pull factors. The image processing looks intensive and the presentor mentioned the need in a comercial environment for the creation of ZIP or ZIP lock polygons so that you can process line segments instead of the whole polygon. Anyone have any further references? Some other sources: http://www.scs.ryerson.ca/~tmcinern/isbi2006.pdf http://www.scs.ryerson.ca/~tmcinern/software.html Some abstracts from the author and presentor Sylvie Jodouin: Bentabet, Layachi; Jodouin, Sylvie; Ziou, Djemel; Vaillancourt, Jean Road Vectors Update Using SAR Imagery : A Snake Based Method IEEE Transactions on Geosciences and Remote Sensing, Volume 41, Num?ro 8, pp. 1785-1803, 2003 [Acc?s restreint] [Informations compl?mentaires] PDF Jodouin, Sylvie; Bentabet, Layachi; Ziou, Djemel; Vaillancourt, Jean; Armenakis, Costas Spatial Database Updating using Active Contours for Multispectral Images: Application with Landsat 7 ISPRS Journal of Photogrammetry and Remote Sensing, Volume 57, pp. 346-355, 2003 [Acc?s restreint] [Informations compl?mentaires] PDF Jodouin, Sylvie; Bentabet, Layachi; Ziou, Djemel; Vaillancourt, Jean; Armenakis, Costas A Combined Estimation-Deformation Model for Area Detection: Application to Topographic Area Feature Update Actes de Photogrammetric Computer Vision, ISPRS Commission III, Symposium, Volume A, pp. 181-186, Graz, Austria, du 09-09-2002 au 13-09-2002 [Informations compl?mentaires] PDF Bentabet, Layachi; Jodouin, Sylvie; Ziou, Djemel; Vaillancourt, Jean Automated Updating of Road Databases from SAR Imagery: Integration of Road Databases and SAR Imagery information Actes de 4th International Conference on Information Fusion, Volume WeA1, pp. 3-10, Montr?al, Qc, Canada, du 07-08-2001 au 10-08-2001 Cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060913/d4599bf6/attachment-0001.html From grass-bugs at intevation.de Wed Sep 13 19:09:26 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Wed Sep 13 19:09:28 2006 Subject: [GRASS-dev] [bug #5134] (grass) wish error Message-ID: <20060913170926.26AE310015B@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5134 ------------------------------------------------------------------------- Subject: wish error Platform: other grass obtained from: Mirror of Trento site grass binary for platform: Compiled from Sources GRASS Version: 6.2 Please enter your name and error description here. Don't write general statements such as "this could be better" - please explain in details how a certain problem can be solved or a feature be added/improved. Send different report for different problems. Thanks! I compiled grass from source (grass-6.2.0beta2.tar.gz) on my freebsd 6.0 Intel box. It required just minor tweaking (include,lib path adjustments). Running the program in X11 it says: Starting GRASS ... WARNING: wish does not work as expected! Please check your GRASS_WISH environment variable. i set $GRASS_WISH=wish8.4 couse wish demands using wish4.8 as command. but after that it still prompts the same error message,although the environment variable now is correct. thanks, Nico -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Wed Sep 13 19:28:47 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Wed Sep 13 19:28:51 2006 Subject: [GRASS-dev] [bug #5133] (grass) It is no possible to download the 6.1 version for MS Windows. Message-ID: <20060913172847.BCF6C10015A@lists.intevation.de> What link do you mean excatly? I can't find any refernce to Grass 6.1 on http://grass.itc.it/download/index.php Maciek -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Wed Sep 13 19:32:09 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Wed Sep 13 19:32:10 2006 Subject: [GRASS-dev] [bug #5134] (grass) wish error Message-ID: <20060913173209.3E7D810015B@lists.intevation.de> What is $ which wish saying for you? Maciek -------------------------------------------- Managed by Request Tracker From grass4u at gmail.com Thu Sep 14 05:56:05 2006 From: grass4u at gmail.com (Huidae Cho) Date: Thu Sep 14 05:56:52 2006 Subject: [GRASS-dev] MS-Windows native GRASS Message-ID: <20060914035605.GA20605@localhost.tamu.edu> Hi, I'm so excited to announce that I've just uploaded a package for MS-Windows native GRASS at http://geni.ath.cx/grass.html . Rather than putting everything required for winGRASS in one huge package, I have prepared a batch file for automatic installation except for MinGW, MSys, and PostgreSQL, which are distributed as *.exe. I hope it will make easy for anyone to install winGRASS. Please note that this first package is considered incomplete and requires more testing and bug fixing. Enjoy, Huidae Cho From glynn at gclements.plus.com Thu Sep 14 08:38:38 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Sep 14 08:39:10 2006 Subject: [GRASS-dev] [bug #5037] (grass) GRASS 6.3: d.graph In-Reply-To: <20060914013714.65b21bb5.hamish_nospam@yahoo.com> References: <20060914013714.65b21bb5.hamish_nospam@yahoo.com> Message-ID: <17672.63726.303593.144450@cerise.gclements.plus.com> Hamish wrote: > > > this bug's URL: http://intevation.de/rt/webrt?serial_num=5037 > > > ------------------------------------------------------------------- > > > > > > Subject: GRASS 6.3: d.graph segfault > > > > > > d.graph segfaults on startup. (GRASS 6.3-cvs only) > .. > Glynn: > > It segfaults because trans is NULL, because R_RGB_color() > > is called before R_open_driver(). > > > > R_open_driver() or R__open_quiet() must be called before almost any > > other R_* functions are called. The only exceptions are: > > > > R_parse_monitorcap > > R_set_update_function > > R_call_update_function > > R_has_update_function > > R_set_cancel > > R_get_cancel > > R_pad_freelist > > R_pad_perror > > > > The old library would silently ignore any operations performed while > > not connected to a driver. > > > There's another problem, G_str_to_color() [lib/gis/color_str.c] returns > an error if a color is given as a R:G:B triplet. Same program, but a completely unrelated bug. > It seems to work fine with triplets from other modules (d.vect). > > e.g.: > > G63> echo "symbol basic/box 16 50 50 green 50:50:50" | d.graph > WARNING: [50:50:50]: No such color > > > sscanf() fills red,green,blue with garbage? [which fails >255 test] > > ret = sscanf (buf, "%d%[,:; ]%d%[,:; ]%d", red, temp, green, temp, blue); > > > I'm having no luck debugging this. R,G,B getting cast to another type > somehwhere???? lib/gis/color_str.c:54: int G_str_to_color (const char *str, int *red, int *green, int *blue) include/gis.h:299: typedef struct { unsigned char r, g, b, a; /* red, green, blue, and alpha */ } RGBA_Color ; display/d.graph/do_graph.c:386: ret = G_str_to_color(line_color_str, &line_color->r, &line_color->g, &line_color->b); IOW, do_graph.c is passing pointers to "unsigned char" fields while G_str_to_color() expects pointers to "int"s, resulting in the pointer targets overlapping (each is 4 bytes wide, but they start 1 byte apart). The value of *red will be the result of reading the entire structure as if it was an int. On a little-endian system, the value will be 0xAABBGGRR (the alpha field will typically contain garbage); on a big-endian system, it would be 0xRRGGBBAA. However, the most common big-endian architecture (PPC) requires "int"s to be aligned, so you would get an exception (SIGBUS, IIRC) trying to read or write *green or *blue. The d.graph code needs to be changed to e.g: { int r, g, b; ret = G_str_to_color(line_color_str, &r, &g, &b); line_color->r = (unsigned char) r; line_color->g = (unsigned char) g; line_color->b = (unsigned char) b; } -- Glynn Clements From glynn at gclements.plus.com Thu Sep 14 08:40:02 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Sep 14 08:41:50 2006 Subject: [GRASS-dev] v.what and spatial index In-Reply-To: <45080850.5060203@club.worldonline.be> References: <44DAE895.4060809@club.worldonline.be> <44FEEFA0.2050703@club.worldonline.be> <17663.4929.559488.267433@cerise.gclements.plus.com> <20060907165008.4b8fc991.hamish_nospam@yahoo.com> <45003E31.1070800@club.worldonline.be> <17664.57943.168262.726011@cerise.gclements.plus.com> <450670E5.7020105@club.worldonline.be> <17670.31147.266199.289345@cerise.gclements.plus.com> <4507DC75.5090001@club.worldonline.be> <17671.63381.317089.820839@cerise.gclements.plus.com> <45080850.5060203@club.worldonline.be> Message-ID: <17672.63810.779967.686971@cerise.gclements.plus.com> Moritz Lennert wrote: > > One issue which won't show up when running it directly from the shell, > > but will if you run it via pipes: you need to explicitly set stdin and > > stdout to line-buffered operation with e.g.: > > > > setvbuf(stdin, NULL, _IOLBF, 0); > > setvbuf(stdout, NULL, _IOLBF, 0); > > I assume this can be done anywhere as long as its before the call to stdin ? It needs to be done before anything reads from stdin or writes to stdout. -- Glynn Clements From glynn at gclements.plus.com Thu Sep 14 08:46:42 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Sep 14 08:46:45 2006 Subject: [GRASS-dev] v.what and spatial index In-Reply-To: <450816E4.6040401@club.worldonline.be> References: <44DAE895.4060809@club.worldonline.be> <44FEEFA0.2050703@club.worldonline.be> <17663.4929.559488.267433@cerise.gclements.plus.com> <20060907165008.4b8fc991.hamish_nospam@yahoo.com> <45003E31.1070800@club.worldonline.be> <17664.57943.168262.726011@cerise.gclements.plus.com> <450670E5.7020105@club.worldonline.be> <17670.31147.266199.289345@cerise.gclements.plus.com> <4507DC75.5090001@club.worldonline.be> <17671.63381.317089.820839@cerise.gclements.plus.com> <450816E4.6040401@club.worldonline.be> Message-ID: <17672.64210.740229.845600@cerise.gclements.plus.com> Moritz Lennert wrote: > >>>> How would this change from the first approach (if v.what could easily be > >>>> made to accept multiple coordinates) ? This would again mean 'blindly' > >>>> collecting points before seeing the results, or having to call v.what > >>>> multiple times. > >>> v.what would read one coordinate pair, perform the lookup, write out > >>> the result(s), repeat until EOF. > >>> > >>> gis.m would start one v.what process; each time you click the mouse > >>> button, it would send the coordinates to the v.what process, read the > >>> result, then display it. It would need to restart v.what if the set of > >>> maps changed, but could use a single process to look up multiple > >>> points. > >> Here's my attempt at applying what you suggest. It's not very > >> complicated, and seems to work fine here, but I'd appreciate if someone > >> could check that I didn't do anything wrong before committing. > > > > One issue which won't show up when running it directly from the shell, > > but will if you run it via pipes: you need to explicitly set stdin and > > stdout to line-buffered operation with e.g.: > > > > setvbuf(stdin, NULL, _IOLBF, 0); > > setvbuf(stdout, NULL, _IOLBF, 0); > > Just to show my ignorance: why stdout ? I'm only using stdin, or ? v.what would read coordinates from stdin and write information regarding the point/line/area at (or near) those coordinates to stdout. See vector/v.what/what.c; there are 25 occurrences of "stdout" in that file. Actually, as what() always calls fflush(stdout), you can omit the setvbuf() call for stdout. -- Glynn Clements From mlennert at club.worldonline.be Thu Sep 14 11:10:46 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Sep 14 11:10:12 2006 Subject: [GRASS-dev] MS-Windows native GRASS In-Reply-To: <20060914035605.GA20605@localhost.tamu.edu> References: <20060914035605.GA20605@localhost.tamu.edu> Message-ID: <4868.164.15.134.77.1158225046.squirrel@geog-pc40.ulb.ac.be> On Thu, September 14, 2006 05:56, Huidae Cho wrote: > Hi, > > I'm so excited to announce that I've just uploaded a package for > MS-Windows native GRASS at http://geni.ath.cx/grass.html . Rather than > putting everything required for winGRASS in one huge package, I have > prepared > a batch file for automatic installation except for MinGW, MSys, and > PostgreSQL, which are distributed as *.exe. I hope it will make easy for > anyone to install winGRASS. Congratulations ! At first try, install didn't work (nothing installed even though it said it did). I then realised that the wget package was not downloaded correctly. After I downloaded it again, everything went very smoothly. > > Please note that this first package is considered incomplete and > requires more testing and bug fixing. First impressions: