From grass-bugs at intevation.de Sat Jul 1 00:14:03 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sat Jul 1 00:14:05 2006 Subject: [GRASS-dev] [bug #4769] (grass) memory leak in v.in.ascii Message-ID: <20060630221403.E1C761006C1@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4769 ------------------------------------------------------------------------- Subject: memory leak in v.in.ascii Platform: GNU/Linux/x86 grass obtained from: CVS grass binary for platform: Compiled from Sources GRASS Version: cvs June 10? 2006 Recent changes in v.in.ascii to support LL data introduced a memory leak for projected data sets. Affected file is vector/v.in.ascii/points.c :points_analyse tokens = G_tokenize (buf, fs); allocates an array of char*s that point to various points in buf, but these char*s are not freed before the next G_tokenize. On large lidar point sets, the leak causes out of memory errors. There was a G_free_tokens(tokens) inside the loop in an older CVS version (1.12), but I don't think this is right either, as G_free_tokens frees both the char* array AND the buffer. I think the correct order of frees to prevent memory leaks is Inside loop: call G_free(tokens), not G_free_tokens(tokens). This frees the char* array, but not the underlying buffer, buf Outside of while loop: call G_free(buf) G_free(tmp_token) G_free(coorbuf) Do not call G_free_tokens(tokens) outside of the loop if G_free(tokens) is called inside. I do not have LL point data to check this. If you need some projected data to test that both cases work, I can provide a few megabyte sample set. Memory usage in this function should not be more than a few KB, and should not depend on the number of points imported -------------------------------------------- Managed by Request Tracker From michael.barton at asu.edu Sat Jul 1 01:11:00 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sat Jul 1 01:11:12 2006 Subject: [GRASS-dev] can't get NVIZ to run In-Reply-To: <37336858-7AB0-43BD-A300-D70EA88D93DA@kyngchaos.com> Message-ID: I just corresponded with Lorenzo a couple of days ago and NVIZ still is not running on Intel Macs. He can copy you the error he gets. 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: Fri, 30 Jun 2006 13:09:49 -0500 > To: > Subject: [GRASS-dev] can't get NVIZ to run > > Right now: Mac OS X 10.4.6 Intel and PPC, GCC 4.0.1, GRASS 6.1 CVS > 06-6-24 snapshot. It's my own build, not Lorenzo's binaries. TclTk > 8.4.13, it IS an X11 build. GRASS built with X, opengl, but without > glw and motif (those shouldn't affect nviz). I think Lorenzo has > NVIZ working, so I'm not sure if it's a bug yet (and different from a > few other crashing nviz bugs already reported), or just that I'm > doing something wrong (in build or run stage). From grass-bugs at intevation.de Sat Jul 1 03:53:13 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sat Jul 1 03:53:14 2006 Subject: [GRASS-dev] [bug #4770] (grass) fdf Message-ID: <20060701015313.992451005C5@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4770 ------------------------------------------------------------------------- Subject: fdf 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 Sat Jul 1 03:54:13 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sat Jul 1 03:54:15 2006 Subject: [GRASS-dev] [bug #4771] (grass) fsdf Message-ID: <20060701015413.3CBD81005C5@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4771 ------------------------------------------------------------------------- Subject: fsdf grass binary for platform: Downloaded precompiled Binaries 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 dassau at gdf-hannover.de Sat Jul 1 10:24:31 2006 From: dassau at gdf-hannover.de (Otto Dassau) Date: Sat Jul 1 10:24:34 2006 Subject: [GRASS-dev] change permissions for mapsets In-Reply-To: <17573.16491.740296.330941@cerise.gclements.plus.com> References: <200606301219.40581.dassau@gdf-hannover.de> <17573.16491.740296.330941@cerise.gclements.plus.com> Message-ID: Dear Glynn > Otto Dassau wrote: > >> I have a question about g.access. >> >> When I try to change permissions for mapset PERMANENT, it does not work: >> -> access to PERMANENT must be open, nothing changed >> >> when I try to change permissions for another mapset test, it works: >> -> Everyone now has access to mapset test >> >> Does this mean, that I cannot use mapset PERMANENT together with other users? >> Or how can I resolve/change this? > > A few notes: > > 1. You cannot select a mapset as the current mapset (where any new > maps will be created) unless you own the mapset directory; having > write permission isn't sufficient. does this mean, only one user (the owner of a mapset) can create new maps in 'his/her' mapset? So if I want another user to have write permissions I would have to change the owner of the mapset directory. for example: I work in a project (mapset) and during my holliday another user shall keep on working for me. If I don't want to create an extra mapset, because I will be back in a couple of weeks and don't want to have all data and results split in 2 mapsets, I could change the owner of the mapset. Is this correct? > 2. To change the permissions for a mapset, you have to own the mapset > directory. ok - I understand, and g.access is only to restrict read and execute access (as written in the manual). > 3. No-one should ever have the PERMANENT mapset as their current > mapset. GRASS doesn't actually enforce this, although it probably > should. yes, that would be fine - I think. thanks a lot for your notes! Otto > -- > Glynn Clements > From glynn at gclements.plus.com Sat Jul 1 20:46:30 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jul 1 20:46:37 2006 Subject: [GRASS-dev] [bug #4757] (grass) lib/gis/done_msg.c fails In-Reply-To: <20060630165819.GF30552@bartok.itc.it> References: <20060628133715.3A838100160@lists.intevation.de> <17570.47207.675273.355721@cerise.gclements.plus.com> <20060630165819.GF30552@bartok.itc.it> Message-ID: <17574.49926.675610.854660@cerise.gclements.plus.com> Markus Neteler wrote: > > > this bug's URL: http://intevation.de/rt/webrt?serial_num=4757 > > > ------------------------------------------------------------------------- > > > > > > Subject: lib/gis/done_msg.c fails > > > > > > grass obtained from: CVS > > > grass binary for platform: Compiled from Sources > > > > > > Hi, > > > > > > both getlogin() and G_whoami() fail in lib/gis/done_msg.c. > > > It is not clear to me why these functions are needed at all. > > > > I suspect that it's to handle the situation where you start a job in > > the background, log out, someone else logs in, your background job > > completes and writes the completion message to the terminal. > > > > This doesn't actually work on Linux, but I can't find any > > documentation which addresses this situation. There isn't any > > fundamental reason why a process which has a descriptor for the > > terminal can't continue to use the terminal after you've logged out. > > > > The code in G_done_msg() checks whether the user running the process > > (as determined by G_whoami()) is the same as the user who is listed in > > the utmp file as being logged in on the terminal. > > > > IMHO, getting rid of that check is unlikely to have any adverse > > consequences in real use. > > not sure if I interprete your opinion correctly: > Approval for the proposed minimization of lib/gis/done_msg.c? Yes. -- Glynn Clements From glynn at gclements.plus.com Sat Jul 1 20:58:24 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jul 1 20:58:28 2006 Subject: [GRASS-dev] portable.h alternatives? [was: include/portable.h?] In-Reply-To: <3960FEBA-B5C5-476C-859B-58651DA2A6E5@kyngchaos.com> References: <20060630155259.GA30552@bartok.itc.it> <3960FEBA-B5C5-476C-859B-58651DA2A6E5@kyngchaos.com> Message-ID: <17574.50640.136871.244152@cerise.gclements.plus.com> William Kyngesburye wrote: > Speaking of portable.h, I had to mess with this recently so I could > get a Universal Mac binary. It involves saving a copy configured on > both platforms and creating a custom portable.h which is > conditionalized on __BIG_ENDIAN__ (an OS X compiler def). > > Would it be possible to somehow make this so it doesn't need to be > generated at compile time? or make it cross-compiler friendly? Or > maybe there is already an option for that? Or some other way of > handling this architecture endian/size thing. Something to make a > Universal build on OS X simpler. Other than getting the universal > build flags in the right place, this is the main sticky point for an > easy universal build. The ideal solution would be to re-write portable.c so that it doesn't depend upon the host's byte order; i.e. [de]serialize in the correct byte-order to start with, rather than assuming that the host's byte-order matches that of the file then "byte-swap" if it doesn't. Alternatively, most of portable.h could be generated by the configure script, using the AC_CHECK_SIZEOF and AC_C_BIGENDIAN macros. However, the latter only accounts for the simple cases; it doesn't handle mixed-endian architectures (primarily some ARM-based platforms; I don't think that the PDP-11 needs to be supported). -- Glynn Clements From glynn at gclements.plus.com Sat Jul 1 21:01:06 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jul 1 21:01:10 2006 Subject: [GRASS-dev] [bug #4768] (grass) nviz segfault on startup when creating display window In-Reply-To: <20060630180943.25CD01006CF@lists.intevation.de> References: <20060630180943.25CD01006CF@lists.intevation.de> Message-ID: <17574.50802.653486.173288@cerise.gclements.plus.com> Request Tracker wrote: > this bug's URL: http://intevation.de/rt/webrt?serial_num=4768 > ------------------------------------------------------------------------- > > Subject: nviz segfault on startup when creating display window > > Platform: Mac OSX > grass obtained from: Trento Italy site > grass binary for platform: Compiled from Sources > GRASS Version: CVS 2006_06_24 > > Even with a simple quickstart: nviz -q, nviz is crashing with a segfault when it tries to create the > output window. From the OSX crashlog: > > Exception: EXC_BAD_ACCESS (0x0001) > Codes: KERN_INVALID_ADDRESS (0x0001) at 0x5c637273 > > Thread 0 Crashed: > 0 libX11.6.dylib 0x9bd35fa1 XQueryExtension + 24 > 1 libGL.1.dylib 0x9be2edab glXQueryExtension + 62 > 2 nviz 0x000115eb Togl_CreateWindow + 56 > 3 com.tcltk.tklibrary 0x9ad191ad Tk_MakeWindowExist + 120 > 4 nviz 0x000126a3 Togl_Cmd + 1046 > 5 com.tcltk.tcllibrary 0x9ac181a3 TclInvokeStringCommand + 121 > 6 com.tcltk.tcllibrary 0x9ac1a915 TclEvalObjvInternal + 733 > 7 com.tcltk.tcllibrary 0x9ac3d666 TclExecuteByteCode + 3101 > 8 com.tcltk.tcllibrary 0x9ac4244e TclCompEvalObj + 279 > 9 com.tcltk.tcllibrary 0x9ac6926d TclObjInterpProc + 524 > 10 com.tcltk.tcllibrary 0x9ac1a915 TclEvalObjvInternal + 733 > 11 com.tcltk.tcllibrary 0x9ac1ac1c Tcl_EvalEx + 488 > 12 com.tcltk.tcllibrary 0x9ac5893a Tcl_FSEvalFile + 400 > 13 com.tcltk.tcllibrary 0x9ac1a915 TclEvalObjvInternal + 733 > 14 com.tcltk.tcllibrary 0x9ac1ac1c Tcl_EvalEx + 488 > 15 com.tcltk.tcllibrary 0x9ac1b03a Tcl_Eval + 42 > 16 nviz 0x0000cac0 Ninit + 199 > 17 nviz 0x00002614 NVIZ_AppInit + 210 > 18 com.tcltk.tklibrary 0x9acef2eb Tk_MainEx + 761 > 19 nviz 0x000111ca main + 97 > 20 nviz 0x000024ea _start + 228 (crt.c:272) > 21 nviz 0x00002405 start + 41 > > If I add an elevation raster from spearfish6 demo, it shows some status, then crashes with the same > thread trace when trying to create the window. This is a bug in the system's OpenGL implementation; there isn't anything we can do about it. -- Glynn Clements From glynn at gclements.plus.com Sat Jul 1 21:04:52 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jul 1 21:04:57 2006 Subject: [GRASS-dev] change permissions for mapsets In-Reply-To: References: <200606301219.40581.dassau@gdf-hannover.de> <17573.16491.740296.330941@cerise.gclements.plus.com> Message-ID: <17574.51028.765758.644667@cerise.gclements.plus.com> Otto Dassau wrote: > > 1. You cannot select a mapset as the current mapset (where any new > > maps will be created) unless you own the mapset directory; having > > write permission isn't sufficient. > > does this mean, only one user (the owner of a mapset) can create > new maps in 'his/her' mapset? Yes. > So if I want another user to have write permissions I would have to > change the owner of the mapset directory. Yes. > for example: > > I work in a project (mapset) and during my holliday another user shall > keep on working for me. If I don't want to create an extra mapset, because > I will be back in a couple of weeks and don't want to have all data and > results split in 2 mapsets, I could change the owner of the mapset. Is > this correct? Yes. -- Glynn Clements From woklist at kyngchaos.com Sat Jul 1 21:07:15 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Sat Jul 1 21:07:20 2006 Subject: [GRASS-dev] portable.h alternatives? [was: include/portable.h?] In-Reply-To: <17574.50640.136871.244152@cerise.gclements.plus.com> References: <20060630155259.GA30552@bartok.itc.it> <3960FEBA-B5C5-476C-859B-58651DA2A6E5@kyngchaos.com> <17574.50640.136871.244152@cerise.gclements.plus.com> Message-ID: <86A6F558-EC90-4D95-9921-D89B4FA6876C@kyngchaos.com> On Jul 1, 2006, at 1:58 PM, Glynn Clements wrote: > The ideal solution would be to re-write portable.c so that it doesn't > depend upon the host's byte order; i.e. [de]serialize in the correct > byte-order to start with, rather than assuming that the host's > byte-order matches that of the file then "byte-swap" if it doesn't. > Maybe I should add a wish for this? Or could you, since you seem to understand what to ask for? This is the only place I've found in GRASS right now with endian- dependent code. Could something like this make it into the 6.2 release? ----- William Kyngesburye http://www.kyngchaos.com/ "Those people who most want to rule people are, ipso-facto, those least suited to do it." - A rule of the universe, from the HitchHiker's Guide to the Galaxy From grass-bugs at intevation.de Sat Jul 1 22:29:39 2006 From: grass-bugs at intevation.de (Markus Neteler via RT) Date: Sat Jul 1 22:29:41 2006 Subject: [GRASS-dev] [bug #4747] (grass) v.to.points: G_percent() is missing Message-ID: <20060701202939.E54D21005B9@lists.intevation.de> Hi, this is an issue in the underlying Vect_build (&Out, stderr); function - so several modules should be affected. No idea how to fix that... Markus -------------------------------------------- Managed by Request Tracker From soerengebbert at gmx.de Sun Jul 2 21:16:00 2006 From: soerengebbert at gmx.de (Soeren Gebbert) Date: Sun Jul 2 21:16:05 2006 Subject: [GRASS-dev] v.in.dxf patch Message-ID: <200607022116.00718.soerengebbert@gmx.de> Dear devs, i noticed a strange behaviour of v.in.dxf while implementing some new vector tests for the grass-test-suite. v.in.dxf was not able to import dxf files created with v.out.dxf. No error message was printed and v.in.dxf automatically removed the created vector?! I am not sure if this is a bug, because i have no "real" dxf data to test this, but i have attached a patch which adds * a error message before deleting the corrupted vector file * a small if check -> which allows to import files created with v.out.dxf. I will submit this patch to CVS in the next week if this is ok for you. Best regards Soeren -------------- next part -------------- A non-text attachment was scrubbed... Name: v.in.dxf_soeren_patch.diff Type: text/x-diff Size: 1010 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060702/e10747fe/v.in.dxf_soeren_patch-0001.bin From michael.barton at asu.edu Sun Jul 2 21:45:11 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sun Jul 2 21:46:19 2006 Subject: [GRASS-dev] [bug #4768] (grass) nviz segfault on startup when creating display window In-Reply-To: <17574.50802.653486.173288@cerise.gclements.plus.com> Message-ID: Should people using Intel Macs install a different version of OpenGL? 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: Glynn Clements > Date: Sat, 1 Jul 2006 20:01:06 +0100 > To: Request Tracker > Cc: > Subject: Re: [GRASS-dev] [bug #4768] (grass) nviz segfault on startup when > creating display window > >> >> If I add an elevation raster from spearfish6 demo, it shows some status, then >> crashes with the same >> thread trace when trying to create the window. > > This is a bug in the system's OpenGL implementation; there isn't > anything we can do about it. From woklist at kyngchaos.com Sun Jul 2 22:35:09 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Sun Jul 2 22:35:20 2006 Subject: [GRASS-dev] Re: [bug #4768] (grass) nviz segfault on startup when In-Reply-To: <20060702194620.CD77D1006A0@lists.intevation.de> References: <20060702194620.CD77D1006A0@lists.intevation.de> Message-ID: It should be the same version on Intel as on PPC. The Intel installed copy is just universal, while the PPC installed copy is PPC only. I don't want to have to mess with OpenGL - Apple's X11 build of OpenGL taps into the system OpenGL framework (at least it's in the lib dependencies from otool -L), so it could be tricky. (Note: I haven't had a chance to test the universal build on PPC yet. I'll try to remember Monday.) I'll look into finding some OpenGL test programs to try. Try to be more sure if it's and OpenGL or Apple problem, or PPC vs Intel, or something I'm doing wrong. Also, I'll look at the Togl demos, since this is a new version of Togl. On Jul 2, 2006, at 2:46 PM, Michael Barton via RT wrote: > Should people using Intel Macs install a different version of OpenGL? > > Michael ----- William Kyngesburye http://www.kyngchaos.com/ "This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind?" - The Ruler of the Universe From neteler at itc.it Mon Jul 3 00:09:04 2006 From: neteler at itc.it (Markus Neteler) Date: Mon Jul 3 00:09:06 2006 Subject: [GRASS-dev] v.rast.stats speedup Message-ID: <20060702220904.GA25418@bartok.itc.it> Hi, I have modified v.rast.stats to work much faster when not using DBF driver (maybe my patch would work for that as well). Please test. The SQLITE NULL/nan bug got also fixed. Markus From grass4u at gmail.com Mon Jul 3 02:35:49 2006 From: grass4u at gmail.com (Huidae Cho) Date: Mon Jul 3 02:38:38 2006 Subject: [GRASS-dev] v.in.dxf patch In-Reply-To: <200607022116.00718.soerengebbert@gmx.de> References: <200607022116.00718.soerengebbert@gmx.de> Message-ID: <20060703003549.GA2473@localhost> Hi, This is a bug and I've fixed it. Thank you. Huidae Cho On Sun, Jul 02, 2006 at 09:16:00PM +0200, Soeren Gebbert wrote: > Dear devs, > i noticed a strange behaviour of v.in.dxf while implementing > some new vector tests for the grass-test-suite. > > v.in.dxf was not able to import dxf files created with v.out.dxf. > No error message was printed and v.in.dxf automatically removed > the created vector?! > > I am not sure if this is a bug, because i have no "real" dxf data to test > this, but i have attached a patch which adds > * a error message before deleting the corrupted vector file > * a small if check -> which allows to import files created with v.out.dxf. > > I will submit this patch to CVS in the next week if this is ok for you. > > Best regards > Soeren > Index: dxf_to_vect.c > =================================================================== > RCS file: /home/grass/grassrepository/grass6/vector/v.in.dxf/dxf_to_vect.c,v > retrieving revision 1.16 > diff -u -u -r1.16 dxf_to_vect.c > --- dxf_to_vect.c 8 Jun 2006 00:48:38 -0000 1.16 > +++ dxf_to_vect.c 2 Jul 2006 18:41:13 -0000 > @@ -81,6 +81,8 @@ > while ((code = dxf_get_code(dxf)) != 9) { > if (code == -2) /* EOF */ > return -1; > + if (code == 0) /* End of the header section */ > + break; > } > } > > Index: main.c > =================================================================== > RCS file: /home/grass/grassrepository/grass6/vector/v.in.dxf/main.c,v > retrieving revision 1.35 > diff -u -u -r1.35 main.c > --- main.c 12 Jun 2006 05:42:40 -0000 1.35 > +++ main.c 2 Jul 2006 18:41:13 -0000 > @@ -179,6 +179,7 @@ > } > } > else { > + G_warning("Something strange happened! The created vector is corrupted and will be deleted."); > fprintf(stderr, "REMOVE [%s]\n", output); > Vect_delete(output); > } > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From hamish_nospam at yahoo.com Mon Jul 3 05:33:10 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jul 3 05:33:25 2006 Subject: [GRASS-dev] change permissions for mapsets In-Reply-To: <17573.16491.740296.330941@cerise.gclements.plus.com> References: <200606301219.40581.dassau@gdf-hannover.de> <17573.16491.740296.330941@cerise.gclements.plus.com> Message-ID: <20060703153310.01fc4ced.hamish_nospam@yahoo.com> Glynn Clements wrote: > 3. No-one should ever have the PERMANENT mapset as their current > mapset. GRASS doesn't actually enforce this, although it probably > should. It is useful to occasionally drop into the PERMANENT to use "g.copy perm_map,map@other_mapset", so that a base map will be available to all mapsets without qualification or risk of accidental damage. Maybe add a "are you sure you want to do this?" dialogue window to the GUI startup menu if the PERMANENT mapset is selected. Hamish From hamish_nospam at yahoo.com Mon Jul 3 05:38:33 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jul 3 05:38:41 2006 Subject: [GRASS-dev] change permissions for mapsets In-Reply-To: References: <200606301219.40581.dassau@gdf-hannover.de> <17573.16491.740296.330941@cerise.gclements.plus.com> Message-ID: <20060703153833.1bae5ad2.hamish_nospam@yahoo.com> Otto Dassau wrote: > I work in a project (mapset) and during my holliday another user shall > keep on working for me. If I don't want to create an extra mapset, > because I will be back in a couple of weeks and don't want to have > all data and results split in 2 mapsets, I could change the owner of > the mapset. Is this correct? you could do that. But fetching maps from other mapsets in the same location is very easy: # select "map1" from the "otto" mapset: (if g.access permission is granted) r.univar map1@otto # copy a map from another mapset back to your mapset for modification: g.copy map2@other,map2 Hamish From neteler at itc.it Mon Jul 3 08:46:22 2006 From: neteler at itc.it (Markus Neteler) Date: Mon Jul 3 08:46:24 2006 Subject: [GRASS-dev] Vectlib: delete broken vectors upon creation failure? In-Reply-To: <20060703003532.A6EE61006A7@lists.intevation.de> References: <20060703003532.A6EE61006A7@lists.intevation.de> Message-ID: <20060703064622.GB28230@bartok.itc.it> Hi, Huidae had added the nice feature in v.in.dxf (now functional, I guess) that a broken vector map is immediately removed when import wasn't successful and is not left behind. This is an issue which affects various modules. I think we should add this somehow to the vector library since broken vector maps aren't really useful. The tmp file approach of raster maps is more failsafe here. Since tmp doesn't exist for vector maps, any ideas how to implement that? At least v.in.ascii needs it, maybe also v.in.ogr. Markus On Mon, Jul 03, 2006 at 02:35:32AM +0200, grass@intevation.de wrote: > Index: main.c > =================================================================== > RCS file: /grassrepository/grass6/vector/v.in.dxf/main.c,v > retrieving revision 1.35 > retrieving revision 1.36 > diff -u -d -r1.35 -r1.36 > --- main.c 12 Jun 2006 05:42:40 -0000 1.35 > +++ main.c 3 Jul 2006 00:35:30 -0000 1.36 > @@ -179,6 +179,8 @@ > } > } > else { > + G_warning(_ > + ("Failed to import DXF file! The created vector file will be deleted.")); > fprintf(stderr, "REMOVE [%s]\n", output); > Vect_delete(output); > } From neteler at itc.it Mon Jul 3 09:21:19 2006 From: neteler at itc.it (Markus Neteler) Date: Mon Jul 3 09:21:21 2006 Subject: [GRASS-dev] Re: v.rast.stats speedup In-Reply-To: <20060702220904.GA25418@bartok.itc.it> References: <20060702220904.GA25418@bartok.itc.it> Message-ID: <20060703072119.GA28470@bartok.itc.it> Hi, now done for the DBF driver as well. Also faster :-) Markus On Mon, Jul 03, 2006 at 12:09:04AM +0200, Markus Neteler wrote: > Hi, > > I have modified v.rast.stats to work much faster when not > using DBF driver (maybe my patch would work for that as > well). > > Please test. > The SQLITE NULL/nan bug got also fixed. > > Markus From grass4u at gmail.com Mon Jul 3 12:27:00 2006 From: grass4u at gmail.com (Huidae Cho) Date: Mon Jul 3 12:29:43 2006 Subject: [GRASS-dev] Vectlib: delete broken vectors upon creation failure? In-Reply-To: <20060703064622.GB28230@bartok.itc.it> References: <20060703003532.A6EE61006A7@lists.intevation.de> <20060703064622.GB28230@bartok.itc.it> Message-ID: <20060703102318.GA7404@localhost> Is there any way to know from the library if a map has not been completely imported? IMHO, incomplete import is different from corrupted files (well sometimes it could mean broken vectors), so only modules importing files can determine to remove incomplete vectors. Huidae Cho On Mon, Jul 03, 2006 at 08:46:22AM +0200, Markus Neteler wrote: > Hi, > > Huidae had added the nice feature in v.in.dxf (now functional, I guess) > that a broken vector map is immediately removed when import wasn't > successful and is not left behind. > > This is an issue which affects various modules. I think we should > add this somehow to the vector library since broken vector maps > aren't really useful. The tmp file approach of raster maps is > more failsafe here. Since tmp doesn't exist for vector maps, > any ideas how to implement that? > At least v.in.ascii needs it, maybe also v.in.ogr. > > Markus > > > On Mon, Jul 03, 2006 at 02:35:32AM +0200, grass@intevation.de wrote: > > Index: main.c > > =================================================================== > > RCS file: /grassrepository/grass6/vector/v.in.dxf/main.c,v > > retrieving revision 1.35 > > retrieving revision 1.36 > > diff -u -d -r1.35 -r1.36 > > --- main.c 12 Jun 2006 05:42:40 -0000 1.35 > > +++ main.c 3 Jul 2006 00:35:30 -0000 1.36 > > @@ -179,6 +179,8 @@ > > } > > } > > else { > > + G_warning(_ > > + ("Failed to import DXF file! The created vector file will be deleted.")); > > fprintf(stderr, "REMOVE [%s]\n", output); > > Vect_delete(output); > > } > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From jachym.cepicky at centrum.cz Mon Jul 3 15:56:52 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Mon Jul 3 15:58:57 2006 Subject: [GRASS-dev] v.in.ogr where Message-ID: <20060703135651.GB8139@localdomain> Hallo, I wonder, how complicated would be to implement option where= in v.in.ogr, so one could import e.g. only part of postgis table to GRASS. Currently you have to import the whole table and run v.select on it, which takes too much time and system resources. Could anybody point me to example, how to do thing like this or, better, could anybody implement it :-) ? Thanks and have a nice day Jachym -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc ----------------------------------------- OFFICE: GDF-Hannover Mengendamm 16d 30177 Hannover Germany e-mail: cepicky@gdf-hannover.de URL: http://gdf-hannover.de Tel.: +49 511-39088507 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060703/e65256a1/attachment.bin From neteler at itc.it Mon Jul 3 16:42:04 2006 From: neteler at itc.it (Markus Neteler) Date: Mon Jul 3 16:42:05 2006 Subject: [GRASS-dev] v.in.ogr where In-Reply-To: <20060703135651.GB8139@localdomain> References: <20060703135651.GB8139@localdomain> Message-ID: <20060703144204.GG19781@bartok.itc.it> On Mon, Jul 03, 2006 at 03:56:52PM +0200, Jachym Cepicky wrote: > Hallo, > I wonder, how complicated would be to implement option where= in v.in.ogr, so one could import e.g. only part of > postgis table to GRASS. Done. :-) Enjoy, Markus From glynn at gclements.plus.com Mon Jul 3 17:42:02 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jul 3 17:48:16 2006 Subject: [GRASS-dev] [bug #4768] (grass) nviz segfault on startup when creating display window In-Reply-To: References: <17574.50802.653486.173288@cerise.gclements.plus.com> Message-ID: <17577.15050.536867.787160@cerise.gclements.plus.com> Michael Barton wrote: > >> If I add an elevation raster from spearfish6 demo, it shows some status, then > >> crashes with the same > >> thread trace when trying to create the window. > > > > This is a bug in the system's OpenGL implementation; there isn't > > anything we can do about it. > > Should people using Intel Macs install a different version of OpenGL? It's worth a try. Even if nothing else works, Mesa should (although it will be a lot slower). -- Glynn Clements From glynn at gclements.plus.com Mon Jul 3 17:52:09 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jul 3 17:52:10 2006 Subject: [GRASS-dev] Vectlib: delete broken vectors upon creation failure? In-Reply-To: <20060703064622.GB28230@bartok.itc.it> References: <20060703003532.A6EE61006A7@lists.intevation.de> <20060703064622.GB28230@bartok.itc.it> Message-ID: <17577.15657.3339.442913@cerise.gclements.plus.com> Markus Neteler wrote: > Huidae had added the nice feature in v.in.dxf (now functional, I guess) > that a broken vector map is immediately removed when import wasn't > successful and is not left behind. > > This is an issue which affects various modules. I think we should > add this somehow to the vector library since broken vector maps > aren't really useful. The tmp file approach of raster maps is > more failsafe here. Since tmp doesn't exist for vector maps, > any ideas how to implement that? SQL transactions, on back-ends which support them. -- Glynn Clements From woklist at kyngchaos.com Mon Jul 3 18:11:26 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Jul 3 18:11:39 2006 Subject: [GRASS-dev] Re: [bug #4768] (grass) nviz segfault on startup when In-Reply-To: References: <20060702194620.CD77D1006A0@lists.intevation.de> Message-ID: > Also, I'll look at the Togl demos, since this is a new version of > Togl. Togl built separately for OSX X11 - demos work, within limits. double, gears and texture demos work. stereo, index and overlay demos do not. According to the Togl docs, stereo and overlay features of Togl require hardware support for them, on higher-end graphics cards (and not even 'gaming' cards). I'm running this on a MacBook, with the Intel GMA 950 integrated graphics. Maybe not up-to- snuff. Does NVIZ use any of these features of Togl? The Togl docs don't say anything about the index demo, but it fails with the same BadWindow/invalid window parameter error of the stereo demo, so it might be a similar hardware feature. > Note: I haven't had a chance to test the universal build on PPC > yet. I'll try to remember Monday. I have the same errors starting NVIZ on a PPC Mac (Tiger). ----- William Kyngesburye http://www.kyngchaos.com/ All generalizations are dangerous, even this one. From michael.barton at asu.edu Mon Jul 3 18:35:20 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Jul 3 18:37:23 2006 Subject: [GRASS-dev] Re: gis.m issues In-Reply-To: <20060629030407.3b5c2028.hamish_nospam@yahoo.com> Message-ID: Hamish, See below. 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: Hamish > Date: Thu, 29 Jun 2006 03:04:07 +1200 > To: Michael Barton > Cc: > Subject: gis.m issues > > some GIS.m / menu.tcl issues: > > * launch r.digit from gis.m menu with no Map Display open leads to a > error. This is a problem with r.digit. It won't start up in an xterm. I can't get it to start in an xterm from the command line either--xterm -e r.digit just starts the TclTk gui. It flashes a small dialog that disappears too quickly for me to read. Other commands like i.points start up fine in an xterm. So I don't know what is wrong. There is a different issue with d.rast.edit in that it wants to have a map displayed in an xmon, but there is not place to specify the map (i.e., you must open it separately using d.rast). > > * d.font in menu.tcl has "execute term d.font" which is wrong. then > complains about can't get socket.. it is looking for an active x > monitor? This doesn't actually need a term at all? fixed > > * g.access. Does this really need to run in a term? fixed > > * g.gisenv: change to run_panel? currently it runs with "--ui" which > kills output. if run_panel you can't edit, add a second menu item for > that? fixed. I did 2 menu entries: one to show current settings and the other to change settings. > > * g.region -p, g.version -c are broken. Move g.version to help menu? fixed > > > > Hamish From neteler at itc.it Mon Jul 3 18:41:12 2006 From: neteler at itc.it (Markus Neteler) Date: Mon Jul 3 18:41:14 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation Message-ID: <20060703164112.GN19781@bartok.itc.it> Hi developers, I think that the current GRASS 6.1-CVS is in a good condition to be released as GRASS 6.1.0. This will pave the way for GRASS 6.2.0 (stable) which may follow shortly. I would suggest to branch off a 6.1.0 branch in CVS to not kill momentum in the HEAD. Important fixes can then be merged if needed. From that branch we get out one or two beta tarballs, then release candidates and finally the 6.1.0 version. If there are no objections, I'll branch right away. Development continues in HEAD as before and we can extract a first 6.1.0beta for packagers and testers. Further discussion: * The x11-less GRASS can be developed in HEAD, we should not wait for that. We can have 6.1.1 if desired in near future. The same applies to the georectifier. * NVIZ/Mac issues we can port from HEAD if they get fixed. Apparently it's more related to openGL than GRASS. * snprintf(): much discussion, no result. We can backport once it happens. * other open issues which are *really* showstoppers for a 6.1.0 unstable release? An announcement is drafted at http://grass.itc.it/announces/announce_grass610.html The list of changes should be almost up to date, please review and add missing items. Also the wording of the first part could be more press release like. Markus -- Markus Neteler http://mpa.itc.it/markus/ ITC-irst - Centro per la Ricerca Scientifica e Tecnologica MPBA - Predictive Models for Biol. & Environ. Data Analysis Via Sommarive, 18 - 38050 Povo (Trento), Italy From cavallini at faunalia.it Mon Jul 3 19:03:05 2006 From: cavallini at faunalia.it (Paolo Cavallini) Date: Mon Jul 3 19:03:07 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: <20060703164112.GN19781@bartok.itc.it> References: <20060703164112.GN19781@bartok.itc.it> Message-ID: <44A94DC9.2050206@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I strongly support the proposal. Current stable grass is quite old, and users must have access to all the new and fancy new features. All the best. pc Markus Neteler wrote: > Hi developers, > ... - -- Paolo Cavallini email+jabber: cavallini@faunalia.it www.faunalia.it Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEqU3J/NedwLUzIr4RAsr0AKC6oovk33Oa2Pg4sGEriGoDAfcoKgCgtqW+ iDKk/oejoCugpG9/bukK+DU= =yBos -----END PGP SIGNATURE----- From woklist at kyngchaos.com Mon Jul 3 19:37:36 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Jul 3 19:37:48 2006 Subject: [GRASS-dev] Re: [bug #4768] (grass) nviz segfault on startup when In-Reply-To: References: <20060702194620.CD77D1006A0@lists.intevation.de> Message-ID: <187BA839-A9FC-4FB0-907E-F06DA8F19E48@kyngchaos.com> I've tried a couple things, and I can think of 2 possibilities: - since togl demos work, possibly there is something wrong with the window NVIZ is trying to setup. I tried removing the togl glXQueryExtension test to force it to assume that glX is OK - it got further, but failed later when X11 wanted to test that on its own: 0 libX11.6.dylib 0x9b4bdfa1 XQueryExtension + 24 1 libX11.6.dylib 0x9b4b4fb1 XInitExtension + 47 2 libXext.6.dylib 0x9b49aec9 XextAddDisplay + 64 3 libGL.1.dylib 0x9b5b9c2a __glXFindDisplay + 116 4 libGL.1.dylib 0x9b5ba304 __glXInitialize + 25 5 libGL.1.dylib 0x9b5b6b23 GetGLXPrivScreenConfig + 27 6 libGL.1.dylib 0x9b5b78a9 glXChooseVisual + 38 7 nviz 0x00011a31 Togl_CreateWindow + 1070 I also tried linking in my test installed togl, instead of using the included togl in the nviz source - same errors. - There is something wrong with glX in Apple's X11 that only shows up (so far) with NVIZ. I need to find some OpenGL demos that use glX, next. ----- William Kyngesburye http://www.kyngchaos.com/ "History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history." - Hitchhiker's Guide to the Galaxy From grass-bugs at intevation.de Mon Jul 3 19:47:36 2006 From: grass-bugs at intevation.de (Paul Kelly via RT) Date: Mon Jul 3 19:47:38 2006 Subject: [GRASS-dev] [bug #4764] (grass) Give NetBSD a distinct configuration section in aclocal.m4. Message-ID: <20060703174736.8B1181005B9@lists.intevation.de> This seems like a good idea and I can't see it causing any problems, but to reduce the chance of any errors (as I won't be able to test this) could you supply the patch against the current CVS version of aclocal.m4 please? Download from here: http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass6/aclocal.m4 Paul -------------------------------------------- Managed by Request Tracker From neteler at itc.it Mon Jul 3 23:11:13 2006 From: neteler at itc.it (Markus Neteler) Date: Mon Jul 3 23:11:14 2006 Subject: [GRASS-dev] GRASS 6.1: wxPython GUI/XML submitted Message-ID: <20060703211112.GB6539@bartok.itc.it> Hi, I have just submitted the slightly updated wxPython GUI from old GRASS 5 (by J Wagner, B Reiter): cd grass61/gui/wxpython r.info --interface-description | python grassgui.py ... pops up a nice GUI (also Asian characters work). The grassgui.py contains the relevant XML parsing stuff which could be the seed for a new GRASS 6 Python class. Thanks to Jachym for figuring out the tricks, Markus -- Markus Neteler http://mpa.itc.it/markus/ ITC-irst - Centro per la Ricerca Scientifica e Tecnologica MPBA - Predictive Models for Biol. & Environ. Data Analysis Via Sommarive, 18 - 38050 Povo (Trento), Italy From neteler at itc.it Tue Jul 4 00:01:45 2006 From: neteler at itc.it (Markus Neteler) Date: Tue Jul 4 00:01:46 2006 Subject: [GRASS-dev] Vectlib: delete broken vectors upon creation failure? In-Reply-To: <20060703102318.GA7404@localhost> References: <20060703003532.A6EE61006A7@lists.intevation.de> <20060703064622.GB28230@bartok.itc.it> <20060703102318.GA7404@localhost> Message-ID: <20060703220144.GB6838@bartok.itc.it> On Mon, Jul 03, 2006 at 05:27:00AM -0500, Huidae Cho wrote: > Is there any way to know from the library if a map has not been completely > imported? IMHO, incomplete import is different from corrupted files (well > sometimes it could mean broken vectors), so only modules importing files can > determine to remove incomplete vectors. OK. I have added a couple of Vect_delete() calls to v.in.ascii before G_fatal_error() happens. Like this cruft is removed before the error message appears. Markus > Huidae Cho > > > On Mon, Jul 03, 2006 at 08:46:22AM +0200, Markus Neteler wrote: > > Hi, > > > > Huidae had added the nice feature in v.in.dxf (now functional, I guess) > > that a broken vector map is immediately removed when import wasn't > > successful and is not left behind. > > > > This is an issue which affects various modules. I think we should > > add this somehow to the vector library since broken vector maps > > aren't really useful. The tmp file approach of raster maps is > > more failsafe here. Since tmp doesn't exist for vector maps, > > any ideas how to implement that? > > At least v.in.ascii needs it, maybe also v.in.ogr. > > > > Markus > > > > > > On Mon, Jul 03, 2006 at 02:35:32AM +0200, grass@intevation.de wrote: > > > Index: main.c > > > =================================================================== > > > RCS file: /grassrepository/grass6/vector/v.in.dxf/main.c,v > > > retrieving revision 1.35 > > > retrieving revision 1.36 > > > diff -u -d -r1.35 -r1.36 > > > --- main.c 12 Jun 2006 05:42:40 -0000 1.35 > > > +++ main.c 3 Jul 2006 00:35:30 -0000 1.36 > > > @@ -179,6 +179,8 @@ > > > } > > > } > > > else { > > > + G_warning(_ > > > + ("Failed to import DXF file! The created vector file will be deleted.")); > > > fprintf(stderr, "REMOVE [%s]\n", output); > > > Vect_delete(output); > > > } > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Markus Neteler http://mpa.itc.it/markus/ ITC-irst - Centro per la Ricerca Scientifica e Tecnologica MPBA - Predictive Models for Biol. & Environ. Data Analysis Via Sommarive, 18 - 38050 Povo (Trento), Italy From michael.barton at asu.edu Tue Jul 4 01:37:37 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jul 4 01:37:44 2006 Subject: [GRASS-dev] internationalization error compiling 6.1cvs 03-04-06 Message-ID: I tried to compile a cvs version of GRASS 6.1 today and it quit in what appears to be an internationalization section. It compiled just fine with the same configuration and dependencies last Friday. I did a make clean and make distclean and reran configure just to make sure. Same results. Here is the error section of the make output. grassmods_tr.po: 1092 translated messages, 226 fuzzy translations, 2046 untranslated messages. grassmods_vi.po: 0 translated messages, 2084 fuzzy translations, 1280 untranslated messages. grassmods_zh.po: 1379 translated messages, 482 fuzzy translations, 1503 untranslated messages. grasstcl_de.po: msgfmt: unrecognized option `--tcl' Try `msgfmt --help' for more information. grasstcl_fr.po: msgfmt: unrecognized option `--tcl' Try `msgfmt --help' for more information. grasstcl_it.po: msgfmt: unrecognized option `--tcl' Try `msgfmt --help' for more information. grasstcl_ja.po: msgfmt: unrecognized option `--tcl' Try `msgfmt --help' for more information. grasstcl_pl.po: msgfmt: unrecognized option `--tcl' Try `msgfmt --help' for more information. grasstcl_pt_br.po: msgfmt: unrecognized option `--tcl' Try `msgfmt --help' for more information. grasstcl_tr.po: msgfmt: unrecognized option `--tcl' Try `msgfmt --help' for more information. grasstcl_vi.po: msgfmt: unrecognized option `--tcl' Try `msgfmt --help' for more information. make[2]: *** [mo] Error 1 make[1]: *** [default] Error 2 make: *** [default] Error 2 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/20060703/1404a796/attachment-0001.html From michael.barton at asu.edu Tue Jul 4 01:53:10 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jul 4 01:53:15 2006 Subject: [GRASS-dev] Re: grass-dev Digest, Vol 3, Issue 4 In-Reply-To: <200607032338.k63Nc8Zm015362@grass.itc.it> Message-ID: This is fine. Can I treat the missing/incorrect RMS calculation as a bug to be fixed as soon as the pieces come together? 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: Reply-To: Date: Tue, 4 Jul 2006 01:38:08 +0200 To: Subject: grass-dev Digest, Vol 3, Issue 4 The same applies to the georectifier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060703/87ea80fb/attachment.html From nicholas.g.lawrence at mainroads.qld.gov.au Tue Jul 4 02:14:27 2006 From: nicholas.g.lawrence at mainroads.qld.gov.au (nicholas.g.lawrence@mainroads.qld.gov.au) Date: Tue Jul 4 02:14:41 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: <20060703164112.GN19781@bartok.itc.it> Message-ID: > An announcement is drafted at > http://grass.itc.it/announces/announce_grass610.html > The list of changes should be almost up to date, please > review and add missing items. Also the wording of the > first part could be more press release like. I notice that the link at Selected Bugfixes (see ChangeLog for details) - Source code quality/libraries: - GRASS is now ANSI C compliant - Ported natively to MS-Windows (MinGW based) ^^^^^^^^^^^^^^^^^^^^^^ Actually points to a page (owned by Markus Neteler) that points to a page for downloading QGIS. nick ************************************************************ Opinions contained in this e-mail do not necessarily reflect the opinions of the Queensland Department of Main Roads, Queensland Transport or Maritime Safety Queensland, or endorsed organisations utilising the same infrastructure. If you have received this electronic mail message in error, please immediately notify the sender and delete the message from your computer. ************************************************************ From hamish_nospam at yahoo.com Tue Jul 4 04:24:39 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jul 4 04:25:17 2006 Subject: [GRASS-dev] Re: gis.m issues In-Reply-To: References: <20060629030407.3b5c2028.hamish_nospam@yahoo.com> Message-ID: <20060704142439.3f42bf74.hamish_nospam@yahoo.com> Michael Barton wrote: > > some GIS.m / menu.tcl issues: > > > > * launch r.digit from gis.m menu with no Map Display open leads to a > > error. > > This is a problem with r.digit. > > It won't start up in an xterm. I can't get it to start in an xterm > from the command line either--xterm -e r.digit just starts the TclTk > gui. It flashes a small dialog that disappears too quickly for me to > read. please update from CVS. now grass-run.sh (lib/init/g-r.src) pauses if the module ends in an error. also r.digit has been changed to never use a startup GUI. > Other commands like i.points start up fine in an xterm. So I don't > know what is wrong. r.digit needs a GIS.m Map Display window open to get region info from. > There is a different issue with d.rast.edit in that it wants to have a > map displayed in an xmon, but there is not place to specify the map > (i.e., you must open it separately using d.rast). we can work on that, either with a bgmap= option or full bgcmd= like v.digit. same issue for r.digit, but I'd rather we leave r.digit alone and focus on a new v.digit/r.digit replacement (write to ascii file on exit then feed to "v.in.ascii format=standard" or r.in.poly). I think it is pretty simple --- but we need to pick a Wx/Gtk Python flavour to move ahead! Hamish From michael.barton at asu.edu Tue Jul 4 05:17:09 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jul 4 05:17:15 2006 Subject: [GRASS-dev] Re: gis.m issues In-Reply-To: <20060704142439.3f42bf74.hamish_nospam@yahoo.com> Message-ID: > From: Hamish > Date: Tue, 4 Jul 2006 14:24:39 +1200 > To: Michael Barton > Cc: > Subject: Re: gis.m issues > > Michael Barton wrote: > >>> some GIS.m / menu.tcl issues: >>> >>> * launch r.digit from gis.m menu with no Map Display open leads to a >>> error. >> >> This is a problem with r.digit. >> >> It won't start up in an xterm. I can't get it to start in an xterm >> from the command line either--xterm -e r.digit just starts the TclTk >> gui. It flashes a small dialog that disappears too quickly for me to >> read. > > please update from CVS. > > now grass-run.sh (lib/init/g-r.src) pauses if the module ends in an > error. > > also r.digit has been changed to never use a startup GUI. I updated at the end of last week. Has it been changed again since then? I tried to update today, but make failed on an internationalization section error (sent to grass-dev this afternoon). > > >> Other commands like i.points start up fine in an xterm. So I don't >> know what is wrong. > > r.digit needs a GIS.m Map Display window open to get region info from. It should be getting this, so I'm not sure what is wrong. > > >> There is a different issue with d.rast.edit in that it wants to have a >> map displayed in an xmon, but there is not place to specify the map >> (i.e., you must open it separately using d.rast). > > we can work on that, either with a bgmap= option or full bgcmd= like > v.digit. > > same issue for r.digit, but I'd rather we leave r.digit alone and focus > on a new v.digit/r.digit replacement (write to ascii file on exit then > feed to "v.in.ascii format=standard" or r.in.poly). I agree > I think it is pretty > simple --- but we need to pick a Wx/Gtk Python flavour to move ahead! I've done considerable background research and strongly favor wxPython. Jachym, Trevor, and David Finlayson seem on board on this. Glynn is overall neutral, though favoring PyGTK a bit. I'm sold on the Python platform and think the wxWidgets extension is better cross-platform. I don't know whether GTK has some better widgets or not, but wxPython has more than we need for now and the future. WxPython for Linux uses GTK; it uses native Mac and Windows widgets on those platforms. AFAICT, wxPython creates a very nice interface in all supported platforms using the same code. There are a few sections that are specific to Windows, Linux, or Mac, but they are easy to avoid. So that's what I think. Jachym, Trevor, David, and I are trying to create a prototype wxPython interface to see if it works OK on Mac, Linux, and Windows before we completely commit to it, however. I'm gone on vacation for a week and a half, but will be working on this afterwards, going through the new book on wxPython. Cheers, 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_nospam at yahoo.com Tue Jul 4 05:26:32 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jul 4 05:26:39 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: <20060703164112.GN19781@bartok.itc.it> References: <20060703164112.GN19781@bartok.itc.it> Message-ID: <20060704152632.09e9075d.hamish_nospam@yahoo.com> Markus wrote: > Hi developers, > > I think that the current GRASS 6.1-CVS is in a good condition > to be released as GRASS 6.1.0. This will pave the way for > GRASS 6.2.0 (stable) which may follow shortly. horray! (outstanding issues for me: fix ps.map vlegend patterns bug and finish last i.vpoints details) recycled comments: Currently 6.0.2. is the most recent release (22 Feb 2006), but the last release including new features was 6.0.0 (10 March 2005). But that had a feature freeze since 1 Jan 2005(?). So as far as stable users are concerned we haven't added a single new feature since late 2004. I am sure you will agree that there have been some improvements since then! we did a similar 5.7.0 development release: http://grass.ibiblio.org/announces/announce_grass570.html Besides it generally being a good idea; and too long since the last; it is important to have a known delta to check against when reworking a major library (eg display drivers); the Debian package freeze is fast approaching and they will only package a point release. Plus support for 64bit, TclTk 8.4, FFTW2, etc etc.. support which 6.0 doesn't have, but many new systems use. e.g. recent troubles as Fedora Core 5 doesn't ship Tcl/Tk 8.3 anymore. > I would suggest to branch off a 6.1.0 branch in CVS to > not kill momentum in the HEAD. Important fixes can then > be merged if needed. From that branch we get out one or > two beta tarballs, then release candidates and finally > the 6.1.0 version. is a full branch really needed? I don't think it is much to declare a "freeze" for two weeks and just tag beta1 now, beta2 in 1 week, and 6.1.0 in two weeks. I guess my real question is do we want to provide support the 6.1.0 line? If so, a branch is fine, if not I suggest we freeze HEAD and use tags. > If there are no objections, I'll branch right away. > Development continues in HEAD as before and we can > extract a first 6.1.0beta for packagers and testers. > > Further discussion: > * The x11-less GRASS can be developed in HEAD, we should > not wait for that. We can have 6.1.1 if desired in near > future. The same applies to the georectifier. > > * NVIZ/Mac issues we can port from HEAD if they get fixed. > Apparently it's more related to openGL than GRASS. > > * snprintf(): much discussion, no result. We can backport > once it happens. all this is fine with me. > * other open issues which are *really* showstoppers for > a 6.1.0 unstable release? no major issues I know of. If any exist, they should be given a high priority and thus be at the top of this list: http://intevation.de/rt/webrt?q_sort=priority&q_reverse=1&q_queue=grass > An announcement is drafted at > http://grass.itc.it/announces/announce_grass610.html > The list of changes should be almost up to date, please > review and add missing items. Also the wording of the > first part could be more press release like. re. the first part: (I'm no press release writer, but..) "A feature release" I have no idea what this means vs. a "new release". 5.7.0 was a "development preview release" -- do you think that is too scary? "is a Geographical Information System (GIS) used for data management, image processing, graphics production, spatial modeling, and visualization of raster, vector and sites data." Using "data management" as first point is boring and not to the point of GRASS. Rename "sites data"? (keep idea) .. ok, reading on I see it needs work .. I'll try to put obvious fixes in CVS rather than commenting here. * is the updates section from cvs2cl.pl or from memory? (more eyes needed?) * we should update roadmap.html before final 6.1.0 release. Nicholas wrote: > Selected Bugfixes (see ChangeLog for details) > > - Source code quality/libraries: > - GRASS is now ANSI C compliant > - Ported natively to MS-Windows (MinGW based) > ^^^^^^^^^^^^^^^^^^^^^^ > > Actually points to a page (owned by Markus Neteler) that > points to a page for downloading QGIS. > - GRASS is now ANSI C compliant is this 100% true? > - Ported natively to MS-Windows (MinGW based) maybe change to "Raster and vector engines ported to native MS-Windows (MinGW based). GUI access available using QGIS." ? Hamish From hmitaso at unity.ncsu.edu Tue Jul 4 06:26:16 2006 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Tue Jul 4 06:26:21 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: <20060704152632.09e9075d.hamish_nospam@yahoo.com> References: <20060703164112.GN19781@bartok.itc.it> <20060704152632.09e9075d.hamish_nospam@yahoo.com> Message-ID: On Jul 3, 2006, at 11:26 PM, Hamish wrote: > Markus wrote: > >> Hi developers, >> >> I think that the current GRASS 6.1-CVS is in a good condition >> to be released as GRASS 6.1.0. This will pave the way for >> GRASS 6.2.0 (stable) which may follow shortly. > > horray! > (outstanding issues for me: fix ps.map vlegend patterns bug and finish > last i.vpoints details) > > recycled comments: > Currently 6.0.2. is the most recent release (22 Feb 2006), but the > last > release including new features was 6.0.0 (10 March 2005). But that had > a feature freeze since 1 Jan 2005(?). So as far as stable users are > concerned we haven't added a single new feature since late 2004. I am > sure you will agree that there have been some improvements since then! > > we did a similar 5.7.0 development release: > http://grass.ibiblio.org/announces/announce_grass570.html > > Besides it generally being a good idea; and too long since the > last; it > is important to have a known delta to check against when reworking a > major library (eg display drivers); the Debian package freeze is fast > approaching and they will only package a point release. > > Plus support for 64bit, TclTk 8.4, FFTW2, etc etc.. support which 6.0 > doesn't have, but many new systems use. e.g. recent troubles as Fedora > Core 5 doesn't ship Tcl/Tk 8.3 anymore. > > >> I would suggest to branch off a 6.1.0 branch in CVS to >> not kill momentum in the HEAD. Important fixes can then >> be merged if needed. From that branch we get out one or >> two beta tarballs, then release candidates and finally >> the 6.1.0 version. > > is a full branch really needed? I don't think it is much to declare a > "freeze" for two weeks and just tag beta1 now, beta2 in 1 week, and > 6.1.0 in two weeks. I guess my real question is do we want to provide > support the 6.1.0 line? If so, a branch is fine, if not I suggest we > freeze HEAD and use tags. > > >> If there are no objections, I'll branch right away. >> Development continues in HEAD as before and we can >> extract a first 6.1.0beta for packagers and testers. >> >> Further discussion: >> * The x11-less GRASS can be developed in HEAD, we should >> not wait for that. We can have 6.1.1 if desired in near >> future. The same applies to the georectifier. >> >> * NVIZ/Mac issues we can port from HEAD if they get fixed. >> Apparently it's more related to openGL than GRASS. >> >> * snprintf(): much discussion, no result. We can backport >> once it happens. > > all this is fine with me. > >> * other open issues which are *really* showstoppers for >> a 6.1.0 unstable release? v.in.ascii has a recently introduced bug that needs to be fixed before a release (#4769), it does not read larger files anymore. For me and some other users it is a showstopper. (Andy has provided a patch but it has some problem - so there is more work needed to get this fixed.) Some modules have problems running on 64bit (maybe that is also #4725? but it is for sure #4546 and supposedly also r.sun - probably due to uninitialized variables). I don't think that this should stop the release. Also I believe that we should thoroughly test gis.m before release - we were getting all kinds of error messages but I think that it all has been fixed by now. Helena > > no major issues I know of. If any exist, they should be given a high > priority and thus be at the top of this list: > > http://intevation.de/rt/webrt? > q_sort=priority&q_reverse=1&q_queue=grass > > >> An announcement is drafted at >> http://grass.itc.it/announces/announce_grass610.html >> The list of changes should be almost up to date, please >> review and add missing items. Also the wording of the >> first part could be more press release like. > > re. the first part: (I'm no press release writer, but..) > > "A feature release" > I have no idea what this means vs. a "new release". 5.7.0 was a > "development preview release" -- do you think that is too scary? > > > "is a Geographical Information System (GIS) used for data management, > image processing, graphics production, spatial modeling, and > visualization of raster, vector and sites data." > > Using "data management" as first point is boring and not to the > point of > GRASS. Rename "sites data"? (keep idea) > > .. ok, reading on I see it needs work .. I'll try to put obvious fixes > in CVS rather than commenting here. > > * is the updates section from cvs2cl.pl or from memory? (more eyes > needed?) > > * we should update roadmap.html before final 6.1.0 release. > > > Nicholas wrote: >> Selected Bugfixes (see ChangeLog for details) >> >> - Source code quality/libraries: >> - GRASS is now ANSI C compliant >> - Ported natively to MS-Windows (MinGW based) >> ^^^^^^^^^^^^^^^^^^^^^^ >> >> Actually points to a page (owned by Markus Neteler) that >> points to a page for downloading QGIS. > >> - GRASS is now ANSI C compliant > is this 100% true? > >> - Ported natively to MS-Windows (MinGW based) > maybe change to "Raster and vector engines ported to native MS-Windows > (MinGW based). GUI access available using QGIS." > ? > > > > Hamish > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From neteler at itc.it Tue Jul 4 09:21:36 2006 From: neteler at itc.it (Markus Neteler) Date: Tue Jul 4 09:21:38 2006 Subject: [GRASS-dev] internationalization error compiling 6.1cvs 03-04-06 In-Reply-To: References: Message-ID: <44AA1700.1030509@itc.it> Michael Barton wrote on 07/04/2006 01:37 AM: > I tried to compile a cvs version of GRASS 6.1 today and it quit in > what appears to be an internationalization section. It compiled just > fine with the same configuration and dependencies last Friday. I did a > make clean and make distclean and reran configure just to make sure. > Same results. > > Here is the error section of the make output. > > grassmods_tr.po: 1092 translated messages, 226 fuzzy translations, > 2046 untranslated messages. > grassmods_vi.po: 0 translated messages, 2084 fuzzy translations, 1280 > untranslated messages. > grassmods_zh.po: 1379 translated messages, 482 fuzzy translations, > 1503 untranslated messages. > grasstcl_de.po: msgfmt: unrecognized option `--tcl' > Try `msgfmt --help' for more information. Michael, it appears that you need to update your 'gettext' package. In newer versions the --tcl parameter is there: msgfmt --help | grep tcl --tcl Tcl mode: generate a tcl/msgcat .msg file I am using: gettext-0.14.5-3 Older versions are seriously broken and Cedric found out from the gettext ChangeLog file. Markus From neteler at itc.it Tue Jul 4 09:23:34 2006 From: neteler at itc.it (Markus Neteler) Date: Tue Jul 4 09:23:36 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: References: Message-ID: <44AA1776.5000702@itc.it> nicholas.g.lawrence@mainroads.qld.gov.au wrote on 07/04/2006 02:14 AM: >>An announcement is drafted at >>http://grass.itc.it/announces/announce_grass610.html >>The list of changes should be almost up to date, please >>review and add missing items. Also the wording of the >>first part could be more press release like. >> >> > >I notice that the link at > > Selected Bugfixes (see ChangeLog for details) > > - Source code quality/libraries: > - GRASS is now ANSI C compliant > - Ported natively to MS-Windows (MinGW based) > ^^^^^^^^^^^^^^^^^^^^^^ > >Actually points to a page (owned by Markus Neteler) that >points to a page for downloading QGIS. > > QGIS and GRASS are integrated there into a single package (for the ease of installation): qgis-grass-0.8.0-preview-win32-060605.zip.torrent 37Mb Windows 0.8 PreviewJune 5 2006 QGIS+GRASS I hope to get assistance to build the package weekly on grass.itc.it or to fetch it weekly from someone else. Markus From benjamin.ducke at ufg.uni-kiel.de Tue Jul 4 09:41:18 2006 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Tue Jul 4 09:42:12 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: <44AA1776.5000702@itc.it> References: <44AA1776.5000702@itc.it> Message-ID: <44AA1B9E.1000703@ufg.uni-kiel.de> Are the any (detailed) instructions for how to build and package a native QGIS + GRASS distribution from the regular GRASS CVS repository? I would love to add my archaeology modules and produce a version of GRASS for my colleagues working on Win32 systems. I am sure this could hit big in a science with low budget and very specific GIS needs. Best, Benjamin Markus Neteler wrote: > nicholas.g.lawrence@mainroads.qld.gov.au wrote on 07/04/2006 02:14 AM: > > >>>An announcement is drafted at >>>http://grass.itc.it/announces/announce_grass610.html >>>The list of changes should be almost up to date, please >>>review and add missing items. Also the wording of the >>>first part could be more press release like. >>> >>> >> >>I notice that the link at >> >> Selected Bugfixes (see ChangeLog for details) >> >> - Source code quality/libraries: >> - GRASS is now ANSI C compliant >> - Ported natively to MS-Windows (MinGW based) >> ^^^^^^^^^^^^^^^^^^^^^^ >> >>Actually points to a page (owned by Markus Neteler) that >>points to a page for downloading QGIS. >> >> > > > QGIS and GRASS are integrated there into a single package (for the ease > of installation): > qgis-grass-0.8.0-preview-win32-060605.zip.torrent > > 37Mb Windows 0.8 PreviewJune 5 2006 QGIS+GRASS > > I hope to get assistance to build the package weekly on grass.itc.it or > to fetch it > weekly from someone else. > > Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From neteler at itc.it Tue Jul 4 10:09:24 2006 From: neteler at itc.it (Markus Neteler) Date: Tue Jul 4 10:09:26 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: <44AA1B9E.1000703@ufg.uni-kiel.de> References: <44AA1776.5000702@itc.it> <44AA1B9E.1000703@ufg.uni-kiel.de> Message-ID: <44AA2234.1000303@itc.it> Benjamin Ducke wrote on 07/04/2006 09:41 AM: > Are the any (detailed) instructions for how to build and package > a native QGIS + GRASS distribution from the regular GRASS CVS > repository? Yes. The document is here: http://wiki.qgis.org/qgiswiki/BuildingWindowsBinaryOnLinux I have added the link to http://mpa.itc.it/radim/wingrass/ > I would love to add my archaeology modules and produce a version > of GRASS for my colleagues working on Win32 systems. > I am sure this could hit big in a science with low budget and > very specific GIS needs. Definitely. But also to show that even in case of a high budget the proposed solution is interesting for various reasons :) Markus From holl at gdf-hannover.de Tue Jul 4 10:10:49 2006 From: holl at gdf-hannover.de (Stephan Holl) Date: Tue Jul 4 10:10:59 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: <44AA1B9E.1000703@ufg.uni-kiel.de> References: <44AA1776.5000702@itc.it> <44AA1B9E.1000703@ufg.uni-kiel.de> Message-ID: <20060704101049.4c29d852@butan.gdf-hannover.de> Hello Benjamin, On Tue, 04 Jul 2006 09:41:18 +0200 Benjamin Ducke wrote: > Are the any (detailed) instructions for how to build and package > a native QGIS + GRASS distribution from the regular GRASS CVS > repository? > > I would love to add my archaeology modules and produce a version > of GRASS for my colleagues working on Win32 systems. > I am sure this could hit big in a science with low budget and > very specific GIS needs. lemmi jump in here and give you the link to Radims detailed description how to build GRASS/QGIS on windows[1]. Best Stephan [1] http://wiki.qgis.org/qgiswiki/BuildingWindowsBinaryOnLinux > > Markus Neteler wrote: > > nicholas.g.lawrence@mainroads.qld.gov.au wrote on 07/04/2006 02:14 > > AM: > > > > > >>>An announcement is drafted at > >>>http://grass.itc.it/announces/announce_grass610.html > >>>The list of changes should be almost up to date, please > >>>review and add missing items. Also the wording of the > >>>first part could be more press release like. > >>> > >>> > >> > >>I notice that the link at > >> > >> Selected Bugfixes (see ChangeLog for details) > >> > >> - Source code quality/libraries: > >> - GRASS is now ANSI C compliant > >> - Ported natively to MS-Windows (MinGW based) > >> ^^^^^^^^^^^^^^^^^^^^^^ > >> > >>Actually points to a page (owned by Markus Neteler) that > >>points to a page for downloading QGIS. > >> > >> > > > > > > QGIS and GRASS are integrated there into a single package (for the > > ease of installation): > > qgis-grass-0.8.0-preview-win32-060605.zip.torrent > > > > 37Mb Windows 0.8 PreviewJune 5 2006 QGIS+GRASS > > > > I hope to get assistance to build the package weekly on > > grass.itc.it or to fetch it > > weekly from someone else. > > > > Markus > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev > > > > > -- GDF Hannover - Solutions for spatial data analysis and remote sensing Hannover Office - Mengendamm 16d - D-30177 Hannover Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508 From rez at touchofmadness.com Tue Jul 4 11:48:51 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Tue Jul 4 11:48:57 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: References: <20060703164112.GN19781@bartok.itc.it> <20060704152632.09e9075d.hamish_nospam@yahoo.com> Message-ID: <1152006531.2454.41.camel@devel> On Tue, 2006-07-04 at 00:26 -0400, Helena Mitasova wrote: > v.in.ascii has a recently introduced bug that needs to be fixed > before a release (#4769), > it does not read larger files anymore. For me and some other users it > is a showstopper. > (Andy has provided a patch but it has some problem - so there is more > work needed to get this fixed.) I've had this done for some time, but I forgot to commit it. Just committed, but please test to make sure large files work again. -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From neteler at itc.it Tue Jul 4 12:03:42 2006 From: neteler at itc.it (Markus Neteler) Date: Tue Jul 4 12:03:44 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: <1152006531.2454.41.camel@devel> References: <20060703164112.GN19781@bartok.itc.it> <20060704152632.09e9075d.hamish_nospam@yahoo.com> <1152006531.2454.41.camel@devel> Message-ID: <44AA3CFE.5050400@itc.it> Brad Douglas wrote on 07/04/2006 11:48 AM: >On Tue, 2006-07-04 at 00:26 -0400, Helena Mitasova wrote: > > >>v.in.ascii has a recently introduced bug that needs to be fixed >>before a release (#4769), >>it does not read larger files anymore. For me and some other users it >>is a showstopper. >>(Andy has provided a patch but it has some problem - so there is more >>work needed to get this fixed.) >> >> > >I've had this done for some time, but I forgot to commit it. Just >committed, but please test to make sure large files work again. > > Brad, thanks for committing. Helena however meant *v*.in.ascii, a different story. I hope that Andrew finishes the bugfix he prepared: http://intevation.de/rt/webrt?serial_num=4769&display=History Ah, I just see that he submitted a new patch. I would need that as personal email since RT isn't suitable to maintain/extract patches. Markus From soerengebbert at gmx.de Tue Jul 4 12:54:28 2006 From: soerengebbert at gmx.de (Soeren Gebbert) Date: Tue Jul 4 12:54:32 2006 Subject: [GRASS-dev] New GRASS-test-suite version 0.2.0.8 Message-ID: <200607041254.28447.soerengebbert@gmx.de> Dear devs and users, a new shiny version of the GRASS-test-suite is available for download: http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/GRASS_Testsuite-0.2.0.8.tar.bz2 The latest test results: http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html/ and with memorycheck via valgrind: http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html_memcheck/ Please dont get confused by the detected memory errors, my debian testing system is not free of memory errors :(. I have implemented some new vector tests * now most of the v.in.* are tested * now most of the v.out.* modules are tested I also improved the framework a bit to implement tests for modules like v.out.ogr. Take a look at the test script ;-) : http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html/v.out.ogr-test.sh.html Available tests scripts with more than 270 implemented tests are: . |-- db | |-- db.columns-test.sh | |-- db.connect-test.sh | |-- db.copy-test.sh | |-- db.describe-test.sh | |-- db.drivers-test.sh | |-- db.execute-test.sh | |-- db.list | |-- db.select-test.sh | |-- db.tables-test.sh | `-- db.test-test.sh |-- general | |-- g.copy-test.sh | |-- g.filename-test.sh | |-- g.findfile-test.sh | |-- g.gisenv-test.sh | |-- g.list-test.sh | |-- g.proj-test.sh | |-- g.region-test.sh | |-- g.remove-test.sh | |-- g.rename-test.sh | |-- g.tempfile-test.sh | |-- g.version-test.sh | `-- general.list |-- raster | |-- r.buffer-test.sh | |-- r.distance-test.sh | |-- r.fill.dir-test.sh | |-- r.in.ascii-test.sh | |-- r.in.gdal-test.sh | |-- r.info-test.sh | |-- r.mapcalc-test.sh | |-- r.mapcalc-zlib-bug-test.sh | |-- r.neighbours-test.sh | |-- r.null-test.sh | |-- r.out.ascii-test.sh | |-- r.out.gdal-test.sh | |-- r.out.vtk-test.sh | |-- r.param.scale-test.sh | |-- r.slope.aspect-test.sh | |-- r.stats-test.sh | |-- r.surf.idw-test.sh | |-- r.surf.idw2-test.sh | |-- r.surf.random-test.sh | |-- r.terraflow-test.sh | |-- r.to.rast3-test.sh | |-- r.to.vect-test.sh | |-- r.watershed-test.sh | `-- raster.list |-- raster3d | |-- r3.cross.rast-test.sh | |-- r3.info-test.sh | |-- r3.mapcalc-test.sh | |-- r3.mask-test.sh | |-- r3.null-test.sh | |-- r3.out.vtk-test.sh | |-- r3.timestamp-test.sh | |-- r3.to.rast-test.sh | `-- raster3.list `-- vector |-- v.buffer-test.sh |-- v.drape-test.sh |-- v.extract-test.sh |-- v.hull-test.sh |-- v.in.ascii-test.sh |-- v.in.dxf-test.sh |-- v.in.ogr-test.sh |-- v.out.ascii-test.sh |-- v.out.dxf-test.sh |-- v.out.ogr-test.sh |-- v.out.pov-test.sh |-- v.out.vtk-test.sh |-- v.parallel-test.sh |-- v.patch-test.sh `-- vector.list Happy testing :D Best regards Soeren From soerengebbert at gmx.de Tue Jul 4 14:15:14 2006 From: soerengebbert at gmx.de (=?iso-8859-1?Q?=22S=F6ren_Gebbert=22?=) Date: Tue Jul 4 14:15:24 2006 Subject: [GRASS-dev] Re: [GRASS-user] New GRASS-test-suite version 0.2.0.8 In-Reply-To: <200607041254.28447.soerengebbert@gmx.de> References: <200607041254.28447.soerengebbert@gmx.de> Message-ID: <20060704121514.291950@gmx.net> Hi, i have used the current testsuite to test the latest qgis-grass windows binary (qgis-grass-0.8.0-preview-win32-060605.zip). The testsuite result: http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html_win32/ A lot of errors occured while running the testsuite. Many modules crashed. The testsuite was not able to verify why, because no error messages was send by the modules or windows to stderr. :( And im not sure if this is related to the testsuite ... :(. Best regards Soeren -------- Original-Nachricht -------- Datum: Tue, 4 Jul 2006 12:54:28 +0200 Von: Soeren Gebbert An: grass developers list , grassuser@grass.itc.it Betreff: [GRASS-user] New GRASS-test-suite version 0.2.0.8 > Dear devs and users, > a new shiny version of the GRASS-test-suite is available for download: > > http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/GRASS_Testsuite-0.2.0.8.tar.bz2 > > The latest test results: > > http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html/ > > and with memorycheck via valgrind: > > http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html_memcheck/ > > > Please dont get confused by the detected memory errors, my debian testing > system > is not free of memory errors :(. > > I have implemented some new vector tests > * now most of the v.in.* are tested > * now most of the v.out.* modules are tested > > I also improved the framework a bit to implement tests for modules like > v.out.ogr. > Take a look at the test script ;-) : > > http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html/v.out.ogr-test.sh.html > > Available tests scripts with more than 270 implemented tests are: > > . > |-- db > | |-- db.columns-test.sh > | |-- db.connect-test.sh > | |-- db.copy-test.sh > | |-- db.describe-test.sh > | |-- db.drivers-test.sh > | |-- db.execute-test.sh > | |-- db.list > | |-- db.select-test.sh > | |-- db.tables-test.sh > | `-- db.test-test.sh > |-- general > | |-- g.copy-test.sh > | |-- g.filename-test.sh > | |-- g.findfile-test.sh > | |-- g.gisenv-test.sh > | |-- g.list-test.sh > | |-- g.proj-test.sh > | |-- g.region-test.sh > | |-- g.remove-test.sh > | |-- g.rename-test.sh > | |-- g.tempfile-test.sh > | |-- g.version-test.sh > | `-- general.list > |-- raster > | |-- r.buffer-test.sh > | |-- r.distance-test.sh > | |-- r.fill.dir-test.sh > | |-- r.in.ascii-test.sh > | |-- r.in.gdal-test.sh > | |-- r.info-test.sh > | |-- r.mapcalc-test.sh > | |-- r.mapcalc-zlib-bug-test.sh > | |-- r.neighbours-test.sh > | |-- r.null-test.sh > | |-- r.out.ascii-test.sh > | |-- r.out.gdal-test.sh > | |-- r.out.vtk-test.sh > | |-- r.param.scale-test.sh > | |-- r.slope.aspect-test.sh > | |-- r.stats-test.sh > | |-- r.surf.idw-test.sh > | |-- r.surf.idw2-test.sh > | |-- r.surf.random-test.sh > | |-- r.terraflow-test.sh > | |-- r.to.rast3-test.sh > | |-- r.to.vect-test.sh > | |-- r.watershed-test.sh > | `-- raster.list > |-- raster3d > | |-- r3.cross.rast-test.sh > | |-- r3.info-test.sh > | |-- r3.mapcalc-test.sh > | |-- r3.mask-test.sh > | |-- r3.null-test.sh > | |-- r3.out.vtk-test.sh > | |-- r3.timestamp-test.sh > | |-- r3.to.rast-test.sh > | `-- raster3.list > `-- vector > |-- v.buffer-test.sh > |-- v.drape-test.sh > |-- v.extract-test.sh > |-- v.hull-test.sh > |-- v.in.ascii-test.sh > |-- v.in.dxf-test.sh > |-- v.in.ogr-test.sh > |-- v.out.ascii-test.sh > |-- v.out.dxf-test.sh > |-- v.out.ogr-test.sh > |-- v.out.pov-test.sh > |-- v.out.vtk-test.sh > |-- v.parallel-test.sh > |-- v.patch-test.sh > `-- vector.list > > Happy testing :D > > Best regards > Soeren > > _______________________________________________ > grassuser mailing list > grassuser@grass.itc.it > http://grass.itc.it/mailman/listinfo/grassuser -- Echte DSL-Flatrate dauerhaft f?r 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl From adanner at cs.duke.edu Tue Jul 4 14:58:51 2006 From: adanner at cs.duke.edu (Andrew Danner) Date: Tue Jul 4 14:58:59 2006 Subject: [GRASS-dev] v.in.ascii updated patch In-Reply-To: <44AA3CFE.5050400@itc.it> References: <20060703164112.GN19781@bartok.itc.it> <20060704152632.09e9075d.hamish_nospam@yahoo.com> <1152006531.2454.41.camel@devel> <44AA3CFE.5050400@itc.it> Message-ID: <1152017931.5258.3.camel@localhost> Markus, The updated patch for v.in.ascii is attached. -Andy On Tue, 2006-07-04 at 12:03 +0200, Markus Neteler wrote: > Brad Douglas wrote on 07/04/2006 11:48 AM: > > >On Tue, 2006-07-04 at 00:26 -0400, Helena Mitasova wrote: > > > > > >>v.in.ascii has a recently introduced bug that needs to be fixed > >>before a release (#4769), > >>it does not read larger files anymore. For me and some other users it > >>is a showstopper. > >>(Andy has provided a patch but it has some problem - so there is more > >>work needed to get this fixed.) > >> > >> > > > >I've had this done for some time, but I forgot to commit it. Just > >committed, but please test to make sure large files work again. > > > > > > Brad, > thanks for committing. Helena however meant *v*.in.ascii, a different > story. I hope > that Andrew finishes the bugfix he prepared: > http://intevation.de/rt/webrt?serial_num=4769&display=History > > Ah, I just see that he submitted a new patch. I would need that as personal > email since RT isn't suitable to maintain/extract patches. > > Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: v_in_ascii_points_c.udiff-2.patch Type: text/x-patch Size: 2186 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060704/a5622756/v_in_ascii_points_c.udiff-2-0001.bin From paul-grass at stjohnspoint.co.uk Tue Jul 4 15:08:48 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Jul 4 15:09:01 2006 Subject: [GRASS-dev] Re: [bug #1140] (grass) Non-portable snprintf() used in several programs In-Reply-To: <20060704123813.F3AE41005CA@lists.intevation.de> References: <20060704123813.F3AE41005CA@lists.intevation.de> Message-ID: Hello Markus! I contend that most of those recent introductions of snprintf() probably don't need it. E.g. the first one (raster3d/r3.in.acii/main.c) can calculate the length of the string to be malloc'ed using strlen() so can guarantee to leave enough space. The second one (db/drivers/dbf/dbfexe.c) can use a fixed field width specifier for the %d format string to fix the length also - again predictable. So I will work through those and see if I can change them not to use snprintf(). Started it now. I feel if there's something where the length of the resulting string really cannot be predicted, then we should use G_asprintf() because it's there. It does seem to be a matter of personal preference and philosophy though! But I think as Glynn has said before, most of the places snprintf() is used the return value is not checked. So if an overflow was prevented, and the string was not the expected value, the program would just ignore it! So to summarise - G_snprintf() would be useful to have to easily fix the places that snprintf() was erroneously introduced - so you could put it in, but I think we should discourage its use in favour of calculating how long the string will be and allocating enough memory. Paul On Tue, 4 Jul 2006, Markus Neteler via RT wrote: > Hi, > > > > the snprintf() is used as of today in: > > > > ./raster3d/r3.in.ascii/main.c > > ./db/drivers/dbf/dbfexe.c > > ./raster/r.support/front/front.c > > ./raster/r.support/front/check.c > > ./raster/r.support/front/run.c > > ./raster/r.support/modhead/check_un.c > > ./raster/r.support/modhead/modhead.c > > ./raster/r.support/modhead/ask_format.c > > ./lib/init/clean_temp.c > > ./lib/db/dbmi_client/select.c > > ./lib/gis/user_config.c > > ./lib/vector/dglib/examples/components.c > > > > I suggest to implement G_snprintf() and use that > > function everywhere. Then we can fix in a single place > > if needed. > > > > Markus > > > > -------------------------------------------- Managed by Request Tracker > From neteler at itc.it Tue Jul 4 15:23:57 2006 From: neteler at itc.it (Markus Neteler) Date: Tue Jul 4 15:23:58 2006 Subject: [GRASS-dev] Re: [bug #1140] (grass) Non-portable snprintf() used in several programs In-Reply-To: References: <20060704123813.F3AE41005CA@lists.intevation.de> Message-ID: <20060704132357.GE21351@bartok.itc.it> Hello Paul, On Tue, Jul 04, 2006 at 02:08:48PM +0100, Paul Kelly wrote: > Hello Markus! > I contend that most of those recent introductions of snprintf() probably > don't need it. E.g. the first one (raster3d/r3.in.acii/main.c) can > calculate the length of the string to be malloc'ed using strlen() so can > guarantee to leave enough space. The second one (db/drivers/dbf/dbfexe.c) > can use a fixed field width specifier for the %d format string to fix the > length also - again predictable. > > So I will work through those and see if I can change them not to use > snprintf(). Started it now. I feel if there's something where the length > of the resulting string really cannot be predicted, then we should use > G_asprintf() because it's there. It does seem to be a matter of personal > preference and philosophy though! But I think as Glynn has said before, > most of the places snprintf() is used the return value is not checked. So > if an overflow was prevented, and the string was not the expected value, > the program would just ignore it! > > So to summarise - G_snprintf() would be useful to have to easily fix > the places that snprintf() was erroneously introduced - so you could put > it in, but I think we should discourage its use in favour of calculating > how long the string will be and allocating enough memory. thanks for working on it. I have submitted now the G_snprintf() wrapper function to lib/gis/snprintf.c with the discouragement included on top. You may use it now if snprintf() cannot be avoided. Markus From grass-bugs at intevation.de Tue Jul 4 15:28:56 2006 From: grass-bugs at intevation.de (Markus Neteler via RT) Date: Tue Jul 4 15:28:58 2006 Subject: [GRASS-dev] [bug #3354] (grass) v.in.ascii crashing on large inputs Message-ID: <20060704132856.D27DA100164@lists.intevation.de> Andrew, patch received. In spearfish UTM, 1 mio points consume around 400k of RAM. Seems to be a reasonable amount. In latlong, 1 mio points seem to run ok as well now! Patch applied to CVS. Thanks, Markus PS: notes to others: for easy testing run v.random + v.out.ascii + v.in.ascii -------------------------------------------- Managed by Request Tracker From neteler at itc.it Tue Jul 4 15:34:35 2006 From: neteler at itc.it (Markus Neteler) Date: Tue Jul 4 15:34:37 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: <20060704152632.09e9075d.hamish_nospam@yahoo.com> References: <20060703164112.GN19781@bartok.itc.it> <20060704152632.09e9075d.hamish_nospam@yahoo.com> Message-ID: <20060704133435.GF21351@bartok.itc.it> On Tue, Jul 04, 2006 at 03:26:32PM +1200, Hamish wrote: >Markus wrote: > >>Hi developers, >> >>I think that the current GRASS 6.1-CVS is in a good condition >>to be released as GRASS 6.1.0. This will pave the way for >>GRASS 6.2.0 (stable) which may follow shortly. > >horray! >(outstanding issues for me: fix ps.map vlegend patterns bug and finish >last i.vpoints details) Hamish: what's your time line for this? [... some additions made to announcement from H's comments...] >>I would suggest to branch off a 6.1.0 branch in CVS to >>not kill momentum in the HEAD. Important fixes can then >>be merged if needed. From that branch we get out one or >>two beta tarballs, then release candidates and finally >>the 6.1.0 version. > >is a full branch really needed? I don't think it is much to declare a >"freeze" for two weeks and just tag beta1 now, beta2 in 1 week, and >6.1.0 in two weeks. I don't like this idea too much for three reasons - some developer will still commit - we kill momentum since betas could be delayed - backporting *important* issues isn't that hard (we did it successfully for 5.4 and 6.0) Let's keep it decoupled. Keep in mind that it is 6.1.0, not 6.2.0! > I guess my real question is do we want to provide >support the 6.1.0 line? If so, a branch is fine, if not I suggest we >freeze HEAD and use tags. IMHO, doing that on a tag can become pretty messy. >>If there are no objections, I'll branch right away. >>Development continues in HEAD as before and we can >>extract a first 6.1.0beta for packagers and testers. >> >>Further discussion: >>* The x11-less GRASS can be developed in HEAD, we should >> not wait for that. We can have 6.1.1 if desired in near >> future. The same applies to the georectifier. >> >>* NVIZ/Mac issues we can port from HEAD if they get fixed. >> Apparently it's more related to openGL than GRASS. >> >>* snprintf(): much discussion, no result. We can backport >> once it happens. > >all this is fine with me. I have added G_snprintf() to lib/gis/ and changed all usages of snprintf() to G_snprintf(). See related https://intevation.de/rt/webrt?serial_num=1140&display=History Paul is working on that now. G_snprintf() submitted to CVS. Helena mentioned v.in.ascii as show-stopper: Andrew fixed it, patch applied. >>An announcement is drafted at >> http://grass.itc.it/announces/announce_grass610.html >>The list of changes should be almost up to date, please >>review and add missing items. Also the wording of the >>first part could be more press release like. > >re. the first part: (I'm no press release writer, but..) > >"A feature release" >I have no idea what this means vs. a "new release". 5.7.0 was a >"development preview release" -- do you think that is too scary? Maybe too scary? >"is a Geographical Information System (GIS) used for data management, >image processing, graphics production, spatial modeling, and >visualization of raster, vector and sites data." > changed to "used for spatial modeling, visualization of raster and vector data, data management, image processing, and graphics production. " >Using "data management" as first point is boring and not to the point of >GRASS. Rename "sites data"? (keep idea) sites removed. >.. ok, reading on I see it needs work .. I'll try to put obvious fixes >in CVS rather than commenting here. thanks >* is the updates section from cvs2cl.pl or from memory? (more eyes needed?) I used cvs2cl.pl, then selected stuff manually (quite time consuming). Yes, more eyes needed, but we should reflect only relevant changes which is not always easy to decide. >* we should update roadmap.html before final 6.1.0 release. Sounds good... but we would need to follow that roadmap then which rarely happened in the past. :) >> - GRASS is now ANSI C compliant > >is this 100% true? I dunno - but maybe we are already happy with 95% (rounding error). >> - Ported natively to MS-Windows (MinGW based) > >maybe change to "Raster and vector engines ported to native MS-Windows >(MinGW based). GUI access available using QGIS." >? You can also use much of winGRASS from "command.com". I didn't try tcltk since I don't have a modifyable Windows version here. winGRASS runs also without QGIS. But a bit more text is needed in the announcement. Markus From neteler at itc.it Tue Jul 4 15:57:21 2006 From: neteler at itc.it (Markus Neteler) Date: Tue Jul 4 15:57:23 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: References: <20060703164112.GN19781@bartok.itc.it> <20060704152632.09e9075d.hamish_nospam@yahoo.com> Message-ID: <20060704135721.GG21351@bartok.itc.it> On Tue, Jul 04, 2006 at 12:26:16AM -0400, Helena Mitasova wrote: ... > Some modules have problems running on 64bit (maybe that is also > #4725? The nviz volume bug was recently introduces, I think. As far as I remember it worked some time ago on 64bit. https://intevation.de/rt/webrt?serial_num=4725 " I followed "mode" into lib/ogsf/GVL2.c GVL_slice_get_drawmode() and then *gvl to gvl_get_vol() in lib/ogsf/gvl.c, but then I get lost. " ? > but it is for sure #4546 https://intevation.de/rt/webrt?serial_num=4546 r.sim.water crashes in simlib/input.c line 403, function grad_check(): if (cchez[k][l] != 0.) { with k=700 and l=0 Not sure why. > and supposedly also r.sun - probably due to uninitialized > variables). Right, It crashes in INPUT () at main.c:656 if (z[i][j] == UNDEFZ || o[i][j] == UNDEFZ || s[i][j] == UNDEFZ) Here a Spearfish test script: ELEV=elevation.dem TMP=$$ SLOPE=$TMP.slope ASP=$TMP.aspect r.slope.aspect elevation.dem as=$TMP.aspect sl=$TMP.slope --o r.mapcalc global_shadow.rad=0 DAY=055 r.sun -s elevin=elevation.dem aspin=$TMP.aspect slopein=$TMP.slope day=$DAY \ beam_rad=bs_rad.$DAY diff_rad=ds_rad.$DAY refl_rad=rs_rad.$DAY > I don't think that this should stop the release. I would appreciate if those two bugs would be fixed, but we can backport the fixes later. > Also I believe that we should thoroughly test gis.m before release - > we were getting all kinds of error messages but I think that it all > has been fixed by now. Yes, gis.m should get a consolidation cycle now. Markus From grass-bugs at intevation.de Tue Jul 4 16:04:54 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Tue Jul 4 16:04:56 2006 Subject: [GRASS-dev] [bug #4786] (grass) r.sun crash on 64bit Message-ID: <20060704140454.05BE11005CA@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4786 ------------------------------------------------------------------------- Subject: r.sun crash on 64bit Hi, here again as bug report. r.sun crashes on 64bit CPUs: It crashes in INPUT () at main.c:656 if (z[i][j] == UNDEFZ || o[i][j] == UNDEFZ || s[i][j] == UNDEFZ) Here a Spearfish test script: ELEV=elevation.dem TMP=$$ SLOPE=$TMP.slope ASP=$TMP.aspect r.slope.aspect elevation.dem as=$TMP.aspect sl=$TMP.slope --o r.mapcalc global_shadow.rad=0 DAY=055 r.sun -s elevin=elevation.dem aspin=$TMP.aspect slopein=$TMP.slope day=$DAY \ beam_rad=bs_rad.$DAY diff_rad=ds_rad.$DAY refl_rad=rs_rad.$DAY (gdb) r -s elevin=elevation.dem aspin=10066.aspect slopein=10066.slope day=055 beam_rad=bs_rad.055 diff_rad=ds_rad.055 refl_rad=rs_rad.055 Starting program: /nfsmnt/bartok0/ssi/neteler/software/cvsgrass61/dist.x86_64-unknown-linux-gnu/bin/r.sun -s elevin=elevation.dem aspin=10066.aspect slopein=10066.slope day=055 beam_rad=bs_rad.055 diff_rad=ds_rad.055 refl_rad=rs_rad.055 [Thread debugging using libthread_db enabled] [New Thread 182917699168 (LWP 10170)] Mode 2: integrated daily irradiation for a given day of the year Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 182917699168 (LWP 10170)] 0x00000000004051b8 in INPUT () at main.c:656 656 if (z[i][j] == UNDEFZ || o[i][j] == UNDEFZ || s[i][j] == UNDEFZ) (gdb) bt #0 0x00000000004051b8 in INPUT () at main.c:656 #1 0x0000000000403fb2 in main (argc=9, argv=0x7fbfffef88) at main.c:440 (gdb) bt full #0 0x00000000004051b8 in INPUT () at main.c:656 cell1 = (FCELL *) 0x515690 cell2 = (FCELL *) 0x517450 cell3 = (FCELL *) 0x519210 cell4 = (FCELL *) 0xffffffffffffffff cell5 = (FCELL *) 0x409b56 cell6 = (FCELL *) 0x2 rast1 = (FCELL *) 0x3be530a502 rast2 = (FCELL *) 0x2a95ffbee0 fd1 = 8 fd2 = 9 fd3 = 10 fd4 = -1073746048 fd5 = 0 fd6 = 0 row = 1398 row_rev = 0 fr1 = 59 fr2 = -449796550 l = 1398 i = 700 j = 0 #1 0x0000000000403fb2 in main (argc=9, argv=0x7fbfffef88) at main.c:440 module = (struct GModule *) 0x2a95ffbfc0 parm = {elevin = 0x2a95ffbf20, aspin = 0x5107b0, slopein = 0x5116d0, linkein = 0x511770, lin = 0x511810, albedo = 0x5118b0, alb = 0x511950, latin = 0x511ad0, lat = 0x511b70, coefbh = 0x511c10, coefdh = 0x511cb0, incidout = 0x511d50, beam_rad = 0x511df0, insol_time = 0x511eb0, diff_rad = 0x511f70, refl_rad = 0x512030, day = 0x5120f0, step = 0x5121b0, declin = 0x512270, ltime = 0x512330} flag = {shade = 0x2a95ffbee0} (gdb) Markus -------------------------------------------- Managed by Request Tracker From cavallini at faunalia.it Tue Jul 4 16:11:43 2006 From: cavallini at faunalia.it (Paolo Cavallini) Date: Tue Jul 4 16:11:46 2006 Subject: [GRASS-dev] v.in.gpsbabel Message-ID: <44AA771F.4060409@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all. Just a small note about v.in.gpsbabel: when loading data to DB, if user does not have sufficient permissions, he gets an error about db.login. In fact, the problem can be solved both with db.login and db.connect, so I think a more general statement would be more appropriate. Should I fill a bug about this? All the best. pc - -- Paolo Cavallini email+jabber: cavallini@faunalia.it www.faunalia.it Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEqncf/NedwLUzIr4RAjMzAJ0QcHeXPuHQ456TZZT/XfUhWPWuswCfQY4A bEk5gzVdzk98mZXt2J8lTws= =9gzg -----END PGP SIGNATURE----- From grass-bugs at intevation.de Tue Jul 4 16:13:51 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Tue Jul 4 16:13:53 2006 Subject: [GRASS-dev] [bug #4787] (grass) Path not found in Mac when Directory has spaces in the name Message-ID: <20060704141351.B74A01005CA@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4787 ------------------------------------------------------------------------- Subject: Path not found in Mac when Directory has spaces in the name Platform: Mac OSX grass obtained from: Trento Italy site grass binary for platform: Downloaded precompiled Binaries Agustin Diez-Castillo When saving a display I got this message rm: /Volumes/Home: No such file or directory rm: Directory/neolitic/disco/AC_JACIMENTS/prospecciomay2006/mapa_04_07_2006.ppm: No such file or directory # but it should be /Volumes/Home\ Directory/neolitic/disco/AC_JACIMENTS/prospecciomay2006/mapa_04_07_2006.ppm # or '/Volumes/Home Directory/neolitic/disco/AC_JACIMENTS/prospecciomay2006/mapa_04_07_2006.ppm' while executing "exec rm /Volumes/Home Directory/neolitic/disco/AC_JACIMENTS/prospecciomay2006/mapa_04_07_2006.ppm" ("eval" body line 1) invoked from within "eval exec "rm $path.ppm"" ("jpg" arm line 3) invoked from within "switch $type { "ppm" { return } "tif" { eval exec {gdal_translate $path.ppm $path.tif -of GTIFF} eval exec "rm $path.ppm" } ..." (procedure "MapToolBar::savefile" line 22) invoked from within "MapToolBar::savefile jpg 95" invoked from within ".mapcan(1).mf.topf.tb0.mapsave.sf.jpg 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.mapsave.sf.jpg 1" (command bound to event) -------------------------------------------- Managed by Request Tracker From sydv at sjgeophysics.com Tue Jul 4 16:18:04 2006 From: sydv at sjgeophysics.com (syd visser) Date: Tue Jul 4 16:16:16 2006 Subject: [GRASS-dev] Re: gis.m issues References: 20060704142439.3f42bf74.hamish_nospam@yahoo.com Message-ID: <44AA789C.10506@sjgeophysics.com> We are moving over to Python and wxPython for most of our development work and therefore would definitely be in favor of grass going in that direction. I noticed there are some VTK modules in grass now. Has anyone looked at what Enthought ( http://www.enthought.com/ ) is doing using Python and wxPython especially MayaVi2 (3D visualization using VTK) https://svn.enthought.com/enthought/wiki/MayaVi. Syd > From: Hamish > Date: Tue, 4 Jul 2006 14:24:39 +1200 > To: Michael Barton > Cc: > Subject: Re: gis.m issues > > Michael Barton wrote: > >I've done considerable background research and strongly favor wxPython. >Jachym, Trevor, and David Finlayson seem on board on this. Glynn is overall >neutral, though favoring PyGTK a bit. I'm sold on the Python platform and >think the wxWidgets extension is better cross-platform. I don't know whether >GTK has some better widgets or not, but wxPython has more than we need for >now and the future. >WxPython for Linux uses GTK; it uses native Mac and Windows widgets on those >platforms. AFAICT, wxPython creates a very nice interface in all supported >platforms using the same code. There are a few sections that are specific to >Windows, Linux, or Mac, but they are easy to avoid. >So that's what I think. Jachym, Trevor, David, and I are trying to create a >prototype wxPython interface to see if it works OK on Mac, Linux, and >Windows before we completely commit to it, however. >I'm gone on vacation for a week and a half, but will be working on this >afterwards, going through the new book on wxPython. >Cheers, >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 -- ///////////////////////////////////////////// Syd Visser P.Geo SJ Geophysics Ltd sydv@sjgeophysics.com www.sjgeophysics.com From neteler at itc.it Tue Jul 4 16:21:01 2006 From: neteler at itc.it (Markus Neteler) Date: Tue Jul 4 16:21:02 2006 Subject: [GRASS-dev] v.in.gpsbabel In-Reply-To: <44AA771F.4060409@faunalia.it> References: <44AA771F.4060409@faunalia.it> Message-ID: <20060704142101.GH21351@bartok.itc.it> On Tue, Jul 04, 2006 at 04:11:43PM +0200, Paolo Cavallini wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all. > Just a small note about v.in.gpsbabel: when loading data to DB, if user > does not have sufficient permissions, he gets an error about db.login. Probably an error test is missing? Could you post the error message? BTW: db.login is only needed for real DBMS'. > In fact, the problem can be solved both with db.login and db.connect, so > I think a more general statement would be more appropriate. > Should I fill a bug about this? Aren't the authors in cc? :-) Markus > All the best. > pc > - -- > Paolo Cavallini > email+jabber: cavallini@faunalia.it > www.faunalia.it > Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFEqncf/NedwLUzIr4RAjMzAJ0QcHeXPuHQ456TZZT/XfUhWPWuswCfQY4A > bEk5gzVdzk98mZXt2J8lTws= > =9gzg > -----END PGP SIGNATURE----- > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Markus Neteler http://mpa.itc.it/markus/ ITC-irst - Centro per la Ricerca Scientifica e Tecnologica MPBA - Predictive Models for Biol. & Environ. Data Analysis Via Sommarive, 18 - 38050 Povo (Trento), Italy From neteler at itc.it Tue Jul 4 16:25:47 2006 From: neteler at itc.it (Markus Neteler) Date: Tue Jul 4 16:25:48 2006 Subject: [GRASS-dev] Re: gis.m issues In-Reply-To: <44AA789C.10506@sjgeophysics.com> References: <44AA789C.10506@sjgeophysics.com> Message-ID: <20060704142547.GI21351@bartok.itc.it> On Tue, Jul 04, 2006 at 07:18:04AM -0700, syd visser wrote: > We are moving over to Python and wxPython for most of our development > work and therefore would definitely be in favor of grass going in that > direction. It did so last night :-) I submitted the updated GRASS 5's wxPython bindings to GRASS 6.1-CVS. See also: http://grass.gdf-hannover.de/wiki/GRASS_and_Python > I noticed there are some VTK modules in grass now. > Has anyone looked at what Enthought ( http://www.enthought.com/ ) is > doing using Python and wxPython especially MayaVi2 (3D visualization > using VTK) https://svn.enthought.com/enthought/wiki/MayaVi. It would be very nice to have more people working on Python bindings. Markus > Syd > > > > From: Hamish > > Date: Tue, 4 Jul 2006 14:24:39 +1200 > > To: Michael Barton > > Cc: > > Subject: Re: gis.m issues > > > > Michael Barton wrote: > > > > >I've done considerable background research and strongly favor wxPython. > >Jachym, Trevor, and David Finlayson seem on board on this. Glynn is > overall > >neutral, though favoring PyGTK a bit. I'm sold on the Python platform and > >think the wxWidgets extension is better cross-platform. I don't know > whether > >GTK has some better widgets or not, but wxPython has more than we need for > >now and the future. > > >WxPython for Linux uses GTK; it uses native Mac and Windows widgets on > those > >platforms. AFAICT, wxPython creates a very nice interface in all supported > >platforms using the same code. There are a few sections that are > specific to > >Windows, Linux, or Mac, but they are easy to avoid. > > >So that's what I think. Jachym, Trevor, David, and I are trying to > create a > >prototype wxPython interface to see if it works OK on Mac, Linux, and > >Windows before we completely commit to it, however. > > >I'm gone on vacation for a week and a half, but will be working on this > >afterwards, going through the new book on wxPython. > > >Cheers, > >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 > > -- > ///////////////////////////////////////////// > Syd Visser P.Geo > SJ Geophysics Ltd > sydv@sjgeophysics.com > www.sjgeophysics.com > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Markus Neteler http://mpa.itc.it/markus/ ITC-irst - Centro per la Ricerca Scientifica e Tecnologica MPBA - Predictive Models for Biol. & Environ. Data Analysis Via Sommarive, 18 - 38050 Povo (Trento), Italy From roberto at geomatica.como.polimi.it Tue Jul 4 16:59:37 2006 From: roberto at geomatica.como.polimi.it (Roberto Antolin) Date: Tue Jul 4 16:58:36 2006 Subject: [GRASS-dev] Vect_set_release_support() In-Reply-To: <200607041416.k64EGJdJ028862@grass.itc.it> References: <200607041416.k64EGJdJ028862@grass.itc.it> Message-ID: <44AA8259.60507@geomatica.como.polimi.it> Hi all, I have a small problem with: "Vect_set_release_support()". I use this function just for releasing memory like this: Vect_build (--); Vect_save_topo (--); Vect_set_release_support(--); Vect_close (--); exit(EXIT_SUCCESS); But, when I call my command from the graphical interface, the interface disappears when the function is called and the vector is not saved. On the other hand, if I call it from the command line, there is no problem. Can somebody help me? Thanks, Roberto. -- Roberto Antolin Sanchez Politecnico di Milano ? Polo Regionale di Como Via Valleggio, 11 ? 22100 Como, Italy tel: +39 031 3327533 email: roberto.antolin@polimi.it From glynn at gclements.plus.com Tue Jul 4 21:20:54 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jul 4 21:21:34 2006 Subject: [GRASS-dev] Re: [bug #4768] (grass) nviz segfault on startup when In-Reply-To: References: <20060702194620.CD77D1006A0@lists.intevation.de> Message-ID: <17578.49046.648187.662500@cerise.gclements.plus.com> William Kyngesburye wrote: > > Also, I'll look at the Togl demos, since this is a new version of > > Togl. > > Togl built separately for OSX X11 - demos work, within limits. > > double, gears and texture demos work. stereo, index and overlay > demos do not. According to the Togl docs, stereo and overlay > features of Togl require hardware support for them, on higher-end > graphics cards (and not even 'gaming' cards). I'm running this on a > MacBook, with the Intel GMA 950 integrated graphics. Maybe not up-to- > snuff. Does NVIZ use any of these features of Togl? No. > The Togl docs don't say anything about the index demo, but it fails > with the same BadWindow/invalid window parameter error of the stereo > demo, so it might be a similar hardware feature. In this context, "index" refers to indexed-colour modes, i.e. those where pixel values are indices into a palette, as opposed to "true-colour" modes where pixels are split into red/green/blue fields. The index demo will only work if your display is in an indexed-colour mode. AFAIK, NVIZ won't work in such modes; it requires true-colour. -- Glynn Clements From glynn at gclements.plus.com Tue Jul 4 21:28:54 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jul 4 21:30:57 2006 Subject: [GRASS-dev] Re: [bug #4768] (grass) nviz segfault on startup when In-Reply-To: <187BA839-A9FC-4FB0-907E-F06DA8F19E48@kyngchaos.com> References: <20060702194620.CD77D1006A0@lists.intevation.de> <187BA839-A9FC-4FB0-907E-F06DA8F19E48@kyngchaos.com> Message-ID: <17578.49526.684665.52124@cerise.gclements.plus.com> William Kyngesburye wrote: > - There is something wrong with glX in Apple's X11 that only shows up > (so far) with NVIZ. I need to find some OpenGL demos that use glX, > next. NVIZ typically links against a /lot/ of libraries; far more than a typical OpenGL demonstration. The more libraries which a program uses, the more chance that one of them will cause a problem. If you have multiple libraries with the same name, it's possible that the choice of which one is linked in will depend upon which other libraries a program uses. One thing to try: build NVIZ, copy the link command from the "make" output, then use a similar command (with the same set of -L/-l/etc switches) to build your test program. That will determine whether the libraries which are being used are having an effect. -- Glynn Clements From glynn at gclements.plus.com Tue Jul 4 21:50:15 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jul 4 21:50:18 2006 Subject: [GRASS-dev] Re: [bug #1140] (grass) Non-portable snprintf() used in several programs In-Reply-To: References: <20060704123813.F3AE41005CA@lists.intevation.de> Message-ID: <17578.50807.818514.870528@cerise.gclements.plus.com> Paul Kelly wrote: > I contend that most of those recent introductions of snprintf() probably > don't need it. E.g. the first one (raster3d/r3.in.acii/main.c) can > calculate the length of the string to be malloc'ed using strlen() so can > guarantee to leave enough space. The second one (db/drivers/dbf/dbfexe.c) > can use a fixed field width specifier for the %d format string to fix the > length also - again predictable. Field width specifiers only control the minimum width of a field (i.e. the amount of padding or the number of leading zeroes); a field can still be larger than the specified width. For %d, it's reasonable to assume a 32-bit integer, which means that it can never be more than 11 characters wide (10 digits, with a leading minus if negative). -- Glynn Clements From glynn at gclements.plus.com Tue Jul 4 21:53:43 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jul 4 21:53:47 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: <20060704101049.4c29d852@butan.gdf-hannover.de> References: <44AA1776.5000702@itc.it> <44AA1B9E.1000703@ufg.uni-kiel.de> <20060704101049.4c29d852@butan.gdf-hannover.de> Message-ID: <17578.51015.472978.97302@cerise.gclements.plus.com> Stephan Holl wrote: > > Are the any (detailed) instructions for how to build and package > > a native QGIS + GRASS distribution from the regular GRASS CVS > > repository? > > > > I would love to add my archaeology modules and produce a version > > of GRASS for my colleagues working on Win32 systems. > > I am sure this could hit big in a science with low budget and > > very specific GIS needs. > > lemmi jump in here and give you the link to Radims detailed description > how to build GRASS/QGIS on windows[1]. It would be more useful to have a guide to building a native Windows version on Windows, rather than having to cross-compile. Also, it would be useful to offer pre-compiled Windows binaries of essential libraries (proj, GDAL etc). -- Glynn Clements From glynn at gclements.plus.com Tue Jul 4 22:02:27 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jul 4 22:02:29 2006 Subject: [GRASS-dev] [bug #4786] (grass) r.sun crash on 64bit In-Reply-To: <20060704140454.05BE11005CA@lists.intevation.de> References: <20060704140454.05BE11005CA@lists.intevation.de> Message-ID: <17578.51539.162675.165106@cerise.gclements.plus.com> Request Tracker wrote: > this bug's URL: http://intevation.de/rt/webrt?serial_num=4786 > ------------------------------------------------------------------------- > > Subject: r.sun crash on 64bit I've committed a fix for this (untested, as I don't have a 64-bit system to test). -- Glynn Clements From paul-grass at stjohnspoint.co.uk Tue Jul 4 22:07:09 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Jul 4 22:07:28 2006 Subject: [GRASS-dev] Re: [bug #1140] (grass) Non-portable snprintf() used in several programs In-Reply-To: <17578.50807.818514.870528@cerise.gclements.plus.com> References: <20060704123813.F3AE41005CA@lists.intevation.de> <17578.50807.818514.870528@cerise.gclements.plus.com> Message-ID: <44AACA6D.8030200@stjohnspoint.co.uk> Glynn Clements wrote: > Paul Kelly wrote: > > >>I contend that most of those recent introductions of snprintf() probably >>don't need it. E.g. the first one (raster3d/r3.in.acii/main.c) can >>calculate the length of the string to be malloc'ed using strlen() so can >>guarantee to leave enough space. The second one (db/drivers/dbf/dbfexe.c) >>can use a fixed field width specifier for the %d format string to fix the >>length also - again predictable. > > > Field width specifiers only control the minimum width of a field (i.e. > the amount of padding or the number of leading zeroes); a field can > still be larger than the specified width. Ah yes I realised that when I actually went to implement my proposed change. > For %d, it's reasonable to assume a 32-bit integer, which means that > it can never be more than 11 characters wide (10 digits, with a > leading minus if negative). Well in this case the existing code was allocating 32 bytes of space and then using snprintf so I think it should be safe to change the snprintf a simple sprintf in this case (db/drivers/dbf/dbfexe.c). From glynn at gclements.plus.com Tue Jul 4 22:09:17 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jul 4 22:09:19 2006 Subject: [GRASS-dev] [bug #4787] (grass) Path not found in Mac when Directory has spaces in the name In-Reply-To: <20060704141351.B74A01005CA@lists.intevation.de> References: <20060704141351.B74A01005CA@lists.intevation.de> Message-ID: <17578.51949.33977.668592@cerise.gclements.plus.com> Request Tracker wrote: > this bug's URL: http://intevation.de/rt/webrt?serial_num=4787 > ------------------------------------------------------------------------- > > Subject: Path not found in Mac when Directory has spaces in the name > "tif" { > eval exec {gdal_translate $path.ppm $path.tif -of GTIFF} > eval exec "rm $path.ppm" > } This is a good example of how /not/ to use "exec" in Tcl. A command is a list of strings, not a string. This issue plagues Bourne-shell scripts do the lack of support for lists. Tcl has lists, so there's no reason for this type of issue to arise. The above should be: exec gdal_translate $path.ppm $path.tif -of GTIFF exec rm $path.ppm I strongly suspect that the same issue applies to most (if not all) of the other occurrences of "eval exec ..." in gis.m (a quick "grep" finds 50 of them). -- Glynn Clements From hamish_nospam at yahoo.com Wed Jul 5 08:20:54 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jul 5 08:23:17 2006 Subject: [GRASS-dev] Re: [GRASS-user] Can't create location In-Reply-To: <17578.48736.571982.372409@cerise.gclements.plus.com> References: <1151503551.6619.6.camel@sirarchie.DOHEMM.DE> <20060628164852.673918d1@butan.gdf-hannover.de> <1151508601.6619.14.camel@sirarchie.DOHEMM.DE> <20060629230048.1ea6d5f6.hamish_nospam@yahoo.com> <1152026085.5030.6.camel@sirarchie.DOHEMM.DE> <17578.48736.571982.372409@cerise.gclements.plus.com> Message-ID: <20060705182054.2b4c382f.hamish_nospam@yahoo.com> Glynn Clements wrote: > The /tmp/grass6-- directories contain per-session state > (the $GISRC file, as well as any sockets used for display monitors). > > There should be one such directory created for each session. They > should be deleted when the session terminates, but they are often left > behind. Stale directories shouldn't cause any problems, unless they > are owned by someone other than the user. Common reasons for /tmp/grass6--.. being left behind are when the GUI startup menu is given but the user presses Cancel, or when creating a new location from EPSG code on the startup GUI (exit & restart). >From looking at my /tmp dir I seem to accumulate them at a rate of about one every four days or uptime, FWTW. Hamish From benjamin.ducke at ufg.uni-kiel.de Wed Jul 5 10:20:56 2006 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Wed Jul 5 10:21:48 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: <20060704135721.GG21351@bartok.itc.it> References: <20060703164112.GN19781@bartok.itc.it> <20060704152632.09e9075d.hamish_nospam@yahoo.com> <20060704135721.GG21351@bartok.itc.it> Message-ID: <44AB7668.9060609@ufg.uni-kiel.de> I have one request concerning the GRASS configure script: would it be possible for configure to write a small one-line ASCII file into GISBASE/etc after a successful configuration, which contains all the options that the user passed to the configure script? Having such a file in a standard location would make it much easier to compile external modules with exactly the same external dependencies as the GRASS system installation. Best, Benjamin Markus Neteler wrote: > On Tue, Jul 04, 2006 at 12:26:16AM -0400, Helena Mitasova wrote: > ... > >>Some modules have problems running on 64bit (maybe that is also >>#4725? > > > The nviz volume bug was recently introduces, I think. As far > as I remember it worked some time ago on 64bit. > > https://intevation.de/rt/webrt?serial_num=4725 > " > I followed "mode" into lib/ogsf/GVL2.c GVL_slice_get_drawmode() > and then *gvl to gvl_get_vol() in lib/ogsf/gvl.c, but then I get lost. > " > > ? > > >>but it is for sure #4546 > > > https://intevation.de/rt/webrt?serial_num=4546 > r.sim.water crashes in simlib/input.c line 403, function grad_check(): > > if (cchez[k][l] != 0.) { > > with k=700 and l=0 > > Not sure why. > > > >>and supposedly also r.sun - probably due to uninitialized >>variables). > > > Right, It crashes in INPUT () at main.c:656 > if (z[i][j] == UNDEFZ || o[i][j] == UNDEFZ || s[i][j] == UNDEFZ) > > Here a Spearfish test script: > > ELEV=elevation.dem > TMP=$$ > SLOPE=$TMP.slope > ASP=$TMP.aspect > r.slope.aspect elevation.dem as=$TMP.aspect sl=$TMP.slope --o > r.mapcalc global_shadow.rad=0 > DAY=055 > r.sun -s elevin=elevation.dem aspin=$TMP.aspect slopein=$TMP.slope day=$DAY \ > beam_rad=bs_rad.$DAY diff_rad=ds_rad.$DAY refl_rad=rs_rad.$DAY > > > > >>I don't think that this should stop the release. > > > I would appreciate if those two bugs would be fixed, but we > can backport the fixes later. > > >>Also I believe that we should thoroughly test gis.m before release - >>we were getting all kinds of error messages but I think that it all >>has been fixed by now. > > > Yes, gis.m should get a consolidation cycle now. > > Markus > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From neteler at itc.it Wed Jul 5 11:42:18 2006 From: neteler at itc.it (Markus Neteler) Date: Wed Jul 5 11:42:20 2006 Subject: [GRASS-dev] Re: [bug #4437] (grass) v.in.ascii & 'Vector ASCII Format Specification' differ In-Reply-To: <20060704232107.a226afec.werchowyna@epf.pl> References: <20060704131621.1ADB31005CA@lists.intevation.de> <20060704232107.a226afec.werchowyna@epf.pl> Message-ID: <20060705094218.GB2923@bartok.itc.it> FWD to the list On Tue, Jul 04, 2006 at 11:21:07PM +0200, Maciek Sieczka wrote: > On Tue, 4 Jul 2006 15:16:21 +0200 (CEST) > Markus Neteler via RT wrote: > > > am I right that Hamish updated the manual? > > There was an update in the v.in.ascii manual. However, there are still > differences between the manual and > http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass6/doc/vector/vector.html#ascii > regarding vector feature types. > > v.in.ascci is missig the lowercase ("mark as deleted") types. Are they > still supported in Grass 6.1? v.in.ascii man contains more usefull > comments which are missing in "GRASS 5.7/6 Vector Format and API" > description. > > I believe both documents should give exactly the same information, to > avoid confussion. > > I don't know what is the right, actuall information though. > > Maciek From neteler at itc.it Wed Jul 5 11:43:03 2006 From: neteler at itc.it (Markus Neteler) Date: Wed Jul 5 11:43:05 2006 Subject: [GRASS-dev] Re: [bug #4786] (grass) r.sun crash on 64bit In-Reply-To: <20060704200230.199DB1006A9@lists.intevation.de> References: <20060704200230.199DB1006A9@lists.intevation.de> Message-ID: <20060705094303.GC2923@bartok.itc.it> On Tue, Jul 04, 2006 at 10:02:30PM +0200, Glynn Clements via RT wrote: > > Request Tracker wrote: > > > this bug's URL: http://intevation.de/rt/webrt?serial_num=4786 > > ------------------------------------------------------------------------- > > > > Subject: r.sun crash on 64bit > > I've committed a fix for this (untested, as I don't have a 64-bit > system to test). Glynn, excellent. Now r.sun works on 64bit. thanks Markus From rez at touchofmadness.com Wed Jul 5 12:03:32 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Wed Jul 5 12:03:44 2006 Subject: [GRASS-dev] G_make_aspect*_colors() broken Message-ID: <1152093812.2454.59.camel@devel> G_make_aspect*_colors() in lib/gis/color_asp.c is broken. It chooses (defaults to?) a greyscale ramp, rather than what is expected for aspect maps. Verified with r.slope.aspect and r.colors. -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From paul-grass at stjohnspoint.co.uk Wed Jul 5 13:11:59 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Wed Jul 5 13:12:04 2006 Subject: [GRASS-dev] Re: [bug #1140] (grass) Non-portable snprintf() used in several programs In-Reply-To: <20060704123813.F3AE41005CA@lists.intevation.de> References: <20060704123813.F3AE41005CA@lists.intevation.de> Message-ID: On Tue, 4 Jul 2006, Markus Neteler via RT wrote: > the snprintf() is used as of today in: > > ./raster3d/r3.in.ascii/main.c > ./db/drivers/dbf/dbfexe.c > ./raster/r.support/front/front.c > ./raster/r.support/front/check.c > ./raster/r.support/front/run.c > ./raster/r.support/modhead/check_un.c > ./raster/r.support/modhead/modhead.c > ./raster/r.support/modhead/ask_format.c > ./lib/init/clean_temp.c > ./lib/db/dbmi_client/select.c > ./lib/gis/user_config.c > ./lib/vector/dglib/examples/components.c Please see attached patch to replace use of snprintf in all those modules. I am posting it to the list first, hopefully for some comments, before committing. Have to admit what I was doing felt a bit pedantic towards the end. But some comments: Mostly what I have done is replaced snprintf writing into fixed size buffers by dynamically allocating space for the buffers based on the length of the strings that were being copied in. Where a formatted number was going in I allowed 32 characters to be on the safe side. In all but one example (./lib/init/clean_temp.c) snprintf() was being used without a check on the return value. So while a buffer overflow may have been avoided, if the string was truncated it would lead to unpredictable results later in the program. This won't happen now. Also in another case (./lib/gis/user_config.c) snprintf() was used with a buffer that had already been correctly dynamically sized, so it wasn't even needed there. Paul -------------- next part -------------- Index: db/drivers/dbf/dbfexe.c =================================================================== RCS file: /grassrepository/grass6/db/drivers/dbf/dbfexe.c,v retrieving revision 1.36 diff -u -r1.36 dbfexe.c --- db/drivers/dbf/dbfexe.c 9 Feb 2006 03:08:48 -0000 1.36 +++ db/drivers/dbf/dbfexe.c 5 Jul 2006 11:02:49 -0000 @@ -353,11 +353,11 @@ if( val->type == SQLP_I ){ val->d = (double)val->i; val->s = (char*)G_malloc (32*sizeof(char)); - snprintf( val->s, 32*sizeof(char), "%d", val->i ); + sprintf( val->s, "%d", val->i ); }else if( val->type == SQLP_D ){ val->i = (int)val->d; val->s = (char*)G_malloc (32*sizeof(char)); - snprintf( val->s, 32*sizeof(char), "%g", val->d ); + sprintf( val->s, "%g", val->d ); }else if( val->type == SQLP_S ){ val->i = atoi( val->s ); val->d = atof( val->s ); Index: lib/db/dbmi_client/select.c =================================================================== RCS file: /grassrepository/grass6/lib/db/dbmi_client/select.c,v retrieving revision 1.7 diff -u -r1.7 select.c --- lib/db/dbmi_client/select.c 30 May 2006 04:06:59 -0000 1.7 +++ lib/db/dbmi_client/select.c 5 Jul 2006 11:02:49 -0000 @@ -49,7 +49,7 @@ { int type, more, alloc, count; int *val; - char buf[1024], *sval; + char *buf, *sval; dbString stmt; dbCursor cursor; dbColumn *column; @@ -62,15 +62,20 @@ alloc = 1000; val = (int *) G_malloc ( alloc * sizeof(int)); - if ( where == NULL || strlen(where) == 0 ) - snprintf(buf,1023, "SELECT %s FROM %s", col, tab); - else - snprintf(buf,1023, "SELECT %s FROM %s WHERE %s", col, tab, where); + if ( where == NULL || strlen(where) == 0 ) { + buf = G_malloc(strlen(col) + strlen(tab) + 14); + sprintf(buf, "SELECT %s FROM %s", col, tab); + } + else { + buf = G_malloc(strlen(col) + strlen(tab) + strlen(where) + 21); + sprintf(buf, "SELECT %s FROM %s WHERE %s", col, tab, where); + } G_debug (3, " SQL: %s", buf ); db_init_string ( &stmt); db_append_string ( &stmt, buf); + G_free(buf); if (db_open_select_cursor(driver, &stmt, &cursor, DB_SEQUENTIAL) != DB_OK) return (-1); Index: lib/gis/user_config.c =================================================================== RCS file: /grassrepository/grass6/lib/gis/user_config.c,v retrieving revision 2.4 diff -u -r2.4 user_config.c --- lib/gis/user_config.c 16 Feb 2006 06:08:49 -0000 2.4 +++ lib/gis/user_config.c 5 Jul 2006 11:02:49 -0000 @@ -76,7 +76,7 @@ if ( NULL == ( path = G_calloc ( 1, len ) ) ) { return NULL; } - snprintf ( path, len, "%s%s", homedir, "/.grass" ); + sprintf ( path, "%s%s", homedir, "/.grass" ); #else me = getuid(); my_passwd = getpwuid (me); @@ -87,7 +87,7 @@ if (NULL == (path = G_calloc (1, len))) return NULL; - snprintf (path, len, "%s%s", my_passwd->pw_dir, "/.grass"); + sprintf (path, "%s%s", my_passwd->pw_dir, "/.grass"); #endif status = lstat (path, &buf); Index: lib/init/clean_temp.c =================================================================== RCS file: /grassrepository/grass6/lib/init/clean_temp.c,v retrieving revision 2.5 diff -u -r2.5 clean_temp.c --- lib/init/clean_temp.c 24 Jun 2006 19:33:03 -0000 2.5 +++ lib/init/clean_temp.c 5 Jul 2006 11:02:49 -0000 @@ -19,7 +19,6 @@ * * 2006: Rewritten for GRASS 6 by roberto Flor, ITC-irst * - * TODO (?): Implement snprintf() as G_snprintf() for portability **************************************************************/ #include @@ -39,7 +38,6 @@ void clean_dir(const char *pathname,uid_t uid,pid_t pid,time_t now,int max_age) { - char buf[BUF_MAX]; DIR *curdir; struct dirent *cur_entry; struct stat info; @@ -53,11 +51,16 @@ /* loop over current dir */ while ((cur_entry = readdir(curdir))) { - if ((G_strcasecmp(cur_entry->d_name,".") == 0 )|| (G_strcasecmp(cur_entry->d_name,"..")==0)) + static char *buf = NULL; + + if ((G_strcasecmp(cur_entry->d_name,".") == 0 )|| (G_strcasecmp(cur_entry->d_name,"..")==0)) continue; /* Skip dir and parent dir entries */ - - if ( (pathlen=snprintf(buf,BUF_MAX,"%s/%s",pathname,cur_entry->d_name)) >= BUF_MAX) - G_fatal_error("clean_temp: exceeded maximum pathname length %d, got %d, should'nt happen",BUF_MAX,pathlen); + + if(buf) + G_free(buf); + + buf = G_malloc(strlen(pathname) + strlen(cur_entry->d_name) + 2); + sprintf(buf, "%s/%s", pathname, cur_entry->d_name); if (stat(buf, &info) != 0) { G_warning("Can't stat file %s: %s,skipping\n",buf,strerror(errno)); Index: lib/vector/dglib/examples/components.c =================================================================== RCS file: /grassrepository/grass6/lib/vector/dglib/examples/components.c,v retrieving revision 1.4 diff -u -r1.4 components.c --- lib/vector/dglib/examples/components.c 3 Jan 2006 08:50:48 -0000 1.4 +++ lib/vector/dglib/examples/components.c 5 Jul 2006 11:02:49 -0000 @@ -50,7 +50,7 @@ #define MY_MAX_COMPONENTS 1024 dglGraph_s agraphComponents[MY_MAX_COMPONENTS]; int nret , fd , i , cComponents; - char szGraphOutFilename[1024]; + char *pszGraphOutFilename; /* program options */ @@ -109,11 +109,14 @@ if ( dglGet_EdgeCount( & agraphComponents[i] ) > 0 ) { if ( pszGraphOut ) { - snprintf( szGraphOutFilename, sizeof(szGraphOutFilename), "%s-component-%d", pszGraphOut, i ); - printf( "[write <%s>...", szGraphOutFilename ); fflush(stdout); - if ( (fd = open( szGraphOutFilename , O_WRONLY | O_CREAT | O_TRUNC, 0666 )) < 0 ) { + pszGraphOutFilename = G_malloc(strlen(pszGraphOut) + 12 + 32); + sprintf( pszGraphOutFilename, "%s-component-%d", pszGraphOut, i ); + printf( "[write <%s>...", pszGraphOutFilename ); fflush(stdout); + if ( (fd = open( pszGraphOutFilename , O_WRONLY | O_CREAT | O_TRUNC, 0666 )) < 0 ) { perror( "open" ); return 1; } + else + G_free(pszGraphOutFilename); dglWrite( & agraphComponents[i], fd ); if ( nret < 0 ) { fprintf( stderr , "dglWrite error: %s\n" , dglStrerror( & graph ) ); Index: raster/r.support/front/check.c =================================================================== RCS file: /grassrepository/grass6/raster/r.support/front/check.c,v retrieving revision 1.3 diff -u -r1.3 check.c --- raster/r.support/front/check.c 9 Feb 2006 03:09:03 -0000 1.3 +++ raster/r.support/front/check.c 5 Jul 2006 11:02:49 -0000 @@ -1,4 +1,5 @@ #include +#include #include #include #include "local_proto.h" @@ -19,17 +20,25 @@ int i; int cats_ok; int max; - char question[100]; - + char *buff; + /* NOTE: G_yes() return value 1 = hitreturn(), 0 otherwise */ data_type = G_raster_map_type(name, mapset); /* Exit if not updating statistics */ - snprintf(question, sizeof(question), _("Update the statistics " - "(histogram, range) for [%s]? "), name); - if (!G_yes(question, 0)) + { + const char *question = _("Update the statistics " + "(histogram, range) for [%s]? "); + + buff = G_malloc(strlen(question) + strlen(name) - 1); + sprintf(buff, question, name); + } + + if (!G_yes(buff, 0)) return EXIT_FAILURE; + else + G_free(buff); G_message(_("\n Updating statistics for [%s]"), name); if (!do_histogram(name, mapset)) Index: raster/r.support/front/front.c =================================================================== RCS file: /grassrepository/grass6/raster/r.support/front/front.c,v retrieving revision 1.6 diff -u -r1.6 front.c --- raster/r.support/front/front.c 27 Mar 2006 08:13:58 -0000 1.6 +++ raster/r.support/front/front.c 5 Jul 2006 11:02:49 -0000 @@ -39,7 +39,6 @@ struct Cell_head cellhd; struct GModule *module; struct Option *raster, *title_opt, *history_opt; - char element[255]; char buf[512]; int cellhd_ok; /* Is cell header OK? */ int is_reclass; /* Is raster reclass? */ @@ -178,6 +177,7 @@ unsigned char *null_bits; int row, col; int null_fd; + char *element; if (is_reclass) G_fatal_error(_("[%s] is a reclass of another map. Exiting."), raster->answer); @@ -189,8 +189,10 @@ null_bits[col] = 0; /* Open null file for writing */ + element = G_malloc(strlen(raster->answer) + 11); sprintf(element, "cell_misc/%s", raster->answer); null_fd = G_open_new(element, "null"); + G_free(element); G_message(_("Writing new null file for [%s]... "), raster->answer); for (row = 0; row < cellhd.rows; row++) { @@ -212,7 +214,8 @@ "(all zero cells will then be considered no data)? "), raster->answer); if (G_yes(buf, 0)) { int null_fd; - char path[400]; + char path[1024]; + char *element; if (is_reclass) G_fatal_error(_("[%s] is a reclass of another map. Exiting."), raster->answer); @@ -222,10 +225,12 @@ /* Write a file of no-nulls */ G_message(_("Removing null file for [%s]...\n"), raster->answer); - snprintf(element, sizeof(element), "cell_misc/%s", raster->answer); + element = G_malloc(strlen(raster->answer) + 11); + sprintf(element, "cell_misc/%s", raster->answer); null_fd = G_open_new(element, "null"); G__file_name(path, element, "null", mapset); unlink(path); + G_free(element); close(null_fd); G_done_msg(_("Done.")); Index: raster/r.support/front/run.c =================================================================== RCS file: /grassrepository/grass6/raster/r.support/front/run.c,v retrieving revision 1.4 diff -u -r1.4 run.c --- raster/r.support/front/run.c 9 Feb 2006 03:09:03 -0000 1.4 +++ raster/r.support/front/run.c 5 Jul 2006 11:02:49 -0000 @@ -1,5 +1,6 @@ #include #include +#include #include @@ -10,14 +11,17 @@ */ int run_etc_support(char *pgm, char *rast) { - char buf[1024]; + const char *gisbase = G_gisbase(); + char *buf; int stat; - snprintf(buf, sizeof(buf), "%s/etc/support/%s '%s'", - G_gisbase(), pgm, rast); + buf = G_malloc(strlen(gisbase) + strlen(pgm) + strlen(rast) + 17); + sprintf(buf, "%s/etc/support/%s '%s'", gisbase, pgm, rast); if ((stat = G_system(buf))) G_sleep(3); + + G_free(buf); return stat; } @@ -30,11 +34,9 @@ */ int run_system(char *pgm) { - char buf[1024]; int stat; - snprintf(buf, sizeof(buf), "%s", pgm); - if ((stat = G_system(buf))) + if ((stat = G_system(pgm))) G_sleep(3); return stat; Index: raster/r.support/modhead/ask_format.c =================================================================== RCS file: /grassrepository/grass6/raster/r.support/modhead/ask_format.c,v retrieving revision 1.2 diff -u -r1.2 ask_format.c --- raster/r.support/modhead/ask_format.c 9 Feb 2006 03:09:03 -0000 1.2 +++ raster/r.support/modhead/ask_format.c 5 Jul 2006 11:02:49 -0000 @@ -15,17 +15,23 @@ { RASTER_MAP_TYPE maptype; char title[80]; - char buf[80]; + char *buf; char no_zeros[80]; G_zero(no_zeros, (int)sizeof(no_zeros)); maptype = G_raster_map_type(name, G_mapset()); - snprintf(title, sizeof(title), _("Please enter the following " - "information for [%s]:"), name); + { + const char *question = _("Please enter the following " + "information for [%s]:"); + + buf = G_malloc(strlen(question) + strlen(name) - 1); + sprintf(buf, question, name); + } V_clear(); - V_line(0, title); + V_line(0, buf); + G_free(buf); V_line(2, _(" Number of rows")); V_line(3, _(" Number of cols")); V_line(4, (maptype == CELL_TYPE ? @@ -46,9 +52,16 @@ if (maptype == CELL_TYPE && cellhd->compressed == 0 && cellhd->rows * cellhd->cols * cellhd->format != filesize) { - snprintf(buf, sizeof(buf), _("rows * cols * bytes per cell " - "must be same as file size (%ld)"), filesize); + { + const char *question = _("rows * cols * bytes per cell " + "must be same as file size (%ld)"); + + buf = G_malloc(strlen(question) + 32); + sprintf(buf, question, filesize); + } + V_line(6, buf); + G_free(buf); V_line(7, _("If you need help figuring them out, just hit ESC")); } V_line(10, no_zeros); @@ -72,7 +85,7 @@ break; strcpy(no_zeros, _("** Negative values not allowed!")); - } else + } else strcpy(no_zeros, _("** Positive values only please!")); } Index: raster/r.support/modhead/check_un.c =================================================================== RCS file: /grassrepository/grass6/raster/r.support/modhead/check_un.c,v retrieving revision 1.3 diff -u -r1.3 check_un.c --- raster/r.support/modhead/check_un.c 9 Feb 2006 03:09:03 -0000 1.3 +++ raster/r.support/modhead/check_un.c 5 Jul 2006 11:02:49 -0000 @@ -19,7 +19,7 @@ long filesize_calc; FILE *fd; static char *tempfile = NULL; - char command[256]; + char *command; /* Check for bad file size */ filesize_calc = cellhd->rows * cellhd->cols * cellhd->format; @@ -59,8 +59,10 @@ fclose(fd); /* display valid combinations */ - snprintf(command, sizeof(command), "$GRASS_PAGER %s", tempfile); + command = G_malloc(strlen(tempfile) + 14); + sprintf(command, "$GRASS_PAGER %s", tempfile); G_system(command); + G_free(command); /* remove temp file */ unlink(tempfile); Index: raster/r.support/modhead/modhead.c =================================================================== RCS file: /grassrepository/grass6/raster/r.support/modhead/modhead.c,v retrieving revision 1.4 diff -u -r1.4 modhead.c --- raster/r.support/modhead/modhead.c 9 Feb 2006 03:09:03 -0000 1.4 +++ raster/r.support/modhead/modhead.c 5 Jul 2006 11:02:49 -0000 @@ -197,7 +197,15 @@ /* If we create a new cell header, find out if file is compressed */ if (!cellhd_ok) { - snprintf(buffer, sizeof(buffer), _("[%s] appears to be compressed. Is it? "), name); + char *buff; + + { + const char *query = _("[%s] appears to be compressed. Is it? "); + + buff = G_malloc(strlen(query) + strlen(name) - 1); + sprintf(buff, query, name); + } + cellhd.compressed = 0; if ((compressed_new || compressed_old) && G_yes(buffer, -1)) { @@ -236,6 +244,7 @@ cellhd.rows = rows_old; } } + G_free(buff); } else { if ((cellhd.compressed < 0) && !compressed_old) cellhd.compressed = 0; Index: raster3d/r3.in.ascii/main.c =================================================================== RCS file: /grassrepository/grass6/raster3d/r3.in.ascii/main.c,v retrieving revision 2.3 diff -u -r2.3 main.c --- raster3d/r3.in.ascii/main.c 9 Feb 2006 03:09:04 -0000 2.3 +++ raster3d/r3.in.ascii/main.c 5 Jul 2006 11:02:49 -0000 @@ -120,11 +120,14 @@ readHeaderString (FILE *fp, char *valueString, double *value) { - static char format[100]; + char *format; - snprintf (format, 100, "%s %%lf", valueString); /*to avoid bufferoverflows we use snprintf*/ + format = G_malloc(strlen(valueString) + 5); + sprintf(format, "%s %%lf", valueString); if (fscanf (fp, format, value) != 1) fatalError ("readHeaderString: header value invalid"); + + G_free(format); while (fgetc (fp) != '\n'); } From hamish_nospam at yahoo.com Wed Jul 5 16:12:30 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jul 5 16:12:35 2006 Subject: [GRASS-dev] Re: [bug #4437] (grass) v.in.ascii & 'Vector ASCII Format Specification' differ In-Reply-To: <20060705094218.GB2923@bartok.itc.it> References: <20060704131621.1ADB31005CA@lists.intevation.de> <20060704232107.a226afec.werchowyna@epf.pl> <20060705094218.GB2923@bartok.itc.it> Message-ID: <20060706021230.453a3c3f.hamish_nospam@yahoo.com> "v.in.ascii & 'Vector ASCII Format Specification' differ" https://intevation.de/rt/webrt?serial_num=4437 Markus: > > > am I right that Hamish updated the manual? yes, sorry I should have closed this bug some time ago. [doing so now] Maciek: > > There was an update in the v.in.ascii manual. more to the point, the vector specification linked below was updated to meet reality. > > However, there are still differences between the manual and > > http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass6/doc/vector/vector.html#ascii > > regarding vector feature types. > > > > v.in.ascci is missig the lowercase ("mark as deleted") types. I don't think it's a problem, the lower case versions aren't worthy of mention in the v.in.ascii help page as they represent deleted features which will be skipped during import. > > Are they still supported in Grass 6.1? yes, but that just means that they are ignored. > > v.in.ascii man contains more usefull comments which are missing in > > "GRASS 5.7/6 Vector Format and API" description. the vector format specification is not a tutorial. which comments do you think should be added to the specification? > > I believe both documents should give exactly the same information, > > to avoid confussion. yes, the technical info should (& does?) match, but I don't think we should clutter the specification with redundant examples. > > I don't know what is the right, actuall information though. no erroneous info should remain. reopen the bug if you see a conflict. Hamish From michael.barton at asu.edu Wed Jul 5 16:38:30 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Jul 5 16:38:35 2006 Subject: [GRASS-dev] Re: grass-dev Digest, Vol 3, Issue 8 In-Reply-To: <200607050636.k656Zxb4010372@grass.itc.it> Message-ID: When I get back, should I go through and get rid of all occurrences of eval exec? I noticed that Cedric introduced a different form "exec $cmd [list arg arg art...] Is this even better or unnecessary? 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: > Reply-To: > Date: Wed, 5 Jul 2006 08:35:59 +0200 > To: > Subject: grass-dev Digest, Vol 3, Issue 8 > > The above should be: > > exec gdal_translate $path.ppm $path.tif -of GTIFF > exec rm $path.ppm > > I strongly suspect that the same issue applies to most (if not all) of > the other occurrences of "eval exec ..." in gis.m (a quick "grep" > finds 50 of them). From michael.barton at asu.edu Wed Jul 5 16:43:10 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Jul 5 16:43:15 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: <44AB7668.9060609@ufg.uni-kiel.de> Message-ID: Benjamin, I don't think this would work for precompiled binaries. They may be installed on a system that doesn't have some of the dependencies. For example, you can compile with MySQL support and then put GRASS on a system without MySQL. 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: Benjamin Ducke > Date: Wed, 05 Jul 2006 10:20:56 +0200 > Cc: > Subject: Re: [GRASS-dev] GRASS 6.1.0 release preparation > > I have one request concerning the GRASS configure script: > would it be possible for configure to write a small one-line > ASCII file into GISBASE/etc after a successful configuration, > which contains all the options that the user passed to the > configure script? > > Having such a file in a standard location would make it > much easier to compile external modules with exactly the > same external dependencies as the GRASS system installation. > > Best, > > Benjamin > > Markus Neteler wrote: >> On Tue, Jul 04, 2006 at 12:26:16AM -0400, Helena Mitasova wrote: >> ... >> >>> Some modules have problems running on 64bit (maybe that is also >>> #4725? >> >> >> The nviz volume bug was recently introduces, I think. As far >> as I remember it worked some time ago on 64bit. >> >> https://intevation.de/rt/webrt?serial_num=4725 >> " >> I followed "mode" into lib/ogsf/GVL2.c GVL_slice_get_drawmode() >> and then *gvl to gvl_get_vol() in lib/ogsf/gvl.c, but then I get lost. >> " >> >> ? >> >> >>> but it is for sure #4546 >> >> >> https://intevation.de/rt/webrt?serial_num=4546 >> r.sim.water crashes in simlib/input.c line 403, function grad_check(): >> >> if (cchez[k][l] != 0.) { >> >> with k=700 and l=0 >> >> Not sure why. >> >> >> >>> and supposedly also r.sun - probably due to uninitialized >>> variables). >> >> >> Right, It crashes in INPUT () at main.c:656 >> if (z[i][j] == UNDEFZ || o[i][j] == UNDEFZ || s[i][j] == >> UNDEFZ) >> >> Here a Spearfish test script: >> >> ELEV=elevation.dem >> TMP=$$ >> SLOPE=$TMP.slope >> ASP=$TMP.aspect >> r.slope.aspect elevation.dem as=$TMP.aspect sl=$TMP.slope --o >> r.mapcalc global_shadow.rad=0 >> DAY=055 >> r.sun -s elevin=elevation.dem aspin=$TMP.aspect slopein=$TMP.slope day=$DAY \ >> beam_rad=bs_rad.$DAY diff_rad=ds_rad.$DAY refl_rad=rs_rad.$DAY >> >> >> >> >>> I don't think that this should stop the release. >> >> >> I would appreciate if those two bugs would be fixed, but we >> can backport the fixes later. >> >> >>> Also I believe that we should thoroughly test gis.m before release - >>> we were getting all kinds of error messages but I think that it all >>> has been fixed by now. >> >> >> Yes, gis.m should get a consolidation cycle now. >> >> Markus >> >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev >> >> > > -- > Benjamin Ducke, M.A. > Arch?oinformatik > (Archaeoinformation Science) > Institut f?r Ur- und Fr?hgeschichte > (Inst. of Prehistoric and Historic Archaeology) > Christian-Albrechts-Universit?t zu Kiel > Johanna-Mestorf-Stra?e 2-6 > D 24098 Kiel > Germany > > Tel.: ++49 (0)431 880-3378 / -3379 > Fax : ++49 (0)431 880-7300 > www.uni-kiel.de/ufg > > From hamish_nospam at yahoo.com Wed Jul 5 17:02:45 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jul 5 17:02:50 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: References: <20060703164112.GN19781@bartok.itc.it> <20060704152632.09e9075d.hamish_nospam@yahoo.com> Message-ID: <20060706030245.4f694334.hamish_nospam@yahoo.com> Helena wrote: > Some modules have problems running on 64bit (maybe that is also #4725? 4725 (NVIZ segfaults with volumes) happens for me on a 32-bit P4 using both TclTk 8.3 and 8.4. https://intevation.de/rt/webrt?serial_num=4725 Hamish From grass-bugs at intevation.de Wed Jul 5 17:25:00 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Wed Jul 5 17:25:03 2006 Subject: [GRASS-dev] [bug #4794] (grass) r.thin Message-ID: <20060705152500.D4BA61006B6@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4794 ------------------------------------------------------------------------- Subject: r.thin Hi, I'm using r.thin command, and it seems that it changes Nodata value cells of the original raster (surrounding cells obtained after the gereference operation of à scanned map) to the value 1. Hence, I get an error message when I try to use r.to.vect command because of these surrounding cells that have the value 1 instead of Nodata and that constitute an area instead of a simple line. Does soemone already had this problem, how can it be avoid, is it possible to change nodata value to 0 for example (Nodata is not allowed in the value to recode with reclass command)? Thanks -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Wed Jul 5 20:17:29 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Wed Jul 5 20:17:30 2006 Subject: [GRASS-dev] [bug #4794] (grass) r.thin Message-ID: <20060705181729.2A5861005B8@lists.intevation.de> Hi > Hi, I'm using r.thin command, and it seems that it changes Nodata value > cells of the original raster (surrounding cells obtained after the > gereference operation of à scanned map) to the value 1 Could you put screenshots that explain your problem (and the input and problematic output data if possible) somewhere? What was your r.thin syntax exactly? What Grass version? Platform? > Does soemone already had this problem, I haven't, I think. > is it possible to change nodata value to 0 for example r.null? Maciek -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Wed Jul 5 20:39:04 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Wed Jul 5 20:39:06 2006 Subject: [GRASS-dev] [bug #3877] (grass) r.to.vect, v.in.ascii use too much memory for millions of points Message-ID: <20060705183904.4D5031005B9@lists.intevation.de> Markus wrote: > New patch submitted, see > > https://intevation.de/rt/webrt?serial_num=3354&display=History > > Does it solve the problem? So I checked with current CVS and the same problem still applies to r.to.vect. "r.to.vect -z feature=point input=dem_5 output=dem_5_pt" eats up all 1GB RAM + 1GB SWAP at about 5 000 000 points. The above mentioned Andrew Danner's fix for v.in.ascii is great stuff but r.to.vect problem remains (in my bug report I was complaining about only r.to.vect, few days later Hamish changed the subject, as v.in.ascii issue popped up during discussion). Is it possible that r.to.vect suffers from a similar problem as v.in.ascii did, so a similar fix would do? Andrew? Maciek -------------------------------------------- Managed by Request Tracker From adanner at cs.duke.edu Wed Jul 5 21:09:02 2006 From: adanner at cs.duke.edu (Andrew Danner) Date: Wed Jul 5 21:09:05 2006 Subject: [GRASS-dev] Re: [bug #3877] (grass) r.to.vect, v.in.ascii use too much memory for millions of points In-Reply-To: <20060705183904.4D5031005B9@lists.intevation.de> References: <20060705183904.4D5031005B9@lists.intevation.de> Message-ID: <1152126542.5695.28.camel@localhost> Maciek, My initial guess is that r.to.vect suffers from a similar bug/feature that plagued v.in.ascii awhile ago and that is the building of vector topology. As it stands now, r.to.vect calls Vect_build after processing all the features and this is the same function call that ate all the memory in v.in.ascii. The solution for v.in.ascii was to add another flag "-b" to skip topology building in points mode. The rest of the r.to.vect code looks pretty clean and I don't immediately expect memory leaks. Radim has said many times that there are not leaks in the Vect_build code, but the memory requirements are high for the topology building. Without looking into the Vect_build code, I tend to believe Radim, so if you want to extract 5 000 000 points from a raster you will need to skip the topology. Note that many vector modules are not able to use vector layers without topology (v.surf.rst being the primary execption), so the "-b" flag is more of a workaround than a long term solution. I haven't had a chance to look into the Vect_build code and see if there is a way to reduce memory usage. Is there any white paper or technical specs on how the new vector library is organized and what the vector topology looks like? -Andy On Wed, 2006-07-05 at 20:39 +0200, Maciek Sieczka via RT wrote: > Markus wrote: > > > New patch submitted, see > > > > https://intevation.de/rt/webrt?serial_num=3354&display=History > > > > Does it solve the problem? > > So I checked with current CVS and the same problem still applies to r.to.vect. > > "r.to.vect -z feature=point input=dem_5 output=dem_5_pt" eats up all 1GB RAM + > 1GB SWAP at about 5 000 000 points. > > The above mentioned Andrew Danner's fix for v.in.ascii is great stuff but > r.to.vect problem remains (in my bug report I was complaining about only > r.to.vect, few days later Hamish changed the subject, as v.in.ascii issue > popped up during discussion). > > Is it possible that r.to.vect suffers from a similar problem as v.in.ascii > did, so a similar fix would do? Andrew? > > Maciek > > > -------------------------------------------- Managed by Request Tracker From neteler at itc.it Wed Jul 5 23:52:00 2006 From: neteler at itc.it (Markus Neteler) Date: Wed Jul 5 23:52:02 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: <44AB7668.9060609@ufg.uni-kiel.de> References: <20060703164112.GN19781@bartok.itc.it> <20060704152632.09e9075d.hamish_nospam@yahoo.com> <20060704135721.GG21351@bartok.itc.it> <44AB7668.9060609@ufg.uni-kiel.de> Message-ID: <20060705215200.GD24748@bartok.itc.it> On Wed, Jul 05, 2006 at 10:20:56AM +0200, Benjamin Ducke wrote: > I have one request concerning the GRASS configure script: > would it be possible for configure to write a small one-line > ASCII file into GISBASE/etc after a successful configuration, > which contains all the options that the user passed to the > configure script? Hi, not sure if such line would be portable. But you could fetch it here: head -7 config.status | tail -1 Markus > Having such a file in a standard location would make it > much easier to compile external modules with exactly the > same external dependencies as the GRASS system installation. > > Best, > > Benjamin > > Markus Neteler wrote: > >On Tue, Jul 04, 2006 at 12:26:16AM -0400, Helena Mitasova wrote: > >... > > > >>Some modules have problems running on 64bit (maybe that is also > >>#4725? > > > > > >The nviz volume bug was recently introduces, I think. As far > >as I remember it worked some time ago on 64bit. > > > >https://intevation.de/rt/webrt?serial_num=4725 > >" > > I followed "mode" into lib/ogsf/GVL2.c GVL_slice_get_drawmode() > > and then *gvl to gvl_get_vol() in lib/ogsf/gvl.c, but then I get lost. > >" > > > >? > > > > > >>but it is for sure #4546 > > > > > >https://intevation.de/rt/webrt?serial_num=4546 > >r.sim.water crashes in simlib/input.c line 403, function grad_check(): > > > > if (cchez[k][l] != 0.) { > > > > with k=700 and l=0 > > > >Not sure why. > > > > > > > >>and supposedly also r.sun - probably due to uninitialized > >>variables). > > > > > >Right, It crashes in INPUT () at main.c:656 > > if (z[i][j] == UNDEFZ || o[i][j] == UNDEFZ || s[i][j] == > > UNDEFZ) > > > >Here a Spearfish test script: > > > >ELEV=elevation.dem > >TMP=$$ > >SLOPE=$TMP.slope > >ASP=$TMP.aspect > >r.slope.aspect elevation.dem as=$TMP.aspect sl=$TMP.slope --o > >r.mapcalc global_shadow.rad=0 > >DAY=055 > >r.sun -s elevin=elevation.dem aspin=$TMP.aspect slopein=$TMP.slope > >day=$DAY \ > > beam_rad=bs_rad.$DAY diff_rad=ds_rad.$DAY refl_rad=rs_rad.$DAY > > > > > > > > > >>I don't think that this should stop the release. > > > > > >I would appreciate if those two bugs would be fixed, but we > >can backport the fixes later. > > > > > >>Also I believe that we should thoroughly test gis.m before release - > >>we were getting all kinds of error messages but I think that it all > >>has been fixed by now. > > > > > >Yes, gis.m should get a consolidation cycle now. > > > >Markus > > > > > >_______________________________________________ > >grass-dev mailing list > >grass-dev@grass.itc.it > >http://grass.itc.it/mailman/listinfo/grass-dev > > > > > > -- > Benjamin Ducke, M.A. > Arch?oinformatik > (Archaeoinformation Science) > Institut f?r Ur- und Fr?hgeschichte > (Inst. of Prehistoric and Historic Archaeology) > Christian-Albrechts-Universit?t zu Kiel > Johanna-Mestorf-Stra?e 2-6 > D 24098 Kiel > Germany > > Tel.: ++49 (0)431 880-3378 / -3379 > Fax : ++49 (0)431 880-7300 > www.uni-kiel.de/ufg > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Markus Neteler http://mpa.itc.it/markus/ ITC-irst - Centro per la Ricerca Scientifica e Tecnologica MPBA - Predictive Models for Biol. & Environ. Data Analysis Via Sommarive, 18 - 38050 Povo (Trento), Italy From neteler at itc.it Thu Jul 6 00:00:33 2006 From: neteler at itc.it (Markus Neteler) Date: Thu Jul 6 00:00:35 2006 Subject: [GRASS-dev] Re: [bug #3877] (grass) r.to.vect, v.in.ascii use too much memory for millions of points In-Reply-To: <1152126542.5695.28.camel@localhost> References: <20060705183904.4D5031005B9@lists.intevation.de> <1152126542.5695.28.camel@localhost> Message-ID: <20060705220033.GE24748@bartok.itc.it> Andrew, On Wed, Jul 05, 2006 at 03:09:02PM -0400, Andrew Danner wrote: ... > I haven't had a chance to look into the Vect_build code and see if > there is a way to reduce memory usage. Is there any white paper or > technical specs on how the new vector library is organized and what the > vector topology looks like? there is a document here (part of the programmer's manual): http://mpa.itc.it/markus/grass61progman/Vector_Library.html That what I could extract from Radim and sketch up :-) It's generated from the (aprtially) doxygenized source code. Markus > -Andy > > > On Wed, 2006-07-05 at 20:39 +0200, Maciek Sieczka via RT wrote: > > Markus wrote: > > > > > New patch submitted, see > > > > > > https://intevation.de/rt/webrt?serial_num=3354&display=History > > > > > > Does it solve the problem? > > > > So I checked with current CVS and the same problem still applies to r.to.vect. > > > > "r.to.vect -z feature=point input=dem_5 output=dem_5_pt" eats up all 1GB RAM + > > 1GB SWAP at about 5 000 000 points. > > > > The above mentioned Andrew Danner's fix for v.in.ascii is great stuff but > > r.to.vect problem remains (in my bug report I was complaining about only > > r.to.vect, few days later Hamish changed the subject, as v.in.ascii issue > > popped up during discussion). > > > > Is it possible that r.to.vect suffers from a similar problem as v.in.ascii > > did, so a similar fix would do? Andrew? > > > > Maciek > > > > > > -------------------------------------------- Managed by Request Tracker > -- Markus Neteler http://mpa.itc.it/markus/ ITC-irst - Centro per la Ricerca Scientifica e Tecnologica MPBA - Predictive Models for Biol. & Environ. Data Analysis Via Sommarive, 18 - 38050 Povo (Trento), Italy From werchowyna at epf.pl Thu Jul 6 00:05:32 2006 From: werchowyna at epf.pl (Maciek Sieczka) Date: Thu Jul 6 00:05:27 2006 Subject: [GRASS-dev] Re: [bug #3877] (grass) r.to.vect, v.in.ascii use too much memory for millions of points In-Reply-To: <1152126542.5695.28.camel@localhost> References: <20060705183904.4D5031005B9@lists.intevation.de> <1152126542.5695.28.camel@localhost> Message-ID: <20060706000532.553858f1.werchowyna@epf.pl> Andrew, I first thought that your v.in.ascii fix enabled v.in.ascii to load huge datasets *not* skipping the topology. After your clarification now I see it was my mistake. Sorry if confusing. Although I realize how important it is for many of us to be able to load huge point datasets in any possible way, for now, like using this no-topology hack, I hope there will one day be a real solution for Grass to be able to process such big datasets in a normal, topological way. Because propably the no-topology hack will be not suitable for anything else besides points and propably we can't expect every single vector module to be extended to support both non-topological and topological vectors - also because there are GIS operations which simply require a topological data model. The few 10^6 number of features limit is a serious limitation in current Grass vector engine. I wouldn't consider the bug solved, even regarding v.in.ascii alone. But I do really appreciate all your effort towards making out as much as possible of v.in.ascii for the moment. Thank you. Maciek -------------------- W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich! http://katalog.panoramainternetu.pl/ From grass-bugs at intevation.de Thu Jul 6 00:08:45 2006 From: grass-bugs at intevation.de (Markus Neteler via RT) Date: Thu Jul 6 00:08:47 2006 Subject: [GRASS-dev] [bug #4794] (grass) r.thin Message-ID: <20060705220845.732351005C5@lists.intevation.de> Hi, r.thin works (in GRASS 6.1-CVS). Quick test: GRASS 6.1.cvs (spearfish60): > g.region -dp projection: 1 (UTM) zone: 13 datum: nad27 ellipsoid: clark66 north: 4928010 south: 4913700 west: 589980 east: 609000 nsres: 30 ewres: 30 rows: 477 cols: 634 r.thin fields out=fields_skeleton File fields -- 477 rows X 634 columns Bounding box: l = 3, r = 635, t = 2, b = 468 Pass number 1 Deleted 5632 pixels Pass number 2 ... Pass number 81 Deleted 0 pixels Thinning completed successfully. Output file 477 rows X 634 columns Window 477 rows X 634 columns d.mon x0 d.rast fields_skeleton # -> looks ok, no data are present r.univar fields_skeleton 100% total null and non-null cells: 302418 total null cells: 299926 <-- no data are there ! Of the non-null cells: ---------------------- n: 2492 minimum: 1 maximum: 63 range: 62 mean: 44.7364 standard deviation: 21.6878 variance: 470.363 variation coefficient: 48.4792 % sum: 111483 I suspect that the original map doesn't have NULL where you think they should be. You can verify it with d.what.rast. I don't see a problem in r.thin (note that we fixed it in April): 2006-04-04 17:07 markus * main.c: increased to 200 iterations default 2006-04-04 17:06 markus * thin_lines.c: fixed max iterations 2006-04-04 16:48 markus * local_proto.h, main.c, thin_lines.c: added iterations parameter. Added exit error message if failure. Fixed wording. Increased default iterations Markus -------------------------------------------- Managed by Request Tracker From neteler at itc.it Thu Jul 6 00:13:09 2006 From: neteler at itc.it (Markus Neteler) Date: Thu Jul 6 00:13:11 2006 Subject: [GRASS-dev] Re: [GRASS-user] Can't create location In-Reply-To: <20060705182054.2b4c382f.hamish_nospam@yahoo.com> References: <1151503551.6619.6.camel@sirarchie.DOHEMM.DE> <20060628164852.673918d1@butan.gdf-hannover.de> <1151508601.6619.14.camel@sirarchie.DOHEMM.DE> <20060629230048.1ea6d5f6.hamish_nospam@yahoo.com> <1152026085.5030.6.camel@sirarchie.DOHEMM.DE> <17578.48736.571982.372409@cerise.gclements.plus.com> <20060705182054.2b4c382f.hamish_nospam@yahoo.com> Message-ID: <20060705221309.GF24748@bartok.itc.it> On Wed, Jul 05, 2006 at 06:20:54PM +1200, Hamish wrote: > Glynn Clements wrote: > > > The /tmp/grass6-- directories contain per-session state > > (the $GISRC file, as well as any sockets used for display monitors). > > > > There should be one such directory created for each session. They > > should be deleted when the session terminates, but they are often left > > behind. Stale directories shouldn't cause any problems, unless they > > are owned by someone other than the user. > > > Common reasons for /tmp/grass6--.. being left behind are when the > GUI startup menu is given but the user presses Cancel, ... which should be possible to get fixed in lib/init/gis_set.tcl around line 592 ? > or when creating > a new location from EPSG code on the startup GUI (exit & restart). Same thing, same file ? I leave this to a tcltk coder (hi Michael :-), Markus From neteler at itc.it Thu Jul 6 00:16:56 2006 From: neteler at itc.it (Markus Neteler) Date: Thu Jul 6 00:16:58 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: <17578.51015.472978.97302@cerise.gclements.plus.com> References: <44AA1776.5000702@itc.it> <44AA1B9E.1000703@ufg.uni-kiel.de> <20060704101049.4c29d852@butan.gdf-hannover.de> <17578.51015.472978.97302@cerise.gclements.plus.com> Message-ID: <20060705221656.GG24748@bartok.itc.it> On Tue, Jul 04, 2006 at 08:53:43PM +0100, Glynn Clements wrote: > > Stephan Holl wrote: > > > > Are the any (detailed) instructions for how to build and package > > > a native QGIS + GRASS distribution from the regular GRASS CVS > > > repository? > > > > > > I would love to add my archaeology modules and produce a version > > > of GRASS for my colleagues working on Win32 systems. > > > I am sure this could hit big in a science with low budget and > > > very specific GIS needs. > > > > lemmi jump in here and give you the link to Radims detailed description > > how to build GRASS/QGIS on windows[1]. > > It would be more useful to have a guide to building a native Windows > version on Windows, rather than having to cross-compile. Agreed. Do you have a suggestion for a free (freedom) compiler? Maybe obvious, but I am not informed. > Also, it would be useful to offer pre-compiled Windows binaries of > essential libraries (proj, GDAL etc). These could be published as by-product of GRASS, for now as cross-compiled version. There is however an outstanding issue with proj (nad2nad is not called within MinGW, so the NAD grid import fails when cross-compiling). Markus From neteler at itc.it Thu Jul 6 00:59:01 2006 From: neteler at itc.it (Markus Neteler) Date: Thu Jul 6 00:59:03 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: <20060706030340.40842889.hamish_nospam@yahoo.com> References: <20060703164112.GN19781@bartok.itc.it> <20060704152632.09e9075d.hamish_nospam@yahoo.com> <20060704133435.GF21351@bartok.itc.it> <20060705095506.6b336afe.hamish_nospam@yahoo.com> <44AB6C04.10908@itc.it> <20060706030340.40842889.hamish_nospam@yahoo.com> Message-ID: <20060705225900.GL24748@bartok.itc.it> Hi developers, back to the open issues: Closed issues: On Thu, Jul 06, 2006 at 03:03:40AM +1200, Hamish wrote: > > >>(outstanding issues for me: fix ps.map vlegend patterns bug and > > >finish last i.vpoints details) > [done] - r.sun/64bit: done - r.sim.water/64bit: almost done, patch under review - snprintf(): almost done, patch under review - v.in.ascii/incomplete vector maps: done Open issues: - NVIZ volume: broken (https://intevation.de/rt/webrt?serial_num=4725) - announcement to be improved (maybe split into short and long version) - update roadmap.html (Web-CVS) - gis.m exec statements Unrelated to 6.1.0 branch (can be backported): - NVIZ/Mac issues - gis.m enhancements - r.to.vect memory consumption with zillion points Markus From glynn at gclements.plus.com Thu Jul 6 05:21:22 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jul 6 05:21:39 2006 Subject: [GRASS-dev] G_make_aspect*_colors() broken In-Reply-To: <1152093812.2454.59.camel@devel> References: <1152093812.2454.59.camel@devel> Message-ID: <17580.33202.530548.957612@cerise.gclements.plus.com> Brad Douglas wrote: > G_make_aspect*_colors() in lib/gis/color_asp.c is broken. It chooses > (defaults to?) a greyscale ramp, rather than what is expected for aspect > maps. > > Verified with r.slope.aspect and r.colors. It creates a black->white->black double ramp, with the half-way point being black. This will do the right thing, provided that your aspect map covers the full range of possible values (e.g. -180 to 180 or 0 to 360), but won't work if a the extrema are absent. -- Glynn Clements From glynn at gclements.plus.com Thu Jul 6 05:40:05 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jul 6 05:40:26 2006 Subject: [GRASS-dev] Re: [bug #1140] (grass) Non-portable snprintf() used in several programs In-Reply-To: References: <20060704123813.F3AE41005CA@lists.intevation.de> Message-ID: <17580.34325.326800.333470@cerise.gclements.plus.com> Paul Kelly wrote: > > the snprintf() is used as of today in: > > > > ./raster3d/r3.in.ascii/main.c > > ./db/drivers/dbf/dbfexe.c > > ./raster/r.support/front/front.c > > ./raster/r.support/front/check.c > > ./raster/r.support/front/run.c > > ./raster/r.support/modhead/check_un.c > > ./raster/r.support/modhead/modhead.c > > ./raster/r.support/modhead/ask_format.c > > ./lib/init/clean_temp.c > > ./lib/db/dbmi_client/select.c > > ./lib/gis/user_config.c > > ./lib/vector/dglib/examples/components.c > > Please see attached patch to replace use of snprintf in all those > modules. I am posting it to the list first, hopefully for some comments, > before committing. In cases where the strings being inserted are themselves supposed to have a maximum length (e.g. map names), I would just check that the strings don't exceed their maximum length and use a fixed-size buffer. > Index: lib/init/clean_temp.c > =================================================================== > RCS file: /grassrepository/grass6/lib/init/clean_temp.c,v > retrieving revision 2.5 > diff -u -r2.5 clean_temp.c > --- lib/init/clean_temp.c 24 Jun 2006 19:33:03 -0000 2.5 > +++ lib/init/clean_temp.c 5 Jul 2006 11:02:49 -0000 > @@ -19,7 +19,6 @@ > * > * 2006: Rewritten for GRASS 6 by roberto Flor, ITC-irst > * > - * TODO (?): Implement snprintf() as G_snprintf() for portability > **************************************************************/ > > #include > @@ -39,7 +38,6 @@ > > void clean_dir(const char *pathname,uid_t uid,pid_t pid,time_t now,int max_age) > { > - char buf[BUF_MAX]; > DIR *curdir; > struct dirent *cur_entry; > struct stat info; > @@ -53,11 +51,16 @@ > /* loop over current dir */ > while ((cur_entry = readdir(curdir))) > { > - if ((G_strcasecmp(cur_entry->d_name,".") == 0 )|| (G_strcasecmp(cur_entry->d_name,"..")==0)) > + static char *buf = NULL; > + > + if ((G_strcasecmp(cur_entry->d_name,".") == 0 )|| (G_strcasecmp(cur_entry->d_name,"..")==0)) > continue; /* Skip dir and parent dir entries */ > - > - if ( (pathlen=snprintf(buf,BUF_MAX,"%s/%s",pathname,cur_entry->d_name)) >= BUF_MAX) > - G_fatal_error("clean_temp: exceeded maximum pathname length %d, got %d, should'nt happen",BUF_MAX,pathlen); > + > + if(buf) > + G_free(buf); > + > + buf = G_malloc(strlen(pathname) + strlen(cur_entry->d_name) + 2); > + sprintf(buf, "%s/%s", pathname, cur_entry->d_name); In this situation, I would start with a reasonably-sized buffer (e.g. 4Kb), then use G_realloc() to enlarge it if necessary. Both malloc() and free() can be quite computationally expensive, and repeated use can cause heap fragmentation, particularly if the size tends to increase with time (as the previously free()d block is too small to be used by the subsequent malloc()). The same applies to any kind of loop: re-using a buffer is more efficient (in terms of both CPU and memory usage) than allocating a new buffer every time. -- Glynn Clements From glynn at gclements.plus.com Thu Jul 6 06:06:33 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jul 6 06:07:32 2006 Subject: [GRASS-dev] Re: grass-dev Digest, Vol 3, Issue 8 In-Reply-To: References: <200607050636.k656Zxb4010372@grass.itc.it> Message-ID: <17580.35913.239668.922846@cerise.gclements.plus.com> Michael Barton wrote: > When I get back, should I go through and get rid of all occurrences of eval > exec? > > I noticed that Cedric introduced a different form "exec $cmd [list arg arg > art...] If you have individual arguments, there should be no eval, just: exec $cmd $arg1 $arg2 etc. If you have a list of arguments, then the correct idiom is: eval [concat [list exec $cmd $arg1 $arg2] $otherargs] or: eval exec [concat [list $cmd $arg1 $arg2] $otherargs] or: eval exec $cmd [concat [list $arg1 $arg2] $otherargs] Although the last one is only correct if it is known that $cmd cannot contain spaces; don't use it if $cmd might be an absolute pathname (on Windows, it might be in the "Program Files" directory). The main point here is that eval will treat each argument as a list. If any of the arguments /aren't/ lists, they have to be inserted into a list so that they aren't themselves treated as lists and broken into multiple elements if they contain spaces. An example: set mapname "elevation.dem" set filename "/cygdrive/c/Documents and Settings/glynn/My Documents/elev.ppm" exec r.out.ppm input=$mapname output=$filename The actual command will be: argv[0] = 'r.out.ppm' argv[1] = 'input=elevation.dem' argv[2] = 'output=/cygdrive/c/Documents and Settings/glynn/My Documents/elev.ppm' No problem there, but with "eval exec ...": eval exec r.out.ppm input=$mapname output=$filename $filename would get split into multiple arguments: argv[0] = 'r.out.ppm' argv[1] = 'input=elevation.dem' argv[2] = 'output=/cygdrive/c/Documents' argv[3] = 'and' argv[4] = 'Settings/glynn/My' argv[5] = 'Documents/elev.ppm' A similar issue applies to shell scripts; several of the scripts in etc/gm/scripts use "eval exec ..." unnecessarily, e.g. r.recode.file: eval `exec r.recode input=$GIS_OPT_INPUT output=$GIS_OPT_OUTPUT < $GIS_OPT_RULES_FILE` This will fail if $GIS_OPT_RULES_FILE contains spaces. The correct formulation is: exec r.recode "input=$GIS_OPT_INPUT" "output=$GIS_OPT_OUTPUT" < "$GIS_OPT_RULES_FILE" Also, note the use of double quotes around each argument; this prevents it being split if the variable contains spaces (this is one signficant difference between shell syntax and Tcl syntax; Tcl won't split variable expansions unless forced to through the use of eval). Quotes aren't strictly necessary for the input= and output= options, because map names aren't allowed to contain spaces. But it won't hurt either, and it's good practice to put quotes around all variable expansions unless you specifically want the expansion to be split into words. They are necessary for the redirect filename, as that could contain spaces. However, this won't work work for the scripts which construct a command using e.g. cmd="$cmd something=$GIS_OPT_SOMETHING", because Bourne-shell doesn't have any support for lists (recent versions of bash have arrays, but those are highly non-portable). There isn't any robust solution to that issue, although using single quotes will help. -- Glynn Clements From glynn at gclements.plus.com Thu Jul 6 06:24:01 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jul 6 06:24:04 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: <20060705221656.GG24748@bartok.itc.it> References: <44AA1776.5000702@itc.it> <44AA1B9E.1000703@ufg.uni-kiel.de> <20060704101049.4c29d852@butan.gdf-hannover.de> <17578.51015.472978.97302@cerise.gclements.plus.com> <20060705221656.GG24748@bartok.itc.it> Message-ID: <17580.36961.971732.713853@cerise.gclements.plus.com> Markus Neteler wrote: > > > > Are the any (detailed) instructions for how to build and package > > > > a native QGIS + GRASS distribution from the regular GRASS CVS > > > > repository? > > > > > > > > I would love to add my archaeology modules and produce a version > > > > of GRASS for my colleagues working on Win32 systems. > > > > I am sure this could hit big in a science with low budget and > > > > very specific GIS needs. > > > > > > lemmi jump in here and give you the link to Radims detailed description > > > how to build GRASS/QGIS on windows[1]. > > > > It would be more useful to have a guide to building a native Windows > > version on Windows, rather than having to cross-compile. > > Agreed. Do you have a suggestion for a free (freedom) compiler? > Maybe obvious, but I am not informed. gcc. Either from MinGW or Cygwin (Cygwin's gcc has the -mno-cygwin switch to allow native (non-Cygwin) executables to be built). > > Also, it would be useful to offer pre-compiled Windows binaries of > > essential libraries (proj, GDAL etc). > > These could be published as by-product of GRASS, for now as > cross-compiled version. There is however an outstanding issue with > proj (nad2nad is not called within MinGW, so the NAD grid import fails > when cross-compiling). FWIW, I've managed to compile most of GRASS with MinGW/MSys, but the Windows stdio implementation appears to be broken with regard to fseek() on files opened for update (read+write). The biggest problem amongst the mandatory dependencies was the sunrpc library (used for the XDR functions) due to the use of the BSD socket functions. -- Glynn Clements From glynn at gclements.plus.com Thu Jul 6 06:27:56 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jul 6 06:27:58 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: <44AB7668.9060609@ufg.uni-kiel.de> References: <20060703164112.GN19781@bartok.itc.it> <20060704152632.09e9075d.hamish_nospam@yahoo.com> <20060704135721.GG21351@bartok.itc.it> <44AB7668.9060609@ufg.uni-kiel.de> Message-ID: <17580.37196.509429.655127@cerise.gclements.plus.com> Benjamin Ducke wrote: > I have one request concerning the GRASS configure script: > would it be possible for configure to write a small one-line > ASCII file into GISBASE/etc after a successful configuration, > which contains all the options that the user passed to the > configure script? > > Having such a file in a standard location would make it > much easier to compile external modules with exactly the > same external dependencies as the GRASS system installation. It would probably be more useful to include the files from include/Make, including those which are generated by the configure script (Grass.make and Platform.make). The generated config.h file is already present. -- Glynn Clements From rez at touchofmadness.com Thu Jul 6 06:31:56 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Thu Jul 6 06:32:00 2006 Subject: [GRASS-dev] G_make_aspect*_colors() broken In-Reply-To: <17580.33202.530548.957612@cerise.gclements.plus.com> References: <1152093812.2454.59.camel@devel> <17580.33202.530548.957612@cerise.gclements.plus.com> Message-ID: <1152160316.20411.10.camel@devel> On Thu, 2006-07-06 at 04:21 +0100, Glynn Clements wrote: > Brad Douglas wrote: > > > G_make_aspect*_colors() in lib/gis/color_asp.c is broken. It chooses > > (defaults to?) a greyscale ramp, rather than what is expected for aspect > > maps. > > > > Verified with r.slope.aspect and r.colors. > > It creates a black->white->black double ramp, with the half-way point > being black. This will do the right thing, provided that your aspect > map covers the full range of possible values (e.g. -180 to 180 or 0 to > 360), but won't work if a the extrema are absent. That's not how it used to work and is down right confusing to examine visually. Each "direction" used to have a distinctive color assigned to it. -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From hmitaso at unity.ncsu.edu Thu Jul 6 06:42:51 2006 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Thu Jul 6 06:42:59 2006 Subject: [GRASS-dev] G_make_aspect*_colors() broken In-Reply-To: <1152160316.20411.10.camel@devel> References: <1152093812.2454.59.camel@devel> <17580.33202.530548.957612@cerise.gclements.plus.com> <1152160316.20411.10.camel@devel> Message-ID: On Jul 6, 2006, at 12:31 AM, Brad Douglas wrote: > On Thu, 2006-07-06 at 04:21 +0100, Glynn Clements wrote: >> Brad Douglas wrote: >> >>> G_make_aspect*_colors() in lib/gis/color_asp.c is broken. It >>> chooses >>> (defaults to?) a greyscale ramp, rather than what is expected for >>> aspect >>> maps. >>> >>> Verified with r.slope.aspect and r.colors. >> >> It creates a black->white->black double ramp, with the half-way point >> being black. This will do the right thing, provided that your aspect >> map covers the full range of possible values (e.g. -180 to 180 or >> 0 to >> 360), but won't work if a the extrema are absent. > > That's not how it used to work and is down right confusing to examine > visually. Each "direction" used to have a distinctive color > assigned to > it. Brad - that is what we have in the rst programs. But for historical reasons, r.slope.aspect has the old greyscale color table - when I did the colored aspect color table for rst there were already too many users used to the greyscale aspect map produced by r.slope.aspect that I did not want to change it (I am talking about early 90ies here). Now, when we have the shaded relief module maybe we could unify the outputs from rst and r.slope.aspect, but I would leave for the next release, unless others feel that it should be done now. Helena > > > -- > 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 glynn at gclements.plus.com Thu Jul 6 06:46:51 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jul 6 06:46:54 2006 Subject: [GRASS-dev] Re: [GRASS-user] can't use r.recode from standart GUI In-Reply-To: <44AB6CB3.7050402@ensam.inra.fr> References: <44AB6CB3.7050402@ensam.inra.fr> Message-ID: <17580.38331.43217.602999@cerise.gclements.plus.com> Nicolas Devaux wrote: > I'm trying to use the r.recode fonction via the GUI (raster, change > categories values.../recode categories using rules). When I launch the > fonction, proper window opens, but when I click run, a terminal window > strart to open and close very quickly. Hence, I can't notify new values > to use for recoding the raster map. If I use the r.recode fonction from > the Grass terminal, everything is working properly... > Does someone have any tip for this problem? There are several possible fixes/workarounds: 1. Use the "Recode categories using rules file" option instead; that reads the rules from a file, rather than from a terminal. 2. Add the path to the GRASS library directory (e.g. /usr/local/grass6/lib) to /etc/ld.so.conf, then run "ldconfig". 3. Change the last line of the etc/gm/script/r.recode.rules script to: exec xterm -e $GISBASE/etc/grass-run.sh r.recode input=$GIS_OPT_INPUT output=$GIS_OPT_OUTPUT Also, I'll commit a fixed r.recode.rules script to CVS. -- Glynn Clements From hamish_nospam at yahoo.com Thu Jul 6 09:03:39 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Jul 6 09:03:43 2006 Subject: [GRASS-dev] postscript color output Message-ID: <20060706190339.32de1f11.hamish_nospam@yahoo.com> Hi, ps.map (legends) output colors as if(do_color) fprintf(PS.fp, "%.2f %.2f %.2f C\n", (double)R/255., (double)G/255., (double)B/255.); else { grey_color_val = (.3 * (double)R + .59 * (double)G + .11 * (double)B)/255.; fprintf(PS.fp, "%.2f setgray\n", grey_color_val); } "0.00" is only 100 levels; should these be changed to %.3f so none of the 256 color resolution is lost? Hamish From benjamin.ducke at ufg.uni-kiel.de Thu Jul 6 09:59:54 2006 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Thu Jul 6 10:00:43 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: References: Message-ID: <44ACC2FA.8080602@ufg.uni-kiel.de> The plan is: Extension authors should provide a list of external dependencies that must be satisfied. GEM could then check if the GRASS installation satisfies these and at least issue a warning if not. Benjamin Michael Barton wrote: > Benjamin, > > I don't think this would work for precompiled binaries. They may be > installed on a system that doesn't have some of the dependencies. For > example, you can compile with MySQL support and then put GRASS on a system > without MySQL. > > 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: Benjamin Ducke >>Date: Wed, 05 Jul 2006 10:20:56 +0200 >>Cc: >>Subject: Re: [GRASS-dev] GRASS 6.1.0 release preparation >> >>I have one request concerning the GRASS configure script: >>would it be possible for configure to write a small one-line >>ASCII file into GISBASE/etc after a successful configuration, >>which contains all the options that the user passed to the >>configure script? >> >>Having such a file in a standard location would make it >>much easier to compile external modules with exactly the >>same external dependencies as the GRASS system installation. >> >>Best, >> >>Benjamin >> >>Markus Neteler wrote: >> >>>On Tue, Jul 04, 2006 at 12:26:16AM -0400, Helena Mitasova wrote: >>>... >>> >>> >>>>Some modules have problems running on 64bit (maybe that is also >>>>#4725? >>> >>> >>>The nviz volume bug was recently introduces, I think. As far >>>as I remember it worked some time ago on 64bit. >>> >>>https://intevation.de/rt/webrt?serial_num=4725 >>>" >>> I followed "mode" into lib/ogsf/GVL2.c GVL_slice_get_drawmode() >>> and then *gvl to gvl_get_vol() in lib/ogsf/gvl.c, but then I get lost. >>>" >>> >>>? >>> >>> >>> >>>>but it is for sure #4546 >>> >>> >>>https://intevation.de/rt/webrt?serial_num=4546 >>>r.sim.water crashes in simlib/input.c line 403, function grad_check(): >>> >>> if (cchez[k][l] != 0.) { >>> >>> with k=700 and l=0 >>> >>>Not sure why. >>> >>> >>> >>> >>>>and supposedly also r.sun - probably due to uninitialized >>>>variables). >>> >>> >>>Right, It crashes in INPUT () at main.c:656 >>> if (z[i][j] == UNDEFZ || o[i][j] == UNDEFZ || s[i][j] == >>>UNDEFZ) >>> >>>Here a Spearfish test script: >>> >>>ELEV=elevation.dem >>>TMP=$$ >>>SLOPE=$TMP.slope >>>ASP=$TMP.aspect >>>r.slope.aspect elevation.dem as=$TMP.aspect sl=$TMP.slope --o >>>r.mapcalc global_shadow.rad=0 >>>DAY=055 >>>r.sun -s elevin=elevation.dem aspin=$TMP.aspect slopein=$TMP.slope day=$DAY \ >>> beam_rad=bs_rad.$DAY diff_rad=ds_rad.$DAY refl_rad=rs_rad.$DAY >>> >>> >>> >>> >>> >>>>I don't think that this should stop the release. >>> >>> >>>I would appreciate if those two bugs would be fixed, but we >>>can backport the fixes later. >>> >>> >>> >>>>Also I believe that we should thoroughly test gis.m before release - >>>>we were getting all kinds of error messages but I think that it all >>>>has been fixed by now. >>> >>> >>>Yes, gis.m should get a consolidation cycle now. >>> >>>Markus >>> >>> >>>_______________________________________________ >>>grass-dev mailing list >>>grass-dev@grass.itc.it >>>http://grass.itc.it/mailman/listinfo/grass-dev >>> >>> >> >>-- >>Benjamin Ducke, M.A. >>Arch?oinformatik >>(Archaeoinformation Science) >>Institut f?r Ur- und Fr?hgeschichte >>(Inst. of Prehistoric and Historic Archaeology) >>Christian-Albrechts-Universit?t zu Kiel >>Johanna-Mestorf-Stra?e 2-6 >>D 24098 Kiel >>Germany >> >>Tel.: ++49 (0)431 880-3378 / -3379 >>Fax : ++49 (0)431 880-7300 >>www.uni-kiel.de/ufg >> >> > > > > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From neteler at itc.it Thu Jul 6 10:12:53 2006 From: neteler at itc.it (Markus Neteler) Date: Thu Jul 6 10:12:54 2006 Subject: [GRASS-dev] sqlite driver: G_free() missing? Message-ID: <20060706081253.GG27935@bartok.itc.it> Hi, while testing: v.random random n=1000000 v.out.ascii random > random.csv v.in.ascii random.csv out=random2 with the sqlite driver, I observed that it eats a lot of memory. Since v.in.ascii works ok with the dbf driver, the problem must be in the sqlite driver. Therein I found some memory allocations but no G_free(): cd db/drivers/sqlite/ grep malloc * cursor.c: c = (cursor *) db_malloc(sizeof(cursor)); describe.c: c->kcols = (int *) G_malloc ( nkcols * sizeof(int) ); error.c: errMsg = (dbString *) G_malloc(sizeof(dbString)); My malloc knowledge is limited, do we need to add some G_free() statements there? thanks Markus From neteler at itc.it Thu Jul 6 10:19:57 2006 From: neteler at itc.it (Markus Neteler) Date: Thu Jul 6 10:19:59 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: <44ACC2FA.8080602@ufg.uni-kiel.de> References: <44ACC2FA.8080602@ufg.uni-kiel.de> Message-ID: <44ACC7AD.70501@itc.it> Benjamin, another, more standardized option is to use grass.pc.in grass.pc (generated by configure from grass.pc.in) Markus Benjamin Ducke wrote on 07/06/2006 09:59 AM: > The plan is: > Extension authors should provide a list of external dependencies > that must be satisfied. > GEM could then check if the GRASS installation satisfies these > and at least issue a warning if not. > > Benjamin > > Michael Barton wrote: > >> Benjamin, >> >> I don't think this would work for precompiled binaries. They may be >> installed on a system that doesn't have some of the dependencies. For >> example, you can compile with MySQL support and then put GRASS on a >> system >> without MySQL. >> >> 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: Benjamin Ducke >>> Date: Wed, 05 Jul 2006 10:20:56 +0200 >>> Cc: >>> Subject: Re: [GRASS-dev] GRASS 6.1.0 release preparation >>> >>> I have one request concerning the GRASS configure script: >>> would it be possible for configure to write a small one-line >>> ASCII file into GISBASE/etc after a successful configuration, >>> which contains all the options that the user passed to the >>> configure script? >>> >>> Having such a file in a standard location would make it >>> much easier to compile external modules with exactly the >>> same external dependencies as the GRASS system installation. >>> >>> Best, >>> >>> Benjamin >>> >>> Markus Neteler wrote: >>> >>>> On Tue, Jul 04, 2006 at 12:26:16AM -0400, Helena Mitasova wrote: >>>> ... >>>> >>>> >>>>> Some modules have problems running on 64bit (maybe that is also >>>>> #4725? >>>> >>>> >>>> >>>> The nviz volume bug was recently introduces, I think. As far >>>> as I remember it worked some time ago on 64bit. >>>> >>>> https://intevation.de/rt/webrt?serial_num=4725 >>>> " I followed "mode" into lib/ogsf/GVL2.c GVL_slice_get_drawmode() >>>> and then *gvl to gvl_get_vol() in lib/ogsf/gvl.c, but then I get >>>> lost. >>>> " >>>> >>>> ? >>>> >>>> >>>> >>>>> but it is for sure #4546 >>>> >>>> >>>> >>>> https://intevation.de/rt/webrt?serial_num=4546 >>>> r.sim.water crashes in simlib/input.c line 403, function grad_check(): >>>> >>>> if (cchez[k][l] != 0.) { >>>> >>>> with k=700 and l=0 >>>> >>>> Not sure why. >>>> >>>> >>>> >>>> >>>>> and supposedly also r.sun - probably due to uninitialized >>>>> variables). >>>> >>>> >>>> >>>> Right, It crashes in INPUT () at main.c:656 >>>> if (z[i][j] == UNDEFZ || o[i][j] == UNDEFZ || s[i][j] == >>>> UNDEFZ) >>>> >>>> Here a Spearfish test script: >>>> >>>> ELEV=elevation.dem >>>> TMP=$$ >>>> SLOPE=$TMP.slope >>>> ASP=$TMP.aspect >>>> r.slope.aspect elevation.dem as=$TMP.aspect sl=$TMP.slope --o >>>> r.mapcalc global_shadow.rad=0 >>>> DAY=055 >>>> r.sun -s elevin=elevation.dem aspin=$TMP.aspect slopein=$TMP.slope >>>> day=$DAY \ >>>> beam_rad=bs_rad.$DAY diff_rad=ds_rad.$DAY refl_rad=rs_rad.$DAY >>>> >>>> >>>> >>>> >>>> >>>>> I don't think that this should stop the release. >>>> >>>> >>>> >>>> I would appreciate if those two bugs would be fixed, but we >>>> can backport the fixes later. >>>> >>>> >>>> >>>>> Also I believe that we should thoroughly test gis.m before release - >>>>> we were getting all kinds of error messages but I think that it all >>>>> has been fixed by now. >>>> >>>> >>>> >>>> Yes, gis.m should get a consolidation cycle now. >>>> >>>> Markus >>>> >>>> >>>> _______________________________________________ >>>> grass-dev mailing list >>>> grass-dev@grass.itc.it >>>> http://grass.itc.it/mailman/listinfo/grass-dev >>>> >>>> >>> >>> -- >>> Benjamin Ducke, M.A. >>> Arch?oinformatik >>> (Archaeoinformation Science) >>> Institut f?r Ur- und Fr?hgeschichte >>> (Inst. of Prehistoric and Historic Archaeology) >>> Christian-Albrechts-Universit?t zu Kiel >>> Johanna-Mestorf-Stra?e 2-6 >>> D 24098 Kiel >>> Germany >>> >>> Tel.: ++49 (0)431 880-3378 / -3379 >>> Fax : ++49 (0)431 880-7300 >>> www.uni-kiel.de/ufg >>> >>> >> >> >> >> > From neteler at itc.it Thu Jul 6 14:30:05 2006 From: neteler at itc.it (Markus Neteler) Date: Thu Jul 6 14:30:06 2006 Subject: [GRASS-dev] v.in.ogr: 'NULL' support activated for OFTInteger and OFTReal Message-ID: <20060706123005.GO27935@bartok.itc.it> Hi, while fixing the missing OFTDate, I have also activated the previously commented support for NULL for OFTInteger and OFTReal types. Example with DBF driver: v.db.select natpol col=FLAECHEID,NEW_DATE,VISIBLE FLAECHEID|NEW_DATE|VISIBLE 0|2005/10/18,F v.db.update natpol col=FLAECHEID value=NULL v.db.select natpol col=FLAECHEID,NEW_DATE,VISIBLE FLAECHEID|NEW_DATE|VISIBLE |2005/10/18,F Markus From hamish_nospam at yahoo.com Thu Jul 6 15:19:42 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Jul 6 15:19:58 2006 Subject: [GRASS-dev] [bug #3877] (grass) r.to.vect, v.in.ascii use too much memory for millions of points In-Reply-To: <20060705183904.4D5031005B9@lists.intevation.de> References: <20060705183904.4D5031005B9@lists.intevation.de> Message-ID: <20060707011942.00c7db9b.hamish_nospam@yahoo.com> Maciek Sieczka wrote: > So I checked with current CVS and the same problem still applies to > r.to.vect. > > "r.to.vect -z feature=point input=dem_5 output=dem_5_pt" eats up all > 1GB RAM + 1GB SWAP at about 5 000 000 points. > > The above mentioned Andrew Danner's fix for v.in.ascii is great stuff > but r.to.vect problem remains (in my bug report I was complaining > about only r.to.vect, few days later Hamish changed the subject, as > v.in.ascii issue popped up during discussion). > > Is it possible that r.to.vect suffers from a similar problem as > v.in.ascii did, so a similar fix would do? Andrew? does it happen during the "building lines" (or "registering lines"?) step? (watch the memory use using 'top' in another xterm, use "M" to sort by memory use) if so, it's the same problem as v.in.ascii building topology. I added a -b flag to r.to.vect (in CVS) to skip building topology for this reason. Only tested with raster cells->vector points in mind. (r.in.xyz -> r.to.vect -> v.surf.rst) Hamish From hamish_nospam at yahoo.com Thu Jul 6 15:27:26 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Jul 6 15:27:31 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: <20060705225900.GL24748@bartok.itc.it> References: <20060703164112.GN19781@bartok.itc.it> <20060704152632.09e9075d.hamish_nospam@yahoo.com> <20060704133435.GF21351@bartok.itc.it> <20060705095506.6b336afe.hamish_nospam@yahoo.com> <44AB6C04.10908@itc.it> <20060706030340.40842889.hamish_nospam@yahoo.com> <20060705225900.GL24748@bartok.itc.it> Message-ID: <20060707012726.3edda5a4.hamish_nospam@yahoo.com> > Hi developers, > > back to the open issues: .. > Open issues: .. > Unrelated to 6.1.0 branch (can be backported): .. > - r.to.vect memory consumption with zillion points -b "skip topology building" was added to r.to.vect soon after r.in.xyz was introduced. If that solves it, the "bug" can be combined with the long standing v.in.ascii issue. Hamish From Florian.Kindl at uibk.ac.at Thu Jul 6 15:44:32 2006 From: Florian.Kindl at uibk.ac.at (Florian Kindl) Date: Thu Jul 6 15:44:35 2006 Subject: [GRASS-dev] Vlib: add attributes to new vector Message-ID: *** (sorry for cross-posting - I sent this to grassusers by mistake) *** Hello list! I started to write a vector module for GRASS GIS. It reads an existing vector set (lines) and writes a new one. The output set should contain the attributes of the input set plus 2 new attributes which are calculated by my module. How do I append these new attribute columns to my output data? When I use Vect_copy_tables ( &In, &Out, 0 ); can I, afterwards, add colums to the table of &Out? Or do I have to add another table like this: ==code== Fi = Vect_default_field_info ( &Out, 1, NULL, GV_1TABLE ); Vect_map_add_dblink ( &Out, 1, NULL, Fi->table, "cat", Fi->database, Fi->driver); driver = db_start_driver_open_database ( Fi->driver, Fi->database ); if ( driver == NULL ) G_fatal_error ( "Cannot open database %s by driver %s", Fi->database, Fi->driver ); sprintf ( buf, "create table %s ( cat integer, bsnid integer, sorder integer )", Fi->table ); db_set_string ( &sql, buf ); G_debug ( 2, db_get_string ( &sql ) ); if (db_execute_immediate (driver, &sql) != DB_OK ) { db_close_database_shutdown_driver ( driver ); G_fatal_error ( "Cannot create table: %s", db_get_string ( &sql ) ); } ==/code== (these lines work if there is no table yet - it fails if one already exists) And finally, can someone explain the concept of dblink,tables,fields, layers concisely? I don't get it yet from the documents on the GRASS 6 vector architecture... Thanks for your help, Flo. -- Florian Kindl Institute ofr Geograpy University of Innsbruck From michael.barton at asu.edu Thu Jul 6 16:17:18 2006 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jul 6 16:17:23 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: <44ACC2FA.8080602@ufg.uni-kiel.de> Message-ID: This sounds like a good plan. I was worried that an extension installation might fail because a system did not have a dependency--unneeded by the extension--that was present in the build system but not on the binary install system. This is not unusual. For example, Lorenzo Moretti's Mac binaries are built with PostgreSQL, but I don't have it on my laptop. This doesn't affect how GRASS runs (as long as I don't want to use PostgreSQL of course). 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: Benjamin Ducke > Date: Thu, 06 Jul 2006 09:59:54 +0200 > To: GRASS devel > Subject: Re: [GRASS-dev] GRASS 6.1.0 release preparation > > The plan is: > Extension authors should provide a list of external dependencies > that must be satisfied. > GEM could then check if the GRASS installation satisfies these > and at least issue a warning if not. > > Benjamin > > Michael Barton wrote: >> Benjamin, >> >> I don't think this would work for precompiled binaries. They may be >> installed on a system that doesn't have some of the dependencies. For >> example, you can compile with MySQL support and then put GRASS on a system >> without MySQL. >> >> 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: Benjamin Ducke >>> Date: Wed, 05 Jul 2006 10:20:56 +0200 >>> Cc: >>> Subject: Re: [GRASS-dev] GRASS 6.1.0 release preparation >>> >>> I have one request concerning the GRASS configure script: >>> would it be possible for configure to write a small one-line >>> ASCII file into GISBASE/etc after a successful configuration, >>> which contains all the options that the user passed to the >>> configure script? >>> >>> Having such a file in a standard location would make it >>> much easier to compile external modules with exactly the >>> same external dependencies as the GRASS system installation. >>> >>> Best, >>> >>> Benjamin >>> >>> Markus Neteler wrote: >>> >>>> On Tue, Jul 04, 2006 at 12:26:16AM -0400, Helena Mitasova wrote: >>>> ... >>>> >>>> >>>>> Some modules have problems running on 64bit (maybe that is also >>>>> #4725? >>>> >>>> >>>> The nviz volume bug was recently introduces, I think. As far >>>> as I remember it worked some time ago on 64bit. >>>> >>>> https://intevation.de/rt/webrt?serial_num=4725 >>>> " >>>> I followed "mode" into lib/ogsf/GVL2.c GVL_slice_get_drawmode() >>>> and then *gvl to gvl_get_vol() in lib/ogsf/gvl.c, but then I get lost. >>>> " >>>> >>>> ? >>>> >>>> >>>> >>>>> but it is for sure #4546 >>>> >>>> >>>> https://intevation.de/rt/webrt?serial_num=4546 >>>> r.sim.water crashes in simlib/input.c line 403, function grad_check(): >>>> >>>> if (cchez[k][l] != 0.) { >>>> >>>> with k=700 and l=0 >>>> >>>> Not sure why. >>>> >>>> >>>> >>>> >>>>> and supposedly also r.sun - probably due to uninitialized >>>>> variables). >>>> >>>> >>>> Right, It crashes in INPUT () at main.c:656 >>>> if (z[i][j] == UNDEFZ || o[i][j] == UNDEFZ || s[i][j] == >>>> UNDEFZ) >>>> >>>> Here a Spearfish test script: >>>> >>>> ELEV=elevation.dem >>>> TMP=$$ >>>> SLOPE=$TMP.slope >>>> ASP=$TMP.aspect >>>> r.slope.aspect elevation.dem as=$TMP.aspect sl=$TMP.slope --o >>>> r.mapcalc global_shadow.rad=0 >>>> DAY=055 >>>> r.sun -s elevin=elevation.dem aspin=$TMP.aspect slopein=$TMP.slope day=$DAY >>>> \ >>>> beam_rad=bs_rad.$DAY diff_rad=ds_rad.$DAY refl_rad=rs_rad.$DAY >>>> >>>> >>>> >>>> >>>> >>>>> I don't think that this should stop the release. >>>> >>>> >>>> I would appreciate if those two bugs would be fixed, but we >>>> can backport the fixes later. >>>> >>>> >>>> >>>>> Also I believe that we should thoroughly test gis.m before release - >>>>> we were getting all kinds of error messages but I think that it all >>>>> has been fixed by now. >>>> >>>> >>>> Yes, gis.m should get a consolidation cycle now. >>>> >>>> Markus >>>> >>>> >>>> _______________________________________________ >>>> grass-dev mailing list >>>> grass-dev@grass.itc.it >>>> http://grass.itc.it/mailman/listinfo/grass-dev >>>> >>>> >>> >>> -- >>> Benjamin Ducke, M.A. >>> Arch?oinformatik >>> (Archaeoinformation Science) >>> Institut f?r Ur- und Fr?hgeschichte >>> (Inst. of Prehistoric and Historic Archaeology) >>> Christian-Albrechts-Universit?t zu Kiel >>> Johanna-Mestorf-Stra?e 2-6 >>> D 24098 Kiel >>> Germany >>> >>> Tel.: ++49 (0)431 880-3378 / -3379 >>> Fax : ++49 (0)431 880-7300 >>> www.uni-kiel.de/ufg >>> >>> >> >> >> >> > > -- > Benjamin Ducke, M.A. > Arch?oinformatik > (Archaeoinformation Science) > Institut f?r Ur- und Fr?hgeschichte > (Inst. of Prehistoric and Historic Archaeology) > Christian-Albrechts-Universit?t zu Kiel > Johanna-Mestorf-Stra?e 2-6 > D 24098 Kiel > Germany > > Tel.: ++49 (0)431 880-3378 / -3379 > Fax : ++49 (0)431 880-7300 > www.uni-kiel.de/ufg > > From werchowyna at epf.pl Thu Jul 6 16:45:22 2006 From: werchowyna at epf.pl (Maciek Sieczka) Date: Thu Jul 6 16:45:18 2006 Subject: [GRASS-dev] [bug #3877] (grass) r.to.vect, v.in.ascii use too much memory for millions of points In-Reply-To: <20060707011942.00c7db9b.hamish_nospam@yahoo.com> References: <20060705183904.4D5031005B9@lists.intevation.de> <20060707011942.00c7db9b.hamish_nospam@yahoo.com> Message-ID: <20060706164522.004be5dc.werchowyna@epf.pl> On Fri, 7 Jul 2006 01:19:42 +1200 Hamish wrote: > Maciek Sieczka wrote: > > So I checked with current CVS and the same problem still applies to > > r.to.vect. > > > > "r.to.vect -z feature=point input=dem_5 output=dem_5_pt" eats up all > > 1GB RAM + 1GB SWAP at about 5 000 000 points. > > > > The above mentioned Andrew Danner's fix for v.in.ascii is great > > stuff but r.to.vect problem remains (in my bug report I was > > complaining about only r.to.vect, few days later Hamish changed the > > subject, as v.in.ascii issue popped up during discussion). > > > > Is it possible that r.to.vect suffers from a similar problem as > > v.in.ascii did, so a similar fix would do? Andrew? > > > does it happen during the "building lines" (or "registering lines"?) > step? Yes. > if so, it's the same problem as v.in.ascii building topology. > I added a -b flag to r.to.vect (in CVS) to skip building topology for > this reason. Only tested with raster cells->vector points in mind. > (r.in.xyz -> r.to.vect -> v.surf.rst) I'm not sure if this is right the way to go. If we proceed this way then v.proj, v.in.*, v.perturb, v.to.points and other would require the same. Do we want it? Double standards will be confusing, expecially for newcommers. Shouldn't the vector engine be fixed instead not to use all memory? Every no-topology hack will reduce the chance for a real solution. (On the other hand, sure I will bless your "r.to.vect -b" having no other solution handy. But really this is not a sustainable approach.) Maciek -------------------- W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich! http://katalog.panoramainternetu.pl/ From grass-bugs at intevation.de Thu Jul 6 19:24:16 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Jul 6 19:24:17 2006 Subject: [GRASS-dev] [bug #4796] (grass) v.digit: $mapname in the title bar Message-ID: <20060706172416.30A4C100161@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4796 ------------------------------------------------------------------------- Subject: v.digit: $mapname in the title bar Platform: GNU/Linux/x86 grass obtained from: CVS grass binary for platform: Compiled from Sources GRASS Version: 2006.07.05 The v.digit title bar displays "v.digit - $mapname". Not the name of the map, but "$mapname" literally. Maciek -------------------------------------------- Managed by Request Tracker From woklist at kyngchaos.com Thu Jul 6 21:28:32 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Thu Jul 6 21:28:52 2006 Subject: [GRASS-dev] GRASS for Mac OS X Aqua binary available for testing Message-ID: My NVIZ crash bug (#4768) morphed into making it work in Mac OS X, without X11. Partial success. I have an experimental binary download for testing on my site. It requires my Graphics Libs and GIS Libs packages. It's Universal for PPC and Intel. Aqua-fied, so there is no need for X11, even for NVIZ! There is a Tcl/Tk Aqua/ Universal download also. The main problem is that NVIZ works on PPC but crashes on Intel, at least on my MacBook (non-Pro). Hopefully someone with a MacBook Pro or Intel iMac (that is, an Intel Mac with a 'real' graphics card) can try it. ----- William Kyngesburye http://www.kyngchaos.com/ "Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence.... - the wisdom of Tarzan From neteler at itc.it Thu Jul 6 22:36:04 2006 From: neteler at itc.it (Markus Neteler) Date: Thu Jul 6 22:36:05 2006 Subject: [GRASS-dev] [bug #4796] (grass) v.digit: $mapname in the title bar In-Reply-To: <20060706172416.30A4C100161@lists.intevation.de> References: <20060706172416.30A4C100161@lists.intevation.de> Message-ID: <20060706203604.GA739@bartok.itc.it> On Thu, Jul 06, 2006 at 07:24:16PM +0200, Request Tracker wrote: > this bug's URL: http://intevation.de/rt/webrt?serial_num=4796 > ------------------------------------------------------------------------- > > Subject: v.digit: $mapname in the title bar > > Platform: GNU/Linux/x86 > grass obtained from: CVS > grass binary for platform: Compiled from Sources > GRASS Version: 2006.07.05 > > The v.digit title bar displays "v.digit - $mapname". Not the name of the map, but "$mapname" literally. In the source code is the following comment: # I'm not sure how to grab the map name, so I'll leave it obviously broken # in the hope someone will fix it. If you comment out the following line, # then the toolbox window takes on the map name! argh! We want both. wm title . "v.digit - \$mapname" Markus From glynn at gclements.plus.com Fri Jul 7 00:30:12 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jul 7 00:30:17 2006 Subject: [GRASS-dev] postscript color output In-Reply-To: <20060706190339.32de1f11.hamish_nospam@yahoo.com> References: <20060706190339.32de1f11.hamish_nospam@yahoo.com> Message-ID: <17581.36596.384287.793068@cerise.gclements.plus.com> Hamish wrote: > ps.map (legends) output colors as > > if(do_color) > fprintf(PS.fp, "%.2f %.2f %.2f C\n", > (double)R/255., (double)G/255., (double)B/255.); > else { > grey_color_val = (.3 * (double)R + .59 * (double)G > + .11 * (double)B)/255.; > fprintf(PS.fp, "%.2f setgray\n", grey_color_val); > } > > "0.00" is only 100 levels; should these be changed to %.3f so none of > the 256 color resolution is lost? Yes. -- Glynn Clements From hamish_nospam at yahoo.com Fri Jul 7 10:19:58 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Jul 7 10:20:31 2006 Subject: [GRASS-dev] [bug #3877] (grass) r.to.vect, v.in.ascii use too much memory for millions of points In-Reply-To: <20060706164522.004be5dc.werchowyna@epf.pl> References: <20060705183904.4D5031005B9@lists.intevation.de> <20060707011942.00c7db9b.hamish_nospam@yahoo.com> <20060706164522.004be5dc.werchowyna@epf.pl> Message-ID: <20060707201958.1da471d9.hamish_nospam@yahoo.com> Maciek wrote: > I'm not sure if this is right the way to go. If we proceed this way > then v.proj, v.in.*, v.perturb, v.to.points and other would require > the same. Do we want it? Double standards will be confusing, > expecially for newcommers. Shouldn't the vector engine be fixed > instead not to use all memory? Every no-topology hack will reduce the > chance for a real solution. > > (On the other hand, sure I will bless your "r.to.vect -b" having no > other solution handy. But really this is not a sustainable approach.) In principal I agree, in practice I am willing to compromise. The -b flag is a temporary work-around until we have a better solution. A pure solution is nice, but may take time and we have deadlines to meet. Or stated another way, I know enough of the vector code to add a -b flag but not enough to rewrite the engine to fix the underlying problem. So I add a -b flag and agree that a better solution is needed. I was never very clear on this, but have an idea that topology is meaningless for data which is only points (no tree; only bounding box matters?). If so, the (correct) solution becomes much easier. Hamish From hamish_nospam at yahoo.com Fri Jul 7 10:35:55 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Jul 7 10:36:00 2006 Subject: [GRASS-dev] displaying (slightly) broken raster maps in gis.m Message-ID: <20060707203555.50b95a00.hamish_nospam@yahoo.com> We noticed gis.m will not display a raster map if the cats/ file is missing but d.rast will. is this something to fix, or nothing to worry about? (mapset was broken after bulk copy via FAT32 external hard drive problems) Hamish From rez at touchofmadness.com Fri Jul 7 11:33:11 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Fri Jul 7 11:33:18 2006 Subject: [GRASS-dev] sqlite driver: G_free() missing? In-Reply-To: <20060706081253.GG27935@bartok.itc.it> References: <20060706081253.GG27935@bartok.itc.it> Message-ID: <1152264791.20411.43.camel@devel> Markus, Comments below per usual. On Thu, 2006-07-06 at 10:12 +0200, Markus Neteler wrote: > Hi, > > while testing: > > v.random random n=1000000 > v.out.ascii random > random.csv > v.in.ascii random.csv out=random2 > > with the sqlite driver, I observed that it eats a lot > of memory. Since v.in.ascii works ok with the dbf driver, the > problem must be in the sqlite driver. Therein I found some memory > allocations but no G_free(): > > cd db/drivers/sqlite/ > grep malloc * > cursor.c: c = (cursor *) db_malloc(sizeof(cursor)); > describe.c: c->kcols = (int *) G_malloc ( nkcols * sizeof(int) ); > error.c: errMsg = (dbString *) G_malloc(sizeof(dbString)); > > My malloc knowledge is limited, do we need to add some > G_free() statements there? There is nothing inherently wrong with cursor.c and describe.c. In cursor.c a 'cursor' struct is initially allocated in function alloc_cursor(). In describe.c, an element of the 'cursor' structure is allocated. There is also a related function, free_cursor() that free()s the memory. There is only a memory leak if alloc_cursor() is called without a corresponding free_cursor(), but the memory is free()d regardless at executable termination. I don't see any reason why the memory allocation in describe.c shouldn't be moved to alloc_cursor() in cursor.c. It may be more readable that way. In, error.c a function init_error() allocates enough memory to hold strings. It appears that the code 'if (!errMsg) {...' functions as a poor "this only happens once" block. There should probably be a corresponding free_error() function, but it isn't really necessary since most people would most likely call it close to program termination. Sorry for the length, but in short, there's really nothing wrong. :-) -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From grass-bugs at intevation.de Fri Jul 7 12:11:19 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Fri Jul 7 12:11:21 2006 Subject: [GRASS-dev] [bug #4800] (grass) d.nviz: interactive line placement problem Message-ID: <20060707101119.D341F1005DF@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4800 ------------------------------------------------------------------------- Subject: d.nviz: interactive line placement problem Hi, I introduced a bug in d.nviz that I don't know how to fix. If the interactive placement point is outside the region (eg in the white bands on the sides of the x monitor) the point is skipped as there is no underlying topography to get the elevation offset from. You get a warning and no point is recorded, but the display draw-line code doesn't get the "undo" message and the next point starts from the last (unrecorded) point instead of retrying from the last good point. Is it possible to reverse the last line? ? Hamish -------------------------------------------- Managed by Request Tracker From neteler at itc.it Fri Jul 7 13:48:16 2006 From: neteler at itc.it (Markus Neteler) Date: Fri Jul 7 13:48:17 2006 Subject: [GRASS-dev] [bug #3877] (grass) r.to.vect, v.in.ascii use too much memory for millions of points In-Reply-To: <20060707201958.1da471d9.hamish_nospam@yahoo.com> References: <20060705183904.4D5031005B9@lists.intevation.de> <20060707011942.00c7db9b.hamish_nospam@yahoo.com> <20060706164522.004be5dc.werchowyna@epf.pl> <20060707201958.1da471d9.hamish_nospam@yahoo.com> Message-ID: <44AE4A00.1000702@itc.it> Hamish wrote on 07/07/2006 10:19 AM: > I was never very clear on this, but have an idea that topology is > meaningless for data which is only points (no tree; only bounding box > matters?). If so, the (correct) solution becomes much easier. > ... nor me. *If* topology is meaningless for point data, then we could add a test in Vect_built() to - check if only points are present in the map, - if so, skip the topology creation. A likewise test would be needed in the Vect_open() routine. Here the question is if we can check beforehand that the map only contains points and then ignore the topology (skip Vect_open_topo() in Vectlib?) Markus From neteler at itc.it Fri Jul 7 16:21:21 2006 From: neteler at itc.it (Markus Neteler) Date: Fri Jul 7 16:21:22 2006 Subject: [GRASS-dev] Programmer's manual: Vector chapter improved Message-ID: <20060707142121.GH15770@bartok.itc.it> Hi, I have given the chapter "GRASS 6 Vector Architecture" a boost: in HTML: http://mpa.itc.it/markus/grass61progman/Vector_Library.html in doxygen: lib/vector/vectorlib.dox in PDF: oops, I just discovered that it's not generated. Coming soon. Markus From hmitaso at unity.ncsu.edu Fri Jul 7 16:27:15 2006 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Fri Jul 7 16:27:20 2006 Subject: [GRASS-dev] [bug #3877] (grass) r.to.vect, v.in.ascii use too much memory for millions of points In-Reply-To: <44AE4A00.1000702@itc.it> References: <20060705183904.4D5031005B9@lists.intevation.de> <20060707011942.00c7db9b.hamish_nospam@yahoo.com> <20060706164522.004be5dc.werchowyna@epf.pl> <20060707201958.1da471d9.hamish_nospam@yahoo.com> <44AE4A00.1000702@itc.it> Message-ID: 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 Jul 7, 2006, at 7:48 AM, Markus Neteler wrote: > Hamish wrote on 07/07/2006 10:19 AM: >> I was never very clear on this, but have an idea that topology is >> meaningless for data which is only points (no tree; only bounding box >> matters?). If so, the (correct) solution becomes much easier. >> > ... nor me. > *If* topology is meaningless for point data, then we could add a test > in Vect_built() to > - check if only points are present in the map, > - if so, skip the topology creation. this is not generaly a good solution - I will get back to this when I have more time - it is good to read Radims document about what to do with the vector format first before further engaging in this discussion - Maciek please read it - that will give you a better idea what is going on. Helena > > A likewise test would be needed in the Vect_open() routine. Here the > question is if we can check beforehand that the map only contains > points and then ignore the topology (skip Vect_open_topo() in > Vectlib?) > > Markus > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From florian.kindl at uibk.ac.at Fri Jul 7 16:50:17 2006 From: florian.kindl at uibk.ac.at (Florian Kindl) Date: Fri Jul 7 16:49:32 2006 Subject: [GRASS-dev] Programmer's manual: Vector chapter improved In-Reply-To: <20060707142121.GH15770@bartok.itc.it> References: <20060707142121.GH15770@bartok.itc.it> Message-ID: <8FE4E8D3-0A5F-4510-B503-C0E2B4A003B4@uibk.ac.at> On 07.07.2006, at 16:21, Markus Neteler wrote: > > I have given the chapter "GRASS 6 Vector Architecture" > a boost: > > in HTML: > http://mpa.itc.it/markus/grass61progman/Vector_Library.html A very welcome boost! :) \flo. From neteler at itc.it Fri Jul 7 17:07:40 2006 From: neteler at itc.it (Markus Neteler) Date: Fri Jul 7 17:07:41 2006 Subject: [GRASS-dev] [bug #3877] (grass) r.to.vect, v.in.ascii use too much memory for millions of points In-Reply-To: References: <20060705183904.4D5031005B9@lists.intevation.de> <20060707011942.00c7db9b.hamish_nospam@yahoo.com> <20060706164522.004be5dc.werchowyna@epf.pl> <20060707201958.1da471d9.hamish_nospam@yahoo.com> <44AE4A00.1000702@itc.it> Message-ID: <44AE78BC.4090406@itc.it> Helena Mitasova wrote on 07/07/2006 04:27 PM: > On Jul 7, 2006, at 7:48 AM, Markus Neteler wrote: >> Hamish wrote on 07/07/2006 10:19 AM: >>> I was never very clear on this, but have an idea that topology is >>> meaningless for data which is only points (no tree; only bounding box >>> matters?). If so, the (correct) solution becomes much easier. >>> >> ... nor me. >> *If* topology is meaningless for point data, then we could add a test >> in Vect_built() to >> - check if only points are present in the map, >> - if so, skip the topology creation. > > this is not generaly a good solution - I will get back to this when I > have more time - > it is good to read Radims document about what to do with the vector > format > first before further engaging in this discussion - Maciek please read > it - > that will give you a better idea what is going on. This is certainly a good idea. May I suggest that someone picks all the pieces from the various (Radim et al.) emails and creates a Wiki page out of that? thanks Markus From hmitaso at unity.ncsu.edu Fri Jul 7 17:54:34 2006 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Fri Jul 7 17:54:30 2006 Subject: [GRASS-dev] [bug #3877] (grass) r.to.vect, v.in.ascii use too much memory for millions of points In-Reply-To: <44AE78BC.4090406@itc.it> References: <20060705183904.4D5031005B9@lists.intevation.de> <20060707011942.00c7db9b.hamish_nospam@yahoo.com> <20060706164522.004be5dc.werchowyna@epf.pl> <20060707201958.1da471d9.hamish_nospam@yahoo.com> <44AE4A00.1000702@itc.it> <44AE78BC.4090406@itc.it> Message-ID: <44AE83BA.2000300@unity.ncsu.edu> Markus Neteler wrote: > Helena Mitasova wrote on 07/07/2006 04:27 PM: > >> On Jul 7, 2006, at 7:48 AM, Markus Neteler wrote: >> >>> Hamish wrote on 07/07/2006 10:19 AM: >>> >>>> I was never very clear on this, but have an idea that topology is >>>> meaningless for data which is only points (no tree; only bounding box >>>> matters?). If so, the (correct) solution becomes much easier. >>>> >>>> >>> ... nor me. >>> *If* topology is meaningless for point data, then we could add a test >>> in Vect_built() to >>> - check if only points are present in the map, >>> - if so, skip the topology creation. >>> >> this is not generaly a good solution - I will get back to this when I >> have more time - >> it is good to read Radims document about what to do with the vector >> format >> first before further engaging in this discussion - Maciek please read >> it - >> that will give you a better idea what is going on. >> > > This is certainly a good idea. May I suggest that someone picks all the > pieces from the various (Radim et al.) emails and creates a Wiki page out > of that? > Markus - the better way would be to add the document that he has written about the next step to do with vector support as a reference into http://mpa.itc.it/markus/grass61progman/Vector_Library.html he has identified scalability as a main issue for vector support and suggests some solutions (I believe it is the building of spatial index that is needed for topology building but potentially for other things that needs to be modified - but I really don't want to go into this without reading it again). As for the emails - most of it is just repeating the same thing over and over (I am starting to be like Radim), although I have posted Radim's suggestion on how to modify v.info and v.to.rast that has not been implemented yet and that might be useful (maybe add it to Radim's document) Helena > thanks > Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- 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 neteler at itc.it Fri Jul 7 18:02:05 2006 From: neteler at itc.it (Markus Neteler) Date: Fri Jul 7 18:02:06 2006 Subject: [GRASS-dev] [bug #3877] (grass) r.to.vect, v.in.ascii use too much memory for millions of points In-Reply-To: <44AE83BA.2000300@unity.ncsu.edu> References: <20060705183904.4D5031005B9@lists.intevation.de> <20060707011942.00c7db9b.hamish_nospam@yahoo.com> <20060706164522.004be5dc.werchowyna@epf.pl> <20060707201958.1da471d9.hamish_nospam@yahoo.com> <44AE4A00.1000702@itc.it> <44AE78BC.4090406@itc.it> <44AE83BA.2000300@unity.ncsu.edu> Message-ID: <20060707160204.GJ15770@bartok.itc.it> On Fri, Jul 07, 2006 at 11:54:34AM -0400, Helena Mitasova wrote: > Markus Neteler wrote: > >Helena Mitasova wrote on 07/07/2006 04:27 PM: > > > >>On Jul 7, 2006, at 7:48 AM, Markus Neteler wrote: > >> > >>>Hamish wrote on 07/07/2006 10:19 AM: > >>> > >>>>I was never very clear on this, but have an idea that topology is > >>>>meaningless for data which is only points (no tree; only bounding box > >>>>matters?). If so, the (correct) solution becomes much easier. > >>>> > >>>> > >>>... nor me. > >>>*If* topology is meaningless for point data, then we could add a test > >>>in Vect_built() to > >>>- check if only points are present in the map, > >>>- if so, skip the topology creation. > >>> > >>this is not generaly a good solution - I will get back to this when I > >>have more time - > >>it is good to read Radims document about what to do with the vector > >>format > >>first before further engaging in this discussion - Maciek please read > >>it - > >>that will give you a better idea what is going on. > >> > > > >This is certainly a good idea. May I suggest that someone picks all the > >pieces from the various (Radim et al.) emails and creates a Wiki page out > >of that? > > > Markus - the better way would be to add the document that he has written > about the next step > to do with vector support as a reference into > http://mpa.itc.it/markus/grass61progman/Vector_Library.html > he has identified scalability as a main issue for vector support and > suggests some solutions > (I believe it is the building of spatial index that is needed for > topology building but potentially for > other things that needs to be modified - but I really don't want to go > into this without reading it again). > As for the emails - most of it is just repeating the same thing over and > over (I am starting > to be like Radim), although I have posted Radim's suggestion on how to > modify > v.info and v.to.rast that has not been implemented yet and that might be > useful (maybe add it to Radim's document) Agreed - add it to Radim's document. At least a document. Currently the info is scattered around and hard to find. Radim's document is there: doc/vector/TODO Markus From werchowyna at epf.pl Fri Jul 7 19:46:54 2006 From: werchowyna at epf.pl (Maciek Sieczka) Date: Fri Jul 7 19:46:45 2006 Subject: [GRASS-dev] current CVS: v.in.ogr doesn't build Message-ID: <20060707194654.99fa9e06.werchowyna@epf.pl> Hi, CVS fetched just a while ago: Errors in: /home/fishoo/src/straight/grass6/vector/v.in.ogr $ cd /home/fishoo/src/straight/grass6/vector/v.in.ogr $ make gcc -I/home/fishoo/src/straight/grass6/dist.i686-pc-linux-gnu/include -g -O2 -I/usr/local/include -DPACKAGE=\""grassmods"\" -I/usr/local/include -I/home/fishoo/src/straight/grass6/dist.i686-pc-linux-gnu/include \ -o OBJ.i686-pc-linux-gnu/main.o -c main.c main.c: In function `main': main.c:632: error: `OFTDate' undeclared (first use in this function) main.c:632: error: (Each undeclared identifier is reported only once main.c:632: error: for each function it appears in.) make: *** [OBJ.i686-pc-linux-gnu/main.o] Error 1 Last time I built on 05 July and all was OK. Since then in GRASS-COMMIT Markus wrote, on 2006.07.06: Modified Files: main.c Log Message: 'NULL' support activated for OFTInteger and OFTReal Modified Files: main.c Log Message: OFTDate added; OFTIntegerList hack polished ? Maciek -------------------- W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich! http://katalog.panoramainternetu.pl/ From glynn at gclements.plus.com Fri Jul 7 20:39:00 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jul 7 20:39:09 2006 Subject: [GRASS-dev] current CVS: v.in.ogr doesn't build In-Reply-To: <20060707194654.99fa9e06.werchowyna@epf.pl> References: <20060707194654.99fa9e06.werchowyna@epf.pl> Message-ID: <17582.43588.702393.150625@cerise.gclements.plus.com> Maciek Sieczka wrote: > CVS fetched just a while ago: > > Errors in: > /home/fishoo/src/straight/grass6/vector/v.in.ogr > > $ cd /home/fishoo/src/straight/grass6/vector/v.in.ogr > $ make > > gcc -I/home/fishoo/src/straight/grass6/dist.i686-pc-linux-gnu/include > -g -O2 -I/usr/local/include -DPACKAGE=\""grassmods"\" > -I/usr/local/include > -I/home/fishoo/src/straight/grass6/dist.i686-pc-linux-gnu/include \ -o > OBJ.i686-pc-linux-gnu/main.o -c main.c main.c: In function `main': > main.c:632: error: `OFTDate' undeclared (first use in this function) > main.c:632: error: (Each undeclared identifier is reported only once > main.c:632: error: for each function it appears in.) make: *** > [OBJ.i686-pc-linux-gnu/main.o] Error 1 > > > > Last time I built on 05 July and all was OK. Since then in GRASS-COMMIT > Markus wrote, on 2006.07.06: > > Modified Files: > main.c > Log Message: > 'NULL' support activated for OFTInteger and OFTReal > > Modified Files: > main.c > Log Message: > OFTDate added; OFTIntegerList hack polished You need the most recent version of GDAL/OGR; the NEWS file at: http://www.remotesensing.org/gdal/NEWS.html says: OGR 1.3.2 - Overview of Changes ------------------------------- OGRFeature: - Added support for OFTDate, OFTTime and OFTDateTime field types. - Also applied to a few drivers (shapefile, mysql, postgres) As 1.3.2 has only been out a couple of months, I doubt that you will be able to get an "official" package from your distribution vendor yet (the 1.3.2 ebuild for Gentoo is still masked on all platforms). -- Glynn Clements From werchowyna at epf.pl Fri Jul 7 21:06:35 2006 From: werchowyna at epf.pl (Maciek Sieczka) Date: Fri Jul 7 21:06:27 2006 Subject: [GRASS-dev] current CVS: v.in.ogr doesn't build In-Reply-To: <17582.43588.702393.150625@cerise.gclements.plus.com> References: <20060707194654.99fa9e06.werchowyna@epf.pl> <17582.43588.702393.150625@cerise.gclements.plus.com> Message-ID: <20060707210635.79bead98.werchowyna@epf.pl> On Fri, 7 Jul 2006 19:39:00 +0100 Glynn Clements wrote: > > Maciek Sieczka wrote: > > > CVS fetched just a while ago: > > > > Errors in: > > /home/fishoo/src/straight/grass6/vector/v.in.ogr > > > > $ cd /home/fishoo/src/straight/grass6/vector/v.in.ogr > > $ make > > > > gcc > > -I/home/fishoo/src/straight/grass6/dist.i686-pc-linux-gnu/include > > -g -O2 -I/usr/local/include -DPACKAGE=\""grassmods"\" > > -I/usr/local/include > > -I/home/fishoo/src/straight/grass6/dist.i686-pc-linux-gnu/include \ > > -o OBJ.i686-pc-linux-gnu/main.o -c main.c main.c: In function > > `main': main.c:632: error: `OFTDate' undeclared (first use in this > > function) main.c:632: error: (Each undeclared identifier is > > reported only once main.c:632: error: for each function it appears > > in.) make: *** [OBJ.i686-pc-linux-gnu/main.o] Error 1 > > > > > > > > Last time I built on 05 July and all was OK. Since then in > > GRASS-COMMIT Markus wrote, on 2006.07.06: > > > > Modified Files: > > main.c > > Log Message: > > 'NULL' support activated for OFTInteger and OFTReal > > > > Modified Files: > > main.c > > Log Message: > > OFTDate added; OFTIntegerList hack polished > > You need the most recent version of GDAL/OGR; the NEWS file at: > > http://www.remotesensing.org/gdal/NEWS.html > > says: > > OGR 1.3.2 - Overview of Changes > ------------------------------- > > OGRFeature: > - Added support for OFTDate, OFTTime and OFTDateTime field > types. > - Also applied to a few drivers (shapefile, mysql, postgres) > > As 1.3.2 has only been out a couple of months, I doubt that you will > be able to get an "official" package from your distribution vendor yet > (the 1.3.2 ebuild for Gentoo is still masked on all platforms). Oops. Time to update GDAL then (using 2006-02-10 for now). Thanks for the information! Maciek -------------------- W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich! http://katalog.panoramainternetu.pl/ From grass-bugs at intevation.de Fri Jul 7 21:49:26 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Fri Jul 7 21:49:28 2006 Subject: [GRASS-dev] [bug #4524] (grass) v.clean, v.patch (else?): output to stderr instead of stdout... Message-ID: <20060707194926.7849B10015B@lists.intevation.de> On Fri, 7 Jul 2006 17:00:00 +0200 (CEST) Markus Neteler via RT wrote: > still an issue? the fprintf's have been changed in v.patch. Yes. v.patch still prints to terminal instead of /dev/null. There is no difference to before the change you mention, ie.: $ v.patch input=map1,map2 output=map3 >/dev/null Patching file map1 Patching file map2 Patch complete. 2 files patched. Intersections at borders will have to be snapped. Lines common between files will have to be edited. The header information also may have to be edited. The above 6 lines should all go to /dev/null, too. v.clean is even worse - *not a single line* is redirected to /dev/null, so each v.clean run results in about 40 lines printed to the terminal. Maciek -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Fri Jul 7 21:55:33 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Fri Jul 7 21:55:33 2006 Subject: [GRASS-dev] [bug #4487] (grass) TCLTK GUI: command window freezes due to a very verbose text output Message-ID: <20060707195533.0B8EA1006B4@lists.intevation.de> On Fri, 7 Jul 2006 16:58:31 +0200 (CEST) Markus Neteler via RT wrote: > still an issue? Maybe Cedric has a comment? Yup, still alive and kicking in current CVS. Several hundreds of lines printed are able to freeze TCL/TK window of r.stats (nviz, v.hull, other) for the command run-time. Maciek -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Fri Jul 7 22:08:19 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Fri Jul 7 22:08:21 2006 Subject: [GRASS-dev] [bug #3046] (grass) r.recode.rules GUI Message-ID: <20060707200819.9233A1006B4@lists.intevation.de> On Fri, 7 Jul 2006 16:47:20 +0200 (CEST) Markus Neteler via RT wrote: > still an issue? Yes. And it was I who promissed to fix it, but now that I know a bit more about Grass and stuff I realize it is impossible for me, because TCL/TK menus are autogenerated :). Or maybe it is possible, by creating symlinks which would make r.recode.rules and r.recode.file HELP button linking to $GISBASE/docs/html/r.recode.html? How exactly, if so? (I could do that then and submit) Maciek -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Fri Jul 7 22:19:36 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Fri Jul 7 22:19:38 2006 Subject: [GRASS-dev] [bug #2962] (grass) v.digit - zooming changes resolution Message-ID: <20060707201936.C32D91005DF@lists.intevation.de> On Fri, 7 Jul 2006 16:44:57 +0200 (CEST) Markus Neteler via RT wrote: > is this still an issue? > Hamish was working on that. Still a problem. See: $ g.region -p projection: 0 (x,y) zone: 0 north: 10000 south: 10 west: 50 east: 5000 nsres: 10 ewres: 10 rows: 999 cols: 495 $ v.digit map1& (a single "Zoom out" click) $ g.region -p projection: 0 (x,y) zone: 0 north: 12068.929 south: -2058.929 west: -975.145 east: 6025.145 ^^^ those should be alligned to multiple 10 nsres: 9.99848408 ewres: 10.00041429 ^^^ those should be equal 10 rows: 1413 cols: 700 Maciek -------------------------------------------- Managed by Request Tracker From neteler at itc.it Sat Jul 8 00:09:15 2006 From: neteler at itc.it (Markus Neteler) Date: Sat Jul 8 00:09:17 2006 Subject: [GRASS-dev] current CVS: v.in.ogr doesn't build In-Reply-To: <17582.43588.702393.150625@cerise.gclements.plus.com> References: <20060707194654.99fa9e06.werchowyna@epf.pl> <17582.43588.702393.150625@cerise.gclements.plus.com> Message-ID: <20060707220915.GA25435@bartok.itc.it> On Fri, Jul 07, 2006 at 07:39:00PM +0100, Glynn Clements wrote: > > Maciek Sieczka wrote: > > > CVS fetched just a while ago: > > > > Errors in: > > /home/fishoo/src/straight/grass6/vector/v.in.ogr > > > > $ cd /home/fishoo/src/straight/grass6/vector/v.in.ogr > > $ make > > > > gcc -I/home/fishoo/src/straight/grass6/dist.i686-pc-linux-gnu/include > > -g -O2 -I/usr/local/include -DPACKAGE=\""grassmods"\" > > -I/usr/local/include > > -I/home/fishoo/src/straight/grass6/dist.i686-pc-linux-gnu/include \ -o > > OBJ.i686-pc-linux-gnu/main.o -c main.c main.c: In function `main': > > main.c:632: error: `OFTDate' undeclared (first use in this function) > > main.c:632: error: (Each undeclared identifier is reported only once > > main.c:632: error: for each function it appears in.) make: *** > > [OBJ.i686-pc-linux-gnu/main.o] Error 1 > > > > > > > > Last time I built on 05 July and all was OK. Since then in GRASS-COMMIT > > Markus wrote, on 2006.07.06: > > > > Modified Files: > > main.c > > Log Message: > > 'NULL' support activated for OFTInteger and OFTReal > > > > Modified Files: > > main.c > > Log Message: > > OFTDate added; OFTIntegerList hack polished > > You need the most recent version of GDAL/OGR; the NEWS file at: > > http://www.remotesensing.org/gdal/NEWS.html > > says: > > OGR 1.3.2 - Overview of Changes > ------------------------------- > > OGRFeature: > - Added support for OFTDate, OFTTime and OFTDateTime field types. > - Also applied to a few drivers (shapefile, mysql, postgres) > > As 1.3.2 has only been out a couple of months, I doubt that you will > be able to get an "official" package from your distribution vendor yet > (the 1.3.2 ebuild for Gentoo is still masked on all platforms). To make everybody happy, I have conditionalized OFTDate on GDAL_VERSION_NUM >= 1320. It doesn't make the code more readable but we can take it out in a couple of months. Maciek, please test this before updating your GDAL installation. Markus From werchowyna at epf.pl Sat Jul 8 01:18:03 2006 From: werchowyna at epf.pl (Maciek Sieczka) Date: Sat Jul 8 01:17:56 2006 Subject: [GRASS-dev] current CVS: v.in.ogr doesn't build In-Reply-To: <20060707220915.GA25435@bartok.itc.it> References: <20060707194654.99fa9e06.werchowyna@epf.pl> <17582.43588.702393.150625@cerise.gclements.plus.com> <20060707220915.GA25435@bartok.itc.it> Message-ID: <20060708011803.951f6f38.werchowyna@epf.pl> On Sat, 8 Jul 2006 00:09:15 +0200 Markus Neteler wrote: > To make everybody happy, I have conditionalized OFTDate on > GDAL_VERSION_NUM >= 1320. It doesn't make the code more readable but > we can take it out in a couple of months. > > Maciek, please test this before updating your GDAL installation. Done. v.in.ogr builds OK with GDAL 1.3.1. Maciek -------------------- W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich! http://katalog.panoramainternetu.pl/ From Michael.Barton at asu.edu Sat Jul 8 08:07:55 2006 From: Michael.Barton at asu.edu (Michael Barton) Date: Sat Jul 8 08:09:44 2006 Subject: [GRASS-dev] displaying (slightly) broken raster maps in gis.m In-Reply-To: <20060707203555.50b95a00.hamish_nospam@yahoo.com> Message-ID: Gis.m is just a wrapper for d.rast. So I'm not sure why one should display a map and the other one won't. ????????????? 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: Fri, 7 Jul 2006 20:35:55 +1200 > To: grass5 > Subject: [GRASS-dev] displaying (slightly) broken raster maps in gis.m > > We noticed gis.m will not display a raster map if the cats/ file is > missing but d.rast will. > > is this something to fix, or nothing to worry about? > > (mapset was broken after bulk copy via FAT32 external hard drive problems) > > > Hamish > > From glynn at gclements.plus.com Sat Jul 8 09:49:46 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jul 8 09:50:04 2006 Subject: [GRASS-dev] displaying (slightly) broken raster maps in gis.m In-Reply-To: References: <20060707203555.50b95a00.hamish_nospam@yahoo.com> Message-ID: <17583.25498.356980.121631@cerise.gclements.plus.com> Michael Barton wrote: > > We noticed gis.m will not display a raster map if the cats/ file is > > missing but d.rast will. > > > > is this something to fix, or nothing to worry about? > > > > (mapset was broken after bulk copy via FAT32 external hard drive problems) > > Gis.m is just a wrapper for d.rast. So I'm not sure why one should display a > map and the other one won't. gis.m/raster.tcl seems to do a bit more than just run d.rast. BTW, looking at that code, I note that the failure to treat commands as lists appears to be a common problem within gis.m, e.g.: set cmd "d.rast map=$opt($id,1,map)" # overlay if { $opt($id,1,overlay) } { append cmd " -o" } [snip] # raster query if { $opt($id,1,rastquery) != "" } { append cmd " {$querytype=$opt($id,1,rastquery)}" } # background color if { $opt($id,1,bkcolor) != "" } { append cmd " bg=$opt($id,1,bkcolor)" } Although this particular case should work (certainly, none of the arguments can contain spaces, and I don't think that they can contain braces), in general you should be using list operations, e.g.: set cmd [list d.rast map=$opt($id,1,map)] # overlay if { $opt($id,1,overlay) } { lappend cmd -o } [snip] # raster query if { $opt($id,1,rastquery) != "" } { lappend cmd $querytype=$opt($id,1,rastquery) } # background color if { $opt($id,1,bkcolor) != "" } { lappend cmd bg=$opt($id,1,bkcolor) } Etc. Whilst it is technically sufficient to use list operations only where necessary, that requires you to actually consider whether or not they are necessary. As most of the time they aren't necessary, overlooking the few cases where they /are/ necessary (e.g. filenames, SQL "WHERE" clauses etc) becomes almost inevitable. -- Glynn Clements From neteler at itc.it Sat Jul 8 12:08:29 2006 From: neteler at itc.it (Markus Neteler) Date: Sat Jul 8 12:08:30 2006 Subject: [GRASS-dev] current CVS: v.in.ogr doesn't build In-Reply-To: <20060708011803.951f6f38.werchowyna@epf.pl> References: <20060707194654.99fa9e06.werchowyna@epf.pl> <17582.43588.702393.150625@cerise.gclements.plus.com> <20060707220915.GA25435@bartok.itc.it> <20060708011803.951f6f38.werchowyna@epf.pl> Message-ID: <20060708100829.GD28425@bartok.itc.it> On Sat, Jul 08, 2006 at 01:18:03AM +0200, Maciek Sieczka wrote: > On Sat, 8 Jul 2006 00:09:15 +0200 > Markus Neteler wrote: > > > To make everybody happy, I have conditionalized OFTDate on > > GDAL_VERSION_NUM >= 1320. It doesn't make the code more readable but > > we can take it out in a couple of months. > > > > Maciek, please test this before updating your GDAL installation. > > Done. v.in.ogr builds OK with GDAL 1.3.1. Good. Now update your GDAL :-) You don't want to miss the improvements... Markus From Michael.Barton at asu.edu Sat Jul 8 16:28:41 2006 From: Michael.Barton at asu.edu (Michael Barton) Date: Sat Jul 8 16:30:40 2006 Subject: [GRASS-dev] displaying (slightly) broken raster maps in gis.m In-Reply-To: <17583.25498.356980.121631@cerise.gclements.plus.com> Message-ID: Glynn and Hamish, Checking in. It sounds like it would be good to shift most command stuff to lists as you suggested earlier. Most of the raster layer option just uses d.rast. However, if you want to do a color drape and put something into the drape map field, it switches to d.his. 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: Glynn Clements > Date: Sat, 8 Jul 2006 08:49:46 +0100 > To: Michael Barton > Cc: Hamish , grass5 > Subject: Re: [GRASS-dev] displaying (slightly) broken raster maps in gis.m > > > Michael Barton wrote: > >>> We noticed gis.m will not display a raster map if the cats/ file is >>> missing but d.rast will. >>> >>> is this something to fix, or nothing to worry about? >>> >>> (mapset was broken after bulk copy via FAT32 external hard drive problems) >> >> Gis.m is just a wrapper for d.rast. So I'm not sure why one should display a >> map and the other one won't. > > gis.m/raster.tcl seems to do a bit more than just run d.rast. > > BTW, looking at that code, I note that the failure to treat commands > as lists appears to be a common problem within gis.m, e.g.: > > set cmd "d.rast map=$opt($id,1,map)" > > # overlay > if { $opt($id,1,overlay) } { > append cmd " -o" > } > > [snip] > > # raster query > if { $opt($id,1,rastquery) != "" } { > append cmd " {$querytype=$opt($id,1,rastquery)}" > } > > # background color > if { $opt($id,1,bkcolor) != "" } { > append cmd " bg=$opt($id,1,bkcolor)" > } > > Although this particular case should work (certainly, none of the > arguments can contain spaces, and I don't think that they can contain > braces), in general you should be using list operations, e.g.: > > set cmd [list d.rast map=$opt($id,1,map)] > > # overlay > if { $opt($id,1,overlay) } { > lappend cmd -o > } > > [snip] > > # raster query > if { $opt($id,1,rastquery) != "" } { > lappend cmd $querytype=$opt($id,1,rastquery) > } > > # background color > if { $opt($id,1,bkcolor) != "" } { > lappend cmd bg=$opt($id,1,bkcolor) > } > > Etc. > > Whilst it is technically sufficient to use list operations only where > necessary, that requires you to actually consider whether or not they > are necessary. As most of the time they aren't necessary, overlooking > the few cases where they /are/ necessary (e.g. filenames, SQL "WHERE" > clauses etc) becomes almost inevitable. > > -- > Glynn Clements From michael.barton at asu.edu Sat Jul 8 16:36:18 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sat Jul 8 16:36:56 2006 Subject: [GRASS-dev] [bug #3046] (grass) r.recode.rules GUI In-Reply-To: <20060707200819.9233A1006B4@lists.intevation.de> Message-ID: I think that all you need to do is create a file named r.recode.rules.html and put it in the right place. 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: Maciek Sieczka via RT > Reply-To: Maciek Sieczka via RT > Date: Fri, 7 Jul 2006 22:08:19 +0200 (CEST) > Cc: , > Subject: [GRASS-dev] [bug #3046] (grass) r.recode.rules GUI > > On Fri, 7 Jul 2006 16:47:20 +0200 (CEST) > Markus Neteler via RT wrote: > >> still an issue? > > Yes. And it was I who promissed to fix it, but now that I know a bit more > about Grass and stuff I realize it is impossible for me, because TCL/TK menus > are autogenerated :). Or maybe it is possible, by creating symlinks which > would make r.recode.rules and r.recode.file HELP button linking to > $GISBASE/docs/html/r.recode.html? How exactly, if so? (I could do that then > and submit) > > Maciek > > > -------------------------------------------- Managed by Request Tracker > > From grass-bugs at intevation.de Sat Jul 8 21:13:51 2006 From: grass-bugs at intevation.de (Markus Neteler via RT) Date: Sat Jul 8 21:13:57 2006 Subject: [GRASS-dev] [bug #3046] (grass) r.recode.rules GUI Message-ID: <20060708191351.264D3100160@lists.intevation.de> Hi, Michael is right. as a test I tried: cd docs/html/ ln -s r.recode.html r.recode.rules.html Then the r.recode.rules help button works. Ideas how to avoid a replication of the original pages? Make a cp while installing r.recode.rules? Markus -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Sat Jul 8 22:22:25 2006 From: grass-bugs at intevation.de (Paul Kelly via RT) Date: Sat Jul 8 22:22:27 2006 Subject: [GRASS-dev] [bug #4764] (grass) Give NetBSD a distinct configuration section in aclocal.m4. Message-ID: <20060708202225.DCF8A100160@lists.intevation.de> Markus: To decode the attachment, copy and paste into a text file and save with a .uue extension. Then open with Winzip and you can extract the attached file from there. Of course this only works on Windows ;) You should be able to achieve the same with the 'uudecode' command on Linux but I didn't get it working... Brook: Patch applied and in CVS now. Please test. -------------------------------------------- Managed by Request Tracker From glynn at gclements.plus.com Sat Jul 8 23:12:37 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jul 8 23:12:45 2006 Subject: [GRASS-dev] [bug #3046] (grass) r.recode.rules GUI In-Reply-To: <20060708191351.264D3100160@lists.intevation.de> References: <20060708191351.264D3100160@lists.intevation.de> Message-ID: <17584.8133.929255.697469@cerise.gclements.plus.com> Markus Neteler via RT wrote: > Michael is right. as a test I tried: > > cd docs/html/ > ln -s r.recode.html r.recode.rules.html > > Then the r.recode.rules help button works. Ideas how to > avoid a replication of the original pages? Make a cp > while installing r.recode.rules? The scripts don't take the same set of arguments as the modules which they use, so they should have their own manual pages. They can refer to the manual page for the underlying module in the "SEE ALSO" section. -- Glynn Clements From soerengebbert at gmx.de Sun Jul 9 00:15:24 2006 From: soerengebbert at gmx.de (Soeren Gebbert) Date: Sun Jul 9 00:15:33 2006 Subject: [GRASS-dev] New raster-to-raster3d conversion module Message-ID: <200607090015.25361.soerengebbert@gmx.de> Dear devs, i would like to add a new raster-to-raster3d conversion module to the grass6.1 CVS in the near future. The module is called r.elev.to.rast3. It creates a new 3D raster map from a 2D elevation and a 2D "value" raster map. The principal functioning is shown here: http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r.elev.to.rast3.png The module sources are available here: http://www-pool.math.tu-berlin.de/~soeren/grass/modules/r.elev.to.rast3.tar.gz A sample screenshot of the spearfish dataset: http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r.elev.to.rast3_spearfish.png This data was created with r.elev.to.rast3, exported with r3.out.vtk and visualized with Paraview (i used the threshold filter and the opacity functionality, to separate the ground from the air). This example is included in the documentation of the module (description.html). I would like to ask if i can commit this module next week, or if i have to wait until GRASS 6.1.0 is released? I have tested this module with different datasets and it seems to work properly. And i will add some tests to the grass test-suite. Maybe someone want to test this module. A short description with examples is available in the tar.gz file. I think together with r.to.rast3 http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r.to.rast3.png r3.to.rast http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r3.to.rast.png and r3.cross.rast http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r3.cross.rast.png the raster<->rast3d modelling/conversion capabilities are mostly complete. If somebody has a any ideas how to improve the existing modules, or about a new module, please tell me. I will try to implement it. Any suggestions, opinions are welcome. Best regards Soeren btw.: I have posted this mail to the grass-user list too. Maybe someone of the users want to test it. :) From ychemin at gmail.com Sun Jul 9 07:48:04 2006 From: ychemin at gmail.com (Yann Chemin) Date: Sun Jul 9 07:48:06 2006 Subject: [GRASS-dev] r.in.gdal to group automatically imported multi-bands image Message-ID: <6278879c0607082248n65b81c0anb88895e0bafbd045@mail.gmail.com> Hello list, When dealing with multi-band satellite data, it is generally easier to group them, and generally we import this data from, say a GeoTiff that is already a multi-band. Could we consider trying to make a group directly on import in r.in.gdal by the name of the image? Imagine people that deal with temporal/hyperspectral data, it could be beneficial. Following this idea, 2 things: 1-GIS.M to load groups directly (i am not familiar to know if this is already there) 2-Attach a default group display command to choose from greyscale or RGB I believe this could help some "image processing" people to use GRASS. Yann From neteler at itc.it Sun Jul 9 12:24:39 2006 From: neteler at itc.it (Markus Neteler) Date: Sun Jul 9 12:24:40 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: <20060705225900.GL24748@bartok.itc.it> References: <20060703164112.GN19781@bartok.itc.it> <20060704152632.09e9075d.hamish_nospam@yahoo.com> <20060704133435.GF21351@bartok.itc.it> <20060705095506.6b336afe.hamish_nospam@yahoo.com> <44AB6C04.10908@itc.it> <20060706030340.40842889.hamish_nospam@yahoo.com> <20060705225900.GL24748@bartok.itc.it> Message-ID: <20060709102439.GA2210@bartok.itc.it> Hi developers, back to the open issues: Closed issues: > - r.sim.water/64bit: almost done, patch under review r.sim.water now done for 64bit, probably there are other open issues which could be backported if needed. > - snprintf(): almost done, patch under review ...partially done. We'll backport later the remaining things. On Fri, Jul 07, 2006 at 01:27:26AM +1200, Hamish wrote: > > - r.to.vect memory consumption with zillion points > -b "skip topology building" was added to r.to.vect soon after r.in.xyz > was introduced. If that solves it, the "bug" can be combined with the > long standing v.in.ascii issue. > - gis.m exec statements AFAIK done. > - NVIZ/Mac issues Glynn added improvements for OpenGL under Mac/Windows. Does it solve the problems now or a further changes needed? Extras done: - netBSD config fix - v.in.ogr DATE support (if GDAL 1.3.2 present), WHERE support - improved vector section in the programmer's manual with language enhancements by Scott Still open issues: > - NVIZ volume: broken (https://intevation.de/rt/webrt?serial_num=4725) ...is this a showstopper? > - announcement to be improved (maybe split into short and long version) > - update roadmap.html (Web-CVS) What about moving the roadmap to Wiki? TODO: - improve announcement - decide about Soeren's new r3 module I'll be busy the next couple of days, so I suggest to defer branching to the end of next week. Markus From soerengebbert at gmx.de Sun Jul 9 16:17:16 2006 From: soerengebbert at gmx.de (Soeren Gebbert) Date: Sun Jul 9 16:17:21 2006 Subject: [GRASS-dev] Re: [bug #4725] (grass) nviz crashed while volume visualisation In-Reply-To: <20060628101310.A6E971005BB@lists.intevation.de> References: <20060628101310.A6E971005BB@lists.intevation.de> Message-ID: <200607091617.17441.soerengebbert@gmx.de> Hi, On Wednesday 28 June 2006 12:13, Harmish Bowman via RT wrote: > [ https://intevation.de/rt/webrt?serial_num=4725 ] > Hi, > "nviz volume=map3d" segfaults.. see bug report for spearfish example. > I've traced it back to incorrect mode in nviz/src/volume.c > > slice_get_drawmode() > > mode=1969841253 (or so) > > when it should be like DM_GOURAUD=256 or DM_FLAT=512 > actual segfault seems to happen after slice_get_drawmode()'s > > return (TCL_ERROR); > > ??? > > called from scripts/panel_vol.tcl line ~450: > > set Nv_(ShadeStyle) [Nvol$curr slice get_drawmode] > I followed "mode" into lib/ogsf/GVL2.c GVL_slice_get_drawmode() > > and then *gvl to gvl_get_vol() in lib/ogsf/gvl.c, but then I get lost. > uninit'd variable? > Hamish Looks like. If nviz is called with -q and a volume + isosurfaces are added -> nviz segfaults. I have corrected the uninitialized variable: cvs server: Diffing . Index: gvl_calc.c =================================================================== RCS file: /home/grass/grassrepository/grass6/lib/ogsf/gvl_calc.c,v retrieving revision 1.3 diff -u -r1.3 gvl_calc.c --- gvl_calc.c 9 Feb 2006 03:08:57 -0000 1.3 +++ gvl_calc.c 9 Jul 2006 13:48:54 -0000 @@ -444,7 +444,7 @@ { int x, y, z; int i, a, read; - geovol_file *vf; + geovol_file *vf = NULL; geovol_isosurf *isosurf; data_buffer *dbuff; and it works for me now. But i am not sure if this realy fixed the problem. But there is a second problem. If i start nviz with the option "volume" and a valid volume map e.g.: nviz volume=vol nviz receives a segmentation fault. This seems to be related to this line: /home/grass/grassrepository/grass6/visualization/nviz/src/togl_flythrough.c:786 buf_vol = Tcl_GetVar(interp, "volume", TCL_GLOBAL_ONLY); buf_vol is a NULL pointer and the program segfaults while the atoi(buf_*) calls later. Something realy strange happens here if a volume map is provided. Maybe the parsing functionality for volume maps is broken? I have no clue where this functionality is defined, so i'm not able to fix this. :( Best Soeren From glynn at gclements.plus.com Sun Jul 9 22:43:49 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jul 9 22:43:56 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: <20060709102439.GA2210@bartok.itc.it> References: <20060703164112.GN19781@bartok.itc.it> <20060704152632.09e9075d.hamish_nospam@yahoo.com> <20060704133435.GF21351@bartok.itc.it> <20060705095506.6b336afe.hamish_nospam@yahoo.com> <44AB6C04.10908@itc.it> <20060706030340.40842889.hamish_nospam@yahoo.com> <20060705225900.GL24748@bartok.itc.it> <20060709102439.GA2210@bartok.itc.it> Message-ID: <17585.27269.621823.431077@cerise.gclements.plus.com> Markus Neteler wrote: > > - gis.m exec statements > AFAIK done. No; there is still a lot of "eval exec ..." in gis.m. Also, the commands are being construced by string concatenation rather than list concatenation. > > - NVIZ/Mac issues > Glynn added improvements for OpenGL under Mac/Windows. Does it solve > the problems now or a further changes needed? There are two issues here. One is that neither version (X11 or native) of NVIZ works on Intel macs. That appears to be an issue with the OpenGL libraries on that platform, although some OpenGL programs are reported to work. I don't know if this is something that can be worked around in NVIZ. The other is that the native version is still in its early stages. The first working test was within the last few days, and it's only been tested on one system so far. Apparently, there are significant differences between different versions of Aqua Tcl/Tk. -- Glynn Clements From glynn at gclements.plus.com Sun Jul 9 23:00:45 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jul 9 23:00:54 2006 Subject: [GRASS-dev] Re: [bug #4725] (grass) nviz crashed while volume visualisation In-Reply-To: <200607091617.17441.soerengebbert@gmx.de> References: <20060628101310.A6E971005BB@lists.intevation.de> <200607091617.17441.soerengebbert@gmx.de> Message-ID: <17585.28285.267945.416942@cerise.gclements.plus.com> Soeren Gebbert wrote: > > and then *gvl to gvl_get_vol() in lib/ogsf/gvl.c, but then I get lost. > > > uninit'd variable? > > Hamish > > Looks like. > If nviz is called with -q and a volume + isosurfaces are added -> nviz segfaults. > I have corrected the uninitialized variable: > > cvs server: Diffing . > Index: gvl_calc.c > =================================================================== > RCS file: /home/grass/grassrepository/grass6/lib/ogsf/gvl_calc.c,v > retrieving revision 1.3 > diff -u -r1.3 gvl_calc.c > --- gvl_calc.c 9 Feb 2006 03:08:57 -0000 1.3 > +++ gvl_calc.c 9 Jul 2006 13:48:54 -0000 > @@ -444,7 +444,7 @@ > { > int x, y, z; > int i, a, read; > - geovol_file *vf; > + geovol_file *vf = NULL; > geovol_isosurf *isosurf; > > data_buffer *dbuff; > > > and it works for me now. But i am not sure if this realy fixed the > problem. I don't think so. In that function (gvl_isosurf_calc), "vf" is only read if the variable "read" is non-zero. But the only places which set "read" also set "vf": -- Glynn Clements From michael.barton at asu.edu Mon Jul 10 00:18:08 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Jul 10 00:18:14 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: <20060709102439.GA2210@bartok.itc.it> Message-ID: Glynn finished the RMS module I need to complete the georectifier for GRASS 6.x. I'm currently out of town and won't be able to work on it until next week. But I think it will come together very quickly. 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: Markus Neteler > Date: Sun, 9 Jul 2006 12:24:39 +0200 > To: > Subject: Re: [GRASS-dev] GRASS 6.1.0 release preparation > > Hi developers, > > back to the open issues: > > > Closed issues: >> - r.sim.water/64bit: almost done, patch under review > r.sim.water now done for 64bit, probably there are other open > issues which could be backported if needed. > >> - snprintf(): almost done, patch under review > ...partially done. We'll backport later the remaining things. > > On Fri, Jul 07, 2006 at 01:27:26AM +1200, Hamish wrote: >>> - r.to.vect memory consumption with zillion points >> -b "skip topology building" was added to r.to.vect soon after r.in.xyz >> was introduced. If that solves it, the "bug" can be combined with the >> long standing v.in.ascii issue. > >> - gis.m exec statements > AFAIK done. > >> - NVIZ/Mac issues > Glynn added improvements for OpenGL under Mac/Windows. Does it solve > the problems now or a further changes needed? > > Extras done: > - netBSD config fix > - v.in.ogr DATE support (if GDAL 1.3.2 present), WHERE support > - improved vector section in the programmer's manual with language > enhancements by Scott > > > Still open issues: >> - NVIZ volume: broken (https://intevation.de/rt/webrt?serial_num=4725) > > ...is this a showstopper? > >> - announcement to be improved (maybe split into short and long version) >> - update roadmap.html (Web-CVS) > > What about moving the roadmap to Wiki? > > TODO: > - improve announcement > - decide about Soeren's new r3 module > > > I'll be busy the next couple of days, so I suggest to defer branching > to the end of next week. > > Markus > > From hamish_nospam at yahoo.com Mon Jul 10 02:53:27 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jul 10 02:53:36 2006 Subject: [GRASS-dev] New raster-to-raster3d conversion module In-Reply-To: <200607090015.25361.soerengebbert@gmx.de> References: <200607090015.25361.soerengebbert@gmx.de> Message-ID: <20060710125327.56049a3b.hamish_nospam@yahoo.com> Soeren Gebbert wrote: > i would like to add a new raster-to-raster3d conversion module > to the grass6.1 CVS in the near future. > > The module is called r.elev.to.rast3. > It creates a new 3D raster map from a 2D elevation and a > 2D "value" raster map. The principal functioning is shown here: > http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r.elev.to.rast3.png Congratulations on the new module! > I would like to ask if i can commit this module next week, or if i > have to wait until GRASS 6.1.0 is released? > I have tested this module with different datasets and it seems to work > properly. And i will add some tests to the grass test-suite. If the new module is ready to be in CVS, but you are not sure if it is release-ready, you can always put it in CVS but not add it to the Makefile or GUI menus. (as long as the change doesn't touch other parts of the software) > I think together with r.to.rast3 > http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r.to.rast3.png > r3.to.rast > http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r3.to.rast.png > and r3.cross.rast > http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r3.cross.rast.png > the raster<->rast3d modelling/conversion capabilities are mostly > complete. Small versions of those pics would be a great addition to the help pages, see r.terraflow, v.voronoi for examples. Hamish From hamish_nospam at yahoo.com Mon Jul 10 08:44:10 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jul 10 08:44:17 2006 Subject: [GRASS-dev] [bug #4524] (grass) v.clean, v.patch (else?): output to stderr instead of stdout... In-Reply-To: <20060707194926.7849B10015B@lists.intevation.de> References: <20060707194926.7849B10015B@lists.intevation.de> Message-ID: <20060710184410.37a73969.hamish_nospam@yahoo.com> Maciek Sieczka wrote: > > still an issue? the fprintf's have been changed in v.patch. > > Yes. > > v.patch still prints to terminal instead of /dev/null. There is no > difference to before the change you mention, ie.: > > $ v.patch input=map1,map2 output=map3 >/dev/null > Patching file map1 > Patching file map2 > Patch complete. 2 files patched. > Intersections at borders will have to be snapped. > Lines common between files will have to be edited. > The header information also may have to be edited. > > The above 6 lines should all go to /dev/null, too. v.clean is even > worse - *not a single line* is redirected to /dev/null, so each > v.clean run results in about 40 lines printed to the terminal. GRASS sends general messages to stderr and parsable output to stdout. to redirect stderr to /dev/null do: G61> v.patch input=map1,map2 output=map3 2> /dev/null note this will send errors and warnings to /dev/null too, which may not be what you want. most modules should be quiet by default (I think ESR asks for "only display output if something surprising happens"), but include a -v verbose flag if verbose output could be interesting (e.g. long running modules). Really long running modules may want to send some heartbeat or status messages. > G> v.patch input=map1,map2 output=map3 >/dev/null > Patching file map1 > Patching file map2 These look like they might be put behind a -v verbose flag or G_debug(1,""); > Patch complete. 2 files patched. > Intersections at borders will have to be snapped. > Lines common between files will have to be edited. > The header information also may have to be edited. These look like they should remain with G_message(). Hamish From hamish_nospam at yahoo.com Mon Jul 10 08:55:48 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jul 10 08:55:52 2006 Subject: [GRASS-dev] [bug #2962] (grass) v.digit - zooming changes resolution In-Reply-To: <20060707201936.C32D91005DF@lists.intevation.de> References: <20060707201936.C32D91005DF@lists.intevation.de> Message-ID: <20060710185548.20f34c76.hamish_nospam@yahoo.com> Maciek Sieczka wrote: > > is this still an issue? > > Hamish was working on that. > > Still a problem. See: > > $ g.region -p > projection: 0 (x,y) > zone: 0 > north: 10000 > south: 10 > west: 50 > east: 5000 > nsres: 10 > ewres: 10 > rows: 999 > cols: 495 > > $ v.digit map1& > > (a single "Zoom out" click) > > $ g.region -p > projection: 0 (x,y) > zone: 0 > north: 12068.929 > south: -2058.929 > west: -975.145 > east: 6025.145 > ^^^ > those should be alligned to multiple 10 > > nsres: 9.99848408 > ewres: 10.00041429 > ^^^ > those should be equal 10 > > rows: 1413 > cols: 700 are you using the latest CVS??? It should restore the starting region on (normal) exit. This bug should be kept open as the v.digit code should a) not be changing the WIND file (if possible with mixed Tcl + C) and b) use "g.region -a" like code when zooming so as not to corrupt background raster resampling. Hamish From hamish_nospam at yahoo.com Mon Jul 10 09:00:08 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jul 10 09:00:16 2006 Subject: [GRASS-dev] r.in.gdal to group automatically imported multi-bands image In-Reply-To: <6278879c0607082248n65b81c0anb88895e0bafbd045@mail.gmail.com> References: <6278879c0607082248n65b81c0anb88895e0bafbd045@mail.gmail.com> Message-ID: <20060710190008.45e80c30.hamish_nospam@yahoo.com> Yann Chemin wrote: > When dealing with multi-band satellite data, it is generally easier to > group them, and generally we import this data from, say a GeoTiff that > is already a multi-band. > > Could we consider trying to make a group directly on import in > r.in.gdal by the name of the image? Imagine people that deal with > temporal/hyperspectral data, it could be beneficial. I was under the impression that r.in.gdal DID do this already (GRASS 6.1 anyway). e.g. r.in.onearth (r.in.wms) creates the group. > Following this idea, 2 things: > 1-GIS.M to load groups directly (i am not familiar to know if this is > already there) > 2-Attach a default group display command to choose from greyscale or > RGB > > I believe this could help some "image processing" people to use GRASS. d.rgb group=groupname could work if the was a consistant naming for bands, and the extension could be predicted. scan.r scan.b scan.c but "r.in.onearth -l tmband=visual" creates: satimage.1 satimage.2 satimage.3 for r,g,b? Hamish From hamish_nospam at yahoo.com Mon Jul 10 09:02:13 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jul 10 09:02:18 2006 Subject: [GRASS-dev] [bug #3877] (grass) r.to.vect, v.in.ascii use too much memory for millions of points In-Reply-To: <44AE78BC.4090406@itc.it> References: <20060705183904.4D5031005B9@lists.intevation.de> <20060707011942.00c7db9b.hamish_nospam@yahoo.com> <20060706164522.004be5dc.werchowyna@epf.pl> <20060707201958.1da471d9.hamish_nospam@yahoo.com> <44AE4A00.1000702@itc.it> <44AE78BC.4090406@itc.it> Message-ID: <20060710190213.1496ec6b.hamish_nospam@yahoo.com> Markus Neteler wrote: > This is certainly a good idea. May I suggest that someone picks all > the pieces from the various (Radim et al.) emails and creates a Wiki > page out of that? It would be good to keep Radim's comments quoted, versus merging Radim's comments with my half-guesses etc. Hamish From hamish_nospam at yahoo.com Mon Jul 10 09:03:47 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jul 10 09:03:52 2006 Subject: [GRASS-dev] [bug #3877] (grass) r.to.vect, v.in.ascii use too much memory for millions of points In-Reply-To: <20060707160204.GJ15770@bartok.itc.it> References: <20060705183904.4D5031005B9@lists.intevation.de> <20060707011942.00c7db9b.hamish_nospam@yahoo.com> <20060706164522.004be5dc.werchowyna@epf.pl> <20060707201958.1da471d9.hamish_nospam@yahoo.com> <44AE4A00.1000702@itc.it> <44AE78BC.4090406@itc.it> <44AE83BA.2000300@unity.ncsu.edu> <20060707160204.GJ15770@bartok.itc.it> Message-ID: <20060710190347.1dbba617.hamish_nospam@yahoo.com> Markus: > Agreed - add it to Radim's document. At least a document. > Currently the info is scattered around and hard to find. > > Radim's document is there: > doc/vector/TODO Are you speaking of a list links to historic grass5 emails at the end of the TODO file? I think that is a great idea. Hamish From tutey at o2.pl Mon Jul 10 09:08:13 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Jul 10 09:08:16 2006 Subject: [GRASS-dev] Re: [bug #4524] (grass) v.clean, v.patch (else?): In-Reply-To: <20060710064430.BE7B1100160@lists.intevation.de> References: <20060710064430.BE7B1100160@lists.intevation.de> Message-ID: <20060710090813.3bbbe8df@sorbus> Mon, 10 Jul 2006 08:44:30 +0200 (CEST) Hamish via RT wrote: > Maciek Sieczka wrote: > > > > still an issue? the fprintf's have been changed in v.patch. > > > > Yes. > > > > v.patch still prints to terminal instead of /dev/null. There is no > > difference to before the change you mention, ie.: > > > > $ v.patch input=map1,map2 output=map3 >/dev/null > > Patching file map1 > > Patching file map2 > > Patch complete. 2 files patched. > > Intersections at borders will have to be snapped. > > Lines common between files will have to be edited. > > The header information also may have to be edited. > > > > The above 6 lines should all go to /dev/null, too. v.clean is even > > worse - *not a single line* is redirected to /dev/null, so each > > v.clean run results in about 40 lines printed to the terminal. > > > GRASS sends general messages to stderr and parsable output to stdout. > > to redirect stderr to /dev/null do: > > G61> v.patch input=map1,map2 output=map3 2> /dev/null > note this will send errors and warnings to /dev/null too, which may > not be what you want. You are right, that is not a solution. We want errors and warnings be let through. > most modules should be quiet by default (I think ESR asks for "only > display output if something surprising happens"), but include a -v > verbose flag if verbose output could be interesting (e.g. long running > modules). Really long running modules may want to send some heartbeat > or status messages. > > > G> v.patch input=map1,map2 output=map3 >/dev/null > > Patching file map1 > > Patching file map2 > > These look like they might be put behind a -v verbose flag or > G_debug(1,""); > > > Patch complete. 2 files patched. > > Intersections at borders will have to be snapped. > > Lines common between files will have to be edited. > > The header information also may have to be edited. > > These look like they should remain with G_message(). What for? >/dev/null should result in filtering out all standard information. Only information in case of unexpected module behaviour should be let through. This will make user's scripts output cleaner. The above info is usefull for a single v.patch run, to give guiding to the user on how to proceed. But when v.patch is called from a script it is script's author responsibility to be aware of such caveats and use v.patch properly. IOW, when v.patch is called from a script the standard message above is not improving anything but decreases the output clarity. Same for v.clean or any other module. Maciek From tutey at o2.pl Mon Jul 10 09:20:30 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Jul 10 09:20:32 2006 Subject: [GRASS-dev] Re: [bug #2962] (grass) v.digit - zooming changes In-Reply-To: <20060710065554.A3671100160@lists.intevation.de> References: <20060710065554.A3671100160@lists.intevation.de> Message-ID: <20060710092030.3f638446@sorbus> Dnia Mon, 10 Jul 2006 08:55:54 +0200 (CEST) Hamish via RT napisa?(a): > Maciek Sieczka wrote: > > > > is this still an issue? > > > Hamish was working on that. > > > > Still a problem. See: > > > > $ g.region -p > > projection: 0 (x,y) > > zone: 0 > > north: 10000 > > south: 10 > > west: 50 > > east: 5000 > > nsres: 10 > > ewres: 10 > > rows: 999 > > cols: 495 > > > > $ v.digit map1& > > > > (a single "Zoom out" click) > > > > $ g.region -p > > projection: 0 (x,y) > > zone: 0 > > north: 12068.929 > > south: -2058.929 > > west: -975.145 > > east: 6025.145 > > ^^^ > > those should be alligned to multiple 10 > > > > nsres: 9.99848408 > > ewres: 10.00041429 > > ^^^ > > those should be equal 10 > > > > rows: 1413 > > cols: 700 > > > are you using the latest CVS??? Yes. Here I run g.region -p *during* v.digit session. > It should restore the starting region on (normal) exit. And it does. But during the v.digit run resolution still changes as I zoom in/out. And this shouldn't happen. I want my backdrop raster to be displayed with a constant resolution, so I can trust what I see. Restoring initial region is a nice feature though. > This bug should be kept open as the v.digit code should a) not be > changing the WIND file (if possible with mixed Tcl + C) and b) use > "g.region -a" like code when zooming so as not to corrupt background > raster resampling. Yes, that's the point. Maciek From grass-bugs at intevation.de Mon Jul 10 11:09:07 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Mon Jul 10 11:09:08 2006 Subject: [GRASS-dev] [bug #4310] (grass) db.drivers: what do the -pf actually do? Message-ID: <20060710090907.2B3721005DD@lists.intevation.de> Hamish wrote: > The module is to tell you about installed db DRIVERS not TABLES. > It is working fine. Hamish, Yes it is *partially* working fine *now*, *after* Markus fix. Before it used to refer to tables (in error) and that's one point of the bug report. The other thing is that -f "Full output" still prints only: $ db.drivers -f sqlite: dbf: ogr: pg: For which you seem to have found the reason: > AFAICT, comment is unused in GRASS 6 (???). > see lib/db/dbmi_base/dbmscap.c (code details in the BT) Could that be fixed? Cheers, Maciek -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Mon Jul 10 11:17:27 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Mon Jul 10 11:17:29 2006 Subject: [GRASS-dev] [bug #4523] (grass) missing db help pages Message-ID: <20060710091727.712011005DE@lists.intevation.de> Markus wrote: > The concept is to only install docs where drivers are > available. A related note is given in the parent help > page. Is that concept OK? Why shouldn't the user be able to learn about Grass-mysql or Grass-sqlite interaction not having built Grass --with either of them? Usually first we try to learn about the very basics and caveats befer going for something - just to make sure it is worth trying at all. Besides, dead links in manual are not desired. Maciek -------------------------------------------- Managed by Request Tracker From hamish_nospam at yahoo.com Mon Jul 10 11:23:57 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jul 10 11:24:02 2006 Subject: [GRASS-dev] Re: [bug #4524] (grass) v.clean, v.patch (else?): In-Reply-To: <20060710090813.3bbbe8df@sorbus> References: <20060710064430.BE7B1100160@lists.intevation.de> <20060710090813.3bbbe8df@sorbus> Message-ID: <20060710212357.14241762.hamish_nospam@yahoo.com> Maciej Sieczka wrote: .. > > > The above 6 lines should all go to /dev/null, too. v.clean is even > > > worse - *not a single line* is redirected to /dev/null, so each > > > v.clean run results in about 40 lines printed to the terminal. > > > > GRASS sends general messages to stderr and parsable output to > > stdout. .. > What for? >/dev/null should result in filtering out all standard > information. Only information in case of unexpected module behaviour > should be let through. This will make user's scripts output cleaner. > The above info is usefull for a single v.patch run, to give guiding to > the user on how to proceed. But when v.patch is called from a script > it is script's author responsibility to be aware of such caveats and > use v.patch properly. IOW, when v.patch is called from a script the > standard message above is not improving anything but decreases the > output clarity. > > Same for v.clean or any other module. fyi, v.clean and any module that builds topology with Vect_build() sends as its second argument the destination of messages. for v.clean this is: Vect_build (pErr, stderr); distribution is as follows: $ cd vector/ $ grep -rI Vect_build * | grep stdout | wc -l 31 $ grep -rI Vect_build * | grep stderr | wc -l 41 clearly not standardized; this should be fixed to either one or the other for most modules. It is indeed arguable (as you suggest) that modules which will not produce parsable output should have status messages sent to stdout. IMO this would lead to a mess- GUIs, etc, couldn't redirect std* en masse and presume that all modules will work as expected. Scripts would have to be crafted for each module's needs individually. The correct solution IMO is to relegate overly verbose messages to G_debug(1,) or a -v verbose flag, and continue to send warnings and errors to stderr. > > Patch complete. 2 files patched. in effect G_done_msg(). > > Intersections at borders will have to be snapped. > > Lines common between files will have to be edited. > > The header information also may have to be edited. These 3 are somewhere between needing Warnings and boldface type in the help page. (hence G_message()) The question might be reduced to "where to send G_message()?" ? Hamish From ychemin at gmail.com Mon Jul 10 12:12:39 2006 From: ychemin at gmail.com (Yann Chemin) Date: Mon Jul 10 12:12:41 2006 Subject: [GRASS-dev] r.in.gdal to group automatically imported multi-bands image In-Reply-To: <20060710190008.45e80c30.hamish_nospam@yahoo.com> References: <6278879c0607082248n65b81c0anb88895e0bafbd045@mail.gmail.com> <20060710190008.45e80c30.hamish_nospam@yahoo.com> Message-ID: <6278879c0607100312u53bd5328sc62c55410497c24e@mail.gmail.com> Could it be possible to automatically get the list of images from the group and take the 3 first bands as RGB, get these into a d.rgb string and attach that to a display button inside each group by default, or something similar...? I do know really, just trying to get some improvement on the usability feeling for image processing in GRASS GIS... thanks yann On 10/07/06, Hamish wrote: > Yann Chemin wrote: > > > When dealing with multi-band satellite data, it is generally easier to > > group them, and generally we import this data from, say a GeoTiff that > > is already a multi-band. > > > > Could we consider trying to make a group directly on import in > > r.in.gdal by the name of the image? Imagine people that deal with > > temporal/hyperspectral data, it could be beneficial. > > I was under the impression that r.in.gdal DID do this already (GRASS 6.1 > anyway). e.g. r.in.onearth (r.in.wms) creates the group. > > > > Following this idea, 2 things: > > 1-GIS.M to load groups directly (i am not familiar to know if this is > > already there) > > 2-Attach a default group display command to choose from greyscale or > > RGB > > > > I believe this could help some "image processing" people to use GRASS. > > > d.rgb group=groupname > > could work if the was a consistant naming for bands, and the extension > could be predicted. > > scan.r > scan.b > scan.c > > but "r.in.onearth -l tmband=visual" creates: > satimage.1 > satimage.2 > satimage.3 > > for r,g,b? > > > Hamish > From grass-bugs at intevation.de Mon Jul 10 13:01:25 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Mon Jul 10 13:01:26 2006 Subject: [GRASS-dev] [bug #4527] (grass) db.copy: segfault when to_table already exists Message-ID: <20060710110125.61408100160@lists.intevation.de> The bug still bites (CVS today). Maciek -------------------------------------------- Managed by Request Tracker From landa.martin at gmail.com Mon Jul 10 13:50:40 2006 From: landa.martin at gmail.com (Martin Landa) Date: Mon Jul 10 13:50:52 2006 Subject: [GRASS-dev] [bug #4527] (grass) db.copy: segfault when to_table already exists In-Reply-To: <20060710110125.61408100160@lists.intevation.de> References: <20060710110125.61408100160@lists.intevation.de> Message-ID: Hi, I hope the attached patch will fix it... Best, Martin 2006/7/10, Maciek Sieczka via RT : > The bug still bites (CVS today). > > Maciek > > > -------------------------------------------- Managed by Request Tracker > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: copy_tab.diff.gz Type: application/x-gzip Size: 755 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060710/008850f4/copy_tab.diff.gz From grass-bugs at intevation.de Mon Jul 10 14:22:24 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Mon Jul 10 14:22:26 2006 Subject: [GRASS-dev] [bug #4605] (grass) v.patch: 'Cannot open old vector ... on level 2' Message-ID: <20060710122224.62B271005B8@lists.intevation.de> guest wrote (Fri, Jul 7 2006 17:01:34): > Hi, > > I think that I have applied it. Can you confirm? It is not fixed I'm affraid. Today's CVS: $ g.list vect ---------------------------------------------- vector files available in mapset srtm_bil: first second $ v.digit first& $ v.patch in=first,second out=third ERROR: Cannot open old vector first@srtm_bil on level 2 ^^^ Should be sth like: "Cannot open existing vector on level 2" As you suggested in your previous message. Maciek -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Mon Jul 10 15:32:09 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Mon Jul 10 15:32:11 2006 Subject: [GRASS-dev] [bug #4807] (grass) r.in.xyz: Message-ID: <20060710133209.A3285100160@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4807 ------------------------------------------------------------------------- Subject: r.in.xyz: Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: Grass 6.1cvs compiled 2006-07-10 Here's the error I get when processing input xyz data: r.in.xyz input=Creed_2006030_1 output=Creed_2006030_2 fs=space Scanning data ... *** glibc detected *** double free or corruption (fasttop): 0x0804d298 *** Aborted This error comes and goes...I can't seem to pinpoint what is causing it to occur. The input xyz file is only 116MB. There's nothing remarkable about the data itself, just 3 columns of space-delimited data. ~ Eric. -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Mon Jul 10 15:39:31 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Mon Jul 10 15:39:32 2006 Subject: [GRASS-dev] [bug #4808] (grass) r.out.arc: TCL/TK GUI has a 'Select item' button for output Message-ID: <20060710133931.CAE711005B8@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4808 ------------------------------------------------------------------------- Subject: r.out.arc: TCL/TK GUI has a 'Select item' button for output Platform: GNU/Linux/x86 grass obtained from: CVS grass binary for platform: Compiled from Sources GRASS Version: 2006-07-10 There should be no 'Select item' button for output. Maciek -------------------------------------------- Managed by Request Tracker From hamish_nospam at yahoo.com Mon Jul 10 15:53:07 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jul 10 15:53:15 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: <20060703164112.GN19781@bartok.itc.it> References: <20060703164112.GN19781@bartok.itc.it> Message-ID: <20060711015307.2d08ab79.hamish_nospam@yahoo.com> Hi, I have worked on the 6.1.0 announcement some: http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/web/announces/announce_grass610.html?rev=HEAD please review. the opening text still needs a bit of cleanup as does the blurb (see below). Markus wrote: > An announcement is drafted at > http://grass.itc.it/announces/announce_grass610.html > The list of changes should be almost up to date, please > review and add missing items. Also the wording of the > first part could be more press release like. "The GRASS Development Team announces:" idea: release as a joint press release with OSGeo ? me: >"A feature release" >I have no idea what this means vs. a "new release". 5.7.0 was a >"development preview release" -- do you think that is too scary? Markus: > Maybe too scary? changed to: "A new release of GRASS GIS has been published today. This is a feature release in preparation for the next benchmark release, which will be GRASS 6.2." I am still not sure what it means, but it conveys some sort of plan. MN: > sites removed. keep as "point data"? Non-GIS readers will wonder what "raster and vector" means. They'll understand what "point data" (or similar) means, and will be looking specifically for that functionality. shrug me: > >* we should update roadmap.html before final 6.1.0 release. MN: > Sounds good... but we would need to follow that roadmap then which > rarely happened in the past. :) ? devel/roadmap.php seems pretty accurate to me feature-wise. ?: v.edit: removed from announcement as not in Makefile. Still alpha/beta? GEM: do mention it, but label as [beta]? beginnings of a blurb: ====================================================================== GRASS GIS releases version 6.1.0 [date] This new release includes hundreds of new features and support for the latest GIS data formats. The Geographic Resources Analysis Support System (GRASS GIS), is a Geographic Information System (GIS) used for spatial modeling, visualization of both raster and vector data, geospatial data management and analysis, processing of satellite and aerial imagery, and production of presentation graphics and hardcopy maps. GRASS combines powerful raster, vector, and geospatial processing engines into a single integrated software package. The GRASS GIS project is developed under the terms of the GNU General Public License (the GPL) in the open by volunteers the world over. GRASS differs from many other GIS software packages used in the professional world in that it is developed and distributed by users for users; mostly on a volunteer basis, in the open, and is given away for free. Emphasis is placed on interoperability and unlimited access to data as well as software flexibility and evolution rate (both added features and bug minimization). GRASS is currently used in academic and commercial settings around the world, as well as by many governmental agencies and environmental consulting companies. ====================================================================== Hamish ps - I will head into the field in a few hours, and aside from a few busy days in the office next week, I will either be back in the field or travelling for the next six weeks. Don't expect any quick responses from the snow-bound fjords! From soerengebbert at gmx.de Mon Jul 10 16:52:48 2006 From: soerengebbert at gmx.de (Soeren Gebbert) Date: Mon Jul 10 16:52:51 2006 Subject: [GRASS-dev] New raster-to-raster3d conversion module In-Reply-To: <20060710125327.56049a3b.hamish_nospam@yahoo.com> References: <200607090015.25361.soerengebbert@gmx.de> <20060710125327.56049a3b.hamish_nospam@yahoo.com> Message-ID: <200607101652.48494.soerengebbert@gmx.de> Dear Hamish, On Monday 10 July 2006 02:53, Hamish wrote: > Soeren Gebbert wrote: > > i would like to add a new raster-to-raster3d conversion module > > to the grass6.1 CVS in the near future. > > > > The module is called r.elev.to.rast3. > > It creates a new 3D raster map from a 2D elevation and a > > 2D "value" raster map. The principal functioning is shown here: > > http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r.elev.to.rast3.png > > Congratulations on the new module! Many thanks! > > > I would like to ask if i can commit this module next week, or if i > > have to wait until GRASS 6.1.0 is released? > > I have tested this module with different datasets and it seems to work > > properly. And i will add some tests to the grass test-suite. > > > If the new module is ready to be in CVS, but you are not sure if it is > release-ready, you can always put it in CVS but not add it to the > Makefile or GUI menus. (as long as the change doesn't touch other parts > of the software) Ok, i will submit it after some more testing, but will not add it to the Makefile/GUI. > > > I think together with r.to.rast3 > > http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r.to.rast3.png > > r3.to.rast > > http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r3.to.rast.png > > and r3.cross.rast > > http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r3.cross.rast.png > > the raster<->rast3d modelling/conversion capabilities are mostly > > complete. > > > Small versions of those pics would be a great addition to the help > pages, see r.terraflow, v.voronoi for examples. Thats a great idea, i will do this. Best regards Soeren > > > Hamish > > From benjamin.ducke at ufg.uni-kiel.de Mon Jul 10 17:07:54 2006 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Mon Jul 10 17:08:41 2006 Subject: [GRASS-dev] New raster-to-raster3d conversion module In-Reply-To: <200607101652.48494.soerengebbert@gmx.de> References: <200607090015.25361.soerengebbert@gmx.de> <20060710125327.56049a3b.hamish_nospam@yahoo.com> <200607101652.48494.soerengebbert@gmx.de> Message-ID: <44B26D4A.7060104@ufg.uni-kiel.de> Soeren, that sounds cool. However, I am to dumb to understand just exactly what the module does from the screenshot you provided. Could you elaborate? 3D functionality in GRASS is really getting somewhere. The only things I could wish for: 1. Make volume vizualization work in NVIZ 2. Module to convert 3D Polygon -> 3D raster map 3. Module to query 3d raster value using 3D vector points/coordinates 4. Categorization and information like r.report provides Maybe for GRASS 6.2? Thanks, Benjamin. Soeren Gebbert wrote: > Dear Hamish, > > On Monday 10 July 2006 02:53, Hamish wrote: > >>Soeren Gebbert wrote: >> >>>i would like to add a new raster-to-raster3d conversion module >>>to the grass6.1 CVS in the near future. >>> >>>The module is called r.elev.to.rast3. >>>It creates a new 3D raster map from a 2D elevation and a >>>2D "value" raster map. The principal functioning is shown here: >>>http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r.elev.to.rast3.png >> >>Congratulations on the new module! > > > Many thanks! > > >>>I would like to ask if i can commit this module next week, or if i >>>have to wait until GRASS 6.1.0 is released? >>>I have tested this module with different datasets and it seems to work >>>properly. And i will add some tests to the grass test-suite. >> >> >>If the new module is ready to be in CVS, but you are not sure if it is >>release-ready, you can always put it in CVS but not add it to the >>Makefile or GUI menus. (as long as the change doesn't touch other parts >>of the software) > > > Ok, i will submit it after some more testing, but will not add it to the Makefile/GUI. > > >>>I think together with r.to.rast3 >>>http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r.to.rast3.png >>>r3.to.rast >>>http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r3.to.rast.png >>>and r3.cross.rast >>>http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r3.cross.rast.png >>>the raster<->rast3d modelling/conversion capabilities are mostly >>>complete. >> >> >>Small versions of those pics would be a great addition to the help >>pages, see r.terraflow, v.voronoi for examples. > > > Thats a great idea, i will do this. > > Best regards > Soeren > > >> >>Hamish >> >> > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From wegmann at biozentrum.uni-wuerzburg.de Mon Jul 10 17:35:25 2006 From: wegmann at biozentrum.uni-wuerzburg.de (Martin Wegmann) Date: Mon Jul 10 17:35:29 2006 Subject: [GRASS-dev] v.to.rast results in nan Message-ID: <200607101735.25955.wegmann@biozentrum.uni-wuerzburg.de> hello, I get a very strange behaviour which might be a bug or feature: When I want to covert vector to raster I tried two ways: Open vector -- zoom in -- apply v.to.rast col=AREA -- r.info gives nan values g.region vect=name -- apply v.to.rast col=AREA -- r.info gives correct values I assumed that zooming in/showing the correct extend in the monitor changed the region settings automatically. It might be a feature but not a very intuitive one. using cvs from last friday. regards, Martin From rez at touchofmadness.com Mon Jul 10 19:09:36 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Mon Jul 10 19:09:56 2006 Subject: [GRASS-dev] v.to.rast results in nan In-Reply-To: <200607101735.25955.wegmann@biozentrum.uni-wuerzburg.de> References: <200607101735.25955.wegmann@biozentrum.uni-wuerzburg.de> Message-ID: <1152551376.20411.130.camel@devel> On Mon, 2006-07-10 at 17:35 +0200, Martin Wegmann wrote: > hello, > > I get a very strange behaviour which might be a bug or feature: > > When I want to covert vector to raster I tried two ways: > > Open vector -- zoom in -- apply v.to.rast col=AREA -- r.info gives nan values > > g.region vect=name -- apply v.to.rast col=AREA -- r.info gives correct values > > I assumed that zooming in/showing the correct extend in the monitor changed > the region settings automatically. It might be a feature but not a very > intuitive one. Thank you for the report. We're seeing a lot of region related errors of late. This is also the case with the v.drape bug (#4606) reported on Saturday. In the case of v.drape, the error is an invalid row fetch, but it doesn't make sense. The vector is entirely within the raster region, except the western edge. To the devel list: Using 'g.region vect=name' seems to remedy the problem in all cases encountered so far. Two questions: - What happened before Friday that yields this bizarre behavior? I don't see anything overtly obvious in my log since June 26 (no major related changes in lib/*). - In light of that, is this something more long-standing that people just happen to be testing or can someone put a firm date on the change? -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From benjamin.ducke at ufg.uni-kiel.de Mon Jul 10 19:25:19 2006 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Mon Jul 10 19:26:05 2006 Subject: [GRASS-dev] GRASS 6.1.0 release preparation In-Reply-To: <20060711015307.2d08ab79.hamish_nospam@yahoo.com> References: <20060703164112.GN19781@bartok.itc.it> <20060711015307.2d08ab79.hamish_nospam@yahoo.com> Message-ID: <44B28D7F.9030102@ufg.uni-kiel.de> > > > ?: > v.edit: removed from announcement as not in Makefile. Still alpha/beta? > GEM: do mention it, but label as [beta]? > > I have just updated GEM to version 1.0 on my webpage as well as in the CVS. I have adjusted the GRASS Makefile and tools/build_html_index.sh so that GEM, its documentation and example files get installed into the right locations. You can now access extensive GEM documentation from "$GISBASE/docs/html/index.html". The executable gem gets installed in $BINDIR, just like the grass61 startup script. Now, if a user manages to install GRASS, he will also have access to GEM. All obvious remaining bugs have been fixed, including registration of HTML man pages for extension modules. It works like a charm for me now and has worked quite OK for a number of months. I am using Linux exclusively. I have reports from Michael that things are not so good for Mac OS X, but I think the issues are related to the extension packages themselves, not to GEM. The last time I checked, everything worked fine on cygwin as well, although only if you specify the --verbose option. No idea about native Win32+QGIS (yet). I think it is not necessary to label GEM beta anymore -- at least not on Linux ... Best, Benjamin -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From grass-bugs at intevation.de Mon Jul 10 19:54:50 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Mon Jul 10 19:54:52 2006 Subject: [GRASS-dev] [bug #4811] (grass) r.param.scale Segmentation fault Message-ID: <20060710175450.B378C1005C4@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4811 ------------------------------------------------------------------------- Subject: r.param.scale Segmentation fault Platform: GNU/Linux/x86 grass obtained from: CVS grass binary for platform: Compiled from Sources GRASS Version: latest CVS Hi, while running the test suite, i found a segfault in r.param.scale: Mapset in Location GRASS 6.1.cvs > gdb r.param.scale GNU gdb 6.4.90-debian This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) r in=elevation out=test --o Starting program: /usr/local/grass-6.1.cvs/bin/r.param.scale in=elevation out=test --o 2% Program received signal SIGSEGV, Segmentation fault. 0x0804b9f4 in process () at process.c:204 204 G_debug(1, "FEATURE: %i", featrow_out[9]); (gdb) bt #0 0x0804b9f4 in process () at process.c:204 #1 0x0804aa85 in main (argc=134547152, argv=0x80506d0) at main.c:46 (gdb) Maybe related to the latest CVS changes -> DEBUG Macro to G_debug? Best regards Soeren -------------------------------------------- Managed by Request Tracker From soerengebbert at gmx.de Tue Jul 11 00:52:40 2006 From: soerengebbert at gmx.de (Soeren Gebbert) Date: Tue Jul 11 00:52:42 2006 Subject: [GRASS-dev] New raster-to-raster3d conversion module In-Reply-To: <44B26D4A.7060104@ufg.uni-kiel.de> References: <200607090015.25361.soerengebbert@gmx.de> <200607101652.48494.soerengebbert@gmx.de> <44B26D4A.7060104@ufg.uni-kiel.de> Message-ID: <200607110052.40706.soerengebbert@gmx.de> Dear Benjamin and devs, On Monday 10 July 2006 17:07, Benjamin Ducke wrote: > Soeren, > > that sounds cool. > However, I am to dumb to understand just exactly what the module > does from the screenshot you provided. > Could you elaborate? I will try, but my "d"english is horrible. With r.elev.to.rast3 you can put raster map values from a specific map (input) in a specific elevation layer within a g3d volume, based on a 2D elevation map (elev). Every 3D cell of the volume that intersect with the elevation map will be set to the cell value of the input map. If the hight value of the elevation map is exactly located at the border between two 3D cells, both cells will get the input map value. This works perfectly for putting geological strata into g3d volumes. I need this for modelling a 3D aquifer. The screenshot http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r.elev.to.rast3.png shows 3 options how to put raster map values into a g3d map. Here are the options of r.elev.to.rast3: Description: Creates a 3D volume map based on a 2D elevation and value raster map Usage: r.elev.to.rast3 [-ul] input=string elev=string output=string [upper=value] [lower=value] [--overwrite] Flags: -u Use the input map values to fill the upper cells -l Use the input map values to fill the lower cells --o Force overwrite of output files Parameters: input 2d raster maps which represent the values elev 2d raster maps which represent the elevation output output 3dcell map upper The value to fill the upper cells, default is null lower The value to fill the lower cells, default is null In the upper volume of the screenshot the 3D elevation layer based on the grey cutplane on the left was filled with the data from the (colored) 2D input map. Also all the 3D cells above the elevation layer are filled with the values from the input map. In the middle volume only the elevation layer was filled with the input map values, upper and lower 3D cells are not filled (null). In the lower volume the elevation layer and all 3D cells lower than the elevation layer are filled with the input map values. > 3D functionality in GRASS is really getting somewhere. > The only things I could wish for: > > 1. Make volume vizualization work in NVIZ Well, it works for isosurfaces and cutplanes. But i dont know how to implement real volume rendering. (have no clue of OpenGL) For this reason i implemented the r/r3/v.out.vtk export modules to visualize all the grass data with VTK based programs like Paraview or MayaVi. And VTK provides much more visualisation capabilities you can imagine. We will never have the manpower to implement this into nviz. btw.: VTK provides Python bindings. Thus with grass swig/Python support and the VTK Python bindings, direct data interaction/visualisation can be implemented. Hm, maybe i should learn Python .... . > 2. Module to convert 3D Polygon -> 3D raster map You will need something like a volume rasterizer to do this. That is not easy to implement. And the hardest thing of 3D polygons with more than 4 vertices is, that the polygon surface is not well defined. You will need additonal points for triangulation. Otherwise you dont get the surface you expect. Only triangles or quadrangles are well suited for rasterisation. But r.elev.to.rast3 provides limited potentialities for this. You can convert lines, boundaries or areas into raster maps and put them with r.to.rast3 or r.elev.to.rast3, into a g3d volume. > 3. Module to query 3d raster value using 3D vector points/coordinates You can do this with Paraview. VTK will give you the options to combine/intersect pointdata, polydata or unstructured grid data with any kind of volume data. Paraview will give you the data on specific points or a specific path within the volume. You can use threshold filter, grid filter, cutplanes and much more to discover your 3D data. > 4. Categorization and information like r.report provides I was thinking today about a module like r.stats -> r3.stats. But i'm just thinking about it. ;) > > Maybe for GRASS 6.2? You are welcome to help implementing this. :) Best regards Soeren btw.: r.elev.to.rast3 is in CVS now. But it will not build by default, the entry in the Makefile is "missing". A new grass test suite with r.elev.to.rast3 tests is available (version 0.2.0.9): http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/GRASS_Testsuite-0.2.0.9.tar.bz2 > > Thanks, > > Benjamin. > > Soeren Gebbert wrote: > > Dear Hamish, > > > > On Monday 10 July 2006 02:53, Hamish wrote: > > > >>Soeren Gebbert wrote: > >> > >>>i would like to add a new raster-to-raster3d conversion module > >>>to the grass6.1 CVS in the near future. > >>> > >>>The module is called r.elev.to.rast3. > >>>It creates a new 3D raster map from a 2D elevation and a > >>>2D "value" raster map. The principal functioning is shown here: > >>>http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r.elev.to.rast3.png > >> > >>Congratulations on the new module! > > > > > > Many thanks! > > > > > >>>I would like to ask if i can commit this module next week, or if i > >>>have to wait until GRASS 6.1.0 is released? > >>>I have tested this module with different datasets and it seems to work > >>>properly. And i will add some tests to the grass test-suite. > >> > >> > >>If the new module is ready to be in CVS, but you are not sure if it is > >>release-ready, you can always put it in CVS but not add it to the > >>Makefile or GUI menus. (as long as the change doesn't touch other parts > >>of the software) > > > > > > Ok, i will submit it after some more testing, but will not add it to the Makefile/GUI. > > > > > >>>I think together with r.to.rast3 > >>>http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r.to.rast3.png > >>>r3.to.rast > >>>http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r3.to.rast.png > >>>and r3.cross.rast > >>>http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r3.cross.rast.png > >>>the raster<->rast3d modelling/conversion capabilities are mostly > >>>complete. > >> > >> > >>Small versions of those pics would be a great addition to the help > >>pages, see r.terraflow, v.voronoi for examples. > > > > > > Thats a great idea, i will do this. > > > > Best regards > > Soeren > > > > > >> > >>Hamish > >> > >> > > > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev > > > > > From soerengebbert at gmx.de Tue Jul 11 00:52:40 2006 From: soerengebbert at gmx.de (Soeren Gebbert) Date: Tue Jul 11 00:52:51 2006 Subject: [GRASS-dev] New raster-to-raster3d conversion module In-Reply-To: <44B26D4A.7060104@ufg.uni-kiel.de> References: <200607090015.25361.soerengebbert@gmx.de> <200607101652.48494.soerengebbert@gmx.de> <44B26D4A.7060104@ufg.uni-kiel.de> Message-ID: <200607110052.40706.soerengebbert@gmx.de> Dear Benjamin and devs, On Monday 10 July 2006 17:07, Benjamin Ducke wrote: > Soeren, > > that sounds cool. > However, I am to dumb to understand just exactly what the module > does from the screenshot you provided. > Could you elaborate? I will try, but my "d"english is horrible. With r.elev.to.rast3 you can put raster map values from a specific map (input) in a specific elevation layer within a g3d volume, based on a 2D elevation map (elev). Every 3D cell of the volume that intersect with the elevation map will be set to the cell value of the input map. If the hight value of the elevation map is exactly located at the border between two 3D cells, both cells will get the input map value. This works perfectly for putting geological strata into g3d volumes. I need this for modelling a 3D aquifer. The screenshot http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r.elev.to.rast3.png shows 3 options how to put raster map values into a g3d map. Here are the options of r.elev.to.rast3: Description: Creates a 3D volume map based on a 2D elevation and value raster map Usage: r.elev.to.rast3 [-ul] input=string elev=string output=string [upper=value] [lower=value] [--overwrite] Flags: -u Use the input map values to fill the upper cells -l Use the input map values to fill the lower cells --o Force overwrite of output files Parameters: input 2d raster maps which represent the values elev 2d raster maps which represent the elevation output output 3dcell map upper The value to fill the upper cells, default is null lower The value to fill the lower cells, default is null In the upper volume of the screenshot the 3D elevation layer based on the grey cutplane on the left was filled with the data from the (colored) 2D input map. Also all the 3D cells above the elevation layer are filled with the values from the input map. In the middle volume only the elevation layer was filled with the input map values, upper and lower 3D cells are not filled (null). In the lower volume the elevation layer and all 3D cells lower than the elevation layer are filled with the input map values. > 3D functionality in GRASS is really getting somewhere. > The only things I could wish for: > > 1. Make volume vizualization work in NVIZ Well, it works for isosurfaces and cutplanes. But i dont know how to implement real volume rendering. (have no clue of OpenGL) For this reason i implemented the r/r3/v.out.vtk export modules to visualize all the grass data with VTK based programs like Paraview or MayaVi. And VTK provides much more visualisation capabilities you can imagine. We will never have the manpower to implement this into nviz. btw.: VTK provides Python bindings. Thus with grass swig/Python support and the VTK Python bindings, direct data interaction/visualisation can be implemented. Hm, maybe i should learn Python .... . > 2. Module to convert 3D Polygon -> 3D raster map You will need something like a volume rasterizer to do this. That is not easy to implement. And the hardest thing of 3D polygons with more than 4 vertices is, that the polygon surface is not well defined. You will need additonal points for triangulation. Otherwise you dont get the surface you expect. Only triangles or quadrangles are well suited for rasterisation. But r.elev.to.rast3 provides limited potentialities for this. You can convert lines, boundaries or areas into raster maps and put them with r.to.rast3 or r.elev.to.rast3, into a g3d volume. > 3. Module to query 3d raster value using 3D vector points/coordinates You can do this with Paraview. VTK will give you the options to combine/intersect pointdata, polydata or unstructured grid data with any kind of volume data. Paraview will give you the data on specific points or a specific path within the volume. You can use threshold filter, grid filter, cutplanes and much more to discover your 3D data. > 4. Categorization and information like r.report provides I was thinking today about a module like r.stats -> r3.stats. But i'm just thinking about it. ;) > > Maybe for GRASS 6.2? You are welcome to help implementing this. :) Best regards Soeren btw.: r.elev.to.rast3 is in CVS now. But it will not build by default, the entry in the Makefile is "missing". A new grass test suite with r.elev.to.rast3 tests is available (version 0.2.0.9): http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/GRASS_Testsuite-0.2.0.9.tar.bz2 > > Thanks, > > Benjamin. > > Soeren Gebbert wrote: > > Dear Hamish, > > > > On Monday 10 July 2006 02:53, Hamish wrote: > > > >>Soeren Gebbert wrote: > >> > >>>i would like to add a new raster-to-raster3d conversion module > >>>to the grass6.1 CVS in the near future. > >>> > >>>The module is called r.elev.to.rast3. > >>>It creates a new 3D raster map from a 2D elevation and a > >>>2D "value" raster map. The principal functioning is shown here: > >>>http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r.elev.to.rast3.png > >> > >>Congratulations on the new module! > > > > > > Many thanks! > > > > > >>>I would like to ask if i can commit this module next week, or if i > >>>have to wait until GRASS 6.1.0 is released? > >>>I have tested this module with different datasets and it seems to work > >>>properly. And i will add some tests to the grass test-suite. > >> > >> > >>If the new module is ready to be in CVS, but you are not sure if it is > >>release-ready, you can always put it in CVS but not add it to the > >>Makefile or GUI menus. (as long as the change doesn't touch other parts > >>of the software) > > > > > > Ok, i will submit it after some more testing, but will not add it to the Makefile/GUI. > > > > > >>>I think together with r.to.rast3 > >>>http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r.to.rast3.png > >>>r3.to.rast > >>>http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r3.to.rast.png > >>>and r3.cross.rast > >>>http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r3.cross.rast.png > >>>the raster<->rast3d modelling/conversion capabilities are mostly > >>>complete. > >> > >> > >>Small versions of those pics would be a great addition to the help > >>pages, see r.terraflow, v.voronoi for examples. > > > > > > Thats a great idea, i will do this. > > > > Best regards > > Soeren > > > > > >> > >>Hamish > >> > >> > > > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev > > > > > From florian.kindl at uibk.ac.at Tue Jul 11 18:31:00 2006 From: florian.kindl at uibk.ac.at (Florian Kindl) Date: Tue Jul 11 18:30:05 2006 Subject: [GRASS-dev] search function in programmer's manual? Message-ID: <2D901E4B-E51E-4575-9722-99EFFC9491E8@uibk.ac.at> Hello list, hello Markus! is there some kind of possibility to search through the contents of http://mpa.itc.it/markus/grass61progman/ This could come in handy when looking for the definition of a certain function without knowing in which library it is defined... thanks, Florian From mlennert at club.worldonline.be Wed Jul 12 10:29:08 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Jul 12 10:29:03 2006 Subject: [GRASS-dev] search function in programmer's manual? In-Reply-To: <2D901E4B-E51E-4575-9722-99EFFC9491E8@uibk.ac.at> References: <2D901E4B-E51E-4575-9722-99EFFC9491E8@uibk.ac.at> Message-ID: <44B4B2D4.6020606@club.worldonline.be> Florian Kindl wrote: > Hello list, hello Markus! > > is there some kind of possibility to search through the contents of > http://mpa.itc.it/markus/grass61progman/ > > This could come in handy when looking for the definition of a certain > function without knowing in which library it is defined... In google: site:mpa.itc.it/markus/grass61progman/ G_message ? Moritz From grass-bugs at intevation.de Wed Jul 12 10:33:45 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Wed Jul 12 10:33:46 2006 Subject: [GRASS-dev] [bug #4524] (grass) v.clean, v.patch (else?): output to stderr instead of stdout... Message-ID: <20060712083345.54E541006A5@lists.intevation.de> Hamish wrote (Mon, Jul 10 2006 11:24:12): > The correct solution IMO is to relegate overly verbose messages to > G_debug(1,) or a -v verbose flag, and continue to send warnings and > errors to stderr. > > > > Patch complete. 2 files patched. > > in effect G_done_msg(). > > > > Intersections at borders will have to be snapped. > > > Lines common between files will have to be edited. > > > The header information also may have to be edited. > > These 3 are somewhere between needing Warnings and boldface type in the > help page. (hence G_message()) > > > The question might be reduced to "where to send G_message()?" ? Anywhere but stdout, I think. Example reason: I don't want somebody using my v.flip (a script that calls v.patch, among the others) to be confused with v.patch information that: # Intersections at borders will have to be snapped. # Lines common between files will have to be edited. # The header information also may have to be edited. Because I have taken care of this for the user, knowing what the input for v.patch is and using 'v.clean tool=snap' as needed. That information above is simply wrong and confusing the user, when v.patch is a script component. Maciek -------------------------------------------- Managed by Request Tracker From Florian.Kindl at uibk.ac.at Wed Jul 12 11:25:02 2006 From: Florian.Kindl at uibk.ac.at (Florian Kindl) Date: Wed Jul 12 11:25:11 2006 Subject: [GRASS-dev] search function in programmer's manual? - solved In-Reply-To: <44B4B2D4.6020606@club.worldonline.be> References: <2D901E4B-E51E-4575-9722-99EFFC9491E8@uibk.ac.at> <44B4B2D4.6020606@club.worldonline.be> Message-ID: On Wed, 12 Jul 2006, Moritz Lennert wrote: >> >> is there some kind of possibility to search through the contents of >> http://mpa.itc.it/markus/grass61progman/ >> > In google: > site:mpa.itc.it/markus/grass61progman/ G_message > > ? > Well o well, how true that is... Must have ignored that possibility as I try not to depend on Google everywhere in my digital life... Thanks for the tip,though! \Flo. From Florian.Kindl at uibk.ac.at Wed Jul 12 12:42:21 2006 From: Florian.Kindl at uibk.ac.at (Florian Kindl) Date: Wed Jul 12 12:41:23 2006 Subject: [GRASS-dev] again: add attributes to new vector / create new vector (Vlib) Message-ID: <275B457A-5FD1-4350-A5C2-7E1721721434@uibk.ac.at> Hello list! I am still working on a new vector module for GRASS GIS. It reads an existing vector set (stream network), calculates the strahler order for the lines and writes a new vector set. I encountered two problems, though: 1) The output set should contain the attributes of the input set plus 2 new attributes which are calculated by my module. How do I append these new attribute columns to my output data? I can successfully write a new table if the old vector had none but i fail to copy existing attributes AND add my calculated columns. How would I accomplish that? 2) Even if the table is written, the output vector is not properly closed. I use Vect_close(&Out); and get the following errors: === WARNING: Could not stat file '/vbg_m28/c716322/vector/xxxx/coor' WARNING: Can't open topo file for write: /vbg_m28/c716322/vector/xxxx/ topo WARNING: Can't open cidx file for write: /vbg_m28/c716322/vector/xxxx/ cidx WARNING: Could not stat file '/vbg_m28/c716322/vector/xxxx/coor' mkdir: cannot create directory `/vbg_m28/c716322/vector': No such file or directory ERROR: can't make mapset element vector/xxxx (/vbg_m28/c716322/vector) === A vector set 'xxxx' is actually created but v.info xxxx yields ERROR: Cannot open old vector xxxx@c716322 on level 2 Any ideas how to solve my problems? Thanks for your help, Flo. -- Florian Kindl Institute of Geography University of Innsbruck _______________________________________________ grass-dev mailing list grass-dev@grass.itc.it http://grass.itc.it/mailman/listinfo/grass-dev From epatton at nrcan.gc.ca Wed Jul 12 14:22:29 2006 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Wed Jul 12 14:22:35 2006 Subject: [GRASS-dev] again: add attributes to new vector / create new vector(Vlib) Message-ID: <0E5A77B55A57D511BB3F0002A537C2620641120A@s5-dar-r1.nrn.nrcan.gc.ca> To add new columns to your database, try v.db.addcol: http://grass.itc.it/grass61/manuals/html61_user/v.db.addcol.html ~ Eric. >-----Original Message----- >From: grass-dev-bounces@grass.itc.it >To: grass-dev@grass.itc.it >Sent: 7/12/2006 6:42 AM >Subject: [GRASS-dev] again: add attributes to new vector / create new vector(Vlib) >Hello list! >I am still working on a new vector module for GRASS GIS. >It reads an existing vector set (stream network), calculates the >strahler order for the lines and writes a new vector set. From Florian.Kindl at uibk.ac.at Wed Jul 12 17:53:42 2006 From: Florian.Kindl at uibk.ac.at (Florian Kindl) Date: Wed Jul 12 17:52:44 2006 Subject: [GRASS-dev] DBMI: status of db_add_columns() - was: add attributes to new vector (Vlib) In-Reply-To: <0E5A77B55A57D511BB3F0002A537C2620641120A@s5-dar-r1.nrn.nrcan.gc.ca> References: <0E5A77B55A57D511BB3F0002A537C2620641120A@s5-dar-r1.nrn.nrcan.gc.ca> Message-ID: <641E2B0D-09BB-4183-9B11-4D668A22E76F@uibk.ac.at> On 12.07.2006, at 14:22, Patton, Eric wrote: > To add new columns to your database, try v.db.addcol: Thanks Eric, v.db.addcol doesn't help me so much as I need to alter the table from within the module written in C. Thank you for your hint, though, it did lead me to the function db_add_columns() in the DBMI library. This function should do what I need. However, it seems to be not implemented yet, a conclusion I draw from the error message I get when I call it: dbmi: db_add_column() not implemented How is the development status of db_add_column() and what can I use instead? -Flo. From tutey at o2.pl Wed Jul 12 22:40:05 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Jul 12 22:40:11 2006 Subject: [GRASS-dev] [bug #4527] (grass) db.copy: segfault when to_table already exists In-Reply-To: References: <20060710110125.61408100160@lists.intevation.de> Message-ID: <44B55E25.5030104@o2.pl> Martin Landa napisa?(a): > Hi, > > I hope the attached patch will fix it... Nice! Will try that (propably not today/tomorrow though). Cheers, Maciek From tutey at o2.pl Thu Jul 13 00:08:27 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Thu Jul 13 00:08:31 2006 Subject: [GRASS-dev] [bug #4527] (grass) db.copy: segfault when to_table already exists In-Reply-To: <44B55E25.5030104@o2.pl> References: <20060710110125.61408100160@lists.intevation.de> <44B55E25.5030104@o2.pl> Message-ID: <44B572DB.9010907@o2.pl> Maciej Sieczka napisa?(a): > Martin Landa napisa?(a): >> Hi, >> >> I hope the attached patch will fix it... > > Nice! Will try that (propably not today/tomorrow though). OK, had some time now. The patch works against current CVS. Grass built and installed OK. db.copy doesn't segfault when trying to ovewrite an existing table and works properly when copying table under unique name. All seems fine. Tested only using DBF though. Could someone apply Martin's patch? Thanks! Maciek From grass-bugs at intevation.de Thu Jul 13 11:51:13 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Jul 13 11:51:15 2006 Subject: [GRASS-dev] [bug #4827] (grass) Building topology for vector is incredibly slow Message-ID: <20060713095113.83FB81005A5@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4827 ------------------------------------------------------------------------- Subject: Building topology for vector is incredibly slow Platform: Mac OSX grass binary for platform: Downloaded precompiled Binaries GRASS Version: 6.1.cvs_060624 Raffaele Morelli I am working with several vector files from Italy I have imported from shape files with v.in.ogr. Those data comes with ISTAT census, so they are organized in several small polygons for each town (called "sezioni"). I wanted to produce a global national vector with polygons representing towns instead small areas inside towns, so I started running a shell script with all the "v.extract -d .. .... " to dissolve boundaries from the same town. Finally I came into a national vector map after patching the regional maps previously obtained gatering towns from the same region. After this I launched a v.clean to remove duplicates,small angles and break poligons. The process runs normally but when it's time to build topology at the end of v.clean the process is incredibly slow. After 50 minutes is still running and the building areas progress is at 33%!!! is this 'normal'? I hope I exposed clearly enough to help you. Thanx anyway -------------------------------------------- Managed by Request Tracker From benjamin.ducke at ufg.uni-kiel.de Thu Jul 13 12:09:12 2006 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Thu Jul 13 12:09:57 2006 Subject: [GRASS-dev] Re: [GRASS-user] v.in.ascii error message In-Reply-To: <44B604B3.6050305@lazygranch.com> References: <1152187266.4299.265412471@webmail.messagingengine.com> <20060706184233.0546cce9.werchowyna@epf.pl> <44B5EEA6.1040308@o2.pl> <44B604B3.6050305@lazygranch.com> Message-ID: <44B61BC8.1070904@ufg.uni-kiel.de> you need to delimit records with | not lines and then have one record per line like this: W115|58|2.4 N36|27|20.9 Also, I am not sure if W115 or N36 is a correct way of specifying the coordinates? Unfortunately, v.in.ascii almost always give that error message, which is usually not to helpful. Benjamin gary wrote: > I find this error message from v.in.ascii a bit cryptic. > > grass command: > v.in.ascii input=/usr/localsrc/utm/PERMANENT/site.dat output=sites5 > format=point fs=| skip=0 x=1 y=2 z=0 cat=0 > > error message: > Maximum input row length: 24 > Maximum number of columns: 2 > Minimum number of columns: 0 > > GRASS_INFO_ERROR(15897,1): x column number > minimum last column number > GRASS_INFO_ERROR(15897,1): (incorrect field separator?) > > > > The file site. dat is one line as follows > W115 58 2.4|N36 27 20.9 > > The default separator is "pipe", so I'm sure the delimiter is fine. Any > idea what I'm doing wrong here? > > _______________________________________________ > grassuser mailing list > grassuser@grass.itc.it > http://grass.itc.it/mailman/listinfo/grassuser > > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From ychemin at gmail.com Thu Jul 13 17:32:30 2006 From: ychemin at gmail.com (Yann Chemin) Date: Thu Jul 13 17:32:32 2006 Subject: [GRASS-dev] i.atcorr Message-ID: <6278879c0607130832m2e4730c2xa812bab33e51d179@mail.gmail.com> Hello, Christo just gave the content of his old web page, it is now available for all in the WIKI under GRASS6 Add-ons / raster. The main link refers to the compiled code under CVS about 2 weeks ago. Did not test it yet. Christo Mentioned the code to work earlier in GRASS though. Yann From tutey at o2.pl Thu Jul 13 22:31:01 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Thu Jul 13 22:31:04 2006 Subject: [GRASS-dev] i.atcorr In-Reply-To: <6278879c0607130832m2e4730c2xa812bab33e51d179@mail.gmail.com> References: <6278879c0607130832m2e4730c2xa812bab33e51d179@mail.gmail.com> Message-ID: <44B6AD85.6060102@o2.pl> Yann Chemin napisa?(a): > Hello, > Christo just gave the content of his old web page, it is now available > for all in the WIKI under GRASS6 Add-ons / raster. > The main link refers to the compiled code under CVS about 2 weeks ago. > Did not test it yet. Christo Mentioned the code to work earlier in > GRASS though. Nice! Keep us updated. Thanks. Maciek From grass-bugs at intevation.de Thu Jul 13 22:35:58 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Jul 13 22:36:00 2006 Subject: [GRASS-dev] [bug #4831] (grass) Can't create new location Message-ID: <20060713203558.DDF0B1005BF@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4831 ------------------------------------------------------------------------- Subject: Can't create new location Platform: Mac OSX grass obtained from: Trento Italy site grass binary for platform: Downloaded precompiled Binaries GRASS Version: g.version I can't create a new location. After I fill in the parameters for location, database, and mapset and push esc return, nothing happens, and I can't proceed. -------------------------------------------- Managed by Request Tracker From Florian.Kindl at uibk.ac.at Fri Jul 14 11:28:05 2006 From: Florian.Kindl at uibk.ac.at (Florian Kindl) Date: Fri Jul 14 11:28:08 2006 Subject: [GRASS-dev] G_get_raster_sample(): request outside region Message-ID: Hello list! I try to obtain the cell values of a raster map at the location of certain nodes of a vector map: +++ struct Cell_head window; G_get_window(&window); ... Vect_get_node_coor( In, node, &x, &y, NULL ); z = G_get_raster_sample( fdrast, &window, NULL, x, y, 0, method ); +++ Running this code gives the following message: WARNING: [rugg_dtmgrd in c716322] - read request for row 311730 is outside region ERROR: problem reading raster cell file Are the coordinates returned by Vect_get_node_coor() a valid argument for G_get_raster_sample() ? Is my use of G_get_window() OK? Any comment is welcome, thanks, Flo. -- Florian Kindl Institute of Geography University of Innsbruck From neteler at itc.it Fri Jul 14 12:37:01 2006 From: neteler at itc.it (Markus Neteler) Date: Fri Jul 14 12:37:03 2006 Subject: [GRASS-dev] Re: [GRASS-user] v.in.ascii error message In-Reply-To: <44B61BC8.1070904@ufg.uni-kiel.de> References: <1152187266.4299.265412471@webmail.messagingengine.com> <20060706184233.0546cce9.werchowyna@epf.pl> <44B5EEA6.1040308@o2.pl> <44B604B3.6050305@lazygranch.com> <44B61BC8.1070904@ufg.uni-kiel.de> Message-ID: <20060714103701.GD1079@bartok.itc.it> On Thu, Jul 13, 2006 at 12:09:12PM +0200, Benjamin Ducke wrote: > you need to delimit records with | not lines > and then have one record per line like this: > > W115|58|2.4 > N36|27|20.9 > > Also, I am not sure if W115 or N36 is a correct > way of specifying the coordinates? I guess that it should be 115:58:2.4W|36:27:20.9N instead of W115 58 2.4|N36 27 20.9 Markus > Unfortunately, v.in.ascii almost always give that > error message, which is usually not to helpful. > > Benjamin > > gary wrote: > >I find this error message from v.in.ascii a bit cryptic. > > > >grass command: > >v.in.ascii input=/usr/localsrc/utm/PERMANENT/site.dat output=sites5 > >format=point fs=| skip=0 x=1 y=2 z=0 cat=0 > > > >error message: > >Maximum input row length: 24 > >Maximum number of columns: 2 > >Minimum number of columns: 0 > > > >GRASS_INFO_ERROR(15897,1): x column number > minimum last column number > >GRASS_INFO_ERROR(15897,1): (incorrect field separator?) > > > > > > > >The file site. dat is one line as follows > >W115 58 2.4|N36 27 20.9 > > > >The default separator is "pipe", so I'm sure the delimiter is fine. Any > >idea what I'm doing wrong here? > > > >_______________________________________________ > >grassuser mailing list > >grassuser@grass.itc.it > >http://grass.itc.it/mailman/listinfo/grassuser > > > > > > -- > Benjamin Ducke, M.A. > Arch?oinformatik > (Archaeoinformation Science) > Institut f?r Ur- und Fr?hgeschichte > (Inst. of Prehistoric and Historic Archaeology) > Christian-Albrechts-Universit?t zu Kiel > Johanna-Mestorf-Stra?e 2-6 > D 24098 Kiel > Germany > > Tel.: ++49 (0)431 880-3378 / -3379 > Fax : ++49 (0)431 880-7300 > www.uni-kiel.de/ufg > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Markus Neteler http://mpa.itc.it/markus/ ITC-irst - Centro per la Ricerca Scientifica e Tecnologica MPBA - Predictive Models for Biol. & Environ. Data Analysis Via Sommarive, 18 - 38050 Povo (Trento), Italy From neteler at itc.it Fri Jul 14 12:44:09 2006 From: neteler at itc.it (Markus Neteler) Date: Fri Jul 14 12:44:10 2006 Subject: [GRASS-dev] search function in programmer's manual? In-Reply-To: <44B4B2D4.6020606@club.worldonline.be> References: <2D901E4B-E51E-4575-9722-99EFFC9491E8@uibk.ac.at> <44B4B2D4.6020606@club.worldonline.be> Message-ID: <20060714104409.GE1079@bartok.itc.it> On Wed, Jul 12, 2006 at 10:29:08AM +0200, Moritz Lennert wrote: > Florian Kindl wrote: > >Hello list, hello Markus! > > > >is there some kind of possibility to search through the contents of > >http://mpa.itc.it/markus/grass61progman/ > > > >This could come in handy when looking for the definition of a certain > >function without knowing in which library it is defined... > > In google: > > site:mpa.itc.it/markus/grass61progman/ G_message I have added this to http://grass.itc.it/searchgrass.php Markus From hmitaso at unity.ncsu.edu Fri Jul 14 18:53:15 2006 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Fri Jul 14 18:53:33 2006 Subject: [GRASS-dev] New raster-to-raster3d conversion module In-Reply-To: <200607110052.40706.soerengebbert@gmx.de> References: <200607090015.25361.soerengebbert@gmx.de> <200607101652.48494.soerengebbert@gmx.de> <44B26D4A.7060104@ufg.uni-kiel.de> <200607110052.40706.soerengebbert@gmx.de> Message-ID: <04E1C0B2-CBA6-4161-8368-440397F70BD7@unity.ncsu.edu> I don't know whether this is important or not, but at CERL the length of command names was carefully guarded (I was not allowed s.surf.tps.cv), so I am wondering whether we should continue this tradition and keep just two dots in the name for as long as possible - maybe it is possible to find a meaningful two dots name for r.elev.to.rast3? If not - should we set some rules on how to create names for new modules and when more dots should be used? The concern then was that it will get out of control and soon we will have ever longer and messier names. Helena On Jul 10, 2006, at 6:52 PM, Soeren Gebbert wrote: > Dear Benjamin and devs, > > On Monday 10 July 2006 17:07, Benjamin Ducke wrote: >> Soeren, >> >> that sounds cool. >> However, I am to dumb to understand just exactly what the module >> does from the screenshot you provided. >> Could you elaborate? > > I will try, but my "d"english is horrible. > > With r.elev.to.rast3 you can put raster map values from a specific > map (input) > in a specific elevation layer within a g3d volume, based on a 2D > elevation map (elev). > Every 3D cell of the volume that intersect with the elevation map > will be set to the cell value of the input map. > If the hight value of the elevation map is exactly located at the > border between two 3D cells, both cells > will get the input map value. > > This works perfectly for putting geological strata into g3d > volumes. I need this for modelling > a 3D aquifer. > > The screenshot > http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/ > r.elev.to.rast3.png > shows 3 options how to put raster map values into a g3d map. > > Here are the options of r.elev.to.rast3: > > Description: > Creates a 3D volume map based on a 2D elevation and value raster map > > Usage: > r.elev.to.rast3 [-ul] input=string elev=string output=string > [upper=value] [lower=value] [--overwrite] > > Flags: > -u Use the input map values to fill the upper cells > -l Use the input map values to fill the lower cells > --o Force overwrite of output files > > Parameters: > input 2d raster maps which represent the values > elev 2d raster maps which represent the elevation > output output 3dcell map > upper The value to fill the upper cells, default is null > lower The value to fill the lower cells, default is null > > > In the upper volume of the screenshot the 3D elevation layer based > on the grey cutplane > on the left was filled with the data from the (colored) 2D input > map. Also all > the 3D cells above the elevation layer are filled with the values > from the input map. > > In the middle volume only the elevation layer was filled with the > input map values, upper > and lower 3D cells are not filled (null). > > In the lower volume the elevation layer and all 3D cells lower than > the elevation layer are filled > with the input map values. > >> 3D functionality in GRASS is really getting somewhere. >> The only things I could wish for: >> >> 1. Make volume vizualization work in NVIZ > > Well, it works for isosurfaces and cutplanes. But i dont know how > to implement real > volume rendering. (have no clue of OpenGL) > For this reason i implemented the r/r3/v.out.vtk export modules to > visualize all > the grass data with VTK based programs like Paraview or MayaVi. > And VTK provides much more visualisation capabilities you can > imagine. We will never have > the manpower to implement this into nviz. > > btw.: > VTK provides Python bindings. Thus with grass swig/Python support > and the VTK Python bindings, > direct data interaction/visualisation can be implemented. Hm, maybe > i should learn Python .... . > >> 2. Module to convert 3D Polygon -> 3D raster map > > You will need something like a volume rasterizer to do this. That > is not easy to implement. > And the hardest thing of 3D polygons with more than 4 vertices is, > that the polygon surface is not > well defined. You will need additonal points for triangulation. > Otherwise you dont get the surface you expect. > Only triangles or quadrangles are well suited for rasterisation. > > But r.elev.to.rast3 provides limited potentialities for this. > You can convert lines, boundaries or areas into raster maps and put > them with r.to.rast3 or r.elev.to.rast3, > into a g3d volume. > >> 3. Module to query 3d raster value using 3D vector points/coordinates > > You can do this with Paraview. VTK will give you the options to > combine/intersect > pointdata, polydata or unstructured grid data with any kind of > volume data. > Paraview will give you the data on specific points or a specific > path within the volume. > You can use threshold filter, grid filter, cutplanes and much more > to discover your 3D data. > >> 4. Categorization and information like r.report provides > > I was thinking today about a module like r.stats -> r3.stats. But > i'm just thinking about it. ;) > >> >> Maybe for GRASS 6.2? > > You are welcome to help implementing this. :) > > Best regards > Soeren > > btw.: > r.elev.to.rast3 is in CVS now. But it will not build by default, > the entry in the Makefile > is "missing". > A new grass test suite with r.elev.to.rast3 tests is available > (version 0.2.0.9): > http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/ > GRASS_Testsuite-0.2.0.9.tar.bz2 > >> >> Thanks, >> >> Benjamin. >> >> Soeren Gebbert wrote: >>> Dear Hamish, >>> >>> On Monday 10 July 2006 02:53, Hamish wrote: >>> >>>> Soeren Gebbert wrote: >>>> >>>>> i would like to add a new raster-to-raster3d conversion module >>>>> to the grass6.1 CVS in the near future. >>>>> >>>>> The module is called r.elev.to.rast3. >>>>> It creates a new 3D raster map from a 2D elevation and a >>>>> 2D "value" raster map. The principal functioning is shown here: >>>>> http://www-pool.math.tu-berlin.de/~soeren/grass/modules/ >>>>> screenshots/r.elev.to.rast3.png >>>> >>>> Congratulations on the new module! >>> >>> >>> Many thanks! >>> >>> >>>>> I would like to ask if i can commit this module next week, or if i >>>>> have to wait until GRASS 6.1.0 is released? >>>>> I have tested this module with different datasets and it seems >>>>> to work >>>>> properly. And i will add some tests to the grass test-suite. >>>> >>>> >>>> If the new module is ready to be in CVS, but you are not sure if >>>> it is >>>> release-ready, you can always put it in CVS but not add it to the >>>> Makefile or GUI menus. (as long as the change doesn't touch >>>> other parts >>>> of the software) >>> >>> >>> Ok, i will submit it after some more testing, but will not add it >>> to the Makefile/GUI. >>> >>> >>>>> I think together with r.to.rast3 >>>>> http://www-pool.math.tu-berlin.de/~soeren/grass/modules/ >>>>> screenshots/r.to.rast3.png >>>>> r3.to.rast >>>>> http://www-pool.math.tu-berlin.de/~soeren/grass/modules/ >>>>> screenshots/r3.to.rast.png >>>>> and r3.cross.rast >>>>> http://www-pool.math.tu-berlin.de/~soeren/grass/modules/ >>>>> screenshots/r3.cross.rast.png >>>>> the raster<->rast3d modelling/conversion capabilities are mostly >>>>> complete. >>>> >>>> >>>> Small versions of those pics would be a great addition to the help >>>> pages, see r.terraflow, v.voronoi for examples. >>> >>> >>> Thats a great idea, i will do this. >>> >>> Best regards >>> Soeren >>> >>> >>>> >>>> Hamish >>>> >>>> >>> >>> >>> _______________________________________________ >>> grass-dev mailing list >>> grass-dev@grass.itc.it >>> http://grass.itc.it/mailman/listinfo/grass-dev >>> >>> >> > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From neteler at itc.it Fri Jul 14 19:24:49 2006 From: neteler at itc.it (Markus Neteler) Date: Fri Jul 14 19:24:52 2006 Subject: [GRASS-dev] GRASS 6.1.0beta1 released Message-ID: <20060714172449.GA6204@bartok.itc.it> Hi, as announced earlier, I have created the GRASS 6.1.0 branch (branch name: "releasebranch_6_1") and tagged a 6.1.0beta1 release. The source code package is available at: http://grass.itc.it/grass61/source/ It will be on the mirrors in 1-2 days. Before announcing it widely with a press release etc, it should go for testing now on the various platforms. Thanks for the hard work on it, congrats to all people involved! Markus PS: See this page how to get it from CVS: http://grass.itc.it/devel/cvstags.php -- Markus Neteler http://mpa.itc.it/markus/ ITC-irst - Centro per la Ricerca Scientifica e Tecnologica MPBA - Predictive Models for Biol. & Environ. Data Analysis Via Sommarive, 18 - 38050 Povo (Trento), Italy From grass-bugs at intevation.de Fri Jul 14 20:58:33 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Fri Jul 14 20:58:36 2006 Subject: [GRASS-dev] [bug #4840] (grass) sh.show.fonts is missing - should be removed from GUI? Message-ID: <20060714185833.DA5531006CB@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4840 ------------------------------------------------------------------------- Subject: sh.show.fonts is missing - should be removed from GUI? Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: 6.1 cvs checked out 2006-07-14 Using gis.m GUI 'Config/Text/Show standard Grass fonts' gives an error "couldn't execute "show.fonts.sh": no such file or directory" If this shell script is no longer apart of the distribution, it should be removed from the GUI menu. My preference would be to provide this script so a selection of fonts can actually be viewed - it might be useful for new users who aren't familiar with the default fonts that ship with Grass. ~ Eric. -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Fri Jul 14 21:03:09 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Fri Jul 14 21:03:10 2006 Subject: [GRASS-dev] [bug #4841] (grass) r.proj - Percent status bar should build in gis.m GUI Message-ID: <20060714190309.E014F1006CB@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4841 ------------------------------------------------------------------------- Subject: r.proj - Percent status bar should build in gis.m GUI Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: 6.1 cvs checked out 2006-07-14 r.proj provides a percent status from the command line, but not in the GUI in gis.m. The last message printed is "projecting...." and no confirmation is provided that it has completed. Would it be possible to have the standard green status bar to build in the gis.m version as in other modules? ~ Eric. -------------------------------------------- Managed by Request Tracker From soerengebbert at gmx.de Fri Jul 14 22:01:32 2006 From: soerengebbert at gmx.de (Soeren Gebbert) Date: Fri Jul 14 22:01:39 2006 Subject: [GRASS-dev] New raster-to-raster3d conversion module In-Reply-To: <04E1C0B2-CBA6-4161-8368-440397F70BD7@unity.ncsu.edu> References: <200607090015.25361.soerengebbert@gmx.de> <200607110052.40706.soerengebbert@gmx.de> <04E1C0B2-CBA6-4161-8368-440397F70BD7@unity.ncsu.edu> Message-ID: <200607142201.33315.soerengebbert@gmx.de> Dear Helena, On Friday 14 July 2006 18:53, Helena Mitasova wrote: > I don't know whether this is important or not, but at CERL the length > of command names > was carefully guarded (I was not allowed s.surf.tps.cv), so I am > wondering whether we > should continue this tradition and keep just two dots in the name for > as long as possible - > maybe it is possible to find a meaningful two dots name for > r.elev.to.rast3? Sorry, i did not informed me about the maximum command name length, so i chosed r.elev.to.rast3 because that was the best name i found and this name explaned the usage correctly. And i dont wanted to extent r.to.rast3 to avoid to many confusing options. Maybe you or somebody else can help me in finding a better name? How about r.elev.rast3 or r.elev.torast3? > If not - should we set some rules on how to create names for new > modules and when > more dots should be used? The concern then was that it will get out > of control and soon we will > have ever longer and messier names. Yes, you are right! We absolutely have to avoid longer and messier names. Is there already a guidline about grass name creation? If not, we should create one. But how to make sure that meaningful names are always possible with two dots? Best Soeren > > Helena > From glynn at gclements.plus.com Sat Jul 15 03:42:17 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jul 15 03:42:20 2006 Subject: [GRASS-dev] G_get_raster_sample(): request outside region In-Reply-To: References: Message-ID: <17592.18425.923983.557159@cerise.gclements.plus.com> Florian Kindl wrote: > I try to obtain the cell values of a raster map at the location of certain > nodes of a vector map: > > +++ > struct Cell_head window; > G_get_window(&window); > > ... > > Vect_get_node_coor( In, node, &x, &y, NULL ); > z = G_get_raster_sample( fdrast, &window, NULL, x, y, 0, method ); > +++ > > Running this code gives the following message: > WARNING: [rugg_dtmgrd in c716322] - read request for row 311730 is outside region > ERROR: problem reading raster cell file > > Are the coordinates returned by Vect_get_node_coor() a valid argument for > G_get_raster_sample() ? Sometimes. The coordinates passed to the latter must lie within the current region, but the coordinates returned from the former can lie outside of the current region. You will need to manually check the coordinates against the region, e.g.: Vect_get_node_coor( In, node, &x, &y, NULL ); if (x >= window.west && x < window.east && y >= window.south && y < window.north) z = G_get_raster_sample( fdrast, &window, NULL, x, y, 0, method ); else ... > Is my use of G_get_window() OK? Yes. -- Glynn Clements From hamish_nospam at yahoo.com Sat Jul 15 05:37:38 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Sat Jul 15 05:37:43 2006 Subject: [GRASS-dev] Re: [bug #4524] (grass) v.clean, v.patch (else?): output to stderr instead of stdout... In-Reply-To: <20060712083345.54E541006A5@lists.intevation.de> References: <20060712083345.54E541006A5@lists.intevation.de> Message-ID: <20060715153738.557352ea.hamish_nospam@yahoo.com> > > The question might be reduced to "where to send G_message()?" ? > > Anywhere but stdout, I think. > > Example reason: I don't want somebody using my v.flip (a script that > calls v.patch, among the others) to be confused with v.patch > information that: > > # Intersections at borders will have to be snapped. > # Lines common between files will have to be edited. > # The header information also may have to be edited. > > Because I have taken care of this for the user, knowing what the input > for v.patch is and using 'v.clean tool=snap' as needed. That > information above is simply wrong and confusing the user, when v.patch > is a script component. No a general solution, but for your script perhaps you could use "grep -v" or sed to filter out the unwanted messages (after redirecting stderr to stdout as needed)? Hamish From hamish_nospam at yahoo.com Sat Jul 15 10:21:54 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Sat Jul 15 10:22:01 2006 Subject: [GRASS-dev] [bug #4827] (grass) Building topology for vector is incredibly slow In-Reply-To: <20060713095113.83FB81005A5@lists.intevation.de> References: <20060713095113.83FB81005A5@lists.intevation.de> Message-ID: <20060715202154.182a450e.hamish_nospam@yahoo.com> > this bug's URL: http://intevation.de/rt/webrt?serial_num=4827 > --------------------------------------------------------------------- > > Subject: Building topology for vector is incredibly slow > > Platform: Mac OSX > grass binary for platform: Downloaded precompiled Binaries > GRASS Version: 6.1.cvs_060624 > > Raffaele Morelli > I am working with several vector files from Italy I have imported from > shape files with v.in.ogr. Those data comes with ISTAT census, so they > are organized in several small polygons for each town (called > "sezioni"). I wanted to produce a global national vector with polygons > representing towns instead small areas inside towns, so I started > running a shell script with all the "v.extract -d .. .... " to > dissolve boundaries from the same town. Finally I came into a national > vector map after patching the regional maps previously obtained > gatering towns from the same region. > > > After this I launched a v.clean to remove duplicates,small angles and > break poligons. The process runs normally but when it's time to build > topology at the end of v.clean the process is incredibly slow. After > 50 minutes is still running and the building areas progress is at > 33%!!! > > is this 'normal'? run v.split before v.clean. grass6/doc/vector/TODO says: v.in.ogr -------- It would be useful to split long boundaries to smaller pieces. Otherwise cleaning process can become very slow because bounding box of long boundaries can overlap large part of the map (for example outline around all areas) and cleaning process is checking intersection with all boundaries falling in the bounding box. Hamish From hamish_nospam at yahoo.com Sat Jul 15 12:33:05 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Sat Jul 15 12:33:10 2006 Subject: [GRASS-dev] v.in.ascii issues Message-ID: <20060715223305.12acedfa.hamish_nospam@yahoo.com> Greetings all, I just added support to scan dd:mm.mmm format lat/lon strings to libgis, most GPS units output this way. This change can touch g.region etc, so I'm not sure if it is worth the risk adding it to the 6.1.0 branch. Doing this exposed a v.in.ascii bug-like feature- scan type is set to double for columns which contain DDD:MM:SS data causing a DB insert error. if the input lines are like: 45:15.586S|166:55.207E|-45.25977|166.92012|First Arm|3|First Arm inner with x=2 and y=1 cat=6, it scans like: [...] Maximum input row length: 89 Maximum number of columns: 7 Minimum number of columns: 7 column: 1 type: double column: 2 type: double column: 3 type: double column: 4 type: double column: 5 type: string length: 11 column: 6 type: integer column: 7 type: string length: 29 (note column 1,2 are scanned as double) then you get this error: DBMI-DBF driver error: SQL parser error in statement: insert into site_locations values ( [...]) Error in db_execute_immediate() ERROR: Cannot insert values: insert into site_locations values ( [...]) as it tries to insert a string (45:15.586S) into a double column. If you define the column types with columns="" you get a warning, but it imports ok: [...] Maximum input row length: 89 Maximum number of columns: 7 Minimum number of columns: 7 column: 1 type: double column: 2 type: double column: 3 type: double column: 4 type: double column: 5 type: string length: 11 column: 6 type: integer column: 7 type: string length: 29 WARNING: Column 1 defined as string has double values WARNING: Column 2 defined as string has double values Building topology ... [...] the table is populated correctly with col1,2 string values. ??, Hamish From hamish_nospam at yahoo.com Sat Jul 15 13:44:37 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Sat Jul 15 13:44:47 2006 Subject: [GRASS-dev] New raster-to-raster3d conversion module In-Reply-To: <200607110052.40706.soerengebbert@gmx.de> References: <200607090015.25361.soerengebbert@gmx.de> <200607101652.48494.soerengebbert@gmx.de> <44B26D4A.7060104@ufg.uni-kiel.de> <200607110052.40706.soerengebbert@gmx.de> Message-ID: <20060715234437.4a5f4ea1.hamish_nospam@yahoo.com> Soeren Gebbert wrote: > With r.elev.to.rast3 you can put raster map values from a specific map > (input) in a specific elevation layer within a g3d volume, based on a > 2D elevation map (elev). Every 3D cell of the volume that intersect > with the elevation map will be set to the cell value of the input map. > If the hight value of the elevation map is exactly located at the > border between two 3D cells, both cells will get the input map value. > > This works perfectly for putting geological strata into g3d volumes. I > need this for modelling a 3D aquifer. I'm not sure if I mentioned this before, if I did please ignore the duplicate. consider renaming the module "r.to.rast3.elev" (or similar) so like modules are grouped together both in the help pages and logically. thanks, Hamish From hamish_nospam at yahoo.com Sat Jul 15 13:56:44 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Sat Jul 15 13:56:49 2006 Subject: [GRASS-dev] start up GUI text Message-ID: <20060715235644.0b24ff01.hamish_nospam@yahoo.com> Hi, I notice on the GUI start up screen we have: Define new location by: [Use projection values] [Use EPSG values] [Use georeferenced file] "Use " seems redundant & makes it not read well. also (database) Path to location: -> Data Path: ? also [Cancel] -> [Quit] or [Exit] ? also lower case the "V" of "Version 6.1. ..." ? also "The world's leading open source GIS" a) needed? b) poor grammar? c) perhaps we can come up with something catchier? ? Hamish From neteler at itc.it Sat Jul 15 15:46:20 2006 From: neteler at itc.it (Markus Neteler) Date: Sat Jul 15 15:46:22 2006 Subject: [GRASS-dev] Debian control file outdated Message-ID: <20060715134620.GB9134@bartok.itc.it> Hi, could a Debian power user please send diffs (or do that in CVS directly) to update the debian/control file? I still see tcltk 8.3 there, it should be probably tcltk >= 8.3. Other changes may be needed, too. Markus From grass-bugs at intevation.de Sat Jul 15 16:56:28 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sat Jul 15 16:56:29 2006 Subject: [GRASS-dev] [bug #4851] (grass) add wavelength display and data export capability to i.spectral Message-ID: <20060715145628.104731005AF@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4851 ------------------------------------------------------------------------- Subject: add wavelength display and data export capability to i.spectral Platform: Mac OSX grass obtained from: Trento Italy site grass binary for platform: Downloaded precompiled Binaries GRASS Version: Grass 6.1cvs 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! Wishlist Re:i.spectral It would be very helpful if this script could be adapted to show actual wave length values on the x-axis as an alternative to the channel number (or actually the raster file name). Also to be able to save or export the DN values for each point selected. Thanks for your consideration. Stuart Edwards -------------------------------------------- Managed by Request Tracker From hmitaso at unity.ncsu.edu Sat Jul 15 17:08:22 2006 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Sat Jul 15 17:08:55 2006 Subject: [GRASS-dev] New raster-to-raster3d conversion module In-Reply-To: <20060715234437.4a5f4ea1.hamish_nospam@yahoo.com> References: <200607090015.25361.soerengebbert@gmx.de> <200607101652.48494.soerengebbert@gmx.de> <44B26D4A.7060104@ufg.uni-kiel.de> <200607110052.40706.soerengebbert@gmx.de> <20060715234437.4a5f4ea1.hamish_nospam@yahoo.com> Message-ID: <590DF891-B1EC-4043-80FA-E397A4933F07@unity.ncsu.edu> On Jul 15, 2006, at 7:44 AM, Hamish wrote: > Soeren Gebbert wrote: >> With r.elev.to.rast3 you can put raster map values from a specific >> map >> (input) in a specific elevation layer within a g3d volume, based >> on a >> 2D elevation map (elev). Every 3D cell of the volume that intersect >> with the elevation map will be set to the cell value of the input >> map. >> If the hight value of the elevation map is exactly located at the >> border between two 3D cells, both cells will get the input map value. >> >> This works perfectly for putting geological strata into g3d >> volumes. I >> need this for modelling a 3D aquifer. > > > I'm not sure if I mentioned this before, if I did please ignore the > duplicate. > > consider renaming the module "r.to.rast3.elev" (or similar) so like > modules are grouped together both in the help pages and logically. given my previou notes about the 2 dots, it looks like r.to.rast3elev would be a good choice, Helena > > > thanks, > Hamish > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From grass-bugs at intevation.de Sat Jul 15 19:04:58 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sat Jul 15 19:04:59 2006 Subject: [GRASS-dev] [bug #4852] (grass) MySQL driver makefile has debug option hardwired Message-ID: <20060715170458.31A171006C6@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4852 ------------------------------------------------------------------------- Subject: MySQL driver makefile has debug option hardwired Platform: Mac OSX grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: 6.1beta1 The compiler debug option (-g) is hardwired into db/drivers/mysql/makefile. This leaves the user no control over this option from CFLAGS (unless there is an option to cancel it?), and (according to the GCC docs) may cause problems if an optimize option is specified in CFLAGS. -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Sat Jul 15 19:15:27 2006 From: grass-bugs at intevation.de (Markus Neteler via RT) Date: Sat Jul 15 19:15:29 2006 Subject: [GRASS-dev] [bug #4852] (grass) MySQL driver makefile has debug option hardwired Message-ID: <20060715171527.356D41006C6@lists.intevation.de> Fixed in CVS, both head and branch. thanks for the report, Markus -------------------------------------------- Managed by Request Tracker From woklist at kyngchaos.com Sat Jul 15 19:20:15 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Sat Jul 15 19:20:21 2006 Subject: [GRASS-dev] Re: [bug #2860] (grass) add LZW option for r.out.tiff Message-ID: Any possibility of getting this one taken care of soon? From grass-bugs at intevation.de Sat Jul 15 19:32:57 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sat Jul 15 19:33:00 2006 Subject: [GRASS-dev] [bug #4853] (grass) Add iODBC as alternative to UnixODBC Message-ID: <20060715173257.D0A8A1006C3@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4853 ------------------------------------------------------------------------- Subject: Add iODBC as alternative to UnixODBC Platform: Mac OSX grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: 6.1beta1 iODBC is included in the Mac OS X system and there are many ready-made iodbc drivers (including MS Access) for Mac OS X. I've successfully built, and tested a little, iODBC support in GRASS by simply substituting -liodbc for -lodbc in configure. -------------------------------------------- Managed by Request Tracker From woklist at kyngchaos.com Sat Jul 15 21:18:08 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Sat Jul 15 21:18:14 2006 Subject: [GRASS-dev] GRASS 6.1.0beta1 Mac binaries available Message-ID: <21787A63-C444-4D17-BE53-5AF1EF0A7BE2@kyngchaos.com> Mac OS X Universal binaries available on my site. (I don't have a download link on the GRASS site yet) - Universal for PPC and Intel Macs - Mac OS 10.3.9 minimum - requires an Aqua Tcl/Tk (download also available) - used by NVIZ and gis.m. - uses my Graphics Libs and GIS Libs packages. - NVIZ runs without X11, using Tcl/Tk Aqua. BUT, there are some OpenGL issues that cause it to crash on my MacBook. It does work on PPC Macs. I can't test a MacBook Pro or iMac, so I don't know if this crash is for all Intel Macs, or just the ones with the Intel GMA graphics chips (MacBook, Mac Mini). *** someone please test this *** - X11 support is included for d.mon & friends functionality. - uses iODBC instead of UnixODBC for ODBC connections. - sorry, no fancy double-clickable GRASS.app yet. ----- William Kyngesburye http://www.kyngchaos.com/ All generalizations are dangerous, even this one. From jachym.cepicky at centrum.cz Sat Jul 15 22:03:32 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Sat Jul 15 22:05:25 2006 Subject: [GRASS-dev] Debian control file outdated In-Reply-To: <20060715134620.GB9134@bartok.itc.it> References: <20060715134620.GB9134@bartok.itc.it> Message-ID: <20060715200331.GB10074@localdomain> Hi, On Sat, Jul 15, 2006 at 03:46:20PM +0200, Markus Neteler wrote: > Hi, > > could a Debian power user please send diffs (or do that in CVS > directly) to update the debian/control file? > > I still see tcltk 8.3 there, it should be probably > tcltk >= 8.3. Other changes may be needed, too. > > Markus > this way it works: Build-depends: flex, bison, libreadline4-dev || libreadline5-dev, libncurses5-dev, lesstif2-dev, debhelper (>= 4.0.2), dpatch, libtiff4-dev, tcl8.4-dev, tk8.4-dev, fftw-dev, xlibmesa-gl-dev, xlibmesa-gl-dev, libfreetype6-dev, autoconf2.13, autotools-dev, libgdal1-dev || libgdal1-1.3.1-dev, proj (>= 4.4.7), libjpeg62-dev, libpng12-dev, postgresql-dev, unixodbc-dev, doxygen, fakeroot Standards-Version: 3.6.1 jachym -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc ----------------------------------------- OFFICE: GDF-Hannover Mengendamm 16d 30177 Hannover Germany e-mail: cepicky@gdf-hannover.de URL: http://gdf-hannover.de Tel.: +49 511-39088507 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060715/35163527/attachment.bin From cedricgrass at shockfamily.net Sat Jul 15 22:43:49 2006 From: cedricgrass at shockfamily.net (Cedric Shock) Date: Sat Jul 15 22:46:30 2006 Subject: [GRASS-dev] Using current grass gui.tcl in python programs. Message-ID: <200607151343.50452.cedricgrass@shockfamily.net> Hi, This might be a quick way to get up and running with playing with python development. It's fairly easy to use the current gui.tcl in python. Here's an example (copy / paste into python run in grass). This could all be bundled up and abstracted away to be more useful. I also stuck this snippit on the wiki at http://grass.gdf-hannover.de/wiki/GRASS_and_Python , so if you make improvements please share them here and there. --Cedric import Tkinter import os # Startup (onde): tk = Tkinter.Tk() tk.eval ("wm withdraw .") tk.eval ("source $env(GISBASE)/etc/gui.tcl") # Here you could do various things to change what the gui does # See gui.tcl and README.GUI # Make a gui (per dialog) # This sets up a window for the command. # This can be different to integrate with tkinter: tk.eval ('set path ".dialog$dlg"') tk.eval ('toplevel .dialog$dlg') # Load the code for this command: fd = os.popen ("d.vect --tcltk") gui = fd.read() # Run it tk.eval(gui) dlg = tk.eval('set dlg') # This is used later to get and set # Get the current command in the gui we just made: currentcommand = tk.eval ("dialog_get_command " + dlg) # Set the command in the dialog we just made: tk.eval ("dialog_set_command " + dlg + " {d.vect map=roads}") From michael.barton at asu.edu Sun Jul 16 01:05:53 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sun Jul 16 01:06:03 2006 Subject: [GRASS-dev] displaying (slightly) broken raster maps in gis.m In-Reply-To: <17583.25498.356980.121631@cerise.gclements.plus.com> Message-ID: Glynn, I've removed all extraneous 'eval exec' syntax from gism I think, with the exception of the procedures in runandoutput.tcl (attached here for convenience because it's small). If I try to clean up the run and runcmd procedures here, d.mon bombs in the gism startup. I don't know whether it is due to writing to /dev/null or because of d.mon. Could you take a look and offer any suggestions? 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: Glynn Clements > Date: Sat, 8 Jul 2006 08:49:46 +0100 > To: Michael Barton > Cc: Hamish , grass5 > Subject: Re: [GRASS-dev] displaying (slightly) broken raster maps in gis.m > > > Michael Barton wrote: > >>> We noticed gis.m will not display a raster map if the cats/ file is >>> missing but d.rast will. >>> >>> is this something to fix, or nothing to worry about? >>> >>> (mapset was broken after bulk copy via FAT32 external hard drive problems) >> >> Gis.m is just a wrapper for d.rast. So I'm not sure why one should display a >> map and the other one won't. > > gis.m/raster.tcl seems to do a bit more than just run d.rast. > > BTW, looking at that code, I note that the failure to treat commands > as lists appears to be a common problem within gis.m, e.g.: > > set cmd "d.rast map=$opt($id,1,map)" > > # overlay > if { $opt($id,1,overlay) } { > append cmd " -o" > } > > [snip] > > # raster query > if { $opt($id,1,rastquery) != "" } { > append cmd " {$querytype=$opt($id,1,rastquery)}" > } > > # background color > if { $opt($id,1,bkcolor) != "" } { > append cmd " bg=$opt($id,1,bkcolor)" > } > > Although this particular case should work (certainly, none of the > arguments can contain spaces, and I don't think that they can contain > braces), in general you should be using list operations, e.g.: > > set cmd [list d.rast map=$opt($id,1,map)] > > # overlay > if { $opt($id,1,overlay) } { > lappend cmd -o > } > > [snip] > > # raster query > if { $opt($id,1,rastquery) != "" } { > lappend cmd $querytype=$opt($id,1,rastquery) > } > > # background color > if { $opt($id,1,bkcolor) != "" } { > lappend cmd bg=$opt($id,1,bkcolor) > } > > Etc. > > Whilst it is technically sufficient to use list operations only where > necessary, that requires you to actually consider whether or not they > are necessary. As most of the time they aren't necessary, overlooking > the few cases where they /are/ necessary (e.g. filenames, SQL "WHERE" > clauses etc) becomes almost inevitable. > > -- > Glynn Clements -------------- next part -------------- ############################################################################ # # LIBRARY: runandoutput.tcl # AUTHOR(S): Cedric Shock (cedricgrass AT shockfamily.net) # PURPOSE: Interactive console for gis.m and other run commands # COPYRIGHT: (C) 2006 GRASS Development Team # # This program is free software under the GNU General Public # License (>=v2). Read the file COPYING that comes with GRASS # for details. # ############################################################################ ############################################# #Overloaded gui.tcl behaviour: # Overload run_cmd (proc called when run button is pushed) proc run_cmd {dlg} { global gronsole global opt set cmd [dialog_get_command $dlg] catch {$opt($dlg,run_button) configure -state disabled} $gronsole run $cmd {} "catch {$opt($dlg,run_button) configure -state active}" # Bring that output window up: raise [winfo toplevel $gronsole] } # no output or progress or buttons: proc make_output {dlg path root} {} proc make_progress {dlg path root} {} proc make_buttons {dlg path root} {} ########################################### proc make_fun_buttons {dlg path} { global opt env set pgm_name $opt($dlg,pgm_name) set buttonframe [frame $path.buttonframe] button $buttonframe.run -text [G_msg "Run"] -command "run_cmd $dlg" # In the future we'll have a button to make a layer from here: # button $buttonframe.layer -text [G_msg "Layer"] -command "layer_cmd $dlg" button $buttonframe.help -text [G_msg "Help"] -command "help_cmd $dlg" button $buttonframe.close -text [G_msg "Close"] -command "close_cmd $dlg" set opt($dlg,run_button) $buttonframe.run # Turn off help button if the help file doesn't exist if {! [file exists $env(GISBASE)/docs/html/$pgm_name.html]} { $buttonframe.help configure -state disabled } pack $buttonframe.run $buttonframe.help $buttonframe.close \ -side left -expand yes -padx 5 -pady 5 pack $buttonframe -expand no -fill x -side bottom -before [lindex [pack slaves $path] 0] # Set the starting window size if this is a toplevel window if {[winfo toplevel $path] == $path} { wm geometry $path "560x350" } } proc run_ui {cmd} { global dlg path set program [lindex $cmd 0] set code [exec -- $program --tcltk] set path .dialog$dlg toplevel $path eval $code # Push the command to the dialog set thisdialog $dlg dialog_set_command $dlg $cmd # Add our ui make_fun_buttons $dlg $path } ################################################# proc run_disabled {gronsole button cmd} { catch {$button configure -state disabled} $gronsole run $cmd {running} "catch {$button configure -state active}" } proc gronsole_history {cmdtext ci cmd} { $cmdtext delete 1.0 end $cmdtext insert end $cmd } proc command_window {where} { global keycontrol set cmdpane [frame $where.command] set cmdwin [ScrolledWindow $where.win -relief sunken -borderwidth 2] set gronsole [Gronsole $where.gronsole -clickcmd "gronsole_history $cmdwin.text"] set cmdtext [text $cmdwin.text -height 4 -width 80] $cmdwin setwidget $cmdtext set runbutton [button $cmdpane.run -text [G_msg "Run"] -command "run_disabled $gronsole $cmdpane.run \[string trim \[$cmdtext get 1.0 end\]\]"] set run2button [button $cmdpane.run2 -text [G_msg "Run (Background)"] -command "$gronsole run \[string trim \[$cmdtext get 1.0 end\]\] {} {}"] set runuibutton [button $cmdpane.runui -text [G_msg "Run UI"] -command "run_ui \[string trim \[$cmdtext get 1.0 end\]\]"] set runxterm [button $cmdpane.xterm -text [G_msg "Run in Xterm"] -command "$gronsole run_xterm \[string trim \[$cmdtext get 1.0 end\]\] {}"] set outpane [frame $where.output] set savebutton [button $outpane.save -text [G_msg "Save"] -command "$gronsole save"] set clearbutton [button $outpane.clear -text [G_msg "Clear"] -command "$gronsole clear"] pack $runbutton $run2button $runuibutton $runxterm \ -side left -expand yes -padx 5 -pady 5 pack $savebutton $clearbutton \ -side left -expand yes -padx 5 -pady 5 pack $cmdpane -fill x -side bottom pack $cmdwin -fill x -side bottom pack $outpane -fill x -side bottom pack $gronsole -side top -fill both -expand yes bind $cmdtext <$keycontrol-c> "tk_textCopy %W" bind $cmdtext <$keycontrol-v> "tk_textPaste %W" bind $cmdtext <$keycontrol-x> "tk_textCut %W" return $gronsole } toplevel .gronsole wm title .gronsole [G_msg "Output - GIS.m"] # If we had our own window manager we could withdraw windows instead of iconifying them: wm protocol .gronsole WM_DELETE_WINDOW "wm iconify .gronsole" set gronsole [command_window {.gronsole}] ############################################################################### # Run procs for gis.m: ################################################################################ proc execute {cmd} { # Use run and output run_ui $cmd } ############################################################################### proc spawn {cmd args} { exec -- $cmd $args & } ############################################################################### proc spawn_panel {cmd args} { global gronsole $gronsole run $cmd gism {} } ############################################################################### proc run_panel {cmd} { global gronsole $gronsole run_wait $cmd gism } ############################################################################### proc run {cmd args} { # 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 exec -- $cmd $args >& /dev/null } ############################################################################### proc runcmd {cmd args} { global gronsole set ci [$gronsole annotate $cmd [list gism running]] eval run $cmd $args $gronsole remove_tag $ci running } ############################################################################### proc term_panel {cmd} { global gronsole $gronsole run_xterm $cmd gism } ############################################################################### proc term {cmd args} { global env exec -- xterm -name xterm-grass -e $env(GISBASE)/etc/grass-run.sh $cmd $args & } ############################################################################### # Make sure there's an xmon before running some commands. # Used in menus. proc guarantee_xmon {} { if {![catch {open "|d.mon -L" r} input]} { while {[gets $input line] >= 0 } { if {[regexp -nocase {(x[0-9]+).*not running} $line dummy monitor]} { # $monnum is the monitor number #create list of non-running monitors lappend xmonlist $monitor } } } close $input set xmon [lindex $xmonlist 0] spawn "d.mon start=$xmon" } ############################################################################### # Annotation procs for gis.m: proc monitor_annotation_start {mon title tags} { global gronsole set handle [$gronsole annotate $title $tags] $gronsole set_click_command $handle {} return $handle } proc monitor_annotate {handle text} { global gronsole $gronsole annotate_text $handle $text } From michael.barton at asu.edu Sun Jul 16 01:28:17 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sun Jul 16 01:28:22 2006 Subject: [GRASS-dev] start up GUI text In-Reply-To: <20060715235644.0b24ff01.hamish_nospam@yahoo.com> Message-ID: Hamish, Responses below. 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: Sat, 15 Jul 2006 23:56:44 +1200 > To: grass5 > Subject: [GRASS-dev] start up GUI text > > Hi, > > I notice on the GUI start up screen we have: > > Define new location by: > [Use projection values] > [Use EPSG values] > [Use georeferenced file] Actually, it says ... Define new location: [Use projection values] [Use EPSG values] [Use georeferenced file] ... not "Define new location by:" I'm looking at code downloaded from the cvs today. Is this OK, or does ... Define new location by: [Projection values] [EPSG values] [Georeferenced file] ...sound better? Makes no difference to me as long as it's understandable. > > also (database) > Path to location: -> Data Path: ? Trying to get away from old "database" term that is confusing to many people. What this refers to, of course, is simply the directory where your location is located. Note, that "location" seems somewhat confusing too, but is deeply embedded into GRASS and is no worse than the jargon one has to learn for other GIS programs. So what to call this? Data path is OK, but I'm trying to tie it back to GRASS location terminology because locations are the critical thing to start with. > > > > also > [Cancel] -> [Quit] or [Exit] ? I simply used the pre-existing button name. Either of the others is OK with me. Which do you and others prefer? > > > also > lower case the "V" of "Version 6.1. ..." ? Again, just used the prior text. Easy to change. I'll commit it next week. > > also > "The world's leading open source GIS" > > a) needed? > b) poor grammar? Copied from the web site home page. What's wrong with the grammar? > c) perhaps we can come up with something catchier? Sure. Suggestions? This was all pretty fast and dirty to improve the startup screen. So it's great if we can fine tune it further. From glynn at gclements.plus.com Sun Jul 16 01:56:06 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jul 16 01:56:11 2006 Subject: [GRASS-dev] New raster-to-raster3d conversion module In-Reply-To: <590DF891-B1EC-4043-80FA-E397A4933F07@unity.ncsu.edu> References: <200607090015.25361.soerengebbert@gmx.de> <200607101652.48494.soerengebbert@gmx.de> <44B26D4A.7060104@ufg.uni-kiel.de> <200607110052.40706.soerengebbert@gmx.de> <20060715234437.4a5f4ea1.hamish_nospam@yahoo.com> <590DF891-B1EC-4043-80FA-E397A4933F07@unity.ncsu.edu> Message-ID: <17593.32918.354076.582402@cerise.gclements.plus.com> Helena Mitasova wrote: > >> With r.elev.to.rast3 you can put raster map values from a specific > >> map > >> (input) in a specific elevation layer within a g3d volume, based > >> on a > >> 2D elevation map (elev). Every 3D cell of the volume that intersect > >> with the elevation map will be set to the cell value of the input > >> map. > >> If the hight value of the elevation map is exactly located at the > >> border between two 3D cells, both cells will get the input map value. > >> > >> This works perfectly for putting geological strata into g3d > >> volumes. I > >> need this for modelling a 3D aquifer. > > > > > > I'm not sure if I mentioned this before, if I did please ignore the > > duplicate. > > > > consider renaming the module "r.to.rast3.elev" (or similar) so like > > modules are grouped together both in the help pages and logically. > > given my previou notes about the 2 dots, it looks like r.to.rast3elev > would be a good choice, Is there any particuarl reason for imposing a "two dots" restriction? -- Glynn Clements From glynn at gclements.plus.com Sun Jul 16 02:20:40 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jul 16 02:20:47 2006 Subject: [GRASS-dev] displaying (slightly) broken raster maps in gis.m In-Reply-To: References: <17583.25498.356980.121631@cerise.gclements.plus.com> Message-ID: <17593.34392.144164.7741@cerise.gclements.plus.com> Michael Barton wrote: > I've removed all extraneous 'eval exec' syntax from gism I think, with the > exception of the procedures in runandoutput.tcl (attached here for > convenience because it's small). If I try to clean up the run and runcmd > procedures here, d.mon bombs in the gism startup. I don't know whether it is > due to writing to /dev/null or because of d.mon. Could you take a look and > offer any suggestions? Thanks. proc run {cmd args} { # 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 exec -- $cmd $args >& /dev/null } proc runcmd {cmd args} { global gronsole set ci [$gronsole annotate $cmd [list gism running]] eval run $cmd $args $gronsole remove_tag $ci running } Cases like this, where the arguments are passed as single list, have to use eval, as exec expects each command-line argument to be a separate argument. If you removed the eval, it would pass the entire argument list as a single argument, which won't work. This isn't a problem, as the "args" syntax (where a procedure's last parameter is named "args") is guaranteed to construct the list correctly. The main point is to apply the same principles to run/runcmd as to exec, i.e. either pass individual arguments or, if you need to use e.g. "eval runcmd $cmd $args", ensure that the argument list is constructed using list operations rather than string concatenation. -- Glynn Clements From hmitaso at unity.ncsu.edu Sun Jul 16 02:36:14 2006 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Sun Jul 16 02:36:20 2006 Subject: [GRASS-dev] New raster-to-raster3d conversion module In-Reply-To: <17593.32918.354076.582402@cerise.gclements.plus.com> References: <200607090015.25361.soerengebbert@gmx.de> <200607101652.48494.soerengebbert@gmx.de> <44B26D4A.7060104@ufg.uni-kiel.de> <200607110052.40706.soerengebbert@gmx.de> <20060715234437.4a5f4ea1.hamish_nospam@yahoo.com> <590DF891-B1EC-4043-80FA-E397A4933F07@unity.ncsu.edu> <17593.32918.354076.582402@cerise.gclements.plus.com> Message-ID: <5CDE235A-CAAE-4DF9-86B9-4962AE2BA1BB@unity.ncsu.edu> On Jul 15, 2006, at 7:56 PM, Glynn Clements wrote: > > Helena Mitasova wrote: > >>>> With r.elev.to.rast3 you can put raster map values from a specific >>>> map >>>> (input) in a specific elevation layer within a g3d volume, based >>>> on a >>>> 2D elevation map (elev). Every 3D cell of the volume that intersect >>>> with the elevation map will be set to the cell value of the input >>>> map. >>>> If the hight value of the elevation map is exactly located at the >>>> border between two 3D cells, both cells will get the input map >>>> value. >>>> >>>> This works perfectly for putting geological strata into g3d >>>> volumes. I >>>> need this for modelling a 3D aquifer. >>> >>> >>> I'm not sure if I mentioned this before, if I did please ignore the >>> duplicate. >>> >>> consider renaming the module "r.to.rast3.elev" (or similar) so like >>> modules are grouped together both in the help pages and logically. >> >> given my previou notes about the 2 dots, it looks like r.to.rast3elev >> would be a good choice, > > Is there any particuarl reason for imposing a "two dots" restriction? just to avoid getting the names out of control - imagine the man page http://grass.itc.it/grass61/manuals/html61_user/raster.html with command names such as r.slope.aspect.curv.polyn2nd.vers3 and they can easily lose any logic, such as s.surf.rst.vol.time.cv (we actually had that kind of name for a development version of s.volt.rst) We can certainly have longer module names but I would suggest some rules on how to keep them meaningful and logical. Helena P.S. I looked at the man pages and surprisingly there are almost no offenders to the two dots max rule in spite of the fact that this has never been an official rule. (v.db.reconnect.all and v.in.sites.all are the exception and they are recent additions) > > -- > Glynn Clements From michael.barton at asu.edu Sun Jul 16 02:39:25 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sun Jul 16 02:39:30 2006 Subject: [GRASS-dev] Using current grass gui.tcl in python programs. In-Reply-To: <200607151343.50452.cedricgrass@shockfamily.net> Message-ID: Thanks Cedric. Good to see you back. Doesn't Tkinter require TclTk to be installed? If so, is there an advantage to having gui.tcl run under Python/Tkinter vs. Wish as it does now? That is, the wxPython prototype I'm working on can launch a GRASS command and it's TclTk gui. Of course this means I'm running part of the UI under TclTk and part under wxPython at the moment. Does Tkinter change this? 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: Cedric Shock > Date: Sat, 15 Jul 2006 13:43:49 -0700 > To: > Subject: [GRASS-dev] Using current grass gui.tcl in python programs. > > Hi, > > This might be a quick way to get up and running with playing with python > development. It's fairly easy to use the current gui.tcl in python. Here's an > example (copy / paste into python run in grass). This could all be bundled up > and abstracted away to be more useful. I also stuck this snippit on the wiki > at http://grass.gdf-hannover.de/wiki/GRASS_and_Python , so if you make > improvements please share them here and there. > > --Cedric > > import Tkinter > import os > > # Startup (onde): > > tk = Tkinter.Tk() > tk.eval ("wm withdraw .") > tk.eval ("source $env(GISBASE)/etc/gui.tcl") > # Here you could do various things to change what the gui does > # See gui.tcl and README.GUI > > # Make a gui (per dialog) > # This sets up a window for the command. > # This can be different to integrate with tkinter: > tk.eval ('set path ".dialog$dlg"') > tk.eval ('toplevel .dialog$dlg') > # Load the code for this command: > fd = os.popen ("d.vect --tcltk") > gui = fd.read() > # Run it > tk.eval(gui) > dlg = tk.eval('set dlg') # This is used later to get and set > > # Get the current command in the gui we just made: > currentcommand = tk.eval ("dialog_get_command " + dlg) > > # Set the command in the dialog we just made: > tk.eval ("dialog_set_command " + dlg + " {d.vect map=roads}") > > From michael.barton at asu.edu Sun Jul 16 02:40:59 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sun Jul 16 02:41:04 2006 Subject: [GRASS-dev] displaying (slightly) broken raster maps in gis.m In-Reply-To: <17593.34392.144164.7741@cerise.gclements.plus.com> Message-ID: OK. Then I think I've got it done. I'll commit it 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: Glynn Clements > Date: Sun, 16 Jul 2006 01:20:40 +0100 > To: Michael Barton > Cc: Hamish , grass5 > Subject: Re: [GRASS-dev] displaying (slightly) broken raster maps in gis.m > > > Michael Barton wrote: > >> I've removed all extraneous 'eval exec' syntax from gism I think, with the >> exception of the procedures in runandoutput.tcl (attached here for >> convenience because it's small). If I try to clean up the run and runcmd >> procedures here, d.mon bombs in the gism startup. I don't know whether it is >> due to writing to /dev/null or because of d.mon. Could you take a look and >> offer any suggestions? Thanks. > > proc run {cmd args} { > # 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 exec -- $cmd $args >& /dev/null > } > > proc runcmd {cmd args} { > global gronsole > > set ci [$gronsole annotate $cmd [list gism running]] > > eval run $cmd $args > > $gronsole remove_tag $ci running > } > > Cases like this, where the arguments are passed as single list, have > to use eval, as exec expects each command-line argument to be a > separate argument. If you removed the eval, it would pass the entire > argument list as a single argument, which won't work. > > This isn't a problem, as the "args" syntax (where a procedure's last > parameter is named "args") is guaranteed to construct the list > correctly. > > The main point is to apply the same principles to run/runcmd as to > exec, i.e. either pass individual arguments or, if you need to use > e.g. "eval runcmd $cmd $args", ensure that the argument list is > constructed using list operations rather than string concatenation. > > -- > Glynn Clements From jachym.cepicky at centrum.cz Sun Jul 16 09:08:22 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Sun Jul 16 09:10:14 2006 Subject: [GRASS-dev] Using current grass gui.tcl in python programs. In-Reply-To: References: <200607151343.50452.cedricgrass@shockfamily.net> Message-ID: <20060716070821.GC6120@localdomain> If I'm not wrong, Tk goes with standard python distribution for all platforms jachym On Sat, Jul 15, 2006 at 05:39:25PM -0700, Michael Barton wrote: > Thanks Cedric. > > Good to see you back. > > Doesn't Tkinter require TclTk to be installed? If so, is there an advantage > to having gui.tcl run under Python/Tkinter vs. Wish as it does now? That is, > the wxPython prototype I'm working on can launch a GRASS command and it's > TclTk gui. Of course this means I'm running part of the UI under TclTk and > part under wxPython at the moment. Does Tkinter change this? > > 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: Cedric Shock > > Date: Sat, 15 Jul 2006 13:43:49 -0700 > > To: > > Subject: [GRASS-dev] Using current grass gui.tcl in python programs. > > > > Hi, > > > > This might be a quick way to get up and running with playing with python > > development. It's fairly easy to use the current gui.tcl in python. Here's an > > example (copy / paste into python run in grass). This could all be bundled up > > and abstracted away to be more useful. I also stuck this snippit on the wiki > > at http://grass.gdf-hannover.de/wiki/GRASS_and_Python , so if you make > > improvements please share them here and there. > > > > --Cedric > > > > import Tkinter > > import os > > > > # Startup (onde): > > > > tk = Tkinter.Tk() > > tk.eval ("wm withdraw .") > > tk.eval ("source $env(GISBASE)/etc/gui.tcl") > > # Here you could do various things to change what the gui does > > # See gui.tcl and README.GUI > > > > # Make a gui (per dialog) > > # This sets up a window for the command. > > # This can be different to integrate with tkinter: > > tk.eval ('set path ".dialog$dlg"') > > tk.eval ('toplevel .dialog$dlg') > > # Load the code for this command: > > fd = os.popen ("d.vect --tcltk") > > gui = fd.read() > > # Run it > > tk.eval(gui) > > dlg = tk.eval('set dlg') # This is used later to get and set > > > > # Get the current command in the gui we just made: > > currentcommand = tk.eval ("dialog_get_command " + dlg) > > > > # Set the command in the dialog we just made: > > tk.eval ("dialog_set_command " + dlg + " {d.vect map=roads}") > > > > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc ----------------------------------------- OFFICE: GDF-Hannover Mengendamm 16d 30177 Hannover Germany e-mail: cepicky@gdf-hannover.de URL: http://gdf-hannover.de Tel.: +49 511-39088507 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060716/ccc31e86/attachment.bin From tutey at o2.pl Sun Jul 16 10:03:28 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Sun Jul 16 10:03:33 2006 Subject: [GRASS-dev] Using current grass gui.tcl in python programs. In-Reply-To: <20060716070821.GC6120@localdomain> References: <200607151343.50452.cedricgrass@shockfamily.net> <20060716070821.GC6120@localdomain> Message-ID: <44B9F2D0.3050308@o2.pl> Jachym Cepicky napisa?(a): > If I'm not wrong, Tk goes with standard python distribution for all > platforms On Ubuntu python-tk is a separate package, not required when installing python. I could safely remove it having python and python-dev still installed. Maciek From jachym.cepicky at centrum.cz Sun Jul 16 10:06:01 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Sun Jul 16 10:07:55 2006 Subject: [GRASS-dev] Using current grass gui.tcl in python programs. In-Reply-To: <44B9F2D0.3050308@o2.pl> References: <200607151343.50452.cedricgrass@shockfamily.net> <20060716070821.GC6120@localdomain> <44B9F2D0.3050308@o2.pl> Message-ID: <20060716080600.GA6095@localdomain> apt-cache show python Suggests: python-doc, python-tk, python-profiler on other platforms, it should be internal part. no reason for make it internal part also on linux, where dependeces are usually solved by packaging system jachym On Sun, Jul 16, 2006 at 10:03:28AM +0200, Maciej Sieczka wrote: > Jachym Cepicky napisa?(a): > > If I'm not wrong, Tk goes with standard python distribution for all > > platforms > > On Ubuntu python-tk is a separate package, not required when installing > python. I could safely remove it having python and python-dev still > installed. > > Maciek > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc ----------------------------------------- OFFICE: GDF-Hannover Mengendamm 16d 30177 Hannover Germany e-mail: cepicky@gdf-hannover.de URL: http://gdf-hannover.de Tel.: +49 511-39088507 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060716/44b0c473/attachment.bin From tutey at o2.pl Sun Jul 16 11:20:17 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Sun Jul 16 11:20:21 2006 Subject: [GRASS-dev] Using current grass gui.tcl in python programs. In-Reply-To: <20060716080600.GA6095@localdomain> References: <200607151343.50452.cedricgrass@shockfamily.net> <20060716070821.GC6120@localdomain> <44B9F2D0.3050308@o2.pl> <20060716080600.GA6095@localdomain> Message-ID: <44BA04D1.70007@o2.pl> Jachym Cepicky napisa?(a): > apt-cache show python > Suggests: python-doc, python-tk, python-profiler > > on other platforms, it should be internal part. no reason for make it > internal part also on linux, where dependeces are usually solved by > packaging system I understand. I only wanted to let know that installing python on Linux doeasn't imply python-tk installed too. Cheers, Maciek From michael.barton at asu.edu Sun Jul 16 18:34:32 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sun Jul 16 18:34:46 2006 Subject: [GRASS-dev] Using current grass gui.tcl in python programs. In-Reply-To: <20060716070821.GC6120@localdomain> Message-ID: I guess I didn't phrase my question correctly. Sorry. Since all GRASS distributions already have TclTk installed, is there any advantage to redoing gui.tcl to work in a Tkinter environment for Python testing purposes? Or are we better off building on the python gui module that Markus put into the cvs? 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: Jachym Cepicky > Date: Sun, 16 Jul 2006 09:08:22 +0200 > To: Michael Barton > Cc: Cedric Shock , > Subject: Re: [GRASS-dev] Using current grass gui.tcl in python programs. > > If I'm not wrong, Tk goes with standard python distribution for all > platforms > > jachym > > On Sat, Jul 15, 2006 at 05:39:25PM -0700, Michael Barton wrote: >> Thanks Cedric. >> >> Good to see you back. >> >> Doesn't Tkinter require TclTk to be installed? If so, is there an advantage >> to having gui.tcl run under Python/Tkinter vs. Wish as it does now? That is, >> the wxPython prototype I'm working on can launch a GRASS command and it's >> TclTk gui. Of course this means I'm running part of the UI under TclTk and >> part under wxPython at the moment. Does Tkinter change this? >> >> 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: Cedric Shock >>> Date: Sat, 15 Jul 2006 13:43:49 -0700 >>> To: >>> Subject: [GRASS-dev] Using current grass gui.tcl in python programs. >>> >>> Hi, >>> >>> This might be a quick way to get up and running with playing with python >>> development. It's fairly easy to use the current gui.tcl in python. Here's >>> an >>> example (copy / paste into python run in grass). This could all be bundled >>> up >>> and abstracted away to be more useful. I also stuck this snippit on the wiki >>> at http://grass.gdf-hannover.de/wiki/GRASS_and_Python , so if you make >>> improvements please share them here and there. >>> >>> --Cedric >>> >>> import Tkinter >>> import os >>> >>> # Startup (onde): >>> >>> tk = Tkinter.Tk() >>> tk.eval ("wm withdraw .") >>> tk.eval ("source $env(GISBASE)/etc/gui.tcl") >>> # Here you could do various things to change what the gui does >>> # See gui.tcl and README.GUI >>> >>> # Make a gui (per dialog) >>> # This sets up a window for the command. >>> # This can be different to integrate with tkinter: >>> tk.eval ('set path ".dialog$dlg"') >>> tk.eval ('toplevel .dialog$dlg') >>> # Load the code for this command: >>> fd = os.popen ("d.vect --tcltk") >>> gui = fd.read() >>> # Run it >>> tk.eval(gui) >>> dlg = tk.eval('set dlg') # This is used later to get and set >>> >>> # Get the current command in the gui we just made: >>> currentcommand = tk.eval ("dialog_get_command " + dlg) >>> >>> # Set the command in the dialog we just made: >>> tk.eval ("dialog_set_command " + dlg + " {d.vect map=roads}") >>> >>> >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev > > -- > Jachym Cepicky > e-mail: jachym.cepicky@centrum.cz > URL: http://les-ejk.cz > GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc > ----------------------------------------- > OFFICE: > GDF-Hannover > Mengendamm 16d > 30177 Hannover > Germany > e-mail: cepicky@gdf-hannover.de > URL: http://gdf-hannover.de > Tel.: +49 511-39088507 From neteler at itc.it Sun Jul 16 18:41:07 2006 From: neteler at itc.it (Markus Neteler) Date: Sun Jul 16 18:41:09 2006 Subject: [GRASS-dev] Using current grass gui.tcl in python programs. In-Reply-To: References: <20060716070821.GC6120@localdomain> Message-ID: <20060716164107.GC24993@bartok.itc.it> On Sun, Jul 16, 2006 at 09:34:32AM -0700, Michael Barton wrote: > I guess I didn't phrase my question correctly. Sorry. Since all GRASS > distributions already have TclTk installed, is there any advantage to > redoing gui.tcl to work in a Tkinter environment for Python testing > purposes? Or are we better off building on the python gui module that Markus > put into the cvs? To add confusion :-) I didn't put a python gui module into the cvs... I uploaded the Python-SWIG code which is intended to permit Pythonic access to library functionality of GRASS (maybe also modules in future). Markus From tutey at o2.pl Sun Jul 16 23:17:12 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Sun Jul 16 23:26:19 2006 Subject: [GRASS-dev] Re: [GRASS-CVS] markus: newsletter/GRASSNews_vol4/grass_articles srtm_kriging.tex, 1.1, 1.2 In-Reply-To: <20060716164436.D81921005AF@lists.intevation.de> References: <20060716164436.D81921005AF@lists.intevation.de> Message-ID: <44BAACD8.20608@o2.pl> > +According to \cite{valeriano:2002}, variograms calculated with linear trend residues of topographic data have adequate fits to classical variogram models, which present a clear and defined sill. Residues of trend surface analysis are used to guarantee geostationarity of data being modelled. > > Since DEMs datasets can be very large, variogram calculation and kriging interpolation can became very time-consuming tasks. The basic idea is to choose a representative subset of the study area, and calculate the variogram over this subset. This variogram model will then be used by kriging to interpolate the hole dataset Typo: "hole" should be "whole". Maciek From Florian.Kindl at uibk.ac.at Mon Jul 17 10:22:17 2006 From: Florian.Kindl at uibk.ac.at (Florian Kindl) Date: Mon Jul 17 10:21:07 2006 Subject: [GRASS-dev] G_get_raster_sample(): request outside region In-Reply-To: <17592.18425.923983.557159@cerise.gclements.plus.com> References: <17592.18425.923983.557159@cerise.gclements.plus.com> Message-ID: On 15.07.2006, at 03:42, Glynn Clements wrote: > > Sometimes. The coordinates passed to the latter must lie within the > current region, but the coordinates returned from the former can lie > outside of the current region. > Glynn, thank you very much for your response! I think I understand what you are saying, but: - my vectors lie completely within the raster. - the error occurs when the region is set to the extent of the raster as well as when it is set to the extent of the vectors. So, how can it be that Vect_get_node_coor() returns coordinates outside the current region? And how can it be that the error occurs even though the node really lies within the current region: +++ /* debug output of my program: */ window.north=270001.000000 window.south=265000.000000 window.west= -45000.000000 window.east= -39000.000000 coor node 1: -41729.635417,267224.854167 WARNING: [raster] - read request for row 311730 is outside region ERROR: problem reading raster cell file +++ thanks again, -Flo. From glynn at gclements.plus.com Mon Jul 17 11:15:45 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jul 17 11:16:01 2006 Subject: [GRASS-dev] G_get_raster_sample(): request outside region In-Reply-To: References: <17592.18425.923983.557159@cerise.gclements.plus.com> Message-ID: <17595.21825.346783.307881@cerise.gclements.plus.com> Florian Kindl wrote: > > Sometimes. The coordinates passed to the latter must lie within the > > current region, but the coordinates returned from the former can lie > > outside of the current region. > > I think I understand what you are saying, but: > - my vectors lie completely within the raster. > - the error occurs when the region is set to the extent of the raster > as well as when it is set to the extent of the vectors. > > So, how can it be that Vect_get_node_coor() returns coordinates > outside the current region? > > And how can it be that the error occurs even though the node really > lies within the current region: > > > +++ > > /* debug output of my program: */ > window.north=270001.000000 > window.south=265000.000000 > window.west= -45000.000000 > window.east= -39000.000000 > coor node 1: -41729.635417,267224.854167 > > WARNING: [raster] - read request for row 311730 is outside region > ERROR: problem reading raster cell file Note the order of the coordinates: double G_get_raster_sample (int fd, struct Cell_head *window, struct Categories *cats, double north, double east, int usedesc, INTERP_TYPE itype) Northing first, easting second; i.e. Y first, X second. Why do I suspect that you have them the wrong way around? If you subtract the easting (instead of the northing) from the north edge of the region, you get: 270001.000000 - -41729.635417 = 311730.635417 Which looks suspiciously like the "row 311730" that it's complaning about. -- Glynn Clements From Florian.Kindl at uibk.ac.at Mon Jul 17 11:43:36 2006 From: Florian.Kindl at uibk.ac.at (Florian Kindl) Date: Mon Jul 17 11:43:42 2006 Subject: [GRASS-dev] G_get_raster_sample(): request outside region - SOLVED In-Reply-To: <17595.21825.346783.307881@cerise.gclements.plus.com> References: <17592.18425.923983.557159@cerise.gclements.plus.com> <17595.21825.346783.307881@cerise.gclements.plus.com> Message-ID: On Mon, 17 Jul 2006, Glynn Clements wrote: > Note the order of the coordinates: > > Northing first, easting second; i.e. Y first, X second. ^^^^^^^^^^^^^^^^^^ (!) That's it, of course! Glynn, you're great - thank you very much!! -Flo. From neteler at itc.it Mon Jul 17 12:22:38 2006 From: neteler at itc.it (Markus Neteler) Date: Mon Jul 17 12:22:40 2006 Subject: [GRASS-dev] Re: [bug #4523] (grass) missing db help pages In-Reply-To: <20060710091727.712011005DE@lists.intevation.de> References: <20060710091727.712011005DE@lists.intevation.de> Message-ID: <44BB64EE.2020606@itc.it> Maciek Sieczka via RT wrote on 07/10/2006 11:17 AM: > Markus wrote: > > >> The concept is to only install docs where drivers are >> available. A related note is given in the parent help >> page. >> > > Is that concept OK? Why shouldn't the user be able to learn about Grass-mysql > or Grass-sqlite interaction not having built Grass --with either of them? > Usually first we try to learn about the very basics and caveats befer going > for something - just to make sure it is worth trying at all. > Just go the the web pages: http://grass.itc.it/grass61/manuals/html61_user/sql.html > Besides, dead links in manual are not desired. > On the web they are all working (now), Markus From neteler at itc.it Mon Jul 17 16:32:20 2006 From: neteler at itc.it (Markus Neteler) Date: Mon Jul 17 16:32:22 2006 Subject: [GRASS-dev] [bug #4527] (grass) db.copy: segfault when to_table already exists In-Reply-To: References: <20060710110125.61408100160@lists.intevation.de> Message-ID: <20060717143220.GB10823@bartok.itc.it> Patch applied to both HEAD and 6.1.0-Branch. thanks Markus On Mon, Jul 10, 2006 at 01:50:40PM +0200, Martin Landa wrote: > Hi, > > I hope the attached patch will fix it... > > Best, Martin > > 2006/7/10, Maciek Sieczka via RT : > >The bug still bites (CVS today). > > > >Maciek > > > > > >-------------------------------------------- Managed by Request Tracker > > > >_______________________________________________ > >grass-dev mailing list > >grass-dev@grass.itc.it > >http://grass.itc.it/mailman/listinfo/grass-dev > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Markus Neteler http://mpa.itc.it/markus/ ITC-irst - Centro per la Ricerca Scientifica e Tecnologica MPBA - Predictive Models for Biol. & Environ. Data Analysis Via Sommarive, 18 - 38050 Povo (Trento), Italy From grass-bugs at intevation.de Mon Jul 17 19:03:19 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Mon Jul 17 19:03:21 2006 Subject: [GRASS-dev] [bug #4863] (grass) r.terraflow: flow= option Message-ID: <20060717170319.0D2EA1006D4@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4863 ------------------------------------------------------------------------- Subject: r.terraflow: flow= option It would be nice if r.terraflow has flow= option (weighted flow accumulation) like r.watershed does. Current r.watershed supports only CELL maps. -------------------------------------------- Managed by Request Tracker From neteler at itc.it Mon Jul 17 19:35:56 2006 From: neteler at itc.it (Markus Neteler) Date: Mon Jul 17 19:35:57 2006 Subject: [GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init gis_set.tcl, 1.24, 1.25 In-Reply-To: <20060717172842.F1D771006C7@lists.intevation.de> References: <20060717172842.F1D771006C7@lists.intevation.de> Message-ID: <20060717173556.GB380@bartok.itc.it> Hi, a few questions: On Mon, Jul 17, 2006 at 07:28:42PM +0200, grass@intevation.de wrote: > Author: michael > > Update of /grassrepository/grass6/lib/init > In directory doto:/tmp/cvs-serv30054 > > Modified Files: > gis_set.tcl > Log Message: > update exec and eval exec statements to properly parse arguments > > Index: gis_set.tcl > =================================================================== > RCS file: /grassrepository/grass6/lib/init/gis_set.tcl,v > retrieving revision 1.24 > retrieving revision 1.25 > diff -u -d -r1.24 -r1.25 > --- gis_set.tcl 24 Jun 2006 19:33:59 -0000 1.24 > +++ gis_set.tcl 17 Jul 2006 17:28:40 -0000 1.25 > @@ -312,10 +312,10 @@ > pack $introtitle -side top > > .frame0.intro.msg tag configure all -justify center > - .frame0.intro.msg insert end [G_msg "Welcome to GRASS GIS Version $GRASSVERSION\n"] > + .frame0.intro.msg insert end [G_msg "Welcome to GRASS GIS version $GRASSVERSION\n"] > .frame0.intro.msg insert end [G_msg "The world's leading open source GIS\n\n"] > - .frame0.intro.msg insert end [G_msg "Select an existing project location and mapset\n"] > - .frame0.intro.msg insert end [G_msg "or define a new project location\n"] > + .frame0.intro.msg insert end [G_msg "Select an existing projection location and GIS mapset\n"] ... what does "existing projection location" mean? I only know "existing project location". The change adds confusion in my opinion. If projected is meant, it is not right since latlong (usually) and xy (always) are unprojected. > + .frame0.intro.msg insert end [G_msg "or define a new projection location\n"] ...also here. > .frame0.intro.msg tag add all 1.0 end > .frame0.intro.msg configure -state disabled > > @@ -338,7 +338,7 @@ > label .frame0.frameDB.left.label \ > -anchor {n} \ > -justify right \ > - -text [G_msg "Path to location: \n(GRASS Database)"] > + -text [G_msg "Path to location : "] "GRASS Database" is a widely used term in the GRASS literature, but sure if it should be removed. > entry .frame0.frameDB.mid.entry \ > -relief {sunken} \ > @@ -408,7 +408,7 @@ > > label .frame0.frameMS.label \ > -anchor {w} \ > - -text [G_msg "Accessible Mapsets"] > + -text [G_msg "(Accessible) GIS Mapsets"] ... this re-reverted the last fix... The () do not add information in my opionion. > listbox .frame0.frameMS.listbox \ > -relief {sunken} \ > @@ -460,7 +460,7 @@ > > label .frame0.frameNMS.first.label \ > -anchor {n} \ > - -text [G_msg "Create new mapset\nin selected location"] > + -text [G_msg "Create new GIS mapset\nin currrent location"] I am also not sure of that. In the beginning nothing is selected, so there is no currrent location. > entry .frame0.frameNMS.second.entry \ > -relief {sunken} \ > @@ -495,7 +495,7 @@ > > label .frame0.frameNMS.fourth.label \ > -anchor {n} \ > - -text [G_msg "\nDefine new location by:"] > + -text [G_msg "Define new projection location"] ... again confusing (for me). > > button .frame0.frameNMS.fifth.button \ > It seems that this needs to be discussed again: at least I would like to better understand most of the changes. thanks Markus From michael.barton at asu.edu Mon Jul 17 20:02:25 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Jul 17 20:02:49 2006 Subject: [GRASS-dev] GRASS 6.1.0beta1 released In-Reply-To: <20060717174027.GA490@bartok.itc.it> Message-ID: Markus, I little while ago I committed all the updates to gism for eval exec and parsing arguments (and hopefully spaces in mac path names). I'm copying this to the list and to Agust?n for testing prior to back porting. 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: Markus Neteler > Date: Mon, 17 Jul 2006 19:40:27 +0200 > To: Michael Barton > Subject: Re: [GRASS-dev] GRASS 6.1.0beta1 released > > Michael, > > On Sat, Jul 15, 2006 at 05:59:32PM +0200, Markus Neteler wrote: >> I suggest to submit fixes first to HEAD, then enhancements. >> I will pick the fixes and merge them into the branch. >> The commit log message should be clear in this regard to >> that I understand which change to apply and which not. >> >> Maybe you could do fixes first? I can take care of the merge >> then. > > it is probably already clear, but could you permit for some > days before adding new features (if available)? I would > like to see that people try again gis.m for the fixes before > I merge them into the branch for beta2. > > thanks > > Markus From michael.barton at asu.edu Mon Jul 17 20:17:08 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Jul 17 20:17:33 2006 Subject: [GRASS-dev] nviz broken on G5 iMac Message-ID: I just compiled a cvs version I updated a few minutes ago, and nviz bombed. The rest of GRASS runs OK. I tried to start nviz just to see what is happening. It started the OSX tcltk aqua and then crashed. I?m using a G5 iMac (not Intel) with OS X 10.4.7. I?m putting the compiler errors below. Problems both with OGSF and NVIZ. 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 ======================= Errors in: /Users/cmbarton/grass_dev/grass6/lib/ogsf anthgradpc7:~/grass_dev/grass6/lib/ogsf cmbarton$ makegcc -I/Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include -I/usr/local/grasslib/include -g -O2 -I/usr/local/grasslib/include -fno-common -DPACKAGE=\""grasslibs"\" -I/usr/local/grasslib/include -I/usr/X11R6/include -DPACKAGE=\""grasslibs"\" -I/usr/X11R6/include -I/usr/local/grasslib/include -I/Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include \ -o OBJ.powerpc-apple-darwin8.7.0/GS2.o -c GS2.cIn file included from /Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include/gras s/gstypes.h:340, from GS2.c:30:/Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/inc lude/grass/ogsf_proto.h:200: warning: parameter names (without types) in function declaration/Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/i nclude/grass/ogsf_proto.h:201: error: parse error before 'GLuint'/Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/incl ude/grass/ogsf_proto.h:458: error: parse error before 'gsd_set_font'/Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7. 0/include/grass/ogsf_proto.h:458: warning: data definition has no type or storage class /Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include/gras s/ogsf_proto.h:461: error: parse error before 'float' /Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include/gras s/ogsf_proto.h:474: error: parse error before 'GLuint' /Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include/gras s/ogsf_proto.h:494: error: parse error before 'GLuint' /Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include/gras s/ogsf_proto.h:555: error: parse error before 'int' /Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include/gras s/ogsf_proto.h:747: error: parse error before 'gsd_put_legend' /Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include/gras s/ogsf_proto.h:747: error: parse error before 'GLuint' /Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include/gras s/ogsf_proto.h:747: warning: data definition has no type or storage class /Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include/gras s/ogsf_proto.h:748: warning: parameter names (without types) in function declaration GS2.c:47: error: parse error before '*' token GS2.c: In function 'GS_set_Narrow': GS2.c:436: error: 'GLdouble' undeclared (first use in this function) GS2.c:436: error: (Each undeclared identifier is reported only once GS2.c:436: error: for each function it appears in.) GS2.c:436: error: parse error before 'modelMatrix' GS2.c:437: error: 'GLint' undeclared (first use in this function) GS2.c:458: error: 'GL_MODELVIEW_MATRIX' undeclared (first use in this function) GS2.c:458: error: 'modelMatrix' undeclared (first use in this function) GS2.c:459: error: 'GL_PROJECTION_MATRIX' undeclared (first use in this function) GS2.c:459: error: 'projMatrix' undeclared (first use in this function) GS2.c:460: error: 'GL_VIEWPORT' undeclared (first use in this function) GS2.c:460: error: 'viewport' undeclared (first use in this function) GS2.c:463: error: parse error before 'out_near' GS2.c:469: error: parse error before 'pt' GS2.c:472: error: parse error before 'pt' GS2.c:478: error: 'factor' undeclared (first use in this function) GS2.c:478: error: 'out_near' undeclared (first use in this function) GS2.c:478: error: 'out_far' undeclared (first use in this function) GS2.c:480: error: 'out' undeclared (first use in this function) GS2.c: At top level: GS2.c:673: error: parse error before 'GLuint' GS2.c: In function 'GS_draw_legend': GS2.c:680: error: 'name' undeclared (first use in this function) GS2.c:680: error: 'fontbase' undeclared (first use in this function) GS2.c:680: error: 'size' undeclared (first use in this function) GS2.c:680: error: 'flags' undeclared (first use in this function) GS2.c:680: error: 'range' undeclared (first use in this function) GS2.c:680: error: 'pt' undeclared (first use in this function) GS2.c: At top level: GS2.c:686: error: parse error before 'list_id' GS2.c: In function 'GS_draw_list': GS2.c:692: error: 'list_id' undeclared (first use in this function) GS2.c: At top level: GS2.c:710: error: parse error before 'list_id' GS2.c: In function 'GS_delete_list': GS2.c:713: error: 'list_id' undeclared (first use in this function) GS2.c: In function 'GS_zoom_setup': GS2.c:2400: error: 'GLint' undeclared (first use in this function) GS2.c:2400: error: parse error before 'tmp' GS2.c:2402: error: 'tmp' undeclared (first use in this function) GS2.c:2402: error: 'num' undeclared (first use in this function) GS2.c: In function 'GS_init_view': GS2.c:2806: error: 'GL_MODELVIEW' undeclared (first use in this function) GS2.c:2826: error: 'GL_DEPTH_TEST' undeclared (first use in this function) GS2.c:2827: error: 'GL_LEQUAL' undeclared (first use in this function) GS2.c: In function 'GS_clear': GS2.c:2887: error: 'GL_DEPTH_BUFFER_BIT' undeclared (first use in this function) GS2.c:2887: error: 'GL_COLOR_BUFFER_BIT' undeclared (first use in this function) GS2.c: In function 'GS_get_aspect': GS2.c:2900: error: 'GLint' undeclared (first use in this function) GS2.c:2900: error: parse error before 'tmp' GS2.c:2912: error: 'GL_VIEWPORT' undeclared (first use in this function) GS2.c:2912: error: 'tmp' undeclared (first use in this function) make: *** [OBJ.powerpc-apple-darwin8.7.0/GS2.o] Error 1 ==================== Errors in: /Users/cmbarton/grass_dev/grass6/visualization/nviz anthgradpc7:~/grass_dev/grass6/visualization/nviz cmbarton$ make cd src ; make gcc -I/Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include -I/usr/local/grasslib/include -g -O2 -I/usr/local/grasslib/include -I/usr/local/grasslib/include -I/usr/local/grasslib/include -I/Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include -I/usr/local/grasslib/include -I/usr/local/grasslib/include -DPACKAGE=\""grassmods"\" -I/Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include \ -o OBJ.powerpc-apple-darwin8.7.0/nvizAppInit.o -c nvizAppInit.c In file included from togl.h:16, from nvizAppInit.c:8: togl_ws.h:14:3: error: #error None of OPENGL_X11, OPENGL_AQUA or OPENGL_WINDOWS defined In file included from nvizAppInit.c:8: togl.h:53:23: error: GL/gl.h: No such file or directory In file included from nvizAppInit.c:8: togl.h:165: error: parse error before 'Togl_LoadBitmapFont' togl.h:165: warning: data definition has no type or storage class togl.h:166: error: parse error before 'GLuint' togl.h:215: error: parse error before 'left' In file included from /Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include/gras s/gstypes.h:340, from interface.h:23, from nvizAppInit.c:9: /Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include/gras s/ogsf_proto.h:200: warning: parameter names (without types) in function declaration /Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include/gras s/ogsf_proto.h:201: error: parse error before 'GLuint' /Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include/gras s/ogsf_proto.h:458: error: parse error before 'gsd_set_font' /Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include/gras s/ogsf_proto.h:458: warning: data definition has no type or storage class /Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include/gras s/ogsf_proto.h:461: error: parse error before 'float' /Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include/gras s/ogsf_proto.h:474: error: parse error before 'GLuint' /Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include/gras s/ogsf_proto.h:494: error: parse error before 'GLuint' /Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include/gras s/ogsf_proto.h:555: error: parse error before 'int' /Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include/gras s/ogsf_proto.h:747: error: parse error before 'gsd_put_legend' /Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include/gras s/ogsf_proto.h:747: error: parse error before 'GLuint' /Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include/gras s/ogsf_proto.h:747: warning: data definition has no type or storage class /Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include/gras s/ogsf_proto.h:748: warning: parameter names (without types) in function declaration In file included from nvizAppInit.c:9: interface.h:67: error: parse error before 'FontBase' interface.h:67: warning: data definition has no type or storage class interface.h:280: error: parse error before 'load_font' interface.h:280: warning: data definition has no type or storage class make[1]: *** [OBJ.powerpc-apple-darwin8.7.0/nvizAppInit.o] Error 1 make: *** [nvwish] Error 2 ==================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060717/97b60bb9/attachment-0001.html From woklist at kyngchaos.com Mon Jul 17 21:27:17 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Jul 17 21:27:25 2006 Subject: [GRASS-dev] Re: nviz broken on G5 iMac In-Reply-To: References: Message-ID: <72A1854D-2D2E-425B-8DE0-8FC03B0F07E6@kyngchaos.com> On Jul 17, 2006, at 1:17 PM, Michael Barton wrote: > I just compiled a cvs version I updated a few minutes ago, and nviz > bombed. The rest of GRASS runs OK. I tried to start nviz just to > see what is happening. It started the OSX tcltk aqua and then crashed. > > I?m using a G5 iMac (not Intel) with OS X 10.4.7. > > I?m putting the compiler errors below. Problems both with OGSF and > NVIZ. > > 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 > > > ======================= > Errors in: > /Users/cmbarton/grass_dev/grass6/lib/ogsf > > anthgradpc7:~/grass_dev/grass6/lib/ogsf cmbarton$ makegcc -I/Users/ > cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include -I/ > usr/local/grasslib/include -g -O2 -I/usr/local/grasslib/include - > fno-common -DPACKAGE=\""grasslibs"\" -I/usr/local/grasslib/ > include -I/usr/X11R6/include -DPACKAGE=\""grasslibs"\" -I/usr/ > X11R6/include -I/usr/local/grasslib/include -I/Users/cmbarton/ > grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include \ -o > OBJ.powerpc-apple-darwin8.7.0/GS2.o -c GS2.cIn file included from / > Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/ > include/grass/gstypes.h:340, from GS2.c:30:/Users/ > cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include/ > grass/ogsf_proto.h:200: warning: parameter names (without types) in > function declaration/Users/cmbarton/grass_dev/grass6/dist.powerpc- > apple-darwin8.7.0/include/grass/ogsf_proto.h:201: error: parse > error before 'GLuint'/Users/cmbarton/grass_dev/grass6/dist.powerpc- > apple-darwin8.7.0/include/grass/ogsf_proto.h:458: error: parse > error before 'gsd_set_font'/Users/cmbarton/grass_dev/grass6/ > dist.powerpc-apple-darwin8.7.0/include/grass/ogsf_proto.h:458: > warning: data definition has no type or storage class I haven't had this problem with a Tcltk aqua build. Maybe something to do with the next one, since the OpenGL headers won't be included without any OPENGL_* defined. > Errors in: > /Users/cmbarton/grass_dev/grass6/visualization/nviz > > anthgradpc7:~/grass_dev/grass6/visualization/nviz cmbarton$ make > cd src ; make > gcc -I/Users/cmbarton/grass_dev/grass6/dist.powerpc-apple- > darwin8.7.0/include -I/usr/local/grasslib/include -g -O2 -I/usr/ > local/grasslib/include -I/usr/local/grasslib/include -I/usr/local/ > grasslib/include -I/Users/cmbarton/grass_dev/grass6/dist.powerpc- > apple-darwin8.7.0/include -I/usr/local/grasslib/include -I/usr/ > local/grasslib/include -DPACKAGE=\""grassmods"\" -I/Users/ > cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include \ > -o OBJ.powerpc-apple-darwin8.7.0/nvizAppInit.o -c > nvizAppInit.c > In file included from togl.h:16, > from nvizAppInit.c:8: > togl_ws.h:14:3: error: #error None of OPENGL_X11, OPENGL_AQUA or > OPENGL_WINDOWS defined > How did you configure GRASS for the Aqua Tcl/Tk? There is the new -- with-opengl=aqua option which you should use in place of manually setting include and lib dirs (--with-opengl-includes=, --with-opengl- libs=). This will set the correct OPENGL_* define. Though it's supposed to default to OPENGL_X11. I started writing an email for the list to describe the new options, but got distracted. Did you build your own Tcl/Tk Aqua, or use my package, or the old Tcl/ Tk Aqua, or Apple's from Tiger? ----- William Kyngesburye http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy From michael.barton at asu.edu Mon Jul 17 21:44:55 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Jul 17 21:44:58 2006 Subject: [GRASS-dev] Re: nviz broken on G5 iMac In-Reply-To: <72A1854D-2D2E-425B-8DE0-8FC03B0F07E6@kyngchaos.com> Message-ID: William, I had some other 'funny' performance, so I did a make clean and recompiled. Now everything compiles fine...but nviz still doesn't work. Here is what happens when I try to run it. GRASS 6.1.cvs (spearfish60_test):~ > nviz elevation=elevation_dem Loading Data Update elev null mask Loading Data translating colors Segmentation fault I've tried running it using x11 and aqua tcl both, with and without -q, from the GUI and the command line. Same result. 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, 17 Jul 2006 14:27:17 -0500 > To: > Cc: Michael Barton > Subject: Re: nviz broken on G5 iMac > > On Jul 17, 2006, at 1:17 PM, Michael Barton wrote: > >> I just compiled a cvs version I updated a few minutes ago, and nviz >> bombed. The rest of GRASS runs OK. I tried to start nviz just to >> see what is happening. It started the OSX tcltk aqua and then crashed. >> >> I?m using a G5 iMac (not Intel) with OS X 10.4.7. >> >> I?m putting the compiler errors below. Problems both with OGSF and >> NVIZ. >> >> 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 >> >> >> ======================= >> Errors in: >> /Users/cmbarton/grass_dev/grass6/lib/ogsf >> >> anthgradpc7:~/grass_dev/grass6/lib/ogsf cmbarton$ makegcc -I/Users/ >> cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include -I/ >> usr/local/grasslib/include -g -O2 -I/usr/local/grasslib/include - >> fno-common -DPACKAGE=\""grasslibs"\" -I/usr/local/grasslib/ >> include -I/usr/X11R6/include -DPACKAGE=\""grasslibs"\" -I/usr/ >> X11R6/include -I/usr/local/grasslib/include -I/Users/cmbarton/ >> grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include \ -o >> OBJ.powerpc-apple-darwin8.7.0/GS2.o -c GS2.cIn file included from / >> Users/cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/ >> include/grass/gstypes.h:340, from GS2.c:30:/Users/ >> cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include/ >> grass/ogsf_proto.h:200: warning: parameter names (without types) in >> function declaration/Users/cmbarton/grass_dev/grass6/dist.powerpc- >> apple-darwin8.7.0/include/grass/ogsf_proto.h:201: error: parse >> error before 'GLuint'/Users/cmbarton/grass_dev/grass6/dist.powerpc- >> apple-darwin8.7.0/include/grass/ogsf_proto.h:458: error: parse >> error before 'gsd_set_font'/Users/cmbarton/grass_dev/grass6/ >> dist.powerpc-apple-darwin8.7.0/include/grass/ogsf_proto.h:458: >> warning: data definition has no type or storage class > > I haven't had this problem with a Tcltk aqua build. Maybe something > to do with the next one, since the OpenGL headers won't be included > without any OPENGL_* defined. > >> Errors in: >> /Users/cmbarton/grass_dev/grass6/visualization/nviz >> >> anthgradpc7:~/grass_dev/grass6/visualization/nviz cmbarton$ make >> cd src ; make >> gcc -I/Users/cmbarton/grass_dev/grass6/dist.powerpc-apple- >> darwin8.7.0/include -I/usr/local/grasslib/include -g -O2 -I/usr/ >> local/grasslib/include -I/usr/local/grasslib/include -I/usr/local/ >> grasslib/include -I/Users/cmbarton/grass_dev/grass6/dist.powerpc- >> apple-darwin8.7.0/include -I/usr/local/grasslib/include -I/usr/ >> local/grasslib/include -DPACKAGE=\""grassmods"\" -I/Users/ >> cmbarton/grass_dev/grass6/dist.powerpc-apple-darwin8.7.0/include \ >> -o OBJ.powerpc-apple-darwin8.7.0/nvizAppInit.o -c >> nvizAppInit.c >> In file included from togl.h:16, >> from nvizAppInit.c:8: >> togl_ws.h:14:3: error: #error None of OPENGL_X11, OPENGL_AQUA or >> OPENGL_WINDOWS defined >> > How did you configure GRASS for the Aqua Tcl/Tk? There is the new -- > with-opengl=aqua option which you should use in place of manually > setting include and lib dirs (--with-opengl-includes=, --with-opengl- > libs=). This will set the correct OPENGL_* define. Though it's > supposed to default to OPENGL_X11. > > I started writing an email for the list to describe the new options, > but got distracted. > > Did you build your own Tcl/Tk Aqua, or use my package, or the old Tcl/ > Tk Aqua, or Apple's from Tiger? > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > First Pogril: Why is life like sticking your head in a bucket filled > with hyena offal? > Second Pogril: I don't know. Why IS life like sticking your head in > a bucket filled with hyena offal? > First Pogril: I don't know either. Wretched, isn't it? > > -HitchHiker's Guide to the Galaxy > From michael.barton at asu.edu Mon Jul 17 21:56:50 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Jul 17 21:56:53 2006 Subject: [GRASS-dev] Using current grass gui.tcl in python programs. In-Reply-To: <20060716164107.GC24993@bartok.itc.it> Message-ID: Someone (I thought it was you) added a new "wxPython" directory to gui. Inside is "grassgui.py" which looks like a wxPython version of gui.tcl. 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: Markus Neteler > Date: Sun, 16 Jul 2006 18:41:07 +0200 > To: > Subject: Re: [GRASS-dev] Using current grass gui.tcl in python programs. > > On Sun, Jul 16, 2006 at 09:34:32AM -0700, Michael Barton wrote: >> I guess I didn't phrase my question correctly. Sorry. Since all GRASS >> distributions already have TclTk installed, is there any advantage to >> redoing gui.tcl to work in a Tkinter environment for Python testing >> purposes? Or are we better off building on the python gui module that Markus >> put into the cvs? > > To add confusion :-) I didn't put a python gui module into the cvs... > I uploaded the Python-SWIG code which is intended to permit Pythonic access > to library functionality of GRASS (maybe also modules in future). > > Markus > > From woklist at kyngchaos.com Mon Jul 17 22:08:10 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Jul 17 22:08:14 2006 Subject: [GRASS-dev] Re: nviz broken on G5 iMac In-Reply-To: References: Message-ID: <13AB9B71-9C15-4087-97DA-E3EB9EAA34A1@kyngchaos.com> On Jul 17, 2006, at 2:44 PM, Michael Barton wrote: > > GRASS 6.1.cvs (spearfish60_test):~ > nviz elevation=elevation_dem > Loading Data > Update elev null mask > Loading Data > translating colors > Segmentation fault > That looks like the crash I get on Intel OSX. But NVIZ ran for me on PPC (and an iMac G5 at that). There should be a crashlog for NVIZ that will give you the thread details. Compare that to my crash in bug #4768 to make sure it's the same crash. Would it be possible for you to try my packages on your iMac (with your Tcl/Tk Aqua first, then mine if that doesn't work - it'll probably overwrite yours since it's a default framework install). If you built GRASS beta 1, my GRASS installer will overwrite that. ----- William Kyngesburye http://www.kyngchaos.com/ "Those people who most want to rule people are, ipso-facto, those least suited to do it." - A rule of the universe, from the HitchHiker's Guide to the Galaxy From woklist at kyngchaos.com Mon Jul 17 22:08:14 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Jul 17 22:08:18 2006 Subject: [GRASS-dev] New OpenGL options to test for native Mac and Win NVIZ Message-ID: <3A39F00D-79E7-4DD1-A338-CE545F771E7E@kyngchaos.com> There are new build options to make a native X11-less NVIZ for Mac OS X and Windows. Mac OS X is the only one tested so far It's been tested a little on a PPC Mac, both Tiger and Panther, and NVIZ works so far. I also tested on a MacBook, the Intel Mac with the Intel GMA integrated graphics chip, and it crashes. I don't have a 'Pro' MacBook or Intel iMac with 'real' ATI graphics hardware to test on. The only option needed to set the OpenGL platform is --with-opengl. By default it uses X11, or GLX-based, OpenGL, so it doesn't break old habits. --with-opengl=aqua, or agl, uses Mac OS X's AGL interface to OpenGL, for a native Aqua NVIZ (and ogsf library). OpenGL include and lib options do not need to be specified for AGL, and will be ignored, they're all fixed on Mac OS X. --with-opengl=windows, or wgl, uses Windows' WGL interface to OpenGL. X11 can still be used for the XDRIVER, alongside AGL. NVIZ will not interact with X11. So, --with-x11 --with-opengl=aqua, will give you both a Mac NVIZ and an X11 d.mon to work with. And, gis.m (any Tcl scripts) will also use the Aqua Tcl. The Mac AGL build, for now, requires a separate Aqua framework build of Tcl/Tk, and NOT Apple's Tcl/Tk framework on Tiger - it's missing the required private headers. The old Tcl/Tk Aqua packages should work, but the Tcl/Tk build instructions are easy to follow for building your own for an up-to-date Tcl/Tk framework, or I have a Universal Tcl/Tk package on my site. So you don't have to muck around patching configure, you should add symlinks to the framework binaries in /usr/local/lib (my package takes care of this): sudo ln -s /Library/Frameworks/Tcl.framework/Tcl /usr/local/lib/ libtcl.dylib sudo ln -s /Library/Frameworks/Tk.framework/Tk /usr/local/lib/ libtk.dylib Then you would use this in configure: --with-tcltk-includes="/Library/Frameworks/Tcl.framework/Headers / Library/Frameworks/Tk.framework/Headers /Library/Frameworks/ Tk.framework/PrivateHeaders" --with-tcltk-libs=/usr/local/lib A framework TclTk option is in the works for GRASS configure. TESTING NEEDED: Try a windows openGL configuration. Try on Intel Mac with ATI graphics. ----- 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 Mon Jul 17 22:21:05 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Jul 17 22:21:09 2006 Subject: [GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init gis_set.tcl, 1.24, 1.25 In-Reply-To: <20060717173556.GB380@bartok.itc.it> Message-ID: Markus, I'm happy to see suggestions. Here is my rational for wording changes. Maybe there can be better wording than my quick fix. I'm trying to think of a user who knows something about GIS and is opening GRASS for the first time. Before she or he can do anything--even start the program--they have to choose a "database", "location", and "mapset". But what is a database? Of course everyone knows that a database is an attribute table or related set of attribute tables defined in a data dictionary. Except that's not what a GRASS database is. It is simply the directory/folder where "locations" are stored. But what is a location? Of course that is a place, maybe where your study area is located. But how do you select that? Except in GRASS, a "location" is really a folder with definitions of the projection (including 'geographic projections' like latlon), coordinate system, and optionally the extents defining a particular part of the world. More people would probably understand what we mean if we ask them to choose the projection/coordinate system than to choose a "location". Then you have to select a "mapset". But what is a mapset. In GRASS, that's where your GIS files are stored--which is what this hypothetical new user has really wanted to get at all along. Every time I try to explain how to start GRASS, I have to explain what a "database", "location", and "mapset" is before the person can even get started working with the program. Any GIS will have some jargon that a person will have to get through (e.g., 'theme' instead of layer). But it would be nice to not have to hit someone with GRASS-specific jargon before they even get the program opened. Of course you can press the help button, but many people would just like to start the program before doing anything else. So I was trying to build in some translations of GRASS jargon to help someone get started. I dropped "GIS Database" because it's not used much. But location and mapset are used a lot. Of course this made for some awkward phraseology, as you noticed. I really did mean "projection location" instead of project location. Maybe "Select an existing 'location' (projection/coordinate system) and GIS Mapset..."??? GIS Mapset doesn't sound too awkward to me. But maybe to others? Suggestions? 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: Markus Neteler > Date: Mon, 17 Jul 2006 19:35:56 +0200 > To: > Subject: [GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init gis_set.tcl, > 1.24, 1.25 > > Hi, > > a few questions: > > > On Mon, Jul 17, 2006 at 07:28:42PM +0200, grass@intevation.de wrote: >> Author: michael >> >> Update of /grassrepository/grass6/lib/init >> In directory doto:/tmp/cvs-serv30054 >> >> Modified Files: >> gis_set.tcl >> Log Message: >> update exec and eval exec statements to properly parse arguments >> >> Index: gis_set.tcl >> =================================================================== >> RCS file: /grassrepository/grass6/lib/init/gis_set.tcl,v >> retrieving revision 1.24 >> retrieving revision 1.25 >> diff -u -d -r1.24 -r1.25 >> --- gis_set.tcl 24 Jun 2006 19:33:59 -0000 1.24 >> +++ gis_set.tcl 17 Jul 2006 17:28:40 -0000 1.25 >> @@ -312,10 +312,10 @@ >> pack $introtitle -side top >> >> .frame0.intro.msg tag configure all -justify center >> - .frame0.intro.msg insert end [G_msg "Welcome to GRASS GIS Version >> $GRASSVERSION\n"] >> + .frame0.intro.msg insert end [G_msg "Welcome to GRASS GIS version >> $GRASSVERSION\n"] >> .frame0.intro.msg insert end [G_msg "The world's leading open source >> GIS\n\n"] >> - .frame0.intro.msg insert end [G_msg "Select an existing project location >> and mapset\n"] >> - .frame0.intro.msg insert end [G_msg "or define a new project >> location\n"] >> + .frame0.intro.msg insert end [G_msg "Select an existing projection >> location and GIS mapset\n"] > > ... what does "existing projection location" mean? > I only know "existing project location". The change adds confusion in my > opinion. > If projected is meant, it is not right since latlong (usually) and xy (always) > are > unprojected. > > > >> + .frame0.intro.msg insert end [G_msg "or define a new projection >> location\n"] > > ...also here. > >> .frame0.intro.msg tag add all 1.0 end >> .frame0.intro.msg configure -state disabled >> >> @@ -338,7 +338,7 @@ >> label .frame0.frameDB.left.label \ >> -anchor {n} \ >> -justify right \ >> - -text [G_msg "Path to location: \n(GRASS Database)"] >> + -text [G_msg "Path to location : "] > > "GRASS Database" is a widely used term in the GRASS literature, > but sure if it should be removed. > > >> entry .frame0.frameDB.mid.entry \ >> -relief {sunken} \ >> @@ -408,7 +408,7 @@ >> >> label .frame0.frameMS.label \ >> -anchor {w} \ >> - -text [G_msg "Accessible Mapsets"] >> + -text [G_msg "(Accessible) GIS Mapsets"] > > ... this re-reverted the last fix... > The () do not add information in my opionion. > > >> listbox .frame0.frameMS.listbox \ >> -relief {sunken} \ >> @@ -460,7 +460,7 @@ >> >> label .frame0.frameNMS.first.label \ >> -anchor {n} \ >> - -text [G_msg "Create new mapset\nin selected location"] >> + -text [G_msg "Create new GIS mapset\nin currrent location"] > > I am also not sure of that. In the beginning nothing is selected, > so there is no currrent location. > >> entry .frame0.frameNMS.second.entry \ >> -relief {sunken} \ >> @@ -495,7 +495,7 @@ >> >> label .frame0.frameNMS.fourth.label \ >> -anchor {n} \ >> - -text [G_msg "\nDefine new location by:"] >> + -text [G_msg "Define new projection location"] > > ... again confusing (for me). > >> >> button .frame0.frameNMS.fifth.button \ >> > > It seems that this needs to be discussed again: at least I > would like to better understand most of the changes. > > thanks > > Markus > > From neteler at itc.it Mon Jul 17 22:43:15 2006 From: neteler at itc.it (Markus Neteler) Date: Mon Jul 17 22:43:16 2006 Subject: [GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init gis_set.tcl, 1.24, 1.25 In-Reply-To: References: <20060717173556.GB380@bartok.itc.it> Message-ID: <20060717204314.GE380@bartok.itc.it> Michael, all, On Mon, Jul 17, 2006 at 01:21:05PM -0700, Michael Barton wrote: > Markus, > > I'm happy to see suggestions. Here is my rational for wording changes. Maybe > there can be better wording than my quick fix. > > I'm trying to think of a user who knows something about GIS and is opening > GRASS for the first time. Before she or he can do anything--even start the > program--they have to choose a "database", "location", and "mapset". > > But what is a database? Of course everyone knows that a database is an > attribute table or related set of attribute tables defined in a data > dictionary. Except that's not what a GRASS database is. It is simply the > directory/folder where "locations" are stored. > > But what is a location? Of course that is a place, maybe where your study > area is located. But how do you select that? Except in GRASS, a "location" > is really a folder with definitions of the projection (including 'geographic > projections' like latlon), coordinate system, and optionally the extents > defining a particular part of the world. More people would probably > understand what we mean if we ask them to choose the projection/coordinate > system than to choose a "location". I always understood (and also teach it like that) that a "location" is a project - but not a projection. "project location" would be even ok but "projection location" I don't really agree with. Sure, I am not a native speaker. > Then you have to select a "mapset". But what is a mapset. In GRASS, that's > where your GIS files are stored--which is what this hypothetical new user > has really wanted to get at all along. A mapset is a set of maps... > Every time I try to explain how to start GRASS, I have to explain what a > "database", "location", and "mapset" is before the person can even get > started working with the program. Right. But that's not so bad because people have to even know what's a projection to create a new location or explicitely create a non-projected location (xy, latlong). > Any GIS will have some jargon that a > person will have to get through (e.g., 'theme' instead of layer). But it > would be nice to not have to hit someone with GRASS-specific jargon before > they even get the program opened. Of course you can press the help button, > but many people would just like to start the program before doing anything > else. I don't think that GRASS is full of jargon. > So I was trying to build in some translations of GRASS jargon to help > someone get started. I dropped "GIS Database" because it's not used much. > But location and mapset are used a lot. Of course this made for some awkward > phraseology, as you noticed. I really did mean "projection location" > instead of project location. Yes, you have inverted my "project location" fix :-) > Maybe "Select an existing 'location' (projection/coordinate system) and GIS > Mapset..."??? > > GIS Mapset doesn't sound too awkward to me. But maybe to others? > > Suggestions? I just want to avoid that we break with the existing wealth of documentation and also a bit with tradition (we have many long term users who even took a while to switch to GRASS 5 or GRASS 6). It is already quite hard to keep presentations reasonably updated, but for tutorials (there are many) and books it is even worse. Well, let's hear the others. It's worth to get this discussed. Markus > > From: Markus Neteler > > Date: Mon, 17 Jul 2006 19:35:56 +0200 > > To: > > Subject: [GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init gis_set.tcl, > > 1.24, 1.25 > > > > Hi, > > > > a few questions: > > > > > > On Mon, Jul 17, 2006 at 07:28:42PM +0200, grass@intevation.de wrote: > >> Author: michael > >> > >> Update of /grassrepository/grass6/lib/init > >> In directory doto:/tmp/cvs-serv30054 > >> > >> Modified Files: > >> gis_set.tcl > >> Log Message: > >> update exec and eval exec statements to properly parse arguments > >> > >> Index: gis_set.tcl > >> =================================================================== > >> RCS file: /grassrepository/grass6/lib/init/gis_set.tcl,v > >> retrieving revision 1.24 > >> retrieving revision 1.25 > >> diff -u -d -r1.24 -r1.25 > >> --- gis_set.tcl 24 Jun 2006 19:33:59 -0000 1.24 > >> +++ gis_set.tcl 17 Jul 2006 17:28:40 -0000 1.25 > >> @@ -312,10 +312,10 @@ > >> pack $introtitle -side top > >> > >> .frame0.intro.msg tag configure all -justify center > >> - .frame0.intro.msg insert end [G_msg "Welcome to GRASS GIS Version > >> $GRASSVERSION\n"] > >> + .frame0.intro.msg insert end [G_msg "Welcome to GRASS GIS version > >> $GRASSVERSION\n"] > >> .frame0.intro.msg insert end [G_msg "The world's leading open source > >> GIS\n\n"] > >> - .frame0.intro.msg insert end [G_msg "Select an existing project location > >> and mapset\n"] > >> - .frame0.intro.msg insert end [G_msg "or define a new project > >> location\n"] > >> + .frame0.intro.msg insert end [G_msg "Select an existing projection > >> location and GIS mapset\n"] > > > > ... what does "existing projection location" mean? > > I only know "existing project location". The change adds confusion in my > > opinion. > > If projected is meant, it is not right since latlong (usually) and xy (always) > > are > > unprojected. > > > > > > > >> + .frame0.intro.msg insert end [G_msg "or define a new projection > >> location\n"] > > > > ...also here. > > > >> .frame0.intro.msg tag add all 1.0 end > >> .frame0.intro.msg configure -state disabled > >> > >> @@ -338,7 +338,7 @@ > >> label .frame0.frameDB.left.label \ > >> -anchor {n} \ > >> -justify right \ > >> - -text [G_msg "Path to location: \n(GRASS Database)"] > >> + -text [G_msg "Path to location : "] > > > > "GRASS Database" is a widely used term in the GRASS literature, > > but sure if it should be removed. > > > > > >> entry .frame0.frameDB.mid.entry \ > >> -relief {sunken} \ > >> @@ -408,7 +408,7 @@ > >> > >> label .frame0.frameMS.label \ > >> -anchor {w} \ > >> - -text [G_msg "Accessible Mapsets"] > >> + -text [G_msg "(Accessible) GIS Mapsets"] > > > > ... this re-reverted the last fix... > > The () do not add information in my opionion. > > > > > >> listbox .frame0.frameMS.listbox \ > >> -relief {sunken} \ > >> @@ -460,7 +460,7 @@ > >> > >> label .frame0.frameNMS.first.label \ > >> -anchor {n} \ > >> - -text [G_msg "Create new mapset\nin selected location"] > >> + -text [G_msg "Create new GIS mapset\nin currrent location"] > > > > I am also not sure of that. In the beginning nothing is selected, > > so there is no currrent location. > > > >> entry .frame0.frameNMS.second.entry \ > >> -relief {sunken} \ > >> @@ -495,7 +495,7 @@ > >> > >> label .frame0.frameNMS.fourth.label \ > >> -anchor {n} \ > >> - -text [G_msg "\nDefine new location by:"] > >> + -text [G_msg "Define new projection location"] > > > > ... again confusing (for me). > > > >> > >> button .frame0.frameNMS.fifth.button \ > >> > > > > It seems that this needs to be discussed again: at least I > > would like to better understand most of the changes. > > > > thanks > > > > Markus > > > > > -- Markus Neteler http://mpa.itc.it/markus/ ITC-irst - Centro per la Ricerca Scientifica e Tecnologica MPBA - Predictive Models for Biol. & Environ. Data Analysis Via Sommarive, 18 - 38050 Povo (Trento), Italy From grass-bugs at intevation.de Mon Jul 17 23:46:27 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Mon Jul 17 23:46:32 2006 Subject: [GRASS-dev] [bug #3990] (grass) r.topmodel, r.topidx: dead link to Fortran source code Message-ID: <20060717214627.D06B01006C7@lists.intevation.de> mneteler wrote (Mon, Jul 17 2006 17:33:14): > Maciek, > > would you mind to create CVS diffs of the necessary changes > and send them to me? This would speed up development and > fixing... See how to do that in SUBMITTING, (26). Markus, I'd love to but I don't know what the necessary changes are. In the bug report I'm asking this. On http://www.es.lancs.ac.uk/hfdg/freeware/hfdg_freeware_top.htm there are still 2 links: http://www.es.lancs.ac.uk/hfdg/freeware/downloads/top-win.zip http://www.es.lancs.ac.uk/hfdg/freeware/downloads/project.zip Neither provides TOPMODEL's source code. Anybody knows where to find it, so we can update t.topmoel and r.topidx manuals accordingly? Maciek P.S. CCing Wouter Buytaert who once said he could know something. -------------------------------------------- Managed by Request Tracker From woklist at kyngchaos.com Mon Jul 17 23:46:55 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Jul 17 23:47:00 2006 Subject: [GRASS-dev] New OpenGL options to test for native Mac and Win NVIZ In-Reply-To: <3A39F00D-79E7-4DD1-A338-CE545F771E7E@kyngchaos.com> References: <3A39F00D-79E7-4DD1-A338-CE545F771E7E@kyngchaos.com> Message-ID: <71C75C01-BCD6-4AC2-AF45-5887B5AD5BC2@kyngchaos.com> NOTE: I forgot some shell setup info here. While it may be obvious to change your GRASS_WISH and GRASS_TCLSH to the Tcl/Tk Aqua tclsh and wish, you also need to set osxaqua=1 in your shell environment for the Tcl scripts to use for a couple things. ie: add export osxaqua=1 to your .bash_profile ----- William Kyngesburye http://www.kyngchaos.com/ "I ache, therefore I am. Or in my case - I am, therefore I ache." - Marvin From hamish_nospam at yahoo.com Tue Jul 18 02:16:30 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jul 18 02:16:36 2006 Subject: [GRASS-dev] New OpenGL options to test for native Mac and Win NVIZ In-Reply-To: <71C75C01-BCD6-4AC2-AF45-5887B5AD5BC2@kyngchaos.com> References: <3A39F00D-79E7-4DD1-A338-CE545F771E7E@kyngchaos.com> <71C75C01-BCD6-4AC2-AF45-5887B5AD5BC2@kyngchaos.com> Message-ID: <20060718121630.3cdcb24f.hamish_nospam@yahoo.com> On Mon, 17 Jul 2006 16:46:55 -0500 William Kyngesburye wrote: > > NOTE: > > I forgot some shell setup info here. While it may be obvious to > change your GRASS_WISH and GRASS_TCLSH to the Tcl/Tk Aqua tclsh and > wish, you also need to set osxaqua=1 in your shell environment for > the Tcl scripts to use for a couple things. > > ie: add > > export osxaqua=1 > > to your .bash_profile or maybe better, to: ~/.grass6.bashrc or ~/.grass.cshrc ? Hamish From hamish_nospam at yahoo.com Tue Jul 18 02:28:15 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jul 18 02:29:20 2006 Subject: [GRASS-dev] Re: nviz broken on G5 iMac In-Reply-To: References: <72A1854D-2D2E-425B-8DE0-8FC03B0F07E6@kyngchaos.com> Message-ID: <20060718122815.2977bc76.hamish_nospam@yahoo.com> > GRASS 6.1.cvs (spearfish60_test):~ > nviz elevation=elevation_dem > Loading Data > Update elev null mask > Loading Data > translating colors > Segmentation fault tip: to get more NVIZ debug info, edit $GISBASE/etc/nviz2.2/scripts/nviz2.2_script and near the top of the file, change DEBUG to "1" #If set to 1 output debug statements global DEBUG set DEBUG 1 maybe it helps narrow down the problem. Hamish From hmitaso at unity.ncsu.edu Tue Jul 18 03:25:46 2006 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Tue Jul 18 03:26:34 2006 Subject: [GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init gis_set.tcl, 1.24, 1.25 In-Reply-To: References: Message-ID: On Jul 17, 2006, at 4:21 PM, Michael Barton wrote: > Markus, > > I'm happy to see suggestions. Here is my rational for wording > changes. Maybe > there can be better wording than my quick fix. > > I'm trying to think of a user who knows something about GIS and is > opening > GRASS for the first time. Before she or he can do anything--even > start the > program--they have to choose a "database", "location", and "mapset". > > But what is a database? Of course everyone knows that a database is an > attribute table or related set of attribute tables defined in a data > dictionary. Except that's not what a GRASS database is. It is > simply the > directory/folder where "locations" are stored. > > But what is a location? Of course that is a place, maybe where your > study > area is located. But how do you select that? Except in GRASS, a > "location" > is really a folder with definitions of the projection (including > 'geographic > projections' like latlon), coordinate system, and optionally the > extents > defining a particular part of the world. More people would probably > understand what we mean if we ask them to choose the projection/ > coordinate > system than to choose a "location". > > Then you have to select a "mapset". But what is a mapset. In GRASS, > that's > where your GIS files are stored--which is what this hypothetical > new user > has really wanted to get at all along. > > Every time I try to explain how to start GRASS, I have to explain > what a > "database", "location", and "mapset" is before the person can even get > started working with the program. Any GIS will have some jargon that a > person will have to get through (e.g., 'theme' instead of layer). > But it > would be nice to not have to hit someone with GRASS-specific jargon > before > they even get the program opened. Of course you can press the help > button, > but many people would just like to start the program before doing > anything > else. > > So I was trying to build in some translations of GRASS jargon to help > someone get started. I dropped "GIS Database" because it's not used > much. > But location and mapset are used a lot. Of course this made for > some awkward > phraseology, as you noticed. I really did mean "projection location" > instead of project location. I have been using GRASS for too long for making any suggestion useful for new users (GIS database, location and mapset has always worked for me) but I found projection location very confusing for both old users and potentially for people who may be new to GRASS but know what projection means. I like project location (I found that people have a quick grasp of location when I describe it as a project and that you have to select a coordinate system for it) and mapset people usually get right away. I don't have an opinion about what to use instead of GIS database, I haven't seen people complaining about that either. > > Maybe "Select an existing 'location' (projection/coordinate system) > and GIS > Mapset..."??? there are additional buttons for selection of projection so "project location" sounds good enough for me > > GIS Mapset doesn't sound too awkward to me. But maybe to others? I think that Mapset is sufficient - there is already GIS in the title. > > Suggestions? I have written this answer before reading a response from Markus - I did not even think about the problems that would cause the change in the startup with documentation, tutorials, and description of modules etc. - Markus is right, we should stick with the terminology that we have unless there is a really compelling reason to change it - it is not too bad and I found that people get it pretty quickly (compared e.g. to the region management or the terminology used in other systems). Helena > > 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: Markus Neteler >> Date: Mon, 17 Jul 2006 19:35:56 +0200 >> To: >> Subject: [GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init >> gis_set.tcl, >> 1.24, 1.25 >> >> Hi, >> >> a few questions: >> >> >> On Mon, Jul 17, 2006 at 07:28:42PM +0200, grass@intevation.de wrote: >>> Author: michael >>> >>> Update of /grassrepository/grass6/lib/init >>> In directory doto:/tmp/cvs-serv30054 >>> >>> Modified Files: >>> gis_set.tcl >>> Log Message: >>> update exec and eval exec statements to properly parse arguments >>> >>> Index: gis_set.tcl >>> =================================================================== >>> RCS file: /grassrepository/grass6/lib/init/gis_set.tcl,v >>> retrieving revision 1.24 >>> retrieving revision 1.25 >>> diff -u -d -r1.24 -r1.25 >>> --- gis_set.tcl 24 Jun 2006 19:33:59 -0000 1.24 >>> +++ gis_set.tcl 17 Jul 2006 17:28:40 -0000 1.25 >>> @@ -312,10 +312,10 @@ >>> pack $introtitle -side top >>> >>> .frame0.intro.msg tag configure all -justify center >>> - .frame0.intro.msg insert end [G_msg "Welcome to GRASS GIS >>> Version >>> $GRASSVERSION\n"] >>> + .frame0.intro.msg insert end [G_msg "Welcome to GRASS GIS >>> version >>> $GRASSVERSION\n"] >>> .frame0.intro.msg insert end [G_msg "The world's leading >>> open source >>> GIS\n\n"] >>> - .frame0.intro.msg insert end [G_msg "Select an existing >>> project location >>> and mapset\n"] >>> - .frame0.intro.msg insert end [G_msg "or define a new project >>> location\n"] >>> + .frame0.intro.msg insert end [G_msg "Select an existing >>> projection >>> location and GIS mapset\n"] >> >> ... what does "existing projection location" mean? >> I only know "existing project location". The change adds confusion >> in my >> opinion. >> If projected is meant, it is not right since latlong (usually) and >> xy (always) >> are >> unprojected. >> >> >> >>> + .frame0.intro.msg insert end [G_msg "or define a new projection >>> location\n"] >> >> ...also here. >> >>> .frame0.intro.msg tag add all 1.0 end >>> .frame0.intro.msg configure -state disabled >>> >>> @@ -338,7 +338,7 @@ >>> label .frame0.frameDB.left.label \ >>> -anchor {n} \ >>> -justify right \ >>> - -text [G_msg "Path to location: \n(GRASS Database)"] >>> + -text [G_msg "Path to location : "] >> >> "GRASS Database" is a widely used term in the GRASS literature, >> but sure if it should be removed. >> >> >>> entry .frame0.frameDB.mid.entry \ >>> -relief {sunken} \ >>> @@ -408,7 +408,7 @@ >>> >>> label .frame0.frameMS.label \ >>> -anchor {w} \ >>> - -text [G_msg "Accessible Mapsets"] >>> + -text [G_msg "(Accessible) GIS Mapsets"] >> >> ... this re-reverted the last fix... >> The () do not add information in my opionion. >> >> >>> listbox .frame0.frameMS.listbox \ >>> -relief {sunken} \ >>> @@ -460,7 +460,7 @@ >>> >>> label .frame0.frameNMS.first.label \ >>> -anchor {n} \ >>> - -text [G_msg "Create new mapset\nin selected location"] >>> + -text [G_msg "Create new GIS mapset\nin currrent location"] >> >> I am also not sure of that. In the beginning nothing is selected, >> so there is no currrent location. >> >>> entry .frame0.frameNMS.second.entry \ >>> -relief {sunken} \ >>> @@ -495,7 +495,7 @@ >>> >>> label .frame0.frameNMS.fourth.label \ >>> -anchor {n} \ >>> - -text [G_msg "\nDefine new location by:"] >>> + -text [G_msg "Define new projection location"] >> >> ... again confusing (for me). >> >>> >>> button .frame0.frameNMS.fifth.button \ >>> >> >> It seems that this needs to be discussed again: at least I >> would like to better understand most of the changes. >> >> thanks >> >> Markus >> >> > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From rez at touchofmadness.com Tue Jul 18 03:42:21 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Tue Jul 18 03:42:27 2006 Subject: [GRASS-dev] PATCH: lib/db/dbmi_client/copy_tab.c Message-ID: <1153186941.22173.26.camel@devel> Here's a patch to copy_tab.c to checks to see if a table already exists before writing. Objections? -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 -------------- next part -------------- A non-text attachment was scrubbed... Name: copy_tab.c.pat Type: text/x-patch Size: 1873 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060717/c46f3e5a/copy_tab.c-0001.bin From michael.barton at asu.edu Tue Jul 18 05:26:09 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jul 18 05:26:16 2006 Subject: [GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init gis_set.tcl, 1.24, 1.25 In-Reply-To: Message-ID: My concern is not with the terminology per se. There is still a considerable lack of consistency in terminology from one GIS platform to another. GRASS terminology is a little obtuse, but not excessively so. The concepts are pretty straightforward once you learn them. My concern is that the way the startup works, a user must confront and understand GRASS-specific terms--ones used in no other GIS--before he or she can even start the program. People I introduce to GRASS always find that a big stumbling block. This complaint about the startup has come across the user list regularly too. Maybe the best solution is to change the startup somehow. However, changing the way GRASS starts is much more involved than simply changing the language in the startup screen. For example, most new users I've talked with indeed take 'location' to mean project location--as it was originally intended I suspect. Then they are put off by the need to specify the extents and resolution of their location before the program will even start. But when I explain that they only REALLY need to specify the projection parameters (latlon; utm, datum, and zone; etc.), they have a much easier time of it. What really matters most in a location is projection information in the WIND and PROJ files, not the extents and resolution--which can be changed easily during a GRASS session. But this is not conveyed by the term "location" alone. Anyway, I was trying to respond to numerous comments about the startup being confusing to a new but knowledgeable user. The startup screen gives people their first impression of the program. So whatever goes there should encourage them to work with the software. I agree that what I stuck in the new screen should be improved, but also feel that some hand-holding to new users would be worthwhile. Cheers, 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, 17 Jul 2006 21:25:46 -0400 > To: Michael Barton > Cc: Markus Neteler , > Subject: Re: [GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init gis_set.tcl, > 1.24, 1.25 > > > On Jul 17, 2006, at 4:21 PM, Michael Barton wrote: > >> Markus, >> >> I'm happy to see suggestions. Here is my rational for wording >> changes. Maybe >> there can be better wording than my quick fix. >> >> I'm trying to think of a user who knows something about GIS and is >> opening >> GRASS for the first time. Before she or he can do anything--even >> start the >> program--they have to choose a "database", "location", and "mapset". >> >> But what is a database? Of course everyone knows that a database is an >> attribute table or related set of attribute tables defined in a data >> dictionary. Except that's not what a GRASS database is. It is >> simply the >> directory/folder where "locations" are stored. >> >> But what is a location? Of course that is a place, maybe where your >> study >> area is located. But how do you select that? Except in GRASS, a >> "location" >> is really a folder with definitions of the projection (including >> 'geographic >> projections' like latlon), coordinate system, and optionally the >> extents >> defining a particular part of the world. More people would probably >> understand what we mean if we ask them to choose the projection/ >> coordinate >> system than to choose a "location". >> >> Then you have to select a "mapset". But what is a mapset. In GRASS, >> that's >> where your GIS files are stored--which is what this hypothetical >> new user >> has really wanted to get at all along. >> >> Every time I try to explain how to start GRASS, I have to explain >> what a >> "database", "location", and "mapset" is before the person can even get >> started working with the program. Any GIS will have some jargon that a >> person will have to get through (e.g., 'theme' instead of layer). >> But it >> would be nice to not have to hit someone with GRASS-specific jargon >> before >> they even get the program opened. Of course you can press the help >> button, >> but many people would just like to start the program before doing >> anything >> else. >> >> So I was trying to build in some translations of GRASS jargon to help >> someone get started. I dropped "GIS Database" because it's not used >> much. >> But location and mapset are used a lot. Of course this made for >> some awkward >> phraseology, as you noticed. I really did mean "projection location" >> instead of project location. > > I have been using GRASS for too long for making any suggestion > useful for new users (GIS database, location and mapset has always > worked for me) > but I found projection location very confusing for both old users and > potentially for people who may be new to GRASS but know what > projection means. > > I like project location (I found that people have a quick grasp of > location > when I describe it as a project and that you have to select a > coordinate system for it) > and mapset people usually get right away. > I don't have an opinion about what to use instead of GIS database, I > haven't seen > people complaining about that either. >> >> Maybe "Select an existing 'location' (projection/coordinate system) >> and GIS >> Mapset..."??? > > there are additional buttons for selection of projection so "project > location" > sounds good enough for me >> >> GIS Mapset doesn't sound too awkward to me. But maybe to others? > > I think that Mapset is sufficient - there is already GIS in the title. >> >> Suggestions? > > I have written this answer before reading a response from Markus - I > did not even think > about the problems that would cause the change in the startup with > documentation, tutorials, > and description of modules etc. - Markus is right, we should > stick with the terminology that we have unless there is a really > compelling > reason to change it - it is not too bad and I found > that people get it pretty quickly (compared e.g. to the region > management or the terminology > used in other systems). > > Helena > > > >> >> 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: Markus Neteler >>> Date: Mon, 17 Jul 2006 19:35:56 +0200 >>> To: >>> Subject: [GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init >>> gis_set.tcl, >>> 1.24, 1.25 >>> >>> Hi, >>> >>> a few questions: >>> >>> >>> On Mon, Jul 17, 2006 at 07:28:42PM +0200, grass@intevation.de wrote: >>>> Author: michael >>>> >>>> Update of /grassrepository/grass6/lib/init >>>> In directory doto:/tmp/cvs-serv30054 >>>> >>>> Modified Files: >>>> gis_set.tcl >>>> Log Message: >>>> update exec and eval exec statements to properly parse arguments >>>> >>>> Index: gis_set.tcl >>>> =================================================================== >>>> RCS file: /grassrepository/grass6/lib/init/gis_set.tcl,v >>>> retrieving revision 1.24 >>>> retrieving revision 1.25 >>>> diff -u -d -r1.24 -r1.25 >>>> --- gis_set.tcl 24 Jun 2006 19:33:59 -0000 1.24 >>>> +++ gis_set.tcl 17 Jul 2006 17:28:40 -0000 1.25 >>>> @@ -312,10 +312,10 @@ >>>> pack $introtitle -side top >>>> >>>> .frame0.intro.msg tag configure all -justify center >>>> - .frame0.intro.msg insert end [G_msg "Welcome to GRASS GIS >>>> Version >>>> $GRASSVERSION\n"] >>>> + .frame0.intro.msg insert end [G_msg "Welcome to GRASS GIS >>>> version >>>> $GRASSVERSION\n"] >>>> .frame0.intro.msg insert end [G_msg "The world's leading >>>> open source >>>> GIS\n\n"] >>>> - .frame0.intro.msg insert end [G_msg "Select an existing >>>> project location >>>> and mapset\n"] >>>> - .frame0.intro.msg insert end [G_msg "or define a new project >>>> location\n"] >>>> + .frame0.intro.msg insert end [G_msg "Select an existing >>>> projection >>>> location and GIS mapset\n"] >>> >>> ... what does "existing projection location" mean? >>> I only know "existing project location". The change adds confusion >>> in my >>> opinion. >>> If projected is meant, it is not right since latlong (usually) and >>> xy (always) >>> are >>> unprojected. >>> >>> >>> >>>> + .frame0.intro.msg insert end [G_msg "or define a new projection >>>> location\n"] >>> >>> ...also here. >>> >>>> .frame0.intro.msg tag add all 1.0 end >>>> .frame0.intro.msg configure -state disabled >>>> >>>> @@ -338,7 +338,7 @@ >>>> label .frame0.frameDB.left.label \ >>>> -anchor {n} \ >>>> -justify right \ >>>> - -text [G_msg "Path to location: \n(GRASS Database)"] >>>> + -text [G_msg "Path to location : "] >>> >>> "GRASS Database" is a widely used term in the GRASS literature, >>> but sure if it should be removed. >>> >>> >>>> entry .frame0.frameDB.mid.entry \ >>>> -relief {sunken} \ >>>> @@ -408,7 +408,7 @@ >>>> >>>> label .frame0.frameMS.label \ >>>> -anchor {w} \ >>>> - -text [G_msg "Accessible Mapsets"] >>>> + -text [G_msg "(Accessible) GIS Mapsets"] >>> >>> ... this re-reverted the last fix... >>> The () do not add information in my opionion. >>> >>> >>>> listbox .frame0.frameMS.listbox \ >>>> -relief {sunken} \ >>>> @@ -460,7 +460,7 @@ >>>> >>>> label .frame0.frameNMS.first.label \ >>>> -anchor {n} \ >>>> - -text [G_msg "Create new mapset\nin selected location"] >>>> + -text [G_msg "Create new GIS mapset\nin currrent location"] >>> >>> I am also not sure of that. In the beginning nothing is selected, >>> so there is no currrent location. >>> >>>> entry .frame0.frameNMS.second.entry \ >>>> -relief {sunken} \ >>>> @@ -495,7 +495,7 @@ >>>> >>>> label .frame0.frameNMS.fourth.label \ >>>> -anchor {n} \ >>>> - -text [G_msg "\nDefine new location by:"] >>>> + -text [G_msg "Define new projection location"] >>> >>> ... again confusing (for me). >>> >>>> >>>> button .frame0.frameNMS.fifth.button \ >>>> >>> >>> It seems that this needs to be discussed again: at least I >>> would like to better understand most of the changes. >>> >>> thanks >>> >>> Markus >>> >>> >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev > From hamish_nospam at yahoo.com Tue Jul 18 05:18:20 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jul 18 05:47:17 2006 Subject: [GRASS-dev] r.proj, v.proj ignore overwrite Message-ID: <20060718151820.6e3b47fe.hamish_nospam@yahoo.com> This may have been mentioned a month ago? but I notice that v.proj (& r.proj?) ignores overwrite settings and overwrites a map without needing the --o flag set. Hamish From glynn at gclements.plus.com Tue Jul 18 09:05:21 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jul 18 09:05:25 2006 Subject: [GRASS-dev] New OpenGL options to test for native Mac and Win NVIZ In-Reply-To: <3A39F00D-79E7-4DD1-A338-CE545F771E7E@kyngchaos.com> References: <3A39F00D-79E7-4DD1-A338-CE545F771E7E@kyngchaos.com> Message-ID: <17596.34865.107738.772179@cerise.gclements.plus.com> William Kyngesburye wrote: > And, gis.m (any Tcl scripts) will also use the Aqua Tcl. gis.m is a pure Tcl/Tk application (rather than hybrid C & Tcl/Tk), so it will use the "wish" executable specified by $GRASS_WISH (or whichever one comes first in the path), regardless of which configure switches are used. > TESTING NEEDED: Try a windows openGL configuration. The native Windows NVIZ (using the standard Tcl/Tk distribution compiled from source) sort of works. However, exec commands hang, so the map browser currently doesn't work. I'm not entirely sure why; executing the same commands in a vanilla "wish" shell works fine. -- Glynn Clements From glynn at gclements.plus.com Tue Jul 18 09:07:49 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jul 18 09:07:51 2006 Subject: [GRASS-dev] r.proj, v.proj ignore overwrite In-Reply-To: <20060718151820.6e3b47fe.hamish_nospam@yahoo.com> References: <20060718151820.6e3b47fe.hamish_nospam@yahoo.com> Message-ID: <17596.35013.515113.967290@cerise.gclements.plus.com> Hamish wrote: > This may have been mentioned a month ago? but I notice that v.proj > (& r.proj?) ignores overwrite settings and overwrites a map without > needing the --o flag set. Neither of them have gisprompt settings for their options. -- Glynn Clements From mlennert at club.worldonline.be Tue Jul 18 09:15:23 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Jul 18 09:15:21 2006 Subject: [GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init gis_set.tcl, 1.24, 1.25 In-Reply-To: References: Message-ID: <44BC8A8B.9050404@club.worldonline.be> Michael Barton wrote: > Anyway, I was trying to respond to numerous comments about the startup being > confusing to a new but knowledgeable user. The startup screen gives people > their first impression of the program. So whatever goes there should > encourage them to work with the software. I agree that what I stuck in the > new screen should be improved, but also feel that some hand-holding to new > users would be worthwhile. I agree with Markus and Helena that the terminology should stay as it is. I actually don't think that it is the terminology that makes the start-up difficult for users, it is the fact that they actually have to think about projection and extent when many just want to open a file they received for which they know neither... What about keeping the original terms with some pop-up help at mouse-over explaining what the term means ? Moritz From glynn at gclements.plus.com Tue Jul 18 09:25:34 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jul 18 09:29:30 2006 Subject: [GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init gis_set.tcl, 1.24, 1.25 In-Reply-To: References: Message-ID: <17596.36078.597792.348341@cerise.gclements.plus.com> Michael Barton wrote: > My concern is not with the terminology per se. There is still a considerable > lack of consistency in terminology from one GIS platform to another. GRASS > terminology is a little obtuse, but not excessively so. The concepts are > pretty straightforward once you learn them. > > My concern is that the way the startup works, a user must confront and > understand GRASS-specific terms--ones used in no other GIS--before he or she > can even start the program. People I introduce to GRASS always find that a > big stumbling block. This complaint about the startup has come across the > user list regularly too. > > Maybe the best solution is to change the startup somehow. However, changing > the way GRASS starts is much more involved than simply changing the language > in the startup screen. > > For example, most new users I've talked with indeed take 'location' to mean > project location--as it was originally intended I suspect. Then they are put > off by the need to specify the extents and resolution of their location > before the program will even start. But when I explain that they only REALLY > need to specify the projection parameters (latlon; utm, datum, and zone; > etc.), they have a much easier time of it. What really matters most in a > location is projection information in the WIND and PROJ files, not the > extents and resolution--which can be changed easily during a GRASS session. > But this is not conveyed by the term "location" alone. > > Anyway, I was trying to respond to numerous comments about the startup being > confusing to a new but knowledgeable user. The startup screen gives people > their first impression of the program. So whatever goes there should > encourage them to work with the software. I agree that what I stuck in the > new screen should be improved, but also feel that some hand-holding to new > users would be worthwhile. I'm not so sure. I don't believe that GRASS will ever be the kind of package which can be used without reading any documentation, and I don't consider this to be a defect. A user isn't going to be able to do anything useful with GRASS without having first read some documentation, so it doesn't really matter whether they have to read the documentation before they get to the startup screen or afterwards. If a user is looking for a simple package which they can use without reading any documentation, it's probably better if they realise sooner rather than later that GRASS isn't such a package. E.g. if they aren't familiar with the notion of the current region, making the startup screen simpler is just going to trade "what do I type here?" queries for "why do I get a blank screen from d.rast?" queries. [And the latter are frequently answered with the (bogus) advice of: use "g.region rast=..." to move the region to the map, when they should be using r.region to move the map.] -- Glynn Clements From frankie at debian.org Tue Jul 18 12:50:21 2006 From: frankie at debian.org (Francesco Paolo Lovergine) Date: Tue Jul 18 12:52:00 2006 Subject: [GRASS-dev] Debian control file outdated In-Reply-To: <20060715200331.GB10074@localdomain> References: <20060715134620.GB9134@bartok.itc.it> <20060715200331.GB10074@localdomain> Message-ID: <20060718105021.GC4898@mithrandir> On Sat, Jul 15, 2006 at 10:03:32PM +0200, Jachym Cepicky wrote: > Hi, > On Sat, Jul 15, 2006 at 03:46:20PM +0200, Markus Neteler wrote: > > Hi, > > > > could a Debian power user please send diffs (or do that in CVS > > directly) to update the debian/control file? > > > > I still see tcltk 8.3 there, it should be probably > > tcltk >= 8.3. Other changes may be needed, too. > > > > Markus > > > > this way it works: > > > Build-depends: flex, bison, libreadline4-dev || libreadline5-dev, libncurses5-dev, lesstif2-dev, debhelper (>= 4.0.2), dpatch, libtiff4-dev, tcl8.4-dev, tk8.4-dev, fftw-dev, xlibmesa-gl-dev, xlibmesa-gl-dev, libfreetype6-dev, autoconf2.13, autotools-dev, libgdal1-dev || libgdal1-1.3.1-dev, proj (>= 4.4.7), libjpeg62-dev, libpng12-dev, postgresql-dev, unixodbc-dev, doxygen, fakeroot > Standards-Version: 3.6.1 > > jachym > We moved to svn recently. For what are debian concerns, we remove the whole debian/ contents from grass tarball. Anyway, svn export svn://svn.debian.org/svn/pkg-grass/packages/pkg-grass/debian is the right way to get current stable tree without svn stuff around. I'm not having currently time to maitain a 6.1 branch. but I hope to do that in an svn branch as soon as possible. -- Francesco P. Lovergine From hamish_nospam at yahoo.com Tue Jul 18 13:24:48 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jul 18 13:25:00 2006 Subject: [GRASS-dev] r.proj, v.proj ignore overwrite In-Reply-To: <17596.35013.515113.967290@cerise.gclements.plus.com> References: <20060718151820.6e3b47fe.hamish_nospam@yahoo.com> <17596.35013.515113.967290@cerise.gclements.plus.com> Message-ID: <20060718232448.3adb3adb.hamish_nospam@yahoo.com> > Hamish: > > This may have been mentioned a month ago? but I notice that v.proj > > (& r.proj?) ignores overwrite settings and overwrites a map without > > needing the --o flag set. Glynn: > Neither of them have gisprompt settings for their options. r.proj didn't, but v.proj does. v.proj uses G_define_standard_option(G_OPT_V_OUTPUT) which sets: Opt->gisprompt = "new,vector,vector"; You do get the "WARNING: file exists and will overwritten" message. (but by the time you read that you have already started writing, so no way out) ? Hamish From Thomas.Adams at noaa.gov Tue Jul 18 13:26:45 2006 From: Thomas.Adams at noaa.gov (Thomas Adams) Date: Tue Jul 18 13:26:54 2006 Subject: [GRASS-dev] [bug #3990] (grass) r.topmodel, r.topidx: dead link to Fortran source code In-Reply-To: <20060717214627.D06B01006C7@lists.intevation.de> References: <20060717214627.D06B01006C7@lists.intevation.de> Message-ID: <44BCC575.5030601@noaa.gov> Maciek, I have the original source code (written in F77), but as far as I can tell, it can not be found on any Univ. of Lancaster web site. If you need it I can send what I have. Regards, Tom Maciek Sieczka via RT wrote: > mneteler wrote (Mon, Jul 17 2006 17:33:14): > > >> Maciek, >> >> would you mind to create CVS diffs of the necessary changes >> and send them to me? This would speed up development and >> fixing... See how to do that in SUBMITTING, (26). >> > > Markus, > > I'd love to but I don't know what the necessary changes are. In the bug report > I'm asking this. > > On http://www.es.lancs.ac.uk/hfdg/freeware/hfdg_freeware_top.htm there are > still 2 links: > > http://www.es.lancs.ac.uk/hfdg/freeware/downloads/top-win.zip > http://www.es.lancs.ac.uk/hfdg/freeware/downloads/project.zip > > Neither provides TOPMODEL's source code. Anybody knows where to find it, so we > can update t.topmoel and r.topidx manuals accordingly? > > Maciek > > P.S. > CCing Wouter Buytaert who once said he could know something. > > > > -------------------------------------------- Managed by Request Tracker > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- Thomas E Adams National Weather Service Ohio River Forecast Center 1901 South State Route 134 Wilmington, OH 45177 EMAIL: thomas.adams@noaa.gov VOICE: 937-383-0528 FAX: 937-383-0033 From landa.martin at gmail.com Tue Jul 18 13:35:54 2006 From: landa.martin at gmail.com (Martin Landa) Date: Tue Jul 18 13:35:57 2006 Subject: [GRASS-dev] PATCH: lib/db/dbmi_client/copy_tab.c In-Reply-To: <1153186941.22173.26.camel@devel> References: <1153186941.22173.26.camel@devel> Message-ID: Hi Brad, After patching the file, I get segfault on my pc... GRASS 6.1.cvs (karlin):~ > db.copy from_table=martin.h1 to_t=martin.h1 WARNING: Table 'grass_karlin' already exists Segmentation fault So I have slightly modified your patch, see the attachment. I hope it helps... Best regards, Martin 2006/7/18, Brad Douglas : > Here's a patch to copy_tab.c to checks to see if a table already exists > before writing. Objections? > > > -- > 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 > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: copy_tab.c_v2.patch Type: application/octet-stream Size: 1988 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060718/cf183b95/copy_tab.c_v2.obj From tiemann at redhat.com Tue Jul 18 14:00:30 2006 From: tiemann at redhat.com (Michael Tiemann) Date: Tue Jul 18 14:02:29 2006 Subject: [GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init gis_set.tcl, 1.24, 1.25 In-Reply-To: <44BC8A8B.9050404@club.worldonline.be> References: <44BC8A8B.9050404@club.worldonline.be> Message-ID: <1153224030.4463.11.camel@localhost.localdomain> On Tue, 2006-07-18 at 09:15 +0200, Moritz Lennert wrote: > Michael Barton wrote: > > > Anyway, I was trying to respond to numerous comments about the startup being > > confusing to a new but knowledgeable user. The startup screen gives people > > their first impression of the program. So whatever goes there should > > encourage them to work with the software. I agree that what I stuck in the > > new screen should be improved, but also feel that some hand-holding to new > > users would be worthwhile. > > I agree with Markus and Helena that the terminology should stay as it is. > I actually don't think that it is the terminology that makes the > start-up difficult for users, it is the fact that they actually have to > think about projection and extent when many just want to open a file > they received for which they know neither... > > What about keeping the original terms with some pop-up help at > mouse-over explaining what the term means ? And/or some script-based help that can provide some guidance, such as "this looks like a GIS file associated with the US Census TIGER database. If this is correct, your projection is likely $PROJ and your extent is likely $EXTENT. Should I use those values?" Or, "this looks like a GIS file associated with a Magellan GPS device. If this is correct..." I believe that there are a few simple use cases--electronic versions of USGS maps, GPS reference data, etc--that cover literally millions of intelligent, but not sophisticated, users. These users don't necessarily need toolbar help in figuring out which band of LANDSAT data they want to overlay, but they do want to map demographic or geocache data, and it would be HUGE if GRASS made it as easy as possible to be successful in those two use cases. M M From jachym.cepicky at centrum.cz Tue Jul 18 14:03:39 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Tue Jul 18 14:05:30 2006 Subject: [GRASS-dev] PATCH: lib/db/dbmi_client/copy_tab.c In-Reply-To: References: <1153186941.22173.26.camel@devel> Message-ID: <20060718120338.GB15967@localdomain> Hi, martin, could you post you patches also to cvs? thanks jachym On Tue, Jul 18, 2006 at 01:35:54PM +0200, Martin Landa wrote: > Hi Brad, > > After patching the file, I get segfault on my pc... > > GRASS 6.1.cvs (karlin):~ > db.copy from_table=martin.h1 to_t=martin.h1 > WARNING: Table 'grass_karlin' already exists > Segmentation fault > > So I have slightly modified your patch, see the attachment. I hope it > helps... > > Best regards, Martin > > 2006/7/18, Brad Douglas : > >Here's a patch to copy_tab.c to checks to see if a table already exists > >before writing. Objections? > > > > > >-- > >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 > > > > > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc ----------------------------------------- OFFICE: GDF-Hannover Mengendamm 16d 30177 Hannover Germany e-mail: cepicky@gdf-hannover.de URL: http://gdf-hannover.de Tel.: +49 511-39088507 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060718/f0012988/attachment.bin From landa.martin at gmail.com Tue Jul 18 14:12:08 2006 From: landa.martin at gmail.com (Martin Landa) Date: Tue Jul 18 14:12:11 2006 Subject: [GRASS-dev] PATCH: lib/db/dbmi_client/copy_tab.c In-Reply-To: <20060718120338.GB15967@localdomain> References: <1153186941.22173.26.camel@devel> <20060718120338.GB15967@localdomain> Message-ID: Dear Jachym, I have not write access to CVS yet, on the other hand I think it is better to test it before committing to CVS... Best, Martin 2006/7/18, Jachym Cepicky : > Hi, > > martin, could you post you patches also to cvs? > > thanks > > jachym > > On Tue, Jul 18, 2006 at 01:35:54PM +0200, Martin Landa wrote: > > Hi Brad, > > > > After patching the file, I get segfault on my pc... > > > > GRASS 6.1.cvs (karlin):~ > db.copy from_table=martin.h1 to_t=martin.h1 > > WARNING: Table 'grass_karlin' already exists > > Segmentation fault > > > > So I have slightly modified your patch, see the attachment. I hope it > > helps... > > > > Best regards, Martin > > > > 2006/7/18, Brad Douglas : > > >Here's a patch to copy_tab.c to checks to see if a table already exists > > >before writing. Objections? > > > > > > > > >-- > > >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 > > > > > > > > > > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev > > -- > Jachym Cepicky > e-mail: jachym.cepicky@centrum.cz > URL: http://les-ejk.cz > GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc > ----------------------------------------- > OFFICE: > GDF-Hannover > Mengendamm 16d > 30177 Hannover > Germany > e-mail: cepicky@gdf-hannover.de > URL: http://gdf-hannover.de > Tel.: +49 511-39088507 > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (GNU/Linux) > > iD8DBQFEvM4ZyKt0uAjU4I8RAvLOAKC0Ec/gJOaWD06sr/zZbrURaWOU8wCgzleA > Rj8jtLKot+WELwQrtVb6rIY= > =BaAQ > -----END PGP SIGNATURE----- > > > From hamish_nospam at yahoo.com Tue Jul 18 14:29:29 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jul 18 14:29:44 2006 Subject: [GRASS-dev] [bug #3990] (grass) r.topmodel, r.topidx: dead link to Fortran source code In-Reply-To: <44BCC575.5030601@noaa.gov> References: <20060717214627.D06B01006C7@lists.intevation.de> <44BCC575.5030601@noaa.gov> Message-ID: <20060719002929.72d6f3d4.hamish_nospam@yahoo.com> Thomas Adams wrote: > I have the original source code (written in F77), but as far as I can > tell, it can not be found on any Univ. of Lancaster web site. If you > need it I can send what I have. FWIW, GRASS has built into the ./configure script checks for g2c and f2c, and the config summary lists the FORTRAN compiler used. I'm not sure if it is actually used for anything, but the infrastructure's there. Hamish From tiemann at redhat.com Tue Jul 18 14:29:03 2006 From: tiemann at redhat.com (Michael Tiemann) Date: Tue Jul 18 14:35:04 2006 Subject: [GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init gis_set.tcl, 1.24, 1.25 In-Reply-To: <17596.36078.597792.348341@cerise.gclements.plus.com> References: <17596.36078.597792.348341@cerise.gclements.plus.com> Message-ID: <1153225743.4463.37.camel@localhost.localdomain> Glynn, I appreciate tremendously all the great work you have been doing for GRASS, except on one point... On Tue, 2006-07-18 at 08:25 +0100, Glynn Clements wrote: > Michael Barton wrote: > > > My concern is not with the terminology per se. There is still a considerable > > lack of consistency in terminology from one GIS platform to another. GRASS > > terminology is a little obtuse, but not excessively so. The concepts are > > pretty straightforward once you learn them. I fundamentally agree with Michael here. > > My concern is that the way the startup works, a user must confront and > > understand GRASS-specific terms--ones used in no other GIS--before he or she > > can even start the program. People I introduce to GRASS always find that a > > big stumbling block. This complaint about the startup has come across the > > user list regularly too. I find this everywhere I travel, and even find myself stumbling on the problem. I don't use GRASS every day, but I want to be able to use it every now and again without feeling lost and baffled. When I use it for a weekend, I think to myself "hey, I've got it! Now I'm not going to forget it." Three months later, I've forgotten it. This is not only frustrating to me, but makes it very difficult for me to be a GRASS ambassador to other business people who would benefit tremendously from being able to map their business data and ideas to geographic reference points or regions. So here is where I disagree with you: > I'm not so sure. > > I don't believe that GRASS will ever be the kind of package which can > be used without reading any documentation, and I don't consider this > to be a defect. Would you be willing to maintain that opinion as part of a silent minority? > A user isn't going to be able to do anything useful with GRASS without > having first read some documentation, so it doesn't really matter > whether they have to read the documentation before they get to the > startup screen or afterwards. I know a lot of people who are far more motivated to read documentation when they have evidence that they really are this >< close to attacking their real problem. If they have to read a lot of documentation before getting a map loaded, it requires them to believe (1) they can find the map they need, (2) they can get it loaded, (3) they can do the analysis they want. That's a lot of doubt to carry while reading documentation. Here's an example. I have a theory that US democracy (as I define it) is weakened (as I define it) when US congressional districts are redrawn (as required by the US constitution) to be less, rather than more, convex (which is left to the courts and the incumbent representatives in charge of drawing the maps). To test this theory, I need to look at congressional district maps and find which ones are becoming less and less convex over time. I have no idea how to do this, but I can start attacking the problem by selecting stories I believe correlate to "stronger" or "weaker" democratic activity and attribute that to the relevant districts, then I can see whether such attribution shows a visual correlation. If I start to see a correlation, I can learn how to order districts based on convexity and then actively search for validating or repudiating evidence of the theory. To get going, I type into Google "us congressional district map" and two clicks later I'm at http://nationalatlas.gov/atlasftp.html#cgd109p . Now, with GRASS as it is, I'm pretty sure I have the right map somewhere, but I not at all sure I can begin my demographic analysis of democracy. I don't know if GRASS supports these formats. I don't know whether I can load these things correctly. I don't know what kind of processing I need to do to load or begin working on these maps. If GRASS lowered the barrier to all these issues, I'd be much more likely to engage the documentation to solve my problem at hand. As it is, I feel I need to do a lot of work, on an uncertain foundation, just to get to square one. I am sure that many people feel this way. > If a user is looking for a simple package which they can use without > reading any documentation, it's probably better if they realise sooner > rather than later that GRASS isn't such a package. I believe that GRASS /can/ be such a package, or can be the basis of such a package (such as QGIS). But don't if we keep convincing ourselves that GIS should be left to the experts. M From grass-bugs at intevation.de Tue Jul 18 14:38:02 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Tue Jul 18 14:38:04 2006 Subject: [GRASS-dev] [bug #4864] (grass) integer division errors Message-ID: <20060718123802.EDB141005C9@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4864 ------------------------------------------------------------------------- Subject: integer division errors Hi, I've just fixed a bug in the symbol library where: float_red = int_red / 255; int/int -> int, so the answer was always 0.0 or 1.0. no good. grep finds these ones too, maybe some are wrong, some are ok? display/d.his/his.c: R = R * I / 255; display/d.his/his.c: G = G * I / 255; display/d.his/his.c: B = B * I / 255; display/d.his/his.c: R = 127 + (R - 127) * S / 255 ; display/d.his/his.c: G = 127 + (G - 127) * S / 255 ; display/d.his/his.c: B = 127 + (B - 127) * S / 255 ; general/g.pnmcomp/main.c: *r = (*r * c0 + *p * c1) / 255; raster/r.his/his.c: R = R * I / 255; raster/r.his/his.c: G = G * I / 255; raster/r.his/his.c: B = B * I / 255; raster/r.his/his.c: R = 127 + (R - 127) * S / 255 ; raster/r.his/his.c: G = 127 + (G - 127) * S / 255 ; raster/r.his/his.c: B = 127 + (B - 127) * S / 255 ; raster/r.out.vtk/writeascii.c: fprintf(fp, "%lf %lf %lf \n", r / 255, g / 255, b / 255); raster3d/r3.out.vtk/writeVTKData.c: fprintf(fp, "%.*f ", dp, (value / 255)); raster3d/r3.out.vtk/writeVTKData.c: fprintf(fp, "%.*f ", dp, (value / 255)); raster/r.out.tiff/r.out.tiff.c:#define SCALE(x) (((x)*((1L<<16)-1))/255) raster3d/r3.showdspf/togif.c: val = (nshades*k)/255; Hamish -------------------------------------------- Managed by Request Tracker From hamish_nospam at yahoo.com Tue Jul 18 16:10:44 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jul 18 16:10:50 2006 Subject: [GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init gis_set.tcl, 1.24, 1.25 In-Reply-To: <20060717173556.GB380@bartok.itc.it> References: <20060717172842.F1D771006C7@lists.intevation.de> <20060717173556.GB380@bartok.itc.it> Message-ID: <20060719021044.17f0d7aa.hamish_nospam@yahoo.com> > ... what does "existing projection location" mean? my overspent 2c re. startup GUI wording: "database". This one should change in the GUI startup screen now that the vector engine talks to "real" databases. I like simple two words: "data path:" for the GUI's database needs. g.gisenv and internally can still use "database" without harm, although r.proj et