From glynn at gclements.plus.com Thu Jun 1 00:01:10 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jun 1 00:02:12 2006 Subject: [GRASS-dev] Maybe a bug? In-Reply-To: References: Message-ID: <17534.4646.606088.749076@cerise.gclements.plus.com> Michael Barton wrote: > Recently, I?ve found that when I close GRASS (6.1 cvs) on my Mac, it doesn?t > seem to exit some of the GRASS libraries. When I?ve tried to update my > binary version (and discard the old one), I?m getting errors that following > files are still in use, even after I?ve quite GRASS and x11. > > libgrass_gis.6.1.cvs.dylib > libgrass_driver.gis.6.1.cvs.dylib > libgrass_datetime.gis.6.1.cvs.dylib > monitorcap The fact that libgrass_driver is amongst them implies a display driver. Use "ps ax" to list the running processes, and kill anything which is left over from a GRASS session. I have no idea why monitorcap would be affected; it isn't a binary file. I don't know about MacOSX specifically, but Unix allows you to "delete" (i.e. unlink) files which are open; it just won't let you modify a file which is mapped for execution (i.e. executables or shared libraries). -- Glynn Clements From michael.barton at asu.edu Thu Jun 1 00:04:46 2006 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jun 1 00:04:57 2006 Subject: [GRASS-dev] Maybe a bug? In-Reply-To: <17534.4646.606088.749076@cerise.gclements.plus.com> Message-ID: On checking, I realized that a further file/process named "PNG" was also open. When I killed that, the others closed too. Is this the PNG driver that is somehow not getting closed? Why not when I shut down GRASS entirely? 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: Glynn Clements > Date: Wed, 31 May 2006 23:01:10 +0100 > To: Michael Barton > Cc: GRASS developers list > Subject: Re: [GRASS-dev] Maybe a bug? > > > Michael Barton wrote: > >> Recently, I?ve found that when I close GRASS (6.1 cvs) on my Mac, it doesn?t >> seem to exit some of the GRASS libraries. When I?ve tried to update my >> binary version (and discard the old one), I?m getting errors that following >> files are still in use, even after I?ve quite GRASS and x11. >> >> libgrass_gis.6.1.cvs.dylib >> libgrass_driver.gis.6.1.cvs.dylib >> libgrass_datetime.gis.6.1.cvs.dylib >> monitorcap > > The fact that libgrass_driver is amongst them implies a display > driver. Use "ps ax" to list the running processes, and kill anything > which is left over from a GRASS session. > > I have no idea why monitorcap would be affected; it isn't a binary > file. I don't know about MacOSX specifically, but Unix allows you to > "delete" (i.e. unlink) files which are open; it just won't let you > modify a file which is mapped for execution (i.e. executables or > shared libraries). > > -- > Glynn Clements From woklist at kyngchaos.com Thu Jun 1 03:04:43 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Thu Jun 1 03:04:50 2006 Subject: [GRASS-dev] NVIZ problem on Intel Macs In-Reply-To: References: Message-ID: <3CEF556A-7FFC-46DA-9623-E6A7008BCBEC@kyngchaos.com> That shouldn't be necessary - an Intel Mac has Intel builds of X11 and OpenGL. How did you build your Intel GRASS Lorenzo - on a PPC Mac with the Universal SDK? Or on an Intel Mac? I tried my build of GRASS CVS 5-27 (built on Intel). NVIZ starts for me - I get the NVIZ Options/Output screen. But when I select a raster and try to Run it, then it crashes, with nothing in the output window except the raster and the X icon to remove it, like so (sometimes the Please Wait window briefly appears): Command: nviz Path: /usr/local/grass-6.1.cvs/bin/nviz Parent: wish8.4 [612] Version: ??? (???) PID: 648 Thread: 0 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 0x000115ab Togl_CreateWindow + 56 3 com.tcltk.tklibrary 0x9ad191ad Tk_MakeWindowExist + 120 4 nviz 0x00012663 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 0x0000ca44 Ninit + 199 17 nviz 0x00002570 NVIZ_AppInit + 210 18 com.tcltk.tklibrary 0x9acef2eb Tk_MainEx + 761 19 nviz 0x0001118a main + 97 20 nviz 0x00002446 _start + 228 (crt.c:272) 21 nviz 0x00002361 start + 41 Still looks like some OpenGL problem. And, I get the exact same crash on my PowerBook, except that NVIZ processes the data a little - this appears in the output winodw below the raster names: Loading Data Update elev null mask Loading Data building color table and the raster names item has an additional printer icon. This is the first time I've run NVIZ, so I'm not sure what to expect, but certainly not a crash. On May 31, 2006, at 4:47 PM, Michael Barton wrote: > Lorenzo, > > See Glynn's response below. I'm wondering if perhaps you need to > install a > new version of x11?? Or maybe get a new version of OpenGL?? to go > with the > Intel Macs > > 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 > > ------ Forwarded Message >> From: Glynn Clements >> Date: Wed, 31 May 2006 22:44:12 +0100 >> To: Michael Barton >> Cc: GRASS developers list >> Subject: Re: [GRASS-dev] NVIZ problem on Intel Macs >> >> >> Michael Barton wrote: >> >>> Lorenzo Moretti is reporting that NVIZ locks up when it tries to >>> start on >>> the new Intel Macs. The error is listed below. Anyone have a >>> suggestion? Has >>> anyone else had a problem? Should this go to the bug list? We do >>> want to run >>> GRASS on the new Macs >> >>>>> X Error of failed request: BadRequest (invalid request code or >>>>> no such >>>>> operation) >>>>> Major opcode of failed request: 129 (Apple-DRI) >>>>> Minor opcode of failed request: 1 () >>>>> Serial number of failed request: 192 >> >> This indicates the OpenGL library isn't compatible with the X server. >> >> There isn't anything which we can do to fix this, although adding the >> "-indirect" switch to the "togl" commands in nviz2.2_script might >> eliminate the error at the expense of performance (indirect rendering >> doesn't use hardware acceleration on the stock X.org servers). >> >> -- >> Glynn Clements > ----- 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 glynn at gclements.plus.com Thu Jun 1 03:06:09 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jun 1 03:13:50 2006 Subject: FW: [GRASS-dev] NVIZ problem on Intel Macs In-Reply-To: References: <17534.3628.989943.861380@cerise.gclements.plus.com> Message-ID: <17534.15745.359196.849761@cerise.gclements.plus.com> Michael Barton wrote: > See Glynn's response below. I'm wondering if perhaps you need to install a > new version of x11?? Or maybe get a new version of OpenGL?? to go with the > Intel Macs If anything, you might need to use an older version. Apparently, GLX support on MacOSX has been broken since X11R6.9: http://lists.freedesktop.org/archives/xorg/2006-May/015716.html "Broken" in the sense of compile errors in the DRI code, so presumably any precompiled X servers for OSX which are newer than that will have DRI support disabled. Also, using: export LIBGL_ALWAYS_INDIRECT=1 may eliminate the error. -- Glynn Clements From glynn at gclements.plus.com Thu Jun 1 03:13:08 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jun 1 03:21:28 2006 Subject: [GRASS-dev] Maybe a bug? In-Reply-To: References: <17534.4646.606088.749076@cerise.gclements.plus.com> Message-ID: <17534.16164.23311.818737@cerise.gclements.plus.com> Michael Barton wrote: > On checking, I realized that a further file/process named "PNG" was also > open. When I killed that, the others closed too. Is this the PNG driver that > is somehow not getting closed? Yes. > Why not when I shut down GRASS entirely? The Init.sh script does the following on termination: # GRASS session finished tput clear echo "Closing monitors....." for MON in `d.mon -L | grep running | grep -v "not running" | sed 's/ .*//'` do echo d.mon stop=$MON d.mon stop=$MON done It's possible that the PNG driver gets omitted from the "for" loop, or that "d.mon stop=..." fails for some reason. It's hard to say which or why without more information. -- Glynn Clements From hamish_nospam at yahoo.com Thu Jun 1 06:14:31 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Jun 1 06:14:37 2006 Subject: [GRASS-dev] raster row alloc? Message-ID: <20060601161431.18b0effd.hamish_nospam@yahoo.com> Hi, I notice G_allocate_raster_buf() allocates G_window_cols() + 1. What's the +1 for? Is it just for good luck, is there a null terminator which inidcates EOL? or something else? I'd like to use G_set_null_value(array, nrows*ncols, map_type); to fill some nrows with NULL in one go instead of a loop over the number of rows, and perhaps G_raster_cpy() to copy a few lines over at a time. nrows*(ncols+1) ? ??? Hamish From hamish_nospam at yahoo.com Thu Jun 1 07:04:35 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Jun 1 07:04:43 2006 Subject: [GRASS-dev] Discussing new GUI toolkit: v.pydigit In-Reply-To: <20060531121906.GC19794@gdf-hannover.de> References: <20060530235842.GC16478@gdf-hannover.de> <20060531215617.41c2dd2d.hamish_nospam@yahoo.com> <20060531121906.GC19794@gdf-hannover.de> Message-ID: <20060601170435.69dd8587.hamish_nospam@yahoo.com> > > for raster option use r.in.poly or "v.in.*/v.edit" + v.to.rast? > > He? Do you mean, that v.pydigit could be used as r.digit? sure, why not? see the r.in.poly help page. The format is almost the same as v.in.ascii format=standard. v.digit and r.digit may as well be put in the same app. > > Same as gis.m? Use the PNG driver to make a PNG (smaller file) or > > PPM (faster) image. Zoom/pan by setting "soft" region changes with > > GRASS_REGION= enviro variable?? (then GUI must keep track) > > Currently: GRASS region settings are not touched. The whole point of $GRASS_REGION and $WIND_OVERRIDE is that you don't need to touch the region settings. The changes only exist in the current processes and don't persist. > The script reads them (g.region -g) and stores to self.region dictionary > (Vpydigit/vdigitGui.py). Everytime, it is zoomed/paned, this variable > is changed. > > I wanted to do it possible independent on the Xdriver - didn't we want > to get rid of it? the PNG[/PPM] driver is not dependant on the XDRIVER. Hamish From hamish_nospam at yahoo.com Thu Jun 1 07:05:24 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Jun 1 07:05:32 2006 Subject: [GRASS-dev] Discussing new GUI toolkit: v.pydigit In-Reply-To: <20060531121906.GC19794@gdf-hannover.de> References: <20060530235842.GC16478@gdf-hannover.de> <20060531215617.41c2dd2d.hamish_nospam@yahoo.com> <20060531121906.GC19794@gdf-hannover.de> Message-ID: <20060601170524.0c705c00.hamish_nospam@yahoo.com> > Personally I thing, that the Zoom->PPM->Display approach one of the > reasons is, why *some* people od not really like the new gis.m - it is > slow. Zoom->PPM->Display does not have to mean Zoom->PPM->Disk->Display Hamish From hamish_nospam at yahoo.com Thu Jun 1 07:10:28 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Jun 1 07:10:33 2006 Subject: [GRASS-dev] Discussing new GUI toolkit: v.pydigit In-Reply-To: <165AA021-B70E-4621-9347-46BC9ADD948F@kyngchaos.com> References: <20060530235842.GC16478@gdf-hannover.de> <20060531215617.41c2dd2d.hamish_nospam@yahoo.com> <20060531121906.GC19794@gdf-hannover.de> <165AA021-B70E-4621-9347-46BC9ADD948F@kyngchaos.com> Message-ID: <20060601171028.4509e7fc.hamish_nospam@yahoo.com> > I wonder - does it (python I assume you mean here) get button-click > info from the system, or interpret mouse/trackpad directly? A > feature of recent PowerBooks, and the new MacBook I'm lovin', is (if > one uses the pad-tap feature) tapping with *two* fingers does a right- > > click. If Python sees it as left/right click, you wouldn't have to > worry about trying to interpret meta-keys as well. Same goes for > ctrl-click - it's a standard setup for the system to do a right-click > > - if Python sees this as right-click instead of ctrl-click, it > wouldn't have to deal with having to have alternatives for extra > buttons on a Mac. There's nothing for a middle-click, so we're only > down to two buttons, not one. > > There are also drivers available to do similar things for older > PowerBooks. AFAIR, ctrl-click and apple-click on the mac were translated to middle/right click somewhere in the system before X11. (but it doesn't always work right in some X applications) Play with "xev" to test? Hamish From hamish_nospam at yahoo.com Thu Jun 1 07:20:01 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Jun 1 07:20:08 2006 Subject: [GRASS-dev] [bug #4524] (grass) v.clean, v.patch (else?): output to stderr instead of stdout... In-Reply-To: References: <20060530185709.4E5D51006AD@lists.intevation.de> <20060531152236.1d10b389.hamish_nospam@yahoo.com> Message-ID: <20060601172001.3d8e2f1c.hamish_nospam@yahoo.com> > Hi, just a short note - in case of v.patch, fprintf (stderr, ...) -> > G_message () [1]. .. http://freegis.org/cgi-bin/viewcvs.cgi/grass6/vector/v.patch/main.c.diff?r1=1.11&r2=1.12 It appears that I am behind the times. Sorry. new content: G_done_msg() should check a GRASS_{VERBOSE|QUIET} enviro var, as well as G_message() and G_percent(). Hamish From hamish_nospam at yahoo.com Thu Jun 1 07:22:29 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Jun 1 07:23:18 2006 Subject: [GRASS-dev] NVIZ problem on Intel Macs In-Reply-To: References: Message-ID: <20060601172229.4667c7b1.hamish_nospam@yahoo.com> > Nviz shows the translating message in the terminal, rises until 99% > and then shows this message: FYI never getting to 100% probably is just a missing G_percent() call after the loop is done. Several modules fail to do this (r.terraflow e.g.). Hamish From hamish_nospam at yahoo.com Thu Jun 1 07:26:22 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Jun 1 07:26:47 2006 Subject: [GRASS-dev] NVIZ problem on Intel Macs In-Reply-To: <3CEF556A-7FFC-46DA-9623-E6A7008BCBEC@kyngchaos.com> References: <3CEF556A-7FFC-46DA-9623-E6A7008BCBEC@kyngchaos.com> Message-ID: <20060601172622.4c84d5bd.hamish_nospam@yahoo.com> On Wed, 31 May 2006 20:04:43 -0500 William Kyngesburye wrote: > > I tried my build of GRASS CVS 5-27 (built on Intel). NVIZ starts for > me - I get the NVIZ Options/Output screen. But when I select a > raster and try to Run it, then it crashes, with nothing in the output > window except the raster and the X icon to remove it, like so > (sometimes the Please Wait window briefly appears): NVIZ debug tip: at the start of nviz2.2_script, change the DEBUG setting to: set DEBUG 1 You'll get more "mile-posts" that way. Hamish From hamish_nospam at yahoo.com Thu Jun 1 07:31:36 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Jun 1 07:31:56 2006 Subject: [GRASS-dev] [bug #4522] (grass) r.series: error in row of input map is non-fatal giving wrong results In-Reply-To: <17533.52789.412070.442208@cerise.gclements.plus.com> References: <20060530025753.3F2821005C4@lists.intevation.de> <17532.15979.943259.530642@cerise.gclements.plus.com> <20060531145048.0d85b79f.hamish_nospam@yahoo.com> <17533.52789.412070.442208@cerise.gclements.plus.com> Message-ID: <20060601173136.06066da3.hamish_nospam@yahoo.com> > I suggest that: > > a) G_get_raster_row() etc should automatically call G_fatal_error() if > an error occurs, with a function to disable this behaviour for modules > which really need to do their own error handling. ok > b) It should be the library's responsibility to clean up incomplete > maps upon exit. > > Having to manually check for error conditions and perform clean-up > whenever an error occurs is enough of a nuisance that it will > frequently be omitted (or, if error handling is added, those code > paths will seldom get tested and thus will frequently contain bugs). does that mean you have to start sending the file descriptors, etc, along to the lib fns? While one read error probably means many, waiting for cleanup-on-GRASS-exit seems less messy somehow. Should G_get_raster_row() do system("$GISBASE/etc/clean_temp") before calling G_fatal_error() ? Hamish From landa.martin at gmail.com Thu Jun 1 10:28:22 2006 From: landa.martin at gmail.com (Martin Landa) Date: Thu Jun 1 10:28:32 2006 Subject: [GRASS-dev] random colors in d.vect In-Reply-To: References: <20060531155322.GA989@localhost.tamu.edu> Message-ID: Hi all, I have rewritten the previous patch. I have separated the added code to a function random_color() and tried to clean the code. Now it works also for layer=-1 (i.e. according to layer number). There is also a small bug in the current d.vect. Flag -c does not work (in connection with layer=-1) for areas. It should be also solved. Please test it if you like, I have no access to the CVS... Best, Martin PS: I think that default value for parameter 'layer' should be -1 instead of 1. Generally, I want to display all objects no matter which layer they are stored in. 2006/5/31, Martin Landa : > Hi, > > the difference is that the current implementation use 'pseudo random' > colors (e.g. cat % palette_ncolors), i.e. the color composition is > always the same. The patch changes this behaviour, it means, you will > not get the same colours by d.vect -c (it is useful if you do not like > the current colors). > > Best, Martin > > 2006/5/31, Huidae Cho : > > Hi, > > > > What's different between 'd.vect -c' and your patch? The -c flag also > > implements random colors based on category/layer number. > > > > Huidae Cho > > > > > > On Wed, May 31, 2006 at 11:36:10AM +0200, Martin Landa wrote: > > > Hi all, > > > > > > I have tried to implement *random* colouring based on category number > > > (according to layer number can be implemented later before CVS > > > committing...), see the attached patch. > > > > > > I do not completely understand why you need to use in level 2 > > > Vect_line_alive() + Vect_read_line() in contrast with level 1 and > > > function Vect_read_next_line (). In any case the functions > > > Vect_read_line () and Vect_read_next_line behave in the same way - > > > they may return 'line number', -1 or -2. So I do not know why > > > variable 'ltype' is tested only (switch (ltype)) in level 1. > > > > > > Best regards, Martin > > > > > > PS: Temporarily I have no GNU/Linux PC with Internet connection, so > > > this patch is against CVS snapshot from 2006/05/27. > > > > > > > _______________________________________________ > > > 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: d_vect_random_cols-2006-06-01.diff.gz Type: application/x-gzip Size: 2348 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060601/c95db367/d_vect_random_cols-2006-06-01.diff.gz From glynn at gclements.plus.com Thu Jun 1 15:21:50 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jun 1 15:22:05 2006 Subject: [GRASS-dev] raster row alloc? In-Reply-To: <20060601161431.18b0effd.hamish_nospam@yahoo.com> References: <20060601161431.18b0effd.hamish_nospam@yahoo.com> Message-ID: <17534.59886.524531.893645@cerise.gclements.plus.com> Hamish wrote: > I notice G_allocate_raster_buf() allocates G_window_cols() + 1. > > What's the +1 for? Is it just for good luck, AFAICT, yes. > is there a null terminator which inidcates EOL? or something else? G_{get,put}_raster_row() etc only read/write G_window_cols() elements. > I'd like to use G_set_null_value(array, nrows*ncols, map_type); > to fill some nrows with NULL in one go instead of a loop over the number > of rows, and perhaps G_raster_cpy() to copy a few lines over at a time. > > nrows*(ncols+1) ? Not necessary. -- Glynn Clements From glynn at gclements.plus.com Thu Jun 1 15:27:00 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jun 1 15:27:16 2006 Subject: [GRASS-dev] [bug #4522] (grass) r.series: error in row of input map is non-fatal giving wrong results In-Reply-To: <20060601173136.06066da3.hamish_nospam@yahoo.com> References: <20060530025753.3F2821005C4@lists.intevation.de> <17532.15979.943259.530642@cerise.gclements.plus.com> <20060531145048.0d85b79f.hamish_nospam@yahoo.com> <17533.52789.412070.442208@cerise.gclements.plus.com> <20060601173136.06066da3.hamish_nospam@yahoo.com> Message-ID: <17534.60196.780248.89602@cerise.gclements.plus.com> Hamish wrote: > > a) G_get_raster_row() etc should automatically call G_fatal_error() if > > an error occurs, with a function to disable this behaviour for modules > > which really need to do their own error handling. > > ok > > > b) It should be the library's responsibility to clean up incomplete > > maps upon exit. > > > > Having to manually check for error conditions and perform clean-up > > whenever an error occurs is enough of a nuisance that it will > > frequently be omitted (or, if error handling is added, those code > > paths will seldom get tested and thus will frequently contain bugs). > > does that mean you have to start sending the file descriptors, etc, > along to the lib fns? While one read error probably means many, waiting > for cleanup-on-GRASS-exit seems less messy somehow. > > Should G_get_raster_row() do system("$GISBASE/etc/clean_temp") before > calling G_fatal_error() ? My comment was limited to cleaning up the temporary cell/fcell file created when writing new raster maps. Essentially, G_open_raster_new() etc would need to use atexit() to automatically "unopen" any incomplete maps. Applications would be responsible for cleaning up their own temporary files. -- Glynn Clements From twiens at interbaun.com Thu Jun 1 15:34:02 2006 From: twiens at interbaun.com (Trevor Wiens) Date: Thu Jun 1 15:34:07 2006 Subject: [GRASS-dev] GUI toolkits [-> ps.map CMYK] In-Reply-To: <20060531232044.5af099b0.hamish_nospam@yahoo.com> References: <44771448.31a.1200.10426@interbaun.com> <200605270924.36803.cavallini@faunalia.it> <20060527215110.7bcd7720@localhost.localdomain> <200605281615.21910.cavallini@faunalia.it> <20060528224434.7357fea1@localhost.localdomain> <20060530190749.45b89b7d.hamish_nospam@yahoo.com> <20060530083633.41805f32@localhost.localdomain> <20060531232044.5af099b0.hamish_nospam@yahoo.com> Message-ID: <20060601073402.09f03f57@localhost.localdomain> On Wed, 31 May 2006 23:20:44 +1200 Hamish wrote: > > In terms of ps.map and process colours I was wondering about > > considering a replacement using the PyX library which supports process > > colours and more importantly text control using TeX. I don't like > > tossing out existing code or suggesting others do the same, but I've > > started using PyX for graph generation (on the same book project) and > > it is pretty nice. Having the ability to layout maps using the > > power of TeX is pretty much as good as it gets IMHO (FYI, I use and > > really like LaTeX). > > have you tried GRI? (or GRE) > > GRI: http://gri.sourceforge.net > I had run across it before and had been unimpressed. Looking again, based on the examples on the site, it seems fairly primitive and less developed than graphing packages like GNU Plot or PyX, ..... Are you familiar with it and have a different view? T -- Trevor Wiens twiens@interbaun.com The significant problems that we face cannot be solved at the same level of thinking we were at when we created them. (Albert Einstein) From woklist at kyngchaos.com Thu Jun 1 15:55:01 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Thu Jun 1 15:55:09 2006 Subject: [GRASS-dev] NVIZ problem on Intel Macs In-Reply-To: <20060601172622.4c84d5bd.hamish_nospam@yahoo.com> References: <3CEF556A-7FFC-46DA-9623-E6A7008BCBEC@kyngchaos.com> <20060601172622.4c84d5bd.hamish_nospam@yahoo.com> Message-ID: Interesting - NVIZ on my MacBook got farther this time: Loading Data Update elev null mask Loading Data building color table Adding panels from /usr/local/grass-6.1.cvs/etc/nviz2.2/scripts Nv_(panels) Build toplevel window toplevel made Even after turning debug back off, I got the same progress as on the PowerBook. Must have been the dataset I was using on the MacBook the first time (I used the same Spearfish demo this time). On Jun 1, 2006, at 12:26 AM, Hamish wrote: > On Wed, 31 May 2006 20:04:43 -0500 > William Kyngesburye wrote: > >> >> I tried my build of GRASS CVS 5-27 (built on Intel). NVIZ starts for >> me - I get the NVIZ Options/Output screen. But when I select a >> raster and try to Run it, then it crashes, with nothing in the output >> window except the raster and the X icon to remove it, like so >> (sometimes the Please Wait window briefly appears): > > > NVIZ debug tip: > > at the start of nviz2.2_script, change the DEBUG setting to: > > set DEBUG 1 > > You'll get more "mile-posts" that way. > > > > Hamish ----- William Kyngesburye http://www.kyngchaos.com/ [Trillian] What are you supposed to do WITH a maniacally depressed robot? [Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer... - HitchHiker's Guide to the Galaxy From woklist at kyngchaos.com Thu Jun 1 16:07:19 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Thu Jun 1 16:07:26 2006 Subject: [GRASS-dev] Discussing new GUI toolkit: v.pydigit In-Reply-To: <20060601171028.4509e7fc.hamish_nospam@yahoo.com> References: <20060530235842.GC16478@gdf-hannover.de> <20060531215617.41c2dd2d.hamish_nospam@yahoo.com> <20060531121906.GC19794@gdf-hannover.de> <165AA021-B70E-4621-9347-46BC9ADD948F@kyngchaos.com> <20060601171028.4509e7fc.hamish_nospam@yahoo.com> Message-ID: Ooh - xev tells me that the two-fingered right-click indeed does 'button 3' in X11. Another interesting thing: another two-fingered trick is scrolling, which seems to work also, giving buttons 4 & 5 in X11, the scroll-wheel I presume. With the emulate 3 button mouse option on in X11, it's apple-click for right-click (and option for middle). These also show the correct button click in xev, but the apple/option keys precede that, which might confuse some X11 programs (not GRASS). On Jun 1, 2006, at 12:10 AM, Hamish wrote: >> I wonder - does it (python I assume you mean here) get button-click >> info from the system, or interpret mouse/trackpad directly? A >> feature of recent PowerBooks, and the new MacBook I'm lovin', is (if >> one uses the pad-tap feature) tapping with *two* fingers does a >> right- >> >> click. If Python sees it as left/right click, you wouldn't have to >> worry about trying to interpret meta-keys as well. Same goes for >> ctrl-click - it's a standard setup for the system to do a right-click >> >> - if Python sees this as right-click instead of ctrl-click, it >> wouldn't have to deal with having to have alternatives for extra >> buttons on a Mac. There's nothing for a middle-click, so we're only >> down to two buttons, not one. >> >> There are also drivers available to do similar things for older >> PowerBooks. > > AFAIR, ctrl-click and apple-click on the mac were translated to > middle/right click somewhere in the system before X11. (but it doesn't > always work right in some X applications) > > Play with "xev" to test? > > > Hamish ----- 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 neteler at itc.it Thu Jun 1 18:47:35 2006 From: neteler at itc.it (Markus Neteler) Date: Thu Jun 1 18:47:36 2006 Subject: [GRASS-dev] v.distance: 3D? Message-ID: <20060601164735.GC14261@bartok.itc.it> Hi, [wish?] from the code of v.distance I guess that it is just doing the 2D projected distances (which should be documented). Would be cool to have 3D support as well, e.g. to calculate antenna distances in mountains. Markus From jachym.cepicky at centrum.cz Thu Jun 1 19:02:34 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Thu Jun 1 19:04:00 2006 Subject: [GRASS-dev] Discussing new GUI toolkit: v.pydigit In-Reply-To: <20060601170435.69dd8587.hamish_nospam@yahoo.com> References: <20060530235842.GC16478@gdf-hannover.de> <20060531215617.41c2dd2d.hamish_nospam@yahoo.com> <20060531121906.GC19794@gdf-hannover.de> <20060601170435.69dd8587.hamish_nospam@yahoo.com> Message-ID: <20060601170232.GA1074@gdf-hannover.de> Hallo, On Thu, Jun 01, 2006 at 05:04:35PM +1200, Hamish wrote: > > > for raster option use r.in.poly or "v.in.*/v.edit" + v.to.rast? > > > > He? Do you mean, that v.pydigit could be used as r.digit? > > sure, why not? > > see the r.in.poly help page. The format is almost the same as v.in.ascii > format=standard. v.digit and r.digit may as well be put in the same app. All right, I'll have to look. > > > > > The script reads them (g.region -g) and stores to self.region dictionary > > (Vpydigit/vdigitGui.py). Everytime, it is zoomed/paned, this variable > > is changed. > > > > I wanted to do it possible independent on the Xdriver - didn't we want > > to get rid of it? > > the PNG[/PPM] driver is not dependant on the XDRIVER. > > Hamish Hamish, and others, I went through the drivers manual page, but I found nothing about how to acess png/ppm file without need to store it to the disk. Could you point me the the right place (source/manual/example), where I could get it? I have support for rasters (from temporary file) now. It's working nicely (via --bgcmd="d.rast ...; d.vect ...") Thank you 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/20060601/6912d8aa/attachment.bin From glynn at gclements.plus.com Thu Jun 1 20:25:39 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jun 1 20:25:42 2006 Subject: [GRASS-dev] Driver changes Message-ID: <17535.12579.16330.85140@cerise.gclements.plus.com> I've just committed some changes to the layout of the driver code. Specifically, the display/drivers/lib directory has been moved to lib/driver, while the bulk of the PNG driver has been moved into a separate library in lib/pngdriver. It shouldn't have any impact from the perspective of either application code or the user, but the changes to the layout (and the corresponding changes to the Makefiles) are signficant enough that I could have missed something which could cause compilation problems. I would appreciate it if people could report successful compilations after having updated to the new code, so that I can get an idea of when it's had a reasonable amount of testing. I don't want to commit the next phase (integration of libpngdriver with libraster) until any problems with the latest changes have been ironed out. -- Glynn Clements From werchowyna at epf.pl Thu Jun 1 22:45:08 2006 From: werchowyna at epf.pl (Maciek Sieczka) Date: Thu Jun 1 22:45:04 2006 Subject: [GRASS-dev] Driver changes In-Reply-To: <17535.12579.16330.85140@cerise.gclements.plus.com> References: <17535.12579.16330.85140@cerise.gclements.plus.com> Message-ID: <20060601224508.849129bf.werchowyna@epf.pl> On Thu, 1 Jun 2006 19:25:39 +0100 Glynn Clements wrote: > I would appreciate it if people could report successful compilations > after having updated to the new code, All OK for me. Using CVS from just a while ago. Not a single error during configure or make. Ubuntu 5.10 Breezy (Debian derivative). ./configure --with-cxx --without-odbc --with-sqlite --with-tcltk-includes="/usr/include/tcl8.4/" --with-postgres-includes="/usr/include/postgresql/" --with-freetype --with-freetype-includes="/usr/include/freetype2/" --with-readline --with-ffmpeg=yes --with-ffmpeg-includes=/usr/include/ffmpeg --with-proj-share=/usr/local/share/proj/ Using gcc 3.4.5. Maciek -------------------- W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich! http://katalog.panoramainternetu.pl/ From jachym.cepicky at centrum.cz Thu Jun 1 23:24:00 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Thu Jun 1 23:25:19 2006 Subject: [GRASS-dev] Driver changes In-Reply-To: <17535.12579.16330.85140@cerise.gclements.plus.com> References: <17535.12579.16330.85140@cerise.gclements.plus.com> Message-ID: <20060601212400.GA24599@gdf-hannover.de> hallo, ./configure --with-cxx --with-freetype --with-tcltk-includes=/usr/include/tcl8.4/ --with-postgres-includes=/usr/include/postgresql/ --with-freetype-includes=/usr/include/freetype2/ compilation no problem d.out.png all right J?chym On Thu, Jun 01, 2006 at 07:25:39PM +0100, Glynn Clements wrote: > > I've just committed some changes to the layout of the driver code. > Specifically, the display/drivers/lib directory has been moved to > lib/driver, while the bulk of the PNG driver has been moved into a > separate library in lib/pngdriver. > > It shouldn't have any impact from the perspective of either > application code or the user, but the changes to the layout (and the > corresponding changes to the Makefiles) are signficant enough that I > could have missed something which could cause compilation problems. > > I would appreciate it if people could report successful compilations > after having updated to the new code, so that I can get an idea of > when it's had a reasonable amount of testing. I don't want to commit > the next phase (integration of libpngdriver with libraster) until any > problems with the latest changes have been ironed out. > > -- > Glynn Clements > > _______________________________________________ > 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/20060601/903e283e/attachment.bin From jachym.cepicky at centrum.cz Fri Jun 2 03:40:43 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Fri Jun 2 03:42:02 2006 Subject: [GRASS-dev] Discussing new GUI toolkit: v.pydigit In-Reply-To: <20060530235842.GC16478@gdf-hannover.de> References: <20060530235842.GC16478@gdf-hannover.de> Message-ID: <20060602014042.GB27200@gdf-hannover.de> Hallo, * added support for d.* commands, for loading background images * code restructurising * http://les-ejk.cz/?cat=vpydigit updated Currently implemetation creates temporary ppm files (via g.tempfile). Hamish: > Zoom->PPM->Display does not have to mean Zoom->PPM->Disk->Display How? g.manual pngdriver does not tell me much :-/ J?chym -- 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/20060602/84b59963/attachment.bin From joel.pitt at gmail.com Fri Jun 2 04:43:18 2006 From: joel.pitt at gmail.com (Joel Pitt) Date: Fri Jun 2 04:43:20 2006 Subject: [GRASS-dev] Discussing new GUI toolkit: v.pydigit In-Reply-To: <20060531121906.GC19794@gdf-hannover.de> References: <20060530235842.GC16478@gdf-hannover.de> <20060531215617.41c2dd2d.hamish_nospam@yahoo.com> <20060531121906.GC19794@gdf-hannover.de> Message-ID: On 6/1/06, Jachym Cepicky wrote: > Suggestion: > mouseL 1 click - digitize > mouseL dbl click - menu > |-> End digitizing > |-> Delete last > |-> Delete all > |-> Snap to closesd node > if boundary -> snap to begin > > mouseR - end digitizing > mouseM - Delete last I agree that we should make it usable for Mac OSX users, however please don't remove right-click context-sensitive menus. IMHO they simply workflow since relevent commands are contained therein and you don't have to search for the button/toolbar to carry out an operation. Also having a strange behaviour where dbl left click brings up a menu instead is just confusing. Right click = menu is the expected behaviour by most computer users. -- -Joel "Wish not to seem, but to be, the best." -- Aeschylus From hamish_nospam at yahoo.com Fri Jun 2 06:59:12 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Jun 2 06:59:21 2006 Subject: [GRASS-dev] Discussing new GUI toolkit: v.pydigit In-Reply-To: <20060601170232.GA1074@gdf-hannover.de> References: <20060530235842.GC16478@gdf-hannover.de> <20060531215617.41c2dd2d.hamish_nospam@yahoo.com> <20060531121906.GC19794@gdf-hannover.de> <20060601170435.69dd8587.hamish_nospam@yahoo.com> <20060601170232.GA1074@gdf-hannover.de> Message-ID: <20060602165912.76073204.hamish_nospam@yahoo.com> Jachym Cepicky wrote: > Hamish, and others, I went through the drivers manual page, but I > found nothing about how to acess png/ppm file without need to store it > to the disk. Could you point me the the right place > (source/manual/example), where I could get it? I don't think it's there. I don't thing the PNG driver help page even mentions the .PPM ability.. I do not know of these things, but as a wild guess: the PNG driver could be enhanced to send data to a UNIX socket instead of a disk file? Would that work for WinGW? > I have support for rasters (from temporary file) now. It's working > nicely (via --bgcmd="d.rast ...; d.vect ...") nice. Hamish From rez at touchofmadness.com Fri Jun 2 07:58:15 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Fri Jun 2 07:58:21 2006 Subject: [GRASS-dev] r.to.vect update Message-ID: <1149227895.2266.175.camel@devel> Hello, I just committed some changes to r.to.vect and I'm asking for testers to ensure everything works properly (no reason why it shouldn't). Changes: - localized text - added progress meters and a quiet flag to shut them up :-) - simplified code -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From mlennert at club.worldonline.be Fri Jun 2 11:24:09 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Jun 2 11:24:18 2006 Subject: [GRASS-dev] random colors in d.vect In-Reply-To: References: <20060531155322.GA989@localhost.tamu.edu> Message-ID: <448003B9.7040808@club.worldonline.be> Martin Landa wrote: > Hi all, > > I have rewritten the previous patch. I have separated the added code > to a function random_color() and tried to clean the code. Now it works > also for layer=-1 (i.e. according to layer number). There is also a > small bug in the current d.vect. Flag -c does not work (in connection > with layer=-1) for areas. It should be also solved. Please test it if > you like, I have no access to the CVS... Any chance of allowing random colors according to an attribute column instead of cat ? Moritz From landa.martin at gmail.com Fri Jun 2 11:27:37 2006 From: landa.martin at gmail.com (Martin Landa) Date: Fri Jun 2 11:27:43 2006 Subject: [GRASS-dev] random colors in d.vect In-Reply-To: <448003B9.7040808@club.worldonline.be> References: <20060531155322.GA989@localhost.tamu.edu> <448003B9.7040808@club.worldonline.be> Message-ID: Hi, good idea, I will try to add it... Best, Martin 2006/6/2, Moritz Lennert : > Martin Landa wrote: > > Hi all, > > > > I have rewritten the previous patch. I have separated the added code > > to a function random_color() and tried to clean the code. Now it works > > also for layer=-1 (i.e. according to layer number). There is also a > > small bug in the current d.vect. Flag -c does not work (in connection > > with layer=-1) for areas. It should be also solved. Please test it if > > you like, I have no access to the CVS... > > > Any chance of allowing random colors according to an attribute column > instead of cat ? > > Moritz > From hamish_nospam at yahoo.com Fri Jun 2 11:33:56 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Jun 2 11:34:12 2006 Subject: [GRASS-dev] Driver changes In-Reply-To: <17535.12579.16330.85140@cerise.gclements.plus.com> References: <17535.12579.16330.85140@cerise.gclements.plus.com> Message-ID: <20060602213356.00d0eb95.hamish_nospam@yahoo.com> > I've just committed some changes to the layout of the driver code. > Specifically, the display/drivers/lib directory has been moved to > lib/driver, while the bulk of the PNG driver has been moved into a > separate library in lib/pngdriver. > > It shouldn't have any impact from the perspective of either > application code or the user, but the changes to the layout (and the > corresponding changes to the Makefiles) are signficant enough that I > could have missed something which could cause compilation problems. > > I would appreciate it if people could report successful compilations > after having updated to the new code, so that I can get an idea of > when it's had a reasonable amount of testing. I don't want to commit > the next phase (integration of libpngdriver with libraster) until any > problems with the latest changes have been ironed out. Can we tag 6.1.0 before the next lot of changes are committed? It would make a common basis for before/after tests. Hamish From grass-bugs at intevation.de Fri Jun 2 12:34:39 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Fri Jun 2 12:34:41 2006 Subject: [GRASS-dev] [bug #4528] (grass) Hello my Dear Stranger! Message-ID: <20060602103439.B09CF1005CF@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4528 ------------------------------------------------------------------------- Greeting. I'm a very young and energetic lady! I have very positive attitude to life and people. I do enjoy new experience life can offer me: to see new interesting places, to meet new people. I do try to enjoy every moment of life and accept everything the way it comes without complaining. Though my life seems to be quite enjoyable there's one important thing missing. It's LOVE! Without my beloved one, my soul mate, my King my life is not completed. I wish i coud find him very soon so that we could share together every momement of the life-time romance! What about you? Could you be my King? If answer is "yes" - you can find more about me http://ZyM.come2meetlove.com/ talk to you soon Galina B. --- Headers Follow --- >From novikov@5season.ru Fri Jun 2 12:34:39 2006 Return-Path: Delivered-To: grass-bugs@lists.intevation.de Received: from mail.intevation.de (aktaia [212.95.126.10]) by lists.intevation.de (Postfix) with ESMTP id 525C21005CB; Fri, 2 Jun 2006 12:34:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.intevation.de (Postfix) with ESMTP id A233C36F29; Fri, 2 Jun 2006 12:34:38 +0200 (CEST) Received: from 61.170.152.154 (unknown [61.170.152.154]) by mail.intevation.de (Postfix) with ESMTP id 7987B36DC6; Fri, 2 Jun 2006 12:34:22 +0200 (CEST) Received: from [10.0.37.169] by 61.170.152.154 id 758XRzEZRFpA; Fri, 02 Jun 2006 13:35:08 +0300 Message-ID: <001f01c68630$2e4d2e00$a925000a@61.170.152.154> From: "Galinochka B." To: "Stefan" Subject: Hello my Dear Stranger! Date: Fri, 02 Jun 2006 13:35:08 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=2.5 tagged_above=-999.0 required=3.0 tests=BAYES_50, SUB_HELLO X-Spam-Level: ** -------------------------------------------- Managed by Request Tracker From glynn at gclements.plus.com Fri Jun 2 13:15:01 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jun 2 13:15:08 2006 Subject: [GRASS-dev] Discussing new GUI toolkit: v.pydigit In-Reply-To: <20060602165912.76073204.hamish_nospam@yahoo.com> References: <20060530235842.GC16478@gdf-hannover.de> <20060531215617.41c2dd2d.hamish_nospam@yahoo.com> <20060531121906.GC19794@gdf-hannover.de> <20060601170435.69dd8587.hamish_nospam@yahoo.com> <20060601170232.GA1074@gdf-hannover.de> <20060602165912.76073204.hamish_nospam@yahoo.com> Message-ID: <17536.7605.202700.699078@cerise.gclements.plus.com> Hamish wrote: > Jachym Cepicky wrote: > > Hamish, and others, I went through the drivers manual page, but I > > found nothing about how to acess png/ppm file without need to store it > > to the disk. Could you point me the the right place > > (source/manual/example), where I could get it? > > I don't think it's there. I don't thing the PNG driver help page even > mentions the .PPM ability.. GRASS_PNGFILE=filename the filename to put the resulting image in, default is map.png. If you set GRASS_PNGFILE to a filename which ends in ".ppm", a PPM file will be created. > I do not know of these things, but as a wild guess: the PNG driver could > be enhanced to send data to a UNIX socket instead of a disk file? It can write data to a file when it's appropriate (i.e. when it terminates, or when a client disconnects), but you can only write data to a socket when something is connected to the other end and is willing to read the data. What's the problem with writing to a file, anyhow? > Would that work for WinGW? Windows doesn't support Unix-domain sockets. -- Glynn Clements From jachym.cepicky at centrum.cz Fri Jun 2 13:28:27 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Fri Jun 2 13:29:45 2006 Subject: [GRASS-dev] Discussing new GUI toolkit: v.pydigit In-Reply-To: <17536.7605.202700.699078@cerise.gclements.plus.com> References: <20060530235842.GC16478@gdf-hannover.de> <20060531215617.41c2dd2d.hamish_nospam@yahoo.com> <20060531121906.GC19794@gdf-hannover.de> <20060601170435.69dd8587.hamish_nospam@yahoo.com> <20060601170232.GA1074@gdf-hannover.de> <20060602165912.76073204.hamish_nospam@yahoo.com> <17536.7605.202700.699078@cerise.gclements.plus.com> Message-ID: <20060602112826.GA30062@gdf-hannover.de> On Fri, Jun 02, 2006 at 12:15:01PM +0100, Glynn Clements wrote: > [...] > > What's the problem with writing to a file, anyhow? > I thing, it is slow. Correct me, if I'm false. It is truth, that it is as simple as possible and transparent sollution. And if the images would not be bigger than screen size, it could be "fast enough". > > Would that work for WinGW? > > Windows doesn't support Unix-domain sockets. > 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/20060602/0fe1b1df/attachment.bin From glynn at gclements.plus.com Fri Jun 2 16:55:14 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jun 2 16:55:19 2006 Subject: [GRASS-dev] Discussing new GUI toolkit: v.pydigit In-Reply-To: <20060602112826.GA30062@gdf-hannover.de> References: <20060530235842.GC16478@gdf-hannover.de> <20060531215617.41c2dd2d.hamish_nospam@yahoo.com> <20060531121906.GC19794@gdf-hannover.de> <20060601170435.69dd8587.hamish_nospam@yahoo.com> <20060601170232.GA1074@gdf-hannover.de> <20060602165912.76073204.hamish_nospam@yahoo.com> <17536.7605.202700.699078@cerise.gclements.plus.com> <20060602112826.GA30062@gdf-hannover.de> Message-ID: <17536.20818.528570.183243@cerise.gclements.plus.com> Jachym Cepicky wrote: > > What's the problem with writing to a file, anyhow? > > > > I thing, it is slow. Correct me, if I'm false. If anything, writing to a file will normally be faster than writing to a pipe. An application can write the entire image to a file in one go, but you can't write more than a fixed amount (typically 4Kbytes) to a pipe at a time. Unless the system is particularly low on RAM, the application doesn't have to wait for the data to be physically written to disk. If the reader deletes the file once it has been read, the data will typically never be written to disk. However, it's unlikely that I/O between the PNG driver and the application is likely to be a signficant factor for performance. -- Glynn Clements From michael.barton at asu.edu Fri Jun 2 19:36:48 2006 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jun 2 19:36:57 2006 Subject: [GRASS-dev] Discussing new GUI toolkit: v.pydigit In-Reply-To: Message-ID: Right click on a Mac SHOULD open a contextual menu. So this is correct behavior on all platforms. I'm working on a georectifier for 6.2, but have been following this disucssion and think it's great. Take a look in the mapcanvas.tcl code to see how we are doing the display using the png driver. Currently it must write to disk, and we are using temp files (g.tmpfile) to do this. I know that Glynn has started reworking the output drivers but don't know if there will be a way to bypass the disk and send some kind of generic graphic output directly to a GUI. Currently, I think that TclTk must pull it off disk anyway. But this may not be the case with wxWidgets/GTK/QT 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: Joel Pitt > Reply-To: > Date: Fri, 2 Jun 2006 14:43:18 +1200 > To: Jachym Cepicky > Cc: Hamish , > Subject: Re: [GRASS-dev] Discussing new GUI toolkit: v.pydigit > > On 6/1/06, Jachym Cepicky wrote: >> Suggestion: >> mouseL 1 click - digitize >> mouseL dbl click - menu >> |-> End digitizing >> |-> Delete last >> |-> Delete all >> |-> Snap to closesd node >> if boundary -> snap to begin >> >> mouseR - end digitizing >> mouseM - Delete last > > I agree that we should make it usable for Mac OSX users, however > please don't remove right-click context-sensitive menus. IMHO they > simply workflow since relevent commands are contained therein and you > don't have to search for the button/toolbar to carry out an operation. > > Also having a strange behaviour where dbl left click brings up a menu > instead is just confusing. Right click = menu is the expected > behaviour by most computer users. > > -- > -Joel > > "Wish not to seem, but to be, the best." > -- Aeschylus > > From grass-bugs at intevation.de Fri Jun 2 20:52:58 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Fri Jun 2 20:53:00 2006 Subject: [GRASS-dev] [bug #4531] (grass) v.patch -a doesn't work correctly Message-ID: <20060602185258.526151005CA@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4531 ------------------------------------------------------------------------- Subject: v.patch -a doesn't work correctly Platform: Mac OSX grass obtained from: Trento Italy site grass binary for platform: Downloaded precompiled Binaries GRASS Version: 6.1 CVS May 27 2006 Both in the command line and the tcl menu, attempting a v.patch using the -a option fails. If I put in the command v.patch input=aouzou87 output=ESRI1988 -a ...then I get (no matter where I put the -a flag)... Error: option : exists. But of *course* it exists--I want to use the append option. v.patch behaves normally if you use a different name for the output and skip the -a flag. The workaround is to g.remove and g.rename. This error occurs on the Mac OS X builds for May 20 and May 27. It also occurs in the GNU Linux x86 build (from source). I am running Mac OS X 10.4.6 (ppc) and Gentoo Linux (2.6.16-r7 kernel). Thanks! -------------------------------------------- Managed by Request Tracker From jachym.cepicky at centrum.cz Sat Jun 3 02:36:25 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Sat Jun 3 02:38:07 2006 Subject: [GRASS-dev] v.out.ascii format=script Message-ID: <20060603003624.GA4266@gdf-hannover.de> Skipped content of type multipart/mixed-------------- 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/20060603/65b07c31/attachment-0001.bin From michael.barton at asu.edu Sat Jun 3 03:42:46 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sat Jun 3 03:36:39 2006 Subject: [GRASS-dev] [bug #4528] (grass) Hello my Dear Stranger! In-Reply-To: <20060602103439.B09CF1005CF@lists.intevation.de> Message-ID: I'm not sure that I can solve this issue with TclTk in the GUI ;-) Michael On 6/2/06 3:34 AM, "Request Tracker" wrote: > this bug's URL: http://intevation.de/rt/webrt?serial_num=4528 > ------------------------------------------------------------------------- > > Greeting. > > I'm a very young and energetic lady! I have very positive attitude to life and > people. I do enjoy new experience life can offer me: to see new interesting > places, to meet new people. > I do try to enjoy every moment of life and accept everything the way it comes > without complaining. > Though my life seems to be quite enjoyable there's one important thing > missing. It's LOVE! > Without my beloved one, my soul mate, my King my life is not completed. > I wish i coud find him very soon so that we could share together every > momement of the life-time romance! > What about you? Could you be my King? If answer is "yes" - you can find more > about me > http://ZyM.come2meetlove.com/ > > talk to you soon > > Galina B. > > > --- Headers Follow --- > >> From novikov@5season.ru Fri Jun 2 12:34:39 2006 > Return-Path: > Delivered-To: grass-bugs@lists.intevation.de > Received: from mail.intevation.de (aktaia [212.95.126.10]) > by lists.intevation.de (Postfix) with ESMTP > id 525C21005CB; Fri, 2 Jun 2006 12:34:39 +0200 (CEST) > Received: from localhost (localhost [127.0.0.1]) > by mail.intevation.de (Postfix) with ESMTP > id A233C36F29; Fri, 2 Jun 2006 12:34:38 +0200 (CEST) > Received: from 61.170.152.154 (unknown [61.170.152.154]) > by mail.intevation.de (Postfix) with ESMTP > id 7987B36DC6; Fri, 2 Jun 2006 12:34:22 +0200 (CEST) > Received: from [10.0.37.169] by 61.170.152.154 > id 758XRzEZRFpA; Fri, 02 Jun 2006 13:35:08 +0300 > Message-ID: <001f01c68630$2e4d2e00$a925000a@61.170.152.154> > From: "Galinochka B." > To: "Stefan" > Subject: Hello my Dear Stranger! > Date: Fri, 02 Jun 2006 13:35:08 +0300 > MIME-Version: 1.0 > Content-Type: text/plain; > charset="windows-1251" > Content-Transfer-Encoding: 8bit > X-Spam-Status: No, hits=2.5 tagged_above=-999.0 required=3.0 tests=BAYES_50, > SUB_HELLO > X-Spam-Level: ** > > -------------------------------------------- Managed by Request Tracker > > ___________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University WWW - http://www.public.asu.edu/~cmbarton Phone: 480-965-6262 Fax: 480-965-7671 From glynn at gclements.plus.com Sat Jun 3 03:52:52 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jun 3 03:52:57 2006 Subject: [GRASS-dev] v.out.ascii format=script In-Reply-To: <20060603003624.GA4266@gdf-hannover.de> References: <20060603003624.GA4266@gdf-hannover.de> Message-ID: <17536.60276.469108.270973@cerise.gclements.plus.com> Jachym Cepicky wrote: > parsing the output from v.out.ascii format=standard is hard work. > > Attached patch adds new output format to v.out.ascii called "script". > With this output, working with vector data in our scripts should be > *much* simpler. > > If format=script is choosed, each feature will be printed in one line, > so e.g. > > B 6 1 > 5958812.48844435 3400828.84221011 > 5958957.29887089 3400877.11235229 > 5959021.65906046 3400930.7458436 > 5959048.47580612 3400973.65263665 > 5959069.92920264 3401032.64947709 > 5958812.48844435 3400828.84221011 > 1 1 > > will become > > B:6:1:1 1:5958812.48844435 3400828.84221011:5958957.29887089 3400877.11235229:.... Many of the tools which you might want to use to process such data may have limits on the maximum length of a line. Writing scripts which expect all the data on one line is a recipe for producing scripts which only work with "simple" maps (or which only work with the GNU versions of the standard tools, as they usually allocate line buffers dynamically). -- Glynn Clements From jachym.cepicky at centrum.cz Sat Jun 3 03:56:23 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Sat Jun 3 03:57:42 2006 Subject: [GRASS-dev] [bug #4528] (grass) Hello my Dear Stranger! In-Reply-To: References: <20060602103439.B09CF1005CF@lists.intevation.de> Message-ID: <20060603015622.GA4909@gdf-hannover.de> GRASS is your friend. Why not to be also your King? Jachym P.S. 15:18:05 : <[Lutz]_> duuuuuuuuuuuuuuuuuuudes 15:19:01 jachym: [Lutz]_: wrong channel ? ;- ) 15:19:19 : <[Lutz]_> oh damn 15:19:33 : <[Lutz]_> but what kind of grass is this? 15:22:01 jachym: gis grass :-D 15:22:35 jachym: most of the people here are computer freeks, using Linux as their operating systems 15:23:08 jachym: we are disussing the core development - are you shure, this is the right place for you? ;- ) see http://grass.itc.it 15:23:09 sigq: Title: GRASS GIS - The World Leading Free Software GIS ( at grass.itc.it ) 15:23:58 : <[Lutz]_> yeah but you're geeks 15:24:01 : <[Lutz]_> it's cool 15:24:04 : <[Lutz]_> you're with me 15:24:31 : <[Lutz]_> damn 15:24:36 : <[Lutz]_> I just realized 15:24:40 : <[Lutz]_> this may be the wrong channel 15:24:49 jachym: LOL! 15:25:39 : <[Lutz]_> drug dog! 15:25:45 : <[Lutz]_> ops wrong reality 15:25:47 : <[Lutz]_> ignore 15:25:55 jachym: I repent, others are allready sleeping 15:26:07 : <[Lutz]_> there are others? where!? 15:26:43 jachym: other people from GRASS community ;- ) , i have mostly no idea, where they are 15:26:54 : <[Lutz]_> I'm _so_ in the grass community 15:26:55 : <[Lutz]_> don't worry 15:27:10 : <[Lutz]_> the others are everyehere but anywhere 15:28:21 jachym: but it is other grass, you propably mean 15:28:38 : <[Lutz]_> I mean 15:28:40 jachym: it's sedge 15:28:44 jachym: not canabis 15:28:54 : <[Lutz]_> wow 15:28:57 : <[Lutz]_> can you smoke that? 15:31:23 jachym: You can smoke everything 15:31:46 : <[Lutz]_> right on! 15:50:52 : <[Lutz]_> bi bi bi bibbi bib bi bibibbibi 15:52:30 : <[Lutz]_> we don't neeed no education 15:52:35 : <[Lutz]_> we don't need no thought control 15:52:43 : <[Lutz]_> a dark sarcasm in the crossroud 15:52:52 : <[Lutz]_> classroom 16:03:52 jachym: Hey! Teacher! Leave us kids allone! 16:04:03 : <[Lutz]_> right on! 16:05:10 : <[Lutz]_> hey! 16:05:32 : <[Lutz]_> oh crap 16:05:37 : <[Lutz]_> gotta google salvie tee, brb 16:41:50 Pmarc: what was that? On Fri, Jun 02, 2006 at 06:42:46PM -0700, Michael Barton wrote: > I'm not sure that I can solve this issue with TclTk in the GUI ;-) > > Michael > > > On 6/2/06 3:34 AM, "Request Tracker" wrote: > > > this bug's URL: http://intevation.de/rt/webrt?serial_num=4528 > > ------------------------------------------------------------------------- > > > > Greeting. > > > > I'm a very young and energetic lady! I have very positive attitude to life and > > people. I do enjoy new experience life can offer me: to see new interesting > > places, to meet new people. > > I do try to enjoy every moment of life and accept everything the way it comes > > without complaining. > > Though my life seems to be quite enjoyable there's one important thing > > missing. It's LOVE! > > Without my beloved one, my soul mate, my King my life is not completed. > > I wish i coud find him very soon so that we could share together every > > momement of the life-time romance! > > What about you? Could you be my King? If answer is "yes" - you can find more > > about me > > http://ZyM.come2meetlove.com/ > > > > talk to you soon > > > > Galina B. > > > > > > --- Headers Follow --- > > > >> From novikov@5season.ru Fri Jun 2 12:34:39 2006 > > Return-Path: > > Delivered-To: grass-bugs@lists.intevation.de > > Received: from mail.intevation.de (aktaia [212.95.126.10]) > > by lists.intevation.de (Postfix) with ESMTP > > id 525C21005CB; Fri, 2 Jun 2006 12:34:39 +0200 (CEST) > > Received: from localhost (localhost [127.0.0.1]) > > by mail.intevation.de (Postfix) with ESMTP > > id A233C36F29; Fri, 2 Jun 2006 12:34:38 +0200 (CEST) > > Received: from 61.170.152.154 (unknown [61.170.152.154]) > > by mail.intevation.de (Postfix) with ESMTP > > id 7987B36DC6; Fri, 2 Jun 2006 12:34:22 +0200 (CEST) > > Received: from [10.0.37.169] by 61.170.152.154 > > id 758XRzEZRFpA; Fri, 02 Jun 2006 13:35:08 +0300 > > Message-ID: <001f01c68630$2e4d2e00$a925000a@61.170.152.154> > > From: "Galinochka B." > > To: "Stefan" > > Subject: Hello my Dear Stranger! > > Date: Fri, 02 Jun 2006 13:35:08 +0300 > > MIME-Version: 1.0 > > Content-Type: text/plain; > > charset="windows-1251" > > Content-Transfer-Encoding: 8bit > > X-Spam-Status: No, hits=2.5 tagged_above=-999.0 required=3.0 tests=BAYES_50, > > SUB_HELLO > > X-Spam-Level: ** > > > > -------------------------------------------- Managed by Request Tracker > > > > > > ___________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > WWW - http://www.public.asu.edu/~cmbarton > Phone: 480-965-6262 > Fax: 480-965-7671 > > _______________________________________________ > 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/20060603/db35f38a/attachment.bin From rez at touchofmadness.com Sat Jun 3 08:45:09 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Sat Jun 3 08:45:13 2006 Subject: [GRASS-dev] btree Message-ID: <1149317109.12998.111.camel@devel> Is it okay to remove lib/btree/try.c? -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From jachym.cepicky at centrum.cz Sat Jun 3 10:42:23 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Sat Jun 3 10:43:36 2006 Subject: [GRASS-dev] v.out.ascii format=script In-Reply-To: <17536.60276.469108.270973@cerise.gclements.plus.com> References: <20060603003624.GA4266@gdf-hannover.de> <17536.60276.469108.270973@cerise.gclements.plus.com> Message-ID: <20060603084222.GA6566@gdf-hannover.de> hallo, On Sat, Jun 03, 2006 at 02:52:52AM +0100, Glynn Clements wrote: > > Jachym Cepicky wrote: > > > parsing the output from v.out.ascii format=standard is hard work. > > > > Attached patch adds new output format to v.out.ascii called "script". > > With this output, working with vector data in our scripts should be > > *much* simpler. > > > > If format=script is choosed, each feature will be printed in one line, > > so e.g. > > > > B 6 1 > > 5958812.48844435 3400828.84221011 > > 5958957.29887089 3400877.11235229 > > 5959021.65906046 3400930.7458436 > > 5959048.47580612 3400973.65263665 > > 5959069.92920264 3401032.64947709 > > 5958812.48844435 3400828.84221011 > > 1 1 > > > > will become > > > > B:6:1:1 1:5958812.48844435 3400828.84221011:5958957.29887089 3400877.11235229:.... > > Many of the tools which you might want to use to process such data > may have limits on the maximum length of a line. > > Writing scripts which expect all the data on one line is a recipe for > producing scripts which only work with "simple" maps (or which only > work with the GNU versions of the standard tools, as they usually > allocate line buffers dynamically). > > -- > Glynn Clements you are right. I found another solution thanks 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/20060603/4f4864ee/attachment.bin From grass-bugs at intevation.de Sat Jun 3 11:38:44 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sat Jun 3 11:38:46 2006 Subject: [GRASS-dev] [bug #4532] (grass) missing buttons in GUI Message-ID: <20060603093844.153B81005CB@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4532 ------------------------------------------------------------------------- Subject: missing buttons in GUI Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: cvs.2006.06.03 Hallo! I noticed that some module GUIs have "lost" some buttons ;-) In particular: - r.reclass.file GUI is missing a button to select the "Ascii file comtaining reclassification rules" - the same for r.recode.file on the other hand, r.recode.file has an unexpected button on "Name of recoded raster map". can these small problems be fixed? thanks! giorgio -------------------------------------------- Managed by Request Tracker From hamish_nospam at yahoo.com Sat Jun 3 12:03:42 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Sat Jun 3 12:03:46 2006 Subject: [GRASS-dev] Raster format and dual function module In-Reply-To: <20060527185909.4d0c3598.hamish_nospam@yahoo.com> References: <17525.35032.965269.616530@cerise.gclements.plus.com> <20060526003817.60cfbdc2.hamish_nospam@yahoo.com> <17525.45528.73645.501406@cerise.gclements.plus.com> <20060526194855.66af0204.hamish_nospam@yahoo.com> <17527.2982.531295.851476@cerise.gclements.plus.com> <20060527185909.4d0c3598.hamish_nospam@yahoo.com> Message-ID: <20060603220342.519c9f3f.hamish_nospam@yahoo.com> Hi, I have added a "replacement raster format" page in the wiki for both informational and educational purposes. http://grass.gdf-hannover.de/wiki/Replacement_raster_format It would be helpful if basic wants, needs, ideas were listed there to keep interested parties informed of existing plans instead of (re)inventing and suggesting the same good ideas over and over again. [links, justifications, explaination of why to do it one way & not the other, etc..] thanks, Hamish From rez at touchofmadness.com Sat Jun 3 12:19:28 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Sat Jun 3 12:19:40 2006 Subject: [GRASS-dev] extraneous lib files Message-ID: <1149329968.12998.128.camel@devel> The following files are extraneous files that could probably be deleted. Most of them are library tests. If they are to be kept, then may I suggest we integrate them into 'make check' or the like: - lib/bitmap/main.c - lib/bitmap/smain.c - lib/cdhc/cdh-f77.out - lib/cdhc/test.c - lib/cdhc/test.f - lib/cdhc/shapiro1.c.save? - lib/form/form.c? - lib/linkm/try.c - lib/linkm/try2.c - lib/linkm/malloc.c - lib/linkm/linkm.c - lib/linkm/speed.c - lib/linkm/speed2.c - lib/linkm/speed3.c - lib/segment/try.c - lib/vector/diglib/test.c - lib/vector/diglib/port_test.c - lib/rtree/test.c - lib/rtree/gammavol.c? - lib/rtree/sphvol.c? - lib/vector/test.c -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From grass-bugs at intevation.de Sun Jun 4 17:40:57 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sun Jun 4 17:41:00 2006 Subject: [GRASS-dev] [bug #4537] (grass) ERROR: Unable to start monitor Message-ID: <20060604154057.A53441006B4@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4537 ------------------------------------------------------------------------- Subject: ERROR: Unable to start monitor Platform: GNU/Linux/x86_64 grass binary for platform: Downloaded precompiled Binaries GRASS Version: grass-6.1.cvs-x86_64-unknown-linux-gnu-0 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! Jonas Mockus: Welcome to GRASS 6.1.cvs (2006) GRASS homepage: http://grass.itc.it/ This version running thru: Bash Shell (/bin/bash) Help is available with the command: g.manual -i See the licence terms with: g.version -c Start the graphical user interface with: gis.m & When ready to quit enter: exit GRASS 6.1.cvs (d2122):/home/md/danguole/d2122/PERMANENT > g.region -d GRASS 6.1.cvs (d2122):/home/md/danguole/d2122/PERMANENT > g.region -p projection: 99 (Unknown projection) zone: 0 PROJ_INFO file not found for location d2122 datum: ** unknown (default: WGS84) ** ellipsoid: a=6378137 es=0.006694385 north: 6126225.5 south: 6101220.5 west: 374975 east: 399980 nsres: 1 ewres: 1 rows: 25005 cols: 25005 GRASS 6.1.cvs (d2122):/home/md/danguole/d2122/PERMANENT > g.list type=vect ---------------------------------------------- vector files available in mapset PERMANENT: adm2 adm3 elev2 infra2 km52 landu2 rivers2 ---------------------------------------------- GRASS 6.1.cvs (d2122):/home/md/danguole/d2122/PERMANENT > gis.m & [1] 3307 GRASS 6.1.cvs (d2122):/home/md/danguole/d2122/PERMANENT > d.mon start=gism PNG: GRASS_TRUECOLOR status: FALSE PNG: collecting to file: map.png, GRASS_WIDTH=640, GRASS_HEIGHT=480 Graphics driver [gism] is already running ERROR: Unable to start monitor -------------------------------------------- Managed by Request Tracker From damiano.triglione at polimi.it Sun Jun 4 18:05:53 2006 From: damiano.triglione at polimi.it (Damiano Triglione) Date: Sun Jun 4 18:05:55 2006 Subject: [GRASS-dev] d.vect with proper colours Message-ID: <001201c687f0$c1c87b00$0301a8c0@phoenixpdam> Hi, I would like to plot vector points file in a way such that the color for each point is proportional to its height (or another attribute). In Grass 5.x I used d.sites.color that was an external module developed by an italian guy who did it very well; what can I do now in Grass 6.x? Thanks a lot, Damiano -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060604/d49840f7/attachment.html From jachym.cepicky at centrum.cz Mon Jun 5 00:34:08 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Mon Jun 5 00:35:24 2006 Subject: [GRASS-dev] Discussing new GUI toolkit: v.pydigit In-Reply-To: <20060530235842.GC16478@gdf-hannover.de> References: <20060530235842.GC16478@gdf-hannover.de> Message-ID: <20060604223405.GA3640@gdf-hannover.de> Hallo, thinks are getting to be complicated, I started to work on support for attribute editing. # v.pydigit-06-06-05-1.tgz BUGS: * No attribute type controll * Redrawing or vector features is problematic (colors) * Nodes should be handeld corretly * Only lines supported * ... * And many others :-) Changes: * Faster * Boundaries and centroids are read too * Completly input geometry overwritten (still via v.out.ascii) * Initial attribute editing implemented: adding collumns, adding attribute to digitized line. http://les-ejk.cz/tmp/vpydigit5.png new versions now avaliable via svn svn checkout https://subversion.gdf-hannover.de:8080/svn/pygrass/v.pydigit 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/20060605/bed1effa/attachment.bin From grass-bugs at intevation.de Mon Jun 5 01:19:26 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Mon Jun 5 01:19:27 2006 Subject: [GRASS-dev] [bug #4542] (grass) r.in.gdal import south utm projected gtiff as negative zone Message-ID: <20060604231926.602181006AC@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4542 ------------------------------------------------------------------------- Subject: r.in.gdal import south utm projected gtiff as negative zone Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: 6.1 r.in.gdal import south utm projected gtiff as negative zone. But in grass, region utm zones south of equator not is negative in a newly created location (examples below) <> name: UTM proj: utm ellps: SAD-69 a: 6378160.0000000000 es: 0.0066945419 f: 298.2500000000 zone: 22 south: defined <> proj: 1 zone: -22 north: 6475848.30684486 south: 6256125 east: 426355.92252066 west: 254360 cols: 5733 rows: 7324 e-w resol: 30.00103306 n-s resol: 30.00045151 format: 1 compressed: 1 When 'g.region -d' is used, the raster imported with r.in.gdal not is visible. The only way to work with it is using g.region 'raster=imported_gtiff'. To fix the imported gtiff I edit the cellhd file changing -22 to 22, then all is working fine. This bug not is specific to grass 6 version, is the same for the version 5. -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Mon Jun 5 08:53:46 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Mon Jun 5 08:53:48 2006 Subject: [GRASS-dev] [bug #4543] (grass) Makefile:22: include/Make/Grass.make: No such file or directory Message-ID: <20060605065346.4DADF1006A9@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4543 ------------------------------------------------------------------------- Subject: Makefile:22: include/Make/Grass.make: No such file or directory Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: 6.0.2 -downloaded the file from http://grass.itc.it/grass60/source/grass-6.0.2.tar.gz -moved file to new directory /home/grass/ -unzipped with $gunzip grass-6.0.2.tar.gz -untarred with $tar -xvf grass-6.0.2.tar.gz -this created a new directory with all of the sources in it. -configured the file with: $CFLAGS="g -Wall" ./configure -tried to make file with: $make get the following errors: Makefile:22: include/Make/Platform.make: No such file or directory Makefile:23: include/Make/Grass.make: No such file or directory make: *** No rule to make target 'include/Make/Grass.make'. Stop. I think the Makefile was configured improperly. Any suggestions? -------------------------------------------- Managed by Request Tracker From paul-grass at stjohnspoint.co.uk Mon Jun 5 11:30:30 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Jun 5 11:30:40 2006 Subject: [GRASS-dev] [bug #4542] (grass) r.in.gdal import south utm projected gtiff as negative zone In-Reply-To: <20060604231926.602181006AC@lists.intevation.de> References: <20060604231926.602181006AC@lists.intevation.de> Message-ID: On Mon, 5 Jun 2006, Request Tracker wrote: > this bug's URL: http://intevation.de/rt/webrt?serial_num=4542 > ------------------------------------------------------------------------- > > Subject: r.in.gdal import south utm projected gtiff as negative zone > > Platform: GNU/Linux/x86 > grass obtained from: Trento Italy site > grass binary for platform: Compiled from Sources > GRASS Version: 6.1 > > r.in.gdal import south utm projected gtiff as negative zone. But in grass, region utm zones south of equator not is negative in a newly created location (examples below) It should be (in the WIND file). And it is in the example you give below! How exactly did you set up the newly created location (which command etc?) > > <> > name: UTM > proj: utm > ellps: SAD-69 > a: 6378160.0000000000 > es: 0.0066945419 > f: 298.2500000000 > zone: 22 > south: defined > > <> > proj: 1 > zone: -22 > north: 6475848.30684486 > south: 6256125 > east: 426355.92252066 > west: 254360 > cols: 5733 > rows: 7324 > e-w resol: 30.00103306 > n-s resol: 30.00045151 > format: 1 > compressed: 1 > > When 'g.region -d' is used, the raster imported with r.in.gdal not is visible. The only way to work with it is using g.region 'raster=imported_gtiff'. > To fix the imported gtiff I edit the cellhd file changing -22 to 22, then all is working fine. > > This bug not is specific to grass 6 version, is the same for the version 5. > > > > -------------------------------------------- Managed by Request Tracker > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From twiens at interbaun.com Mon Jun 5 17:14:02 2006 From: twiens at interbaun.com (Trevor Wiens) Date: Mon Jun 5 17:14:07 2006 Subject: [GRASS-dev] cvs gis.m error Message-ID: <20060605091402.017cb373@localhost.localdomain> Upon running gis.m I get the following error: child process exited abnormally child process exited abnormally while executing "exec -- d.mon start=gism -s >& /dev/null" ("eval" body line 1) invoked from within "eval exec -- $cmd $args >& /dev/null" (procedure "run" line 6) invoked from within "run d.mon start=gism -s" ("eval" body line 1) invoked from within "eval run $cmd $args" (procedure "runcmd" line 6) invoked from within "runcmd "d.mon start=gism -s"" (procedure "MapCanvas::driversettings" line 55) invoked from within "MapCanvas::driversettings $mon" (procedure "MapCanvas::drawmap" line 39) invoked from within "MapCanvas::drawmap $mon" (procedure "MapCanvas::display_server" line 9) invoked from within "MapCanvas::display_server" ("after" script) After this I can add layers to the tree view but nothing displays. Any suggestions? T -- Trevor Wiens twiens@interbaun.com The significant problems that we face cannot be solved at the same level of thinking we were at when we created them. (Albert Einstein) From werchowyna at epf.pl Mon Jun 5 20:43:19 2006 From: werchowyna at epf.pl (Maciek Sieczka) Date: Mon Jun 5 20:43:15 2006 Subject: [GRASS-dev] DEM, natural neighbor interpolation and Grass Message-ID: <20060605204319.da26fd09.werchowyna@epf.pl> Hi! Maybe some of you remember my notes about the nnbathy (a natural neighbor interpolation program), it's usability for producing DEMs from clustered, heterogenous input and it's complicated interaction with Grass. nnbathy performs great. Now I wrote a script which is an easy to use interface between nnbathy and Grass. All you need to do to run it is to specify the input raster name and the output name. The script will transform your input into x,y,z which nnbathy accepts, let nnbathy interpolate the grid, then let awk do the processing from x,y,z nnbathy output into Grass ASCII raster, and, finaly, r.in.ascii imports. Please take a look at it and let me know what you think (also about the html man page). I'll be putting the script on WIKI in few days if nobody minds. In order to obtain nnbathy with serial input processing enabled (to interpolate any large grid with minor memory usage), please compile it yourself following the instructions in the man page. The prebuilt binaries at http://www.marine.csiro.au/~sakov don't have serial input processing turned on. Cheers Maciek P.S. Please note that nnbathy accepts quite few options which modify the way the output is produced. I have set the following ones in my script: '-W 0' which limits the output non-NULL area only to the convex hull encompasing the input data. You could let nnbathy extrapolate if you need to, by modyfing the number after -W. '-P alg=nn -n' which chooses the Sibson natural neighbor interpolation algorithm. However, other 2 are possible - non-Sibsonian natural neighbor, and linear (which looks exactly the same as the triangulation eg. in Saga). I haven't implemented controlling any nnbathy options through my script, because for DEM production I'm most happy with output produced by those particular settings I hardcoded. I guess you should be happy with the result too. There are several more options in nnbathy, if you want to experiment the script is easy to modify. Please consult with nnabthy help page to learn more. Maciek -------------------- W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich! http://katalog.panoramainternetu.pl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: r.surf.nnbathy Type: application/octet-stream Size: 4944 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060605/fedca43a/r.surf-0001.obj -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060605/fedca43a/r.surf.nnbathy-0001.html From hmitaso at unity.ncsu.edu Mon Jun 5 21:21:00 2006 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Mon Jun 5 21:18:55 2006 Subject: [GRASS-dev] DEM, natural neighbor interpolation and Grass In-Reply-To: <20060605204319.da26fd09.werchowyna@epf.pl> References: <20060605204319.da26fd09.werchowyna@epf.pl> Message-ID: <4484841C.1000208@unity.ncsu.edu> Maciek Sieczka wrote: > Hi! > > Maybe some of you remember my notes about the nnbathy (a natural > neighbor interpolation program), it's usability for producing DEMs from > clustered, heterogenous input and it's complicated interaction with > Grass. > > nnbathy performs great. Now I wrote a script which is an easy to > use interface between nnbathy and Grass. All you need to do to run it > is to specify the input raster name and the output name. The script will > transform your input into x,y,z which nnbathy accepts, let nnbathy > interpolate the grid, then let awk do the processing from x,y,z nnbathy > output into Grass ASCII raster, and, finaly, r.in.ascii imports. > Hamish - r.in.xyz should be able to import this directly ? so the awk step could be skipped making the procedure faster - this will help particularly for large data sets. Helena > Please take a look at it and let me know what you think (also about the > html man page). I'll be putting the script on WIKI in few days if > nobody minds. > > In order to obtain nnbathy with serial input processing enabled (to > interpolate any large grid with minor memory usage), please compile > it yourself following the instructions in the man page. The prebuilt > binaries at http://www.marine.csiro.au/~sakov don't have serial input > processing turned on. > > Cheers > Maciek > > P.S. > > Please note that nnbathy accepts quite few options which modify the way > the output is produced. I have set the following ones in my script: > > '-W 0' which limits the output non-NULL area only to the convex hull > encompasing the input data. You could let nnbathy extrapolate if > you need to, by modyfing the number after -W. > > '-P alg=nn -n' which chooses the Sibson natural neighbor interpolation > algorithm. However, other 2 are possible - non-Sibsonian natural > neighbor, and linear (which looks exactly the same as the triangulation > eg. in Saga). > > I haven't implemented controlling any nnbathy options through my > script, because for DEM production I'm most happy with output produced > by those particular settings I hardcoded. I guess you should be happy > with the result too. > > There are several more options in nnbathy, if you want to experiment > the script is easy to modify. Please consult with nnabthy help page to > learn more. > > Maciek > > > -------------------- > W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich! > http://katalog.panoramainternetu.pl/ > > > ------------------------------------------------------------------------ > > > NAME > > /*r.surf.nnbathy*/ - Interpolate surface from rasterized input using > nn natural neighbor > intepolation library. > > > SYNOPSIS > > *r.surf.nnbathy* > *r.surf.nnbathy help* > *r.surf.nnbathy* *input*=/name/ *output*=/name/ > > > Parameters: > > *input*=/name/ > Input raster name > *output*=/name/ > Output raster name > > > DESCRIPTION > > /r.surf.nnbathy/ is a Bash and Awk script. It is an interface between > the external /nnbathy/ utility and Grass. /nnbathy/ is a surface > interpolation program, which uses /nn/ - a natural neighbor > interpolation library. /nnbathy/ and /nn/ were written by Pavel Sakov > . /nn/ uses /triangle/ software > by Jonathan Shewchuk for > performing the Delaunay triangulation. > > The *output* raster contains a continous surface interpolated from the > *input* raster. > > There is no limitation in regard to the shape and distribution of the > input cells. The input could be e.g. open or closed elevation contour > lines, elevation points, areas and any combination of these. Natural > neighbor algorithm exactly follows the input data and is able to > produce a good result from very clustered, heterogenous input. It will > preserve any rapid value gradient present in the input. It doesn't > produce artificial bulges or hollows between the distant input data, > only a linear, continous surface. It might lead to bogus flat areas in > case of kidney-like shaped contour lines in input. > > /nnbathy/, if built with '-DNN_SERIAL' switch, is able to handle a > grid of virtually any size, using very little memory. It reads, > interpolates and writes one output point at a time only. This > eliminates necessity to hold the whole output array in memory. > > In order to install /nnbathy/ with serial input processing enabled, do > the following: > > 1. Download nn.tar.gz from http://www.marine.csiro.au/~sakov/ > > 2. tar xzvf nn.tar.gz > 3. cd nn > 4. ./configure > 5. make > 6. gcc -o nnbathy nnbathy.c -g -O2 -Wall -pedantic -I. > -DNN_SERIAL libnn.a -lm > 7. chmod u+x ./nnbathy > > Now copy the /nnbathy/ executable to a directory listed in your PATH. > > > NOTES & CAVEATS > > 1. The output extent and resolution will match the current > region settings. > 2. The output non-NULL area will be limited to the convex hull > encompassing all the non-NULL input cells. > 3. The output is double floating point raster. > 4. Natural neighbor is a an /exact/ interpolation algorithm, so > all non-NULL input cells have their value exactly preserved in > the output. > 5. The script will work with /nnbathy/ version 1.63 and higher. > > I'd like to thank Pavel Sakov > for all his support in > regard to /nn/ and /nnbathy/ usage, and especially for > implementing serial input processing. > > > SEE ALSO > > *v.to.rast* > Pavel Sakov > > > AUTHOR > > Maciej Sieczka, Wroclaw, Poland, 2006 > Wroclaw University, Intitute of Plant Biology > ------------------------------------------------------------------------ > ------------------------------------------------------------------------ > > _______________________________________________ > 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 wolf+grass at bergenheim.net Mon Jun 5 21:57:29 2006 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Mon Jun 5 21:57:36 2006 Subject: [GRASS-dev] CVS Message-ID: Hi, I'm having problems connecting to the CVS server (for write). What's up? Has anybody else got any problems? --Wolf -- <:3 )---- Wolf Bergenheim ----( 8:> From glynn at gclements.plus.com Mon Jun 5 22:54:20 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jun 5 22:54:33 2006 Subject: [GRASS-dev] CVS In-Reply-To: References: Message-ID: <17540.39420.885562.387320@cerise.gclements.plus.com> Wolf Bergenheim wrote: > I'm having problems connecting to the CVS server (for write). What's up? > Has anybody else got any problems? I was having problems earlier, but it's working now. -- Glynn Clements From jachym.cepicky at centrum.cz Tue Jun 6 00:38:18 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Tue Jun 6 00:39:30 2006 Subject: [GRASS-dev] Discussing new GUI toolkit: v.pydigit In-Reply-To: <20060530235842.GC16478@gdf-hannover.de> References: <20060530235842.GC16478@gdf-hannover.de> Message-ID: <20060605223817.GA8884@gdf-hannover.de> Hallo, today's version of v.pydigit: + Concept of database management finished |- creating new database table |- adding collumns of defined types |- different features can have different new category management `- ... + Digitizing boundaries and centroids BUGS: * v.edit is not able to work with "centroid", need to discusse this with Wolf * same for type "boundary" * .... NOTE: The program should be able to speak with newest version of v.edit, which is *NOT* in CVS (Wolf wrote message about problems with acess to cvs) - I did not test it, I just checked the strings comming out out v.pydigit and they should be all right. Target: version 0.1 should be able to add new features (with/without attributes) or delete them Download: svn checkout https://subversion.gdf-hannover.de:8080/svn/pygrass/v.pydigit or http://les-ejk.cz/programs/grass/v.pydigit-06-06-06-1.tgz -- 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/20060606/afe7458f/attachment.bin From joel.pitt at gmail.com Tue Jun 6 01:37:29 2006 From: joel.pitt at gmail.com (Joel Pitt) Date: Tue Jun 6 01:38:00 2006 Subject: [GRASS-dev] raster row alloc? In-Reply-To: <17534.59886.524531.893645@cerise.gclements.plus.com> References: <20060601161431.18b0effd.hamish_nospam@yahoo.com> <17534.59886.524531.893645@cerise.gclements.plus.com> Message-ID: On 6/2/06, Glynn Clements wrote: > > I'd like to use G_set_null_value(array, nrows*ncols, map_type); > > to fill some nrows with NULL in one go instead of a loop over the number > > of rows, and perhaps G_raster_cpy() to copy a few lines over at a time. > > > > nrows*(ncols+1) ? > > Not necessary. Glynn, as lovely as your succinct answers are, would you be able to clarify whether you meant that Hamish's wish is not necessary or if the the "+1" in "nrows*(ncols+1)" is not necessary to perform this action? Thanks, -- -Joel "Wish not to seem, but to be, the best." -- Aeschylus From michael.barton at asu.edu Tue Jun 6 02:28:03 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jun 6 02:28:38 2006 Subject: [GRASS-dev] New georectifying module in TclTk Message-ID: I?ve nearly finished a new georectifying module in TclTk and want to get it into the CVS where it can be tested and I can get some help on RMS error calculation. Here is a brief rundown on how it works. Start out in the location/mapset where you want the georectified map to END UP (i.e., the TARGET location). Open any map display (or displays) that you want to use for getting geographic coordinates Select georectify from the file menu In the georectify startup, you must: 1) select the mapset of the file to be georectified (the location and gisdbase are automatically noted) 2) run i.group to create a group to georectify. Target is automatically set to the current location and mapset. 3) select the group to georectify 4) select the raster map to display for interactive georectification (normally a raster in the group you want to georectify) 5) start the georectification You will have a map display with the raster to georectify and a GCP (ground control point) manager window. 1) Click in an xy entry box in the GCP manager 2) Click on the xy map you want to georectify to put xy coordinates in the entry box. The focus will shift to the corresponding geographic entry box in the GCP manager. 3) Click on a point in a georectified map to get geographic coordinates. 4) Repeat until you have enough xy and geographic coordinate pairs. NOTE: you can edit/enter any point by typing. You can also edit existing points by clicking on a new spot in the display. Click the button to save the points to a POINTS file Click on the georectify button to select the type of georectification you want (Is 3rd order georectification still broken?) That's it. RMS error calculation does not work yet. There may be some issues still remaining with zooming in the xy map display. *************** Anyone who is familiar with how i.rectify works, I need to ask for help on RMS error calculation. Somehow, I need to actually rectify the GCP's so I will get meainingful RMS error results. I can't find where to do this in the C code (semi-incomprehensible to me). Try it out and let me know what you think. 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_nospam at yahoo.com Tue Jun 6 03:03:51 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jun 6 03:04:05 2006 Subject: [GRASS-dev] raster row alloc? In-Reply-To: References: <20060601161431.18b0effd.hamish_nospam@yahoo.com> <17534.59886.524531.893645@cerise.gclements.plus.com> Message-ID: <20060606130351.1c3632dc.hamish_nospam@yahoo.com> Joel Pitt wrote: > Glynn wrote: > > Hamish wrote: > > > I'd like to use G_set_null_value(array, nrows*ncols, map_type); > > > to fill some nrows with NULL in one go instead of a loop over the > > > number of rows, and perhaps G_raster_cpy() to copy a few lines > > > over at a time. > > > > > > nrows*(ncols+1) ? > > > > Not necessary. > > Glynn, as lovely as your succinct answers are, would you be able to > clarify whether you meant that Hamish's wish is not necessary or if > the the "+1" in "nrows*(ncols+1)" is not necessary to perform this > action? +1 isn't necessary; nrows*ncols is enough. i.e. you can copy chunks of memory without worrying about stopping on each individual line. I think it might be a common mistake to do (at least it is one I've done in the past): row_array = G_allocate_raster_buf(map_type); ptr = row_array; loop { ptr = G_incr_void_ptr(ptr, G_raster_size(map_type)); G_set_raster_value_d(ptr, value, map_type); } when the order should be: row_array = G_allocate_raster_buf(map_type); ptr = row_array; loop { G_set_raster_value_d(ptr, value, map_type); ptr = G_incr_void_ptr(ptr, G_raster_size(map_type)); } By allocating an extra byte for row_array you mitigate the effect of this sort of dumb mistake. It doesn't cost much for a single row, and the bug doesn't have an effect as long as you are consistently +1. Hamish From rez at touchofmadness.com Tue Jun 6 03:10:55 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Tue Jun 6 03:11:04 2006 Subject: [GRASS-dev] update: put_row.c Message-ID: <1149556255.12998.194.camel@devel> Mostly large file related. Objections? -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 -------------- next part -------------- A non-text attachment was scrubbed... Name: put_row.c.diff Type: text/x-patch Size: 1863 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060605/865ebd3d/put_row.c.bin From glynn at gclements.plus.com Tue Jun 6 03:12:01 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jun 6 03:12:05 2006 Subject: [GRASS-dev] raster row alloc? In-Reply-To: References: <20060601161431.18b0effd.hamish_nospam@yahoo.com> <17534.59886.524531.893645@cerise.gclements.plus.com> Message-ID: <17540.54881.448373.495165@cerise.gclements.plus.com> Joel Pitt wrote: > > > I'd like to use G_set_null_value(array, nrows*ncols, map_type); > > > to fill some nrows with NULL in one go instead of a loop over the number > > > of rows, and perhaps G_raster_cpy() to copy a few lines over at a time. > > > > > > nrows*(ncols+1) ? > > > > Not necessary. > > Glynn, as lovely as your succinct answers are, would you be able to > clarify whether you meant that Hamish's wish is not necessary or if > the the "+1" in "nrows*(ncols+1)" is not necessary to perform this > action? The +1 isn't necessary. -- Glynn Clements From glynn at gclements.plus.com Tue Jun 6 03:17:29 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jun 6 03:18:01 2006 Subject: [GRASS-dev] New georectifying module in TclTk In-Reply-To: References: Message-ID: <17540.55209.242308.848138@cerise.gclements.plus.com> Michael Barton wrote: > Anyone who is familiar with how i.rectify works, I need to ask for help on > RMS error calculation. Somehow, I need to actually rectify the GCP's so I > will get meainingful RMS error results. I can't find where to do this in the > C code (semi-incomprehensible to me). AFAICT, the relevant function is compute_transformation() in imagery/i.points/analyze.c. -- Glynn Clements From michael.barton at asu.edu Tue Jun 6 05:05:31 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jun 6 05:06:45 2006 Subject: [GRASS-dev] New georectifying module in TclTk In-Reply-To: <17540.55209.242308.848138@cerise.gclements.plus.com> Message-ID: I will admit from the beginning that since I don't really know C, I may well be missing something. But I think this calls some transformations in i.rectify somehow. As I understand it (also in the i.points and i.rectify docs), you first need to rectify the points using one of the rectification transformations. Then you can go ahead with the compute_transformation() procedure. 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: Tue, 6 Jun 2006 02:17:29 +0100 > To: Michael Barton > Cc: GRASS developers list , Helena Mitasova > > Subject: Re: [GRASS-dev] New georectifying module in TclTk > > > Michael Barton wrote: > >> Anyone who is familiar with how i.rectify works, I need to ask for help on >> RMS error calculation. Somehow, I need to actually rectify the GCP's so I >> will get meainingful RMS error results. I can't find where to do this in the >> C code (semi-incomprehensible to me). > > AFAICT, the relevant function is compute_transformation() in > imagery/i.points/analyze.c. > > -- > Glynn Clements From grass4u at gmail.com Tue Jun 6 05:37:06 2006 From: grass4u at gmail.com (Huidae Cho) Date: Tue Jun 6 05:37:28 2006 Subject: [GRASS-dev] r.mapcalc operator precedence table Message-ID: <20060606033548.GA1401@localhost> Hi, While editing the operator precedence table in r.mapcalc.html, I found that operators with higher precedence have HIGHER numbers. Shouldn't the highest precedence have the lowest number or 1? Huidae Cho From michael.barton at asu.edu Tue Jun 6 06:02:54 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jun 6 06:03:15 2006 Subject: [GRASS-dev] TclTk georectify addendum Message-ID: Just a couple more comments about the TclTk georectify module. It is a TclTk replacement for i.points and i.vpoints, combined with integrated interface to i.group, i.target, and i.rectify. There has been some discussion about dropping i.rectify for gdalwarp. I?ve used i.rectify here, but it is probably possible to rewrite this to use gdalwarp in the future. Because it uses a TclTk canvas and replaces i.points and i.vpoints, it does not require x11 for interactive selection of ground control points from georectified and non-rectified maps. Finally, I want to acknowledge some critical help from Glynn Clements for ideas of how to get the map points into the GCP manager window. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060605/52940624/attachment.html From glynn at gclements.plus.com Tue Jun 6 06:09:59 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jun 6 06:10:04 2006 Subject: [GRASS-dev] update: put_row.c In-Reply-To: <1149556255.12998.194.camel@devel> References: <1149556255.12998.194.camel@devel> Message-ID: <17541.23.980129.878128@cerise.gclements.plus.com> Brad Douglas wrote: > Mostly large file related. Objections? No objections, although none of this is likely to have any effect upon large file support. FWIW, the last argument to write() is a size_t rather than a ssize_t, although I can't imagine a single row occupying anywhere near 2^31 bytes. Using SEEK_{SET,CUR} instead of 0/1 is definitely a good thing, though. -- Glynn Clements From glynn at gclements.plus.com Tue Jun 6 06:21:35 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jun 6 06:21:39 2006 Subject: [GRASS-dev] raster row alloc? In-Reply-To: <20060606130351.1c3632dc.hamish_nospam@yahoo.com> References: <20060601161431.18b0effd.hamish_nospam@yahoo.com> <17534.59886.524531.893645@cerise.gclements.plus.com> <20060606130351.1c3632dc.hamish_nospam@yahoo.com> Message-ID: <17541.719.237372.396100@cerise.gclements.plus.com> Hamish wrote: > > > > I'd like to use G_set_null_value(array, nrows*ncols, map_type); > > > > to fill some nrows with NULL in one go instead of a loop over the > > > > number of rows, and perhaps G_raster_cpy() to copy a few lines > > > > over at a time. > > > > > > > > nrows*(ncols+1) ? > > > > > > Not necessary. > > > > Glynn, as lovely as your succinct answers are, would you be able to > > clarify whether you meant that Hamish's wish is not necessary or if > > the the "+1" in "nrows*(ncols+1)" is not necessary to perform this > > action? > > +1 isn't necessary; nrows*ncols is enough. i.e. you can copy chunks of > memory without worrying about stopping on each individual line. > > I think it might be a common mistake to do (at least it is one I've > done in the past): > > row_array = G_allocate_raster_buf(map_type); > ptr = row_array; > loop { > ptr = G_incr_void_ptr(ptr, G_raster_size(map_type)); > G_set_raster_value_d(ptr, value, map_type); > } > > when the order should be: > > row_array = G_allocate_raster_buf(map_type); > ptr = row_array; > loop { > G_set_raster_value_d(ptr, value, map_type); > ptr = G_incr_void_ptr(ptr, G_raster_size(map_type)); > } > > By allocating an extra byte for row_array you mitigate the effect > of this sort of dumb mistake. It doesn't cost much for a single row, > and the bug doesn't have an effect as long as you are consistently +1. The former will result in the data being out of place by one column, which is still a bug; possibly worse than a crash. I thought that it might have been related to the "nbytes" prefix at the beginning of each line in a raster file, but the internal buffers (G__.work_buf etc) aren't allocated using those functions. It might be a precaution against writing to buf[n] where n is incorrectly constrained to "<= cols" rather than "< cols". By allocating an extra cell, an erroneous write will be ignored rather than overwriting something important. -- Glynn Clements From michael.barton at asu.edu Tue Jun 6 06:19:30 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jun 6 06:26:04 2006 Subject: [GRASS-dev] d.vect with proper colours In-Reply-To: <001201c687f0$c1c87b00$0301a8c0@phoenixpdam> Message-ID: Use the thematic mapper, d.vect.thematic. 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: Damiano Triglione Date: Sun, 4 Jun 2006 18:05:53 +0200 To: Subject: [GRASS-dev] d.vect with proper colours Hi, I would like to plot vector points file in a way such that the color for each point is proportional to its height (or another attribute). In Grass 5.x I used d.sites.color that was an external module developed by an italian guy who did it very well; what can I do now in Grass 6.x? Thanks a lot, Damiano -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060605/b2bc492e/attachment.html From michael.barton at asu.edu Tue Jun 6 06:26:46 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jun 6 06:27:22 2006 Subject: [GRASS-dev] cvs gis.m error In-Reply-To: <20060605091402.017cb373@localhost.localdomain> Message-ID: I'm running Lorenzo's binaries of 27 May with no problems in general. Check in gronconsole to see if there are any errors reported there. 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: Trevor Wiens > Date: Mon, 5 Jun 2006 09:14:02 -0600 > To: GRASS-DEV > Subject: [GRASS-dev] cvs gis.m error > > Upon running gis.m I get the following error: > > > child process exited abnormally > child process exited abnormally > while executing > "exec -- d.mon start=gism -s >& /dev/null" > ("eval" body line 1) > invoked from within > "eval exec -- $cmd $args >& /dev/null" > (procedure "run" line 6) > invoked from within > "run d.mon start=gism -s" > ("eval" body line 1) > invoked from within > "eval run $cmd $args" > (procedure "runcmd" line 6) > invoked from within > "runcmd "d.mon start=gism -s"" > (procedure "MapCanvas::driversettings" line 55) > invoked from within > "MapCanvas::driversettings $mon" > (procedure "MapCanvas::drawmap" line 39) > invoked from within > "MapCanvas::drawmap $mon" > (procedure "MapCanvas::display_server" line 9) > invoked from within > "MapCanvas::display_server" > ("after" script) > > After this I can add layers to the tree view but nothing displays. > > Any suggestions? > > T > -- > Trevor Wiens > twiens@interbaun.com > > The significant problems that we face cannot be solved at the same > level of thinking we were at when we created them. > (Albert Einstein) > > From glynn at gclements.plus.com Tue Jun 6 06:52:54 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jun 6 06:53:07 2006 Subject: [GRASS-dev] New georectifying module in TclTk In-Reply-To: References: <17540.55209.242308.848138@cerise.gclements.plus.com> Message-ID: <17541.2598.746200.431865@cerise.gclements.plus.com> Michael Barton wrote: > I will admit from the beginning that since I don't really know C, I may well > be missing something. But I think this calls some transformations in > i.rectify somehow. As I understand it (also in the i.points and i.rectify > docs), you first need to rectify the points using one of the rectification > transformations. Then you can go ahead with the compute_transformation() > procedure. compute_transformation() starts by calling Compute_equation() (in imagery/i.points/equ.c), which calls I_compute_georef_equations(). That computes the best-fit affine transformation (forward and inverse) from the control points. It then goes on to call I_georef() for each pair of control points, measuring the difference between the projected source and the destination, and vice-versa. I_compute_georef_equations() and I_georef() are both defined in lib/imagery/georef.c. On entry, the only values which need to have been set are the control points. Upon completion: + group.equation_stat contains 1 if a transformation could be computed. + group.{E,N}{12,21} contain the transformation coefficients (see I_georef() for their interpretation). + xres, yres and gnd contain the x, y and diagonal (Euclidian) differences for each pair. + xmax, ymax and gmax contain the indices of the control points with the greatest x, y and diagonal (Euclidian) differences. + rms is set to the RMS diagonal error -- Glynn Clements From glynn at gclements.plus.com Tue Jun 6 06:56:08 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jun 6 06:56:13 2006 Subject: [GRASS-dev] r.mapcalc operator precedence table In-Reply-To: <20060606033548.GA1401@localhost> References: <20060606033548.GA1401@localhost> Message-ID: <17541.2792.997224.768153@cerise.gclements.plus.com> Huidae Cho wrote: > While editing the operator precedence table in r.mapcalc.html, I found that > operators with higher precedence have HIGHER numbers. Shouldn't the highest > precedence have the lowest number or 1? That's the usual convention. -- Glynn Clements From michael.barton at asu.edu Tue Jun 6 07:02:27 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jun 6 07:08:16 2006 Subject: [GRASS-dev] New georectifying module in TclTk In-Reply-To: <17541.2598.746200.431865@cerise.gclements.plus.com> Message-ID: Where is this procedure ( I_compute_georef_equations())? It isn't in equ.c. 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: Tue, 6 Jun 2006 05:52:54 +0100 > To: Michael Barton > Cc: Helena Mitasova , GRASS developers list > > Subject: Re: [GRASS-dev] New georectifying module in TclTk > > which calls I_compute_georef_equations(). > That computes the best-fit affine transformation (forward and inverse) > from the control points. From Michael.Barton at asu.edu Tue Jun 6 06:56:40 2006 From: Michael.Barton at asu.edu (Michael Barton) Date: Tue Jun 6 07:09:36 2006 Subject: [GRASS-dev] New georectifying module in TclTk In-Reply-To: <17541.2598.746200.431865@cerise.gclements.plus.com> Message-ID: Shows how little I understand C. This will help to try and follow out the various transformations. Mainly I need the affine transformation. A question here. Is a single transformation used to generate the projected points for RMS error calcuations? Or are different transformations used depending on whether 1st, 2nd, or 3rd order is selected? 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: Tue, 6 Jun 2006 05:52:54 +0100 > To: Michael Barton > Cc: Helena Mitasova , GRASS developers list > > Subject: Re: [GRASS-dev] New georectifying module in TclTk > > > Michael Barton wrote: > >> I will admit from the beginning that since I don't really know C, I may well >> be missing something. But I think this calls some transformations in >> i.rectify somehow. As I understand it (also in the i.points and i.rectify >> docs), you first need to rectify the points using one of the rectification >> transformations. Then you can go ahead with the compute_transformation() >> procedure. > > compute_transformation() starts by calling Compute_equation() (in > imagery/i.points/equ.c), which calls I_compute_georef_equations(). > That computes the best-fit affine transformation (forward and inverse) > from the control points. > > It then goes on to call I_georef() for each pair of control points, > measuring the difference between the projected source and the > destination, and vice-versa. > > I_compute_georef_equations() and I_georef() are both defined in > lib/imagery/georef.c. > > On entry, the only values which need to have been set are the control > points. > > Upon completion: > > + group.equation_stat contains 1 if a transformation could be > computed. > > + group.{E,N}{12,21} contain the transformation coefficients (see > I_georef() for their interpretation). > > + xres, yres and gnd contain the x, y and diagonal (Euclidian) > differences for each pair. > > + xmax, ymax and gmax contain the indices of the control points with > the greatest x, y and diagonal (Euclidian) differences. > > + rms is set to the RMS diagonal error > > -- > Glynn Clements From grass4u at gmail.com Tue Jun 6 07:21:15 2006 From: grass4u at gmail.com (Huidae Cho) Date: Tue Jun 6 07:21:36 2006 Subject: [GRASS-dev] r.mapcalc operator precedence table In-Reply-To: <17541.2792.997224.768153@cerise.gclements.plus.com> References: <20060606033548.GA1401@localhost> <17541.2792.997224.768153@cerise.gclements.plus.com> Message-ID: <20060606052115.GA3460@localhost> On Tue, Jun 06, 2006 at 05:56:08AM +0100, Glynn Clements wrote: > > Huidae Cho wrote: > > > While editing the operator precedence table in r.mapcalc.html, I found that > > operators with higher precedence have HIGHER numbers. Shouldn't the highest > > precedence have the lowest number or 1? > > That's the usual convention. > You mean the convention is that the higher precedence has the higher number? Huidae Cho From werchowyna at epf.pl Tue Jun 6 08:01:19 2006 From: werchowyna at epf.pl (Maciek Sieczka) Date: Tue Jun 6 08:01:19 2006 Subject: [GRASS-dev] New georectifying module in TclTk In-Reply-To: References: Message-ID: <20060606080119.90d8fdc0.werchowyna@epf.pl> On Mon, 05 Jun 2006 17:28:03 -0700 Michael Barton wrote: Congrats Michael! I'm not able to do any testing but will do it in future and let you know how it works. > Click on the georectify button to select the type of georectification > you want (Is 3rd order georectification still broken?) Broken?! Can you elaborate on it? The last time I used i.rectify few mnonths ago I only noticed that 2nd order output is somewhat strange (map borders became convex, in general rectification result worse than 1st and 3rd order), but 1st and 3rd produced a reasonable output... Maciek -------------------- W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich! http://katalog.panoramainternetu.pl/ From werchowyna at epf.pl Tue Jun 6 08:19:59 2006 From: werchowyna at epf.pl (Maciek Sieczka) Date: Tue Jun 6 08:20:00 2006 Subject: [GRASS-dev] [bug #4531] (grass) v.patch -a doesn't work correctly In-Reply-To: <20060602185258.526151005CA@lists.intevation.de> References: <20060602185258.526151005CA@lists.intevation.de> Message-ID: <20060606081959.8ab75544.werchowyna@epf.pl> The report author says the problem is fixed - he forgot to use '--o'. Closing it. Maciek -------------------- W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich! http://katalog.panoramainternetu.pl/ From wolf+grass at bergenheim.net Tue Jun 6 08:21:37 2006 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Tue Jun 6 08:21:41 2006 Subject: [GRASS-dev] G_error in Vlib Message-ID: Hi, I need G_error (function that does the same thing as G_fatal_error except that it does not exit). Any objections to me adding it (as soon as I get my CVS working again)? I think it can be good to have a possibility of issuing an error message that doesn't call exit. --Wolf -- <:3 )---- Wolf Bergenheim ----( 8:> From twiens at interbaun.com Tue Jun 6 08:22:32 2006 From: twiens at interbaun.com (Trevor Wiens) Date: Tue Jun 6 08:22:35 2006 Subject: [GRASS-dev] cvs gis.m error In-Reply-To: References: <20060605091402.017cb373@localhost.localdomain> Message-ID: <20060606002232.52fa8f66@localhost.localdomain> On Mon, 05 Jun 2006 21:26:46 -0700 Michael Barton wrote: > I'm running Lorenzo's binaries of 27 May with no problems in general. Check > in gronconsole to see if there are any errors reported there. > > It simply shows that the command d.mon start=gism -s is still running. That's it. Stopping the existing display and opening an new one doesn't resolve the problem. No errors, but also no display either. When I modify the run command in runandoutput.tcl to stop sending everything to /dev/ null, the following happens. The error appears sooner with the message No such monitor gism on the command d.mon stop=gism with the rest being pretty much as before. Hmm.... BTW, this makes me wonder about the wisdom of sending everything to /dev/null. A session log file makes more sense to me. When I revert to an earlier version of the code (one which I was playing with so I revert to different versions of mapcanvas.tcl and maptool.tcl the errors are identical so it would seem to have something to do with d.mon on my system. Has that changed recently? T > > > > child process exited abnormally > > child process exited abnormally > > while executing > > "exec -- d.mon start=gism -s >& /dev/null" > > ("eval" body line 1) > > invoked from within > > "eval exec -- $cmd $args >& /dev/null" > > (procedure "run" line 6) > > invoked from within > > "run d.mon start=gism -s" > > ("eval" body line 1) > > invoked from within > > "eval run $cmd $args" > > (procedure "runcmd" line 6) > > invoked from within > > "runcmd "d.mon start=gism -s"" > > (procedure "MapCanvas::driversettings" line 55) > > invoked from within > > "MapCanvas::driversettings $mon" > > (procedure "MapCanvas::drawmap" line 39) > > invoked from within > > "MapCanvas::drawmap $mon" > > (procedure "MapCanvas::display_server" line 9) > > invoked from within > > "MapCanvas::display_server" > > ("after" script) > > > > After this I can add layers to the tree view but nothing displays. > > > > Any suggestions? > > > > T > > -- > > Trevor Wiens > > twiens@interbaun.com > > > > The significant problems that we face cannot be solved at the same > > level of thinking we were at when we created them. > > (Albert Einstein) > > > > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Trevor Wiens twiens@interbaun.com The significant problems that we face cannot be solved at the same level of thinking we were at when we created them. (Albert Einstein) From wolf+grass at bergenheim.net Tue Jun 6 08:46:06 2006 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Tue Jun 6 08:46:09 2006 Subject: [GRASS-dev] Deleteing vector lines Message-ID: Hi, What must be done to delete vector lines from a vector map? I'm currently trying to do: for(cat=cl->min[i]; cat <= cl->max[i]; cat++) { ret = Vect_cidx_find_next(Map, layer, cat, GV_POINTS|GV_LINES, 0, &type, &id); if(ret<0) continue; if(type==GV_CENTROID) { int area; double x,y; Vect_get_node_coor(Map, id, &x, &y, NULL); area = Vect_find_area(Map, x, y); Vect_delete_line(Map, id); Vect_delete_line(Map, area); attr_del(Map, layer, cat); } else { Vect_delete_line(Map, id); attr_del(Map, layer, cat); but when it calls Vect_cidx_find_next the second time I get a fatal error saying: ERROR: Category index is not up to date and then it exits. So I guess I'm asking how do I update the category index? Should I call Vect_cidx_save()? If I do, do I then need to Vect_cidx_open()? --Wolf -- <:3 )---- Wolf Bergenheim ----( 8:> From wolf+grass at bergenheim.net Tue Jun 6 09:22:30 2006 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Tue Jun 6 09:22:33 2006 Subject: [GRASS-dev] CVS In-Reply-To: <17540.39420.885562.387320@cerise.gclements.plus.com> References: <17540.39420.885562.387320@cerise.gclements.plus.com> Message-ID: On Mon, 5 Jun 2006, Glynn Clements wrote: > > Wolf Bergenheim wrote: > >> I'm having problems connecting to the CVS server (for write). What's up? >> Has anybody else got any problems? > > I was having problems earlier, but it's working now. > Ahh.. I got it working again. It was a firewall problem. --W -- <:3 )---- Wolf Bergenheim ----( 8:> From wolf+grass at bergenheim.net Tue Jun 6 09:30:47 2006 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Tue Jun 6 09:30:51 2006 Subject: [GRASS-dev] v.edit Message-ID: Ok now v.edit's add functionality is completed. One can add point,line,area,boundary,centroid. Boundaries will not be given a cat. Adding an area tries to put a centroid in the geographic mean, and if it fails it will exit, with nothing added. if you give many co-ordinates when adding a point many points will be generated. The cat support includes support for many cat's and ranges. This is for instance supported: v.edit map=test cat=267,347-350,353,356-359 coords=... And if there are more points then given cats, the cat will just be increased by one. The example above will result in 10 cats: 267,347,348,349,350,353,356,357,358 and 359. If you give 11 point the eleventh point will get the next cat (which is 360) --Wolf -- <:3 )---- Wolf Bergenheim ----( 8:> From glynn at gclements.plus.com Tue Jun 6 09:38:40 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jun 6 09:38:49 2006 Subject: [GRASS-dev] r.mapcalc operator precedence table In-Reply-To: <20060606052115.GA3460@localhost> References: <20060606033548.GA1401@localhost> <17541.2792.997224.768153@cerise.gclements.plus.com> <20060606052115.GA3460@localhost> Message-ID: <17541.12544.297132.927081@cerise.gclements.plus.com> Huidae Cho wrote: > > > While editing the operator precedence table in r.mapcalc.html, I found that > > > operators with higher precedence have HIGHER numbers. Shouldn't the highest > > > precedence have the lowest number or 1? > > > > That's the usual convention. > > You mean the convention is that the higher precedence has the higher number? I meant that your suggestion was the usual convention, but in retrospect it's less clear-cut. E.g. Haskell uses higher numbers for higher precedence: infixr 9 . infixl 9 !! infixr 8 ^, ^^, ** infixl 7 *, /, `quot`, `rem`, `div`, `mod`, :%, % infixl 6 +, - --infixr 5 : -- this fixity declaration is hard-wired into Hugs infixr 5 ++ infix 4 ==, /=, <, <=, >=, >, `elem`, `notElem` infixr 3 && infixr 2 || infixl 1 >>, >>= infixr 1 =<< infixr 0 $, $!, `seq` -- Glynn Clements From glynn at gclements.plus.com Tue Jun 6 09:46:29 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jun 6 09:47:39 2006 Subject: [GRASS-dev] New georectifying module in TclTk In-Reply-To: References: <17541.2598.746200.431865@cerise.gclements.plus.com> Message-ID: <17541.13013.905497.27525@cerise.gclements.plus.com> Michael Barton wrote: > Shows how little I understand C. This will help to try and follow out the > various transformations. Mainly I need the affine transformation. > > A question here. Is a single transformation used to generate the projected > points for RMS error calcuations? Or are different transformations used > depending on whether 1st, 2nd, or 3rd order is selected? i.points only understands affine (first-order) transformations, so that's what the error estimates assume. The 2nd- and 3rd-order transformations are specific to i.rectify, in imagery/i.rectify/crs.c. The problem with higher-order transformations is that you can't readily invert them, so you can only calculate the error in one direction. With regard to your subsequent message: > > I_compute_georef_equations() and I_georef() are both defined in > > lib/imagery/georef.c. -- Glynn Clements From glynn at gclements.plus.com Tue Jun 6 09:51:46 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jun 6 09:51:55 2006 Subject: [GRASS-dev] G_error in Vlib In-Reply-To: References: Message-ID: <17541.13330.198282.577228@cerise.gclements.plus.com> Wolf Bergenheim wrote: > I need G_error (function that does the same thing as G_fatal_error except > that it does not exit). Any objections to me adding it (as soon as I get > my CVS working again)? I think it can be good to have a possibility of > issuing an error message that doesn't call exit. That's essentially what G_warning() does. -- Glynn Clements From wolf+grass at bergenheim.net Tue Jun 6 09:54:54 2006 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Tue Jun 6 09:54:58 2006 Subject: [GRASS-dev] G_error in Vlib In-Reply-To: <17541.13330.198282.577228@cerise.gclements.plus.com> References: <17541.13330.198282.577228@cerise.gclements.plus.com> Message-ID: On Tue, 6 Jun 2006, Glynn Clements wrote: > > Wolf Bergenheim wrote: > >> I need G_error (function that does the same thing as G_fatal_error except >> that it does not exit). Any objections to me adding it (as soon as I get >> my CVS working again)? I think it can be good to have a possibility of >> issuing an error message that doesn't call exit. > > That's essentially what G_warning() does. > Yes but it puts a 'WARNING: '-prefix and not a 'ERROR: '-prefix. (; --W -- <:3 )---- Wolf Bergenheim ----( 8:> From glynn at gclements.plus.com Tue Jun 6 10:01:33 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jun 6 10:02:55 2006 Subject: [GRASS-dev] cvs gis.m error In-Reply-To: <20060606002232.52fa8f66@localhost.localdomain> References: <20060605091402.017cb373@localhost.localdomain> <20060606002232.52fa8f66@localhost.localdomain> Message-ID: <17541.13917.218436.910586@cerise.gclements.plus.com> Trevor Wiens wrote: > > I'm running Lorenzo's binaries of 27 May with no problems in general. Check > > in gronconsole to see if there are any errors reported there. > > It simply shows that the command d.mon start=gism -s > is still running. That's it. Stopping the existing display and opening > an new one doesn't resolve the problem. No errors, but also no display > either. > > When I modify the run command in runandoutput.tcl to stop sending > everything to /dev/ null, the following happens. The error appears > sooner with the message No such monitor gism on the command > d.mon stop=gism > > with the rest being pretty much as before. > > Hmm.... > > BTW, this makes me wonder about the wisdom of sending everything > to /dev/null. A session log file makes more sense to me. That's an option, as is redirecting to gis.m's stderr (typically the terminal) with "2>@stderr", but you have to redirect stderr somewhere. If a command spawned with exec or open writes anything to an unredirected stderr, Tcl will generate an error. -- Glynn Clements From jachym.cepicky at centrum.cz Tue Jun 6 11:43:05 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Tue Jun 6 11:44:09 2006 Subject: [GRASS-dev] v.edit In-Reply-To: References: Message-ID: <20060606094304.GE11405@gdf-hannover.de> Hallo, great work On Tue, Jun 06, 2006 at 10:30:47AM +0300, Wolf Bergenheim wrote: > Ok now v.edit's add functionality is completed. One can add > point,line,area,boundary,centroid. Boundaries will not be given a cat. > > Adding an area tries to put a centroid in the geographic mean, and if it > fails it will exit, with nothing added. > > if you give many co-ordinates when adding a point many points will be > generated. > > The cat support includes support for many cat's and ranges. This is for > instance supported: > v.edit map=test cat=267,347-350,353,356-359 coords=... > And if there are more points then given cats, the cat will just be > increased by one. The example above will result in 10 cats: > 267,347,348,349,350,353,356,357,358 and 359. If you give 11 point the > eleventh point will get the next cat (which is 360) > > --Wolf Why should a boundary NOT have category too? How would you distinguish two different types of boundary arround one area? Example on http://les-ejk.cz/tmp/boundaries.gif One country (Sachsen) has 2 different types of boundaries (country and state). I thing, it is usefull to have a possibility for adding category number (and attributes) to boundary too. Or do I understand it wrong? 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/20060606/ca659d97/attachment.bin From hamish_nospam at yahoo.com Tue Jun 6 12:00:15 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jun 6 12:00:22 2006 Subject: [GRASS-dev] cvs gis.m error In-Reply-To: <17541.13917.218436.910586@cerise.gclements.plus.com> References: <20060605091402.017cb373@localhost.localdomain> <20060606002232.52fa8f66@localhost.localdomain> <17541.13917.218436.910586@cerise.gclements.plus.com> Message-ID: <20060606220015.62402995.hamish_nospam@yahoo.com> Trevor: > > BTW, this makes me wonder about the wisdom of sending everything > > to /dev/null. A session log file makes more sense to me. I don't guess at how it would fit, but before someone goes to any trouble we already have one. (optional) see "GIS_ERROR_LOG": http://grass.ibiblio.org/grass61/manuals/html61_user/variables.html#files "touch ~/GIS_ERROR_LOG" to enable it. Hamish From wolf+grass at bergenheim.net Tue Jun 6 12:09:33 2006 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Tue Jun 6 12:09:36 2006 Subject: [GRASS-dev] v.edit In-Reply-To: <20060606094304.GE11405@gdf-hannover.de> References: <20060606094304.GE11405@gdf-hannover.de> Message-ID: On Tue, 6 Jun 2006, Jachym Cepicky wrote: > > Why should a boundary NOT have category too? How would you distinguish > two different types of boundary arround one area? Example on > At the moment because that is the way I coded, and I haven't seen a boundary with a cat yet. I can quite easily change it, if you think I should. While we are talking about all this. Is there any such thing as an open boundary (a line of type GV_BOUNDARY that has different first and last points? As I understand it boundaries are lines that define the shape of an area and the centroid marks the "inside" of the area. So that way boundaries are not really part of the area, but rather marks its extents. --W -- <:3 )---- Wolf Bergenheim ----( 8:> From hamish_nospam at yahoo.com Tue Jun 6 12:16:25 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jun 6 12:23:22 2006 Subject: [GRASS-dev] New georectifying module in TclTk In-Reply-To: References: <17541.2598.746200.431865@cerise.gclements.plus.com> Message-ID: <20060606221625.114ab975.hamish_nospam@yahoo.com> > Where is this procedure ( I_compute_georef_equations())? It isn't in > equ.c. I_*() are in lib/imagery/ G_*() are in lib/gis/ R_*() are in lib/raster/ etc $ cd lib/ $ grep -rI "I_compute_georef_equations" * imagery/georef.c:int I_compute_georef_equations( so it is in lib/imagery/georef.c Hamish From hamish_nospam at yahoo.com Tue Jun 6 12:35:32 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jun 6 12:36:52 2006 Subject: [GRASS-dev] New georectifying module in TclTk In-Reply-To: <20060606080119.90d8fdc0.werchowyna@epf.pl> References: <20060606080119.90d8fdc0.werchowyna@epf.pl> Message-ID: <20060606223532.2b6ffaf9.hamish_nospam@yahoo.com> Michael: > > (Is 3rd order georectification still broken?) Maciek: > Broken?! Can you elaborate on it? The last time I used i.rectify few > mnonths ago I only noticed that 2nd order output is somewhat strange > (map borders became convex, in general rectification result worse > than 1st and 3rd order), but 1st and 3rd produced a reasonable > output... see https://intevation.de/rt/webrt?serial_num=3166 related ? https://intevation.de/rt/webrt?serial_num=3052 also https://intevation.de/rt/webrt?serial_num=3296 I think GDAL order=3 will have the same problems, as both started from the same code. I didn't know order=2 had problems..? Michael: > > There has been some discussion about dropping i.rectify for > > gdalwarp. I?ve used i.rectify here, but it is probably possible to > > rewrite this to use gdalwarp in the future. I think we should keep i.rectify but use GDAL's warp API for the heavy lifting. (as opposed to the "gdalwarp" program) see https://intevation.de/rt/webrt?serial_num=2952 http://www.gdal.org/warptut.html Hamish From hamish_nospam at yahoo.com Tue Jun 6 12:44:54 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jun 6 12:45:42 2006 Subject: [GRASS-dev] G_error in Vlib In-Reply-To: References: <17541.13330.198282.577228@cerise.gclements.plus.com> Message-ID: <20060606224454.1bb7f81a.hamish_nospam@yahoo.com> Wolf: > >> I need G_error (function that does the same thing as G_fatal_error > >> except that it does not exit). Any objections to me adding it (as > >> soon as I get my CVS working again)? I think it can be good to have > >> a possibility of issuing an error message that doesn't call exit. Glynn: > > That's essentially what G_warning() does. > > Wolf: > Yes but it puts a 'WARNING: '-prefix and not a 'ERROR: '-prefix. (; So what's wrong with "WARNING:" ? what's the situation? what about: G_message("ERROR: zombies"); If it must happen, perhaps it should be called G_nonfatal_error() or something more explicit than G_error()? Hamish From wolf+grass at bergenheim.net Tue Jun 6 13:05:44 2006 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Tue Jun 6 13:05:52 2006 Subject: [GRASS-dev] G_error in Vlib In-Reply-To: <20060606224454.1bb7f81a.hamish_nospam@yahoo.com> References: <17541.13330.198282.577228@cerise.gclements.plus.com> <20060606224454.1bb7f81a.hamish_nospam@yahoo.com> Message-ID: On Tue, 6 Jun 2006, Hamish wrote: > Wolf: >>>> I need G_error (function that does the same thing as G_fatal_error >>>> except that it does not exit). Any objections to me adding it (as >>>> soon as I get my CVS working again)? I think it can be good to have >>>> a possibility of issuing an error message that doesn't call exit. > Glynn: >>> That's essentially what G_warning() does. >>> > Wolf: >> Yes but it puts a 'WARNING: '-prefix and not a 'ERROR: '-prefix. (; > > > So what's wrong with "WARNING:" ? what's the situation? > It is a fatal error but I can not use G_fatal_error because it calls exit, and I need to properly close the vector in v.edit. One such case is for instance that the DB connection fails. I still need to build the topology or else the vector file is broken (need to run v.build on it before you can continue). > what about: G_message("ERROR: zombies"); > Doesn't do the ERROR or WARN magic (like email etc.), and it doesn't beep ;) > > If it must happen, perhaps it should be called G_nonfatal_error() or > something more explicit than G_error()? > If you have G_error and G_fatal_error and both are documented, then it would be quite clear which does what? But if you like G_nonfatal_error better then I can live with it too. I don't really care that much about the function name, but I do care what it does (; --W -- <:3 )---- Wolf Bergenheim ----( 8:> From hamish_nospam at yahoo.com Tue Jun 6 13:15:53 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jun 6 13:16:37 2006 Subject: [GRASS-dev] v.edit In-Reply-To: <20060606094304.GE11405@gdf-hannover.de> References: <20060606094304.GE11405@gdf-hannover.de> Message-ID: <20060606231553.7add632a.hamish_nospam@yahoo.com> Jachym Cepicky wrote: > Why should a boundary NOT have category too? How would you distinguish > two different types of boundary arround one area? Example on > > http://les-ejk.cz/tmp/boundaries.gif > > One country (Sachsen) has 2 different types of boundaries (country and > state). > > I thing, it is usefull to have a possibility for adding category > number (and attributes) to boundary too. > > Or do I understand it wrong? It can have its uses. You can give a boundary a cat with v.category if you want. In general it isn't needed, and worse can subtly change things (like v.to.rast output) so should be used with caution. v.edit could have the power to add boundary cats, just leave it out of the GUI controls ;) Hamish From hamish_nospam at yahoo.com Tue Jun 6 13:21:42 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jun 6 13:22:20 2006 Subject: [GRASS-dev] G_error in Vlib In-Reply-To: References: <17541.13330.198282.577228@cerise.gclements.plus.com> <20060606224454.1bb7f81a.hamish_nospam@yahoo.com> Message-ID: <20060606232142.6317e5b6.hamish_nospam@yahoo.com> Wolf: > >>>> I need G_error (function that does the same thing as > >>>> G_fatal_error except that it does not exit). Any objections to me > >>>> adding it (as soon as I get my CVS working again)? I think it can > >>>> be good to have a possibility of issuing an error message that > >>>> doesn't call exit. Glynn: > >>> That's essentially what G_warning() does. > >>> Wolf: > >> Yes but it puts a 'WARNING: '-prefix and not a 'ERROR: '-prefix. (; > Hamish: > > So what's wrong with "WARNING:" ? what's the situation? > Wolf: > It is a fatal error but I can not use G_fatal_error because it calls > exit, and I need to properly close the vector in v.edit. One such > case is for instance that the DB connection fails. I still need to > build the topology or else the vector file is broken (need to run > v.build on it before you can continue). so when you detect an error call a cleanup function to sort out the mess, and have G_fatal_error() as the fn's last line? Hamish From hamish_nospam at yahoo.com Tue Jun 6 13:26:13 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jun 6 13:26:49 2006 Subject: [GRASS-dev] v.edit In-Reply-To: References: <20060606094304.GE11405@gdf-hannover.de> Message-ID: <20060606232613.5e8448bc.hamish_nospam@yahoo.com> > While we are talking about all this. Is there any such thing as an > open boundary (a line of type GV_BOUNDARY that has different first and > last points? As I understand it boundaries are lines that define the > shape of an area and the centroid marks the "inside" of the area. So > that way boundaries are not really part of the area, but rather marks > its extents. Yes, try making one with the (old) v.digit. (red endpoints). on exit: Topology was built. Number of nodes : 2 Number of primitives: 1 Number of points : 0 Number of lines : 0 Number of boundaries: 1 Number of centroids : 0 Number of areas : 0 Number of isles : 0 Number of incorrect boundaries : 1 Hamish From jachym.cepicky at centrum.cz Tue Jun 6 13:28:03 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Tue Jun 6 13:29:08 2006 Subject: [GRASS-dev] v.edit In-Reply-To: <20060606231553.7add632a.hamish_nospam@yahoo.com> References: <20060606094304.GE11405@gdf-hannover.de> <20060606231553.7add632a.hamish_nospam@yahoo.com> Message-ID: <20060606112802.GA929@gdf-hannover.de> Hi, On Tue, Jun 06, 2006 at 11:15:53PM +1200, Hamish wrote: > > It can have its uses. You can give a boundary a cat with v.category if > you want. > > In general it isn't needed, and worse can subtly change things (like > v.to.rast output) so should be used with caution. > > v.edit could have the power to add boundary cats, just leave it out of > the GUI controls ;) > > Hamish Did you see the last version of v.pydigit? Is that desired setting and behaviour ? 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/20060606/24d85911/attachment.bin From wolf+grass at bergenheim.net Tue Jun 6 13:31:55 2006 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Tue Jun 6 13:31:58 2006 Subject: [GRASS-dev] G_error in Vlib In-Reply-To: <20060606232142.6317e5b6.hamish_nospam@yahoo.com> References: <17541.13330.198282.577228@cerise.gclements.plus.com> <20060606224454.1bb7f81a.hamish_nospam@yahoo.com> <20060606232142.6317e5b6.hamish_nospam@yahoo.com> Message-ID: On Tue, 6 Jun 2006, Hamish wrote: > > so when you detect an error call a cleanup function to sort out the > mess, and have G_fatal_error() as the fn's last line? > Thing is I wanted to avoid making a cleanup function that takes an ellipsis (; but I guess I have no choice d: --W -- <:3 )---- Wolf Bergenheim ----( 8:> From hamish_nospam at yahoo.com Tue Jun 6 13:33:10 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jun 6 13:33:47 2006 Subject: [GRASS-dev] v.edit In-Reply-To: References: Message-ID: <20060606233310.5db5d3df.hamish_nospam@yahoo.com> Wolf wrote: > Adding an area tries to put a centroid in the geographic mean, and if > it fails it will exit, with nothing added. donut case? kidney shape ("C")? Use Vect_get_point_in_area() to find a centroid that is really in the area. see v.category add GV_AREA. [It tests for an existing one first with Vect_get_area_centroid()] the vector lib has most common tools aready.... Hamish From hamish_nospam at yahoo.com Tue Jun 6 13:36:23 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jun 6 13:37:00 2006 Subject: [GRASS-dev] Deleteing vector lines In-Reply-To: References: Message-ID: <20060606233623.3c435db5.hamish_nospam@yahoo.com> > What must be done to delete vector lines from a vector map? no answer, but maybe a hint: http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD section 1.1 Hamish From wolf+grass at bergenheim.net Tue Jun 6 13:48:49 2006 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Tue Jun 6 13:48:53 2006 Subject: [GRASS-dev] v.edit In-Reply-To: <20060606233310.5db5d3df.hamish_nospam@yahoo.com> References: <20060606233310.5db5d3df.hamish_nospam@yahoo.com> Message-ID: Hamish wrote: > Wolf wrote: >> Adding an area tries to put a centroid in the geographic mean, and if >> it fails it will exit, with nothing added. > > donut case? kidney shape ("C")? > Currently it will print an error message and exit. ): > > Use Vect_get_point_in_area() to find a centroid that is really in the > area. Thanks! I'll look in to it. (: --W -- <:3 )---- Wolf Bergenheim ----( 8:> From Roger.Bivand at nhh.no Tue Jun 6 14:14:42 2006 From: Roger.Bivand at nhh.no (Roger Bivand) Date: Tue Jun 6 14:11:48 2006 Subject: [GRASS-dev] G_error in Vlib In-Reply-To: Message-ID: On Tue, 6 Jun 2006, Wolf Bergenheim wrote: > On Tue, 6 Jun 2006, Hamish wrote: > > > Wolf: > >>>> I need G_error (function that does the same thing as G_fatal_error > >>>> except that it does not exit). Any objections to me adding it (as > >>>> soon as I get my CVS working again)? I think it can be good to have > >>>> a possibility of issuing an error message that doesn't call exit. > > Glynn: > >>> That's essentially what G_warning() does. > >>> > > Wolf: > >> Yes but it puts a 'WARNING: '-prefix and not a 'ERROR: '-prefix. (; > > > > > > So what's wrong with "WARNING:" ? what's the situation? > > > > It is a fatal error but I can not use G_fatal_error because it calls exit, > and I need to properly close the vector in v.edit. One such case is for > instance that the DB connection fails. I still need to build the topology > or else the vector file is broken (need to run v.build on it before you > can continue). In the orginal GRASS 5 compiled R interface, the error handling is passed to R for exactly this reason to avoid exit(). Then it was: void R_G_init(char *name) { G_set_error_routine(R_handler); G_sleep_on_error(0); G_gisinit(name); } int R_handler(char *message, int fatal) { if(fatal == 1) error(message); else warning(message); return(1); } where R_G_init() simply sets up the handler and the handler lets you set the appropriate actions. This of course assumes that your function does the clear-up, but G_set_error_routine() certainly worked very nicely in the 5.* codebase except where gislib functions called exit() directly - this was cleaned later I think by Radim. It is still in current CVS lib/gis, so I'd try it first, because it will also grab both GRASS errors and warnings thrown by GRASS functions your code calls. Roger > > > what about: G_message("ERROR: zombies"); > > > > Doesn't do the ERROR or WARN magic (like email etc.), and it doesn't beep ;) > > > > > If it must happen, perhaps it should be called G_nonfatal_error() or > > something more explicit than G_error()? > > > > If you have G_error and G_fatal_error and both are documented, then it > would be quite clear which does what? But if you like G_nonfatal_error > better then I can live with it too. I don't really care that much about > the function name, but I do care what it does (; > > --W > > -- Roger Bivand Economic Geography Section, Department of Economics, Norwegian School of Economics and Business Administration, Helleveien 30, N-5045 Bergen, Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43 e-mail: Roger.Bivand@nhh.no From epatton at nrcan.gc.ca Tue Jun 6 15:11:23 2006 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Tue Jun 6 15:11:27 2006 Subject: [GRASS-dev] DEM, natural neighbor interpolation and Grass Message-ID: <0E5A77B55A57D511BB3F0002A537C262064111AD@s5-dar-r1.nrn.nrcan.gc.ca> This is great, Maciek, thanks! I'll give it a try. ~ Eric. -----Original Message----- Sent: 6/5/2006 2:43 PM Subject: [GRASS-dev] DEM, natural neighbor interpolation and Grass Maybe some of you remember my notes about the nnbathy (a natural neighbor interpolation program), it's usability for producing DEMs from clustered, heterogenous input and it's complicated interaction with Grass. Maciek -------------------- From hamish_nospam at yahoo.com Tue Jun 6 16:23:22 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jun 6 16:23:30 2006 Subject: [GRASS-dev] v.in.dxf: support for 3DFACE? Message-ID: <20060607022322.0de1b938.hamish_nospam@yahoo.com> Hi, all excited to try out v.in.dxf :) but 3DFACE isn't implemented yet :( I can convert the DXF to a polyline version, and import with the new -f flag, but I need to run v.build before I can display it. After that I can do g.region v=, display with d.vect, & display in NVIZ (3D vector). Looking in v.info the x,y,z ranges are all 0,0. Note the final x,y ranges are both negative. (?) after import: | N: 0.000 S: 0.000 | | E: 0.000 W: 0.000 | | B: 0.000 T: 0.000 | after v.build: | N: -4816.565 S: -5951.313 | | E: -1943.884 W: -3092.723 | | B: -11.644 T: 54.011 | ?? Also it exits with "No DXF layers found!" for the 3DFACE import. This had me really puzzled as the layer does exist, it is just all of unknown feature types. Could the error message be improved? "... with data!" "Layers found with no features" "No features in layer" ??? Any plans for 3DFACE support? The wireframe is good stuff, but just a skeleton. :) http://www.autodesk.com/techpubs/autocad/acad2000/dxf/3dface_dxf_06.htm http://freegis.org/cgi-bin/viewcvs.cgi/grass6/vector/v.in.dwg/entity.c?rev=HEAD&content-type=text/vnd.viewcvs-markup thanks, Hamish From rez at touchofmadness.com Tue Jun 6 16:40:02 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Tue Jun 6 16:40:25 2006 Subject: [GRASS-dev] G_error in Vlib In-Reply-To: <17541.13330.198282.577228@cerise.gclements.plus.com> References: <17541.13330.198282.577228@cerise.gclements.plus.com> Message-ID: <1149604802.12998.206.camel@devel> On Tue, 2006-06-06 at 08:51 +0100, Glynn Clements wrote: > Wolf Bergenheim wrote: > > > I need G_error (function that does the same thing as G_fatal_error except > > that it does not exit). Any objections to me adding it (as soon as I get > > my CVS working again)? I think it can be good to have a possibility of > > issuing an error message that doesn't call exit. > > That's essentially what G_warning() does. There's always G_set_error_routine()... -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From grass4u at gmail.com Tue Jun 6 17:16:03 2006 From: grass4u at gmail.com (Huidae Cho) Date: Tue Jun 6 17:16:24 2006 Subject: [GRASS-dev] Re: v.in.dxf: support for 3DFACE? In-Reply-To: <20060607022322.0de1b938.hamish_nospam@yahoo.com> References: <20060607022322.0de1b938.hamish_nospam@yahoo.com> Message-ID: <20060606151602.GA2063@localhost.tamu.edu> Hamish, On Wed, Jun 07, 2006 at 02:23:22AM +1200, Hamish wrote: > Hi, > > all excited to try out v.in.dxf :) but 3DFACE isn't implemented yet :( > > I can convert the DXF to a polyline version, and import with the new -f > flag, but I need to run v.build before I can display it. After that I I fixed this bug. > can do g.region v=, display with d.vect, & display in NVIZ (3D vector). > > Looking in v.info the x,y,z ranges are all 0,0. > Note the final x,y ranges are both negative. (?) > > after import: > | N: 0.000 S: 0.000 | > | E: 0.000 W: 0.000 | > | B: 0.000 T: 0.000 | > after v.build: > | N: -4816.565 S: -5951.313 | > | E: -1943.884 W: -3092.723 | > | B: -11.644 T: 54.011 | > Well, I think usual coordinates in DXF are not geographic coordinates, but it depends on DXF files. > ?? > > > Also it exits with "No DXF layers found!" for the 3DFACE import. > This had me really puzzled as the layer does exist, it is just all > of unknown feature types. Could the error message be improved? > "... with data!" > "Layers found with no features" > "No features in layer" > ??? v.in.dxf does not count layers it cannot import. > > > Any plans for 3DFACE support? The wireframe is good stuff, but just a > skeleton. :) > > http://www.autodesk.com/techpubs/autocad/acad2000/dxf/3dface_dxf_06.htm > > http://freegis.org/cgi-bin/viewcvs.cgi/grass6/vector/v.in.dwg/entity.c?rev=HEAD&content-type=text/vnd.viewcvs-markup Could you send me a sample DXF for 3DFACE and its screenshot? Thank you. Huidae Cho From michael.barton at asu.edu Tue Jun 6 17:28:14 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jun 6 17:28:24 2006 Subject: [GRASS-dev] New georectifying module in TclTk In-Reply-To: <17541.13013.905497.27525@cerise.gclements.plus.com> Message-ID: Thanks. That is helpful. It will be certainly easier if I only am doing rms calculations using one equation. Still, I wonder can minimizing errors using an affine transformation produce poorer results for polynomial transformations? Also, in responding to my own comment yesterday... I looked at gdalwarp last night and I'm not sure it could replace i.rectify as is. If there is someway to specify a set of GCP's that are not embedded in the raster file format, I didn't see it in the docs. Also, I didn't see any way of using it to do error calculations (though this might be moot). GDAL will also need to to GRASS to GRASS file formats. I know this was a problem awhile back, but perhaps it is not one now. More interestingly, it might be more possible to wrap v.transform into the georectifier so that it will do both raster and vector files, if this is of any interest to people. 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: Tue, 6 Jun 2006 08:46:29 +0100 > To: Michael Barton > Cc: Helena Mitasova , GRASS developers list > > Subject: Re: [GRASS-dev] New georectifying module in TclTk > > > Michael Barton wrote: > >> Shows how little I understand C. This will help to try and follow out the >> various transformations. Mainly I need the affine transformation. >> >> A question here. Is a single transformation used to generate the projected >> points for RMS error calcuations? Or are different transformations used >> depending on whether 1st, 2nd, or 3rd order is selected? > > i.points only understands affine (first-order) transformations, so > that's what the error estimates assume. > > The 2nd- and 3rd-order transformations are specific to i.rectify, in > imagery/i.rectify/crs.c. > > The problem with higher-order transformations is that you can't > readily invert them, so you can only calculate the error in one > direction. > > With regard to your subsequent message: > >>> I_compute_georef_equations() and I_georef() are both defined in >>> lib/imagery/georef.c. > > -- > Glynn Clements From michael.barton at asu.edu Tue Jun 6 17:32:35 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jun 6 17:32:45 2006 Subject: [GRASS-dev] v.edit In-Reply-To: Message-ID: This sounds great. 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: Wolf Bergenheim > Date: Tue, 6 Jun 2006 10:30:47 +0300 (EEST) > To: GRASS developers list > Subject: [GRASS-dev] v.edit > > Ok now v.edit's add functionality is completed. One can add > point,line,area,boundary,centroid. Boundaries will not be given a cat. > > Adding an area tries to put a centroid in the geographic mean, and if it > fails it will exit, with nothing added. > > if you give many co-ordinates when adding a point many points will be > generated. > > The cat support includes support for many cat's and ranges. This is for > instance supported: > v.edit map=test cat=267,347-350,353,356-359 coords=... > And if there are more points then given cats, the cat will just be > increased by one. The example above will result in 10 cats: > 267,347,348,349,350,353,356,357,358 and 359. If you give 11 point the > eleventh point will get the next cat (which is 360) > > --Wolf > > -- > > <:3 )---- Wolf Bergenheim ----( 8:> > > From michael.barton at asu.edu Tue Jun 6 17:42:27 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jun 6 17:42:38 2006 Subject: [GRASS-dev] v.edit In-Reply-To: <20060606094304.GE11405@gdf-hannover.de> Message-ID: Jachym, See 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: Jachym Cepicky > Date: Tue, 6 Jun 2006 11:43:05 +0200 > To: Wolf Bergenheim > Cc: GRASS developers list > Subject: Re: [GRASS-dev] v.edit > > Hallo, > > great work > > On Tue, Jun 06, 2006 at 10:30:47AM +0300, Wolf Bergenheim wrote: >> Ok now v.edit's add functionality is completed. One can add >> point,line,area,boundary,centroid. Boundaries will not be given a cat. >> >> Adding an area tries to put a centroid in the geographic mean, and if it >> fails it will exit, with nothing added. >> >> if you give many co-ordinates when adding a point many points will be >> generated. >> >> The cat support includes support for many cat's and ranges. This is for >> instance supported: >> v.edit map=test cat=267,347-350,353,356-359 coords=... >> And if there are more points then given cats, the cat will just be >> increased by one. The example above will result in 10 cats: >> 267,347,348,349,350,353,356,357,358 and 359. If you give 11 point the >> eleventh point will get the next cat (which is 360) >> >> --Wolf > > Why should a boundary NOT have category too? How would you distinguish > two different types of boundary arround one area? Example on > > http://les-ejk.cz/tmp/boundaries.gif > > One country (Sachsen) has 2 different types of boundaries (country and > state). You can also think of this conceptually as 2 different areas (country and state) that overlay. Or the area can simply have 2 attributes or even 2 layers (a state layer and a country layer). So there are a number of ways to represent this situation. As I said earlier, while it sometimes might be convenient for a boundary to have a cat (with possibility of attributes) separate from that of an area, I think it is better to make boundaries different from lines. A line can be open or closed, has a cat and attributes. It is a vector entity. A boundary, while internally structured like a line, is part of a complex entity called area. The complex area entity is composed of a closed line and a point, and has a single cat for the closed line/point pair. I think this kind of definition would make entity creation and management easier than it is now. A boundary that is not part of an area and is not a closed line is an odd, confusing entity IMHO. Could be convenient, I admit, but I think that we are better off without it. Michael > > I thing, it is usefull to have a possibility for adding category number > (and attributes) to boundary too. > > Or do I understand it wrong? > > 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 From michael.barton at asu.edu Tue Jun 6 17:48:56 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jun 6 17:49:02 2006 Subject: [GRASS-dev] Re: v.in.dxf: support for 3DFACE? In-Reply-To: <20060606151602.GA2063@localhost.tamu.edu> Message-ID: I haven't kept up with v.in.dxf since initially testing it and cheering its incorporation into GRASS 6. But I'll be needing it soon and some of my colleagues are using it quite a bit. Is there a way to maintain a dxf entity attribute as a cat/attribute for areas? The object it to avoid going through the complication of converting lines to boundaries, adding centroids, adding cats, and linking cats with attributes. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Huidae Cho > Date: Tue, 6 Jun 2006 10:16:03 -0500 > To: Hamish > Cc: grass5 > Subject: [GRASS-dev] Re: v.in.dxf: support for 3DFACE? > > Hamish, > > On Wed, Jun 07, 2006 at 02:23:22AM +1200, Hamish wrote: >> Hi, >> >> all excited to try out v.in.dxf :) but 3DFACE isn't implemented yet :( >> >> I can convert the DXF to a polyline version, and import with the new -f >> flag, but I need to run v.build before I can display it. After that I > > I fixed this bug. > >> can do g.region v=, display with d.vect, & display in NVIZ (3D vector). >> >> Looking in v.info the x,y,z ranges are all 0,0. >> Note the final x,y ranges are both negative. (?) >> >> after import: >> | N: 0.000 S: 0.000 | >> | E: 0.000 W: 0.000 | >> | B: 0.000 T: 0.000 | >> after v.build: >> | N: -4816.565 S: -5951.313 | >> | E: -1943.884 W: -3092.723 | >> | B: -11.644 T: 54.011 | >> > > Well, I think usual coordinates in DXF are not geographic coordinates, but it > depends on DXF files. > >> ?? >> >> >> Also it exits with "No DXF layers found!" for the 3DFACE import. >> This had me really puzzled as the layer does exist, it is just all >> of unknown feature types. Could the error message be improved? >> "... with data!" >> "Layers found with no features" >> "No features in layer" >> ??? > > v.in.dxf does not count layers it cannot import. > >> >> >> Any plans for 3DFACE support? The wireframe is good stuff, but just a >> skeleton. :) >> >> http://www.autodesk.com/techpubs/autocad/acad2000/dxf/3dface_dxf_06.htm >> >> >> http://freegis.org/cgi-bin/viewcvs.cgi/grass6/vector/v.in.dwg/entity.c?rev=HE >> AD&content-type=text/vnd.viewcvs-markup > > Could you send me a sample DXF for 3DFACE and its screenshot? > > Thank you. > Huidae Cho > > From werchowyna at epf.pl Tue Jun 6 17:58:06 2006 From: werchowyna at epf.pl (Maciek Sieczka) Date: Tue Jun 6 17:58:04 2006 Subject: [GRASS-dev] New georectifying module in TclTk In-Reply-To: References: <17541.13013.905497.27525@cerise.gclements.plus.com> Message-ID: <20060606175806.9d13ae12.werchowyna@epf.pl> On Tue, 06 Jun 2006 08:28:14 -0700 Michael Barton wrote: > Thanks. That is helpful. It will be certainly easier if I only am > doing rms calculations using one equation. Still, I wonder can > minimizing errors using an affine transformation produce poorer > results for polynomial transformations? > > Also, in responding to my own comment yesterday... I looked at > gdalwarp last night and I'm not sure it could replace i.rectify as > is. If there is someway to specify a set of GCP's that are not > embedded in the raster file format, I didn't see it in the docs. 1. 'gdal_translate -gcp' to add GCPs to raster 2. 'gdalwarp' to warp using those GCPs > Also, I didn't see any way of using it to do error calculations > (though this might be moot). Not in the verbose gdalwarp output AFAIK. > GDAL will also need to to GRASS to GRASS > file formats. I know this was a problem awhile back, but perhaps it > is not one now. AFAIK Grass raster and vectors are supported only for reading. I've been using it for e.g. QGIS and it works very good. > More interestingly, it might be more possible to wrap v.transform > into the georectifier so that it will do both raster and vector > files, if this is of any interest to people. Maybe a good idea. If this also enables us to overlay raster and vector in the reference window, to select GCPs for raster from vectors and vice versa, it could be really usefull. Maciek -------------------- W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich! http://katalog.panoramainternetu.pl/ From grass4u at gmail.com Tue Jun 6 18:24:06 2006 From: grass4u at gmail.com (Huidae Cho) Date: Tue Jun 6 18:24:27 2006 Subject: [GRASS-dev] Re: v.in.dxf: support for 3DFACE? In-Reply-To: References: <20060606151602.GA2063@localhost.tamu.edu> Message-ID: <20060606162406.GA18500@localhost.tamu.edu> On Tue, Jun 06, 2006 at 08:48:56AM -0700, Michael Barton wrote: > I haven't kept up with v.in.dxf since initially testing it and cheering its > incorporation into GRASS 6. But I'll be needing it soon and some of my > colleagues are using it quite a bit. > > Is there a way to maintain a dxf entity attribute as a cat/attribute for > areas? The object it to avoid going through the complication of converting > lines to boundaries, adding centroids, adding cats, and linking cats with > attributes. I'll add the ENTITY column some time later. Huidae Cho > > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > > > From: Huidae Cho > > Date: Tue, 6 Jun 2006 10:16:03 -0500 > > To: Hamish > > Cc: grass5 > > Subject: [GRASS-dev] Re: v.in.dxf: support for 3DFACE? > > > > Hamish, > > > > On Wed, Jun 07, 2006 at 02:23:22AM +1200, Hamish wrote: > >> Hi, > >> > >> all excited to try out v.in.dxf :) but 3DFACE isn't implemented yet :( > >> > >> I can convert the DXF to a polyline version, and import with the new -f > >> flag, but I need to run v.build before I can display it. After that I > > > > I fixed this bug. > > > >> can do g.region v=, display with d.vect, & display in NVIZ (3D vector). > >> > >> Looking in v.info the x,y,z ranges are all 0,0. > >> Note the final x,y ranges are both negative. (?) > >> > >> after import: > >> | N: 0.000 S: 0.000 | > >> | E: 0.000 W: 0.000 | > >> | B: 0.000 T: 0.000 | > >> after v.build: > >> | N: -4816.565 S: -5951.313 | > >> | E: -1943.884 W: -3092.723 | > >> | B: -11.644 T: 54.011 | > >> > > > > Well, I think usual coordinates in DXF are not geographic coordinates, but it > > depends on DXF files. > > > >> ?? > >> > >> > >> Also it exits with "No DXF layers found!" for the 3DFACE import. > >> This had me really puzzled as the layer does exist, it is just all > >> of unknown feature types. Could the error message be improved? > >> "... with data!" > >> "Layers found with no features" > >> "No features in layer" > >> ??? > > > > v.in.dxf does not count layers it cannot import. > > > >> > >> > >> Any plans for 3DFACE support? The wireframe is good stuff, but just a > >> skeleton. :) > >> > >> http://www.autodesk.com/techpubs/autocad/acad2000/dxf/3dface_dxf_06.htm > >> > >> > >> http://freegis.org/cgi-bin/viewcvs.cgi/grass6/vector/v.in.dwg/entity.c?rev=HE > >> AD&content-type=text/vnd.viewcvs-markup > > > > Could you send me a sample DXF for 3DFACE and its screenshot? > > > > Thank you. > > Huidae Cho > > > > > From david.p.finlayson at gmail.com Tue Jun 6 19:01:17 2006 From: david.p.finlayson at gmail.com (David Finlayson) Date: Tue Jun 6 19:01:21 2006 Subject: [GRASS-dev] v.edit In-Reply-To: References: <20060606094304.GE11405@gdf-hannover.de> Message-ID: I agree with Michael. I think that we should strive to make the topologic model as orthogonal as possible. More importantly, it should be easy to understand and implement. Tools should enforce the model not add to the confusion. One of the problems of operational GIS are broken/unclean topology. If we need more sophisticated topological entities than point, line, area; then we should develop a higher-order topologic model that is built out of the three primitive objects rather than hack the simple model. For example, boundary lines for a single area with distinct categories are merging the behavior of line entity with the area entity. I think that is confusing. On 6/6/06, Michael Barton wrote: > Jachym, > > See 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: Jachym Cepicky > > Date: Tue, 6 Jun 2006 11:43:05 +0200 > > To: Wolf Bergenheim > > Cc: GRASS developers list > > Subject: Re: [GRASS-dev] v.edit > > > > Hallo, > > > > great work > > > > On Tue, Jun 06, 2006 at 10:30:47AM +0300, Wolf Bergenheim wrote: > >> Ok now v.edit's add functionality is completed. One can add > >> point,line,area,boundary,centroid. Boundaries will not be given a cat. > >> > >> Adding an area tries to put a centroid in the geographic mean, and if it > >> fails it will exit, with nothing added. > >> > >> if you give many co-ordinates when adding a point many points will be > >> generated. > >> > >> The cat support includes support for many cat's and ranges. This is for > >> instance supported: > >> v.edit map=test cat=267,347-350,353,356-359 coords=... > >> And if there are more points then given cats, the cat will just be > >> increased by one. The example above will result in 10 cats: > >> 267,347,348,349,350,353,356,357,358 and 359. If you give 11 point the > >> eleventh point will get the next cat (which is 360) > >> > >> --Wolf > > > > Why should a boundary NOT have category too? How would you distinguish > > two different types of boundary arround one area? Example on > > > > http://les-ejk.cz/tmp/boundaries.gif > > > > One country (Sachsen) has 2 different types of boundaries (country and > > state). > > You can also think of this conceptually as 2 different areas (country and > state) that overlay. Or the area can simply have 2 attributes or even 2 > layers (a state layer and a country layer). So there are a number of ways > to represent this situation. > > As I said earlier, while it sometimes might be convenient for a boundary to > have a cat (with possibility of attributes) separate from that of an area, I > think it is better to make boundaries different from lines. > > A line can be open or closed, has a cat and attributes. It is a vector > entity. > > A boundary, while internally structured like a line, is part of a complex > entity called area. The complex area entity is composed of a closed line and > a point, and has a single cat for the closed line/point pair. > > I think this kind of definition would make entity creation and management > easier than it is now. A boundary that is not part of an area and is not a > closed line is an odd, confusing entity IMHO. Could be convenient, I admit, > but I think that we are better off without it. > > Michael > > > > I thing, it is usefull to have a possibility for adding category number > > (and attributes) to boundary too. > > > > Or do I understand it wrong? > > > > 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 > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- David Finlayson From michael.barton at asu.edu Tue Jun 6 19:10:39 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jun 6 19:10:50 2006 Subject: [GRASS-dev] Re: v.in.dxf: support for 3DFACE? In-Reply-To: <20060606162406.GA18500@localhost.tamu.edu> Message-ID: Thanks. I'm passing this on to one of my colleagues who needs it right away. 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: Huidae Cho > Date: Tue, 6 Jun 2006 11:24:06 -0500 > To: Michael Barton > Cc: Hamish , grass5 , Andrea > Moreno Martin > Subject: Re: [GRASS-dev] Re: v.in.dxf: support for 3DFACE? > > On Tue, Jun 06, 2006 at 08:48:56AM -0700, Michael Barton wrote: >> I haven't kept up with v.in.dxf since initially testing it and cheering its >> incorporation into GRASS 6. But I'll be needing it soon and some of my >> colleagues are using it quite a bit. >> >> Is there a way to maintain a dxf entity attribute as a cat/attribute for >> areas? The object it to avoid going through the complication of converting >> lines to boundaries, adding centroids, adding cats, and linking cats with >> attributes. > > I'll add the ENTITY column some time later. > > Huidae Cho > >> >> Michael >> __________________________________________ >> Michael Barton, Professor of Anthropology >> School of Human Evolution & Social Change >> Center for Social Dynamics & Complexity >> Arizona State University >> >> phone: 480-965-6213 >> fax: 480-965-7671 >> www: http://www.public.asu.edu/~cmbarton >> >> >> >>> From: Huidae Cho >>> Date: Tue, 6 Jun 2006 10:16:03 -0500 >>> To: Hamish >>> Cc: grass5 >>> Subject: [GRASS-dev] Re: v.in.dxf: support for 3DFACE? >>> >>> Hamish, >>> >>> On Wed, Jun 07, 2006 at 02:23:22AM +1200, Hamish wrote: >>>> Hi, >>>> >>>> all excited to try out v.in.dxf :) but 3DFACE isn't implemented yet :( >>>> >>>> I can convert the DXF to a polyline version, and import with the new -f >>>> flag, but I need to run v.build before I can display it. After that I >>> >>> I fixed this bug. >>> >>>> can do g.region v=, display with d.vect, & display in NVIZ (3D vector). >>>> >>>> Looking in v.info the x,y,z ranges are all 0,0. >>>> Note the final x,y ranges are both negative. (?) >>>> >>>> after import: >>>> | N: 0.000 S: 0.000 | >>>> | E: 0.000 W: 0.000 | >>>> | B: 0.000 T: 0.000 | >>>> after v.build: >>>> | N: -4816.565 S: -5951.313 | >>>> | E: -1943.884 W: -3092.723 | >>>> | B: -11.644 T: 54.011 | >>>> >>> >>> Well, I think usual coordinates in DXF are not geographic coordinates, but >>> it >>> depends on DXF files. >>> >>>> ?? >>>> >>>> >>>> Also it exits with "No DXF layers found!" for the 3DFACE import. >>>> This had me really puzzled as the layer does exist, it is just all >>>> of unknown feature types. Could the error message be improved? >>>> "... with data!" >>>> "Layers found with no features" >>>> "No features in layer" >>>> ??? >>> >>> v.in.dxf does not count layers it cannot import. >>> >>>> >>>> >>>> Any plans for 3DFACE support? The wireframe is good stuff, but just a >>>> skeleton. :) >>>> >>>> http://www.autodesk.com/techpubs/autocad/acad2000/dxf/3dface_dxf_06.htm >>>> >>>> >>>> http://freegis.org/cgi-bin/viewcvs.cgi/grass6/vector/v.in.dwg/entity.c?rev= >>>> HE >>>> AD&content-type=text/vnd.viewcvs-markup >>> >>> Could you send me a sample DXF for 3DFACE and its screenshot? >>> >>> Thank you. >>> Huidae Cho >>> >>> >> From michael.barton at asu.edu Tue Jun 6 19:30:47 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jun 6 19:30:59 2006 Subject: [GRASS-dev] New georectifying module in TclTk In-Reply-To: <20060606223532.2b6ffaf9.hamish_nospam@yahoo.com> Message-ID: Hamish, It sounds like most of the issues can be avoided by using i.rectify -c. What are the disadvantages of using the -c switch? It is not very clear (to me) in the docs. 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: Tue, 6 Jun 2006 22:35:32 +1200 > To: Maciek Sieczka > Cc: , > Subject: Re: [GRASS-dev] New georectifying module in TclTk > > Michael: >>> (Is 3rd order georectification still broken?) > Maciek: >> Broken?! Can you elaborate on it? The last time I used i.rectify few >> mnonths ago I only noticed that 2nd order output is somewhat strange >> (map borders became convex, in general rectification result worse >> than 1st and 3rd order), but 1st and 3rd produced a reasonable >> output... > > see > https://intevation.de/rt/webrt?serial_num=3166 > related ? > https://intevation.de/rt/webrt?serial_num=3052 > > also > https://intevation.de/rt/webrt?serial_num=3296 > > I think GDAL order=3 will have the same problems, as both started from > the same code. > > I didn't know order=2 had problems..? > > > > Michael: >>> There has been some discussion about dropping i.rectify for >>> gdalwarp. I?ve used i.rectify here, but it is probably possible to >>> rewrite this to use gdalwarp in the future. > > I think we should keep i.rectify but use GDAL's warp API for the heavy > lifting. (as opposed to the "gdalwarp" program) > > see > https://intevation.de/rt/webrt?serial_num=2952 > http://www.gdal.org/warptut.html > > > Hamish From michael.barton at asu.edu Tue Jun 6 19:37:55 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jun 6 19:38:13 2006 Subject: [GRASS-dev] New georectifying module in TclTk In-Reply-To: <17541.2598.746200.431865@cerise.gclements.plus.com> Message-ID: For RMS error calculation, I just need to use either the forward or reverse, right? I don't see where I need both directions. 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: Glynn Clements > Date: Tue, 6 Jun 2006 05:52:54 +0100 > To: Michael Barton > Cc: Helena Mitasova , GRASS developers list > > Subject: Re: [GRASS-dev] New georectifying module in TclTk > > compute_transformation() starts by calling Compute_equation() (in > imagery/i.points/equ.c), which calls I_compute_georef_equations(). > That computes the best-fit affine transformation (forward and inverse) > from the control points. From glynn at gclements.plus.com Tue Jun 6 23:01:20 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jun 6 23:02:58 2006 Subject: [GRASS-dev] New georectifying module in TclTk In-Reply-To: References: <17541.13013.905497.27525@cerise.gclements.plus.com> Message-ID: <17541.60704.188971.539468@cerise.gclements.plus.com> Michael Barton wrote: > Thanks. That is helpful. It will be certainly easier if I only am doing rms > calculations using one equation. Still, I wonder can minimizing errors using > an affine transformation produce poorer results for polynomial > transformations? If you intend to use a polynomial transformation, the error measurements for an affine transformation aren't really relevant. In any case, the error measurement is only really useful to Note that the fitting and measurement performed by i.points has no effect upon the transformation chosen by i.rectify. It's just giving the user an idea of what to expect from i.rectify (assuming that an affine transformation is used), as well as highlighting points which the user might have misplaced. > Also, in responding to my own comment yesterday... I looked at gdalwarp last > night and I'm not sure it could replace i.rectify as is. If there is someway > to specify a set of GCP's that are not embedded in the raster file format, I > didn't see it in the docs. Also, I didn't see any way of using it to do > error calculations (though this might be moot). GDAL will also need to to > GRASS to GRASS file formats. I know this was a problem awhile back, but > perhaps it is not one now. It would be useful if the same front-end could be used for both i.rectify and gdalwarp. The main issue is that you need a way to compute the best-fit transformation from the control points and to project sample points without actually transformating the entire image. > More interestingly, it might be more possible to wrap v.transform into the > georectifier so that it will do both raster and vector files, if this is of > any interest to people. v.transform also uses an affine transform. Non-affine transformations on vectors are awkward as they transform straight line segments to curve segments. Also, vector transformations are normally done in the opposite direction to raster transformations. -- Glynn Clements From glynn at gclements.plus.com Tue Jun 6 23:12:40 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jun 6 23:21:29 2006 Subject: [GRASS-dev] New georectifying module in TclTk In-Reply-To: References: <17541.2598.746200.431865@cerise.gclements.plus.com> Message-ID: <17541.61384.459954.890990@cerise.gclements.plus.com> Michael Barton wrote: > For RMS error calculation, I just need to use either the forward or reverse, > right? I don't see where I need both directions. You probably don't really need both, at least for an affine transformation. The diagonal error computed in one direction will be proportional to that computed in the other direction. The same doesn't apply for the x and y error, though. For polynomial transformations, the situation is more complex. The inverse of a polynomial transformation isn't itself a polynomial transformation. Or, to put it another way, the best-fit reverse transformation won't be the inverse of the best-fit forward transformation. At the very least, you need to make sure to use the correct direction (rasters are usually transformed by projecting coordinates from the target location into the image's X/Y coordinate system; at least, that's how r.proj works). It might help to compute the error both ways to provide an idea of how good a fit the transformation is. A transformation which accurately maps a minimal set of control points won't necessarily accurately map the entire region. -- Glynn Clements From michael.barton at asu.edu Wed Jun 7 06:13:33 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Jun 7 06:13:53 2006 Subject: [GRASS-dev] Request to add a GCP file in vector directories Message-ID: I?m integrating vector georectification (v.transform) into the GIS Manager georectifier. It would be nice if a GCP file could be saved in a vector folder so that it could be called up, edited, and reused and a user doesn?t have to re-enter GCP?s every time they start the georectifier. This is the case now for rasters, because a GCP file (POINTS) is saved inside the group folder for a raster group. I?m proposing to have the georectifier (at the user?s option) save a file named ?gcp? (points might be confusing in a vector folder) in the appropriate vector folder to be rectified. It would be a simple ascii text file and take the format of the standard file needed by v.transform, with the addition of a header indicating the target location and mapset it is aimed at. For example... # target: /Users/shared/grassdata/spearfish60/newvector -584 585 598000 4920770 580 585 598020 4920770 580 -600 598020 4920750 -584 -600 598000 4920750 Does anyone foresee a problem with 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060606/2ea66b4d/attachment.html From glynn at gclements.plus.com Wed Jun 7 08:33:32 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Jun 7 08:34:26 2006 Subject: [GRASS-dev] Request to add a GCP file in vector directories In-Reply-To: References: Message-ID: <17542.29500.100441.162381@cerise.gclements.plus.com> Michael Barton wrote: > I'm integrating vector georectification (v.transform) into the GIS Manager > georectifier. It would be nice if a GCP file could be saved in a vector > folder so that it could be called up, edited, and reused and a user doesn't > have to re-enter GCP's every time they start the georectifier. This is the > case now for rasters, because a GCP file (POINTS) is saved inside the group > folder for a raster group. > > I'm proposing to have the georectifier (at the user's option) save a file > named ?gcp? (points might be confusing in a vector folder) in the > appropriate vector folder to be rectified. It would be a simple ascii text > file and take the format of the standard file needed by v.transform, with > the addition of a header indicating the target location and mapset it is > aimed at. For example... > > # target: /Users/shared/grassdata/spearfish60/newvector > -584 585 598000 4920770 > 580 585 598020 4920770 > 580 -600 598020 4920750 > -584 -600 598000 4920750 > > Does anyone foresee a problem with this? Unlike i.rectify, v.transform doesn't operate upon maps from a different location. You have to get the source map into the current location first. [On the last point, g.copy should probably have an option to allow data to be copied from different locations or even from different database directories.] Also, transformations are arguably a property of a location rather than a specific map. If you had a number of maps, all in the same (unspecified) coordinate system, you would probably want to use the same transformation for all of them. AFAICT, the POINTS file is just an artifact of the i.points/i.rectify workflow. The data just needed to be stored somewhere, and not much thought was really given to the details. It's arguable that GCP files should be a separate entity, similar to e.g. named regions. Also, it might be useful to allow global GCP files for an X-Y location which specify the transformations to/from lat-lon. Adding support for arbitrary polynomial transformations to libproj would allow you to use *.proj to project to/from X-Y locations. -- Glynn Clements From michael.barton at asu.edu Wed Jun 7 08:48:35 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Jun 7 08:48:46 2006 Subject: [GRASS-dev] Request to add a GCP file in vector directories In-Reply-To: <17542.29500.100441.162381@cerise.gclements.plus.com> Message-ID: > From: Glynn Clements > Date: Wed, 7 Jun 2006 07:33:32 +0100 > To: Michael Barton > Cc: grass5 > Subject: Re: [GRASS-dev] Request to add a GCP file in vector directories > > Unlike i.rectify, v.transform doesn't operate upon maps from a > different location. You have to get the source map into the current > location first. True. I.target can also be set to the current location/mapset. For consistency, the georectifier can operate on maps (raster and vector) from other locations and the same location (I'm adding this part now). > > [On the last point, g.copy should probably have an option to allow > data to be copied from different locations or even from different > database directories.] This would be nice as long it wasn't misused (e.g., copying a raster from a latlon location to a utm location) > > Also, transformations are arguably a property of a location rather > than a specific map. If you had a number of maps, all in the same > (unspecified) coordinate system, you would probably want to use the > same transformation for all of them. This is a good point. Should a generic gcp file just be stored in PERMANENT? What about maps with different extents--especially non-overlapping maps--in the same location? 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 grass-bugs at intevation.de Wed Jun 7 09:49:42 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Wed Jun 7 09:49:44 2006 Subject: [GRASS-dev] [bug #4546] (grass) r.sim.water segmentation fault Message-ID: <20060607074942.203DE1005AC@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4546 ------------------------------------------------------------------------- Subject: r.sim.water segmentation fault Platform: GNU/Linux/x86_64 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: grass-6.1.cvs_src_snapshot_2006_06_03 when running r.sim.water by: ----------------- GRASS 6.1.cvs (spearfish60):~ > r.sim.water elevin=elevation.10m dxin=elevation.10m_dx dyin=elevation.10m_dy rain=elevation.10m_rain manin=elevation.10m_manin infil=elevation.10m_infil depth=elevation.10m_depth disch=elevation.10m_disch ----------------- it stops with output: ------------------ Authors: original version L.Mitas, H.Mitasova GRASS implementation J. Hofierka see references in manual page or at: http://www2.gis.uiuc.edu:2280/modviz/papers/listsj.html Running MAY 10 version Segmentation fault ------------------- This applies to many 6.x versions (including stable) and also to 32bit installations (including precompiled ones). The input maps "rain", "manin" and "infil" have been created artificially as constant fields by the following script: ------------------- #!/bin/sh dem=elevation.10m g.region rast=${dem} r.slope.aspect --o elevation=$dem dx=${dem}_dx dy=${dem}_dy r.mapcalc "${dem}_rain=if(${dem},0.0001,null())" r.mapcalc "${dem}_manin=if(${dem},0.04,null())" r.mapcalc "${dem}_infil=if(${dem},0.9,null())" echo r.sim.water elevin=${dem} dxin=${dem}_dx dyin=${dem}_dy \ rain=${dem}_rain manin=${dem}_manin infil=${dem}_infil \ depth=${dem}_depth disch=${dem}_disch r.sim.water elevin=${dem} dxin=${dem}_dx dyin=${dem}_dy \ rain=${dem}_rain manin=${dem}_manin infil=${dem}_infil \ depth=${dem}_depth disch=${dem}_disch --------------------- Many thanks for looking at it, Andreas -------------------------------------------- Managed by Request Tracker From hamish_nospam at yahoo.com Wed Jun 7 10:16:18 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jun 7 10:16:23 2006 Subject: [GRASS-dev] [bug #4546] (grass) r.sim.water segmentation fault In-Reply-To: <20060607074942.203DE1005AC@lists.intevation.de> References: <20060607074942.203DE1005AC@lists.intevation.de> Message-ID: <20060607201618.1fe65bfb.hamish_nospam@yahoo.com> > this bug's URL: http://intevation.de/rt/webrt?serial_num=4546 > --------------------------------------------------------------------- > > Subject: r.sim.water segmentation fault > > Platform: GNU/Linux/x86_64 > grass obtained from: Trento Italy site > grass binary for platform: Compiled from Sources > GRASS Version: grass-6.1.cvs_src_snapshot_2006_06_03 try with today's CVS -- Glynn fixed the startup problem yesterday. cd raster/simwe/ cvs update make Hamish From ychemin at gmail.com Wed Jun 7 10:53:26 2006 From: ychemin at gmail.com (Yann Chemin) Date: Wed Jun 7 10:53:28 2006 Subject: [GRASS-dev] where is i.atcorr Message-ID: <6278879c0606070153r7dcd3b46h70e2d11fe3301d44@mail.gmail.com> Hello list, the link http://www.cs.sun.ac.za/~caz/projects.html in http://grass.itc.it/download/addons.php is broken. Anybody knows where the code has gone? Thanks, Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060607/ac19321a/attachment.html From grass-bugs at intevation.de Wed Jun 7 11:01:59 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Wed Jun 7 11:02:01 2006 Subject: [GRASS-dev] [bug #4547] (grass) v.clean: break tool for 3D lines resets elevation to 0.00 Message-ID: <20060607090159.2B0131005C4@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4547 ------------------------------------------------------------------------- Subject: v.clean: break tool for 3D lines resets elevation to 0.00 Hi, I have a 3D vector map of boundaries and centroids which started life as a series of triangular 3D surface faces. They all exist in the same plane with a constant elevation of ~ -11. I wish to connect them all together and disolve the common boundaries. (remove diagonal from square feature made up of two triangles forming a single square polygon from 2*triangles) but before I can use v.clean tool=rmdupl I need to run tool=break. v.clean tool=break does its thing, and finds lots of them. Problem is the output map has (re)set many of the points' z value to 0.0000 and then the nodes no longer snap together.... If I output an error= map all points have 0.00 elevation. (v.info z-range) test: v.category in=grid_faces_clean_polygons1 out=gf2 op=del v.category in=gf2 out=gf3 op=add type=boundary v.db.addtable gf3 col="x double, y double, z double" v.to.db gf3 option=start col=x,y,z [this is taking a while to run, I'll post the results to the bugtracker tomorrow] v.univar gf3 col=z ? mean(z) to get propotion of points converted 0 vs number of points in error map & original. Hamish -------------------------------------------- Managed by Request Tracker From hamish_nospam at yahoo.com Wed Jun 7 11:51:27 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jun 7 11:52:45 2006 Subject: [GRASS-dev] New georectifying module in TclTk In-Reply-To: References: <20060606223532.2b6ffaf9.hamish_nospam@yahoo.com> Message-ID: <20060607215127.50b03ea9.hamish_nospam@yahoo.com> > It sounds like most of the issues can be avoided by using i.rectify > -c. that is my understanding. > What are the disadvantages of using the -c switch? you have to restart GRASS in the target location and set up the region by hand. Ok if you knew to project a v.in.region box first and can calculate your target resolution, & give g.region all the right answers; but an automatic determination would be much better for most people. > It is not very clear (to me) in the docs. As it wasn't (isn't) very clear to the folks writing the docs.... You'll have to dig into the archives to read the "region cropping" history and the debate on the correct way to describe that flag. AFAIR, the default mode tries not to reproject cells which are not being used. (off the edge of the page in one projection) That is a very rough recollection though- it wasn't all to clear to me at the time either. Hamish From neteler at itc.it Wed Jun 7 12:01:15 2006 From: neteler at itc.it (Markus Neteler) Date: Wed Jun 7 12:01:17 2006 Subject: [GRASS-dev] Re: [STATSGRASS] propagating temporary files In-Reply-To: <20060607195929.0d2ab2bb.hamish_nospam@yahoo.com> References: <20060607152347.c8c77akqq9348s4g@webmail-3.ucs.uwa.edu.au> <20060607195929.0d2ab2bb.hamish_nospam@yahoo.com> Message-ID: <20060607100115.GB8647@bartok.itc.it> On Wed, Jun 07, 2006 at 07:59:29PM +1200, Hamish wrote: > On Wed, Jun 07, 2006 at 03:23:47PM +0800, rsadler@cyllene.uwa.edu.au wrote: ... > > I can disappear these files at run-time, but the strange thing is that > > this didn't appear to be a problem a couple of a weeks ago. Some months ago we introduced scripts (also commands?) which created subdirectories within $MAPSET/.tmp/ but the $GISBASE/etc/clean_temp wasn't yet changed accordingly. > usually $GISBASE/etc/clean_temp is run at GRASS startup and exit to > flush the $MAPSET/.tmp/ dir. At your own risk you can call it within > your GRASS session to clean out the muck. The current clean_temp program fails to remove subdirectories in /.tmp/ which are sometimes created. I have received a new version of clean_temp (written by Roberto Flor) which needs to be tested: http://mpa.itc.it/markus/tmp/clean_temp2.c This new version removes also subdirectories generated in the $MAPSET/.tmp/ dir. Markus From hamish_nospam at yahoo.com Wed Jun 7 12:34:00 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jun 7 12:36:46 2006 Subject: [GRASS-dev] Request to add a GCP file in vector directories In-Reply-To: References: Message-ID: <20060607223400.41cb5d81.hamish_nospam@yahoo.com> Michael Barton wrote: > I?m integrating vector georectification (v.transform) into the GIS > Manager georectifier. It would be nice if a GCP file could be saved in > a vector folder so that it could be called up, edited, and reused and > a user doesn?t have to re-enter GCP?s every time they start the > georectifier. This is the case now for rasters, because a GCP file > (POINTS) is saved inside the group folder for a raster group. > > I?m proposing to have the georectifier (at the user?s option) save a > file named ?gcp? (points might be confusing in a vector folder) in the > appropriate vector folder to be rectified. It would be a simple ascii > text file and take the format of the standard file needed by > v.transform, with the addition of a header indicating the target > location and mapset it is aimed at. For example... > > # target: /Users/shared/grassdata/spearfish60/newvector > -584 585 598000 4920770 > 580 585 598020 4920770 > 580 -600 598020 4920750 > -584 -600 598000 4920750 a couple of points: * "group" isn't (or shouldn't be) limited to raster maps. It's a common thing to have a bunch of maps in one projection and need them in another. (e.g. multiple satellite channels) I have a dozen XY vectors here which all exist in the same CAD space, it would be grand if I could transform them all without diving into the MAPSET dir & copying the file by hand.. I suggest you reuse group/ folder & structure. * reuse the POINTS file format. It's the same thing with different whitespace & comments. It's not so bluky that there's a real need to simplify it. The "status" column gets set to 0 when you disable a point in i.rectify, this is a good thing. The less divergence the better until a full rewrite. mind that gdal uses different row convention to GRASS. (flipped) See my i.warp script, http://bambi.otago.ac.nz/hamish/grass/gdal/sidescan_warp.html (also a demo of the broken CRS order=3 in GDAL there) note 6.1/6.0 difference, IIRC it comes from r.in.gdal in 6.0 importing the entire thing in negative coordinates. The difference is on the GDAL_GCP= line?? (-r reverse sort). It's a bit of a mess .. was trying to debug a GDAL memory problem without a clue. [in the end running gdalwarp -tps via electric fence and removing some GCPs helped the most; run in two passes and r.patch the results together rather that fix the breakage for the full scene] +______________ no need to reinvent the wheel. Hamish From hamish_nospam at yahoo.com Wed Jun 7 12:42:49 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jun 7 12:43:31 2006 Subject: [GRASS-dev] Request to add a GCP file in vector directories In-Reply-To: References: <17542.29500.100441.162381@cerise.gclements.plus.com> Message-ID: <20060607224249.7bfd2216.hamish_nospam@yahoo.com> > This is a good point. Should a generic gcp file just be stored in > PERMANENT? What about maps with different extents--especially > non-overlapping maps--in the same location? I'm not a fan. e.g. I've got a mapset: grassdata/simple_xy/charts/ where I have scanned versions of nautical charts imported. For each new chart I have it's own group with its own GCP info. I don't want a new mapset, let alone location, for each new scan. The group thing is good logically & works well in practice. Again I'd suggest we keep using the same method, just make a nice front end for it which merges and hides the gritty details. (I can picture a tabbed GUI with target in one, registed maps in another, etc..) Hamish From hamish_nospam at yahoo.com Wed Jun 7 12:48:36 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jun 7 12:48:43 2006 Subject: [GRASS-dev] Re: [STATSGRASS] propagating temporary files In-Reply-To: <20060607100115.GB8647@bartok.itc.it> References: <20060607152347.c8c77akqq9348s4g@webmail-3.ucs.uwa.edu.au> <20060607195929.0d2ab2bb.hamish_nospam@yahoo.com> <20060607100115.GB8647@bartok.itc.it> Message-ID: <20060607224836.3a195c99.hamish_nospam@yahoo.com> Markus wrote: > Some months ago we introduced scripts (also commands?) which created > subdirectories within $MAPSET/.tmp/ I think just some scripts to it "the hard way". g.tempfile needs a "-d" flag to create a directory and not a file. see the init.sh script, r.terraflow, for ideas on creating the dir safely. Hamish From glynn at gclements.plus.com Wed Jun 7 13:04:58 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Jun 7 13:05:00 2006 Subject: [GRASS-dev] [bug #4546] (grass) r.sim.water segmentation fault In-Reply-To: <20060607201618.1fe65bfb.hamish_nospam@yahoo.com> References: <20060607074942.203DE1005AC@lists.intevation.de> <20060607201618.1fe65bfb.hamish_nospam@yahoo.com> Message-ID: <17542.45786.44325.740519@cerise.gclements.plus.com> Hamish wrote: > > this bug's URL: http://intevation.de/rt/webrt?serial_num=4546 > > --------------------------------------------------------------------- > > > > Subject: r.sim.water segmentation fault > > > > Platform: GNU/Linux/x86_64 > > grass obtained from: Trento Italy site > > grass binary for platform: Compiled from Sources > > GRASS Version: grass-6.1.cvs_src_snapshot_2006_06_03 > > try with today's CVS -- Glynn fixed the startup problem yesterday. I doubt that's relevant here. My fix simply removed a "banner" which was being printed even when the --tcltk switch was used, thus interfering with gis.m. -- Glynn Clements From glynn at gclements.plus.com Wed Jun 7 13:15:14 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Jun 7 13:16:03 2006 Subject: [GRASS-dev] Request to add a GCP file in vector directories In-Reply-To: <20060607224249.7bfd2216.hamish_nospam@yahoo.com> References: <17542.29500.100441.162381@cerise.gclements.plus.com> <20060607224249.7bfd2216.hamish_nospam@yahoo.com> Message-ID: <17542.46402.486046.444077@cerise.gclements.plus.com> Hamish wrote: > > This is a good point. Should a generic gcp file just be stored in > > PERMANENT? What about maps with different extents--especially > > non-overlapping maps--in the same location? > > I'm not a fan. > > e.g. I've got a mapset: > > grassdata/simple_xy/charts/ > > where I have scanned versions of nautical charts imported. > > For each new chart I have it's own group with its own GCP info. > > I don't want a new mapset, let alone location, for each new scan. Right. It depends largely on whether the location is being used as a general purpose container or like a normal (georeferenced) location except that it has a non-standard projection. Even in the latter case, you might need multiple transformations, as one which is a good fit for one map might not be a good fit for another. Producing a transformation which is a good fit for the entire location would be difficult if you can only set reference points over a single map. Support for locations with user-defined (polynomial) projections would need to be in addition to the existing transformation tools, not a replacement. But it may be worth considering at this point. > The group thing is good logically & works well in practice. > Again I'd suggest we keep using the same method, just make a nice > front end for it which merges and hides the gritty details. > (I can picture a tabbed GUI with target in one, registed maps in > another, etc..) Command-line front-ends for some of the tools would also be nice. [By "command-line", I mean input via command-line options and/or files/stdin, rather than via curses forms.] -- Glynn Clements From glynn at gclements.plus.com Wed Jun 7 13:22:41 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Jun 7 13:23:15 2006 Subject: [GRASS-dev] Request to add a GCP file in vector directories In-Reply-To: <20060607223400.41cb5d81.hamish_nospam@yahoo.com> References: <20060607223400.41cb5d81.hamish_nospam@yahoo.com> Message-ID: <17542.46849.686754.148097@cerise.gclements.plus.com> Hamish wrote: > * reuse the POINTS file format. It's the same thing with different > whitespace & comments. It's not so bluky that there's a real need to > simplify it. The "status" column gets set to 0 when you disable a point > in i.rectify, this is a good thing. v.transform already has a defined format for GCPs, and that format is exposed to the user (i.e. the user is supposed to create the data in that format). A common format would need to remain compatible (e.g. change v.transform to allow either 4 or 5 columns). -- Glynn Clements From grass-bugs at intevation.de Wed Jun 7 16:40:26 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Wed Jun 7 16:40:28 2006 Subject: [GRASS-dev] [bug #4548] (grass) html docs are not generated Message-ID: <20060607144026.534791005C3@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4548 ------------------------------------------------------------------------- Subject: html docs are not generated Platform: GNU/Linux/x86 grass obtained from: CVS grass binary for platform: Compiled from Sources GRASS Version: latest cvs version When i try to generate the html docs (make htmldocs) in the grass6/lib directory, i get the following error: ../include/Make/Html.make:32: warning: overriding commands for target `htmlgen' ../include/Make/Html.make:32: warning: ignoring old commands for target `htmlgen' ../include/Make/Html.make:101: warning: overriding commands for target `htmlcmd1' ../include/Make/Html.make:101: warning: ignoring old commands for target `htmlcmd1' ../include/Make/Html.make:107: warning: overriding commands for target `htmlscript1' ../include/Make/Html.make:107: warning: ignoring old commands for target `htmlscript1' ../include/Make/Html.make:117: warning: overriding commands for target `htmletc1' ../include/Make/Html.make:117: warning: ignoring old commands for target `htmletc1' ../include/Make/Html.make:123: warning: overriding commands for target `htmldir1' ../include/Make/Html.make:123: warning: ignoring old commands for target `htmldir1' ../include/Make/Html.make:128: warning: overriding commands for target `htmlmulti' ../include/Make/Html.make:128: warning: ignoring old commands for target `htmlmulti' rm -rf ./latex ./html mv: cannot stat `grasslibslib.dox': No such file or directory make: *** [htmldocs] Error 1 Best Soeren -------------------------------------------- Managed by Request Tracker From david.p.finlayson at gmail.com Wed Jun 7 18:53:48 2006 From: david.p.finlayson at gmail.com (David Finlayson) Date: Wed Jun 7 18:53:50 2006 Subject: [GRASS-dev] Python GUI toolkits Message-ID: It looks like v.pyedit is written in pyGTK rather than wxPython. Will v.pygtk run natively on Windows or Apple? Will it look like a native application? >From my brief look at the toolkits, it seemed that wxPython was a little more cross platform friendly because it used native widgets. -- David Finlayson From michael.barton at asu.edu Wed Jun 7 19:14:45 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Jun 7 19:14:51 2006 Subject: [GRASS-dev] Request to add a GCP file in vector directories In-Reply-To: <20060607223400.41cb5d81.hamish_nospam@yahoo.com> Message-ID: Hamish, Haven't read through all my mail from overnight yet, so there might be comments by others. But I'll start with my own. 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: Wed, 7 Jun 2006 22:34:00 +1200 > To: Michael Barton > Cc: > Subject: Re: [GRASS-dev] Request to add a GCP file in vector directories > > Michael Barton wrote: > >> I?m integrating vector georectification (v.transform) into the GIS >> Manager georectifier. It would be nice if a GCP file could be saved in >> a vector folder so that it could be called up, edited, and reused and >> a user doesn?t have to re-enter GCP?s every time they start the >> georectifier. This is the case now for rasters, because a GCP file >> (POINTS) is saved inside the group folder for a raster group. >> >> I?m proposing to have the georectifier (at the user?s option) save a >> file named ?gcp? (points might be confusing in a vector folder) in the >> appropriate vector folder to be rectified. It would be a simple ascii >> text file and take the format of the standard file needed by >> v.transform, with the addition of a header indicating the target >> location and mapset it is aimed at. For example... >> >> # target: /Users/shared/grassdata/spearfish60/newvector >> -584 585 598000 4920770 >> 580 585 598020 4920770 >> 580 -600 598020 4920750 >> -584 -600 598000 4920750 > > > a couple of points: > > * "group" isn't (or shouldn't be) limited to raster maps. > > It's a common thing to have a bunch of maps in one projection and need > them in another. (e.g. multiple satellite channels) > I have a dozen XY vectors here which all exist in the same CAD space, it > would be grand if I could transform them all without diving into the > MAPSET dir & copying the file by hand.. > > I suggest you reuse group/ folder & structure. This seems fine and is the reason I wanted to save a vector gcp file. However, v.transform won't read a 'group'. I could emulate it in TclTk, but if this is what we want to do, it would be better to have v.transform simply work like i.rectify. > > > * reuse the POINTS file format. It's the same thing with different > whitespace & comments. It's not so bluky that there's a real need to > simplify it. The "status" column gets set to 0 when you disable a point > in i.rectify, this is a good thing. > > The less divergence the better until a full rewrite. Again, v.transform might have problems with the 1 or 0 at the end of each GCP line. Otherwise, the formats are the same. Again, altering v.transform to read a standard POINTS file makes for nice consistency. > > > > mind that gdal uses different row convention to GRASS. (flipped) > See my i.warp script, > > http://bambi.otago.ac.nz/hamish/grass/gdal/sidescan_warp.html > (also a demo of the broken CRS order=3 in GDAL there) > > note 6.1/6.0 difference, IIRC it comes from r.in.gdal in 6.0 importing > the entire thing in negative coordinates. The difference is on the > GDAL_GCP= line?? (-r reverse sort). It's a bit of a mess .. was trying > to debug a GDAL memory problem without a clue. [in the end running > gdalwarp -tps via electric fence and removing some GCPs helped the most; > run in two passes and r.patch the results together rather that fix the > breakage for the full scene] This and other issues make me shy away from trying to add in the abilty to use gdalwarp right now. It needs very different parameters, requires more file manipulation, and doesn't do vectors (AFAIK). I kind of like your idea better to use gdal libraries. > > > > +______________ > > no need to reinvent the wheel. Rather, lets have the same wheels all around the vehicle. Michael > > > Hamish From michael.barton at asu.edu Wed Jun 7 19:23:30 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Jun 7 19:23:39 2006 Subject: [GRASS-dev] issue with g.region Message-ID: I?ve been meaning to ask about this, but keep forgetting. I?m having trouble using g.region to set 3D values. When I do (regardless of how I do it), I get a error that depth is 0 and the region is not valid. I can go in and reset the WIND file by hand, but I think there is a problem. Has anyone else run into this? Should I add it to the bug list? 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/20060607/606fc153/attachment.html From michael.barton at asu.edu Wed Jun 7 19:32:54 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Jun 7 19:33:10 2006 Subject: [GRASS-dev] Request to add a GCP file in vector directories In-Reply-To: <17542.46402.486046.444077@cerise.gclements.plus.com> Message-ID: Currently, I've got the gcp file stored in $GISDBASE/vector/[vector name]. It is no problem to put into $GISBASE/group/[vector group]. But to do this, it would be better if... --i.group (or a new v.group) could create the group structure and the group file --v.transform could read a group file and act on the vectors listed --v.transform could read a standard POINTS file and use or ignore the "use gcp" column. I could emulate steps 1 & 2 in TclTk (and probably hack step 3), but it would be better in the long run if the GRASS C modules acted in a consistent way for vectors and rasters. I'll keep the 'test version' of the rectifier as is for the moment, but can change it to use a group structure if that's what we want and can make the changes to i.group/v.group and v.transform. 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: Glynn Clements > Date: Wed, 7 Jun 2006 12:15:14 +0100 > To: Hamish > Cc: Michael Barton , > Subject: Re: [GRASS-dev] Request to add a GCP file in vector directories > > > Hamish wrote: > >>> This is a good point. Should a generic gcp file just be stored in >>> PERMANENT? What about maps with different extents--especially >>> non-overlapping maps--in the same location? >> >> I'm not a fan. >> >> e.g. I've got a mapset: >> >> grassdata/simple_xy/charts/ >> >> where I have scanned versions of nautical charts imported. >> >> For each new chart I have it's own group with its own GCP info. >> >> I don't want a new mapset, let alone location, for each new scan. > > Right. It depends largely on whether the location is being used as a > general purpose container or like a normal (georeferenced) location > except that it has a non-standard projection. > > Even in the latter case, you might need multiple transformations, as > one which is a good fit for one map might not be a good fit for > another. Producing a transformation which is a good fit for the entire > location would be difficult if you can only set reference points over > a single map. > > Support for locations with user-defined (polynomial) projections would > need to be in addition to the existing transformation tools, not a > replacement. But it may be worth considering at this point. > >> The group thing is good logically & works well in practice. >> Again I'd suggest we keep using the same method, just make a nice >> front end for it which merges and hides the gritty details. >> (I can picture a tabbed GUI with target in one, registed maps in >> another, etc..) > > Command-line front-ends for some of the tools would also be nice. > > [By "command-line", I mean input via command-line options and/or > files/stdin, rather than via curses forms.] > > -- > Glynn Clements From jachym.cepicky at centrum.cz Wed Jun 7 22:18:05 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Wed Jun 7 22:19:10 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: References: Message-ID: <20060607201803.GA32453@gdf-hannover.de> Hi, On Wed, Jun 07, 2006 at 09:53:48AM -0700, David Finlayson wrote: > It looks like v.pyedit is written in pyGTK rather than wxPython. Will > v.pygtk run natively on Windows or Apple? Should run > Will it look like a native application? AFAIK now, does it harm? My experience with Gaim on windows area, that it looks almost like the native gui apps. My mother is using gaim and she has no problem with that, how it looks like. > > From my brief look at the toolkits, it seemed that wxPython was a > little more cross platform friendly because it used native widgets. > I was asking other users, if they could live with Gtk gui. Nobody answared. I do not understand, why any GUI should look "native". It should just be intuitive. I'm developing v.pydigit mostly for studing purposes. At the end should we be on the beginning of the new GRASS GUI (if any). v.pydigit should show, how to write things and show the posibilities and advantages of 3 tools: * python * glade * gtk+ I thing, I can say now, that these tools * are making gui development fast and easy even for non-programers * the gui can be "fast enough" for common usage * it is possible to run it even on not-so-well equiped computers -- * I like the way, Gtk+ apps are looking/can look. -- (Ones I tryed to work with python+Qt - it was sooo sloow) IIRC, there is no tool for wxWindows, which would act similar to Glade. Glade is producing XML files. What I read, the best tool like glade for gtk, would be wxglade for wxwindows. It produces pure xml file, which disables to bind results from glade in another language, but this is only how I understand it, so if anybody else would have experience with tools like this, I would welcome comments from your site. Anyway, if you or anybody else will start to develop any other GUI using wxWindows, you can count with me. BTW: New version of v.pydigit is able to digitize lines, boundaries, points and centroids. You can edit your attribute table and add attributes to new digitized features. I wrote some summary to another e-mail, but it did not come to this list so far. I newver said, v.pydigit will/should be *the* grass GUI or *the* grass digitalisation tool. The more it can, the more I thing, I would start from scratch and build most of the app again more as real GUI framework and not only one-tool program. But it could be here, until we will not have something more common, and people could use it for their common work. I hope to make it work better (user friendlier), than v.digit ever was (I'll see, how much time I'll have, this is not my only project and not the most importand one) 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/20060607/3754f9f2/attachment.bin From glynn at gclements.plus.com Wed Jun 7 22:48:13 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Jun 7 22:48:23 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: References: Message-ID: <17543.15245.429171.786275@cerise.gclements.plus.com> David Finlayson wrote: > It looks like v.pyedit is written in pyGTK rather than wxPython. Will > v.pygtk run natively on Windows or Apple? Only if you have GTK. > Will it look like a native application? Only to the extent that GTK does, which depends upon the theme being used. > >From my brief look at the toolkits, it seemed that wxPython was a > little more cross platform friendly because it used native widgets. While a native look-and-feel is nice to have, using native widgets can create portability issues due to differences in the way that equivalent widgets behave. Also, obtaining a native look-and-feel involves more than just using the platform's native widgets. There are also conventions which rely upon the application to follow them, which means writing separate cases for each platform. Using a toolkit which behaves identically on all platforms is simpler for the developers (and we aren't exactly overstaffed). It also means that the application behaves in a consistent manner on all platforms, which is useful if you use multiple platforms, or if you are writing documentation. -- Glynn Clements From david.p.finlayson at gmail.com Wed Jun 7 22:49:03 2006 From: david.p.finlayson at gmail.com (David Finlayson) Date: Wed Jun 7 22:49:07 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: <20060607201803.GA32453@gdf-hannover.de> References: <20060607201803.GA32453@gdf-hannover.de> Message-ID: I am sure your work is great and greatly appreciated! For what it is worth, I use Gnome on Linux, so I agree with you about GTK looking good---it does to me anyway. I was mainly concerned about Apple users. The last I heard, GTK was not easy to install on Apple OSX and many apple users have a natural revulsion to non-native apps (I don't own an apple so I don't understand myself). Windows has never had a standard GUI so it is less of an issue with Windows users. I was toying with the idea of creating a Matlab or R-style GUI for grass. The idea would be to have a command line interface with helper applications such as graphics monitors, text editor, file browser, help-system, etc. All accessible from tool bars. People seem to really like Matlab once they learn it and I thought that if a grass version were done right, even guys like me might use it (which means that I better write code that I want to use!). If the "shell" were Python, I could build most of this out of the default tools in wxPython. In fact, I got a basic editor up and running in about 100 lines of code! All the pieces are there for display, editing, python interpreter, color pickers etc. I was looking at the XML specification for GUIs which could build a GUI for command line tools on the fly the way gis.m does now. And the framework seems flexible enough to make it really easy to add new tools by non-programmers who know a few things about Python. All that being said. It would be a real pain to maintain programs in 3 different GUI frameworks. If pyGTK works, maybe I ought to look at that for my GUI. David On 6/7/06, Jachym Cepicky wrote: > Hi, > > On Wed, Jun 07, 2006 at 09:53:48AM -0700, David Finlayson wrote: > > It looks like v.pyedit is written in pyGTK rather than wxPython. Will > > v.pygtk run natively on Windows or Apple? > > Should run > > > Will it look like a native application? > > AFAIK now, does it harm? My experience with Gaim on windows area, that > it looks almost like the native gui apps. My mother is using gaim and > she has no problem with that, how it looks like. > > > > > From my brief look at the toolkits, it seemed that wxPython was a > > little more cross platform friendly because it used native widgets. > > > > I was asking other users, if they could live with Gtk gui. Nobody > answared. I do not understand, why any GUI should look "native". It > should just be intuitive. > > I'm developing v.pydigit mostly for studing purposes. At the end should > we be on the beginning of the new GRASS GUI (if any). v.pydigit should > show, how to write things and show the posibilities and advantages of 3 > tools: > > * python > * glade > * gtk+ > > I thing, I can say now, that these tools > > * are making gui development fast and easy even for non-programers > * the gui can be "fast enough" for common usage > * it is possible to run it even on not-so-well equiped computers > -- > * I like the way, Gtk+ apps are looking/can look. > -- > (Ones I tryed to work with python+Qt - it was sooo sloow) > > IIRC, there is no tool for wxWindows, which would act similar to Glade. > Glade is producing XML files. What I read, the best tool like glade for > gtk, would be wxglade for wxwindows. It produces pure xml file, which > disables to bind results from glade in another language, but this is > only how I understand it, so if anybody else would have experience with > tools like this, I would welcome comments from your site. > > Anyway, if you or anybody else will start to develop any other GUI using > wxWindows, you can count with me. > > BTW: New version of v.pydigit is able to digitize lines, boundaries, > points and centroids. You can edit your attribute table and add > attributes to new digitized features. I wrote some summary to another > e-mail, but it did not come to this list so far. > > I newver said, v.pydigit will/should be *the* grass GUI or *the* grass > digitalisation tool. The more it can, the more I thing, I would start > from scratch and build most of the app again more as real GUI framework > and not only one-tool program. But it could be here, until we will not > have something more common, and people could use it for their common > work. I hope to make it work better (user friendlier), than v.digit ever was > (I'll see, how much time I'll have, this is not my only project and not > the most importand one) > > 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 > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (GNU/Linux) > > iD8DBQFEhzR7yKt0uAjU4I8RAilqAKCzAFMAv2nrTGdsLOVhWbI7kINRxQCdHEoc > GMMh3ioWxjdvR+i9TNB64qs= > =XPrR > -----END PGP SIGNATURE----- > > > -- David Finlayson From michael.barton at asu.edu Wed Jun 7 23:44:16 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Jun 7 23:46:14 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: <17543.15245.429171.786275@cerise.gclements.plus.com> Message-ID: Perhaps a more important question. The GTK apps I know of (GIMP for example) need x11 to run on my Mac. Can GTK apps run without x11? In Aqua on Macs? In (whatever it is) on Windows? 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: Glynn Clements > Date: Wed, 7 Jun 2006 21:48:13 +0100 > To: David Finlayson > Cc: GRASS developers list > Subject: Re: [GRASS-dev] Python GUI toolkits > > > David Finlayson wrote: > >> It looks like v.pyedit is written in pyGTK rather than wxPython. Will >> v.pygtk run natively on Windows or Apple? > > Only if you have GTK. > >> Will it look like a native application? > > Only to the extent that GTK does, which depends upon the theme being used. > >>> From my brief look at the toolkits, it seemed that wxPython was a >> little more cross platform friendly because it used native widgets. > > While a native look-and-feel is nice to have, using native widgets can > create portability issues due to differences in the way that > equivalent widgets behave. > > Also, obtaining a native look-and-feel involves more than just using > the platform's native widgets. There are also conventions which rely > upon the application to follow them, which means writing separate > cases for each platform. > > Using a toolkit which behaves identically on all platforms is simpler > for the developers (and we aren't exactly overstaffed). It also means > that the application behaves in a consistent manner on all platforms, > which is useful if you use multiple platforms, or if you are writing > documentation. > > -- > Glynn Clements > > From michael.barton at asu.edu Thu Jun 8 00:54:04 2006 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jun 8 00:54:10 2006 Subject: [GRASS-dev] updates to georectifier Message-ID: I just committed an updated version of the georectifier. Mainly, I?ve folded in vector georectifying, using v.transform. For this test version, I?m saving vector GCP points in a gcp file inside each vector folder. However, if we switch to a group model, this is easy to change. I?ve cleaned up a few bugs and improved robusticity (I hope). Zoom and pan still don?t work right, but resizing the window does. Once we have a C module that can do the affine transformations for RMS error calculation, I?ll add that in. As I write, something occurred to me. Does v.transform do an affine transformation on points? Is it different from the transformation done in the libraries used by i.rectify? 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/20060607/0c95994c/attachment.html From glynn at gclements.plus.com Thu Jun 8 01:39:34 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jun 8 01:39:41 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: References: <20060607201803.GA32453@gdf-hannover.de> Message-ID: <17543.25526.32069.86046@cerise.gclements.plus.com> David Finlayson wrote: > I am sure your work is great and greatly appreciated! For what it is > worth, I use Gnome on Linux, so I agree with you about GTK looking > good---it does to me anyway. > > I was mainly concerned about Apple users. The last I heard, GTK was > not easy to install on Apple OSX and many apple users have a natural > revulsion to non-native apps (I don't own an apple so I don't > understand myself). Windows has never had a standard GUI so it is less > of an issue with Windows users. Windows has had lots of "standard" GUIs in its time, although adherence to UI guidelines tends to be rather more lax than on the Mac (in particular, Microsoft doesn't seem particularly interested in following the guidelines which they suggest for other developers). I would expect the non-native appearance to be more of an issue on the Mac, partly because UI guidelines tend to be more strongly adhered to there, but mainly because Unix GUI toolkits tend to be more heavily influenced by the Windows GUI than by the Mac GUI, so the difference is less noticable on Windows. -- Glynn Clements From grass-bugs at intevation.de Thu Jun 8 02:01:06 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Jun 8 02:01:09 2006 Subject: [GRASS-dev] [bug #4553] (grass) Re[5]:Greeting ! Message-ID: <20060608000106.C852F1005C4@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4553 ------------------------------------------------------------------------- Hello. I'm a very young and energetic lady! I have very positive attitude to life and people. I do enjoy new experience life can offer me: to see new interesting places, to meet new people. I do try to enjoy every moment of life and accept everything the way it comes without complaining. Though my life seems to be quite enjoyable there's one important thing missing. It's LOVE! Without my beloved one, my soul mate, my King my life is not completed. I wish i coud find him very soon so that we could share together every momement of the life-time romance! What about you? Could you be my King? If answer is "yes" - you can find more about me http://mzhoxrMK8Jk.i-am-waiting4love.net/ ta-ta!! Biana --- Headers Follow --- >From geras@74.ru Thu Jun 8 02:01:06 2006 Return-Path: Delivered-To: grass-bugs@lists.intevation.de Received: from mail.intevation.de (aktaia [212.95.126.10]) by lists.intevation.de (Postfix) with ESMTP id 6A3E11005C3; Thu, 8 Jun 2006 02:01:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.intevation.de (Postfix) with ESMTP id 01CFB36DB1; Thu, 8 Jun 2006 02:01:06 +0200 (CEST) Received: from 200-163-6-183.bsace705.dsl.brasiltelecom.net.br (unknown [200.163.6.183]) by mail.intevation.de (Postfix) with ESMTP id 98D4F36D7F; Thu, 8 Jun 2006 02:00:57 +0200 (CEST) Received: from [10.0.2.59] by 200-163-6-183.bsace705.dsl.brasiltelecom.net.br id m4tZXcA26zJU; Thu, 08 Jun 2006 03:01:44 +0300 Message-ID: <002201c68a8e$b4cd9980$3b02000a@200-163-6-183.bsace705.dsl.brasiltelecom.net.br> From: "Biana" To: "bernhard" Subject: Re[5]:Greeting ! Date: Thu, 08 Jun 2006 03:01:44 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 0623-1, 06/06/2006), Outbound message X-Antivirus-Status: Clean X-Spam-Status: No, hits=-0.0 tagged_above=-999.0 required=3.0 tests=BAYES_40 X-Spam-Level: -------------------------------------------- Managed by Request Tracker From glynn at gclements.plus.com Thu Jun 8 02:01:49 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jun 8 02:04:20 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: References: <17543.15245.429171.786275@cerise.gclements.plus.com> Message-ID: <17543.26861.284579.875286@cerise.gclements.plus.com> Michael Barton wrote: > Perhaps a more important question. The GTK apps I know of (GIMP for example) > need x11 to run on my Mac. Can GTK apps run without x11? In Aqua on Macs? In > (whatever it is) on Windows? There is a native MacOSX port of GTK under development: http://developer.imendio.com/wiki/Gtk_Mac_OS_X However, it doesn't appear to be as mature at the Windows port yet: http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Things_to_do Of the items on that list, most seem to be related to applications which do their own low-level event handling and drawing, rather than more typical UIs built from standard widgets. Some of them could be relevant to the display canvas, though. The most serious issues seem to be: Menus/pop up windows * These are currently buggy and need fixing. (medium) Miscellaneous * Currently GTK+ runs only on Tiger. This should perhaps be fixed. (medium) #322372 * Bugs, bugs, bugs :) Just pick one and fix it! :) So far as Windows is concerned, I use GIMP, Pan and X-Chat on Windows using the native GTK port. They have a few rough edges, but those are all quite minor. The UI appearance is no less "native" than e.g. Delphi applications. Given the number of Windows users who seem willing to tolerate stuff like WinAmp, I don't see any reason to worry about the differences between GTK and the standard Windows/MFC controls. Admittedly WinAmp-style UIs don't seem to have caught on for "serious" applications, although I've seen plenty of "Easy Photo Album" programs (usually bundled with scanners, digital cameras etc) which seem to go out of their way to avoid looking like normal Windows applications (e.g. most of the icons look like they belong on a toy aimed at the pre-school age group). -- Glynn Clements From grass-bugs at intevation.de Thu Jun 8 02:30:04 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Jun 8 02:30:05 2006 Subject: [GRASS-dev] [bug #4555] (grass) 3D settings cause error in g.region Message-ID: <20060608003004.ABCD71005C3@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4555 ------------------------------------------------------------------------- Subject: 3D settings cause error in g.region Platform: Mac OSX grass obtained from: Mirror of Trento site grass binary for platform: Downloaded precompiled Binaries GRASS Version: 6.1 cvs 27-May-06 If you try to set 3D settings (resolution, top/bottom) using g.region, it produces an error that depth is 0. Then it is no longer possible to run g.region on the WIND file. It is possible to manually fix WIND with a text editor, but g.region is problematic. -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Thu Jun 8 02:59:06 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Jun 8 02:59:08 2006 Subject: [GRASS-dev] [bug #4556] (grass) NVIZ does not display vector maps at startup Message-ID: <20060608005906.36F171005AC@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4556 ------------------------------------------------------------------------- Subject: NVIZ does not display vector maps at startup Platform: other grass obtained from: CVS grass binary for platform: Compiled from Sources GRASS Version: CVS checked out at 20060607 Running "nviz raster vect=vect" does not display "vect" map at startup. The vector map shows up only after refreshing the display panel. It looks like the startup procedure uses Nquick_draw which is used when dragging mouse to change positions. -------------------------------------------- Managed by Request Tracker From twiens at interbaun.com Thu Jun 8 06:29:16 2006 From: twiens at interbaun.com (Trevor Wiens) Date: Thu Jun 8 06:29:20 2006 Subject: [GRASS-dev] gis.m error resolved Message-ID: <20060607222916.4aa3a527@localhost.localdomain> My problems with the cvs version of gis.m have disappeared. I don't know the cause. I updated and re-ran ./configure to make sure everything was being found and it is working now. Thanks for the help. T -- Trevor Wiens twiens@interbaun.com The significant problems that we face cannot be solved at the same level of thinking we were at when we created them. (Albert Einstein) From david.p.finlayson at gmail.com Thu Jun 8 06:36:04 2006 From: david.p.finlayson at gmail.com (David Finlayson) Date: Thu Jun 8 06:36:06 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: <17543.26861.284579.875286@cerise.gclements.plus.com> References: <17543.15245.429171.786275@cerise.gclements.plus.com> <17543.26861.284579.875286@cerise.gclements.plus.com> Message-ID: In contrast to GTK, wxPython appears to be mature for all platforms---at least there are no major warnings on the download page (other than a note about Universal binaries) The screenshots page shows examples from all of the major platforms: http://www.wxpython.org/screenshots.php I think that the demo that comes with wxPython would be an excellent test of the look and feel across platforms. Can someone try it out on OSX? I know that the demo program works well on Linux (Ubuntu/Gnome = GTK) and Windows. I haven't tried it on a QT system. It is impressive how little code is required to build the demo programs. Personally, I like the idea that it will blend in with the rest of my desktop. I think you get all the integration for free. The toolkit abstracts out the differences between platforms. There would be no KDE vs Gnome choice that needs to be made since wxWidgets handles will work with QT or GTK depending on the installed packages. I don't really know. I've only programmed toy applications with it. On 6/7/06, Glynn Clements wrote: > > Michael Barton wrote: > > > Perhaps a more important question. The GTK apps I know of (GIMP for example) > > need x11 to run on my Mac. Can GTK apps run without x11? In Aqua on Macs? In > > (whatever it is) on Windows? > > There is a native MacOSX port of GTK under development: > > http://developer.imendio.com/wiki/Gtk_Mac_OS_X > > However, it doesn't appear to be as mature at the Windows port yet: > > http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Things_to_do > > Of the items on that list, most seem to be related to applications > which do their own low-level event handling and drawing, rather than > more typical UIs built from standard widgets. Some of them could be > relevant to the display canvas, though. > > The most serious issues seem to be: > > Menus/pop up windows > > * These are currently buggy and need fixing. (medium) > > Miscellaneous > > * Currently GTK+ runs only on Tiger. This should perhaps be fixed. (medium) #322372 > > * Bugs, bugs, bugs :) Just pick one and fix it! :) > > So far as Windows is concerned, I use GIMP, Pan and X-Chat on Windows > using the native GTK port. They have a few rough edges, but those are > all quite minor. The UI appearance is no less "native" than e.g. > Delphi applications. > > Given the number of Windows users who seem willing to tolerate stuff > like WinAmp, I don't see any reason to worry about the differences > between GTK and the standard Windows/MFC controls. > > Admittedly WinAmp-style UIs don't seem to have caught on for "serious" > applications, although I've seen plenty of "Easy Photo Album" programs > (usually bundled with scanners, digital cameras etc) which seem to go > out of their way to avoid looking like normal Windows applications > (e.g. most of the icons look like they belong on a toy aimed at the > pre-school age group). > > -- > Glynn Clements > -- David Finlayson From michael.barton at asu.edu Thu Jun 8 08:01:29 2006 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jun 8 08:01:40 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: <17543.25526.32069.86046@cerise.gclements.plus.com> Message-ID: Ideally, we should be able to write one piece of GUI code that will run on all platforms, without x11 on Windows and preferably running under aqua on a Mac. Does anyone looking into either wxPython or pyGTK know if this can be done with either of these platforms? The whole idea of not requiring x11 for GRASS is kind of lost if it is required for the GUI. By the same token, it would be difficult to maintain 3 different versions of the GUI (unless the differences were very minimal). 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: Thu, 8 Jun 2006 00:39:34 +0100 > To: David Finlayson > Cc: Jachym Cepicky , GRASS developers list > > Subject: Re: [GRASS-dev] Python GUI toolkits > > > David Finlayson wrote: > >> I am sure your work is great and greatly appreciated! For what it is >> worth, I use Gnome on Linux, so I agree with you about GTK looking >> good---it does to me anyway. >> >> I was mainly concerned about Apple users. The last I heard, GTK was >> not easy to install on Apple OSX and many apple users have a natural >> revulsion to non-native apps (I don't own an apple so I don't >> understand myself). Windows has never had a standard GUI so it is less >> of an issue with Windows users. > > Windows has had lots of "standard" GUIs in its time, although > adherence to UI guidelines tends to be rather more lax than on the Mac > (in particular, Microsoft doesn't seem particularly interested in > following the guidelines which they suggest for other developers). > > I would expect the non-native appearance to be more of an issue on the > Mac, partly because UI guidelines tend to be more strongly adhered to > there, but mainly because Unix GUI toolkits tend to be more heavily > influenced by the Windows GUI than by the Mac GUI, so the difference > is less noticable on Windows. > > -- > Glynn Clements > > From michael.barton at asu.edu Thu Jun 8 09:19:44 2006 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jun 8 09:19:53 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: Message-ID: I just downloaded and installed wxPython, Activestate's Python for Mac,and the wxPython sample/demo/docs package. I ran the demo and it looks great. I think that people would be thrilled to have this look for GRASS on a Mac. The demo code *looks* very short and easy--but I don't know what is involved to put it all together. A very important aspect that I don't know is if creating GUI code on my Mac in wxPython would run the same on Linux and Windows. Also, how easy would it be to port a piece of pyGTK code to wxPython? I realize that they are running different underlying platforms (though I noticed that the wxPython docs say you need GTK for the Linux version). But since they are both Python, doesn't that make the syntax somewhat similar??? Can anyone advise? 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: David Finlayson > Date: Wed, 7 Jun 2006 21:36:04 -0700 > To: Glynn Clements > Cc: Michael Barton , GRASS developers list > > Subject: Re: [GRASS-dev] Python GUI toolkits > > In contrast to GTK, wxPython appears to be mature for all > platforms---at least there are no major warnings on the download page > (other than a note about Universal binaries) > > The screenshots page shows examples from all of the major platforms: > > http://www.wxpython.org/screenshots.php > > I think that the demo that comes with wxPython would be an excellent > test of the look and feel across platforms. Can someone try it out on > OSX? I know that the demo program works well on Linux (Ubuntu/Gnome = > GTK) and Windows. I haven't tried it on a QT system. It is impressive > how little code is required to build the demo programs. > > Personally, I like the idea that it will blend in with the rest of my > desktop. I think you get all the integration for free. The toolkit > abstracts out the differences between platforms. There would be no KDE > vs Gnome choice that needs to be made since wxWidgets handles will > work with QT or GTK depending on the installed packages. > > I don't really know. I've only programmed toy applications with it. > > On 6/7/06, Glynn Clements wrote: >> >> Michael Barton wrote: >> >>> Perhaps a more important question. The GTK apps I know of (GIMP for example) >>> need x11 to run on my Mac. Can GTK apps run without x11? In Aqua on Macs? In >>> (whatever it is) on Windows? >> >> There is a native MacOSX port of GTK under development: >> >> http://developer.imendio.com/wiki/Gtk_Mac_OS_X >> >> However, it doesn't appear to be as mature at the Windows port yet: >> >> http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Things_to_do >> >> Of the items on that list, most seem to be related to applications >> which do their own low-level event handling and drawing, rather than >> more typical UIs built from standard widgets. Some of them could be >> relevant to the display canvas, though. >> >> The most serious issues seem to be: >> >> Menus/pop up windows >> >> * These are currently buggy and need fixing. (medium) >> >> Miscellaneous >> >> * Currently GTK+ runs only on Tiger. This should perhaps be fixed. >> (medium) #322372 >> >> * Bugs, bugs, bugs :) Just pick one and fix it! :) >> >> So far as Windows is concerned, I use GIMP, Pan and X-Chat on Windows >> using the native GTK port. They have a few rough edges, but those are >> all quite minor. The UI appearance is no less "native" than e.g. >> Delphi applications. >> >> Given the number of Windows users who seem willing to tolerate stuff >> like WinAmp, I don't see any reason to worry about the differences >> between GTK and the standard Windows/MFC controls. >> >> Admittedly WinAmp-style UIs don't seem to have caught on for "serious" >> applications, although I've seen plenty of "Easy Photo Album" programs >> (usually bundled with scanners, digital cameras etc) which seem to go >> out of their way to avoid looking like normal Windows applications >> (e.g. most of the icons look like they belong on a toy aimed at the >> pre-school age group). >> >> -- >> Glynn Clements >> > > > -- > David Finlayson From david.p.finlayson at gmail.com Thu Jun 8 10:09:21 2006 From: david.p.finlayson at gmail.com (David Finlayson) Date: Thu Jun 8 10:09:25 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: References: Message-ID: According to the pyGTK FAQ there is no native MacOS X support, it requires an X server of some kind (X11 or Apple's version): http://www.async.com.br/faq/pygtk/index.py?req=show&file=faq01.019.htp This toolkit seems like a dead end if the goal is to liberate GRASS from an X server (though it does look nice) On 6/8/06, Michael Barton wrote: > I just downloaded and installed wxPython, Activestate's Python for Mac,and > the wxPython sample/demo/docs package. > > I ran the demo and it looks great. I think that people would be thrilled to > have this look for GRASS on a Mac. > > The demo code *looks* very short and easy--but I don't know what is involved > to put it all together. > > A very important aspect that I don't know is if creating GUI code on my Mac > in wxPython would run the same on Linux and Windows. > > Also, how easy would it be to port a piece of pyGTK code to wxPython? I > realize that they are running different underlying platforms (though I > noticed that the wxPython docs say you need GTK for the Linux version). But > since they are both Python, doesn't that make the syntax somewhat similar??? > > Can anyone advise? > > 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: David Finlayson > > Date: Wed, 7 Jun 2006 21:36:04 -0700 > > To: Glynn Clements > > Cc: Michael Barton , GRASS developers list > > > > Subject: Re: [GRASS-dev] Python GUI toolkits > > > > In contrast to GTK, wxPython appears to be mature for all > > platforms---at least there are no major warnings on the download page > > (other than a note about Universal binaries) > > > > The screenshots page shows examples from all of the major platforms: > > > > http://www.wxpython.org/screenshots.php > > > > I think that the demo that comes with wxPython would be an excellent > > test of the look and feel across platforms. Can someone try it out on > > OSX? I know that the demo program works well on Linux (Ubuntu/Gnome = > > GTK) and Windows. I haven't tried it on a QT system. It is impressive > > how little code is required to build the demo programs. > > > > Personally, I like the idea that it will blend in with the rest of my > > desktop. I think you get all the integration for free. The toolkit > > abstracts out the differences between platforms. There would be no KDE > > vs Gnome choice that needs to be made since wxWidgets handles will > > work with QT or GTK depending on the installed packages. > > > > I don't really know. I've only programmed toy applications with it. > > > > On 6/7/06, Glynn Clements wrote: > >> > >> Michael Barton wrote: > >> > >>> Perhaps a more important question. The GTK apps I know of (GIMP for example) > >>> need x11 to run on my Mac. Can GTK apps run without x11? In Aqua on Macs? In > >>> (whatever it is) on Windows? > >> > >> There is a native MacOSX port of GTK under development: > >> > >> http://developer.imendio.com/wiki/Gtk_Mac_OS_X > >> > >> However, it doesn't appear to be as mature at the Windows port yet: > >> > >> http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Things_to_do > >> > >> Of the items on that list, most seem to be related to applications > >> which do their own low-level event handling and drawing, rather than > >> more typical UIs built from standard widgets. Some of them could be > >> relevant to the display canvas, though. > >> > >> The most serious issues seem to be: > >> > >> Menus/pop up windows > >> > >> * These are currently buggy and need fixing. (medium) > >> > >> Miscellaneous > >> > >> * Currently GTK+ runs only on Tiger. This should perhaps be fixed. > >> (medium) #322372 > >> > >> * Bugs, bugs, bugs :) Just pick one and fix it! :) > >> > >> So far as Windows is concerned, I use GIMP, Pan and X-Chat on Windows > >> using the native GTK port. They have a few rough edges, but those are > >> all quite minor. The UI appearance is no less "native" than e.g. > >> Delphi applications. > >> > >> Given the number of Windows users who seem willing to tolerate stuff > >> like WinAmp, I don't see any reason to worry about the differences > >> between GTK and the standard Windows/MFC controls. > >> > >> Admittedly WinAmp-style UIs don't seem to have caught on for "serious" > >> applications, although I've seen plenty of "Easy Photo Album" programs > >> (usually bundled with scanners, digital cameras etc) which seem to go > >> out of their way to avoid looking like normal Windows applications > >> (e.g. most of the icons look like they belong on a toy aimed at the > >> pre-school age group). > >> > >> -- > >> Glynn Clements > >> > > > > > > -- > > David Finlayson > > -- David Finlayson From wolf+grass at bergenheim.net Thu Jun 8 10:15:31 2006 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Thu Jun 8 10:15:38 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: References: Message-ID: On Thu, 8 Jun 2006, Michael Barton wrote: > Also, how easy would it be to port a piece of pyGTK code to wxPython? I > realize that they are running different underlying platforms (though I > noticed that the wxPython docs say you need GTK for the Linux version). But > since they are both Python, doesn't that make the syntax somewhat similar??? > > Can anyone advise? If we choose pyGTK it means we can develop the UI with PyGlade, and it generates pyGTK code + xml files for libglade to parse. And that is AFAIK the thing that makes developing with pyGTK so quick. And that is IMO why this combination is the strongest candidate. As for porting pyGTK to wxPython, well don't even think about it (; It is IMO better to code for wxPython directly. Read here more about this: http://www.linuxjournal.com/article/7421 + resources: http://www.linuxjournal.com/article/7558 http://www.linuxjournal.com/article/6586 --Wolf -- <:3 )---- Wolf Bergenheim ----( 8:> From wolf+grass at bergenheim.net Thu Jun 8 10:18:42 2006 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Thu Jun 8 10:18:56 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: References: Message-ID: On Thu, 8 Jun 2006, David Finlayson wrote: > According to the pyGTK FAQ there is no native MacOS X support, it > requires an X server of some kind (X11 or Apple's version): > > http://www.async.com.br/faq/pygtk/index.py?req=show&file=faq01.019.htp > > This toolkit seems like a dead end if the goal is to liberate GRASS > from an X server (though it does look nice) > Indeed, but as people here have said they are working on a native GTK, and as soon as there is a native GTK I suspect that there will be a pyGTK that can use the native GTK. --W -- <:3 )---- Wolf Bergenheim ----( 8:> From wolf+grass at bergenheim.net Thu Jun 8 10:39:19 2006 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Thu Jun 8 10:39:30 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: References: Message-ID: On Thu, 8 Jun 2006, Wolf Bergenheim wrote: > On Thu, 8 Jun 2006, Michael Barton wrote: > >> Also, how easy would it be to port a piece of pyGTK code to wxPython? I >> realize that they are running different underlying platforms (though I >> noticed that the wxPython docs say you need GTK for the Linux version). >> But >> since they are both Python, doesn't that make the syntax somewhat >> similar??? >> >> Can anyone advise? > > If we choose pyGTK it means we can develop the UI with PyGlade, and it > generates pyGTK code + xml files for libglade to parse. And that is AFAIK the > thing that makes developing with pyGTK so quick. And that is IMO why this > combination is the strongest candidate. > > As for porting pyGTK to wxPython, well don't even think about it (; It is IMO > better to code for wxPython directly. > > Read here more about this: > http://www.linuxjournal.com/article/7421 + resources: > http://www.linuxjournal.com/article/7558 > http://www.linuxjournal.com/article/6586 > Looking for a RAD for wxWidgets + Python I found wxGlade: http://wxglade.sourceforge.net/ That makes me lean toward wxWidgets again, but on the other hand I like the idea of using GTK (or QT) since then we could have a constant GRASS look, instead of having a native look. But making it easier to install GRASS is more important IMHO. --W -- <:3 )---- Wolf Bergenheim ----( 8:> From jachym.cepicky at centrum.cz Thu Jun 8 10:43:35 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Thu Jun 8 10:44:36 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: References: Message-ID: <20060608084334.GA3058@gdf-hannover.de> On Thu, Jun 08, 2006 at 12:19:44AM -0700, Michael Barton wrote: > Also, how easy would it be to port a piece of pyGTK code to wxPython? I > realize that they are running different underlying platforms (though I > noticed that the wxPython docs say you need GTK for the Linux version). But > since they are both Python, doesn't that make the syntax somewhat similar??? > > Can anyone advise? > > Michael Syntax maybe. I was looking after some gui builder tool. The nicest could be wxGlade, however I was not able to re-build something similar to current version of v.pydigit. I'm affraid, the gui code will have to be maintained by hand :-( At least code of the monitors, since wxglade seems not to be able to add drawing area object to the gui. 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/20060608/6b1eb80d/attachment.bin From soerengebbert at gmx.de Thu Jun 8 12:32:47 2006 From: soerengebbert at gmx.de (=?iso-8859-1?q?S=F6ren_Gebbert?=) Date: Thu Jun 8 12:32:56 2006 Subject: [GRASS-dev] New grass test suite (0.2.0.6) available Message-ID: <200606081232.47909.soerengebbert@gmx.de> Hi, a new version (0.2.0.6) of the grass test suite is available. http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/GRASS_Testsuite-0.2.0.6.tar.bz2 The pdf description is now part of the test suite documentation, including the openoffice file. Maybe a native english speaker may check my horribile denglish? :) Tests for the new features of * v.out.vtk * r3.out.vtk * and r.out.vtk are implemented. The latest test run can be watched here: http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html/ and with valgrind memcheck: http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html_memcheck/ Best regards Soeren From grass-bugs at intevation.de Thu Jun 8 12:57:48 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Jun 8 12:57:49 2006 Subject: [GRASS-dev] [bug #4557] (grass) problem with v.surf.rst cross validation Message-ID: <20060608105748.1F3EB1005D8@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4557 ------------------------------------------------------------------------- Subject: problem with v.surf.rst cross validation hi I m using grass6.0 I m trying to use the function v.surf.rst it does the interpolation but when withou changing any parameters i try to do the cross validations comes this error v.surf.rst input=punti_interpolazione layer=0 dmax=4.999977 dmin=0.999995 cvdev=cross_test zmult=1.0 tension=40. smooth=0.1 segmax=40 npmin=100 -v Authors: original version - H.Mitasova, L.Mitas, I. Kosinovsky, D.P. Gerdes See manual pages for reference and publications T3 DBMI-DBF driver error: SQL parser error in statement: create table punti_interpolazione.cross_test ( cat integer, flt1 double precision) Error in db_execute_immediate() GRASS_INFO_ERROR(2693,1): Cannot create table: create table punti_interpolazione.cross_test ( cat integer, flt1 double precision) (end) and i don t understand what is the problem, as there is not this pb for the interpolation itself thanks -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Thu Jun 8 12:58:58 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Jun 8 12:59:00 2006 Subject: [GRASS-dev] [bug #4558] (grass) problem with v.surf.rst cross validation Message-ID: <20060608105858.B86E21005D8@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4558 ------------------------------------------------------------------------- Subject: problem with v.surf.rst cross validation hi I m using grass6.0 I m trying to use the function v.surf.rst it does the interpolation but when withou changing any parameters i try to do the cross validations comes this error v.surf.rst input=punti_interpolazione layer=0 dmax=4.999977 dmin=0.999995 cvdev=cross_test zmult=1.0 tension=40. smooth=0.1 segmax=40 npmin=100 -v Authors: original version - H.Mitasova, L.Mitas, I. Kosinovsky, D.P. Gerdes See manual pages for reference and publications T3 DBMI-DBF driver error: SQL parser error in statement: create table punti_interpolazione.cross_test ( cat integer, flt1 double precision) Error in db_execute_immediate() GRASS_INFO_ERROR(2693,1): Cannot create table: create table punti_interpolazione.cross_test ( cat integer, flt1 double precision) (end) and i don t understand what is the problem, as there is not this pb for the interpolation itself thanks -------------------------------------------- Managed by Request Tracker From hamish_nospam at yahoo.com Thu Jun 8 14:47:45 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Jun 8 14:47:50 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: <20060607201803.GA32453@gdf-hannover.de> References: <20060607201803.GA32453@gdf-hannover.de> Message-ID: <20060609004745.0e31b819.hamish_nospam@yahoo.com> IMO we should pick a GUI language based on its long term merits, not because we have a nice editor for one. Fast development is nice, but lack of bug reports is much nicer. (especially if they are upstream bugs) Having the resulting GUI look somewhat native is indeed very important on the Mac. Looking native but acting like GRASS on all platforms isn't too bad I think. Rewritting to conditionally "become" a Mac app on Mac and no where else is surely a bad idea. Linux people will be used to a world of heterogenous interfaces and Windows people will be used to a world of pain ... but on Mac ... if I understand correctly Python seems to be a common theme, that's nice to see. Can anyone test v.pydigit on Mac + native GTK? Win+WinGTK? Would pyGTK it need to have libglade on all platforms? Or just for development? David: > I was toying with the idea of creating a Matlab or R-style GUI for > grass. The idea would be to have a command line interface with helper > applications such as graphics monitors, text editor, file browser, > help-system, etc. All accessible from tool bars. People seem to really > like Matlab once they learn it and I thought that if a grass version > were done right, even guys like me might use it (which means that I > better write code that I want to use!). FWIW, I really like the Matlab language & engine but I hate the 6+ GUI command interface. I run it -nojvm from my normal rxvt terminal window with nedit in Matlab mode for the editor. For me, I need to focus when working with it and a cluttered command window really hurts that. It doesn't help that the Java interface is slow, buggy, and the fonts horrible. I don't know R so well, so there the GUI version is a nice crutch -- I can see the advantage to the concept. Hamish From david.p.finlayson at gmail.com Thu Jun 8 17:52:31 2006 From: david.p.finlayson at gmail.com (David Finlayson) Date: Thu Jun 8 17:52:33 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: <20060609004745.0e31b819.hamish_nospam@yahoo.com> References: <20060607201803.GA32453@gdf-hannover.de> <20060609004745.0e31b819.hamish_nospam@yahoo.com> Message-ID: On 6/8/06, Hamish wrote: > IMO we should pick a GUI language based on its long term merits, not > because we have a nice editor for one. Fast development is nice, but > lack of bug reports is much nicer. (especially if they are upstream > bugs) > Indeed. WIth the exception of Visual Basic, I've always built GUI code by hand. In the end it makes for cleaner code. Here (wxpython or pygtk) widgets and event handlers are rarely more than a few lines of code each anyway. Mark Lutz's book on Programming Python (a classic now) has some nice examples of programming GUI code in Tcl/tk. He shows how to use mixen classes to wrap up the tedious parts of the GUI construction. There are two advantages: 1. Common objects are easy to instantiate with sensible defaults 2. More importantly, you isolate the program from the underlying GUI implementation so that the GUI toolkit can be changed in the future by modifying the mixen class methods in one place (for example, when GTK becomes native on OS X) without modifying the main program calls. Python is about 80% lisp now. Which means you can write meta programs that write programs. Its a powerful concept once you start working with it. Hammish: > > FWIW, I really like the Matlab language & engine but I hate the 6+ GUI > command interface. I run it -nojvm from my normal rxvt terminal window > with nedit in Matlab mode for the editor. For me, I need to focus when > working with it and a cluttered command window really hurts that. > It doesn't help that the Java interface is slow, buggy, and the fonts > horrible. I don't know R so well, so there the GUI version is a nice > crutch -- I can see the advantage to the concept. > > In my opinion, one of the problems with a GUI is that you have to learn GRASS twice to use it in scripts. Once, you learn the buttons for getting things done. Twice, you learn the commands to do the same thing. That makes scripting a high barrier to cross and a lot of people never learn how to automate there work. In CLI, you only learn the program once, you use the same command for interactive and scripting use. Just like the big math programming languages. This must work because all of the big math programs use this approach (Matlab, Maple, Mathematica, R, S-plus, etc.) and many of these are popular with their users. BUT, the main problem with the CLI is discoverability. You can't use it if you don't know the commands and weak CLI do not assist in the tedious usage parts. And there are some things that are just easier when interactive, like laying out a figure. So, a nice IDE can really make using the program easier by providing helper tools that make the CLI friendlier and more discoverable. My idea is to combine the best of both worlds. Focus on the CLI so that the user only learns the tool one way. But make it discoverable. For example, the GUI-IDE thing could have a tree view of all the available programs organized by task. An executable index to all grass programs. A browser for locations/mapsets, etc. Use the same tool to drag-and-drop a simple script in the built-in editor. This is a different paradigm than a full-on GUI like is found on Qgis. We can implement different GUIs for GRASS 7 and see which one becomes popular enough to support in the main distribution. From grass-bugs at intevation.de Thu Jun 8 18:13:06 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Jun 8 18:13:07 2006 Subject: [GRASS-dev] [bug #4560] (grass) Message-ID: <20060608161306.A1C031006A6@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4560 ------------------------------------------------------------------------- Subject: -------------------------------------------- Managed by Request Tracker From david.p.finlayson at gmail.com Thu Jun 8 20:26:45 2006 From: david.p.finlayson at gmail.com (David Finlayson) Date: Thu Jun 8 20:26:50 2006 Subject: [GRASS-dev] A portible shell for GRASS 7+ ? Message-ID: IPython is an advanced interactive shell for Python. It has a lot of features that make interactive use of Python very powerful. I think that we could write some wrappers around the GRASS programs and completely replace BASH as shell for GRASS. What we would get out of this is: 1. Tab completion for GRASS programs 2. Python as a scripting language (no problems "shelling out" to C or Fortran) 3. IPython is already thread-safe for wxPython GUIs 4. A lot of math tools for plotting and math are already using IPython as a shell 5. Very powerful introspection capabilities for programs. 6. Windows, Unix, Mac all supported and mature. 7. Future of IPython is network aware for clustered use of GRASS! The list is too long... Take a look: http://ipython.scipy.org/ What do you think? I'd be willing to start writing the software to "wrap" our existing programs so that they work with IPython interactively. -- David Finlayson From david.p.finlayson at gmail.com Thu Jun 8 20:34:11 2006 From: david.p.finlayson at gmail.com (David Finlayson) Date: Thu Jun 8 20:34:13 2006 Subject: [GRASS-dev] Re: A portible shell for GRASS 7+ ? In-Reply-To: References: Message-ID: I should add, that one of IPython's features is "autocall". This removes the need to use parethesis in function calls. What is cool about this is that we could write wrappers around the grass programs as functions and within IPython, the syntax of calling the functions would be virtually identical with the current documentation: For example: class general: def list(type, mapset): print os.popen('g.list type=%, mapset=%' % (type, mapset)) Would be called like this in normal Python: > import grass > g = grass.general() > g.list(type, mapset) .... In IPython, this could be: > import grass > g = grass.general() > g.list type, mapset ... That looks almost identical to the current bash command! From wolf+grass at bergenheim.net Thu Jun 8 22:17:01 2006 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Thu Jun 8 22:17:04 2006 Subject: [GRASS-dev] A portible shell for GRASS 7+ ? In-Reply-To: References: Message-ID: On Thu, 8 Jun 2006, David Finlayson wrote: > > What do you think? > Sounds promising, but, personally I'd hate it. Why? First off one of the coolest things with grass is that I get my trusted old tcsh (which I have been using since 1996), I was delighted. This means that to do many things I don't need to learn anything new. I can use env variables and loops and whatnot, all things that I'm used to. I do realize that for people in mac or windows worlds or people new to computers don't know all this and for them it would be all the same. Secondly I'd need to learn python to do any scripting, which sucks. Thirdly I like to have all the gazillion of command-line programs that I have, to filter and do all kinds of magic from withing GRASS. I can also easily launch any non-grass application WITHOUT LEAVING THE GRASS SHELL. And my final argument is: Why would we re-invent the wheel? Command-line shells have been around for a very long time which means that a lot of effort has gone into them, and to be frank we don't have that many resources that we should use it on re-inventing the wheel. --W -- <:3 )---- Wolf Bergenheim ----( 8:> From glynn at gclements.plus.com Thu Jun 8 22:09:59 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jun 8 22:21:15 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: References: <17543.25526.32069.86046@cerise.gclements.plus.com> Message-ID: <17544.33815.619566.632663@cerise.gclements.plus.com> Michael Barton wrote: > Ideally, we should be able to write one piece of GUI code that will run on > all platforms, without x11 on Windows and preferably running under aqua on a > Mac. > > Does anyone looking into either wxPython or pyGTK know if this can be done > with either of these platforms? > > The whole idea of not requiring x11 for GRASS is kind of lost if it is > required for the GUI. By the same token, it would be difficult to maintain 3 > different versions of the GUI (unless the differences were very minimal). wxPython uses wxWidgets, which uses the platform's native widgets. This provides a more native look-and-feel, but is harder to code for, as there tend to be subtle differences between the behaviour of similar widgets on different platforms. wxGTK uses GTK; whether or not that requires an X server depends upon whether you use the platform's native GTK port or the X11 version. On Unix systems (other than MacOSX), the X11 version /is/ the native version. On Windows, there is a mature native version, while Cygwin offers an X11-based GTK package. You would only use the Cygwin version if you require an especially high degree of compatibility, e.g. because the application directly uses X11 functions in addition to GTK functions. On MacOSX, the native port appears to be at an alpha stage (based upon the "todo" list on the web site). Also, running Unix/X11 applications isn't as problematic on OSX as it is on Windows, as you don't need a Cygwin-style compatibility layer. -- Glynn Clements From glynn at gclements.plus.com Thu Jun 8 22:22:29 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jun 8 22:22:38 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: References: <20060607201803.GA32453@gdf-hannover.de> <20060609004745.0e31b819.hamish_nospam@yahoo.com> Message-ID: <17544.34565.331515.143038@cerise.gclements.plus.com> David Finlayson wrote: > In my opinion, one of the problems with a GUI is that you have to > learn GRASS twice to use it in scripts. Once, you learn the buttons > for getting things done. Twice, you learn the commands to do the same > thing. That makes scripting a high barrier to cross and a lot of > people never learn how to automate there work. In CLI, you only learn > the program once, you use the same command for interactive and > scripting use. Just like the big math programming languages. This must > work because all of the big math programs use this approach (Matlab, > Maple, Mathematica, R, S-plus, etc.) and many of these are popular > with their users. > > BUT, the main problem with the CLI is discoverability. You can't use > it if you don't know the commands and weak CLI do not assist in the > tedious usage parts. And there are some things that are just easier > when interactive, like laying out a figure. So, a nice IDE can really > make using the program easier by providing helper tools that make the > CLI friendlier and more discoverable. For GRASS, the main problem with a command line is that specifying points by typing in coordinates is a lot less convenient than using a mouse. Modules such as v.digit and i.points /need/ a GUI. Beyond that, the visualisation aspects of gis.m should ultimately be able to be controlled from the command line. I.e. being able to type a command to add, move, modify, hide (etc) layers, rather than having to use buttons or menus. Even from a command-line perspective, the existing display architecture is deficient in that you can't modify the layer stack other than adding a new layer on the top or clearing the stack altogether. -- Glynn Clements From glynn at gclements.plus.com Thu Jun 8 22:33:04 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jun 8 22:33:12 2006 Subject: [GRASS-dev] Re: A portible shell for GRASS 7+ ? In-Reply-To: References: Message-ID: <17544.35200.478408.95690@cerise.gclements.plus.com> David Finlayson wrote: > I should add, that one of IPython's features is "autocall". This > removes the need to use parethesis in function calls. What is cool > about this is that we could write wrappers around the grass programs > as functions and within IPython, the syntax of calling the functions > would be virtually identical with the current documentation: > > For example: > > class general: > def list(type, mapset): > print os.popen('g.list type=%, mapset=%' % (type, mapset)) You don't want to be using a popen()-style interface which takes an entire command as a string and uses the shell to decompose it, but something which takes a list of arguments. Using the shell is a nuisance if any of the arguments need to contain spaces or shell metacharacters. -- Glynn Clements From michael.barton at asu.edu Thu Jun 8 22:45:37 2006 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jun 8 22:45:43 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: <20060609004745.0e31b819.hamish_nospam@yahoo.com> Message-ID: I'm willing to test, but what does it take to test this? I'm running GIMP under x11, so I must have some version of GTK+ installed. Can I just get it and run it or do I have to do anything? ..... With respect to GUI design and platforms, I suggest we take things one step at a time since we don't have a large development/design team, but do have quite a bit of interest. Out of the next generation GUI discussion of last Fall and early this year, the basic plan was to... 1) Come up with a set of interface design specs. 2) Implement the new design specs as well as possible in the current TclTk platform. 3) Identify and migrate to a new GUI platform if needed. 4) This step was not discussed, but reasonably, it would be to review and revise if necessary the overall GUI design specs in the context of the new GUI platform. We're almost through step 2. I recommend that we try to implement the design specs we are just now completing in TclTk in a new platform, rather than trying to migrate to a new platform AND comprehensively change the interface design again (after just barely getting it out the door over the last 4-5 months). The latter seems overly ambitious and likely to devolve into UI chaos, with multiple competing designs. Currently, we have a team of people all working together on the same design plan and same GUI platform. The result is how much it has progressed in such a short time. I'd hate to lose that kind of synergy. Granted, a reason for switching from TclTk to another GUI platform is that it gives us richer options for a GUI (we already have very rich CLI options). But it seems better to begin to explore those by improving on the design specs we now have, rather than starting from scratch. And to be honest, if the idea of learning Python (I've already started, given that it is summer and I can work it in around writing and analysis) seems a little daunting, the idea of learning Python, building a GUI, AND redesigning the GUI from the ground up seems exhausting. 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: Fri, 9 Jun 2006 00:47:45 +1200 > To: > Subject: Re: [GRASS-dev] Python GUI toolkits > > IMO we should pick a GUI language based on its long term merits, not > because we have a nice editor for one. Fast development is nice, but > lack of bug reports is much nicer. (especially if they are upstream > bugs) > > > Having the resulting GUI look somewhat native is indeed very important > on the Mac. Looking native but acting like GRASS on all platforms isn't > too bad I think. Rewritting to conditionally "become" a Mac app on Mac > and no where else is surely a bad idea. Linux people will be used to a > world of heterogenous interfaces and Windows people will be used to a > world of pain ... but on Mac ... if I understand correctly > > Python seems to be a common theme, that's nice to see. > > > Can anyone test v.pydigit on Mac + native GTK? Win+WinGTK? > Would pyGTK it need to have libglade on all platforms? > Or just for development? > > > David: >> I was toying with the idea of creating a Matlab or R-style GUI for >> grass. The idea would be to have a command line interface with helper >> applications such as graphics monitors, text editor, file browser, >> help-system, etc. All accessible from tool bars. People seem to really >> like Matlab once they learn it and I thought that if a grass version >> were done right, even guys like me might use it (which means that I >> better write code that I want to use!). > > FWIW, I really like the Matlab language & engine but I hate the 6+ GUI > command interface. I run it -nojvm from my normal rxvt terminal window > with nedit in Matlab mode for the editor. For me, I need to focus when > working with it and a cluttered command window really hurts that. > It doesn't help that the Java interface is slow, buggy, and the fonts > horrible. I don't know R so well, so there the GUI version is a nice > crutch -- I can see the advantage to the concept. > > > > Hamish > > From michael.barton at asu.edu Thu Jun 8 22:50:19 2006 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jun 8 22:50:29 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: <17544.33815.619566.632663@cerise.gclements.plus.com> Message-ID: Does this mean that a scrolling tree widget, for example, that I coded in wxPython (using my Mac as a development machine with the installation of wxWidgets that comes with wxPython) might not work properly in Linux? Or that it might not 'look' the same? I'm not trying to be overly picky, but trying to find out whether this is or is not really an issue for a GUI that simply sits on top of GRASS. The web page propaganda says code once and have it run on all, of course. 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: Glynn Clements > Date: Thu, 8 Jun 2006 21:09:59 +0100 > To: Michael Barton > Cc: David Finlayson , Jachym Cepicky > , GRASS developers list > Subject: Re: [GRASS-dev] Python GUI toolkits > > > wxPython uses wxWidgets, which uses the platform's native widgets. > This provides a more native look-and-feel, but is harder to code for, > as there tend to be subtle differences between the behaviour of > similar widgets on different platforms. > From michael.barton at asu.edu Thu Jun 8 23:46:38 2006 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jun 8 23:47:17 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: <20060608211013.GA9851@gdf-hannover.de> Message-ID: Jachym, The screenshots of v.pydigit look great. I just downloaded and tried to run v.pydigit--just to see what happened. It failed, saying I needed pygtk (I've got Python 2.4+ installed). I went to the pyGTK website. There does not seem to be a pyGTK binary for Mac OSX, although there is one for Windows. I dug around a bit, it seems that compiling it on the Mac is somewhat tricky. It looks like it could be available from Darwinports. I haven't used this (except for a brief tryout) because it messes with some of my system settings, making it difficult for me to run other x11 programs. Maybe Fink has it, but I haven't checked yet. This makes me hearken back to the days of GRASS 5.0.1, when I had to search around for a proper version of TclTk to run it. This isn't very attractive to go through this just to be able to develop and run the package--especially given I'd need to put it on my laptop too. 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: Jachym Cepicky > Date: Thu, 8 Jun 2006 23:10:17 +0200 > To: Michael Barton > Subject: Re: [GRASS-dev] Python GUI toolkits > > On Thu, Jun 08, 2006 at 01:45:37PM -0700, Michael Barton wrote: >> I'm willing to test, but what does it take to test this? I'm running GIMP >> under x11, so I must have some version of GTK+ installed. Can I just get it >> and run it or do I have to do anything? > > hallo, just get it and run ./v.pydigit > > dependences are: > * python > * python-glade2 > * python-gtk2 > * grass61 > > these are the names of packages under debian. I have no idea, how to get > them on other distro/unix :-( > > short description > > http://les-ejk.cz/?cat=vpydigit > > I'm looking forward to result > > Jachym > > >> >> ..... >> >> With respect to GUI design and platforms, I suggest we take things one step >> at a time since we don't have a large development/design team, but do have >> quite a bit of interest. >> >> Out of the next generation GUI discussion of last Fall and early this year, >> the basic plan was to... >> >> 1) Come up with a set of interface design specs. >> 2) Implement the new design specs as well as possible in the current TclTk >> platform. >> 3) Identify and migrate to a new GUI platform if needed. >> 4) This step was not discussed, but reasonably, it would be to review and >> revise if necessary the overall GUI design specs in the context of the new >> GUI platform. >> >> We're almost through step 2. >> >> I recommend that we try to implement the design specs we are just now >> completing in TclTk in a new platform, rather than trying to migrate to a >> new platform AND comprehensively change the interface design again (after >> just barely getting it out the door over the last 4-5 months). The latter >> seems overly ambitious and likely to devolve into UI chaos, with multiple >> competing designs. >> >> Currently, we have a team of people all working together on the same design >> plan and same GUI platform. The result is how much it has progressed in such >> a short time. I'd hate to lose that kind of synergy. >> >> Granted, a reason for switching from TclTk to another GUI platform is that >> it gives us richer options for a GUI (we already have very rich CLI >> options). But it seems better to begin to explore those by improving on the >> design specs we now have, rather than starting from scratch. And to be >> honest, if the idea of learning Python (I've already started, given that it >> is summer and I can work it in around writing and analysis) seems a little >> daunting, the idea of learning Python, building a GUI, AND redesigning the >> GUI from the ground up seems exhausting. >> >> 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: Fri, 9 Jun 2006 00:47:45 +1200 >>> To: >>> Subject: Re: [GRASS-dev] Python GUI toolkits >>> >>> IMO we should pick a GUI language based on its long term merits, not >>> because we have a nice editor for one. Fast development is nice, but >>> lack of bug reports is much nicer. (especially if they are upstream >>> bugs) >>> >>> >>> Having the resulting GUI look somewhat native is indeed very important >>> on the Mac. Looking native but acting like GRASS on all platforms isn't >>> too bad I think. Rewritting to conditionally "become" a Mac app on Mac >>> and no where else is surely a bad idea. Linux people will be used to a >>> world of heterogenous interfaces and Windows people will be used to a >>> world of pain ... but on Mac ... if I understand correctly >>> >>> Python seems to be a common theme, that's nice to see. >>> >>> >>> Can anyone test v.pydigit on Mac + native GTK? Win+WinGTK? >>> Would pyGTK it need to have libglade on all platforms? >>> Or just for development? >>> >>> >>> David: >>>> I was toying with the idea of creating a Matlab or R-style GUI for >>>> grass. The idea would be to have a command line interface with helper >>>> applications such as graphics monitors, text editor, file browser, >>>> help-system, etc. All accessible from tool bars. People seem to really >>>> like Matlab once they learn it and I thought that if a grass version >>>> were done right, even guys like me might use it (which means that I >>>> better write code that I want to use!). >>> >>> FWIW, I really like the Matlab language & engine but I hate the 6+ GUI >>> command interface. I run it -nojvm from my normal rxvt terminal window >>> with nedit in Matlab mode for the editor. For me, I need to focus when >>> working with it and a cluttered command window really hurts that. >>> It doesn't help that the Java interface is slow, buggy, and the fonts >>> horrible. I don't know R so well, so there the GUI version is a nice >>> crutch -- I can see the advantage to the concept. >>> >>> >>> >>> Hamish >>> >>> >> >> _______________________________________________ >> 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 jachym.cepicky at centrum.cz Fri Jun 9 00:00:53 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Fri Jun 9 00:01:55 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: References: <20060608211013.GA9851@gdf-hannover.de> Message-ID: <20060608220052.GA4880@gdf-hannover.de> hallo, On Thu, Jun 08, 2006 at 02:46:38PM -0700, Michael Barton wrote: > Jachym, > > The screenshots of v.pydigit look great. I just downloaded and tried to run > v.pydigit--just to see what happened. > > It failed, saying I needed pygtk (I've got Python 2.4+ installed). I feel bad about it :-( > > I went to the pyGTK website. There does not seem to be a pyGTK binary for > Mac OSX, although there is one for Windows. I dug around a bit, it seems > that compiling it on the Mac is somewhat tricky. It looks like it could be > available from Darwinports. I haven't used this (except for a brief tryout) > because it messes with some of my system settings, making it difficult for > me to run other x11 programs. Maybe Fink has it, but I haven't checked yet. > > This makes me hearken back to the days of GRASS 5.0.1, when I had to search > around for a proper version of TclTk to run it. This isn't very attractive > to go through this just to be able to develop and run the > package--especially given I'd need to put it on my laptop too. > > Michael You are right, this does not seem that easy, as it is on linux. If I understood it correctly, wxpython seems to work for you? 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/20060609/59bfac31/attachment-0001.bin From michael.barton at asu.edu Fri Jun 9 00:13:22 2006 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jun 9 00:13:37 2006 Subject: [GRASS-dev] Re: grass-dev Digest, Vol 2, Issue 19 In-Reply-To: <200606082202.k58M20YA032603@grass.itc.it> Message-ID: wxPython installed in a snap and the demos seem to run flawlessly. I'm personally not concerned about having to run x11 or not on my Mac (do it all the time), but some people find it a little intimidating. My main concerns are... 1) Is it relatively easy for individuals who volunteer to help develop [including me :-)] to be able to contribute, regardless of the platform they work on? In fact it is better if the GUI developers, especially, work on different platforms to make sure that GRASS works the same on all supported systems. 2) We should try to limit the quantity and complexity of coding that needs to be done to the extent possible, compatible with getting high quality results. This is why a Python-based approach seems very attractive. So we shouldn't settle on a system that very few people can use or learn and we should avoid having to maintain multiple versions of the GUI for each platform. TclTk is good in both respects. So we should maintain this kind of environment to the extent possible in any new platform. 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: Fri, 9 Jun 2006 00:02:00 +0200 > To: > Subject: grass-dev Digest, Vol 2, Issue 19 > > > You are right, this does not seem that easy, as it is on linux. > If I understood it correctly, wxpython seems to work for you? > > Jachym > From joel.pitt at gmail.com Fri Jun 9 01:31:36 2006 From: joel.pitt at gmail.com (Joel Pitt) Date: Fri Jun 9 01:31:38 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: <20060609004745.0e31b819.hamish_nospam@yahoo.com> References: <20060607201803.GA32453@gdf-hannover.de> <20060609004745.0e31b819.hamish_nospam@yahoo.com> Message-ID: On 6/9/06, Hamish wrote: > Would pyGTK it need to have libglade on all platforms? > Or just for development? If you design the GUI with glade then you need libglade at runtime. pyGTK does not *need* libglade to be used, and I'm somewhat hesitant about having libglade required across platforms. IMHO glade is great for prototyping, but for clean and well designed code - especially with regards to OO encapsulation of GUI elements - then writing the GUI directly with pyGTK is best. Considering that people seem to really want a native look and feel I think wxPython is our best bet, with wxglade for prototyping until we can solidify the GUI into well designed code. From what people are saying native GTK ports seem to be difficult and buggy in MacOSX... On the other hand, we could always use Java for the GUI... (although in seriousness there is SWT http://www.eclipse.org/swt/ , which binds Java to the native GUI libraries - and runs quickly because it uses the actual libraries, not JAVA interpretations) -- -Joel "Wish not to seem, but to be, the best." -- Aeschylus From joel.pitt at gmail.com Fri Jun 9 01:51:49 2006 From: joel.pitt at gmail.com (Joel Pitt) Date: Fri Jun 9 01:51:50 2006 Subject: [GRASS-dev] A portible shell for GRASS 7+ ? In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Joel Pitt Date: Jun 9, 2006 11:50 AM Subject: Re: [GRASS-dev] A portible shell for GRASS 7+ ? To: Wolf Bergenheim I can see both sides and their benefits. But I don't think we should force people to use a python shell since alot of GRASS users are bash/tcsh wizards. I think we should combine some ideas here. In the thread "Python GUI toolkits" David mentioned an R or Matlab style GUI - I like this, I also like the idea of being able to use python to throw up custom graphs of GIS data (although I know R can do this as well). Perhaps we could create a GUI that allowed you to have multiple shells open, R for GRASS, a bash shell, an IPython one. Come to think of it there isn't any reason why these shells can't exist on their own... Hmm, seems I've come to the end of my train of thought. -joel On 6/9/06, Wolf Bergenheim wrote: > On Thu, 8 Jun 2006, David Finlayson wrote: > > > > What do you think? > > > > Sounds promising, but, personally I'd hate it. Why? > > > First off one of the coolest things with grass is that I get my trusted > old tcsh (which I have been using since 1996), I was delighted. This means > that to do many things I don't need to learn anything new. I can use env > variables and loops and whatnot, all things that I'm used to. I do realize > that for people in mac or windows worlds or people new to computers don't > know all this and for them it would be all the same. Secondly I'd need to > learn python to do any scripting, which sucks. Thirdly I like to have all > the gazillion of command-line programs that I have, to filter and do all > kinds of magic from withing GRASS. I can also easily launch any non-grass > application WITHOUT LEAVING THE GRASS SHELL. And my final argument is: Why > would we re-invent the wheel? Command-line shells have been around for a > very long time which means that a lot of effort has gone into them, and to > be frank we don't have that many resources that we should use it on > re-inventing the wheel. > -- -Joel "Wish not to seem, but to be, the best." -- Aeschylus -- -Joel "Wish not to seem, but to be, the best." -- Aeschylus From david.p.finlayson at gmail.com Fri Jun 9 05:12:42 2006 From: david.p.finlayson at gmail.com (David Finlayson) Date: Fri Jun 9 05:12:44 2006 Subject: [GRASS-dev] A portible shell for GRASS 7+ ? In-Reply-To: References: Message-ID: Wolf, Joel: ... OK, in retrospect proposing a new shell for GRASS 7 was provocative. I don't want that kind pressure for a hobby project. Consider this a proposal for an optional download. Besides, you're preaching to the choir...search the mailing lists for my name and command line and you will find at least several rants of my own on this topic. I need full scripting capability for GRASS and access to Unix and custom programs I have written for my projects. I would never compromise that. So, why am I proposing a Python shell for GRASS? 1. I am intrigued by the possibility of making a Matlab of GIS. GRASS is the perfect candidate for this. Python and the IPython interpreter have all the tools needed to make a higher-level shell. Think of this as the exact compliment to Qgis. Where Qgis wants to make a GIS with lowest possible barrier to entry, I want to make a GIS with the highest possible productivity for intermediate to advanced users: * Imagine having a command line that auto completes options, layers, raster and vector names! * How about a display monitor that could be controlled by the command line or the GUI at the same time (a la Matlabs graphics figures)? * How about having complete access to the GRASS API via Python SWIG? * All in the same shell? Bottom line though is that if I want some creative control over how the GRASS CLI evolves, I need to shut up and code. 2. Windows GRASS needs this badly. The DOS shell is OK for some things but Windows comes with no tools for working with text, or databases, etc., etc., etc. Python provides a lot of power through its libraries and it is very easy to extend. Using IPython as a shell would really improve the tool set of native GRASS on Windows with no need for emulating a Unix environment. 3. I think a lot of GUI-only people would consider the command line if it was a little easier to learn and use. A GRASS IDE (if you will), might be really cool. It might be powerful, too. From david.p.finlayson at gmail.com Fri Jun 9 06:13:05 2006 From: david.p.finlayson at gmail.com (David Finlayson) Date: Fri Jun 9 06:13:08 2006 Subject: [GRASS-dev] Re: grass-dev Digest, Vol 2, Issue 19 In-Reply-To: References: <200606082202.k58M20YA032603@grass.itc.it> Message-ID: FWIW, tk is the "default" GUI of Python and is installed by with virtually all Python platforms. On 6/8/06, Michael Barton wrote: > wxPython installed in a snap and the demos seem to run flawlessly. I'm > personally not concerned about having to run x11 or not on my Mac (do it all > the time), but some people find it a little intimidating. My main concerns > are... > > 1) Is it relatively easy for individuals who volunteer to help develop > [including me :-)] to be able to contribute, regardless of the platform they > work on? In fact it is better if the GUI developers, especially, work on > different platforms to make sure that GRASS works the same on all supported > systems. > > 2) We should try to limit the quantity and complexity of coding that needs > to be done to the extent possible, compatible with getting high quality > results. This is why a Python-based approach seems very attractive. So we > shouldn't settle on a system that very few people can use or learn and we > should avoid having to maintain multiple versions of the GUI for each > platform. TclTk is good in both respects. So we should maintain this kind of > environment to the extent possible in any new platform. > > 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: Fri, 9 Jun 2006 00:02:00 +0200 > > To: > > Subject: grass-dev Digest, Vol 2, Issue 19 > > > > > > You are right, this does not seem that easy, as it is on linux. > > If I understood it correctly, wxpython seems to work for you? > > > > Jachym > > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- David Finlayson From michael.barton at asu.edu Fri Jun 9 06:18:42 2006 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jun 9 06:18:47 2006 Subject: [GRASS-dev] Re: grass-dev Digest, Vol 2, Issue 19 In-Reply-To: Message-ID: Interesting. I noticed that Tkinter and other such programs were installed by default with my new Python package. I don't think that's a reason not to look for a better GUI. But I am learning that TclTk has been a pretty good choice for GRASS (not a primitive relic) up till we have started wanting to do some considerably more sophisticated interface things. It just wasn't used to its fullest. 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: David Finlayson > Date: Thu, 8 Jun 2006 21:13:05 -0700 > To: Michael Barton > Cc: > Subject: Re: [GRASS-dev] Re: grass-dev Digest, Vol 2, Issue 19 > > FWIW, tk is the "default" GUI of Python and is installed by with > virtually all Python platforms. > > From ychemin at gmail.com Fri Jun 9 06:24:55 2006 From: ychemin at gmail.com (Yann Chemin) Date: Fri Jun 9 06:24:57 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: <17544.34565.331515.143038@cerise.gclements.plus.com> References: <20060607201803.GA32453@gdf-hannover.de> <20060609004745.0e31b819.hamish_nospam@yahoo.com> <17544.34565.331515.143038@cerise.gclements.plus.com> Message-ID: <6278879c0606082124g6c0571f6o61ce43217f0f580f@mail.gmail.com> Each time we finish a GRASS GIS lab session (3-4 hours), i run the script of the whole lab in 1-2 minutes in front of the students, you should see their reaction! Such "assisted" scripting capability would be a serious advantage for fastening the learning curve to advanced level processing. Aggreed, not all processing can be done scripting-side, but surely a lot can be done. Besides, GRASS GIS is changing fast, having a way to list & pick-up commands can really help out here. 2006/6/9, Glynn Clements : > > > David Finlayson wrote: > > > In my opinion, one of the problems with a GUI is that you have to > > learn GRASS twice to use it in scripts. Once, you learn the buttons > > for getting things done. Twice, you learn the commands to do the same > > thing. That makes scripting a high barrier to cross and a lot of > > people never learn how to automate there work. In CLI, you only learn > > the program once, you use the same command for interactive and > > scripting use. Just like the big math programming languages. This must > > work because all of the big math programs use this approach (Matlab, > > Maple, Mathematica, R, S-plus, etc.) and many of these are popular > > with their users. > > > > BUT, the main problem with the CLI is discoverability. You can't use > > it if you don't know the commands and weak CLI do not assist in the > > tedious usage parts. And there are some things that are just easier > > when interactive, like laying out a figure. So, a nice IDE can really > > make using the program easier by providing helper tools that make the > > CLI friendlier and more discoverable. > > For GRASS, the main problem with a command line is that specifying > points by typing in coordinates is a lot less convenient than using a > mouse. > > Modules such as v.digit and i.points /need/ a GUI. > > Beyond that, the visualisation aspects of gis.m should ultimately be > able to be controlled from the command line. I.e. being able to type a > command to add, move, modify, hide (etc) layers, rather than having to > use buttons or menus. > > Even from a command-line perspective, the existing display > architecture is deficient in that you can't modify the layer stack > other than adding a new layer on the top or clearing the stack > altogether. > > -- > Glynn Clements > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060609/c1b79ea1/attachment-0001.html From grass-bugs at intevation.de Fri Jun 9 06:34:43 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Fri Jun 9 06:34:45 2006 Subject: [GRASS-dev] [bug #4562] (grass) hi Message-ID: <20060609043443.A85FF1005BB@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4562 ------------------------------------------------------------------------- Haven't you liked walking?. Thu, 08 Jun 2006 21:36:53 -0800 grass-bugs@intevation.de Broaden your opportunities with a degree. online There are no .required tests, classes, books, or interviews! Bachelor.s, Master.s, MBA, and Doct.orate (PhD) Dip.loma! Call us now 1.2.0.6-984-1672 24.hours a day 7.days a week With Love Malcolm Hilton That carpenter is practicing running at this time.. I am enjoying eating in the river.. 2. Toren came to me at age 32 months. He had 2 words: Ma Ma and Bye Bye. He could not focus, but ran around the room. His mother was convinced I was going to have him cured by his third birthday. I told her I was no miracle worker, but we'd do what we could during the next 4 months. Immediately we started structuring Toren's day. I went home and worked up a program called 'Toren's Nouns'. The first day I showed Toren the program, he looked at it for 10-15 seconds and then left the computer. The next day he stayed about 30 seconds. Each day he built up more time at the computer. By the second week, he would sit on my lap for 10 minutes pressing whichever word he wanted to hear. But he spoke no sounds, no words. Three weeks passed. I began berating myself. 'See, Jo, you thought this noun program was so great. Look at Toren, he's not learning anything.' The fourth week Toren walked over to the computer, picked up the overlay from the IntelliKeys keyboard, pointed to 10 different w ords and approximated each word. That day, I cried.. --- Headers Follow --- >From PeelEury@mediacom.net Fri Jun 9 06:34:43 2006 Return-Path: Delivered-To: grass-bugs@lists.intevation.de Received: from mail.intevation.de (aktaia [212.95.126.10]) by lists.intevation.de (Postfix) with ESMTP id 704F51005AC for ; Fri, 9 Jun 2006 06:34:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.intevation.de (Postfix) with ESMTP id E42ED36DB1; Fri, 9 Jun 2006 06:34:42 +0200 (CEST) Received: from 500B8028 (24-181-43-245.dhcp.wspn.ga.charter.com [24.181.43.245]) by mail.intevation.de (Postfix) with SMTP id 3371F36E1C; Fri, 9 Jun 2006 06:34:18 +0200 (CEST) Received: from accentus.acetylrosaniline.net by amphoriloquy.yahoo.ca with SMTP; Fri, 09 Jun 2006 06:28:53 +0100 Date: Fri, 09 Jun 2006 10:29:53 +0500 From: "Garrett Lewis" To: grass-bugs@intevation.de Subject: hi Message-ID: <0Bw578rES1.4955.x956e7C8D4@localhost> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.0 tagged_above=-999.0 required=3.0 tests=BAYES_44 X-Spam-Level: -------------------------------------------- Managed by Request Tracker From michael.barton at asu.edu Fri Jun 9 06:35:13 2006 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jun 9 06:35:17 2006 Subject: [GRASS-dev] Re: grass-dev Digest, Vol 2, Issue 20 In-Reply-To: <200606090425.k594P1Ef003616@grass.itc.it> Message-ID: I want to point out that ?assisted scripting? and command line learning is already available in the current (new and still not quite finished) GIS Manager. The command console records all commands run by the GUI and keeps a running history of commands and their output. By clicking on any command in the history window, it is put into the command console at the bottom where you can modify it and run it. Type ?til your heart?s content. You can also cut and paste individual commands into a script if you want to build one. I realize that GRASS and its interface is changing rapidly, sometimes on a weekly basis. But we are trying to maintain (and improve) a robust command line while making a much more usable GUI. 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: Fri, 9 Jun 2006 06:25:01 +0200 To: Subject: grass-dev Digest, Vol 2, Issue 20 From: Yann Chemin Date: Fri, 9 Jun 2006 11:24:55 +0700 To: Subject: Re: [GRASS-dev] Python GUI toolkits Each time we finish a GRASS GIS lab session (3-4 hours), i run the script of the whole lab in 1-2 minutes in front of the students, you should see their reaction! Such "assisted" scripting capability would be a serious advantage for fastening the learning curve to advanced level processing. Aggreed, not all processing can be done scripting-side, but surely a lot can be done. Besides, GRASS GIS is changing fast, having a way to list & pick-up commands can really help out here. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060608/429f0605/attachment.html From david.p.finlayson at gmail.com Fri Jun 9 06:55:35 2006 From: david.p.finlayson at gmail.com (David Finlayson) Date: Fri Jun 9 06:55:38 2006 Subject: [GRASS-dev] Re: grass-dev Digest, Vol 2, Issue 19 In-Reply-To: References: Message-ID: As far as I am concerned, there are more pressing issues for GRASS than the GUI. #1. is an (optional) portable shell that doesn't require (but doesn't inhibit) a UNIX back end #2. is a complete face-lift to the map production capabilities of GRASS. I recently designed several large-format maps for a public display of our mapping capabilities (coastal USGS). I found that I didn't have the control or flexibility I needed in GRASS to do the maps the way I wanted. ps.map just isn't very powerful yet. I regressed to ArcGIS/Illustrator for the first time in over a year :( I think it was possible, just too difficult to script the rgb > his transformations in the short time I had available. Also the map decorations I needed just weren't available in GRASS. On 6/8/06, Michael Barton wrote: > Interesting. I noticed that Tkinter and other such programs were installed > by default with my new Python package. I don't think that's a reason not to > look for a better GUI. But I am learning that TclTk has been a pretty good > choice for GRASS (not a primitive relic) up till we have started wanting to > do some considerably more sophisticated interface things. It just wasn't > used to its fullest. > > 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: David Finlayson > > Date: Thu, 8 Jun 2006 21:13:05 -0700 > > To: Michael Barton > > Cc: > > Subject: Re: [GRASS-dev] Re: grass-dev Digest, Vol 2, Issue 19 > > > > FWIW, tk is the "default" GUI of Python and is installed by with > > virtually all Python platforms. > > > > > > -- David Finlayson From michael.barton at asu.edu Fri Jun 9 07:28:53 2006 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jun 9 07:29:00 2006 Subject: [GRASS-dev] Re: grass-dev Digest, Vol 2, Issue 19 In-Reply-To: Message-ID: David, Making final, complete publication quality map output has never been a strength of GRASS. The first script I wrote, d.out.png, was a result of frustration at having so few options of getting output from GRASS. It's major strengths has been as a research, analysis, and modeling package. The main way to do nice output has been to dump GRASS display to a graphics file and work on it in that. This is not such a bad model, given that very nice graphics layout and high-quality decorations requires quite a bit of programming to achieve. So it's not that bad an idea to leave it to InkScape or similar program to do that. That said, we are closer now to having publication-quality output than ever before. A simple example of this is that postscript text can now be added to the display. However, doing more of this will either involve a more sophisticated text/command file method like now in ps.map and gmt, or much heavier use of a GUI platform for text, decorations, and vectors. Improvements to the first method are not closely tied to the GUI, but require more enhancements to ps.map (quite a bit has been done in this regard over the past year). For the 2nd method, text and decorations are relatively straightforward, created in the same way as the zoom boxes and postscript text is now done in the GIS Manager. It just takes some programming drudgery, but this is the way that most people will want to make higher quality maps so it will need to be done. I've simply been too tied up with getting other parts done (profiler, georectifier, legend for thematic maps, etc) to rewrite the GRASS decoration display modules into TclTk (all were written to render in what is now considered a low-resolution display). If we are switching to a new GUI platform, I'd rather put the effort into doing nice display decorations in the new platform. The real sticker is vector rendering. Currently, vectors display just like rasters. Changing this requires changing how vector information is sent to a display. Different models for doing this are being worked on. An example is Jachym's prototype v.pydigit. One reason for a new GUI platform is that it could make more versatile visualization easier than it is under TclTk. How far to take this is another matter. Good cartographic output and layout requires a whole 'nother layer of programming on top of the display interface. It's generally done poorly in GIS packages for that reason. ArcGIS is finally getting close to something that works pretty well--after how long?--and this is an important component of its business. It's a good idea and it would be great if someone is willing to tackle it. However, I'd simply like to first get the current design into a new platform over the next year before we invest additional effort in adding new major interface features. For an alternative idea, it might be worth looking at the Cavnas (commercial graphics program) model. Add rudamentary GIS capabilities in a plugin to a good drawing or layout program like InkScape or Scribus, so that GRASS output or even GIS files could be brought into these for high-quality output. Just a rambling thought. 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: David Finlayson > Date: Thu, 8 Jun 2006 21:55:35 -0700 > To: Michael Barton > Cc: > Subject: Re: [GRASS-dev] Re: grass-dev Digest, Vol 2, Issue 19 > > As far as I am concerned, there are more pressing issues for GRASS than the > GUI. > > #1. is an (optional) portable shell that doesn't require (but doesn't > inhibit) a UNIX back end > #2. is a complete face-lift to the map production capabilities of GRASS. > > I recently designed several large-format maps for a public display of > our mapping capabilities (coastal USGS). I found that I didn't have > the control or flexibility I needed in GRASS to do the maps the way I > wanted. ps.map just isn't very powerful yet. I regressed to > ArcGIS/Illustrator for the first time in over a year :( > > I think it was possible, just too difficult to script the rgb > his > transformations in the short time I had available. Also the map > decorations I needed just weren't available in GRASS. > > From twiens at interbaun.com Fri Jun 9 08:07:49 2006 From: twiens at interbaun.com (Trevor Wiens) Date: Fri Jun 9 08:07:52 2006 Subject: [GRASS-dev] Re: grass-dev Digest, Vol 2, Issue 19 In-Reply-To: References: Message-ID: <20060609000749.45ac8f3d@localhost.localdomain> On Thu, 8 Jun 2006 21:55:35 -0700 "David Finlayson" wrote: > As far as I am concerned, there are more pressing issues for GRASS than the GUI. I disagree. See below. > #1. is an (optional) portable shell that doesn't require (but doesn't > inhibit) a UNIX back end > #2. is a complete face-lift to the map production capabilities of GRASS. > > I recently designed several large-format maps for a public display of > our mapping capabilities (coastal USGS). I found that I didn't have > the control or flexibility I needed in GRASS to do the maps the way I > wanted. ps.map just isn't very powerful yet. I regressed to > ArcGIS/Illustrator for the first time in over a year :( > > I think it was possible, just too difficult to script the rgb > his > transformations in the short time I had available. Also the map > decorations I needed just weren't available in GRASS. Cartography is a weakness throughout GIS in general, not only GRASS. The fact that it is still normal to pull GIS output into drawing programs to make it acceptable is an embarrassment. However to generate professional output efficiently, both scripting and interactive controls are needed. Setting colours and themes and layers are obvious in a well designed config file and command combination (BTW I hate GMT with its multiple commands for every layer; so tedious), but layout and legend placement is more difficult, but labels absolutely require both a scripting capability to allow for automated label placement algorithms (eg simulated annealing) and then an interactive environment to catch what is lost and possibly allow for drawing program features like bezier curves and fitting text to curves. In addition, these labels must be defined in terms to the size of the printed document but linked to the underlying geography to allow for expansion or shifting of the underlying geographic region without having to start over. What is needed is a environment where the output is "What You See Is EXACTLY What You Get" not "WYSI sort of WYG". To me this means interactive display and editing of postscript; this AFAIK is not trivial. Thus it is clear that to answer the question of cartography, both more powerful CLI modules are needed as well as top notch GUI. In Michael's other reply which has just been posted as I write, he mentions the concept of using a plugin for Inkscape, etc to allow for this type of capability. I'm not sure it is the best solution but definitely a step in the right direction. There is a commercial application called Canvas which is in process of adding more and more geographic capabilities into a pretty nice drawing program. This is definitely much better than just about anything else out there for people who don't have 5 figures or more to spend on cartographic software. Now to the shell... Interesting idea. I've never used Matlab but I have some experience with R and I never use the GUI because it sucks (IMAO); it is easier to just code what I need. In fact, however I dislike the R language so I use RPy and only write the functions I needed to in R and script everything in Python. It is slower to run, but much quicker to code for me. The concept of providing an obvious link between the GUI and the CLI is a good one. GIS is by its nature visual, much more so than statistical analysis (IMHO) so I'm not sure that the Matlab or R paradigm is the right one. One of the things that I've discussed with Michael B. off list is the toolbox concept. The big problem with modern GUI software is menu hell; sprawling menus that go on and on and on. Anytime you want to do anything it takes forever to find where that thing was which you did last month.... Drawing programs have used the toolbox abstraction quite successfully and I think it is potentially very useful for GIS and GRASS. The current command listing is certainly a step in the right direction and I wonder about using a toolbox where users can choose the display to be either icons, icons and text, icons and command names, or just command names. In this way providing baby steps to users who have been ignoring the commands listed in the command window when the pointed and clicked. A proper GUI integrated with a nice CLI (I like the idea of a Python shell, but we need to allow for different shells such as bash, etc.) is in my mind a good vision for GRASS and I think the one we already working toward. T -- Trevor Wiens twiens@interbaun.com The significant problems that we face cannot be solved at the same level of thinking we were at when we created them. (Albert Einstein) From twiens at interbaun.com Fri Jun 9 08:16:07 2006 From: twiens at interbaun.com (Trevor Wiens) Date: Fri Jun 9 08:16:11 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: References: <17544.33815.619566.632663@cerise.gclements.plus.com> Message-ID: <20060609001607.41071ae9@localhost.localdomain> On Thu, 08 Jun 2006 13:50:19 -0700 Michael Barton wrote: > Does this mean that a scrolling tree widget, for example, that I coded in > wxPython (using my Mac as a development machine with the installation of > wxWidgets that comes with wxPython) might not work properly in Linux? Or > that it might not 'look' the same? > > I'm not trying to be overly picky, but trying to find out whether this is or > is not really an issue for a GUI that simply sits on top of GRASS. The web > page propaganda says code once and have it run on all, of course. > This is a long thread so I'm unsure which response to reply to. I picked this as it was near the bottom. It seems to me that out of this discussion wxPython seems to be standing out as general contender because of the weakness of pyGTK on the Mac at this time. If we don't want to be dependent on libglade would it be worth considering something like PythonCard? From what I can tell it has no special run time requirements and its use is not required, but it may speed certain aspects of the development cycle. Opinions? T -- Trevor Wiens twiens@interbaun.com The significant problems that we face cannot be solved at the same level of thinking we were at when we created them. (Albert Einstein) From cavallini at faunalia.it Fri Jun 9 08:17:15 2006 From: cavallini at faunalia.it (Paolo Cavallini) Date: Fri Jun 9 08:17:19 2006 Subject: [GRASS-dev] grass6.2? Message-ID: <4489126B.9080901@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all. The current cvs version has a number of very important improvements of the current stable (one for all: v.in.dxf). I believe it is important to let normal users have access to these features. I would therefore recommend designing a roadmap for a release in a reasonable time. 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 iD8DBQFEiRJq/NedwLUzIr4RAr+9AKCB0HOyLnfJUGGYYtjulv2DPdGQ6QCgg+fH QZyqztU4I4qHOFo92vTvN7Q= =EbuB -----END PGP SIGNATURE----- From david.p.finlayson at gmail.com Fri Jun 9 08:23:33 2006 From: david.p.finlayson at gmail.com (David Finlayson) Date: Fri Jun 9 08:23:36 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: <20060609001607.41071ae9@localhost.localdomain> References: <17544.33815.619566.632663@cerise.gclements.plus.com> <20060609001607.41071ae9@localhost.localdomain> Message-ID: I looked briefly at PythonCard (another layer on top of wxPython). It didn't look like a living project. Is it still maintained? On 6/8/06, Trevor Wiens wrote: > On Thu, 08 Jun 2006 13:50:19 -0700 > Michael Barton wrote: > > > Does this mean that a scrolling tree widget, for example, that I coded in > > wxPython (using my Mac as a development machine with the installation of > > wxWidgets that comes with wxPython) might not work properly in Linux? Or > > that it might not 'look' the same? > > > > I'm not trying to be overly picky, but trying to find out whether this is or > > is not really an issue for a GUI that simply sits on top of GRASS. The web > > page propaganda says code once and have it run on all, of course. > > > > This is a long thread so I'm unsure which response to reply to. I > picked this as it was near the bottom. > > It seems to me that out of this discussion wxPython seems to be > standing out as general contender because of the weakness of pyGTK on > the Mac at this time. If we don't want to be dependent on libglade would > it be worth considering something like PythonCard? From what I can tell > it has no special run time requirements and its use is not required, but > it may speed certain aspects of the development cycle. > > Opinions? > > T > -- > Trevor Wiens > twiens@interbaun.com > > The significant problems that we face cannot be solved at the same > level of thinking we were at when we created them. > (Albert Einstein) > -- David Finlayson From twiens at interbaun.com Fri Jun 9 08:39:23 2006 From: twiens at interbaun.com (Trevor Wiens) Date: Fri Jun 9 08:39:25 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: References: <17544.33815.619566.632663@cerise.gclements.plus.com> <20060609001607.41071ae9@localhost.localdomain> Message-ID: <20060609003923.4a6d97ec@localhost.localdomain> On Thu, 8 Jun 2006 23:23:33 -0700 "David Finlayson" wrote: > I looked briefly at PythonCard (another layer on top of wxPython). It > didn't look like a living project. Is it still maintained? > > The mailing list is still active and sourceforge reported stats indicate that it is active, so it probably is active. I don't really know from experience. I don't know if it is really any good, as I've not done anything more than browse through the demos. I raised the question as it may speed development, is available on all platforms (with an editor, etc) and doesn't appear to have any extra run-time requirements. Seems like a good idea, but I don't know if it is any good. According to Jachym, who tried a bit more with it than I have so far, he preferred Glade, but it seems that libglade may be a concern. T -- Trevor Wiens twiens@interbaun.com The significant problems that we face cannot be solved at the same level of thinking we were at when we created them. (Albert Einstein) From glynn at gclements.plus.com Fri Jun 9 08:39:50 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jun 9 08:41:14 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: References: <17544.33815.619566.632663@cerise.gclements.plus.com> Message-ID: <17545.6070.97866.394701@cerise.gclements.plus.com> Michael Barton wrote: > > wxPython uses wxWidgets, which uses the platform's native widgets. > > This provides a more native look-and-feel, but is harder to code for, > > as there tend to be subtle differences between the behaviour of > > similar widgets on different platforms. > > Does this mean that a scrolling tree widget, for example, that I coded in > wxPython (using my Mac as a development machine with the installation of > wxWidgets that comes with wxPython) might not work properly in Linux? Or > that it might not 'look' the same? Well, I wouldn't expect it to look the same; the whole point of using native widgets is that they look like other applications on the same platform, not like the same application on other platforms. So far as working "correctly" is concerned: If you only use "basic" functionality, then it will probably work on all platforms, although the widget will probably behave differently on different platforms, e.g. if you collapse then expand a node, whether the collapsed/expanded state of its children is remembered, etc. If you use more advanced functionality, you might have to to have the Python equivalent of "#ifdef LINUX" etc. Some functionality might only be available on certain platforms, e.g. whether you can sort a table by multiple keys, whether the user can re-order columns, etc. Generally speaking, the more complex the widget, the greater the differences between equivalent widgets on a particular platform. At one extreme are complex dialogs like file or colour selectors, followed by tree and table widgets. At the other extreme, labels and push-buttons tend to be fairly standard. -- Glynn Clements From glynn at gclements.plus.com Fri Jun 9 08:50:43 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jun 9 08:50:47 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: References: <20060607201803.GA32453@gdf-hannover.de> <20060609004745.0e31b819.hamish_nospam@yahoo.com> Message-ID: <17545.6723.962823.678975@cerise.gclements.plus.com> Joel Pitt wrote: > > Would pyGTK it need to have libglade on all platforms? > > Or just for development? > > If you design the GUI with glade then you need libglade at runtime. > pyGTK does not *need* libglade to be used, and I'm somewhat hesitant > about having libglade required across platforms. IMHO glade is great > for prototyping, but for clean and well designed code - especially > with regards to OO encapsulation of GUI elements - then writing the > GUI directly with pyGTK is best. I disagree. If you view Glade merely as a development tool, then it doesn't provide any advantage to the user over coding the GUI. However, I tend to view external UI descriptions such as Glade or UIL (the same thing, but for Motif) as user configuration files. If the user doesn't like the placement of buttons or menu items, or their shortcuts etc, they can just edit the UI description. Similarly, if they don't use certain features, they can just remove unnecessary widgets from the UI. -- Glynn Clements From hamish_nospam at yahoo.com Fri Jun 9 09:06:59 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Jun 9 09:07:13 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: <17544.34565.331515.143038@cerise.gclements.plus.com> References: <20060607201803.GA32453@gdf-hannover.de> <20060609004745.0e31b819.hamish_nospam@yahoo.com> <17544.34565.331515.143038@cerise.gclements.plus.com> Message-ID: <20060609190659.3772c350.hamish_nospam@yahoo.com> > Even from a command-line perspective, the existing display > architecture is deficient in that you can't modify the layer stack > other than adding a new layer on the top or clearing the stack > altogether. d.save remove= Hamish From hamish_nospam at yahoo.com Fri Jun 9 09:13:17 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Jun 9 09:13:26 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: <6278879c0606082124g6c0571f6o61ce43217f0f580f@mail.gmail.com> References: <20060607201803.GA32453@gdf-hannover.de> <20060609004745.0e31b819.hamish_nospam@yahoo.com> <17544.34565.331515.143038@cerise.gclements.plus.com> <6278879c0606082124g6c0571f6o61ce43217f0f580f@mail.gmail.com> Message-ID: <20060609191317.26758efc.hamish_nospam@yahoo.com> > Each time we finish a GRASS GIS lab session (3-4 hours), i run the > script of the whole lab in 1-2 minutes in front of the students, you > should see their reaction! > > Such "assisted" scripting capability would be a serious advantage for > fastening the learning curve to advanced level processing. Aggreed, > not all processing can be done scripting-side, but surely a lot can be > done. Besides, GRASS GIS is changing fast, having a way to list & > pick-up commands can really help out here. I got to know the GRASS modules by cutting and pasting the command line versions from the old GRASS 5 GUI menus into a text editor diary. At some point I needed to loop some things for 365 days, figured out how to do this in Bash, and then nice things happened to my productivity levels. We can do this now with d.m and gis.m (some quoting required) in GRASS 6. Hamish From hamish_nospam at yahoo.com Fri Jun 9 09:20:37 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Jun 9 09:20:50 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: <20060609001607.41071ae9@localhost.localdomain> References: <17544.33815.619566.632663@cerise.gclements.plus.com> <20060609001607.41071ae9@localhost.localdomain> Message-ID: <20060609192037.4c1eaf46.hamish_nospam@yahoo.com> Trevor Wiens wrote: > It seems to me that out of this discussion wxPython seems to be > standing out as general contender because of the weakness of pyGTK on > the Mac at this time. The *perceived* weakness of [py]GTK on the Mac at this time. Maybe their TODO lags behind their CVS? (like here) We need to try "Hello, world" in multiple ways or better v.pydigit etc on the different platforms so we can talk about real data instead of just continuing speculation. Hamish From hamish_nospam at yahoo.com Fri Jun 9 09:29:56 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Jun 9 09:36:31 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: References: <20060608211013.GA9851@gdf-hannover.de> Message-ID: <20060609192956.400cf843.hamish_nospam@yahoo.com> Michael Barton wrote: > The screenshots of v.pydigit look great. I just downloaded and tried > to run v.pydigit--just to see what happened. > > It failed, saying I needed pygtk (I've got Python 2.4+ installed). > > I went to the pyGTK website. There does not seem to be a pyGTK binary > for Mac OSX, although there is one for Windows. I dug around a bit, it > seems that compiling it on the Mac is somewhat tricky. It looks like > it could be available from Darwinports. I haven't used this (except > for a brief tryout) because it messes with some of my system settings, > making it difficult for me to run other x11 programs. Maybe Fink has > it, but I haven't checked yet. > > This makes me hearken back to the days of GRASS 5.0.1, when I had to > search around for a proper version of TclTk to run it. This isn't very > attractive to go through this just to be able to develop and run the > package--especially given I'd need to put it on my laptop too. But the key change for you was not GRASS 6, but Lorenzo's packages? The dependent libs would come with or be built into the app. No problem for users, just like installing libgdal is no problem with the Mac binaries, it just works. Fink has it: http://pdb.finkproject.org/pdb/search.php?summary=pygtk So it is possible. But Mac users don't need Fink and hardly even know they need it, if it comes in the "grasslibs" binary package. I haven't seen an answer yet: is libglade needed at run time or just for developers? Hamish From hamish_nospam at yahoo.com Fri Jun 9 10:13:34 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Jun 9 10:14:07 2006 Subject: [GRASS-dev] Re: grass-dev Digest, Vol 2, Issue 19 In-Reply-To: References: Message-ID: <20060609201334.00c7a939.hamish_nospam@yahoo.com> David Finlayson wrote: > As far as I am concerned, there are more pressing issues for GRASS > than the GUI. 1) Get NVIZ working* on Fedora Core 5 then release GRASS 6.1.0 as a development snapshot. 2) see (1). [*] Figure out if it is a 64bit problem, a dreaded TclTk 8.4+threading error, TclTk 8.5 newness, or something that happened with the Togl 1.7 update. Reported by Helena: >> nviz gives me: >> >> GRASS 6.1.cvs (jockeystft):/bigdata/lindata > nviz el01.z4 >> Loading Data >> Loading Data >> translating colors from fp >> X Error of failed request: GLXBadContext >> Major opcode of failed request: 143 (GLX) >> Minor opcode of failed request: 5 (X_GLXMakeCurrent) >> Serial number of failed request: 201 >> Current serial number in output stream: 201 and same by Jaime Carrera: http://article.gmane.org/gmane.comp.gis.grass.user/13687 thanks, Hamish From wollez at gmx.net Fri Jun 9 09:49:50 2006 From: wollez at gmx.net (Wolfgang) Date: Fri Jun 9 10:30:37 2006 Subject: [GRASS-dev] A portible shell for GRASS 7+ ? In-Reply-To: References: Message-ID: Hi all, I'm not an developer but a user of grass and I'm working on grass for cygwin and I would prefer to get rid of cygwin, because I only need it to run grass. But I don't think the windows command line is extendable in a way that it is fully compatible with bash (even if all packages from gnuwin32 (gnuwin32.sf.net) are installed). So I would like to have an alternative shell for grass. Cheers Wolfgang David Finlayson schrieb: > Wolf, Joel: > > ... > > OK, in retrospect proposing a new shell for GRASS 7 was provocative. I > don't want that kind pressure for a hobby project. Consider this a > proposal for an optional download. > > Besides, you're preaching to the choir...search the mailing lists for > my name and command line and you will find at least several rants of > my own on this topic. I need full scripting capability for GRASS and > access to Unix and custom programs I have written for my projects. I > would never compromise that. > > So, why am I proposing a Python shell for GRASS? > > 1. I am intrigued by the possibility of making a Matlab of GIS. GRASS > is the perfect candidate for this. Python and the IPython interpreter > have all the tools needed to make a higher-level shell. Think of this > as the exact compliment to Qgis. Where Qgis wants to make a GIS with > lowest possible barrier to entry, I want to make a GIS with the > highest possible productivity for intermediate to advanced users: > > * Imagine having a command line that auto completes options, layers, > raster and vector names! > > * How about a display monitor that could be controlled by the command > line or the GUI at the same time (a la Matlabs graphics figures)? > > * How about having complete access to the GRASS API via Python SWIG? > > * All in the same shell? > > Bottom line though is that if I want some creative control over how > the GRASS CLI evolves, I need to shut up and code. > > 2. Windows GRASS needs this badly. The DOS shell is OK for some things > but Windows comes with no tools for working with text, or databases, > etc., etc., etc. Python provides a lot of power through its libraries > and it is very easy to extend. Using IPython as a shell would really > improve the tool set of native GRASS on Windows with no need for > emulating a Unix environment. > > 3. I think a lot of GUI-only people would consider the command line if > it was a little easier to learn and use. A GRASS IDE (if you will), > might be really cool. It might be powerful, too. From hamish_nospam at yahoo.com Fri Jun 9 11:33:14 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Jun 9 11:33:21 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: References: <20060607201803.GA32453@gdf-hannover.de> <20060609004745.0e31b819.hamish_nospam@yahoo.com> Message-ID: <20060609213314.3ff20f9c.hamish_nospam@yahoo.com> This flew by just now on DebianGIS concerning WxWidgets and Thuban: http://thread.gmane.org/gmane.comp.gis.grass.pkg.general/1969 (C++ linking problems with unmatching wxproj version) Joel Pitt wrote: > [libglade is required at run-time] ok, thanks. (no show stopper, but nice to know) > On the other hand, we could always use Java for the GUI... > (although in seriousness there is SWT http://www.eclipse.org/swt/ , > which binds Java to the native GUI libraries - and runs quickly > because it uses the actual libraries, not JAVA interpretations) It was reported yesterday on the DebianGIS mailing list that OpenJUMP now runs with classpath (free java clone) and is almost ready for Debian main. see http://kennke.org/blog/ > Perhaps we could create a GUI that allowed you to have multiple shells > open, R for GRASS, a bash shell, an IPython one. > > Come to think of it there isn't any reason why these shells can't > exist on their own... bash$ python Python 2.3.5 (#2, Sep 4 2005, 22:01:42) Type "help", "copyright", "credits" or "license" for more information. >>> _ voila! have fun. GRASS> R R : Copyright 2005, The R Foundation for Statistical Computing Version 2.1.0 (2005-04-18), ISBN 3-900051-07-0 .. Type 'q()' to quit R. > _ voila! have fun. IPython maybe more, but if it lets you run arbitrary system commands, that's all that GRASS commands are. David Finlayson wrote: > I am intrigued by the possibility of making a Matlab of GIS. I was thinking yesterday how close the two were at a base level. Little scriptable modules, which a GUI call call or modify an object property if you want, but at the base it returns to a solid modular CLI. > * Imagine having a command line that auto completes options, layers, > raster and vector names! Live the dream: http://grass.gdf-hannover.de/wiki/GRASS_AddOns#General_add-ons > * How about a display monitor that could be controlled by the command > line or the GUI at the same time (a la Matlabs graphics figures)? Glynn just mentioned this is a target. > * How about having complete access to the GRASS API via Python SWIG? This is well on its way.. Hamish From hamish_nospam at yahoo.com Fri Jun 9 11:33:16 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Jun 9 11:34:36 2006 Subject: [GRASS-dev] ps.map catrography [was Re: grass-dev Digest, Vol 2, Issue 19] In-Reply-To: References: Message-ID: <20060609213316.5e952a90.hamish_nospam@yahoo.com> David Finlayson wrote: > #2. is a complete face-lift to the map production capabilities of > #GRASS. > > I recently designed several large-format maps for a public display of > our mapping capabilities (coastal USGS). I found that I didn't have > the control or flexibility I needed in GRASS to do the maps the way I > wanted. ps.map just isn't very powerful yet. eh? how so? I have resorted to custom modifications to the C code and editing the .ps file in vi from time to time, but where does it lack power? (I take it you mean features, not control) David: > I regressed to ArcGIS/Illustrator for the first time in over a year :( > > I think it was possible, just too difficult to script the rgb > his > transformations in the short time I had available. Also the map > decorations I needed just weren't available in GRASS. File a wish or two. Maybe something is low hanging fruit. What map decorations did you want? Could be inserted as .eps? (.ttf->.eps?) as display icons? Michael Barton wrote: > The main way to do nice output has been to dump GRASS display to a > graphics file and work on it in that. This is not such a bad model, > given that very nice graphics layout and high-quality decorations > requires quite a bit of programming to achieve. So it's not that bad > an idea to leave it to InkScape or similar program to do that. To repeat myself: the d.* commands are good for presentation and web graphics. For the printed page ps.map shines. A common UI for both end systems would be nice. Michael: > Improvements to the first method are not closely tied to the GUI, but > require more enhancements to ps.map All are encouraged to file ps.map wishes as needed.. Michael: > rewrite the GRASS decoration display modules into TclTk (all were > written to render in what is now considered a low-resolution display). > If we are switching to a new GUI platform, I'd rather put the effort > into doing nice display decorations in the new platform. d.graph is now in good shape. It can take either map or display coordinates to draw; rotate & change the width of text; display all symbols, etc etc. The gui can just write a command file and let d.graph take care of the rest. The analogue is g-ps.map by Jachym Cepicky (or equivalent) http://les-ejk.cz/?cat=gpsmap There is no reason that a module like this couldn't create a ps.map template or a d.graph template depending on a radio button. Same as a *.digit program should be able to make a v.in.ascii or r.in.poly format command file depending on the user's choice. Trevor Wiens wrote: > Cartography is a weakness throughout GIS in general, not only GRASS. > The fact that it is still normal to pull GIS output into drawing > programs to make it acceptable is an embarrassment. However to > generate professional output efficiently, both scripting and > interactive controls are needed. I agree. Exactitude is key for publication quality stuff. A GUI is great for setup but you'll need to hack the resulting LaTEX / XML / ps.map file to get it "just right". Trevor: > but labels absolutely require both a > scripting capability to allow for automated label placement algorithms > (eg simulated annealing) and then an interactive environment to catch > what is lost and possibly allow for drawing program features like > bezier curves and fitting text to curves. In addition, these labels > must be defined in terms to the size of the printed document but > linked to the underlying geography to allow for expansion or shifting > of the underlying geographic region without having to start over. What > is needed is a environment where the output is "What You See Is > EXACTLY What You Get" not "WYSI sort of WYG". To me this means > interactive display and editing of postscript; this AFAIK is not > trivial. Not trivial, but I think we already have all this mostly done! * auto-label extraction and placement by v.label * labels both rotated (-a) and curved (-c) to vector lines: v.label * text sized by pt size or by map scale: ps.map's text "size" or "fontsize", same options in v.label As LyX puts it: "WYSIWYW" (What you see is what you want) Hamish From hamish_nospam at yahoo.com Fri Jun 9 11:38:25 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Jun 9 11:38:39 2006 Subject: [GRASS-dev] grass6.2? In-Reply-To: <4489126B.9080901@faunalia.it> References: <4489126B.9080901@faunalia.it> Message-ID: <20060609213825.02c15f46.hamish_nospam@yahoo.com> Paolo Cavallini wrote: > The current cvs version has a number of very important improvements of > the current stable (one for all: v.in.dxf). I believe it is important to > let normal users have access to these features. I would therefore > recommend designing a roadmap for a release in a reasonable time. see http://thread.gmane.org/gmane.comp.gis.grass.devel/11403/focus=11456 http://thread.gmane.org/gmane.comp.gis.grass.devel/12423/focus=12492 Hamish From hamish_nospam at yahoo.com Fri Jun 9 11:47:33 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Jun 9 11:48:36 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: References: <20060609004745.0e31b819.hamish_nospam@yahoo.com> Message-ID: <20060609214733.7ee57d12.hamish_nospam@yahoo.com> > Granted, a reason for switching from TclTk to another GUI platform is > that it gives us richer options for a GUI (we already have very rich > CLI options). But it seems better to begin to explore those by > improving on the design specs we now have, rather than starting from > scratch. And to be honest, if the idea of learning Python (I've > already started, given that it is summer and I can work it in around > writing and analysis) seems a little daunting, the idea of learning > Python, building a GUI, AND redesigning the GUI from the ground up > seems exhausting. If we can pick wxWidgets or pyGTK, then we can start with the frontends: py.digit (r.+v.), py.rectify (incl points, groups, v.trans, the new i.3 code, i.ortho?,..), py.profile, py.psmap, py.mapset, py.projection, py.startup ... After that & we are all better informed we can worry about replacing gis.m. --with-python can be optional until things are well ready. Managable small steps. Hamish From cavallini at faunalia.it Fri Jun 9 11:49:11 2006 From: cavallini at faunalia.it (Paolo Cavallini) Date: Fri Jun 9 11:49:19 2006 Subject: [GRASS-dev] grass6.2? In-Reply-To: <20060609213825.02c15f46.hamish_nospam@yahoo.com> References: <4489126B.9080901@faunalia.it> <20060609213825.02c15f46.hamish_nospam@yahoo.com> Message-ID: <200606091149.13094.cavallini@faunalia.it> Thanks Hamish. I' aware of the threads, but afterwards the discussion seemed to die out, so my question. Perhaps I missed the point, but I didn't see a clear roadmap coming out. All the best. pc At 11:38, venerd? 9 giugno 2006 you presumably wrote: > Paolo Cavallini wrote: > > The current cvs version has a number of very important improvements of > > the current stable (one for all: v.in.dxf). I believe it is important to > > let normal users have access to these features. I would therefore > > recommend designing a roadmap for a release in a reasonable time. > > see > http://thread.gmane.org/gmane.comp.gis.grass.devel/11403/focus=11456 > http://thread.gmane.org/gmane.comp.gis.grass.devel/12423/focus=12492 > > > > Hamish -- Paolo Cavallini email+jabber: cavallini@faunalia.it www.faunalia.it Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953 From jachym.cepicky at centrum.cz Fri Jun 9 12:09:47 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Fri Jun 9 12:10:45 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: <20060609214733.7ee57d12.hamish_nospam@yahoo.com> References: <20060609004745.0e31b819.hamish_nospam@yahoo.com> <20060609214733.7ee57d12.hamish_nospam@yahoo.com> Message-ID: <20060609100945.GA8684@gdf-hannover.de> Hallo, On Fri, Jun 09, 2006 at 09:47:33PM +1200, Hamish wrote: > If we can pick wxWidgets or pyGTK, then we can start with the frontends: > > py.digit (r.+v.), py.rectify (incl points, groups, v.trans, the new i.3 > code, i.ortho?,..), py.profile, py.psmap, py.mapset, py.projection, > py.startup ... After that & we are all better informed we can worry > about replacing gis.m. --with-python can be optional until things are > well ready. > > Managable small steps. > > Hamish all these tools do need one common thing: py.monitor. Currently v.pydigit, g-ps.map ... do have own drawingarea and I see, this is not the best approach. so I would suggest, working py.monitor should be the *first* step towards new gui. Than you can add toolbars and new functoins for digitizing/rectifing/... I have posted on http://les-ejk.cz/tmp/py.monitor.png my imagination (very draft) of how monitor such these could look like. It is assumed, that it would be able to "listen" to the console commands and add tham automaticly to stack of command under the map area. The way currently gis.m is doing things are IMHO good, I just would not add another window on the destop. What do you thing? 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/20060609/8ed6fb9b/attachment.bin From lrntct at gmail.com Fri Jun 9 12:31:26 2006 From: lrntct at gmail.com (Laurent C.) Date: Fri Jun 9 12:31:30 2006 Subject: [GRASS-dev] A portible shell for GRASS 7+ ? In-Reply-To: References: Message-ID: <787520ee0606090331r3b8642bcl8b65e048a751bde4@mail.gmail.com> 2006/6/9, Wolfgang : > > Hi all, > > I'm not an developer but a user of grass and I'm working on grass for > cygwin and I would prefer to get rid of cygwin, because I only need it > to run grass. But I don't think the windows command line is extendable > in a way that it is fully compatible with bash (even if all packages > from gnuwin32 (gnuwin32.sf.net) are installed). So I would like to have > an alternative shell for grass. > > Cheers > Wolfgang > Hello, Bash isn't in gnuwin32 packages, but it run natively under Windows. http://www.steve.org.uk/Software/bash/ Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060609/2685fab7/attachment.html From wollez at gmx.net Fri Jun 9 13:01:35 2006 From: wollez at gmx.net (Wolfgang Zillig) Date: Fri Jun 9 13:01:43 2006 Subject: [GRASS-dev] A portible shell for GRASS 7+ ? In-Reply-To: <787520ee0606090331r3b8642bcl8b65e048a751bde4@mail.gmail.com> References: <787520ee0606090331r3b8642bcl8b65e048a751bde4@mail.gmail.com> Message-ID: <4489550F.4080603@gmx.net> If I understand correctly, the only limit is the X-server to run Grass on native windows? Wolfgang Laurent C. schrieb: > 2006/6/9, Wolfgang >: > > Hi all, > > I'm not an developer but a user of grass and I'm working on grass for > cygwin and I would prefer to get rid of cygwin, because I only need it > to run grass. But I don't think the windows command line is > extendable > in a way that it is fully compatible with bash (even if all packages > from gnuwin32 (gnuwin32.sf.net ) are > installed). So I would like to have > an alternative shell for grass. > > Cheers > Wolfgang > > > Hello, > > Bash isn't in gnuwin32 packages, but it run natively under Windows. > http://www.steve.org.uk/Software/bash/ > > > Laurent From lrntct at gmail.com Fri Jun 9 14:14:25 2006 From: lrntct at gmail.com (Laurent C.) Date: Fri Jun 9 14:14:27 2006 Subject: [GRASS-dev] A portible shell for GRASS 7+ ? In-Reply-To: <4489550F.4080603@gmx.net> References: <787520ee0606090331r3b8642bcl8b65e048a751bde4@mail.gmail.com> <4489550F.4080603@gmx.net> Message-ID: <787520ee0606090514x2038a5bby4326dfb9cf46c7ed@mail.gmail.com> 2006/6/9, Wolfgang Zillig : > > If I understand correctly, the only limit is the X-server to run Grass > on native windows? > Wolfgang AFAIK, yes. That why a lot of work is made to remplace the actual tool which need X11, like v.digit and so on. For example, Radim made a qgis-grass binary for windows which work quite well. Laurent C. schrieb: > > 2006/6/9, Wolfgang >: > > > > Hi all, > > > > I'm not an developer but a user of grass and I'm working on grass > for > > cygwin and I would prefer to get rid of cygwin, because I only need > it > > to run grass. But I don't think the windows command line is > > extendable > > in a way that it is fully compatible with bash (even if all packages > > from gnuwin32 (gnuwin32.sf.net ) are > > installed). So I would like to have > > an alternative shell for grass. > > > > Cheers > > Wolfgang > > > > > > Hello, > > > > Bash isn't in gnuwin32 packages, but it run natively under Windows. > > http://www.steve.org.uk/Software/bash/ > > > > > > Laurent > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060609/9c0995d4/attachment-0001.html From grass-bugs at intevation.de Fri Jun 9 14:39:48 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Fri Jun 9 14:39:50 2006 Subject: [GRASS-dev] [bug #4563] (grass) g.version should show finer precision timestamp other than just year Message-ID: <20060609123948.F3ABF1006AA@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4563 ------------------------------------------------------------------------- Subject: g.version should show finer precision timestamp other than just year 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-06-09 Would it be possible for g.version to show more detailed information about /when/ the Grass version was compiled? This would be very useful for example on machines where multiple Grass cvs versions are installed, and the user is unsure of what particular cvs brand they are working with. In this respect, g.version reporting "Grass 6.1 cvs (2006)" isn't really telling the user a whole lot. ~ Eric. -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Fri Jun 9 14:47:57 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Fri Jun 9 14:47:59 2006 Subject: [GRASS-dev] [bug #4564] (grass) v.in.ogr w/ large datasets Message-ID: <20060609124757.651E91006A4@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4564 ------------------------------------------------------------------------- Subject: v.in.ogr w/ large datasets Dear GRASSers, we have problems importing a large dataset (~300.000 features) with v.in.ogr. It eats up all mem and dies without importing. We have tried using with -c (no clean) in order to reduce the mem consumption, but without luck. At least this thread seems to be realated to our problem. http://grass.itc.it/pipermail/grass-dev/2006-May/023088.html Some links to similar problems discussed on the mailinglist: http://grass.itc.it/pipermail/grass-dev/2006-May/022917.html Radim wrote something about it, but did not elaborate where to start solving this problem. Best regards Stephan -------------------------------------------- Managed by Request Tracker From holl at gdf-hannover.de Fri Jun 9 14:48:31 2006 From: holl at gdf-hannover.de (Stephan Holl) Date: Fri Jun 9 14:48:49 2006 Subject: [GRASS-dev] v.in.ogr eats all memory In-Reply-To: <17517.57935.247355.100716@cerise.gclements.plus.com> References: <20060518162918.GB4663@bartok.itc.it> <20060519172015.2dff278d.hamish_nospam@yahoo.com> <17517.57935.247355.100716@cerise.gclements.plus.com> Message-ID: <20060609144831.36726c32@butan.gdf-hannover.de> Hello developers, On Fri, 19 May 2006 16:20:47 +0100 Glynn Clements wrote: > > Hamish wrote: > > > > Question: Can we add some test to avoid that more > > > than xx percent of the memory are used? There won't > > > be any hot plugin of extra RAM, so v.in.ogr should > > > exit with memory allocation error. > > > > attempt G_malloc(),G_free() of estimated size before processing. > > That won't necessarily help. > > The underlying brk/sbrk (or mmap(MAP_ANONYMOUS)) call will succeed so > long as there is sufficient virtual memory and you don't exceed any > usage limits which are in force. > > That doesn't mean that reading/writing the allocated memory won't > cause the system to go into a swapping frenzy. > > > Back in > > the mailing list archives somewhere I figured out the current bytes > > per vector point needed (with valgrind) and suggested this? > > > > I don't know how to query available memory in a cross platform way. > > The "free" command will give you some global memory statistics. > However, that information is practically meaningless to an > application, as there is no way to figure out how much of that memory > you can reasonably expect to use. > > On a lightly-loaded system, the application can expect to be able to > use all of the memory which is currently being used by the buffer > cache (which is usually most of the total memory). On a heavily-loaded > system, it may only be able to use a small fraction of it. > To keep this problem in mind I have added a bug in bugtracker[1] so that we do not forget it. If anybody feels responsible to fix this anoying problem, please go ahead :-) It seems that building topology needs lot of memory though. Best regards Stephan [1] https://intevation.de/rt/webrt?display=History&serial_num=4564 -- 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 hmitaso at unity.ncsu.edu Fri Jun 9 15:55:23 2006 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Fri Jun 9 15:55:40 2006 Subject: [GRASS-dev] grass6.2? In-Reply-To: <200606091149.13094.cavallini@faunalia.it> References: <4489126B.9080901@faunalia.it> <20060609213825.02c15f46.hamish_nospam@yahoo.com> <200606091149.13094.cavallini@faunalia.it> Message-ID: <6A30DF58-8AD1-44AF-8F6E-565566CF7FD7@unity.ncsu.edu> we need a freeze to get the release done, too many changes are happening at this time and we need somebody to declare the freeze - Markus is traveling so we are somewhat lacking a leadership - this is one situation when having a steering committee would be helpful - the committee could meet on IRC, declare an official freeze and we don't get this die-out discussions, Helena Helena Mitasova Dept. of Marine, Earth and Atm. Sciences 1125 Jordan Hall, NCSU Box 8208, Raleigh NC 27695 http://skagit.meas.ncsu.edu/~helena/ On Jun 9, 2006, at 5:49 AM, Paolo Cavallini wrote: > Thanks Hamish. > I' aware of the threads, but afterwards the discussion seemed to > die out, so > my question. > Perhaps I missed the point, but I didn't see a clear roadmap coming > out. > All the best. > pc > > At 11:38, venerd? 9 giugno 2006 you presumably wrote: >> Paolo Cavallini wrote: >>> The current cvs version has a number of very important >>> improvements of >>> the current stable (one for all: v.in.dxf). I believe it is >>> important to >>> let normal users have access to these features. I would therefore >>> recommend designing a roadmap for a release in a reasonable time. >> >> see >> http://thread.gmane.org/gmane.comp.gis.grass.devel/11403/focus=11456 >> http://thread.gmane.org/gmane.comp.gis.grass.devel/12423/focus=12492 >> >> >> >> Hamish > > -- > Paolo Cavallini > email+jabber: cavallini@faunalia.it > www.faunalia.it > Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39) > 348-3801953 > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From jachym.cepicky at centrum.cz Fri Jun 9 18:07:25 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Fri Jun 9 18:08:22 2006 Subject: [GRASS-dev] v.pydigit 06-06-09 Message-ID: <20060609160724.GA12363@gdf-hannover.de> Hallo, while discussing about the new gui, I'm still working on v.pydigit. I hope, I will be later able to help more with the new gui, if I'll have clear imagination, what the problems could be and how the things can be done. I also hope, that at least some functions can be recycled later in the new gui. Today's version is able to change attributes to vector objects - * click on the feature, * right click * select "Edit attributes" in the menu * edit your attributes * store I removed the support for "later storing" - it made the code too complicated and I actually do not see any positive thing. It should work just like d.what.vect -e works See http://les-ejk.cz/?cat=vpydigit 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/20060609/c391c566/attachment.bin From michael.barton at asu.edu Fri Jun 9 17:14:09 2006 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jun 9 18:13:49 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: <20060609214733.7ee57d12.hamish_nospam@yahoo.com> Message-ID: I agree. Let's see if we can port what we've got now and see how current problems can be fixed. I'm not in the least opposed to reopening the UI design discussion. This would be very healthy and productive. I just think we need to focus on one enormous step at a time. And switching GUI platforms after 15 years is pretty big. My hope is to maintain the more or less unidirected, organized chaos that has been so productive over the past year. 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, 9 Jun 2006 21:47:33 +1200 > To: Michael Barton > Cc: > Subject: Re: [GRASS-dev] Python GUI toolkits > > > If we can pick wxWidgets or pyGTK, then we can start with the frontends: > > py.digit (r.+v.), py.rectify (incl points, groups, v.trans, the new i.3 > code, i.ortho?,..), py.profile, py.psmap, py.mapset, py.projection, > py.startup ... After that & we are all better informed we can worry > about replacing gis.m. --with-python can be optional until things are > well ready. > > Managable small steps. > From michael.barton at asu.edu Fri Jun 9 17:15:04 2006 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jun 9 18:13:54 2006 Subject: [GRASS-dev] Re: grass-dev Digest, Vol 2, Issue 19 In-Reply-To: <20060609201334.00c7a939.hamish_nospam@yahoo.com> Message-ID: And working without x11. 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, 9 Jun 2006 20:13:34 +1200 > To: David Finlayson > Cc: , , Jaime Carrera > , > Subject: Re: [GRASS-dev] Re: grass-dev Digest, Vol 2, Issue 19 > > > 1) Get NVIZ working* on Fedora Core 5 then release GRASS 6.1.0 as a > development snapshot. > > 2) see (1). > From michael.barton at asu.edu Fri Jun 9 18:43:20 2006 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jun 9 18:43:37 2006 Subject: [GRASS-dev] A portible shell for GRASS 7+ ? In-Reply-To: <787520ee0606090514x2038a5bby4326dfb9cf46c7ed@mail.gmail.com> Message-ID: I?ve run the current GIS Manager in Aqua TclTk with the bash terminal and no x11 using Lorenzo?s binaries. It runs fine as long as you don?t start something that requires x11 (e.g. i.points, v.digit, d.profile, nviz). The new georectifier and profiler work without x11, and so should work fine. If someone could compile the existing Windows native code with the d.modules and gis.m intact, and start it up using native Windows wish it should run theoretically. But I don?t know how to do this and so can?t test it. It would be good to know if our efforts in this direction are helpful, though. 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: "Laurent C." Date: Fri, 9 Jun 2006 14:14:25 +0200 To: Wolfgang Zillig Cc: grass-devel Subject: Re: [GRASS-dev] A portible shell for GRASS 7+ ? 2006/6/9, Wolfgang Zillig : > If I understand correctly, the only limit is the X-server to run Grass > on native windows? > Wolfgang AFAIK, yes. That why a lot of work is made to remplace the actual tool which need X11, like v.digit and so on. For example, Radim made a qgis-grass binary for windows which work quite well. > Laurent C. schrieb: >> > 2006/6/9, Wolfgang >: >> > >> > Hi all, >> > >> > I'm not an developer but a user of grass and I'm working on grass for >> > cygwin and I would prefer to get rid of cygwin, because I only need it >> > to run grass. But I don't think the windows command line is >> > extendable >> > in a way that it is fully compatible with bash (even if all packages >> > from gnuwin32 (gnuwin32.sf.net >> ) are >> > installed). So I would like to have >> > an alternative shell for grass. >> > >> > Cheers >> > Wolfgang >> > >> > >> > Hello, >> > >> > Bash isn't in gnuwin32 packages, but it run natively under Windows. >> > http://www.steve.org.uk/Software/bash/ >> > >> > >> > Laurent > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060609/2fde08a3/attachment-0001.html From michael.barton at asu.edu Fri Jun 9 18:48:36 2006 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jun 9 18:49:01 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: <20060609100945.GA8684@gdf-hannover.de> Message-ID: I agree. This is a critical test. I've been trying to think about how to do this in wxPython--though I still don't know enough yet. I'll try to get a fink version of pygtk in the next week and see if I can test v.pydigit. I've also gone through the first part of a wxPython tutorial and built the example control window. If anyone would like to test it on another system, I can send it to them or post it. We need to get the current GRASS 6.2 out the door. Then I can devote more time to learning something completely new. The georectifier is almost done. Just need RMS and v.transform group options if someone is able to do these. Has anyone else played with it yet? 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: Jachym Cepicky > Date: Fri, 9 Jun 2006 12:09:47 +0200 > To: Hamish > Cc: Michael Barton , > Subject: Re: [GRASS-dev] Python GUI toolkits > > I have posted on http://les-ejk.cz/tmp/py.monitor.png my imagination > (very draft) of how monitor such these could look like. It is assumed, > that it would be able to "listen" to the console commands and add tham > automaticly to stack of command under the map area. The way currently > gis.m is doing things are IMHO good, I just would not add another window > on the destop. > > What do you thing? From michael.barton at asu.edu Fri Jun 9 19:02:01 2006 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jun 9 19:02:13 2006 Subject: [GRASS-dev] grass6.2? In-Reply-To: <6A30DF58-8AD1-44AF-8F6E-565566CF7FD7@unity.ncsu.edu> Message-ID: Agreed. When is Markus back? We're *so* close to getting an x11-less GRASS, it would be nice to do this for 6.2. This offers possibilities to run GRASS natively on Windows, as well as making it more consistently useable overall. To accomplish that, here is what remains to be done. georectifier: C script for RMS error, updates to v.transform so that it can read or ignore a 5th column (use gcp) in a points file, creation of v.group (if everyone thinks this is a good idea). The last two are for consistency, but not required for functionality. I have everything running as is now except for RMS. nviz: Glynn has already noted what probably needs to be done. It sounds minimal from the perspective of someone who doesn't know C. v.digit: I don't think this will get done. Jachym's efforts have been directed towards pyGTK. This is nice for the future, but doesn't help for 6.2. Unless someone jumps into the breach soon, we should just accept that you will need x11 (or QGIS) for digitizing for now. d.path and wildfire modeliing: I wouldn't worry about for 6.2 I'm not sure what else needs to be done for the rest of the program. It seems like we are ready for a feature freeze otherwise. 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: Helena Mitasova > Date: Fri, 9 Jun 2006 09:55:23 -0400 > To: > Cc: > Subject: Re: [GRASS-dev] grass6.2? > > we need a freeze to get the release done, too many changes are > happening at this time > and we need somebody to declare the freeze - > Markus is traveling so we are somewhat lacking a leadership - this is > one situation > when having a steering committee would be helpful - the committee > could meet on IRC, declare an > official freeze and we don't get this die-out discussions, > > Helena > > Helena Mitasova > Dept. of Marine, Earth and Atm. Sciences > 1125 Jordan Hall, NCSU Box 8208, > Raleigh NC 27695 > http://skagit.meas.ncsu.edu/~helena/ > > > > On Jun 9, 2006, at 5:49 AM, Paolo Cavallini wrote: > >> Thanks Hamish. >> I' aware of the threads, but afterwards the discussion seemed to >> die out, so >> my question. >> Perhaps I missed the point, but I didn't see a clear roadmap coming >> out. >> All the best. >> pc >> >> At 11:38, venerd? 9 giugno 2006 you presumably wrote: >>> Paolo Cavallini wrote: >>>> The current cvs version has a number of very important >>>> improvements of >>>> the current stable (one for all: v.in.dxf). I believe it is >>>> important to >>>> let normal users have access to these features. I would therefore >>>> recommend designing a roadmap for a release in a reasonable time. >>> >>> see >>> http://thread.gmane.org/gmane.comp.gis.grass.devel/11403/focus=11456 >>> http://thread.gmane.org/gmane.comp.gis.grass.devel/12423/focus=12492 >>> >>> >>> >>> Hamish >> >> -- >> Paolo Cavallini >> email+jabber: cavallini@faunalia.it >> www.faunalia.it >> Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39) >> 348-3801953 >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev > > > From epatton at nrcan.gc.ca Fri Jun 9 20:03:58 2006 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Fri Jun 9 20:04:05 2006 Subject: [GRASS-dev] Proper formatting of input parameters for bash scripts Message-ID: <0E5A77B55A57D511BB3F0002A537C262064111BE@s5-dar-r1.nrn.nrcan.gc.ca> I'm trying to write a script that accepts either a delimited list for input (like g.region rast=map1,map2,map3,...) or will interpret the given input as a wildcard pattern if the appropriate flag is given also. What is the syntax required when writing in bash to enable this functionality? The script I'm writing uses r.patch in loop if a wildcard pattern is given, otherwise it should accept single or multiple-delimited lists of input rasters by default. Thanks, ~ Eric. From kwythers at umn.edu Fri Jun 9 20:32:15 2006 From: kwythers at umn.edu (Kirk R. Wythers) Date: Fri Jun 9 20:32:20 2006 Subject: [GRASS-dev] another v.in.ogr question In-Reply-To: <20060609144831.36726c32@butan.gdf-hannover.de> References: <20060518162918.GB4663@bartok.itc.it> <20060519172015.2dff278d.hamish_nospam@yahoo.com> <17517.57935.247355.100716@cerise.gclements.plus.com> <20060609144831.36726c32@butan.gdf-hannover.de> Message-ID: <8B5B85AE-1270-492F-9F3E-5B7957299249@umn.edu> Is it possible to read multiple tables from postgis (postgresql) into grass with v.in.ogr? I seem to be able to only read in the table that contains the geometry data. I tried creating a postgresql view that contains all the columns (from multiple tables) that I need, however, v.in.ogr does not seem to see the view. Thanks, From twiens at interbaun.com Fri Jun 9 21:12:33 2006 From: twiens at interbaun.com (twiens) Date: Fri Jun 9 21:12:37 2006 Subject: [GRASS-dev] Python GUI toolkits Message-ID: <4489c821.159.4858.13524@interbaun.com> ----- Original Message Follows ----- From: Hamish To: Trevor Wiens Cc: grass-dev@grass.itc.it Subject: Re: [GRASS-dev] Python GUI toolkits Date: Fri, 9 Jun 2006 19:20:37 +1200 > Trevor Wiens wrote: > > It seems to me that out of this discussion wxPython > > seems to be standing out as general contender because of > > the weakness of pyGTK on the Mac at this time. > > The *perceived* weakness of [py]GTK on the Mac at this > time. > > Maybe their TODO lags behind their CVS? (like here) > > We need to try "Hello, world" in multiple ways or better > v.pydigit etc on the different platforms so we can talk > about real data instead of just continuing speculation. > Right. I could see if I can get v.pydigit to run on my wife's iMac. I'll look into it over the weekend as I have time. T -- Trevor Wiens From glynn at gclements.plus.com Fri Jun 9 22:28:22 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jun 9 22:32:30 2006 Subject: [GRASS-dev] A portible shell for GRASS 7+ ? In-Reply-To: References: <787520ee0606090514x2038a5bby4326dfb9cf46c7ed@mail.gmail.com> Message-ID: <17545.55782.941172.48309@cerise.gclements.plus.com> Michael Barton wrote: > If someone could compile the existing Windows native code with the d.modules > and gis.m intact, and start it up using native Windows wish it should run > theoretically. But I don?t know how to do this and so can?t test it. It > would be good to know if our efforts in this direction are helpful, though. I can get most of GRASS to compile on Windows without Cygwin (this relies upon the not-yet-committed changes to libraster to allow driver-less rendering). However, there appear to be some fundamental problems with the MSVC run-time, e.g. fseek() doesn't work on files opened for update ("wb+"), so I wouldn't expect it to run. FWIW, the portions which fail to compile are: lib/fonts/for_grass lib/vector/diglib Both due to fseek() issues. display/d.colors raster/r.le/r.le.trace Undefined reference to sleep() display/d.mon/pgms Undefined reference to ttyname() vector/v.digit Undefined reference to gettimeofday() imagery/i.ortho.photo/photo.2image imagery/i.ortho.photo/photo.2target imagery/i.points imagery/i.vpoints Missing imagery/i.class Undefined SIGTSTP imagery/i.ortho.photo/photo.rectify imagery/i.rectify Both define a symbol "compress" which conflicts with zlib. display/d.paint.labels raster/r.support/modcats raster/r.support/modcolr raster/r.support/modhist raster/r.support/modhead Attempting to use ln/mv on files which don't exist (need to add the .exe suffix). This is with only mandatory external dependencies; no Tcl/Tk, PNG, TIFF, OpenGL etc. -- Glynn Clements From glynn at gclements.plus.com Fri Jun 9 22:32:51 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jun 9 22:34:06 2006 Subject: [GRASS-dev] grass6.2? In-Reply-To: References: <6A30DF58-8AD1-44AF-8F6E-565566CF7FD7@unity.ncsu.edu> Message-ID: <17545.56051.80953.220406@cerise.gclements.plus.com> Michael Barton wrote: > We're *so* close to getting an x11-less GRASS, it would be nice to do this > for 6.2. This offers possibilities to run GRASS natively on Windows, as well > as making it more consistently useable overall. To accomplish that, here is > what remains to be done. So, should I commit the changes to libraster to allow driver-less rendering? -- Glynn Clements From JGillette at rfmd.com Fri Jun 9 23:22:29 2006 From: JGillette at rfmd.com (John Gillette) Date: Fri Jun 9 23:22:58 2006 Subject: [GRASS-dev] GTK on MAC Message-ID: Trevor, Michael and others [concerning GTK on MAC], I don't know anything about this but did some searching as I am interested in seeing the GTK approach work. I ran across an article talking up the possibility of developing GTK applications on the MAC with a link to a tutorial on how to do this on the MAC. Please look at this and see if it helps at all with what is needed. The need for GPL Free Apps on Mac OS X: http://osnews.com/story.php?news_id=10867 reference in article is steps to set up GTK on MAC: http://gimp-app.sourceforge.net/gimp.app.howto.txt I hope this helps. John From joel.pitt at gmail.com Sat Jun 10 00:50:29 2006 From: joel.pitt at gmail.com (Joel Pitt) Date: Sat Jun 10 00:50:35 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: <17545.6723.962823.678975@cerise.gclements.plus.com> References: <20060607201803.GA32453@gdf-hannover.de> <20060609004745.0e31b819.hamish_nospam@yahoo.com> <17545.6723.962823.678975@cerise.gclements.plus.com> Message-ID: On 6/9/06, Glynn Clements wrote: > > Joel Pitt wrote: > > > Would pyGTK it need to have libglade on all platforms? > > > Or just for development? > > > > If you design the GUI with glade then you need libglade at runtime. > > pyGTK does not *need* libglade to be used, and I'm somewhat hesitant > > about having libglade required across platforms. IMHO glade is great > > for prototyping, but for clean and well designed code - especially > > with regards to OO encapsulation of GUI elements - then writing the > > GUI directly with pyGTK is best. > > I disagree. If you view Glade merely as a development tool, then it > doesn't provide any advantage to the user over coding the GUI. > > However, I tend to view external UI descriptions such as Glade or UIL > (the same thing, but for Motif) as user configuration files. If the > user doesn't like the placement of buttons or menu items, or their > shortcuts etc, they can just edit the UI description. Similarly, if > they don't use certain features, they can just remove unnecessary > widgets from the UI. Good point Glynn. Guess I spend too much time thinking from a developers perspective. If we use wxPython/wxGlade then it is worth noting that XRC files can be generated that perform a similar role to glade xml files: http://wxwidgets.org/manuals/2.6.3/wx_xrcoverview.html#xrcoverview -- -Joel "Wish not to seem, but to be, the best." -- Aeschylus From michael.barton at asu.edu Sat Jun 10 00:54:03 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sat Jun 10 00:54:11 2006 Subject: [GRASS-dev] A portible shell for GRASS 7+ ? In-Reply-To: <17545.55782.941172.48309@cerise.gclements.plus.com> Message-ID: Although this sounds grim, it actually may not be as bad as it seems. Most are x11 issues, and many have new TclTk equivalents. 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: Glynn Clements > Date: Fri, 9 Jun 2006 21:28:22 +0100 > To: Michael Barton > Cc: "Laurent C." , Wolfgang Zillig , > grass-devel > Subject: Re: [GRASS-dev] A portible shell for GRASS 7+ ? > > > Michael Barton wrote: > >> If someone could compile the existing Windows native code with the d.modules >> and gis.m intact, and start it up using native Windows wish it should run >> theoretically. But I don?t know how to do this and so can?t test it. It >> would be good to know if our efforts in this direction are helpful, though. > > I can get most of GRASS to compile on Windows without Cygwin (this > relies upon the not-yet-committed changes to libraster to allow > driver-less rendering). > > However, there appear to be some fundamental problems with the MSVC > run-time, e.g. fseek() doesn't work on files opened for update > ("wb+"), so I wouldn't expect it to run. > > FWIW, the portions which fail to compile are: > > lib/fonts/for_grass > lib/vector/diglib > > Both due to fseek() issues. These may be the most problematic > > display/d.colors > raster/r.le/r.le.trace > > Undefined reference to sleep() > Neither needed for most GIS work. d.colors requires x11 anyway and would not run without Cygwin > display/d.mon/pgms > > Undefined reference to ttyname() Don't know what this might do > > vector/v.digit > > Undefined reference to gettimeofday() Requires x11 and wouldn't run anyway without Cygwin > > imagery/i.ortho.photo/photo.2image > imagery/i.ortho.photo/photo.2target > imagery/i.points > imagery/i.vpoints > > Missing i.points and v.points require x11 and replaced by TclTk georectifier. Have to do without i.ortho.photo, but this is a specialized application. > > imagery/i.class > > Undefined SIGTSTP It would be nice if this worked. > > imagery/i.ortho.photo/photo.rectify > imagery/i.rectify i.rectify needs to work for the georectifier, but doesn't need to run in x11 interactive mode. > > Both define a symbol "compress" which conflicts with zlib. > > display/d.paint.labels > raster/r.support/modcats > raster/r.support/modcolr > raster/r.support/modhist > raster/r.support/modhead > > Attempting to use ln/mv on files which don't exist (need to add the > .exe suffix). d.paint.lables/d.labels replaced by TclTk equivalent in gis.m. Didn't work right in TclTk canvas anyway (at least on Mac) r.support would be nice but not critical > > This is with only mandatory external dependencies; no Tcl/Tk, PNG, > TIFF, OpenGL etc. > > -- > Glynn Clements From michael.barton at asu.edu Sat Jun 10 00:55:07 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sat Jun 10 00:55:11 2006 Subject: [GRASS-dev] grass6.2? In-Reply-To: <17545.56051.80953.220406@cerise.gclements.plus.com> Message-ID: Does this mean that I can change gis.m to render with out running d.mon? Anything I would have to know about setting environments to do this? Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Glynn Clements > Date: Fri, 9 Jun 2006 21:32:51 +0100 > To: Michael Barton > Cc: Helena Mitasova , , > > Subject: Re: [GRASS-dev] grass6.2? > > > Michael Barton wrote: > >> We're *so* close to getting an x11-less GRASS, it would be nice to do this >> for 6.2. This offers possibilities to run GRASS natively on Windows, as well >> as making it more consistently useable overall. To accomplish that, here is >> what remains to be done. > > So, should I commit the changes to libraster to allow driver-less > rendering? > > -- > Glynn Clements From michael.barton at asu.edu Sat Jun 10 00:58:08 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sat Jun 10 00:58:20 2006 Subject: [GRASS-dev] Proper formatting of input parameters for bash scripts In-Reply-To: <0E5A77B55A57D511BB3F0002A537C262064111BE@s5-dar-r1.nrn.nrcan.gc.ca> Message-ID: Doesn't the "multiple" argument do this automatically in the g_parser() system? 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: "Patton, Eric" > Date: Fri, 9 Jun 2006 15:03:58 -0300 > To: "'grass-dev@grass.itc.it'" > Subject: [GRASS-dev] Proper formatting of input parameters for bash scripts > > I'm trying to write a script that accepts either a delimited list for input > (like g.region rast=map1,map2,map3,...) or will interpret the given input as > a wildcard pattern if the appropriate flag is given also. What is the syntax > required when writing in bash to enable this functionality? The script I'm > writing uses r.patch in loop if a wildcard pattern is given, otherwise it > should accept single or multiple-delimited lists of input rasters by > default. > > Thanks, > > ~ Eric. > > From michael.barton at asu.edu Sat Jun 10 01:00:46 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sat Jun 10 01:01:28 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: Message-ID: Maybe glade works this way, I've only looked at wxGlade briefly. When I tried a couple of similar tools for TclTk, I found that if I changed anything in the code, the GUI builder would no longer recognize it and I was stuck with doing it by hand from then on. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Joel Pitt > Reply-To: > Date: Sat, 10 Jun 2006 10:50:29 +1200 > To: Glynn Clements > Cc: Hamish , > Subject: Re: [GRASS-dev] Python GUI toolkits > > On 6/9/06, Glynn Clements wrote: >> >> Joel Pitt wrote: >>>> Would pyGTK it need to have libglade on all platforms? >>>> Or just for development? >>> >>> If you design the GUI with glade then you need libglade at runtime. >>> pyGTK does not *need* libglade to be used, and I'm somewhat hesitant >>> about having libglade required across platforms. IMHO glade is great >>> for prototyping, but for clean and well designed code - especially >>> with regards to OO encapsulation of GUI elements - then writing the >>> GUI directly with pyGTK is best. >> >> I disagree. If you view Glade merely as a development tool, then it >> doesn't provide any advantage to the user over coding the GUI. >> >> However, I tend to view external UI descriptions such as Glade or UIL >> (the same thing, but for Motif) as user configuration files. If the >> user doesn't like the placement of buttons or menu items, or their >> shortcuts etc, they can just edit the UI description. Similarly, if >> they don't use certain features, they can just remove unnecessary >> widgets from the UI. > > Good point Glynn. Guess I spend too much time thinking from a > developers perspective. > > If we use wxPython/wxGlade then it is worth noting that XRC files can > be generated that perform a similar role to glade xml files: > http://wxwidgets.org/manuals/2.6.3/wx_xrcoverview.html#xrcoverview > > -- > -Joel > > "Wish not to seem, but to be, the best." > -- Aeschylus > > From glynn at gclements.plus.com Sat Jun 10 03:30:32 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jun 10 03:30:59 2006 Subject: [GRASS-dev] grass6.2? In-Reply-To: References: <17545.56051.80953.220406@cerise.gclements.plus.com> Message-ID: <17546.8376.108654.592564@cerise.gclements.plus.com> Michael Barton wrote: > > So, should I commit the changes to libraster to allow driver-less > > rendering? > > Does this mean that I can change gis.m to render with out running d.mon? Yes. > Anything I would have to know about setting environments to do this? If the environment variable GRASS_RENDER_IMMEDIATE is set to TRUE, libraster uses the built-in "PNG driver" instead of connecting to a monitor. All of the environment variables which the PNG driver understands apply to immediate rendering. This should be backwards-compatible, i.e. so long as you don't set GRASS_RENDER_IMMEDIATE, everything should work as before. I've attached the code in case anyone wants to try it now. -- Glynn Clements -------------- next part -------------- A non-text attachment was scrubbed... Name: libraster.tar.gz Type: application/octet-stream Size: 25931 bytes Desc: driver-less libraster Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060610/16bcbc75/libraster.tar-0001.obj From glynn at gclements.plus.com Sat Jun 10 03:50:11 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jun 10 03:50:25 2006 Subject: [GRASS-dev] A portible shell for GRASS 7+ ? In-Reply-To: References: <17545.55782.941172.48309@cerise.gclements.plus.com> Message-ID: <17546.9555.674728.957100@cerise.gclements.plus.com> Michael Barton wrote: > > I can get most of GRASS to compile on Windows without Cygwin (this > > relies upon the not-yet-committed changes to libraster to allow > > driver-less rendering). > > > > However, there appear to be some fundamental problems with the MSVC > > run-time, e.g. fseek() doesn't work on files opened for update > > ("wb+"), so I wouldn't expect it to run. > > > > FWIW, the portions which fail to compile are: > > > > lib/fonts/for_grass > > lib/vector/diglib > > > > Both due to fseek() issues. > > These may be the most problematic Definitely. The lib/fonts/for_grass issue is that splitfont() doesn't work. lib/vector/diglib fails because the portable I/O test fails. IOW, these are both run-time failures. It's likely that everything which uses fseek() on read-write files will fail similarly (I've written test programs to verify the fseek() behaviour, and they fail in the same way). > > display/d.mon/pgms > > > > Undefined reference to ttyname() > > Don't know what this might do If the fifth field in the monitorcap file is non-empty, you can only start the monitor from the specified terminal (i.e. mon.start's stdin must refer to the specified terminal). This has a very specific purpose: if you are running GRASS on a pair of actual hardware terminals (one text terminal and one graphics terminal, e.g. a DEC vt220 and a Tektronix 4105) on a multi-user system, it stops you from starting someone else's monitor by mistake. Given that the Tektronix 4105 driver isn't supported in 5.x, let alone 6.x, I think it's safe to consider this feature "obsolete". > > imagery/i.class > > > > Undefined SIGTSTP > > It would be nice if this worked. It wouldn't be hard to just disable that code with "#ifndef __MINGW32__". It's catching that signal because curses messes with the terminal, so you need to either disable Ctrl-Z or catch it and restore the terminal settings. That isn't applicable to Windows, as you can't suspend console applications. > > imagery/i.ortho.photo/photo.rectify > > imagery/i.rectify > > i.rectify needs to work for the georectifier, but doesn't need to run in x11 > interactive mode. We just need to rename compress() to something which doesn't conflict with zlib. Actually, compress() is just a stub, so we could probably just remove it. > > display/d.paint.labels > > raster/r.support/modcats > > raster/r.support/modcolr > > raster/r.support/modhist > > raster/r.support/modhead > > > > Attempting to use ln/mv on files which don't exist (need to add the > > .exe suffix). > > d.paint.lables/d.labels replaced by TclTk equivalent in gis.m. Didn't work > right in TclTk canvas anyway (at least on Mac) > r.support would be nice but not critical Platform.make.in actually has a variable EXE_SUFFIX, but nothing sets it. -- Glynn Clements From michael.barton at asu.edu Sat Jun 10 07:46:37 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sat Jun 10 07:46:41 2006 Subject: [GRASS-dev] grass6.2? In-Reply-To: <17546.8376.108654.592564@cerise.gclements.plus.com> Message-ID: What about geometry? We have to stop d.mon gism, reset the geometry, and restart gism. How is this handled in the new system? 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, 10 Jun 2006 02:30:32 +0100 > To: Michael Barton > Cc: > Subject: Re: [GRASS-dev] grass6.2? > > > Michael Barton wrote: > >>> So, should I commit the changes to libraster to allow driver-less >>> rendering? >> >> Does this mean that I can change gis.m to render with out running d.mon? > > Yes. > >> Anything I would have to know about setting environments to do this? > > If the environment variable GRASS_RENDER_IMMEDIATE is set to TRUE, > libraster uses the built-in "PNG driver" instead of connecting to a > monitor. All of the environment variables which the PNG driver > understands apply to immediate rendering. > > This should be backwards-compatible, i.e. so long as you don't set > GRASS_RENDER_IMMEDIATE, everything should work as before. > > I've attached the code in case anyone wants to try it now. > > -- > Glynn Clements > From rez at touchofmadness.com Sat Jun 10 12:54:12 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Sat Jun 10 12:54:20 2006 Subject: [GRASS-dev] Re: grass-dev Digest, Vol 2, Issue 19 In-Reply-To: <20060609201334.00c7a939.hamish_nospam@yahoo.com> References: <20060609201334.00c7a939.hamish_nospam@yahoo.com> Message-ID: <1149936853.2222.22.camel@devel> On Fri, 2006-06-09 at 20:13 +1200, Hamish wrote: > David Finlayson wrote: > > As far as I am concerned, there are more pressing issues for GRASS > > than the GUI. > > 1) Get NVIZ working* on Fedora Core 5 then release GRASS 6.1.0 as a > development snapshot. > > 2) see (1). > > [*] Figure out if it is a 64bit problem, a dreaded TclTk 8.4+threading > error, TclTk 8.5 newness, or something that happened with the Togl 1.7 > update. > > > Reported by Helena: > > >> nviz gives me: > >> > >> GRASS 6.1.cvs (jockeystft):/bigdata/lindata > nviz el01.z4 > >> Loading Data > >> Loading Data > >> translating colors from fp > >> X Error of failed request: GLXBadContext > >> Major opcode of failed request: 143 (GLX) > >> Minor opcode of failed request: 5 (X_GLXMakeCurrent) > >> Serial number of failed request: 201 > >> Current serial number in output stream: 201 > > and same by Jaime Carrera: > http://article.gmane.org/gmane.comp.gis.grass.user/13687 I thought this had been fixed? Could it be a missing dependency (mesa or equiv.?)? I'm currently running FC5, 64bit, with FC5 packages of TclTk* and *GL* and I have no problem with nviz in Spearfish (anymore). Export to image formats are still broken (some segv(), some write bad data). Animation via ffmpeg 'works', but again, writes bad data. The 64bit data corruption and segv() issues needs to be fixed before 6.2 goes gold. I'll see if I can't hunt down and correct the segv()s this weekend. -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From wolf+grass at bergenheim.net Sat Jun 10 14:54:34 2006 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Sat Jun 10 14:54:50 2006 Subject: [GRASS-dev] grass6.2? In-Reply-To: References: Message-ID: On Fri, 9 Jun 2006, Michael Barton wrote: > > georectifier: C script for RMS error, updates to v.transform so that it can > read or ignore a 5th column (use gcp) in a points file, creation of v.group > (if everyone thinks this is a good idea). The last two are for consistency, > but not required for functionality. I have everything running as is now > except for RMS. I haven't followed the discussions about this so closely. Would you mind telling me what it is that you way, then I could maybe whip up a module to do the calculations. Do we have some sort of equation(s)? > v.digit: I don't think this will get done. Jachym's efforts have been > directed towards pyGTK. This is nice for the future, but doesn't help for > 6.2. Unless someone jumps into the breach soon, we should just accept that > you will need x11 (or QGIS) for digitizing for now. Also v.edit would need some more doing. esp. the delete doesn't work, and I haven't had time to have a good look at it ): I'm also having strange problems with adding adjacent areas. if they are only N-S,E-W it's all good, but if not then I'd need to do some voodoo to make it work. why? i.e. this works: +---+---+ | | | +---+---+ | | | +---+---+ This doesn't +---+---+ /| /| / +-+-+-+-+ / |/ |/ +---+---+ Can anyone give me a clue on what is going on? --W -- <:3 )---- Wolf Bergenheim ----( 8:> From grass-bugs at intevation.de Sat Jun 10 19:37:26 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sat Jun 10 19:37:28 2006 Subject: [GRASS-dev] [bug #4565] (grass) cartography work Message-ID: <20060610173726.14BC31005A3@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4565 ------------------------------------------------------------------------- Subject: cartography work Platform: WindowsNT/2000/XP grass obtained from: Mirror of Trento site 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 Jun 10 19:38:38 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sat Jun 10 19:38:40 2006 Subject: [GRASS-dev] [bug #4566] (grass) Message-ID: <20060610173838.B2AA21005A3@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4566 ------------------------------------------------------------------------- Subject: -------------------------------------------- Managed by Request Tracker From david.p.finlayson at gmail.com Sun Jun 11 01:32:27 2006 From: david.p.finlayson at gmail.com (David Finlayson) Date: Sun Jun 11 01:32:30 2006 Subject: [GRASS-dev] $GISBASE/etc/run what does this do? Message-ID: I am trying to understand $GISBASE/etc/Init.sh The final call is to a program $GIS/etc/run $SHELL What does "run" do exactly? -- David Finlayson From glynn at gclements.plus.com Sun Jun 11 09:01:23 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jun 11 09:01:48 2006 Subject: [GRASS-dev] Re: grass-dev Digest, Vol 2, Issue 19 In-Reply-To: <1149936853.2222.22.camel@devel> References: <20060609201334.00c7a939.hamish_nospam@yahoo.com> <1149936853.2222.22.camel@devel> Message-ID: <17547.49091.412676.127861@cerise.gclements.plus.com> Brad Douglas wrote: > Export to image formats are still broken (some segv(), some write bad > data). Animation via ffmpeg 'works', but again, writes bad data. > The 64bit data corruption and segv() issues needs to be fixed before 6.2 > goes gold. I'll see if I can't hunt down and correct the segv()s this > weekend. I'm looking into the OGSF image handling stuff right now. -- Glynn Clements From glynn at gclements.plus.com Sun Jun 11 09:04:10 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jun 11 09:04:15 2006 Subject: [GRASS-dev] grass6.2? In-Reply-To: References: <17546.8376.108654.592564@cerise.gclements.plus.com> Message-ID: <17547.49258.581831.541645@cerise.gclements.plus.com> Michael Barton wrote: > >>> So, should I commit the changes to libraster to allow driver-less > >>> rendering? > >> > >> Does this mean that I can change gis.m to render with out running d.mon? > > > > Yes. > > > >> Anything I would have to know about setting environments to do this? > > > > If the environment variable GRASS_RENDER_IMMEDIATE is set to TRUE, > > libraster uses the built-in "PNG driver" instead of connecting to a > > monitor. All of the environment variables which the PNG driver > > understands apply to immediate rendering. > > > > This should be backwards-compatible, i.e. so long as you don't set > > GRASS_RENDER_IMMEDIATE, everything should work as before. > > > > I've attached the code in case anyone wants to try it now. > > What about geometry? We have to stop d.mon gism, reset the geometry, and > restart gism. How is this handled in the new system? As with the PNG driver, the dimensions are taken from GRASS_WIDTH and GRASS_HEIGHT, defaulting to 640 and 480 respectively. -- Glynn Clements From glynn at gclements.plus.com Sun Jun 11 09:11:10 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jun 11 09:11:43 2006 Subject: [GRASS-dev] grass6.2? In-Reply-To: References: Message-ID: <17547.49678.544043.367330@cerise.gclements.plus.com> Wolf Bergenheim wrote: > > georectifier: C script for RMS error, updates to v.transform so that it can > > read or ignore a 5th column (use gcp) in a points file, creation of v.group > > (if everyone thinks this is a good idea). The last two are for consistency, > > but not required for functionality. I have everything running as is now > > except for RMS. > > I haven't followed the discussions about this so closely. Would you mind > telling me what it is that you way, then I could maybe whip up a module > to do the calculations. Do we have some sort of equation(s)? See compute_transformation() in imagery/i.points/analyze.c. Compute_equation() is in imagery/i.points/equ.c. The two I_* functions which are used are in lib/imagery/georef.c. However, the use of the I_* functions should be replaced by GDALCreateGCPTransformer(), GDALGCPTransform() and GDALDestroyGCPTransformer(). Unlike the I_* functions, the GDAL functions support 2nd- and 3rd-order transformations, and are based upon the same code which i.rectify uses. -- Glynn Clements From glynn at gclements.plus.com Sun Jun 11 09:17:25 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jun 11 09:17:30 2006 Subject: [GRASS-dev] $GISBASE/etc/run what does this do? In-Reply-To: References: Message-ID: <17547.50053.659286.168799@cerise.gclements.plus.com> David Finlayson wrote: > I am trying to understand $GISBASE/etc/Init.sh > > The final call is to a program $GIS/etc/run $SHELL > > What does "run" do exactly? It runs a command with SIGINT and SIGQUIT re-enabled (the Init.sh script ignores those signals, as well as SIGTERM). -- Glynn Clements From grass-bugs at intevation.de Sun Jun 11 10:03:26 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sun Jun 11 10:03:28 2006 Subject: [GRASS-dev] [bug #4568] (grass) weekly 6.1-CVS source code snapshot - show current grass version Message-ID: <20060611080326.A493E1006A7@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4568 ------------------------------------------------------------------------- Subject: weekly 6.1-CVS source code snapshot - show current grass version Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: grass-6.1.cvs_src_snapshot_2006_06_10.tar.gz hi, i´ve compiled the grass-6.1.cvs_src_snapshot_2006_06_10.tar.gz on my suse 10.1 -linux-machine. for the command in gis.m "Show current grass version" the following error message in the tcltk-menue comes up: wrong # args: should be "run_panel cmd" wrong # args: should be "run_panel cmd" while executing "run_panel g.version -c " invoked from within ".#menubar.#menubar#options.#menubar#options#menu2 invoke active" ("uplevel" body line 1) invoked from within "uplevel #0 [list $w invoke active]" (procedure "tk::MenuInvoke" line 50) invoked from within "tk::MenuInvoke .#menubar.#menubar#options.#menubar#options#menu2 1" (command bound to event) greetings helli -o-o-o-o-o-o-o-o-o-o-o-o- helmut kudrnovsky www.alectoria.at hellik@web.de -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Sun Jun 11 10:08:45 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sun Jun 11 10:08:47 2006 Subject: [GRASS-dev] [bug #4569] (grass) grass-6.1.cvs_src_snapshot_2006_06_10.tar.gz - error message for Message-ID: <20060611080845.912F91006A7@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4569 ------------------------------------------------------------------------- Subject: grass-6.1.cvs_src_snapshot_2006_06_10.tar.gz - error message for Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: grass-6.1.cvs_src_snapshot_2006_06_10.tar.gz hi again, grass-6.1.cvs_src_snapshot_2006_06_10.tar.gz compiled on suse 10.1, error message for the command "display region settings" in the tcltk-menue: wrong # args: should be "run_panel cmd" wrong # args: should be "run_panel cmd" while executing "run_panel g.region -p " invoked from within ".#menubar.#menubar#options.#menubar#options#menu1 invoke active" ("uplevel" body line 1) invoked from within "uplevel #0 [list $w invoke active]" (procedure "tk::MenuInvoke" line 50) invoked from within "tk::MenuInvoke .#menubar.#menubar#options.#menubar#options#menu1 1" (command bound to event) greetings helli -o-o-o-o-o-o-o-o-o-o-o-o- helmut kudrnovsky www.alectoria.at hellik@web.de -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Sun Jun 11 10:13:42 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sun Jun 11 10:13:44 2006 Subject: [GRASS-dev] [bug #4570] (grass) grass-6.1.cvs_src_snapshot_2006_06_10.tar.gz - error message for the command Message-ID: <20060611081342.D3CED1006A7@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4570 ------------------------------------------------------------------------- Subject: grass-6.1.cvs_src_snapshot_2006_06_10.tar.gz - error message for the command Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: grass-6.1.cvs_src_snapshot_2006_06_10.ta hi, following error message on the compiled grass-6.1.cvs_src_snapshot_2006_06_10.tar.gz on suse 10.1 for the command "show standard grass fonts": couldn't execute "show.fonts.sh": no such file or directory couldn't execute "show.fonts.sh": no such file or directory while executing "exec -- $program --tcltk" (procedure "run_ui" line 6) invoked from within "run_ui $cmd" (procedure "execute" line 3) invoked from within "execute show.fonts.sh " invoked from within ".#menubar.#menubar#options.#menubar#options#menu4 invoke active" ("uplevel" body line 1) invoked from within "uplevel #0 [list $w invoke active]" (procedure "tk::MenuInvoke" line 50) invoked from within "tk::MenuInvoke .#menubar.#menubar#options.#menubar#options#menu4 1" (command bound to event) greetings helli -o-o-o-o-o-o-o-o-o-o-o-o- helmut kudrnovsky www.alectoria.at hellik@web.de -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Sun Jun 11 11:05:28 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sun Jun 11 11:05:31 2006 Subject: [GRASS-dev] [bug #4571] (grass) How can I fix GRASS_WISH? Message-ID: <20060611090528.BE4D41005C1@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4571 ------------------------------------------------------------------------- Subject: How can I fix GRASS_WISH? In fedora 5 it keeps saying me that my environment is misconfigured, it suggests to change GRASS_WISH. My wish it's to change it but I have no idea how. Latest 6.1 -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Sun Jun 11 13:17:48 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Sun Jun 11 13:17:50 2006 Subject: [GRASS-dev] [bug #4557] (grass) problem with v.surf.rst cross validation Message-ID: <20060611111748.C53481006A7@lists.intevation.de> Marie, Indeed in Grass 6.0x for turning on the CV there is '-v'. In the newer Grass 6.1, as Helena says, there is '-c'. Question for devs - is it good that we have the flags not preserved between 6.0 and 6.1? Getting back to Marie's problem > v.surf.rst input=punti_interpolazione layer=0 dmax=4.999977 dmin=0.999995 > cvdev=cross_test zmult=1.0 tension=40. smooth=0.1 segmax=40 npmin=100 -v > DBMI-DBF driver error: > SQL parser error in statement: > create table punti_interpolazione.cross_test ( cat integer, flt1 double > precision) > Error in db_execute_immediate() Marie, I don't why v.surf.rst is trying to create a table 'punti_interpolazione.cross_test' when your requested CV vector name is 'cross_test'. Especially that the dot in the table name is illegal (http://grass.itc.it/grass61/manuals/html61_user/sql.html). Moreover I can't reproduce the error in my Grass 6.02 instalation (2006_01_28), using exactly the same command as you did. Are you sure you pastes *exactly* the command you used, and that there was no dot in 'cvdev' name by nay chance? Can you try the latest 6.0x version, which is 6.02, and let us know how it works? 6.0 is over a year old now. Maciek -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Sun Jun 11 14:06:26 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Sun Jun 11 14:06:27 2006 Subject: [GRASS-dev] [bug #4449] (grass) NVIZ_out_of_Memory Message-ID: <20060611120626.93E0F1006A7@lists.intevation.de> > nviz(17755,0xa000ed98) malloc: *** vm_allocate(size=3655032832) failed > (error code=3) > nviz(17755,0xa000ed98) malloc: *** error: can't allocate region > nviz(17755,0xa000ed98) malloc: *** set a breakpoint in szone_error to > debug Out of memory - Unable to load map > Platform: Mac > Version:cvs moretti's 06 may 06 To the bug requestor: You haven't given your email when you reported this bug. If you are reading this, can you please reply to Hamish'es question in the tracker here: http://intevation.de/rt/webrt?serial_num=444 and let us know what is the current status? Maciek -------------------------------------------- Managed by Request Tracker From glynn at gclements.plus.com Sun Jun 11 14:19:10 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jun 11 14:19:13 2006 Subject: [GRASS-dev] Re: grass-dev Digest, Vol 2, Issue 19 In-Reply-To: <17547.49091.412676.127861@cerise.gclements.plus.com> References: <20060609201334.00c7a939.hamish_nospam@yahoo.com> <1149936853.2222.22.camel@devel> <17547.49091.412676.127861@cerise.gclements.plus.com> Message-ID: <17548.2622.435238.584651@cerise.gclements.plus.com> Glynn Clements wrote: > > Export to image formats are still broken (some segv(), some write bad > > data). Animation via ffmpeg 'works', but again, writes bad data. > > The 64bit data corruption and segv() issues needs to be fixed before 6.2 > > goes gold. I'll see if I can't hunt down and correct the segv()s this > > weekend. > > I'm looking into the OGSF image handling stuff right now. I've committed some changes which should fix the 64-bit issues in the image dumping code. -- Glynn Clements From grass-bugs at intevation.de Sun Jun 11 14:31:47 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Sun Jun 11 14:31:49 2006 Subject: [GRASS-dev] [bug #4368] (grass) g.parser: pass through --o Message-ID: <20060611123147.BB9ED1006A7@lists.intevation.de> The bug is fixed I think, but I don't understand all the issues touched in the discussion. Anyway, as it "works for me", I'm taking the liberty to close it. Please re-open if needed. Maciek -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Sun Jun 11 14:43:49 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Sun Jun 11 14:43:51 2006 Subject: [GRASS-dev] [bug #4355] (grass) GUI: r.terraflow: the window does not pop up, error printed to terminal Message-ID: <20060611124349.62C501006A7@lists.intevation.de> Fixed in CVS. Thanks! Closing it. Maciek -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Sun Jun 11 14:49:05 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Sun Jun 11 14:49:07 2006 Subject: [GRASS-dev] [bug #4571] (grass) How can I fix GRASS_WISH? Message-ID: <20060611124905.822B51006A7@lists.intevation.de> > suggests to change GRASS_WISH. My wish it's to change it but I have no idea > how. http://grass.itc.it/grass61/manuals/html61_user/variables.html http://grass.itc.it/grass61/manuals/html61_user/g.gisenv.html Maciek P.S. Allways put your email when reporting a bug. I'm forwarding the message to grass user and grass devel lists in a hope it will reach you. Closing the bug. Maciek -------------------------------------------- Managed by Request Tracker From michael.barton at asu.edu Sun Jun 11 16:45:50 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sun Jun 11 16:46:05 2006 Subject: [GRASS-dev] grass6.2? In-Reply-To: Message-ID: Wolf, Thanks for the offer. 1. In order to calculate RMS error, it is necessary to transform the GCP's unprojected coordinates into projected coordinates, and calculate the diagonal distance between the transformed coordinates and the coordinates used to define the transformation. Apparently, there is already C-code to do this in the imagery library. Glynn said that he might be able to do a quick C-module to accomplish this, using existing code rather than have anyone write new code to do it. 2. I've combined raster and vector georectification into one module. However, the set up for georectifying vectors differs from rasters in several ways. Hamish and others suggested that this is a good time to make them consistent. This involves modifying v.transform and either extending i.group or making v.group. Here are the differences... I.group creates an ascii REF file listing all rasters that will be rectified using the same set of GCP's (stored in an ascii POINTS file). It also creates (if necessary) a group directory structure $GISBASE/group/[groupname] where REF and other georectifing configurations files are stored. There is no equivalent v.group I.target creates an ascii TARGET file that lists the projected location/mapset into which the files in REF will be projected. There is no equivalent for vectors. This is needed by i.rectify but not by v.transform. I.points interactively creates a 5 column POINTS file that is used for rectifying rasters. The columns are unprojected x, unprojected y, projected east, projected north, a boolean (0/1) value that determine whether the row (a GCP) is used in rectification and RMS calculation. It calculates RMS error for the GCP's in the points file (those with a 1 in the 5th column). It saves the POINTS file in $GISBASE/group/[groupname]/ There is no equivalent v.points. V.transform uses an ascii file very similar to the POINTS file, except that it lacks the 5th column. In other words, all GCP's in a vector points file are used for georectification. There is no interactive program like i.points to create a vector points file. The vector points file can be stored anywhere and have any name. The georectifier is replacing i.points and serves to create a points file for vectors too. The suggestion is to have v.transform and i.rectify read files of identical 5 column format, have v.transform work on groups of vectors rather than just a single vector, and use a directory structure of $GISBASDE/group/... For vectors as well as rasters. This requires something to set up the group structure, REF file and possibly TARGET file for vectors (extended i.group, or a new v.group), and changing v.transform to use the group directory/file structure, read a 5 column POINTS file, and possibly a TARGET file. 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: Wolf Bergenheim > Date: Sat, 10 Jun 2006 15:54:34 +0300 (EEST) > To: Michael Barton > Cc: Helena Mitasova , , > > Subject: Re: [GRASS-dev] grass6.2? > > On Fri, 9 Jun 2006, Michael Barton wrote: >> >> georectifier: C script for RMS error, updates to v.transform so that it can >> read or ignore a 5th column (use gcp) in a points file, creation of v.group >> (if everyone thinks this is a good idea). The last two are for consistency, >> but not required for functionality. I have everything running as is now >> except for RMS. > > I haven't followed the discussions about this so closely. Would you mind > telling me what it is that you way, then I could maybe whip up a module > to do the calculations. Do we have some sort of equation(s)? > >> v.digit: I don't think this will get done. Jachym's efforts have been >> directed towards pyGTK. This is nice for the future, but doesn't help for >> 6.2. Unless someone jumps into the breach soon, we should just accept that >> you will need x11 (or QGIS) for digitizing for now. > > Also v.edit would need some more doing. esp. the delete doesn't work, and > I haven't had time to have a good look at it ): I'm also having strange > problems with adding adjacent areas. if they are only N-S,E-W it's all > good, but if not then I'd need to do some voodoo to make it work. why? > > i.e. this works: > +---+---+ > | | | > +---+---+ > | | | > +---+---+ > > This doesn't > +---+---+ > /| /| / > +-+-+-+-+ > / |/ |/ > +---+---+ > > Can anyone give me a clue on what is going on? > > --W > > -- > > <:3 )---- Wolf Bergenheim ----( 8:> > From michael.barton at asu.edu Sun Jun 11 17:19:56 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sun Jun 11 17:20:12 2006 Subject: [GRASS-dev] Re: grass-dev Digest, Vol 2, Issue 19 In-Reply-To: <17547.49091.412676.127861@cerise.gclements.plus.com> Message-ID: That's great. 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, 11 Jun 2006 08:01:23 +0100 > To: > Cc: Hamish , , David > Finlayson , , > , Jaime Carrera > Subject: Re: [GRASS-dev] Re: grass-dev Digest, Vol 2, Issue 19 > > > Brad Douglas wrote: > >> Export to image formats are still broken (some segv(), some write bad >> data). Animation via ffmpeg 'works', but again, writes bad data. >> The 64bit data corruption and segv() issues needs to be fixed before 6.2 >> goes gold. I'll see if I can't hunt down and correct the segv()s this >> weekend. > > I'm looking into the OGSF image handling stuff right now. > > -- > Glynn Clements From michael.barton at asu.edu Sun Jun 11 17:23:26 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sun Jun 11 17:23:32 2006 Subject: [GRASS-dev] $GISBASE/etc/run what does this do? In-Reply-To: <17547.50053.659286.168799@cerise.gclements.plus.com> Message-ID: We're trying to figure this out too to get Java and GRASS to talk to each other. Could you explain a bit more? What you say sounds like it doesn't really do anything useful. 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, 11 Jun 2006 08:17:25 +0100 > To: David Finlayson > Cc: GRASS developers list > Subject: Re: [GRASS-dev] $GISBASE/etc/run what does this do? > > > David Finlayson wrote: > >> I am trying to understand $GISBASE/etc/Init.sh >> >> The final call is to a program $GIS/etc/run $SHELL >> >> What does "run" do exactly? > > It runs a command with SIGINT and SIGQUIT re-enabled (the Init.sh > script ignores those signals, as well as SIGTERM). > > -- > Glynn Clements > > From werchowyna at epf.pl Sun Jun 11 17:52:28 2006 From: werchowyna at epf.pl (Maciek Sieczka) Date: Sun Jun 11 17:52:23 2006 Subject: [GRASS-dev] where is i.atcorr In-Reply-To: <6278879c0606070153r7dcd3b46h70e2d11fe3301d44@mail.gmail.com> References: <6278879c0606070153r7dcd3b46h70e2d11fe3301d44@mail.gmail.com> Message-ID: <20060611175228.8fb7abe1.werchowyna@epf.pl> On Wed, 7 Jun 2006 15:53:26 +0700 "Yann Chemin" wrote: > Hello list, > the link http://www.cs.sun.ac.za/~caz/projects.html in > http://grass.itc.it/download/addons.php is broken. > Anybody knows where the code has gone? Ask i.atcors's author: Christo Zietsman 13422863 at sun.ac.za or christo at issi.co.za (not sure which one is current) If he is not reachable, try contacting his (former?) head: Wolfgang L?ck wolfluck at mweb.co.za Please note that there were problems with i.atcor http://intevation.de/rt/webrt?serial_num=2629&display=History Maciek -------------------- W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich! http://katalog.panoramainternetu.pl/ From werchowyna at epf.pl Sun Jun 11 17:59:33 2006 From: werchowyna at epf.pl (Maciek Sieczka) Date: Sun Jun 11 17:59:28 2006 Subject: [GRASS-dev] New georectifying module in TclTk In-Reply-To: <20060607215127.50b03ea9.hamish_nospam@yahoo.com> References: <20060606223532.2b6ffaf9.hamish_nospam@yahoo.com> <20060607215127.50b03ea9.hamish_nospam@yahoo.com> Message-ID: <20060611175933.b293dec9.werchowyna@epf.pl> On Wed, 7 Jun 2006 21:51:27 +1200 Hamish wrote: > > It sounds like most of the issues can be avoided by using i.rectify > > -c. > > that is my understanding. > > > What are the disadvantages of using the -c switch? > > you have to restart GRASS in the target location and set up the region > by hand. Ok if you knew to project a v.in.region box first and can > calculate your target resolution Could you say how to calculate it? Maciek -------------------- W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich! http://katalog.panoramainternetu.pl/ From david.p.finlayson at gmail.com Sun Jun 11 19:52:50 2006 From: david.p.finlayson at gmail.com (David Finlayson) Date: Sun Jun 11 19:52:53 2006 Subject: [GRASS-dev] $GISBASE/etc/run what does this do? In-Reply-To: References: <17547.50053.659286.168799@cerise.gclements.plus.com> Message-ID: Last night I got GRASS to launch and run entirely from Python. No bourne shell at all. I'm not sure what to do with the signal catching in the Init.sh script. I was going to look them up on Google and see what they do. Then decide whether this is a feature that should be duplicated in Python Does it control how canceling commands (Ctrl+D, etc.) work? On 6/11/06, Michael Barton wrote: > We're trying to figure this out too to get Java and GRASS to talk to each > other. > > Could you explain a bit more? What you say sounds like it doesn't really do > anything useful. > > 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, 11 Jun 2006 08:17:25 +0100 > > To: David Finlayson > > Cc: GRASS developers list > > Subject: Re: [GRASS-dev] $GISBASE/etc/run what does this do? > > > > > > David Finlayson wrote: > > > >> I am trying to understand $GISBASE/etc/Init.sh > >> > >> The final call is to a program $GIS/etc/run $SHELL > >> > >> What does "run" do exactly? > > > > It runs a command with SIGINT and SIGQUIT re-enabled (the Init.sh > > script ignores those signals, as well as SIGTERM). > > > > -- > > Glynn Clements > > > > > > -- David Finlayson From glynn at gclements.plus.com Mon Jun 12 00:01:53 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jun 12 00:02:47 2006 Subject: [GRASS-dev] grass6.2? In-Reply-To: References: Message-ID: <17548.37585.735281.876075@cerise.gclements.plus.com> Michael Barton wrote: > 1. In order to calculate RMS error, it is necessary to transform the GCP's > unprojected coordinates into projected coordinates, and calculate the > diagonal distance between the transformed coordinates and the coordinates > used to define the transformation. Apparently, there is already C-code to do > this in the imagery library. Glynn said that he might be able to do a quick > C-module to accomplish this, using existing code rather than have anyone > write new code to do it. To clarify: the code to choose a transformation and to project coordinates is in the imagery library, while the error calculation is in i.points. However: 1. i.rectify has its own alternatives to the functions in the imagery library. The i.rectify versions support 2nd- and 3rd- order transformations, while those in the imagery library only support 1st-order (affine) transformations. Thus the error calculations are only meaningful if you use a 1st-order transformation with i.rectify. 2. GDAL contains its own version of the code used by i.rectify. Rather than duplicate this, we should use the GDAL version. > 2. I've combined raster and vector georectification into one module. > However, the set up for georectifying vectors differs from rasters in > several ways. Hamish and others suggested that this is a good time to make > them consistent. This involves modifying v.transform and either extending > i.group or making v.group. Here are the differences... One difference which should probably be stated more explicitly is that i.rectify can use a source from a different location, whereas v.transform requires the source to be in the current location. -- Glynn Clements From michael.barton at asu.edu Mon Jun 12 00:14:25 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Jun 12 00:14:40 2006 Subject: [GRASS-dev] grass6.2? In-Reply-To: <17548.37585.735281.876075@cerise.gclements.plus.com> Message-ID: I'd put it a bit differently. What seems to happen is that the vector output from v.transform ends up in the same location as the input file. That is, if your vector file is in an xy location, the projected output will also end up in the same location--even though it is correctly projected. In other words, it behaves like any other normal map operation--it must take place within the active location/mapset. So, subsequently, you can simply copy the vector folder for the projected map to the proper projected location and mapset. The georectifier does that now. This is due to the lack of a 'target' location/mapset like those produced by i.group. I don't know if you want to change that behavior to make it consistent with rasters, or let the georectifier (or other such utility) do the work. 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, 11 Jun 2006 23:01:53 +0100 > To: Michael Barton > Cc: Wolf Bergenheim , Helena Mitasova > , , > Subject: Re: [GRASS-dev] grass6.2? > > One difference which should probably be stated more explicitly is that > i.rectify can use a source from a different location, whereas > v.transform requires the source to be in the current location. From glynn at gclements.plus.com Mon Jun 12 00:33:18 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jun 12 00:33:31 2006 Subject: [GRASS-dev] $GISBASE/etc/run what does this do? In-Reply-To: References: <17547.50053.659286.168799@cerise.gclements.plus.com> Message-ID: <17548.39470.689654.16951@cerise.gclements.plus.com> David Finlayson wrote: > Last night I got GRASS to launch and run entirely from Python. No > bourne shell at all. I'm not sure what to do with the signal catching > in the Init.sh script. I was going to look them up on Google and see > what they do. Then decide whether this is a feature that should be > duplicated in Python > > Does it control how canceling commands (Ctrl+D, etc.) work? If you don't run $SHELL via etc/run, the spawned shell will have SIGINT and SIGQUIT disabled. In practice, this will typically disable Ctrl-C and Ctrl-\ (the codes which generate the signals can be changed, but those are the usual defaults). AFAICT, the reason that Init.sh disables those signals is so that Ctrl-C and Ctrl-\ go to the interactive session shell, not the shell running the Init.sh script. On a system which supports job control (which is likely to be every Unix system still in use), that shouldn't be necessary, as the signals will go to the foreground process group, which will be either the spawned shell or its children. -- Glynn Clements From michael.barton at asu.edu Mon Jun 12 00:43:53 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Jun 12 00:44:00 2006 Subject: [GRASS-dev] $GISBASE/etc/run what does this do? In-Reply-To: <17548.39470.689654.16951@cerise.gclements.plus.com> Message-ID: Thanks to both of you for these informative answers. They are very helpful. 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, 11 Jun 2006 23:33:18 +0100 > To: David Finlayson > Cc: Michael Barton , GRASS developers list > > Subject: Re: [GRASS-dev] $GISBASE/etc/run what does this do? > > > David Finlayson wrote: > >> Last night I got GRASS to launch and run entirely from Python. No >> bourne shell at all. I'm not sure what to do with the signal catching >> in the Init.sh script. I was going to look them up on Google and see >> what they do. Then decide whether this is a feature that should be >> duplicated in Python >> >> Does it control how canceling commands (Ctrl+D, etc.) work? > > If you don't run $SHELL via etc/run, the spawned shell will have > SIGINT and SIGQUIT disabled. In practice, this will typically disable > Ctrl-C and Ctrl-\ (the codes which generate the signals can be > changed, but those are the usual defaults). > > AFAICT, the reason that Init.sh disables those signals is so that > Ctrl-C and Ctrl-\ go to the interactive session shell, not the shell > running the Init.sh script. > > On a system which supports job control (which is likely to be every > Unix system still in use), that shouldn't be necessary, as the signals > will go to the foreground process group, which will be either the > spawned shell or its children. > > -- > Glynn Clements From glynn at gclements.plus.com Mon Jun 12 02:19:56 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jun 12 02:20:49 2006 Subject: [GRASS-dev] grass6.2? In-Reply-To: References: <17548.37585.735281.876075@cerise.gclements.plus.com> Message-ID: <17548.45868.591098.578758@cerise.gclements.plus.com> Michael Barton wrote: > > One difference which should probably be stated more explicitly is that > > i.rectify can use a source from a different location, whereas > > v.transform requires the source to be in the current location. > > I'd put it a bit differently. > > What seems to happen is that the vector output from v.transform ends up in > the same location as the input file. That is, if your vector file is in an > xy location, the projected output will also end up in the same > location--even though it is correctly projected. In other words, it behaves > like any other normal map operation--it must take place within the active > location/mapset. > > So, subsequently, you can simply copy the vector folder for the projected > map to the proper projected location and mapset. The georectifier does that > now. This is due to the lack of a 'target' location/mapset like those > produced by i.group. > > I don't know if you want to change that behavior to make it consistent with > rasters, or let the georectifier (or other such utility) do the work. i.rectify, r.proj and v.proj all read from one location and write to another (although the two can be the same, they don't have to be), while v.transform only uses a single location. I suggest that v.transform should be extended to allow a different source location. -- Glynn Clements From michael.barton at asu.edu Mon Jun 12 02:40:00 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Jun 12 02:40:16 2006 Subject: [GRASS-dev] grass6.2? In-Reply-To: <17548.45868.591098.578758@cerise.gclements.plus.com> Message-ID: I noted the difference because i.rectify reads from the current location and writes to the location specified by i.target. V.proj and r.proj read from a different location/map set and write to the current one. I'd suggest making v.transform consistent with i.rectify rather than v.proj, either by implementing a TARGET file or with location and mapset arguments in the command (the latter seems easier than the i.target way). 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: Mon, 12 Jun 2006 01:19:56 +0100 > To: Michael Barton > Cc: Helena Mitasova , Wolf Bergenheim > , , > Subject: Re: [GRASS-dev] grass6.2? > > i.rectify, r.proj and v.proj all read from one location and write to > another (although the two can be the same, they don't have to be), > while v.transform only uses a single location. I suggest that > v.transform should be extended to allow a different source location. From hamish_nospam at yahoo.com Mon Jun 12 03:03:16 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 12 03:03:31 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: <20060609100945.GA8684@gdf-hannover.de> References: <20060609004745.0e31b819.hamish_nospam@yahoo.com> <20060609214733.7ee57d12.hamish_nospam@yahoo.com> <20060609100945.GA8684@gdf-hannover.de> Message-ID: <20060612130316.46b82b0c.hamish_nospam@yahoo.com> Jachym Cepicky wrote: > The way currently gis.m is doing things are IMHO good, I just would > not add another window on the destop. As it is, 4 to 5 windows for gis.m (incl. term and module GUI) is 2-3 too many. Hamish From hamish_nospam at yahoo.com Mon Jun 12 03:06:19 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 12 03:06:27 2006 Subject: [GRASS-dev] grass6.2? In-Reply-To: <17545.56051.80953.220406@cerise.gclements.plus.com> References: <6A30DF58-8AD1-44AF-8F6E-565566CF7FD7@unity.ncsu.edu> <17545.56051.80953.220406@cerise.gclements.plus.com> Message-ID: <20060612130619.569a5a9c.hamish_nospam@yahoo.com> Glynn Clements wrote: > So, should I commit the changes to libraster to allow driver-less > rendering? Not until 6.1.0 is released please! If that is committed we have to wait to release 6.1.0, if not we can pretty much release it now. Hamish From grass-bugs at intevation.de Mon Jun 12 03:29:38 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Mon Jun 12 03:29:40 2006 Subject: [GRASS-dev] [bug #4583] (grass) Waiting for your response for approva Sun, 11 Jun 2006 19:57:36 -0600l Message-ID: <20060612012938.680E81006D1@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4583 ------------------------------------------------------------------------- We have been attempting to reach you regarding your pre-approval. You can get up to $297,000 for as low as $797/month. We need to hear back from you as soon as possible. Follow our link to complete your application: http://www.yourlowestrefi.com Mark Roth Lending Agent Continental Loans workpiece to your deportation dormant. specie and calais. butyl if you christenson chasm. --- Headers Follow --- >From fcy6f6i0gt41gg@fantask.dk Mon Jun 12 03:29:38 2006 Return-Path: Delivered-To: grass-bugs@lists.intevation.de Received: from mail.intevation.de (aktaia [212.95.126.10]) by lists.intevation.de (Postfix) with ESMTP id 3E5A11006CB for ; Mon, 12 Jun 2006 03:29:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.intevation.de (Postfix) with ESMTP id D0BFF371E3; Mon, 12 Jun 2006 03:29:37 +0200 (CEST) Received: from 130E0270 (unknown [200.125.105.176]) by mail.intevation.de (Postfix) with SMTP id 374563724D; Mon, 12 Jun 2006 02:57:36 +0200 (CEST) X-Apparently-To: heiko.kehlenbrink@intevation.de Received: from decryption (HELO 9devolve) as user melody@contradistinct by www.captaincy.com.ar with Mosap; Mon, 12 Jun 2006 05:52:36 +0400 Date: Mon, 12 Jun 2006 02:55:36 +0100 Message-Id: Date: Mon, 12 Jun 2006 06:56:36 +0500 From: "Continental Loans" To: Subject: Waiting for your response for approva Sun, 11 Jun 2006 19:57:36 -0600l X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=3.0 tests= X-Spam-Level: -------------------------------------------- Managed by Request Tracker From rez at touchofmadness.com Mon Jun 12 04:57:24 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Mon Jun 12 04:57:36 2006 Subject: [GRASS-dev] 64bit image issues (WAS: Re: grass-dev Digest, Vol 2, Issue 19) In-Reply-To: <17548.2622.435238.584651@cerise.gclements.plus.com> References: <20060609201334.00c7a939.hamish_nospam@yahoo.com> <1149936853.2222.22.camel@devel> <17547.49091.412676.127861@cerise.gclements.plus.com> <17548.2622.435238.584651@cerise.gclements.plus.com> Message-ID: <1150081044.2222.56.camel@devel> On Sun, 2006-06-11 at 13:19 +0100, Glynn Clements wrote: > Glynn Clements wrote: > > > > Export to image formats are still broken (some segv(), some write bad > > > data). Animation via ffmpeg 'works', but again, writes bad data. > > > The 64bit data corruption and segv() issues needs to be fixed before 6.2 > > > goes gold. I'll see if I can't hunt down and correct the segv()s this > > > weekend. > > > > I'm looking into the OGSF image handling stuff right now. > > I've committed some changes which should fix the 64-bit issues in the > image dumping code. Thank you! I now have complete images, not quadrants. High resolution PPM still crashes, tho: #0 0x00002aaab2612d6e in _mesa_GetIntegerv () from /usr/lib64/dri/radeon_dri.so #1 0x00002aaaaaad762d in gsd_getViewport (tmp=0xffc4b910, num=0xffc4b900) at gsd_prim.c:750 #2 0x00002aaaaaac7276 in GS_zoom_setup (a=0x7fffffc4c64c, b=0x7fffffc4c648, c=0x7fffffc4c644, d=0x7fffffc4c640, maxx=0x7fffffc4c63c, maxy=0x7fffffc4c638) at GS2.c:2395 #3 0x000000000041f999 in Nstart_zoom_cmd (data=0x5380a0, interp=0x5514a0, argc=4, argv=0x7fffffc4c6d0) at do_zoom.c:73 #4 0x00000031a2b2cd49 in TclInvokeStringCommand () from /usr/lib64/libtcl8.4.so I'll be committing code to fix several segv() issues in lib/image soon, as well (one caused by off_t issue and another by free()). Currently testing... -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From hamish_nospam at yahoo.com Mon Jun 12 05:08:20 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 12 05:08:25 2006 Subject: [GRASS-dev] [bug #4563] (grass) g.version should show finer precision timestamp other than just year In-Reply-To: <20060609123948.F3ABF1006AA@lists.intevation.de> References: <20060609123948.F3ABF1006AA@lists.intevation.de> Message-ID: <20060612150820.3df13883.hamish_nospam@yahoo.com> > this bug's URL: http://intevation.de/rt/webrt?serial_num=4563 > --------------------------------------------------------------------- > > Subject: g.version should show finer precision timestamp other than > just year > > 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-06-09 > > Would it be possible for g.version to show more detailed information > about /when/ the Grass version was compiled? This would be very useful > for example on machines where multiple Grass cvs versions are > installed, and the user is unsure of what particular cvs brand they > are working with. In this respect, g.version reporting "Grass 6.1 cvs > (2006)" isn't really telling the user a whole lot. I would like to see this too, but "GRASS 6.1-cvs built yyyy-mm-dd" doesn't tell you much. Maybe it is an old snapshot which is rebuilt on a newer date? Maybe have CVS server "touch; update" or "date > cvs.date" a file in the CVS which the build system could include in the devel version string, instead of just a hard-coded year? Hamish From hamish_nospam at yahoo.com Mon Jun 12 05:12:21 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 12 05:12:25 2006 Subject: [GRASS-dev] [bug #4564] (grass) v.in.ogr w/ large datasets In-Reply-To: <20060609124757.651E91006A4@lists.intevation.de> References: <20060609124757.651E91006A4@lists.intevation.de> Message-ID: <20060612151221.216cd498.hamish_nospam@yahoo.com> > this bug's URL: http://intevation.de/rt/webrt?serial_num=4564 > --------------------------------------------------------------------- > > Subject: v.in.ogr w/ large datasets > > Dear GRASSers, > > we have problems importing a large dataset (~300.000 features) with > v.in.ogr. It eats up all mem and dies without importing. > > We have tried using with -c (no clean) in order to reduce the mem > consumption, but without luck. > > At least this thread seems to be realated to our problem. > http://grass.itc.it/pipermail/grass-dev/2006-May/023088.html > > Some links to similar problems discussed on the mailinglist: > http://grass.itc.it/pipermail/grass-dev/2006-May/022917.html > > Radim wrote something about it, but did not elaborate where to start > solving this problem. populating the table will be the problem? Try running "top" in another window and type "M" to sory by memory use. Memory use of builing topology isn't a problem until ~ 1-3 million features? Try using v.external. What sort of features? areas? lines? points? 3D? Hamish From david.p.finlayson at gmail.com Mon Jun 12 06:11:24 2006 From: david.p.finlayson at gmail.com (David Finlayson) Date: Mon Jun 12 06:11:27 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: <20060612130316.46b82b0c.hamish_nospam@yahoo.com> References: <20060609004745.0e31b819.hamish_nospam@yahoo.com> <20060609214733.7ee57d12.hamish_nospam@yahoo.com> <20060609100945.GA8684@gdf-hannover.de> <20060612130316.46b82b0c.hamish_nospam@yahoo.com> Message-ID: I agree. I've got half an acre (hectre) of screen and I still can't keep the output windows where I can see it. I'm not sure if I have a solution. Maybe adding some tabs to the control panel on gis.m so that the output can be contained in the same tool? Personally, I like tools like Jedit that allow you to "latch" windows together so that they act and move together (and remember where they were put when you launch them next time). I don't like windows popping up all over the place in random locations. David On 6/11/06, Hamish wrote: > Jachym Cepicky wrote: > > The way currently gis.m is doing things are IMHO good, I just would > > not add another window on the destop. > > As it is, 4 to 5 windows for gis.m (incl. term and module GUI) is 2-3 > too many. > > > Hamish > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- David Finlayson From hamish_nospam at yahoo.com Mon Jun 12 06:10:36 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 12 06:15:14 2006 Subject: [GRASS-dev] Re: grass-dev Digest, Vol 2, Issue 19 In-Reply-To: References: <20060609201334.00c7a939.hamish_nospam@yahoo.com> Message-ID: <20060612161036.33d3e17d.hamish_nospam@yahoo.com> Hamish: > > 1) Get NVIZ working* on Fedora Core 5 then release GRASS 6.1.0 as a > > development snapshot. > > > > 2) see (1). Michael: > And working without x11. To clarify, GRASS 6.2 should have most features work without needing x11. GRASS 6.1.0 can and should be released as things are now. Hamish From hamish_nospam at yahoo.com Mon Jun 12 06:57:08 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 12 06:57:12 2006 Subject: [GRASS-dev] Proper formatting of input parameters for bash scripts In-Reply-To: <0E5A77B55A57D511BB3F0002A537C262064111BE@s5-dar-r1.nrn.nrcan.gc.ca> References: <0E5A77B55A57D511BB3F0002A537C262064111BE@s5-dar-r1.nrn.nrcan.gc.ca> Message-ID: <20060612165708.05ab5264.hamish_nospam@yahoo.com> Eric Patton wrote: > I'm trying to write a script that accepts either a delimited list for > input (like g.region rast=map1,map2,map3,...) or will interpret the > given input as a wildcard pattern if the appropriate flag is given > also. What is the syntax required when writing in bash to enable this > functionality? The script I'm writing uses r.patch in loop if a > wildcard pattern is given, otherwise it should accept single or > multiple-delimited lists of input rasters by default. Adding #% multiple : yes to the option def'n will "allow" multiple input names (for shell scripts this only really changes the help text I think) For patterns, use "g.mlist sep=, pat=$GIS_OPT_input" to parse the string. I don't know if using muliple+patterns will work on the same input line. Maybe some g.mlist enhancement is required for that. Hamish From glynn at gclements.plus.com Mon Jun 12 06:59:49 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jun 12 07:04:56 2006 Subject: [GRASS-dev] Re: [GRASS-user] Freetype fonts in gis.m In-Reply-To: <20060612152602.04cee950.hamish_nospam@yahoo.com> References: <0E5A77B55A57D511BB3F0002A537C262064111B6@s5-dar-r1.nrn.nrcan.gc.ca> <20060612152602.04cee950.hamish_nospam@yahoo.com> Message-ID: <17548.62661.239482.181201@cerise.gclements.plus.com> Hamish wrote: > Adding a d.font.freetype "cmd" to the gis.m command list will run, but > doesn't seem to have any effect on the rendering. You have to add it below the layer which draws the text (so that it is run first), and you have to force it to be executed, e.g. using the "Redraw all layers" button. If the layer containing the text is re-rendered but the d.font.freetype command is skipped because the layer hasn't changed, the text will use the default "romans" font instead. I'd suggest going through the d.* commands which use R_text() without setting an explicit font and adding font= options. However, first we should think about how to handle FreeType fonts. E.g. whether it's up to the application to figure out whether to use R_font() or R_font_freetype(), or whether the two should be merged. Personally, I favour the latter. On option is to have an explicit prefix on FreeType font names (e.g. "font=ft:luximr" will look for a FreeType font). Another is to try the name as a vector font first then as a FreeType font if that fails (or the reverse). Also, vector fonts have a fixed encoding, while FreeType fonts support a user-configurable encoding. [FWIW, 21 modules use R_text(), of which 6 also use R_font(), while the rest use the "current" font, which is a rather awkward concept within gis.m.] -- Glynn Clements From glynn at gclements.plus.com Mon Jun 12 07:17:20 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jun 12 07:17:28 2006 Subject: [GRASS-dev] Re: [GRASS-user] Freetype fonts in gis.m In-Reply-To: <20060612160644.419e3a3d.hamish_nospam@yahoo.com> References: <17545.54520.310610.425098@cerise.gclements.plus.com> <17546.7648.59177.6079@cerise.gclements.plus.com> <20060612160644.419e3a3d.hamish_nospam@yahoo.com> Message-ID: <17548.63712.3676.600706@cerise.gclements.plus.com> Hamish wrote: > > a) make a distinction between setting the font in a persistent manner > > (for d.font[.freetype]) and setting the font internally for a single > > client (e.g. "d.vect ... font=...", or the .F operator in d.text). > > > > b) modify modules which use R_text() to accept font= and charset= > > options to eliminate the need for d.font[.freetype] (which doesn't > > work well with command layers). > > Adding FONT or FTFONT to GISRC and having d.font[.freetype] modify that > via g.gisenv or equiv. is a good idea. Hacking in font= etc into > G_parser()* is a huge pain when you have multiple commands that draw > text and/or use d.redraw. I don't want to have to retype that for every > command, and I do want a consistent font between different decorations. > Just adding font= for the first d.* command is non-intuitive. > > * adding font= to every module that uses R_text() is just too ugly Regardless of having a configurable global font, any command which draws text should allow the user to specify a particular font for that command. Trying to use d.font[.freetype] with command layers in gis.m isn't practical. In any case, point a) has to be dealt with. The situation where a module setting a font for its own text changes the font used by subsequent modules isn't acceptable. However, one problem with the $GISRC approach is that the setting would be shared by all monitors, whereas currently each monitor can have a separate font. I'm not sure whether that behaviour needs to be preserved. -- Glynn Clements From glynn at gclements.plus.com Mon Jun 12 07:24:52 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jun 12 07:25:17 2006 Subject: [GRASS-dev] grass6.2? In-Reply-To: References: <17548.45868.591098.578758@cerise.gclements.plus.com> Message-ID: <17548.64164.181269.661186@cerise.gclements.plus.com> Michael Barton wrote: > I noted the difference because i.rectify reads from the current location and > writes to the location specified by i.target. Ah. That is something which its replacement shouldn't imitate. Reading from a different location or mapset is reasonable enough, but nothing should write outside of the current mapset. The case of r.in.gdal creating a new location is probably OK, but writing to an existing mapset (other than the current one) isn't. BTW, does i.rectify bother to lock the destination mapset? -- Glynn Clements From glynn at gclements.plus.com Mon Jun 12 07:34:24 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jun 12 07:34:28 2006 Subject: [GRASS-dev] 64bit image issues (WAS: Re: grass-dev Digest, Vol 2, Issue 19) In-Reply-To: <1150081044.2222.56.camel@devel> References: <20060609201334.00c7a939.hamish_nospam@yahoo.com> <1149936853.2222.22.camel@devel> <17547.49091.412676.127861@cerise.gclements.plus.com> <17548.2622.435238.584651@cerise.gclements.plus.com> <1150081044.2222.56.camel@devel> Message-ID: <17548.64736.998061.850635@cerise.gclements.plus.com> Brad Douglas wrote: > On Sun, 2006-06-11 at 13:19 +0100, Glynn Clements wrote: > > Glynn Clements wrote: > > > > > > Export to image formats are still broken (some segv(), some write bad > > > > data). Animation via ffmpeg 'works', but again, writes bad data. > > > > The 64bit data corruption and segv() issues needs to be fixed before 6.2 > > > > goes gold. I'll see if I can't hunt down and correct the segv()s this > > > > weekend. > > > > > > I'm looking into the OGSF image handling stuff right now. > > > > I've committed some changes which should fix the 64-bit issues in the > > image dumping code. > > Thank you! I now have complete images, not quadrants. High resolution > PPM still crashes, tho: > #0 0x00002aaab2612d6e in _mesa_GetIntegerv () > from /usr/lib64/dri/radeon_dri.so > #1 0x00002aaaaaad762d in gsd_getViewport (tmp=0xffc4b910, > num=0xffc4b900) > at gsd_prim.c:750 > #2 0x00002aaaaaac7276 in GS_zoom_setup (a=0x7fffffc4c64c, > b=0x7fffffc4c648, > c=0x7fffffc4c644, d=0x7fffffc4c640, maxx=0x7fffffc4c63c, > maxy=0x7fffffc4c638) at GS2.c:2395 Try the attached patch. -- Glynn Clements -------------- next part -------------- Index: lib/ogsf/GS2.c =================================================================== RCS file: /grassrepository/grass6/lib/ogsf/GS2.c,v retrieving revision 1.8 diff -u -r1.8 GS2.c --- lib/ogsf/GS2.c 31 Mar 2006 20:51:25 -0000 1.8 +++ lib/ogsf/GS2.c 12 Jun 2006 05:32:24 -0000 @@ -37,7 +37,7 @@ */ #define NVIZ_HACK 1 -int gsd_getViewport(GLint, GLint); +int gsd_getViewport(GLint *, GLint *); static int Surf_ID[MAX_SURFS]; static int Next_surf = 0; @@ -2392,7 +2392,7 @@ { GLint tmp[4]; GLint num[2]; - gsd_getViewport(&tmp, &num); + gsd_getViewport(tmp, num); *a = tmp[0]; *b = tmp[1]; *c = tmp[2]; From hamish_nospam at yahoo.com Mon Jun 12 07:48:15 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 12 07:49:11 2006 Subject: [GRASS-dev] $GISBASE/etc/run what does this do? In-Reply-To: <17548.39470.689654.16951@cerise.gclements.plus.com> References: <17547.50053.659286.168799@cerise.gclements.plus.com> <17548.39470.689654.16951@cerise.gclements.plus.com> Message-ID: <20060612174815.381e062d.hamish_nospam@yahoo.com> David wrote: > I'm not sure what to do with the signal catching in the Init.sh > script. I was going to look them up on Google and see what they do. http://www.everything2.com/index.pl?node_id=467946 Hamish From hamish_nospam at yahoo.com Mon Jun 12 07:58:09 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 12 07:58:14 2006 Subject: [GRASS-dev] [bug #4571] (grass) How can I fix GRASS_WISH? In-Reply-To: <20060611090528.BE4D41005C1@lists.intevation.de> References: <20060611090528.BE4D41005C1@lists.intevation.de> Message-ID: <20060612175809.627f30cd.hamish_nospam@yahoo.com> > this bug's URL: http://intevation.de/rt/webrt?serial_num=4571 > --------------------------------------------------------------------- > > Subject: How can I fix GRASS_WISH? > > In fedora 5 it keeps saying me that my environment is misconfigured, > it suggests to change GRASS_WISH. My wish it's to change it but I have > no idea how. Latest 6.1 can you post the exact error message? If "wish" itself doesn't exist you can set GRASS to look for it under another name with GRASS_WISH. see http://grass.ibiblio.org/grass61/manuals/html61_user/variables.html#enviro to set a custom "wish" put this line in ~/.grass.bashrc export GRASS_WISH=/usr/bin/wish8.4 The "wish" program is needed to generate Tcl/Tk GUI windows. see http://www.tcl.tk/man/tcl8.4/UserCmd/wish.htm Hamish From michael.barton at asu.edu Mon Jun 12 08:28:21 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Jun 12 08:28:27 2006 Subject: [GRASS-dev] Re: [GRASS-user] Freetype fonts in gis.m In-Reply-To: <17548.63712.3676.600706@cerise.gclements.plus.com> Message-ID: Maybe this is what you're all getting at, but it seems most logical to have a 'default' font that could be set by d.font* (putting it into GISRC seems logical too). And also having each d.* command that uses text have the ability to optionally set a font for that command. If the font is not set, it uses the default; if the font is set for a command, it overrides the default. There should be no need to rerun d.font* for each command. 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: Mon, 12 Jun 2006 06:17:20 +0100 > To: Hamish > Cc: , , > > Subject: Re: [GRASS-user] Freetype fonts in gis.m > > > Hamish wrote: > >>> a) make a distinction between setting the font in a persistent manner >>> (for d.font[.freetype]) and setting the font internally for a single >>> client (e.g. "d.vect ... font=...", or the .F operator in d.text). >>> >>> b) modify modules which use R_text() to accept font= and charset= >>> options to eliminate the need for d.font[.freetype] (which doesn't >>> work well with command layers). >> >> Adding FONT or FTFONT to GISRC and having d.font[.freetype] modify that >> via g.gisenv or equiv. is a good idea. Hacking in font= etc into >> G_parser()* is a huge pain when you have multiple commands that draw >> text and/or use d.redraw. I don't want to have to retype that for every >> command, and I do want a consistent font between different decorations. >> Just adding font= for the first d.* command is non-intuitive. >> >> * adding font= to every module that uses R_text() is just too ugly > > Regardless of having a configurable global font, any command which > draws text should allow the user to specify a particular font for that > command. Trying to use d.font[.freetype] with command layers in gis.m > isn't practical. > > In any case, point a) has to be dealt with. The situation where a > module setting a font for its own text changes the font used by > subsequent modules isn't acceptable. > > However, one problem with the $GISRC approach is that the setting > would be shared by all monitors, whereas currently each monitor can > have a separate font. I'm not sure whether that behaviour needs to be > preserved. > > -- > Glynn Clements From hamish_nospam at yahoo.com Mon Jun 12 08:30:06 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 12 08:31:06 2006 Subject: [GRASS-dev] New georectifying module in TclTk In-Reply-To: <20060611175933.b293dec9.werchowyna@epf.pl> References: <20060606223532.2b6ffaf9.hamish_nospam@yahoo.com> <20060607215127.50b03ea9.hamish_nospam@yahoo.com> <20060611175933.b293dec9.werchowyna@epf.pl> Message-ID: <20060612183006.273ef281.hamish_nospam@yahoo.com> Maciek Sieczka wrote: > > > It sounds like most of the issues can be avoided by using > > > i.rectify -c. > > > > that is my understanding. > > > > > What are the disadvantages of using the -c switch? > > > > you have to restart GRASS in the target location and set up the > > region by hand. Ok if you knew to project a v.in.region box first > > and can calculate your target resolution > > Could you say how to calculate it? 1) XY to meters: see "Introduction to GRASS software" by Markus Neteler, 1998 2nd ed., part VI, section 1.1.1 (p.27) 2) lat-lon to meters: 1852m per nautical mile 60 nautical miles per degree lat width of degree lon goes as cos(lat) so dist_m_ns = dist_deg * 1852*60 dist_m_ew = dist_deg * 1852*60 * cos(lat) and res_ns = dist/rows res_ew = dist/cols see also "g.region -e" Hamish From michael.barton at asu.edu Mon Jun 12 08:32:35 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Jun 12 08:34:15 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: Message-ID: > From: David Finlayson > Date: Sun, 11 Jun 2006 21:11:24 -0700 > To: Hamish > Cc: Jachym Cepicky , , > > Subject: Re: [GRASS-dev] Python GUI toolkits > > I agree. I've got half an acre (hectre) of screen and I still can't > keep the output windows where I can see it. I'm not sure if I have a > solution. Maybe adding some tabs to the control panel on gis.m so that > the output can be contained in the same tool? This has already been suggested. Simply a bit complicated to implement currently in TclTk because so much else is happening. But I just did a prototype wxPython/wxGlade GIS Manager with exactly this kind of configuration: tab for layer tree, tab for options, tab for console. It makes for a more compact display. > > Personally, I like tools like Jedit that allow you to "latch" windows > together so that they act and move together (and remember where they > were put when you launch them next time). I don't like windows popping > up all over the place in random locations. Sounds good, but I don't know how to do it. Maybe in the new system? 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 Mon Jun 12 08:47:59 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 12 08:48:07 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: References: <20060609004745.0e31b819.hamish_nospam@yahoo.com> <20060609214733.7ee57d12.hamish_nospam@yahoo.com> <20060609100945.GA8684@gdf-hannover.de> <20060612130316.46b82b0c.hamish_nospam@yahoo.com> Message-ID: <20060612184759.3095c66f.hamish_nospam@yahoo.com> > > Jachym Cepicky wrote: > > > The way currently gis.m is doing things are IMHO good, I just > > > would not add another window on the destop. Hamish: > > As it is, 4 to 5 windows for gis.m (incl. term and module GUI) is > > 2-3 too many. David: > I agree. I've got half an acre (hectre) of screen and I still can't > keep the output windows where I can see it. I'm not sure if I have a > solution. Maybe adding some tabs to the control panel on gis.m so that > the output can be contained in the same tool? > > Personally, I like tools like Jedit that allow you to "latch" windows > together so that they act and move together (and remember where they > were put when you launch them next time). I don't like windows popping > up all over the place in random locations. fyi, what I've done to make this less annoying for sawfish WM (Gnome) in Linux; place windows in 4 corners (new GUIs pop up in center): $ sawfish-ui [Matched Windows tab] Matches: Action: GIS Manager - position=(750 . 10) ^Map Display 1$ place-mode=top-left ^Output - GIS\.m$ place-mode=south-east-going-north ^rxvt$ [xterm] position=(35 . 605) In the past we tried to set placement automatically in the Tcl code, but Glynn explained it was bad to hard-code in placement -- or more to the point override a user's WM settings. Hamish From michael.barton at asu.edu Mon Jun 12 08:48:35 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Jun 12 08:49:20 2006 Subject: [GRASS-dev] Re: [GRASS-user] Freetype fonts in gis.m In-Reply-To: <17548.63712.3676.600706@cerise.gclements.plus.com> Message-ID: More generally, to make the d.* commands most efficiently useable from the command line and for scripting, it makes sense to add a font= option to all that need it. That is, d.legend by itself should be able to set which font it uses. It can already set everything else except the font. 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: Mon, 12 Jun 2006 06:17:20 +0100 > To: Hamish > Cc: , , > > Subject: Re: [GRASS-user] Freetype fonts in gis.m > > Regardless of having a configurable global font, any command which > draws text should allow the user to specify a particular font for that > command. Trying to use d.font[.freetype] with command layers in gis.m > isn't practical. From michael.barton at asu.edu Mon Jun 12 08:51:13 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Jun 12 08:51:26 2006 Subject: [GRASS-dev] grass6.2? In-Reply-To: <17548.64164.181269.661186@cerise.gclements.plus.com> Message-ID: Is there a reason to change i.rectify at some point so that it also will read from a different directory and write to the current one? This is how the georectifier works, but I have to switch back and forth between locations/mapsets to make i.rectify work. I have no idea about the locking. But probably not or I would have probably run into it like I did with g.mapset. 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: Mon, 12 Jun 2006 06:24:52 +0100 > To: Michael Barton > Cc: Helena Mitasova , Wolf Bergenheim > , , > Subject: Re: [GRASS-dev] grass6.2? > > > Michael Barton wrote: > >> I noted the difference because i.rectify reads from the current location and >> writes to the location specified by i.target. > > Ah. That is something which its replacement shouldn't imitate. > > Reading from a different location or mapset is reasonable enough, but > nothing should write outside of the current mapset. The case of > r.in.gdal creating a new location is probably OK, but writing to an > existing mapset (other than the current one) isn't. > > BTW, does i.rectify bother to lock the destination mapset? > > -- > Glynn Clements From jachym.cepicky at centrum.cz Mon Jun 12 09:04:28 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Mon Jun 12 09:05:21 2006 Subject: [GRASS-dev] Python GUI toolkits In-Reply-To: <20060612184759.3095c66f.hamish_nospam@yahoo.com> References: <20060609004745.0e31b819.hamish_nospam@yahoo.com> <20060609214733.7ee57d12.hamish_nospam@yahoo.com> <20060609100945.GA8684@gdf-hannover.de> <20060612130316.46b82b0c.hamish_nospam@yahoo.com> <20060612184759.3095c66f.hamish_nospam@yahoo.com> Message-ID: <20060612070427.GB32488@gdf-hannover.de> It can manage your window manager or your app. Personally I like the way, gaim does this job. It can use notebook for each chat session in one window, but you can allways drag&drop one tab and make new window out of it jachym On Mon, Jun 12, 2006 at 06:47:59PM +1200, Hamish wrote: > > > Jachym Cepicky wrote: > > > > The way currently gis.m is doing things are IMHO good, I just > > > > would not add another window on the destop. > Hamish: > > > As it is, 4 to 5 windows for gis.m (incl. term and module GUI) is > > > 2-3 too many. > David: > > I agree. I've got half an acre (hectre) of screen and I still can't > > keep the output windows where I can see it. I'm not sure if I have a > > solution. Maybe adding some tabs to the control panel on gis.m so that > > the output can be contained in the same tool? > > > > Personally, I like tools like Jedit that allow you to "latch" windows > > together so that they act and move together (and remember where they > > were put when you launch them next time). I don't like windows popping > > up all over the place in random locations. > > > fyi, what I've done to make this less annoying for sawfish WM (Gnome) in > Linux; place windows in 4 corners (new GUIs pop up in center): > > $ sawfish-ui > [Matched Windows tab] > Matches: Action: > GIS Manager - position=(750 . 10) > ^Map Display 1$ place-mode=top-left > ^Output - GIS\.m$ place-mode=south-east-going-north > ^rxvt$ [xterm] position=(35 . 605) > > > In the past we tried to set placement automatically in the Tcl code, but > Glynn explained it was bad to hard-code in placement -- or more to > the point override a user's WM settings. > > > > Hamish > > _______________________________________________ > 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/20060612/c6355254/attachment.bin From david.p.finlayson at gmail.com Mon Jun 12 09:08:37 2006 From: david.p.finlayson at gmail.com (David Finlayson) Date: Mon Jun 12 09:08:40 2006 Subject: [GRASS-dev] GRASS init.sh Message-ID: It seems to me that the GRASS initialization script is a lot more complicated than necessary. If I understand correctly, the script needs to do seven things: 1. Set the system environment variables (GISBASE, PATH, LD_LIBRARY_PATH, etc) 2. Set the user environment variables (GISDBASE, LOCATION_NAME, MAPSET, etc) 3. Create a temporary directory for processing 4. Copy .grassrc6 into the temporary directory for session use 5. Launch a Shell with the GRASS environment variables set 6. Copy the session grassrc file from temporary directory back to .grassrc6 7. Delete the temporary directory Seems straight forward until you take a look at the scripts involved. A few issues: 1. system-wide environment variables are embedded in two different scripts (grass61, $GISBASE/etc/init.sh) instead of in a (single) system-wide configuration file. 2. Many system-wide environment variables are determined at run-time by init.sh. This means that there is a lot of platform specific code looking for libraries and executables. Routines are different for each shell and each major platform. Surely there is a better way to do this? Maybe a configuration wizard that helps the user write or update their system-wide config file? 3. user environment variables are stored in two places $HOME/.grassrc6 and $HOME/.grass.$SHELL 4. Again, there is a lot of code in init.sh that tries to discover these user variables and if necessary query from the user (including a crude, text-based gui in the script itself). 5. Of course, this won't run at all on Windows without a full Unix emulation layer 6. It's written in sh, it looks like line noise. I see all of this mainly as an issue for making the code portable across platforms and execution environments (such as my IPython experiment). It would be easier to put configuration options in a configuration file and then have the various shells pick up the data using their available tools. I think that this would be much more portable and much simpler as well. -- David Finlayson From hamish_nospam at yahoo.com Mon Jun 12 09:20:34 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 12 09:20:41 2006 Subject: [GRASS-dev] [bug #4557] (grass) problem with v.surf.rst cross validation In-Reply-To: <20060611111748.C53481006A7@lists.intevation.de> References: <20060611111748.C53481006A7@lists.intevation.de> Message-ID: <20060612192034.5f679a03.hamish_nospam@yahoo.com> Maciek Sieczka wrote: > Indeed in Grass 6.0x for turning on the CV there is '-v'. In the newer > Grass 6.1, as Helena says, there is '-c'. > > Question for devs - is it good that we have the flags not preserved > between 6.0 and 6.1? It is bad - any scripts or Books written for GRASS 6.0 should work with any GRASS 6.x. If "-v" is obsolete it should be described as depreciated in the flag->description and trigger a G_warning() before setting "-c" to be true & then run the module as the user intended. Hamish From hamish_nospam at yahoo.com Mon Jun 12 09:23:41 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 12 09:23:50 2006 Subject: [GRASS-dev] Re: [GRASS-user] Freetype fonts in gis.m In-Reply-To: <17548.62661.239482.181201@cerise.gclements.plus.com> References: <0E5A77B55A57D511BB3F0002A537C262064111B6@s5-dar-r1.nrn.nrcan.gc.ca> <20060612152602.04cee950.hamish_nospam@yahoo.com> <17548.62661.239482.181201@cerise.gclements.plus.com> Message-ID: <20060612192341.1cc9b479.hamish_nospam@yahoo.com> > > Adding a d.font.freetype "cmd" to the gis.m command list will run, > > but doesn't seem to have any effect on the rendering. > > You have to add it below the layer which draws the text (so that it is > run first), and you have to force it to be executed, e.g. using the > "Redraw all layers" button. > > If the layer containing the text is re-rendered but the > d.font.freetype command is skipped because the layer hasn't changed, > the text will use the default "romans" font instead. ah, ok, d.font.freetype works as a gis.m "command layer" if I flush the image cache. thanks, Hamish From neteler at itc.it Mon Jun 12 09:34:23 2006 From: neteler at itc.it (Markus Neteler) Date: Mon Jun 12 09:34:25 2006 Subject: [GRASS-dev] grass6.2? In-Reply-To: References: <17548.64164.181269.661186@cerise.gclements.plus.com> Message-ID: <20060612073422.GA18664@bartok.itc.it> Michael, just curious: do you intend to also include the new developments: - homology based rectification with lines - Fourier correlation based auto search of GCPs ? See: http://grass.itc.it/pipermail/grass-dev/2006-March/022051.html for link to the source code. Markus On Sun, Jun 11, 2006 at 11:51:13PM -0700, Michael Barton wrote: > Is there a reason to change i.rectify at some point so that it also will > read from a different directory and write to the current one? This is how > the georectifier works, but I have to switch back and forth between > locations/mapsets to make i.rectify work. > > I have no idea about the locking. But probably not or I would have probably > run into it like I did with g.mapset. > > 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 rez at touchofmadness.com Mon Jun 12 09:41:14 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Mon Jun 12 09:41:23 2006 Subject: [GRASS-dev] 64bit image issues (WAS: Re: grass-dev Digest, Vol 2, Issue 19) In-Reply-To: <17548.64736.998061.850635@cerise.gclements.plus.com> References: <20060609201334.00c7a939.hamish_nospam@yahoo.com> <1149936853.2222.22.camel@devel> <17547.49091.412676.127861@cerise.gclements.plus.com> <17548.2622.435238.584651@cerise.gclements.plus.com> <1150081044.2222.56.camel@devel> <17548.64736.998061.850635@cerise.gclements.plus.com> Message-ID: <1150098074.2222.69.camel@devel> On Mon, 2006-06-12 at 06:34 +0100, Glynn Clements wrote: > Brad Douglas wrote: > > On Sun, 2006-06-11 at 13:19 +0100, Glynn Clements wrote: > > > Glynn Clements wrote: > > > > > > > > Export to image formats are still broken (some segv(), some write bad > > > > > data). Animation via ffmpeg 'works', but again, writes bad data. > > > > > The 64bit data corruption and segv() issues needs to be fixed before 6.2 > > > > > goes gold. I'll see if I can't hunt down and correct the segv()s this > > > > > weekend. > > > > > > > > I'm looking into the OGSF image handling stuff right now. > > > > > > I've committed some changes which should fix the 64-bit issues in the > > > image dumping code. > > > > Thank you! I now have complete images, not quadrants. High resolution > > PPM still crashes, tho: > > #0 0x00002aaab2612d6e in _mesa_GetIntegerv () > > from /usr/lib64/dri/radeon_dri.so > > #1 0x00002aaaaaad762d in gsd_getViewport (tmp=0xffc4b910, > > num=0xffc4b900) > > at gsd_prim.c:750 > > #2 0x00002aaaaaac7276 in GS_zoom_setup (a=0x7fffffc4c64c, > > b=0x7fffffc4c648, > > c=0x7fffffc4c644, d=0x7fffffc4c640, maxx=0x7fffffc4c63c, > > maxy=0x7fffffc4c638) at GS2.c:2395 > > Try the attached patch. > > plain text document attachment (GS_zoom_setup.diff), "GS_zoom_setup > 64-bit patch" > Index: lib/ogsf/GS2.c > =================================================================== > RCS file: /grassrepository/grass6/lib/ogsf/GS2.c,v > retrieving revision 1.8 > diff -u -r1.8 GS2.c > --- lib/ogsf/GS2.c 31 Mar 2006 20:51:25 -0000 1.8 > +++ lib/ogsf/GS2.c 12 Jun 2006 05:32:24 -0000 > @@ -37,7 +37,7 @@ > */ > #define NVIZ_HACK 1 > > -int gsd_getViewport(GLint, GLint); > +int gsd_getViewport(GLint *, GLint *); > > static int Surf_ID[MAX_SURFS]; > static int Next_surf = 0; > @@ -2392,7 +2392,7 @@ > { > GLint tmp[4]; > GLint num[2]; > - gsd_getViewport(&tmp, &num); > + gsd_getViewport(tmp, num); > *a = tmp[0]; > *b = tmp[1]; > *c = tmp[2]; Although, I still cannot create high resolution PPM images, this is the right thing to do (no longer segv()s and I added some temp debug code to check the validity of the returned values). Please commit. FYI, it is exiting with status 01 and I can only assume the error has nothing to do with GRASS (looks like the xorg GLX module needs work?): % Creating PBuffer Using GLX 1.3 X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 21 Current serial number in output stream: 22 -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From hamish_nospam at yahoo.com Mon Jun 12 10:06:09 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 12 10:06:56 2006 Subject: [GRASS-dev] Re: [GRASS-user] Freetype fonts in gis.m In-Reply-To: References: <17548.63712.3676.600706@cerise.gclements.plus.com> Message-ID: <20060612200609.7df5d83c.hamish_nospam@yahoo.com> [might as well move this off the -user list] Michael Barton wrote: > More generally, to make the d.* commands most efficiently useable from > the command line and for scripting, it makes sense to add a font= > option to all that need it. That is, d.legend by itself should be able > to set which font it uses. It can already set everything else except > the font. The question remains how to easily retain a font setting if the display monitors will be stateless. From the command line having to retype it for every module is highly annoying. Right now I just need to set my TTF font once per session. * I want to be able to set a default font. (optionally TTF) * I want to keep the modules as simple as possible. (e.g. d.vect+new user) fyi, Matlab's way: [each is a child of the one above] "root" has certain settings (CLI and system wide settings) (More = off, ScreenDepth = [24], Children =, etc) then "figure" windows have their settings (DoubleBuffer = on, PaperType = a4, MenuBar =, Position =, Children =, ...) then "axes" have their settings (GridLineStyle =, Title =, XTickLabel =, Projection = orthographic, Children =, ...) then "lines" [etc] have their settings (Color =, LineStyle =, LineWidth =, Data = [X Y], ...) each level has a pointer you can get() or set() features with. e.g. root is 0, figure1 is 1, figure2 is 2, etc. maybe a useful paradigm to consider, as the two programs are structurally very similar creatures. Hamish From michael.barton at asu.edu Mon Jun 12 10:09:31 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Jun 12 10:09:38 2006 Subject: [GRASS-dev] Re: [GRASS-user] Freetype fonts in gis.m In-Reply-To: <20060612200609.7df5d83c.hamish_nospam@yahoo.com> Message-ID: You should also be able to set a 'default' font. The font= argument should be optional. If left out of the command, it defaults to the default font. The default font could be set (as now) with d.font* Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Hamish > Date: Mon, 12 Jun 2006 20:06:09 +1200 > To: Michael Barton > Cc: , > Subject: Re: [GRASS-user] Freetype fonts in gis.m > > [might as well move this off the -user list] > > Michael Barton wrote: >> More generally, to make the d.* commands most efficiently useable from >> the command line and for scripting, it makes sense to add a font= >> option to all that need it. That is, d.legend by itself should be able >> to set which font it uses. It can already set everything else except >> the font. > > The question remains how to easily retain a font setting if the display > monitors will be stateless. From the command line having to retype it > for every module is highly annoying. Right now I just need to set my TTF > font once per session. > > * I want to be able to set a default font. (optionally TTF) > * I want to keep the modules as simple as possible. (e.g. d.vect+new user) > > > > fyi, Matlab's way: [each is a child of the one above] > > "root" has certain settings (CLI and system wide settings) > (More = off, ScreenDepth = [24], Children =, etc) > > then > "figure" windows have their settings > (DoubleBuffer = on, PaperType = a4, MenuBar =, Position =, Children =, ...) > > then > "axes" have their settings > (GridLineStyle =, Title =, XTickLabel =, Projection = orthographic, Children > =, ...) > > then > "lines" [etc] have their settings > (Color =, LineStyle =, LineWidth =, Data = [X Y], ...) > > > each level has a pointer you can get() or set() features with. e.g. root > is 0, figure1 is 1, figure2 is 2, etc. > > > maybe a useful paradigm to consider, as the two programs are > structurally very similar creatures. > > > Hamish From glynn at gclements.plus.com Mon Jun 12 10:08:24 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jun 12 10:10:42 2006 Subject: [GRASS-dev] grass6.2? In-Reply-To: References: <17548.64164.181269.661186@cerise.gclements.plus.com> Message-ID: <17549.8440.776520.784930@cerise.gclements.plus.com> Michael Barton wrote: > >> I noted the difference because i.rectify reads from the current location and > >> writes to the location specified by i.target. > > > > Ah. That is something which its replacement shouldn't imitate. I had forgotten that i.rectify itself doesn't need replacing, only i.points. > > Reading from a different location or mapset is reasonable enough, but > > nothing should write outside of the current mapset. The case of > > r.in.gdal creating a new location is probably OK, but writing to an > > existing mapset (other than the current one) isn't. > > > > BTW, does i.rectify bother to lock the destination mapset? > > Is there a reason to change i.rectify at some point so that it also will > read from a different directory and write to the current one? This is how > the georectifier works, but I have to switch back and forth