From michael.barton at asu.edu Wed Aug 1 01:56:16 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Aug 1 01:56:30 2007 Subject: [GRASS-dev] question about any July changes in hydrology functions Message-ID: Beginning sometime in the 1st half of July, we?ve started getting some weird artifacts in surface process models that we?ve been developing using r.flow, r.slop.aspect, and r.mapcalc. The results are linear zones of deposits that seem to follow cell grid lines. This wasn?t happening previous to early July. We?ve scouring our scripts and so far can?t find anything to account for this changed behavior. It acts like some kind of dynamic resolution change artifact, but we are not doing anything to cause this AFAICT. It is probably something squirrelly in our scripts that we just haven?t seen. But I thought I go for a long shot and ask if there have been any changes that might affect the behavior of r.flow or r.slope.aspect recently. I didn?t see anything obvious in the commit list archives, but may have missed a library change of some kind. Thanks Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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/20070731/b8ad1795/attachment.html From paul-grass at stjohnspoint.co.uk Wed Aug 1 01:56:31 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Wed Aug 1 01:56:42 2007 Subject: [GRASS-dev] d.font -l: please sort alphabetically In-Reply-To: <28309.58031.qm@web52712.mail.re2.yahoo.com> References: <28309.58031.qm@web52712.mail.re2.yahoo.com> Message-ID: On Sun, 29 Jul 2007, Hamish wrote: > Paul mentioned that the stroke fonts have no long description. It would be nice > if someone could write those and insert somehow as their names can be a little > cryptic. Another nice idea is to write a little d.font && d.text script that > demonstrates what those all look like and post it + a screenshot of the result > to the wiki. (sorry can't help, I'm supposed to be AWOL right now) I've written a short Perl script (see attached) that sort of does that. It would be nice to refine it and make it automatically create multiple PNG files or something like that. At the minute probably best to run it with large resolution PNG output, then resample to a lower resolution and split into pieces before putting on display anywhere. Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: show.fonts.pl Type: text/x-perl Size: 605 bytes Desc: Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070801/08e4c579/show.fonts.bin From glynn at gclements.plus.com Wed Aug 1 09:31:22 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Aug 1 09:31:54 2007 Subject: [GRASS-dev] question about any July changes in hydrology functions In-Reply-To: References: Message-ID: <18096.14026.701901.897681@cerise.gclements.plus.com> Michael Barton wrote: > Beginning sometime in the 1st half of July, we?ve started getting some weird > artifacts in surface process models that we?ve been developing using r.flow, > r.slop.aspect, and r.mapcalc. The results are linear zones of deposits that > seem to follow cell grid lines. This wasn?t happening previous to early > July. We?ve scouring our scripts and so far can?t find anything to account > for this changed behavior. It acts like some kind of dynamic resolution > change artifact, but we are not doing anything to cause this AFAICT. > > It is probably something squirrelly in our scripts that we just haven?t > seen. But I thought I go for a long shot and ask if there have been any > changes that might affect the behavior of r.flow or r.slope.aspect recently. > I didn?t see anything obvious in the commit list archives, but may have > missed a library change of some kind. $ cvs diff -D 2007-07-01 -D 2007-07-15 raster/r.mapcalc raster/r.slope.aspect raster/r.flow cvs server: Diffing raster/r.mapcalc cvs server: Diffing raster/r.slope.aspect cvs server: Diffing raster/r.flow Assuming that your dates are correct, it isn't the programs. Extending the comparison to lib/{gis,vector,bitmap,btree,rowio,segment} (the only libraries which those programs use directly) doesn't show anything which looks remotely relevant. I can only suggest checking out and compiling "before" and "after" versions, and examining any intermediate data produced by your scripts. -- Glynn Clements From wichmann at laserdata.at Wed Aug 1 13:31:54 2007 From: wichmann at laserdata.at (vwichmann) Date: Wed Aug 1 13:31:57 2007 Subject: [GRASS-dev] [grass-code I][431] g.copy segmentation fault In-Reply-To: <46A98E2D.5010000@laserdata.at> References: <20070620135314.9534A40FB3@pyrosoma.intevation.org> <46810AD4.4080905@o2.pl> <46A07996.7040300@laserdata.at> <46A44D73.9050908@laserdata.at> <18084.55455.521934.169287@cerise.gclements.plus.com> <46A5F668.1000903@laserdata.at> <18086.22872.250450.40350@cerise.gclements.plus.com> <46A6FA2C.2090509@laserdata.at> <18087.44200.396477.767347@cerise.gclements.plus.com> <46A85192.8050708@laserdata.at> <18089.1673.583722.407646@cerise.gclements.plus.com> <46A98E2D.5010000@laserdata.at> Message-ID: <11943808.post@talk.nabble.com> Glynn Clements wrote: >>> It might help if you re-compile the general/manage directory without >>> optimisation, e.g.: >>> >>> make -C general/manage clean >>> make -C general/manage CFLAGS1='-g' >>> >>> That will certainly make it easier to debug; OTOH, it might simply >>> make the bug disappear. >>> ... just as a follow up: discussion off-list showed that this solved the problem for several people who encountered this error too. Volker -- View this message in context: http://www.nabble.com/-grass-code-I--431--g.copy-segmentation-fault-tf3952533.html#a11943808 Sent from the Grass - Dev mailing list archive at Nabble.com. From michael.barton at asu.edu Wed Aug 1 17:06:40 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Aug 1 17:07:00 2007 Subject: [GRASS-dev] question about any July changes in hydrology functions In-Reply-To: <18096.14026.701901.897681@cerise.gclements.plus.com> Message-ID: Thanks Glynn, We've been diffing our scripts to the extent possible--i.e., once we started committing them to the SVN and haven't found anything obvious yet. Helena also mentioned r.neighbors as a possible culprit, as I'd forgotten to mention that we also use this to smooth results. Michael On 8/1/07 12:31 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> Beginning sometime in the 1st half of July, we?ve started getting some weird >> artifacts in surface process models that we?ve been developing using r.flow, >> r.slop.aspect, and r.mapcalc. The results are linear zones of deposits that >> seem to follow cell grid lines. This wasn?t happening previous to early >> July. We?ve scouring our scripts and so far can?t find anything to account >> for this changed behavior. It acts like some kind of dynamic resolution >> change artifact, but we are not doing anything to cause this AFAICT. >> >> It is probably something squirrelly in our scripts that we just haven?t >> seen. But I thought I go for a long shot and ask if there have been any >> changes that might affect the behavior of r.flow or r.slope.aspect recently. >> I didn?t see anything obvious in the commit list archives, but may have >> missed a library change of some kind. > > $ cvs diff -D 2007-07-01 -D 2007-07-15 raster/r.mapcalc raster/r.slope.aspect > raster/r.flow > cvs server: Diffing raster/r.mapcalc > cvs server: Diffing raster/r.slope.aspect > cvs server: Diffing raster/r.flow > > Assuming that your dates are correct, it isn't the programs. Extending > the comparison to lib/{gis,vector,bitmap,btree,rowio,segment} (the > only libraries which those programs use directly) doesn't show > anything which looks remotely relevant. > > I can only suggest checking out and compiling "before" and "after" > versions, and examining any intermediate data produced by your > scripts. __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 at gclements.plus.com Thu Aug 2 04:34:05 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Aug 2 04:34:11 2007 Subject: [GRASS-dev] question about any July changes in hydrology functions In-Reply-To: References: <18096.14026.701901.897681@cerise.gclements.plus.com> Message-ID: <18097.17053.866339.91699@cerise.gclements.plus.com> Michael Barton wrote: > Helena also mentioned r.neighbors as a possible culprit, as I'd forgotten to > mention that we also use this to smooth results. Neither r.neighbors or lib/stats changed during the first half of July. -- Glynn Clements From michael.barton at asu.edu Thu Aug 2 05:39:35 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Aug 2 05:39:54 2007 Subject: [GRASS-dev] question about any July changes in hydrology functions In-Reply-To: <18097.17053.866339.91699@cerise.gclements.plus.com> Message-ID: Tests over the last couple days suggest that r.neighbors may be the, or one of, the causes. We lose most of the artifacts if we turn off smoothing using r.neighbors, and the artifacts are much worse with a neighborhood of 7x7 than 3x3. We're probably wrong about the date, however. This seems to only show up clearly in very long runs (a simulation of 50 recursive models) and is most pronounced with larger smoothing neighborhoods. Previously we'd done a small neighborhood of 3x3 and done most of our tests for no more than 10 iterations. We only did a couple of long ones and were looking more at stats from the output than the maps themselves. Now we are doing a number of 50+ iteration runs (the most recent one ran for nearly 600 years simulated time). using a median smoother gives much worse results than a mean smoother, though a median ought to be better the larger the neighborhood is, since it should not be affected as much by extreme values. Our next test it to find out if there is some kind of issue with region setting that is interacting with the smoothing. Probably not, but we need to make sure. I'll report more later after. If anyone is interested in seeing what I've tried to describe, I've posted images of the effects of different smoothing parameters at: Michael On 8/1/07 7:34 PM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> Helena also mentioned r.neighbors as a possible culprit, as I'd forgotten to >> mention that we also use this to smooth results. > > Neither r.neighbors or lib/stats changed during the first half of July. __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hmitaso at unity.ncsu.edu Thu Aug 2 07:24:48 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Thu Aug 2 07:24:54 2007 Subject: [GRASS-dev] question about any July changes in hydrology functions In-Reply-To: References: Message-ID: <7FF04607-7942-478E-8898-B096F55F6D34@unity.ncsu.edu> That is what I call a gridding effect - check it out here - and this was done only with simwe and r.mapcalc - no r.flow, r.neighbors, etc. (some of the problem actually may be hidden in r.mapcalc computations) http://skagit.meas.ncsu.edu/~helena/gmslab/oxfordms/oxf.html you can see how it evolves here (you start seeing it after several iterations - it is there from the start but it is small at the beginning and just grows over time until you start seeing it) http://skagit.meas.ncsu.edu/~helena/gmslab/oxfordms/eledhedge.gif I thought that smoothing will take care of it but apparently just the opposite We need to find out what to do about it - I think that it is more related to the modeling approach than GRASS itself, BTW as I understand it median is computed by dividing the values into a finite number of classes so the median from a continuous field would not change continuously from cell to cell and the effect you are getting could be expected especially for larger number of cells. Mean is computed directly from the floating point values - is that right? 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 Aug 1, 2007, at 11:39 PM, Michael Barton wrote: > Tests over the last couple days suggest that r.neighbors may be > the, or one > of, the causes. We lose most of the artifacts if we turn off > smoothing using > r.neighbors, and the artifacts are much worse with a neighborhood > of 7x7 > than 3x3. > > We're probably wrong about the date, however. This seems to only > show up > clearly in very long runs (a simulation of 50 recursive models) and > is most > pronounced with larger smoothing neighborhoods. Previously we'd > done a small > neighborhood of 3x3 and done most of our tests for no more than 10 > iterations. We only did a couple of long ones and were looking more > at stats > from the output than the maps themselves. Now we are doing a number > of 50+ > iteration runs (the most recent one ran for nearly 600 years simulated > time). > > using a median smoother gives much worse results than a mean smoother, > though a median ought to be better the larger the neighborhood is, > since it > should not be affected as much by extreme values. > > Our next test it to find out if there is some kind of issue with > region > setting that is interacting with the smoothing. Probably not, but > we need to > make sure. > > I'll report more later after. If anyone is interested in seeing > what I've > tried to describe, I've posted images of the effects of different > smoothing > parameters at: > > > > Michael > > > > On 8/1/07 7:34 PM, "Glynn Clements" wrote: > >> >> Michael Barton wrote: >> >>> Helena also mentioned r.neighbors as a possible culprit, as I'd >>> forgotten to >>> mention that we also use this to smooth results. >> >> Neither r.neighbors or lib/stats changed during the first half of >> July. > > __________________________________________ > Michael Barton, Professor of Anthropology > Director of Graduate Studies > 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 michael.barton at asu.edu Thu Aug 2 07:46:45 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Aug 2 07:47:00 2007 Subject: [GRASS-dev] question about any July changes in hydrology functions In-Reply-To: <7FF04607-7942-478E-8898-B096F55F6D34@unity.ncsu.edu> Message-ID: On 8/1/07 10:24 PM, "Helena Mitasova" wrote: > That is what I call a gridding effect - > check it out here - and this was done only with simwe and r.mapcalc > - no r.flow, r.neighbors, etc. > (some of the problem actually may be hidden in r.mapcalc computations) > > http://skagit.meas.ncsu.edu/~helena/gmslab/oxfordms/oxf.html > > you can see how it evolves here (you start seeing it after several > iterations - it is there from the start > but it is small at the beginning and just grows over time until you > start seeing it) > > http://skagit.meas.ncsu.edu/~helena/gmslab/oxfordms/eledhedge.gif These displays match what we are getting. Apparently, this only begins to show up with long, recursive simulations. One characteristic of recursive cellular automata simulations, of course, is emergent patterns that are not easily predicted by the original processes--including cascades of deviation amplifying effects. I didn't expect this to pop up in this part of our simulation, but in retrospect, it is not all that surprising. But is is annoying and we'll have to correct it somehow. > > I thought that smoothing will take care of it but apparently just the > opposite This does seem strange. Even odder is the fact that the anomalies get bigger the larger the smoothing neighborhood. Usually, increasing the neighborhood creates greater smoothing. It might be the way we are using smoothing. We check to see if an erosion/deposition value exceeds the smoothed value by some user-determined amount. It is does, the smoothed value is used instead of the original value. The goal was to get rid of extreme values but leave the rest alone. Perhaps we should just use the smoothed value for all cells instead of just extreme ones. > We need to find out what to do about it - I think that > it is more related to the modeling approach than GRASS itself, > Is this perhaps a function of dx and dy calculations? > BTW as I understand it median is computed by dividing the values into > a finite number of classes > so the median from a continuous field would not change continuously > from cell to cell and > the effect you are getting could be expected especially for larger > number of cells. I don't know how r.neighbors computes the median. However, it is supposed to be a value such that half the neighbor cells have larger values and half have smaller values. I would have thought that the way to compute would be to order the neighborhood values from smallest to largest and find the middle. Since the neighborhood is always an odd number, the middle is always a single cell. > Mean is computed directly from the floating point values - is that > right? This ought to be the sum of the neighbor cell values divided by the number of cells. The median is less affected by a single extreme cell than the mean, which is why we preferred the median. However, if the median calculation algorithm is problematic, then we'll have to switch to the mean. Thanks for looking at this. I'll be very interested to hear any further ideas you have. Michael > > 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 Aug 1, 2007, at 11:39 PM, Michael Barton wrote: > >> Tests over the last couple days suggest that r.neighbors may be >> the, or one >> of, the causes. We lose most of the artifacts if we turn off >> smoothing using >> r.neighbors, and the artifacts are much worse with a neighborhood >> of 7x7 >> than 3x3. >> >> We're probably wrong about the date, however. This seems to only >> show up >> clearly in very long runs (a simulation of 50 recursive models) and >> is most >> pronounced with larger smoothing neighborhoods. Previously we'd >> done a small >> neighborhood of 3x3 and done most of our tests for no more than 10 >> iterations. We only did a couple of long ones and were looking more >> at stats >> from the output than the maps themselves. Now we are doing a number >> of 50+ >> iteration runs (the most recent one ran for nearly 600 years simulated >> time). >> >> using a median smoother gives much worse results than a mean smoother, >> though a median ought to be better the larger the neighborhood is, >> since it >> should not be affected as much by extreme values. >> >> Our next test it to find out if there is some kind of issue with >> region >> setting that is interacting with the smoothing. Probably not, but >> we need to >> make sure. >> >> I'll report more later after. If anyone is interested in seeing >> what I've >> tried to describe, I've posted images of the effects of different >> smoothing >> parameters at: >> >> >> >> Michael >> >> >> >> On 8/1/07 7:34 PM, "Glynn Clements" wrote: >> >>> >>> Michael Barton wrote: >>> >>>> Helena also mentioned r.neighbors as a possible culprit, as I'd >>>> forgotten to >>>> mention that we also use this to smooth results. >>> >>> Neither r.neighbors or lib/stats changed during the first half of >>> July. >> >> __________________________________________ >> Michael Barton, Professor of Anthropology >> Director of Graduate Studies >> 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 >> >> > __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 neteler at itc.it Thu Aug 2 09:32:42 2007 From: neteler at itc.it (Markus Neteler) Date: Thu Aug 2 09:32:45 2007 Subject: [GRASS-dev] d.out.file and d.font issue In-Reply-To: <18095.31474.490428.345203@cerise.gclements.plus.com> References: <11863084.post@talk.nabble.com> <18094.47636.231094.41039@cerise.gclements.plus.com> <11919720.post@talk.nabble.com> <18094.64776.775542.754988@cerise.gclements.plus.com> <11923092.post@talk.nabble.com> <18095.31474.490428.345203@cerise.gclements.plus.com> Message-ID: <11959778.post@talk.nabble.com> Glynn Clements wrote: > > Markus Neteler wrote: > >> > If you are looking for a quick fix to this specific problem, it would >> > be simpler to just remove the D_clear_window() call from d.rast. > >> Great suggestion: > >> Now d.out.file keeps the d.font settings. >> Any objections to submit this to CVS? > > Not from me. > > -- > Glynn Clements > I think that a few commands need a modification then (D_full_screen()?) to perform also frame removal: - d.profile - d.histogram - more? No big deal, though. Markus -- View this message in context: http://www.nabble.com/d.out.file-and-d.font-issue-tf4169926.html#a11959778 Sent from the Grass - Dev mailing list archive at Nabble.com. From mlennert at club.worldonline.be Thu Aug 2 10:02:37 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Aug 2 10:01:00 2007 Subject: [GRASS-dev] Re: [GRASS-user] How can I find average/maximum raster values within a vector area? In-Reply-To: References: <7e879ea0708011343o2699a5d6qf2db4d67b8bccdf@mail.gmail.com> Message-ID: <46B18F9D.7000709@club.worldonline.be> On 02/08/07 06:59, David Finlayson wrote: > Forgot to CC grass list > > On 8/1/07, David Finlayson wrote: >> I think you want the command r.statistics. You will need to convert >> your administrative areas vector map into a raster map where each area >> has a unique ID. Then run r.statistics on the pollution map using the >> administrative areas raster as the cover. This tool builds a database >> table with the min,max avg, etc statistics of pollution for each area >> id. How difficult would it be to create a module 'v.statistics' which would skip the step of converting the cover to raster ? Moritz From paul-grass at stjohnspoint.co.uk Thu Aug 2 12:26:44 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Thu Aug 2 12:26:51 2007 Subject: [GRASS-dev] Re: v.path.obstacles In-Reply-To: <46A8E263.1080304@bergenheim.net> References: <1185306826.8290.11.camel@dev64.localdomain> <20070724203521.GD15606@bartok.itc.it> <46A8E263.1080304@bergenheim.net> Message-ID: On Thu, 26 Jul 2007, Wolf Bergenheim wrote: > v.path.obstacles: > ~~~~~~~~~~~~~~~~~ > This module creates a visibility graph from non-intersecting lines and > boundaries. It is actually remarkably fast. This output vector map can > be used with graph analysis modules like v.net.path to find the shortest > path between point A and B in free vector space. This project is in a > testable shape. Not everything works perfectly yet, but Maximilian is > actively working on it. We could use some feedback so if you are > interested in this functionality, please try it out, and let us know > what you think. > Maximilian also brought up the issue that perhaps this module should be > renamed to v.net.visibility. Any comments? Hello Wolf and Maximilian, As promised I have just had a chance to try this - I too am impressed by how fast it ran - however, it seems to be lacking a facility for entering the desired start and finish points that the shortest path should be found between - as far as I can see these need to also be included in the visiblity graph for it to work properly? I suppose you could manually add them to the obstacles map before starting, but people might not want to have to edit it. Hmmm I'm not sure. Nice idea it seems actually keeping the visiblity graph generation out as a separate module - I guess that is just the logical way the idea developed in the end? And then you could write a shell script to run this module (v.net.visiblity sounds like a logical name) to generate a temporary map and then run other v.net.* modules on it to generate the shortest path. Have you any ideas/scenarios for how you think it might eventually be used like this? A couple of comments on the code itself - I think it could do with being compiled with -Wall being added to the EXTRA_CFLAGS to catch compiler warnings, of which there are currently quite a lot. It seems to be the general GRASS style to keep function prototypes for functions that are not local to one file in a separate local_proto.h. Also the indentation, in main.c anyway where I was reading, is quite inconsistent and makes it a bit hard to read. There is a suggested set of commandline switches for the "indent" command in the GRASS SUBMITTING file (top level directory in CVS) - I'd suggest using this on the source files before they're committed to CVS. But in general, looks good and seems to be quite useful. I would suggest the example in the man page should show how it can be used in combination with one of the other v.net.* commands - this wasn't obvious to me at all at the start. Best regards Paul From grass-dev at grass.itc.it Wed Aug 1 13:21:06 2007 From: grass-dev at grass.itc.it (grass-dev@grass.itc.it) Date: Thu Aug 2 12:38:16 2007 Subject: [GRASS-dev] [grass-code I][451] "place with mouse" gets confused when placing several different layers Message-ID: <20070801112106.2A6E540132@pyrosoma.intevation.org> code I item #451, was opened at 2007-08-01 13:21 Status: Open Priority: 3 Submitted By: Moritz Lennert (moritz) Assigned to: Nobody (None) Summary: "place with mouse" gets confused when placing several different layers Issue type: module bug Issue status: None GRASS version: CVS HEAD GRASS component: tcl/tk GUI Operating system: Linux Operating system version: Debian Etch GRASS CVS checkout date, if applies (YYMMDD): 070801 Initial Comment: The "place with mouse" option in the tcl/tk GUI seems to get confused when placing several different types of layers. 1) Place a text with the mouse, then place a ps-text with the mouse. If you then select the text-layer again and replace it with the mouse, it disappears. 2) Place a ps-text with the mouse, then place a text with the mouse. If you then select the ps-text layer againg and replace it with the mouse, it will appear at the wrong place. 3) Place a text, then place a scalebar. When you select the text again and try to place it, the following error appears. The same (or very similar) happens with different combinations of scalebar and text or ps-text. invalid command name ".mainframe.frame.pw1.f1.frame.sw.sf.frame.fr.at2.b" invalid command name ".mainframe.frame.pw1.f1.frame.sw.sf.frame.fr.at2.b" while executing "$pctentry delete 0 end" invoked from within "if { $pctentry != "" } { $pctentry delete 0 end $pctentry insert 0 "$xpct,$ypct" # object placement marker $mapdisp create line 167 [expr ..." (command bound to event) Moritz ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=451&group_id=21 From neteler at itc.it Thu Aug 2 12:43:48 2007 From: neteler at itc.it (Markus Neteler) Date: Thu Aug 2 12:43:51 2007 Subject: [GRASS-dev] Parallelized raster computing: using r.li.daemon code? Message-ID: <11962114.post@talk.nabble.com> Hi, I wonder if the r.li.daemon code could be moved up to (some) library level to use parallelization whereever possible. Since the code is there and seems to work... Markus -- View this message in context: http://www.nabble.com/Parallelized-raster-computing%3A-using-r.li.daemon-code--tf4205362.html#a11962114 Sent from the Grass - Dev mailing list archive at Nabble.com. From glynn at gclements.plus.com Thu Aug 2 13:47:49 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Aug 2 13:47:54 2007 Subject: [GRASS-dev] question about any July changes in hydrology functions In-Reply-To: References: <18097.17053.866339.91699@cerise.gclements.plus.com> Message-ID: <18097.50277.882635.792629@cerise.gclements.plus.com> Michael Barton wrote: > Tests over the last couple days suggest that r.neighbors may be the, or one > of, the causes. We lose most of the artifacts if we turn off smoothing using > r.neighbors, and the artifacts are much worse with a neighborhood of 7x7 > than 3x3. > > We're probably wrong about the date, however. This seems to only show up > clearly in very long runs (a simulation of 50 recursive models) and is most > pronounced with larger smoothing neighborhoods. Previously we'd done a small > neighborhood of 3x3 and done most of our tests for no more than 10 > iterations. We only did a couple of long ones and were looking more at stats > from the output than the maps themselves. Now we are doing a number of 50+ > iteration runs (the most recent one ran for nearly 600 years simulated > time). > > using a median smoother gives much worse results than a mean smoother, > though a median ought to be better the larger the neighborhood is, since it > should not be affected as much by extreme values. The nonlinear nature of the median can exacerbate discontinuities. The median chooses a single value from the set of inputs; it doesn't average them. This can make it a poor choice for a smoothing filter, particularly if you are going to calculate derivatives (e.g. r.slope.aspect) on the result. If you want to eliminate outliers, a better option might be an average over some quantile range (e.g. 20%-80%), or a weighted average where values near the median get a larger weight. If you're trying to remove spatial noise, you normally want a filter which gives greater weight to the values nearer the centre. To avoid "contamination" by noise, one method is to use a variety of linear filters and take the median of the results. -- Glynn Clements From glynn at gclements.plus.com Thu Aug 2 14:14:34 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Aug 2 14:14:39 2007 Subject: [GRASS-dev] question about any July changes in hydrology functions In-Reply-To: References: <7FF04607-7942-478E-8898-B096F55F6D34@unity.ncsu.edu> Message-ID: <18097.51882.871942.690228@cerise.gclements.plus.com> Michael Barton wrote: > > I thought that smoothing will take care of it but apparently just the > > opposite > > This does seem strange. Even odder is the fact that the anomalies get bigger > the larger the smoothing neighborhood. Usually, increasing the neighborhood > creates greater smoothing. That's the case if the neighbours are being averaged, but it doesn't hold for a quantile. > It might be the way we are using smoothing. We check to see if an > erosion/deposition value exceeds the smoothed value by some user-determined > amount. It is does, the smoothed value is used instead of the original > value. The goal was to get rid of extreme values but leave the rest alone. That will typically cause gradient discontinuities as you switch between filtered and unfiltered data. That wouldn't necessarily be an issue in itself, but it will be if you start calculating derivatives on the result. Actually, ignore my earlier suggestion of using a median-of-filtered-values approach. That will have similar problems regarding derivatives. Moreover, any mechanism that has a discrete "cut" (i.e. if then else ) will have the same issue. You need to find some way to introduce a continuous transition. E.g. rather than selecting filtered vs unfiltered based upon a threshold, interpolate between filtered and unfiltered based upon the distance from the threshold, turning the discrete step into an ogive (S-curve). Even then, any kind of nonlinearity risks introducing artifacts when it occurs as part of a complex process, particularly if it's iterative. In general, iterative processes won't end up being stable just because you want them to be stable. If there's any kind of "amplification" involved, instability is likely to be the "default" behaviour; stability has to be forced. > > BTW as I understand it median is computed by dividing the values into > > a finite number of classes > > so the median from a continuous field would not change continuously > > from cell to cell and > > the effect you are getting could be expected especially for larger > > number of cells. > > I don't know how r.neighbors computes the median. However, it is supposed to > be a value such that half the neighbor cells have larger values and half > have smaller values. I would have thought that the way to compute would be > to order the neighborhood values from smallest to largest and find the > middle. Since the neighborhood is always an odd number, the middle is always > a single cell. This is essentially what happens, although if there are any null cells, the median may be computed over an even number of cells resulting in the mean of the two middle cells. The actual implementation (from lib/stats/c_median.c) is: void c_median(DCELL *result, DCELL *values, int n) { n = sort_cell(values, n); if (n < 1) G_set_d_null_value(result, 1); else *result = (values[(n-1)/2] + values[n/2]) / 2; } where sort_cell() sorts the cell values into ascending order. [If the number of cells is odd, (n-1)/2 and n/2 will be equal, so the middle value is averaged with itself.] > > Mean is computed directly from the floating point values - is that > > right? > > This ought to be the sum of the neighbor cell values divided by the number > of cells. > > The median is less affected by a single extreme cell than the mean, which is > why we preferred the median. However, if the median calculation algorithm is > problematic, then we'll have to switch to the mean. It's problematic if you're going to differentiate the result, because it's a discontinuous function; it's essentially a tree of if/then/else choices. -- Glynn Clements From michael.barton at asu.edu Thu Aug 2 18:22:27 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Aug 2 18:22:37 2007 Subject: [GRASS-dev] question about any July changes in hydrology functions In-Reply-To: <18097.51882.871942.690228@cerise.gclements.plus.com> Message-ID: Glynn and Helena, Thanks very much for the information and advice. So the upshot is, for this kind of simulation modeling, we avoid using a cut-off function and avoid using a median filter. Both create slight but abrupt discontinuities in the landscape which can amplify in recursive runs. I think we'll try just using the r.neighbors smoothed map (using a mean smoother) rather than some function of the original and smoothed map. I have a couple further questions before we launch into revising these scripts. 1. Is there any speed advantage/disadvantage to using r.mfilter over r.neighbors? At the moment, because we are trying to get rid of occasional spikes, I don't think that a weighted mean will give better results than an unweighted mean. But the only way to get functions like a weighted mean is to use r.mfilter, so it would be good to know if there are any known performance hits or if it is faster. 2. We are starting with a depressionless DEM, but now I'm wondering if it would be a good idea to fill any depressions between each iteration of the simulation. If so, it looks like r.terraflow builds this into its routine and could save considerable time over running r.fill.dir each time. Any thoughts along those lines? Thanks again Michael On 8/2/07 5:14 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >>> I thought that smoothing will take care of it but apparently just the >>> opposite >> >> This does seem strange. Even odder is the fact that the anomalies get bigger >> the larger the smoothing neighborhood. Usually, increasing the neighborhood >> creates greater smoothing. > > That's the case if the neighbours are being averaged, but it doesn't > hold for a quantile. > >> It might be the way we are using smoothing. We check to see if an >> erosion/deposition value exceeds the smoothed value by some user-determined >> amount. It is does, the smoothed value is used instead of the original >> value. The goal was to get rid of extreme values but leave the rest alone. > > That will typically cause gradient discontinuities as you switch > between filtered and unfiltered data. That wouldn't necessarily be an > issue in itself, but it will be if you start calculating derivatives > on the result. > > Actually, ignore my earlier suggestion of using a > median-of-filtered-values approach. That will have similar problems > regarding derivatives. > > Moreover, any mechanism that has a discrete "cut" (i.e. if > then else ) will have the same issue. You need to > find some way to introduce a continuous transition. E.g. rather than > selecting filtered vs unfiltered based upon a threshold, interpolate > between filtered and unfiltered based upon the distance from the > threshold, turning the discrete step into an ogive (S-curve). > > Even then, any kind of nonlinearity risks introducing artifacts when > it occurs as part of a complex process, particularly if it's > iterative. > > In general, iterative processes won't end up being stable just because > you want them to be stable. If there's any kind of "amplification" > involved, instability is likely to be the "default" behaviour; > stability has to be forced. > >>> BTW as I understand it median is computed by dividing the values into >>> a finite number of classes >>> so the median from a continuous field would not change continuously >>> from cell to cell and >>> the effect you are getting could be expected especially for larger >>> number of cells. >> >> I don't know how r.neighbors computes the median. However, it is supposed to >> be a value such that half the neighbor cells have larger values and half >> have smaller values. I would have thought that the way to compute would be >> to order the neighborhood values from smallest to largest and find the >> middle. Since the neighborhood is always an odd number, the middle is always >> a single cell. > > This is essentially what happens, although if there are any null > cells, the median may be computed over an even number of cells > resulting in the mean of the two middle cells. The actual > implementation (from lib/stats/c_median.c) is: > > void c_median(DCELL *result, DCELL *values, int n) > { > n = sort_cell(values, n); > > if (n < 1) > G_set_d_null_value(result, 1); > else > *result = (values[(n-1)/2] + values[n/2]) / 2; > } > > where sort_cell() sorts the cell values into ascending order. > > [If the number of cells is odd, (n-1)/2 and n/2 will be equal, so the > middle value is averaged with itself.] > >>> Mean is computed directly from the floating point values - is that >>> right? >> >> This ought to be the sum of the neighbor cell values divided by the number >> of cells. >> >> The median is less affected by a single extreme cell than the mean, which is >> why we preferred the median. However, if the median calculation algorithm is >> problematic, then we'll have to switch to the mean. > > It's problematic if you're going to differentiate the result, because > it's a discontinuous function; it's essentially a tree of if/then/else > choices. __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 at gclements.plus.com Fri Aug 3 02:31:29 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Aug 3 02:31:35 2007 Subject: [GRASS-dev] question about any July changes in hydrology functions In-Reply-To: References: <18097.51882.871942.690228@cerise.gclements.plus.com> Message-ID: <18098.30561.468261.982236@cerise.gclements.plus.com> Michael Barton wrote: > 1. Is there any speed advantage/disadvantage to using r.mfilter over > r.neighbors? At the moment, because we are trying to get rid of occasional > spikes, I don't think that a weighted mean will give better results than an > unweighted mean. But the only way to get functions like a weighted mean is > to use r.mfilter, so it would be good to know if there are any known > performance hits or if it is faster. r.mfilter currently works with integers. AFAICT, there's no fundamental reason why it can't be upgraded to FP. -- Glynn Clements From michael.barton at asu.edu Fri Aug 3 02:54:03 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Aug 3 02:54:23 2007 Subject: [GRASS-dev] question about any July changes in hydrology functions In-Reply-To: <18098.30561.468261.982236@cerise.gclements.plus.com> Message-ID: Then, as is it won't work for us. If it can be upgraded to integers we can try it. Thanks for the info. Saved us some time in fruitless testing. Now that we understand what is going on, we're getting better results. We will still need to conduct more tests, but will report back to the list with the results. Michael On 8/2/07 5:31 PM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> 1. Is there any speed advantage/disadvantage to using r.mfilter over >> r.neighbors? At the moment, because we are trying to get rid of occasional >> spikes, I don't think that a weighted mean will give better results than an >> unweighted mean. But the only way to get functions like a weighted mean is >> to use r.mfilter, so it would be good to know if there are any known >> performance hits or if it is faster. > > r.mfilter currently works with integers. AFAICT, there's no > fundamental reason why it can't be upgraded to FP. __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 michael.barton at asu.edu Fri Aug 3 03:10:25 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Aug 3 03:10:38 2007 Subject: [GRASS-dev] [grass-code I][451] "place with mouse" gets confused when placing several different layers In-Reply-To: <20070801112106.2A6E540132@pyrosoma.intevation.org> Message-ID: Moritz, Could you try with clicking inside the coordinate box of the layer desired before trying to place with a mouse? Also, I've had luck with deselecting and reselecting the place with mouse check box for a layer. This is kind a hack, since you can't really place these items interactively with the current setup (but you can with wxgrass). What is going on is that clicking with a mouse will pick up screen coordinates, which are then passed back to the coordinate field for the layer in question. If the desired layer is not active the coordinates will end up in the wrong box or it won't be able to find the box it is supposed to put them in. There may be other causes that make the coordinates end up in the wrong layer too. Unfortunately, the TclTk error is not more informative than the above summary. Michael On 8/1/07 4:21 AM, "grass-dev@grass.itc.it" wrote: > code I item #451, was opened at 2007-08-01 13:21 > Status: Open > Priority: 3 > Submitted By: Moritz Lennert (moritz) > Assigned to: Nobody (None) > Summary: "place with mouse" gets confused when placing several different > layers > Issue type: module bug > Issue status: None > GRASS version: CVS HEAD > GRASS component: tcl/tk GUI > Operating system: Linux > Operating system version: Debian Etch > GRASS CVS checkout date, if applies (YYMMDD): 070801 > > > Initial Comment: > The "place with mouse" option in the tcl/tk GUI seems to get confused when > placing several different types of layers. > > 1) Place a text with the mouse, then place a ps-text with the mouse. If you > then select the text-layer again and replace it with the mouse, it disappears. > > 2) Place a ps-text with the mouse, then place a text with the mouse. If you > then select the ps-text layer againg and replace it with the mouse, it will > appear at the wrong place. > > 3) Place a text, then place a scalebar. When you select the text again and try > to place it, the following error appears. The same (or very similar) happens > with different combinations of scalebar and text or ps-text. > > invalid command name ".mainframe.frame.pw1.f1.frame.sw.sf.frame.fr.at2.b" > invalid command name ".mainframe.frame.pw1.f1.frame.sw.sf.frame.fr.at2.b" > while executing > "$pctentry delete 0 end" > invoked from within > "if { $pctentry != "" } { > $pctentry delete 0 end > $pctentry insert 0 "$xpct,$ypct" > # object placement marker > $mapdisp create line 167 [expr ..." > (command bound to event) > > > Moritz > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://wald.intevation.org/tracker/?func=detail&atid=204&aid=451&group_id=21 > > __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 at gclements.plus.com Fri Aug 3 12:18:46 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Aug 3 12:18:52 2007 Subject: [GRASS-dev] question about any July changes in hydrology functions In-Reply-To: References: <18098.30561.468261.982236@cerise.gclements.plus.com> Message-ID: <18099.262.879095.241236@cerise.gclements.plus.com> Michael Barton wrote: > >> 1. Is there any speed advantage/disadvantage to using r.mfilter over > >> r.neighbors? At the moment, because we are trying to get rid of occasional > >> spikes, I don't think that a weighted mean will give better results than an > >> unweighted mean. But the only way to get functions like a weighted mean is > >> to use r.mfilter, so it would be good to know if there are any known > >> performance hits or if it is faster. > > > > r.mfilter currently works with integers. AFAICT, there's no > > fundamental reason why it can't be upgraded to FP. > > Then, as is it won't work for us. If it can be upgraded to integers we can > try it. I've added an FP version, r.mfilter.fp. I didn't modify r.mfilter as it turns out that there is some behaviour which is specific to integer maps, and to the zero-is-null behaviour of 4.x. It wasn't practical to add support for FP and null values without breaking compatibility. -- Glynn Clements From mlennert at club.worldonline.be Fri Aug 3 12:34:58 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Aug 3 12:33:24 2007 Subject: [GRASS-dev] [grass-code I][451] "place with mouse" gets confused when placing several different layers In-Reply-To: References: Message-ID: <46B304D2.8010201@club.worldonline.be> On 03/08/07 03:10, Michael Barton wrote: > Moritz, > > Could you try with clicking inside the coordinate box of the layer desired > before trying to place with a mouse? Doesn't change anything. > Also, I've had luck with deselecting > and reselecting the place with mouse check box for a layer. This works. > > This is kind a hack, since you can't really place these items interactively > with the current setup (but you can with wxgrass). What is going on is that > clicking with a mouse will pick up screen coordinates, which are then passed > back to the coordinate field for the layer in question. If the desired layer > is not active the coordinates will end up in the wrong box or it won't be > able to find the box it is supposed to put them in. But the desired layer _is_ active, i.e. highlighted in yellow. > There may be other > causes that make the coordinates end up in the wrong layer too. It sounds more like the variable which determines which layer to attribute the coordinates to is not reinitialised when you select a layer. It only is when you uncheck+check the "place with mouse" box. In view of the upcoming wxgrass gui, and unless identifying the culprit in the tcl/tk gui is not too difficult, knowing that unchecking+checking solves the problem is probably enough for me for now (maybe we should add a hint somewhere). Moritz From tutey at o2.pl Fri Aug 3 15:57:51 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Fri Aug 3 15:58:04 2007 Subject: [GRASS-dev] Re: [GRASS-user] 32 bit OS .. 64 bit OS In-Reply-To: <46B31BF0.5060100@itc.it> References: <767806.37866.qm@web60525.mail.yahoo.com> <46B2F603.5060800@itc.it> <46B301B3.7060503@o2.pl> <46B31BF0.5060100@itc.it> Message-ID: <46B3345F.4090206@o2.pl> Markus Neteler wrote: > Maciej Sieczka wrote on 08/03/2007 12:21 PM: >> Ravi, are you referring to the fact that there is no generic 32bit >> binary GRASS package on GRASS website, but only 64bit? > If so, I don't know how to generate 32bit binaries on a (pure) 64bit > machine as the GRASS server is. A way out would be that a community > member auto-generates 32bit Linux binaries which I then auto-fetch > every week. Hi After some reading I must say I'm to ignorant in this regard and won't help much. If anybody is willing to take on this, I found 2 usefull resources: "building 32bit app on 64bit system" [1] and "How to build 32-bit Wine on a 64-bit (x86-64) system" [2]. The latter is about Wine, but it gives detailed instructions for several main distributions, which could help. [1]http://www.linuxquestions.org/questions/showthread.php?t=570955 [2]http://wiki.winehq.org/WineOn64bit Maciek From kwythers at umn.edu Fri Aug 3 17:55:46 2007 From: kwythers at umn.edu (Kirk Wythers) Date: Fri Aug 3 17:56:00 2007 Subject: [GRASS-dev] r.colors gui Message-ID: <1AE0B022-F891-4EE7-9981-8861C9D2E812@umn.edu> I am having trouble setting the color table with r.colors through the gui (6.3 build about 2 weeks old or so). Not sure if this a build issue or my own incompetence. Can anyone confirm that the r.colors gui is working for them? Thanks, Kirk From rez at touchofmadness.com Fri Aug 3 19:05:37 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Fri Aug 3 19:05:43 2007 Subject: [GRASS-dev] Re: [GRASS-user] 32 bit OS .. 64 bit OS In-Reply-To: <46B3345F.4090206@o2.pl> References: <767806.37866.qm@web60525.mail.yahoo.com> <46B2F603.5060800@itc.it> <46B301B3.7060503@o2.pl> <46B31BF0.5060100@itc.it> <46B3345F.4090206@o2.pl> Message-ID: <1186160737.2967.178.camel@dev64.localdomain> On Fri, 2007-08-03 at 15:57 +0200, Maciej Sieczka wrote: > Markus Neteler wrote: > > Maciej Sieczka wrote on 08/03/2007 12:21 PM: > > >> Ravi, are you referring to the fact that there is no generic 32bit > >> binary GRASS package on GRASS website, but only 64bit? > > > If so, I don't know how to generate 32bit binaries on a (pure) 64bit > > machine as the GRASS server is. A way out would be that a community > > member auto-generates 32bit Linux binaries which I then auto-fetch > > every week. > > Hi > > After some reading I must say I'm to ignorant in this regard and won't > help much. If anybody is willing to take on this, I found 2 usefull > resources: "building 32bit app on 64bit system" [1] and "How to build > 32-bit Wine on a 64-bit (x86-64) system" [2]. The latter is about Wine, > but it gives detailed instructions for several main distributions, > which could help. > > [1]http://www.linuxquestions.org/questions/showthread.php?t=570955 > [2]http://wiki.winehq.org/WineOn64bit export CFLAGS="-m32..." However, I fail to see the usefulness of 32bit GRASS on 64bit systems. -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From mlennert at club.worldonline.be Fri Aug 3 19:20:41 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Aug 3 19:19:07 2007 Subject: [GRASS-dev] Re: [GRASS-user] 32 bit OS .. 64 bit OS In-Reply-To: <1186160737.2967.178.camel@dev64.localdomain> References: <767806.37866.qm@web60525.mail.yahoo.com> <46B2F603.5060800@itc.it> <46B301B3.7060503@o2.pl> <46B31BF0.5060100@itc.it> <46B3345F.4090206@o2.pl> <1186160737.2967.178.camel@dev64.localdomain> Message-ID: <46B363E9.5040609@club.worldonline.be> On 03/08/07 19:05, Brad Douglas wrote: > On Fri, 2007-08-03 at 15:57 +0200, Maciej Sieczka wrote: >> Markus Neteler wrote: >>> Maciej Sieczka wrote on 08/03/2007 12:21 PM: >>>> Ravi, are you referring to the fact that there is no generic 32bit >>>> binary GRASS package on GRASS website, but only 64bit? >>> If so, I don't know how to generate 32bit binaries on a (pure) 64bit >>> machine as the GRASS server is. A way out would be that a community >>> member auto-generates 32bit Linux binaries which I then auto-fetch >>> every week. >> Hi >> >> After some reading I must say I'm to ignorant in this regard and won't >> help much. If anybody is willing to take on this, I found 2 usefull >> resources: "building 32bit app on 64bit system" [1] and "How to build >> 32-bit Wine on a 64-bit (x86-64) system" [2]. The latter is about Wine, >> but it gives detailed instructions for several main distributions, >> which could help. >> >> [1]http://www.linuxquestions.org/questions/showthread.php?t=570955 >> [2]http://wiki.winehq.org/WineOn64bit > > export CFLAGS="-m32..." > > However, I fail to see the usefulness of 32bit GRASS on 64bit systems. The question was whether Markus could use his 64bit server to cross-compile binaries for 32bit systems or whether someone with a 32bit system would have to do it. Moritz From rez at touchofmadness.com Fri Aug 3 19:24:54 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Fri Aug 3 19:25:19 2007 Subject: [GRASS-dev] Re: [GRASS-user] 32 bit OS .. 64 bit OS In-Reply-To: <46B363E9.5040609@club.worldonline.be> References: <767806.37866.qm@web60525.mail.yahoo.com> <46B2F603.5060800@itc.it> <46B301B3.7060503@o2.pl> <46B31BF0.5060100@itc.it> <46B3345F.4090206@o2.pl> <1186160737.2967.178.camel@dev64.localdomain> <46B363E9.5040609@club.worldonline.be> Message-ID: <1186161894.2967.185.camel@dev64.localdomain> On Fri, 2007-08-03 at 19:20 +0200, Moritz Lennert wrote: > On 03/08/07 19:05, Brad Douglas wrote: > > On Fri, 2007-08-03 at 15:57 +0200, Maciej Sieczka wrote: > >> Markus Neteler wrote: > >>> Maciej Sieczka wrote on 08/03/2007 12:21 PM: > >>>> Ravi, are you referring to the fact that there is no generic 32bit > >>>> binary GRASS package on GRASS website, but only 64bit? > >>> If so, I don't know how to generate 32bit binaries on a (pure) 64bit > >>> machine as the GRASS server is. A way out would be that a community > >>> member auto-generates 32bit Linux binaries which I then auto-fetch > >>> every week. > >> Hi > >> > >> After some reading I must say I'm to ignorant in this regard and won't > >> help much. If anybody is willing to take on this, I found 2 usefull > >> resources: "building 32bit app on 64bit system" [1] and "How to build > >> 32-bit Wine on a 64-bit (x86-64) system" [2]. The latter is about Wine, > >> but it gives detailed instructions for several main distributions, > >> which could help. > >> > >> [1]http://www.linuxquestions.org/questions/showthread.php?t=570955 > >> [2]http://wiki.winehq.org/WineOn64bit > > > > export CFLAGS="-m32..." > > > > However, I fail to see the usefulness of 32bit GRASS on 64bit systems. > > The question was whether Markus could use his 64bit server to > cross-compile binaries for 32bit systems or whether someone with a 32bit > system would have to do it. Ah. Okay, I misunderstood the question. Yes, it is possible to compile 32bit on 64bit. I don't do it simply because I hate to co-mingle bit depths, but that's a personal choice. -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From michael.barton at asu.edu Sat Aug 4 06:20:04 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Aug 4 06:23:36 2007 Subject: [GRASS-dev] question about any July changes in hydrology functions In-Reply-To: <18099.262.879095.241236@cerise.gclements.plus.com> Message-ID: Thanks Glynn. We'll certainly give it a try. Michael On 8/3/07 3:18 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >>>> 1. Is there any speed advantage/disadvantage to using r.mfilter over >>>> r.neighbors? At the moment, because we are trying to get rid of occasional >>>> spikes, I don't think that a weighted mean will give better results than an >>>> unweighted mean. But the only way to get functions like a weighted mean is >>>> to use r.mfilter, so it would be good to know if there are any known >>>> performance hits or if it is faster. >>> >>> r.mfilter currently works with integers. AFAICT, there's no >>> fundamental reason why it can't be upgraded to FP. >> >> Then, as is it won't work for us. If it can be upgraded to integers we can >> try it. > > I've added an FP version, r.mfilter.fp. > > I didn't modify r.mfilter as it turns out that there is some behaviour > which is specific to integer maps, and to the zero-is-null behaviour > of 4.x. It wasn't practical to add support for FP and null values > without breaking compatibility. __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 michael.barton at asu.edu Sat Aug 4 08:51:46 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Aug 4 08:51:56 2007 Subject: [GRASS-dev] wxgrass intro screen and location wizard completed Message-ID: I just committed the finishing touches to the wxPython GUI intro screen and location wizard. The intro screen gives the same functions as the TclTk one (GRASS database, location, and mapset selection) and mapset creation, plus a new location wizard that Jachym and I've done, and options to rename or delete locations and mapsets. The location wizard is a nice GUI (with a great graphic from Jachym) that walks you through location creation by any of the following methods: espg code, georeferenced file, datum selection, projection/ellipse selection, custom PROJ4 string entry, or XY location creation. After a location is created, you have the option of setting/resetting the default region extents and resolution. This is all done within a wxPython GUI that runs native on all major platforms. ---------------- The new wxPython GUI for GRASS is currently under development and nearing completion. It can be downloaded from It requires Python 2.4 or above and wxPython 2.8 or above. ---------------- Give it a spin. Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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/20070803/25d26186/attachment-0001.html From michael.barton at asu.edu Sat Aug 4 09:04:34 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Aug 4 09:04:45 2007 Subject: [GRASS-dev] r.colors gui In-Reply-To: <1AE0B022-F891-4EE7-9981-8861C9D2E812@umn.edu> Message-ID: I assume that you're talking about the color rules entry screen, where you can type in rules. I just tried it on a build from last weekend and it works fine. So does setting the colors from the color table GUI (r.colors) Michael On 8/3/07 8:55 AM, "Kirk Wythers" wrote: > I am having trouble setting the color table with r.colors through the > gui (6.3 build about 2 weeks old or so). Not sure if this a build > issue or my own incompetence. Can anyone confirm that the r.colors > gui is working for them? > > Thanks, > > Kirk > > __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 michael.barton at asu.edu Sat Aug 4 09:14:38 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Aug 4 09:14:52 2007 Subject: [GRASS-dev] question about any July changes in hydrology functions In-Reply-To: <18099.262.879095.241236@cerise.gclements.plus.com> Message-ID: I wanted to report that we managed to get rid of the artifacts and produce a very nice looking map, with a 50-year recursive landscape evolution simulation. Surprisingly, we ended up using a median filter after all, but without the cutoff function. I realized that we needed to 'despeckle' the map in order to remove the spikes that were the original problem we were trying to fix when we generated the gridded peaks artifacts. We're running more tests to see what neighborhood size works best. 7x7 looked really nice for most things, but was a little rough in areas where grazing animals had randomly denuded cells of vegetation and it had regenerated to a varying amount (though still far better than any other result we'd had so far). Trying 9x9 now. Also running it with the coupled agent based model of village farming over the weekend to see how it performs. I'll try to post some pictures of the results next week. This updated version of r.landscape.evol is now on the GRASS Addons SVN server. Thanks to both of you for helping us to sort out this mysterious simulation effect. Michael On 8/3/07 3:18 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >>>> 1. Is there any speed advantage/disadvantage to using r.mfilter over >>>> r.neighbors? At the moment, because we are trying to get rid of occasional >>>> spikes, I don't think that a weighted mean will give better results than an >>>> unweighted mean. But the only way to get functions like a weighted mean is >>>> to use r.mfilter, so it would be good to know if there are any known >>>> performance hits or if it is faster. >>> >>> r.mfilter currently works with integers. AFAICT, there's no >>> fundamental reason why it can't be upgraded to FP. >> >> Then, as is it won't work for us. If it can be upgraded to integers we can >> try it. > > I've added an FP version, r.mfilter.fp. > > I didn't modify r.mfilter as it turns out that there is some behaviour > which is specific to integer maps, and to the zero-is-null behaviour > of 4.x. It wasn't practical to add support for FP and null values > without breaking compatibility. __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From benjamin.ducke at ufg.uni-kiel.de Sat Aug 4 13:57:57 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Sat Aug 4 13:58:17 2007 Subject: [GRASS-dev] wxgrass intro screen and location wizard completed In-Reply-To: References: Message-ID: <46B469C5.9040503@ufg.uni-kiel.de> This looks great and I have been wanting to try wxGRASS for some time now, however on my Gentoo linux system I have actually never been able to get wxPython to run. Maybe someone could help me clarify some issues. 1. I don't understand the relation between wxWindows, wxWidgets and wxPython. The wxWidgets site claims to have GUI libs with python support. If I install them, I get libs, header files and a config script called wx-config. That's OK. But why does the wxPython distro install those same files again? It also comes with a config script called wx-config and installs headers and include files in the same location as wxWidgets, even with the same names and same version numbers. I am confused ... 2. The build and install instructions for wxPythons are a mess. From those two documents, I just can't seem to figure out how to make a global build and install from source. I manage to compile and install the C API part (btw.: is this the same that comes with wxWidgets?) alright, but runnning python setup.py install just gives me: wx/setup.h: No such file or directory and a load of other error messages complaining about missing header files in wx/. Even though I did a "make install" and manually copied header files to system-wide location /usr/incluce/wx/ Anyone got some experience installing wxPython from scratch on a Linux system? Thanks, Benjamin Michael Barton wrote: > I just committed the finishing touches to the wxPython GUI intro screen > and location wizard. > > The intro screen gives the same functions as the TclTk one (GRASS > database, location, and mapset selection) and mapset creation, plus a > new location wizard that Jachym and I've done, and options to rename or > delete locations and mapsets. > > The location wizard is a nice GUI (with a great graphic from Jachym) > that walks you through location creation by any of the following > methods: espg code, georeferenced file, datum selection, > projection/ellipse selection, custom PROJ4 string entry, or XY location > creation. After a location is created, you have the option of > setting/resetting the default region extents and resolution. > > This is all done within a wxPython GUI that runs native on all major > platforms. > > ---------------- > The new wxPython GUI for GRASS is currently under development and > nearing completion. It can be downloaded from > > It requires Python 2.4 or above and wxPython 2.8 or above. > ---------------- > > Give it a spin. > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > Director of Graduate Studies > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > ------------------------------------------------------------------------ > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From glynn at gclements.plus.com Sat Aug 4 17:04:07 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Aug 4 17:04:17 2007 Subject: [GRASS-dev] wxgrass intro screen and location wizard completed In-Reply-To: <46B469C5.9040503@ufg.uni-kiel.de> References: <46B469C5.9040503@ufg.uni-kiel.de> Message-ID: <18100.38247.741028.795098@cerise.gclements.plus.com> Benjamin Ducke wrote: > 1. I don't understand the relation between wxWindows, wxWidgets and > wxPython. wxWindows is the old name, wxWidgets is the new name. wxPython refers to the Python bindings for wxWidgets. > The wxWidgets site claims to have GUI libs with python > support. If I install them, I get libs, header files and a config > script called wx-config. That's OK. But why does the wxPython distro > install those same files again? It also comes with a config script > called wx-config and installs headers and include files in the same > location as wxWidgets, even with the same names and same version > numbers. I am confused ... The wxPython source distribution bundles a copy of wxWidgets. This may not be such a great idea, but that's how it is. -- Glynn Clements From benjamin.ducke at ufg.uni-kiel.de Sat Aug 4 17:25:00 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Sat Aug 4 17:25:15 2007 Subject: [GRASS-dev] wxgrass intro screen and location wizard completed In-Reply-To: <18100.38247.741028.795098@cerise.gclements.plus.com> References: <46B469C5.9040503@ufg.uni-kiel.de> <18100.38247.741028.795098@cerise.gclements.plus.com> Message-ID: <46B49A4C.9060600@ufg.uni-kiel.de> OK, I think I managed to sort things out and they are working for me now. I just got rid of the previous wxWidget installation I had and installed all from scratch using wxPython. There are two little glitches: 1. You have to compile and install the stuff in the 'contrib' dir manually. 2. The setup.py script is a bit stupid. It assumes that you want to build with unicode support and fails, otherwise (that's what my problem was). Cheers, Benjamin Glynn Clements wrote: > Benjamin Ducke wrote: > >> 1. I don't understand the relation between wxWindows, wxWidgets and >> wxPython. > > wxWindows is the old name, wxWidgets is the new name. > > wxPython refers to the Python bindings for wxWidgets. > >> The wxWidgets site claims to have GUI libs with python >> support. If I install them, I get libs, header files and a config >> script called wx-config. That's OK. But why does the wxPython distro >> install those same files again? It also comes with a config script >> called wx-config and installs headers and include files in the same >> location as wxWidgets, even with the same names and same version >> numbers. I am confused ... > > The wxPython source distribution bundles a copy of wxWidgets. This may > not be such a great idea, but that's how it is. > From benjamin.ducke at ufg.uni-kiel.de Sat Aug 4 17:37:58 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Sat Aug 4 17:38:11 2007 Subject: [GRASS-dev] wxgrass intro screen and location wizard completed In-Reply-To: References: Message-ID: <46B49D56.9090105@ufg.uni-kiel.de> Hmmm, after starting wxgrass, I get this message dumped to the command line every few seconds, preventing me from using the CLI: ** (python:25499): WARNING **: IPP request failed with status 1280 Ben Michael Barton wrote: > I just committed the finishing touches to the wxPython GUI intro screen > and location wizard. > > The intro screen gives the same functions as the TclTk one (GRASS > database, location, and mapset selection) and mapset creation, plus a > new location wizard that Jachym and I've done, and options to rename or > delete locations and mapsets. > > The location wizard is a nice GUI (with a great graphic from Jachym) > that walks you through location creation by any of the following > methods: espg code, georeferenced file, datum selection, > projection/ellipse selection, custom PROJ4 string entry, or XY location > creation. After a location is created, you have the option of > setting/resetting the default region extents and resolution. > > This is all done within a wxPython GUI that runs native on all major > platforms. > > ---------------- > The new wxPython GUI for GRASS is currently under development and > nearing completion. It can be downloaded from > > It requires Python 2.4 or above and wxPython 2.8 or above. > ---------------- > > Give it a spin. > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > Director of Graduate Studies > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > ------------------------------------------------------------------------ > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From paul-grass at stjohnspoint.co.uk Sat Aug 4 18:35:35 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sat Aug 4 18:35:40 2007 Subject: [GRASS-dev] Re: v.generalize In-Reply-To: <46A8E263.1080304@bergenheim.net> References: <1185306826.8290.11.camel@dev64.localdomain> <20070724203521.GD15606@bartok.itc.it> <46A8E263.1080304@bergenheim.net> Message-ID: On Thu, 26 Jul 2007, Wolf Bergenheim wrote: > v.generalize: > ~~~~~~~~~~~~~ > v.generalize is fully functional complete with manual and smoothing and > simplification operations. The module works with both areas and lines. > Attribute tables are also copied and cats are preserved. Please give the > module a try and send us feedback! > The rest of SoC will be spent in implementing other generalization > operations and getting all the rest of the bugs out. Hello Wolf and Daniel Now I've had time to look at v.generalize too and am very impressed. The amount of easily-accessible functionality that this module adds to the GRASS vector capabilities really seems to be something significant. At first glance the amount of options seemed overwhelming but on reading through the man page and looking at the references there it became much more obvious. I think it could still be made clearer, but there is already a lot of information and explanation there and also in the source code, which is good. The main thing I was wondering about is whether the threshold parameter is dual-purpose? If I understand correctly, is it used in some algorithms but then again also at the end to remove lines left that are shorter and areas that are smaller than the threshold? Is that dual purpose use likely to cause any problems? Or should these be different parameters? I am curious too as to the spelling of alfa rather than alpha! Compiling with -Wall I see quite a lot of missing function prototypes - as for the other Summer of Code module I feel putting in a local_proto.h for the functions that can be called from other source files, and marking the functions local to each file as static, would make things a bit clearer. Also perhaps Doxygen-style documentation for the functions? This one's not a big deal at all. I know it's a bit of work but the functions look well organised already, so presumably there is a lot of thought behind the way they are and it should be easy enough to put that into words. But in general the code comments are really good and helpful - only there where they are needed and left out where it is obvious by reading the code, what is going on. Was thinking too about all the matrix stuff in the matrix.c file - sorry for this lazy question, as if I had more time to look through and was more familiar with these things I could answer it myself - but is it better than the G_matrix_* functions in lib/gmath, or just an alternative? Would also be interesting to hear if Daniel has any suggestions for improvements and tidying of the vector API in GRASS. I enjoyed reading the code and it seems to utilise the existing API very well, which makes me think it's possible suggestions for enhancements and further development of the API could even come out of this work. But in summary, I had to search hard to find these few suggestions for improvement! It looks like a really excellent piece of work and it will be great to have it in GRASS. Paul From bundala at gmail.com Sat Aug 4 22:57:26 2007 From: bundala at gmail.com (Daniel Bundala) Date: Sat Aug 4 22:57:29 2007 Subject: [GRASS-dev] Re: v.generalize In-Reply-To: References: <1185306826.8290.11.camel@dev64.localdomain> <20070724203521.GD15606@bartok.itc.it> <46A8E263.1080304@bergenheim.net> Message-ID: <9211715e0708041357g7446308eqa5dee5ea51851c59@mail.gmail.com> Hello Paul, Wolf and List On 8/4/07, Paul Kelly wrote: > On Thu, 26 Jul 2007, Wolf Bergenheim wrote: > > > v.generalize: > > ~~~~~~~~~~~~~ > > v.generalize is fully functional complete with manual and smoothing and > > simplification operations. The module works with both areas and lines. > > Attribute tables are also copied and cats are preserved. Please give the > > module a try and send us feedback! > > The rest of SoC will be spent in implementing other generalization > > operations and getting all the rest of the bugs out. > > Hello Wolf and Daniel > Now I've had time to look at v.generalize too and am very impressed. The > amount of easily-accessible functionality that this module adds to the > GRASS vector capabilities really seems to be something significant. At > first glance the amount of options seemed overwhelming but on reading > through the man page and looking at the references there it became much > more obvious. I think it could still be made clearer, but there is already > a lot of information and explanation there and also in the source code, > which is good. This is true. Actually, the man page does not contain any examples. I will try to improve this... Moreover, I am planning to write a tutorial/GSoC Final Report which will demonstrate the capabilities of this module with a lot of examples and nice pictures... > > The main thing I was wondering about is whether the threshold parameter is > dual-purpose? If I understand correctly, is it used in some algorithms but > then again also at the end to remove lines left that are shorter and areas > that are smaller than the threshold? Is that dual purpose use likely to > cause any problems? Or should these be different parameters? Yes, you understand it correctly. But this happens only if you simplify the lines. Just few days ago, I added new flag (-r) to the module which specifies whether the small/short linear features are romeved. It is also mentioned somewhere in the newest version of the man page. > I am curious too as to the spelling of alfa rather than alpha! Oops. I think that this caused me some problems with TeX as well.... I will change it. > > Compiling with -Wall I see quite a lot of missing function prototypes - as > for the other Summer of Code module I feel putting in a local_proto.h for > the functions that can be called from other source files, and marking > the functions local to each file as static, would make things a bit > clearer. Also perhaps Doxygen-style documentation for the functions? This > one's not a big deal at all. I know it's a bit of work but the functions > look well organised already, so presumably there is a lot of thought > behind the way they are and it should be easy enough to put that into > words. But in general the code comments are really good and helpful - only > there where they are needed and left out where it is obvious by reading > the code, what is going on. Glad you like me style of comments... You know, *the* most boring part of the project. And I will check that -Wall stuff. > > Was thinking too about all the matrix stuff in the matrix.c file - sorry > for this lazy question, as if I had more time to look through and was more > familiar with these things I could answer it myself - but is it better > than the G_matrix_* functions in lib/gmath, or just an alternative? It is probably just an alternative, but it was meant to better:) In the beginnings, it seemed that I will be working with the special type of sparse matrices only. But this is no more the case. > Would also be interesting to hear if Daniel has any suggestions for > improvements and tidying of the vector API in GRASS. I enjoyed reading the > code and it seems to utilise the existing API very well, which makes me > think it's possible suggestions for enhancements and further development > of the API could even come out of this work. Hmmm, maybe, I was really missing built-in functions for the work with the single points/vectors. (Vector from mathematical/geometrical/physical point of view) Something I have implemented in point.* > But in summary, I had to search hard to find these few suggestions for > improvement! It looks like a really excellent piece of work and it will be > great to have it in GRASS. > > Paul Thanks Paul for your feedback! I dont know what commit/version did you use, but from the above, it seems that it was not the very last commit. Well, there were no changes in the code, but I documented displacement and "network generalization" operations. Just to keep you informed about the newest functionalities of v.generalize:) To tell the truth, "displacement" has very impressive results! (Stay tuned for the tutorial, everything will be there:) Daniel > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From michael.barton at asu.edu Sat Aug 4 23:43:05 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Aug 4 23:43:11 2007 Subject: [GRASS-dev] fix to location wizard Message-ID: I just found and fixed a bug in the coordinate setting pages of the location wizard. Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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/20070804/b56774e3/attachment.html From benjamin.ducke at ufg.uni-kiel.de Sun Aug 5 12:28:13 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Sun Aug 5 12:28:40 2007 Subject: [GRASS-dev] wxgrass intro screen and location wizard completed In-Reply-To: References: Message-ID: <46B5A63D.9060507@ufg.uni-kiel.de> Looks like it's just something to do with the Gnome print plugin that I compiled on my box. For some reason, it's not working the way it should. Nothing of general interest/worry, I think. Ben Michael Barton wrote: > Benjamin, > > I have no idea why you're getting this error. I always install from the > wxPython site rather than the wxWidgets site. Installing on FC6, we had to > manually put the wxPython files into their proper directory. After that, it > all went well. Make sure you don't have >1 version of Python lurking on your > system. Good luck. > > Michael > > > On 8/4/07 8:37 AM, "Benjamin Ducke" wrote: > >> Hmmm, after starting wxgrass, I get this message >> dumped to the command line every few seconds, preventing me from >> using the CLI: >> >> ** (python:25499): WARNING **: IPP request failed with status 1280 >> >> Ben > > __________________________________________ > Michael Barton, Professor of Anthropology > Director of Graduate Studies > 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 michael.barton at asu.edu Sun Aug 5 20:23:35 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Aug 5 20:23:42 2007 Subject: [GRASS-dev] problems compiling r.neighbors Message-ID: I just did a cvs update and tried to compile GRASS. I did a make distclean. I got the following error compilng r.neighbors. cmb-MBP:~/grass_dev/grass6 cmbarton$ cd ./raster/r.neighbors cmb-MBP:~/grass_dev/grass6/raster/r.neighbors cmbarton$ make gcc -L/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.10.1/lib -DPACKAGE=\""grassmods"\" -o /Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.10.1/bin/r.neighbor s OBJ.i686-apple-darwin8.10.1/bufs.o OBJ.i686-apple-darwin8.10.1/divr_cats.o OBJ.i686-apple-darwin8.10.1/gather.o OBJ.i686-apple-darwin8.10.1/intr_cats.o OBJ.i686-apple-darwin8.10.1/main.o OBJ.i686-apple-darwin8.10.1/null_cats.o OBJ.i686-apple-darwin8.10.1/readcell.o -lgrass_stats -lgrass_gis -lgrass_datetime -lz -lgrass_gis -lgrass_datetime -lz -lz /usr/bin/ld: Undefined symbols: _read_weights collect2: ld returned 1 exit status make: *** [/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.10.1/bin/r.neighbo rs] Error 1 cmb-MBP:~/grass_dev/grass6/raster/r.neighbors cmbarton$ Any suggestions? Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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/20070805/b463c0f8/attachment.html From paul-grass at stjohnspoint.co.uk Sun Aug 5 20:51:30 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sun Aug 5 20:51:38 2007 Subject: [GRASS-dev] wxgrass intro screen and location wizard completed In-Reply-To: <46B469C5.9040503@ufg.uni-kiel.de> References: <46B469C5.9040503@ufg.uni-kiel.de> Message-ID: On Sat, 4 Aug 2007, Benjamin Ducke wrote: > This looks great and I have been wanting to try wxGRASS for some time > now, however on my Gentoo linux system I have actually never been able > to get wxPython to run. I got it installed and working on Slackware 12.0 a couple of weeks ago. Some info below. > Maybe someone could help me clarify some issues. > > 1. I don't understand the relation between wxWindows, wxWidgets and > wxPython. The wxWidgets site claims to have GUI libs with python > support. If I install them, I get libs, header files and a config > script called wx-config. That's OK. But why does the wxPython distro > install those same files again? It also comes with a config script > called wx-config and installs headers and include files in the same > location as wxWidgets, even with the same names and same version > numbers. I am confused ... You just need to download the large 25MB or so file from wxPython and all the other stuff comes with it. I suppose it gets complicated if you have a different version of Wxwindows/wxwidgets installed already. Luckily I was doing a clean installation. > 2. The build and install instructions for wxPythons are a mess. > From those two documents, I just can't seem to figure out how to > make a global build and install from source. I manage to compile I agree they are far more complicated than necessary. Seems like very minimal effort has been put into making compilation and installation of the package simple. FWIW, here are my (simplified) instructions which worked for me: Download combined Wxwidgets/Wxpython package from Wxpython website (approx. 25MB) Untar and cd into WxwidgetsDir mkdir bld cd bld ../configure --enable-optimise --with-opengl (If you don't enable OpenGL you get problems with the wxPython install later as it seems to assume OpenGL is enabled...) make make -C contrib/src/gizmos make -C contrib/src/stc sudo make install sudo make -C contrib/src/gizmos install sudo make -C contrib/src/stc install cd ../wxPython Edit config.py to say WX_CONFIG = "wx-config" or else warnings about having only one config environment seem to confuse the next bit sudo python setup.py install and that was it. Hope it is useful to someone - meant to post it earlier but forgot, sorry. Paul From michael.barton at asu.edu Sun Aug 5 21:05:02 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Aug 5 21:05:07 2007 Subject: [GRASS-dev] layers added to wxgrass Message-ID: I just added the following new display layers to the layer manager in wxgrass: d.shadedmap, d.rumbline, d.geodesic, and d.rast.arrow. This gives the new wxPython GUI layer manager all the same types of layers available in the TclTk GUI except for d.rast.num. d.rast.num is a problem in the wxPython GUI because it requires a very low resolution rendering (less than 100x100 cells). This is incompatible with the rendering algorithm in wxgrass which keeps a constant GRASS output display resolution that is equal to the display canvas resolution in pixels. This makes for nice looking displays and very fast rendering, but is a problem for d.rast.num. There is probably a way to solve this, but it will take some thought and recoding. AFAICT, the GUI in wxPython now has equivalent (or better) functionality than the TclTk one with the following exceptions: digitizing - actively under development georectifying - next on my list nviz - could really use some expertise in openGL to reconceptualize and implement this. Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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/20070805/7e47de76/attachment.html From benjamin.ducke at ufg.uni-kiel.de Sun Aug 5 21:17:25 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Sun Aug 5 21:17:55 2007 Subject: [GRASS-dev] wxgrass intro screen and location wizard completed In-Reply-To: References: <46B469C5.9040503@ufg.uni-kiel.de> Message-ID: <46B62245.1030709@ufg.uni-kiel.de> Paul, Glynn, Michael and all thanks for the hints, meanwhile I have figured out how to get things working on my Gentoo Linux box and the glitches I faced were pretty much the same you described. In case it will help anyone in the future, here are my notes for an installation of wxGRASS on Gentoo linux (or any other Linux distro from scratch, I guess): *** wxGRASS on Linux with wxPython from scratch: This GUI is based completely on interpreted Python code. No compilation is required. GUI libs used are wxPython: http://www.wxpython.org/ ... this includes a copy of the basic wxWindows widgets with the same version number as the wxPython distribution. So no need to install wxWindows/wxWdigets separately. Problem: can create a real mess because there seem to be some steps that assume that a unicode build has been made and other that assume a plain ANSI build! If the two get mixed up, compilation will fail at some point complaining about missing include files in wx/ because the configure script is not pointing to the right build directory. Solution: create a UNICODE build and make sure there is nothing lying around that still points to an ANSI build. Step ONE: build main wxWidgets libs (will be done in subdirectory 'bld' in main wxPython sources dir). extract archive to $WXDIR, configure (NOTE: change --prefix= to wherever your Python stuff and system libs are globally installed), build and install: mkdir $WXDIR/bld cd $WXDIR/bld ../configure --prefix=/usr --with-gtk --without-gnomeprint --with-opengl --enable-geometry --enable-graphics_ctx --enable-sound --with-sdl --enable-mediactrl --enable-display --enable-optimize --enable-unicode make sudo make install exit (NOTE: I disabled gnomeprint on my system, because it kept dumping a stupid "IPP" related error message on my console; you might want to set other options to better suit your system) Now we need to make some contributed extensions. These are skipped by the main Makefile but will likely be needed later. Make sure you are in the 'bld' subdirectory. cd contrib make sudo make install exit This should have taken care to install all headers and libaries in the system-wide locations. Confirm that all is working by doing: wx-config --version and wx-config --list The version displayed by the first command needs to be the same as that of the wxPython you are installing. If not, there is an old version of wxWidgets floating around that you should deinstall (note: wx 2.8 has wx 2.6 compatibility enabled by default). The second command should list just one wx configuration, namely the current UNICODE build. If it shows more, there are other builds in /usr/lib/wx/config and /usr/lib/wx/include. You may want to delete these. Step TWO: create and install system-wide Python bindings for wx. The Python extensions have to be made with superuser rights for a system-wide install: cd $WXDIR/wxPython sudo python setup.py install NOTE: setup.py is a little bit dumb. It assumes that you are doing a unicode build and that the extensions from the 'contrib' dir have been installed. If you followed the above instructions precisely, all should work. If not, you will get errors about missing includes in wx/ sooner or later. In that case, consult $WXDIR/docs/BUILD.txt for information on how to swith off dependencies. *** Paul Kelly wrote: > On Sat, 4 Aug 2007, Benjamin Ducke wrote: > >> This looks great and I have been wanting to try wxGRASS for some time >> now, however on my Gentoo linux system I have actually never been able >> to get wxPython to run. > > I got it installed and working on Slackware 12.0 a couple of weeks ago. > Some info below. > >> Maybe someone could help me clarify some issues. >> >> 1. I don't understand the relation between wxWindows, wxWidgets and >> wxPython. The wxWidgets site claims to have GUI libs with python >> support. If I install them, I get libs, header files and a config >> script called wx-config. That's OK. But why does the wxPython distro >> install those same files again? It also comes with a config script >> called wx-config and installs headers and include files in the same >> location as wxWidgets, even with the same names and same version >> numbers. I am confused ... > > You just need to download the large 25MB or so file from wxPython and > all the other stuff comes with it. I suppose it gets complicated if you > have a different version of Wxwindows/wxwidgets installed already. > Luckily I was doing a clean installation. > >> 2. The build and install instructions for wxPythons are a mess. >> From those two documents, I just can't seem to figure out how to >> make a global build and install from source. I manage to compile > > I agree they are far more complicated than necessary. Seems like very > minimal effort has been put into making compilation and installation of > the package simple. FWIW, here are my (simplified) instructions which > worked for me: > > Download combined Wxwidgets/Wxpython package from Wxpython website > (approx. 25MB) > Untar and cd into WxwidgetsDir > mkdir bld > cd bld > ../configure --enable-optimise --with-opengl > (If you don't enable OpenGL you get problems with the wxPython install > later > as it seems to assume OpenGL is enabled...) > make > make -C contrib/src/gizmos > make -C contrib/src/stc > sudo make install > sudo make -C contrib/src/gizmos install > sudo make -C contrib/src/stc install > cd ../wxPython > Edit config.py to say WX_CONFIG = "wx-config" or else warnings about having > only one config environment seem to confuse the next bit > sudo python setup.py install > > and that was it. Hope it is useful to someone - meant to post it earlier > but forgot, sorry. > > Paul > > > From michael.barton at asu.edu Sun Aug 5 21:25:14 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Aug 5 21:25:25 2007 Subject: [GRASS-dev] new layers for wxgrass - IMPORTANT reminder Message-ID: If you update wxgrass to get the new layer types, you also MUST update the ICONS from the cvs or it won't work. Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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/20070805/44f0d68b/attachment-0001.html From grass-dev at grass.itc.it Sun Aug 5 21:36:14 2007 From: grass-dev at grass.itc.it (grass-dev@grass.itc.it) Date: Sun Aug 5 21:32:13 2007 Subject: [GRASS-dev] [grass-code I][452] v.overlay misses some vector elemnts with "and" operator Message-ID: <20070805193614.9F695B4006@pyrosoma.intevation.org> code I item #452, was opened at 2007-08-05 21:36 Status: Open Priority: 3 Submitted By: Andras Fabian (alpilotx) Assigned to: Nobody (None) Summary: v.overlay misses some vector elemnts with "and" operator Issue type: other bug Issue status: None GRASS version: CVS HEAD GRASS component: vector Operating system: Linux Operating system version: SUSE Linus 10.2 / Kernel 2.6.21 GRASS CVS checkout date, if applies (YYMMDD): 070804 Initial Comment: I have noticed a new issue with v.overlay and the "and" operator, although I don't know, if this is in some way related to "[#384] v.overlay with 'and' operator sometimes produces wrong results" http://wald.intevation.org/tracker/index.php?func=detail&aid=384&group_id=21&atid=204 (which was added to the tracker Maciej Sieczka in my name - though nothing happened on that bug, why ???) OK, this time it looks like this. I have a set of vectory polygons (call it "polygons_select") and one larger vector polygon which almost overlaps the previous ones (call it "eco_clipped_central_appalachian"). Now, I would like to cut A by B, so I obviously do a v.overlay with "and". Or as it looks in reality: " v.overlay ainput=polygons_select atype=area alayer=1 binput=eco_clipped_central_appalachian btype=area blayer=1 output=polygons_current operator=and olayer=1,0,0 --overwrite " Now the resulting "polygons_current" is missing some polygons, which should obviously NOT be missing! See attached screenshots: - polygons_select.jpg is where I start - polygons_select_WITH_eco_clipped_central_appalachian.jpg shows the second polygon (in transparent yellow) which I would like to overlay with the first ones. - polygons_current.jpg shows with the red arrow, where one polygon is missing. I also attach the vector sets from GRASS, so maybe someone could test it out. As I'm working on a slightly time critical project, it would be very helpful to have some response within the next weeks. Thank you very much! Andras Fabian http://www.alpilotx.de (where many infos about my project can be seen) ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=452&group_id=21 From michael.barton at asu.edu Mon Aug 6 00:51:17 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Aug 6 00:51:24 2007 Subject: [GRASS-dev] wxgrass intro screen and location wizard completed In-Reply-To: <46B62245.1030709@ufg.uni-kiel.de> Message-ID: What do you think about posting your and Paul's installation information to the GRASS WIKI in the Python GUI section? Michael On 8/5/07 12:17 PM, "Benjamin Ducke" wrote: > Paul, Glynn, Michael and all > > thanks for the hints, meanwhile I have figured out how to get > things working on my Gentoo Linux box and the glitches I faced > were pretty much the same you described. In case it will help > anyone in the future, here are my notes for an installation of > wxGRASS on Gentoo linux (or any other Linux distro from scratch, > I guess): > > *** > > wxGRASS on Linux with wxPython from scratch: > > This GUI is based completely on interpreted Python code. No compilation > is required. GUI libs used are wxPython: > > http://www.wxpython.org/ > > ... this includes a copy of the basic wxWindows widgets with the same > version number as the wxPython distribution. So no need to install > wxWindows/wxWdigets separately. > > Problem: can create a real mess because there seem to be some steps > that assume that a unicode build has been made and other that assume > a plain ANSI build! If the two get mixed up, compilation will fail > at some point complaining about missing include files in wx/ because > the configure script is not pointing to the right build directory. > > Solution: create a UNICODE build and make sure there is nothing lying > around that still points to an ANSI build. > > Step ONE: build main wxWidgets libs (will be done in subdirectory 'bld' > in main > wxPython sources dir). > > extract archive to $WXDIR, configure (NOTE: change --prefix= to wherever > your Python stuff and system libs are globally installed), build and > install: > > mkdir $WXDIR/bld > cd $WXDIR/bld > ../configure --prefix=/usr --with-gtk --without-gnomeprint --with-opengl > --enable-geometry --enable-graphics_ctx --enable-sound --with-sdl > --enable-mediactrl --enable-display --enable-optimize --enable-unicode > make > sudo make install > exit > > (NOTE: I disabled gnomeprint on my system, because it kept dumping > a stupid "IPP" related error message on my console; you might want > to set other options to better suit your system) > > Now we need to make some contributed extensions. These are skipped by > the main Makefile but will likely be needed later. Make sure you are in > the 'bld' subdirectory. > > cd contrib > make > sudo make install > exit > > This should have taken care to install all headers and libaries in > the system-wide locations. Confirm that all is working by doing: > > wx-config --version > > and > > wx-config --list > > The version displayed by the first command needs to be the same as that > of the wxPython you are installing. If not, there is an old version of > wxWidgets floating around that you should deinstall (note: wx 2.8 has > wx 2.6 compatibility enabled by default). > > The second command should list just one wx configuration, namely the > current UNICODE build. If it shows more, there are other builds in > /usr/lib/wx/config and /usr/lib/wx/include. You may want to delete these. > > Step TWO: create and install system-wide Python bindings for wx. > > The Python extensions have to be made with superuser rights for a > system-wide install: > > cd $WXDIR/wxPython > sudo python setup.py install > > NOTE: setup.py is a little bit dumb. It assumes that you are doing a > unicode build and that the extensions from the 'contrib' dir have been > installed. If you followed the above instructions precisely, all should > work. If not, you will get errors about missing includes in wx/ sooner > or later. In that case, consult $WXDIR/docs/BUILD.txt for information on > how to swith off dependencies. > > *** > > Paul Kelly wrote: >> On Sat, 4 Aug 2007, Benjamin Ducke wrote: >> >>> This looks great and I have been wanting to try wxGRASS for some time >>> now, however on my Gentoo linux system I have actually never been able >>> to get wxPython to run. >> >> I got it installed and working on Slackware 12.0 a couple of weeks ago. >> Some info below. >> >>> Maybe someone could help me clarify some issues. >>> >>> 1. I don't understand the relation between wxWindows, wxWidgets and >>> wxPython. The wxWidgets site claims to have GUI libs with python >>> support. If I install them, I get libs, header files and a config >>> script called wx-config. That's OK. But why does the wxPython distro >>> install those same files again? It also comes with a config script >>> called wx-config and installs headers and include files in the same >>> location as wxWidgets, even with the same names and same version >>> numbers. I am confused ... >> >> You just need to download the large 25MB or so file from wxPython and >> all the other stuff comes with it. I suppose it gets complicated if you >> have a different version of Wxwindows/wxwidgets installed already. >> Luckily I was doing a clean installation. >> >>> 2. The build and install instructions for wxPythons are a mess. >>> From those two documents, I just can't seem to figure out how to >>> make a global build and install from source. I manage to compile >> >> I agree they are far more complicated than necessary. Seems like very >> minimal effort has been put into making compilation and installation of >> the package simple. FWIW, here are my (simplified) instructions which >> worked for me: >> >> Download combined Wxwidgets/Wxpython package from Wxpython website >> (approx. 25MB) >> Untar and cd into WxwidgetsDir >> mkdir bld >> cd bld >> ../configure --enable-optimise --with-opengl >> (If you don't enable OpenGL you get problems with the wxPython install >> later >> as it seems to assume OpenGL is enabled...) >> make >> make -C contrib/src/gizmos >> make -C contrib/src/stc >> sudo make install >> sudo make -C contrib/src/gizmos install >> sudo make -C contrib/src/stc install >> cd ../wxPython >> Edit config.py to say WX_CONFIG = "wx-config" or else warnings about having >> only one config environment seem to confuse the next bit >> sudo python setup.py install >> >> and that was it. Hope it is useful to someone - meant to post it earlier >> but forgot, sorry. >> >> Paul >> >> >> > > __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 michael.barton at asu.edu Mon Aug 6 06:19:13 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Aug 6 06:19:21 2007 Subject: [GRASS-dev] rename 'wxgrass'? Message-ID: We've been calling the wxPython interface to GRASS 'wxgrass' for the past 6 months or so. This is an informal reference and simply the name of the BASH script used to start the GUI. We came up with this to do something different from the current GUI init script "gis.m". However, before we begin distributing this GUI with GRASS, I think we should change the name of the script and how we reference this GUI. This past spring, it came to my attention that Francisco Alonso, Universidad de Murcia, has developed an application with a wxPython interface that incorporates GRASS commands. He calls this wxGRASS. It has been presented at a GIS conference in Spain and it's web site is here: . It is a nice application with some good interface ideas. I and others have been in contact with Francisco and exchanged information about our wxPython interfaces. If time permits, he may even help with some of the GUI coding eventually. Since he has used the term wxGRASS first, I think we should use another name our our GUI init script and informal reference to the wxPython interface for GRASS so as not to cause confusion. I'm open to suggestions. Here are some initial ideas I've had: wxpg, wxpgrass, grasswx, grassgui (this could be the generic calling script for whatever is the current GRASS GUI), wxgui, wxpgui. Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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/20070805/3046ecc7/attachment.html From michael.barton at asu.edu Mon Aug 6 06:27:58 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Aug 6 06:28:07 2007 Subject: [GRASS-dev] module dialogs in wxPython Message-ID: Daniel and Glynn, What would it take to have a module come up in the wxPython version of the autogenerated dialog if GRASS_GUI is set to wx in .grassrc6? I think this discussion got started sometime back, but wasn't resolved. I think we're close enough to begin distributing the new GUI as an alternate interface for people to use, beginning the transition to wxPython, that we could think about what is needed to do this. Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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/20070805/81b61683/attachment.html From wolf+grass at bergenheim.net Mon Aug 6 08:39:49 2007 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Mon Aug 6 08:40:26 2007 Subject: [GRASS-dev] Re: [GRASSGUI] rename 'wxgrass'? In-Reply-To: References: Message-ID: <46B6C235.3060209@bergenheim.net> On 06.08.2007 07:19, Michael Barton wrote: > We've been calling the wxPython interface to GRASS 'wxgrass' for the .... > > Here are some initial ideas I've had: wxpg, wxpgrass, grasswx, grassgui > (this could be the generic calling script for whatever is the current > GRASS GUI), wxgui, wxpgui. I think it is the GRASS GUI, and should be called that. Who cares whet programming language it was made in or what toolkit it uses. The TCL GUI could be called old GUI when we switch. Until that time talking about the new GUI and the old GUI should be pretty clear to everybody. --Wolf -- <:3 )---- Wolf Bergenheim ----( 8:> From wollez at gmx.net Mon Aug 6 10:01:39 2007 From: wollez at gmx.net (WolfgangZ) Date: Mon Aug 6 10:01:54 2007 Subject: [GRASS-dev] rename 'wxgrass'? In-Reply-To: References: Message-ID: Michael Barton schrieb: > We've been calling the wxPython interface to GRASS 'wxgrass' for the > past 6 months or so. This is an informal reference and simply the name > of the BASH script used to start the GUI. We came up with this to do > something different from the current GUI init script "gis.m". > > However, before we begin distributing this GUI with GRASS, I think we > should change the name of the script and how we reference this GUI. This > past spring, it came to my attention that Francisco Alonso, Universidad > de Murcia, has developed an application with a wxPython interface that > incorporates GRASS commands. He calls this wxGRASS. It has been > presented at a GIS conference in Spain and it's web site is here: > . > > It is a nice application with some good interface ideas. I and others > have been in contact with Francisco and exchanged information about our > wxPython interfaces. If time permits, he may even help with some of the > GUI coding eventually. > > Since he has used the term wxGRASS first, I think we should use another > name our our GUI init script and informal reference to the wxPython > interface for GRASS so as not to cause confusion. I'm open to suggestions. > > Here are some initial ideas I've had: wxpg, wxpgrass, grasswx, grassgui > (this could be the generic calling script for whatever is the current > GRASS GUI), wxgui, wxpgui. > > Michael Hello, I'm more or less only a temporal grass user, but I would also prefer Grass Gui or when this is too long g.gui . Regards Wolfgang From florian.kindl at uibk.ac.at Mon Aug 6 10:12:39 2007 From: florian.kindl at uibk.ac.at (Florian Kindl) Date: Mon Aug 6 10:24:18 2007 Subject: [GRASS-dev] rename 'wxgrass'? In-Reply-To: References: Message-ID: <20070806081239.GB13061@uibk.ac.at> > Michael Barton schrieb: > >Here are some initial ideas I've had: wxpg, wxpgrass, grasswx, grassgui > >(this could be the generic calling script for whatever is the current > >GRASS GUI), wxgui, wxpgui. +1 for the generic grassgui script. I think, it can?t get more precise. wxpg and the like sound to me like w-x-postgres... If, for whatever reason, there were _several_ guis, grassgui could start either of these by a switch: grassgui --wx (default) grassgui --tcl grassgui --qt ... 0.02 cent of a long-time lurker, \flo -- Mag. Florian Kindl Institute of Geography University of Innsbruck From benjamin.ducke at ufg.uni-kiel.de Mon Aug 6 12:40:48 2007 From: benjamin.ducke at ufg.uni-kiel.de (benjamin.ducke@ufg.uni-kiel.de) Date: Mon Aug 6 12:40:51 2007 Subject: [GRASS-dev] wxgrass intro screen and location wizard completed In-Reply-To: References: Message-ID: <4976.144.82.106.54.1186396848.squirrel@webmail.mail.uni-kiel.de> Sure, if you would like to post my instructions: go ahead and do it. I have no idea about Wikis and how they work (or how the heck you are supossed to find a piece of information on one of them) ... Ben > What do you think about posting your and Paul's installation information > to > the GRASS WIKI in the Python GUI section? > > Michael > > > On 8/5/07 12:17 PM, "Benjamin Ducke" > wrote: > >> Paul, Glynn, Michael and all >> >> thanks for the hints, meanwhile I have figured out how to get >> things working on my Gentoo Linux box and the glitches I faced >> were pretty much the same you described. In case it will help >> anyone in the future, here are my notes for an installation of >> wxGRASS on Gentoo linux (or any other Linux distro from scratch, >> I guess): >> >> *** >> >> wxGRASS on Linux with wxPython from scratch: >> >> This GUI is based completely on interpreted Python code. No compilation >> is required. GUI libs used are wxPython: >> >> http://www.wxpython.org/ >> >> ... this includes a copy of the basic wxWindows widgets with the same >> version number as the wxPython distribution. So no need to install >> wxWindows/wxWdigets separately. >> >> Problem: can create a real mess because there seem to be some steps >> that assume that a unicode build has been made and other that assume >> a plain ANSI build! If the two get mixed up, compilation will fail >> at some point complaining about missing include files in wx/ because >> the configure script is not pointing to the right build directory. >> >> Solution: create a UNICODE build and make sure there is nothing lying >> around that still points to an ANSI build. >> >> Step ONE: build main wxWidgets libs (will be done in subdirectory 'bld' >> in main >> wxPython sources dir). >> >> extract archive to $WXDIR, configure (NOTE: change --prefix= to wherever >> your Python stuff and system libs are globally installed), build and >> install: >> >> mkdir $WXDIR/bld >> cd $WXDIR/bld >> ../configure --prefix=/usr --with-gtk --without-gnomeprint --with-opengl >> --enable-geometry --enable-graphics_ctx --enable-sound --with-sdl >> --enable-mediactrl --enable-display --enable-optimize --enable-unicode >> make >> sudo make install >> exit >> >> (NOTE: I disabled gnomeprint on my system, because it kept dumping >> a stupid "IPP" related error message on my console; you might want >> to set other options to better suit your system) >> >> Now we need to make some contributed extensions. These are skipped by >> the main Makefile but will likely be needed later. Make sure you are in >> the 'bld' subdirectory. >> >> cd contrib >> make >> sudo make install >> exit >> >> This should have taken care to install all headers and libaries in >> the system-wide locations. Confirm that all is working by doing: >> >> wx-config --version >> >> and >> >> wx-config --list >> >> The version displayed by the first command needs to be the same as that >> of the wxPython you are installing. If not, there is an old version of >> wxWidgets floating around that you should deinstall (note: wx 2.8 has >> wx 2.6 compatibility enabled by default). >> >> The second command should list just one wx configuration, namely the >> current UNICODE build. If it shows more, there are other builds in >> /usr/lib/wx/config and /usr/lib/wx/include. You may want to delete >> these. >> >> Step TWO: create and install system-wide Python bindings for wx. >> >> The Python extensions have to be made with superuser rights for a >> system-wide install: >> >> cd $WXDIR/wxPython >> sudo python setup.py install >> >> NOTE: setup.py is a little bit dumb. It assumes that you are doing a >> unicode build and that the extensions from the 'contrib' dir have been >> installed. If you followed the above instructions precisely, all should >> work. If not, you will get errors about missing includes in wx/ sooner >> or later. In that case, consult $WXDIR/docs/BUILD.txt for information on >> how to swith off dependencies. >> >> *** >> >> Paul Kelly wrote: >>> On Sat, 4 Aug 2007, Benjamin Ducke wrote: >>> >>>> This looks great and I have been wanting to try wxGRASS for some time >>>> now, however on my Gentoo linux system I have actually never been able >>>> to get wxPython to run. >>> >>> I got it installed and working on Slackware 12.0 a couple of weeks ago. >>> Some info below. >>> >>>> Maybe someone could help me clarify some issues. >>>> >>>> 1. I don't understand the relation between wxWindows, wxWidgets and >>>> wxPython. The wxWidgets site claims to have GUI libs with python >>>> support. If I install them, I get libs, header files and a config >>>> script called wx-config. That's OK. But why does the wxPython distro >>>> install those same files again? It also comes with a config script >>>> called wx-config and installs headers and include files in the same >>>> location as wxWidgets, even with the same names and same version >>>> numbers. I am confused ... >>> >>> You just need to download the large 25MB or so file from wxPython and >>> all the other stuff comes with it. I suppose it gets complicated if you >>> have a different version of Wxwindows/wxwidgets installed already. >>> Luckily I was doing a clean installation. >>> >>>> 2. The build and install instructions for wxPythons are a mess. >>>> From those two documents, I just can't seem to figure out how to >>>> make a global build and install from source. I manage to compile >>> >>> I agree they are far more complicated than necessary. Seems like very >>> minimal effort has been put into making compilation and installation of >>> the package simple. FWIW, here are my (simplified) instructions which >>> worked for me: >>> >>> Download combined Wxwidgets/Wxpython package from Wxpython website >>> (approx. 25MB) >>> Untar and cd into WxwidgetsDir >>> mkdir bld >>> cd bld >>> ../configure --enable-optimise --with-opengl >>> (If you don't enable OpenGL you get problems with the wxPython install >>> later >>> as it seems to assume OpenGL is enabled...) >>> make >>> make -C contrib/src/gizmos >>> make -C contrib/src/stc >>> sudo make install >>> sudo make -C contrib/src/gizmos install >>> sudo make -C contrib/src/stc install >>> cd ../wxPython >>> Edit config.py to say WX_CONFIG = "wx-config" or else warnings about >>> having >>> only one config environment seem to confuse the next bit >>> sudo python setup.py install >>> >>> and that was it. Hope it is useful to someone - meant to post it >>> earlier >>> but forgot, sorry. >>> >>> Paul >>> >>> >>> >> >> > > __________________________________________ > Michael Barton, Professor of Anthropology > Director of Graduate Studies > 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 cdavilam at jemila.jazztel.es Mon Aug 6 17:23:52 2007 From: cdavilam at jemila.jazztel.es (=?ISO-8859-1?Q?Carlos_D=E1vila?=) Date: Mon Aug 6 17:19:12 2007 Subject: [GRASS-dev] problems compiling r.neighbors In-Reply-To: References: Message-ID: <46B73D08.6060301@jemila.jazztel.es> Michael Barton escribi?: > I just did a cvs update and tried to compile GRASS. I did a make > distclean. > > I got the following error compilng r.neighbors. > > cmb-MBP:~/grass_dev/grass6 cmbarton$ cd ./raster/r.neighbors > cmb-MBP:~/grass_dev/grass6/raster/r.neighbors cmbarton$ make > gcc > -L/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.10.1/lib > -DPACKAGE=\""grassmods"\" -o > /Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.10.1/bin/r.neighbors > OBJ.i686-apple-darwin8.10.1/bufs.o > OBJ.i686-apple-darwin8.10.1/divr_cats.o > OBJ.i686-apple-darwin8.10.1/gather.o > OBJ.i686-apple-darwin8.10.1/intr_cats.o > OBJ.i686-apple-darwin8.10.1/main.o > OBJ.i686-apple-darwin8.10.1/null_cats.o > OBJ.i686-apple-darwin8.10.1/readcell.o -lgrass_stats -lgrass_gis > -lgrass_datetime -lz -lgrass_gis -lgrass_datetime -lz -lz > /usr/bin/ld: Undefined symbols: > _read_weights > collect2: ld returned 1 exit status > make: *** > [/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.10.1/bin/r.neighbors] > Error 1 > cmb-MBP:~/grass_dev/grass6/raster/r.neighbors cmbarton$ I have the same problem. Last changes in r.neighbors seem to have generated some problems. Carlos From cavallini at faunalia.it Mon Aug 6 17:25:04 2007 From: cavallini at faunalia.it (Paolo Cavallini) Date: Mon Aug 6 17:25:13 2007 Subject: [GRASS-dev] layers added to wxgrass In-Reply-To: References: Message-ID: <46B73D50.5020406@faunalia.it> I should add r.li to the list: currently it depends on TclTk for setup, but it should not be too difficult to switch the GUI to wxPython. Thanks for your work. All the best. pc Michael Barton ha scritto: > AFAICT, the GUI in wxPython now has equivalent (or better) functionality > than the TclTk one with the following exceptions: > digitizing - actively under development > georectifying - next on my list > nviz - could really use some expertise in openGL to reconceptualize and > implement this. > > Michael -- Paolo Cavallini, see: http://www.faunalia.it/pc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070806/b95e3c59/signature.bin From neteler at itc.it Mon Aug 6 17:29:39 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Aug 6 17:29:40 2007 Subject: [GRASS-dev] problems compiling r.neighbors In-Reply-To: <46B73D08.6060301@jemila.jazztel.es> References: <46B73D08.6060301@jemila.jazztel.es> Message-ID: <20070806152938.GE28800@bartok.itc.it> On Mon, Aug 06, 2007 at 05:23:52PM +0200, Carlos D?vila wrote: > Michael Barton escribi?: ... >> /usr/bin/ld: Undefined symbols: >> _read_weights >> collect2: ld returned 1 exit status >> make: *** >> [/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.10.1/bin/r.neighbors] >> Error 1 >> cmb-MBP:~/grass_dev/grass6/raster/r.neighbors cmbarton$ > I have the same problem. Last changes in r.neighbors seem to have generated > some problems. I think that file read_weights.c wasn't submitted to CVS. Markus From glynn at gclements.plus.com Mon Aug 6 18:18:16 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Aug 6 18:18:27 2007 Subject: [GRASS-dev] Re: [GRASSGUI] module dialogs in wxPython In-Reply-To: References: Message-ID: <18103.18888.184830.114757@cerise.gclements.plus.com> Michael Barton wrote: > What would it take to have a module come up in the wxPython version of the > autogenerated dialog if GRASS_GUI is set to wx in .grassrc6? I think this > discussion got started sometime back, but wasn't resolved. It needs: 1. A Python equivalent of lib/gis/gui.tcl. 2. A Python equivalent of generate_tcl(), unless you make #1 accept XML, in which case G_usage_xml() can be used. 3. Some changes to G_gui() to select the desired GUI based upon $GRASS_GUI. #1 is the main part; the rest is straightforward. -- Glynn Clements From glynn at gclements.plus.com Mon Aug 6 18:19:35 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Aug 6 18:19:37 2007 Subject: [GRASS-dev] problems compiling r.neighbors In-Reply-To: <20070806152938.GE28800@bartok.itc.it> References: <46B73D08.6060301@jemila.jazztel.es> <20070806152938.GE28800@bartok.itc.it> Message-ID: <18103.18967.457001.12407@cerise.gclements.plus.com> Markus Neteler wrote: > >> /usr/bin/ld: Undefined symbols: > >> _read_weights > >> collect2: ld returned 1 exit status > >> make: *** > >> [/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.10.1/bin/r.neighbors] > >> Error 1 > >> cmb-MBP:~/grass_dev/grass6/raster/r.neighbors cmbarton$ > > I have the same problem. Last changes in r.neighbors seem to have generated > > some problems. > > I think that file read_weights.c wasn't submitted to CVS. That's correct; sorry. It's there now. -- Glynn Clements From michael.barton at asu.edu Mon Aug 6 19:15:55 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Aug 6 19:16:07 2007 Subject: [GRASS-dev] Re: [GRASSGUI] module dialogs in wxPython In-Reply-To: <18103.18888.184830.114757@cerise.gclements.plus.com> Message-ID: On 8/6/07 9:18 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> What would it take to have a module come up in the wxPython version of the >> autogenerated dialog if GRASS_GUI is set to wx in .grassrc6? I think this >> discussion got started sometime back, but wasn't resolved. > > It needs: > > 1. A Python equivalent of lib/gis/gui.tcl. This exists. menform.py > > 2. A Python equivalent of generate_tcl(), unless you make #1 accept > XML, in which case G_usage_xml() can be used. menuform accepts and parses xml generated by --interface-description Futzing around with this, I was able to get a wxPython last night dialog by entering: python $GISBASE/etc/wx/gui_modules/menuform.py > > 3. Some changes to G_gui() to select the desired GUI based upon > $GRASS_GUI. So it seems to be down to #3 > > #1 is the main part; the rest is straightforward. Excellent Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 carlos.grohmann at gmail.com Mon Aug 6 20:37:57 2007 From: carlos.grohmann at gmail.com (=?ISO-8859-1?Q?Carlos_"Gu=E2no"_Grohmann?=) Date: Mon Aug 6 20:38:01 2007 Subject: [GRASS-dev] Re: [GRASSGUI] module dialogs in wxPython In-Reply-To: References: <18103.18888.184830.114757@cerise.gclements.plus.com> Message-ID: > > Futzing around with this, I was able to get a wxPython last night dialog by > entering: > > python $GISBASE/etc/wx/gui_modules/menuform.py > Indeed! I just use the line above to run a script I made, and I got a dialog with three tabs, one for main, one for options, and one for output. really nice congrats Carlos -- +-----------------------------------------------------------+ Carlos Henrique Grohmann - Guano Visiting Researcher at Kingston University London - UK Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - carlos dot grohmann at gmail dot com +-----------------------------------------------------------+ _________________ "Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive." --The winning entry in a "What were HAL's first words" contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke Can't stop the signal. From carlos.grohmann at gmail.com Tue Aug 7 00:19:37 2007 From: carlos.grohmann at gmail.com (=?ISO-8859-1?Q?Carlos_"Gu=E2no"_Grohmann?=) Date: Tue Aug 7 00:19:40 2007 Subject: [GRASS-dev] zomm issue with wx GUI Message-ID: Just been paly around with the wx gui. Works fine, but there are some issues: if I hit crtl+d inthe terminal (as I usually do to exit grass), the gui remains open. and if I exit the gui (file-exit) the grass session remains open in the terminal. BTW, I am using it as the main gui, called from .grassrc6 Now the main one. If I set the zoom to some map, I don't get the whole map in the display! see the pictures to compare what happens in wx and tcl guis http://www.igc.usp.br/pessoais/guano/temp/tcl.jpg http://www.igc.usp.br/pessoais/guano/temp/wx.jpg (I put the images in this server because I'm not sure whats the limit for the dev list, although they are quite small) Carlos -- +-----------------------------------------------------------+ Carlos Henrique Grohmann - Guano Visiting Researcher at Kingston University London - UK Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - carlos dot grohmann at gmail dot com +-----------------------------------------------------------+ _________________ "Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive." --The winning entry in a "What were HAL's first words" contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke Can't stop the signal. From michael.barton at asu.edu Tue Aug 7 07:44:12 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Aug 7 07:44:25 2007 Subject: [GRASS-dev] Re: wx init.sh needs updating In-Reply-To: Message-ID: William, I thought that the cvs version of init.sh was the one to use now. Please go ahead and make the one further change. We should get rid of the init.sh in the svn repository and instructions that say to use it. If you take care of init.sh in the cvs, I'll take care of the svn version. Thanks for noticing this. I started messing around with a python replacement for init.sh, just to see what is needed. It is going pretty well, but tedious. Once done (and probably won't work right off) it could be a good opportunity to clean up the start up script for GRASS. Thinking ahead to a time when the same script can start GRASS on all platforms. Michael On 8/6/07 10:14 PM, "William Kyngesburye" wrote: > Just found some time to take a look at wxgrass again. The init.sh in > the svn gui source needs to be updated - there are a bunch of updates > missing, so if someone overwrites their existing init.sh per the > readme, the updates will be lost. > > I see that most of the wx changes are already in the GRASS cvs > init.sh. The other option would be to update the readme install > instructions - with one update to the CVS init.sh, this step could be > removed. The one difference I found is the message about restarting/ > starting the gui. This would take care of the different gui cases (I > left out d.m): > > case "$GRASS_GUI" in > tcltk | gis.m) > echo "If required, restart the graphical user interface > with: gis.m" > ;; > wx) > echo "If required, restart the graphical user interface > with: wxgrass &" > ;; > *) > echo "Start the graphical user interface with: gis.m" > ;; > esac > > (I could apply that if you like.) > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > Theory of the Universe > > There is a theory which states that if ever anyone discovers exactly > what the universe is for and why it is here, it will instantly > disappear and be replaced by something even more bizarrely > inexplicable. There is another theory which states that this has > already happened. > > -Hitchhiker's Guide to the Galaxy 2nd season intro > > __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From benjamin.ducke at ufg.uni-kiel.de Tue Aug 7 10:53:56 2007 From: benjamin.ducke at ufg.uni-kiel.de (benjamin.ducke@ufg.uni-kiel.de) Date: Tue Aug 7 10:53:59 2007 Subject: [GRASS-dev] zomm issue with wx GUI In-Reply-To: References: Message-ID: <1975.144.82.106.51.1186476836.squirrel@webmail.mail.uni-kiel.de> I can confirm both these issues (on Gentoo Linux). If I leave a wx monitor open, after I quit GRASS, I will not be able to close it at all and have to kill the underlying process. If however, I also leave the main manager window open, then I will be able to close that and it will in turn close open map windows, even if I exited the GRASS shell already. I observe the same problem with zooming. Additionally, the manual pages in the wx module dialogs do not show any bitmaps. But this may be a problem with my own wxPython setup. Benjamin > Just been paly around with the wx gui. Works fine, but there are some > issues: > > if I hit crtl+d inthe terminal (as I usually do to exit grass), the > gui remains open. and if I exit the gui (file-exit) the grass session > remains open in the terminal. > BTW, I am using it as the main gui, called from .grassrc6 > > Now the main one. If I set the zoom to some map, I don't get the whole > map in the display! see the pictures to compare what happens in wx and > tcl guis > > http://www.igc.usp.br/pessoais/guano/temp/tcl.jpg > http://www.igc.usp.br/pessoais/guano/temp/wx.jpg > (I put the images in this server because I'm not sure whats the limit > for the dev list, although they are quite small) > > Carlos > > -- > +-----------------------------------------------------------+ > Carlos Henrique Grohmann - Guano > Visiting Researcher at Kingston University London - UK > Geologist M.Sc - Doctorate Student at IGc-USP - Brazil > Linux User #89721 - carlos dot grohmann at gmail dot com > +-----------------------------------------------------------+ > _________________ > "Good morning, doctors. I have taken the liberty of removing Windows > 95 from my hard drive." > --The winning entry in a "What were HAL's first words" contest judged > by 2001: A SPACE ODYSSEY creator Arthur C. Clarke > > Can't stop the signal. > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > > From carlos.grohmann at gmail.com Tue Aug 7 10:58:45 2007 From: carlos.grohmann at gmail.com (=?ISO-8859-1?Q?Carlos_"Gu=E2no"_Grohmann?=) Date: Tue Aug 7 10:58:48 2007 Subject: [GRASS-dev] zomm issue with wx GUI In-Reply-To: <1975.144.82.106.51.1186476836.squirrel@webmail.mail.uni-kiel.de> References: <1975.144.82.106.51.1186476836.squirrel@webmail.mail.uni-kiel.de> Message-ID: I'm missing the bitmaps in man pages as well. I'm also missing the 'overwrite' option (only tried r.in.gdal) Carlos On 8/7/07, benjamin.ducke@ufg.uni-kiel.de wrote: > I can confirm both these issues (on Gentoo Linux). > > If I leave a wx monitor open, after I quit GRASS, I will > not be able to close it at all and have to kill the underlying > process. If however, I also leave the main manager window open, > then I will be able to close that and it will in turn close > open map windows, even if I exited the GRASS shell already. > > I observe the same problem with zooming. > > Additionally, the manual pages in the wx module dialogs do not > show any bitmaps. But this may be a problem with my own wxPython > setup. > > Benjamin > > > Just been paly around with the wx gui. Works fine, but there are some > > issues: > > > > if I hit crtl+d inthe terminal (as I usually do to exit grass), the > > gui remains open. and if I exit the gui (file-exit) the grass session > > remains open in the terminal. > > BTW, I am using it as the main gui, called from .grassrc6 > > > > Now the main one. If I set the zoom to some map, I don't get the whole > > map in the display! see the pictures to compare what happens in wx and > > tcl guis > > > > http://www.igc.usp.br/pessoais/guano/temp/tcl.jpg > > http://www.igc.usp.br/pessoais/guano/temp/wx.jpg > > (I put the images in this server because I'm not sure whats the limit > > for the dev list, although they are quite small) > > > > Carlos > > > > -- > > +-----------------------------------------------------------+ > > Carlos Henrique Grohmann - Guano > > Visiting Researcher at Kingston University London - UK > > Geologist M.Sc - Doctorate Student at IGc-USP - Brazil > > Linux User #89721 - carlos dot grohmann at gmail dot com > > +-----------------------------------------------------------+ > > _________________ > > "Good morning, doctors. I have taken the liberty of removing Windows > > 95 from my hard drive." > > --The winning entry in a "What were HAL's first words" contest judged > > by 2001: A SPACE ODYSSEY creator Arthur C. Clarke > > > > Can't stop the signal. > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev > > > > > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- +-----------------------------------------------------------+ Carlos Henrique Grohmann - Guano Visiting Researcher at Kingston University London - UK Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - carlos dot grohmann at gmail dot com +-----------------------------------------------------------+ _________________ "Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive." --The winning entry in a "What were HAL's first words" contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke Can't stop the signal. From hamish_nospam at yahoo.com Tue Aug 7 12:33:51 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Aug 7 12:33:57 2007 Subject: [GRASS-dev] rename 'wxgrass'? In-Reply-To: Message-ID: <72422.48989.qm@web52703.mail.re2.yahoo.com> > We've been calling the wxPython interface to GRASS 'wxgrass' for the past 6 > months or so. and it's pretty good. Also consider the 'pygrass' combinations. The g.gui suggestion is nice too. Simple and to the point. 2c, Hamish ____________________________________________________________________________________ Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool. http://autos.yahoo.com/carfinder/ From woklist at kyngchaos.com Tue Aug 7 16:24:35 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Tue Aug 7 16:24:52 2007 Subject: [GRASS-dev] Re: wx init.sh needs updating In-Reply-To: References: Message-ID: Done. On Aug 7, 2007, at 12:44 AM, Michael Barton wrote: > William, > > I thought that the cvs version of init.sh was the one to use now. > Please go > ahead and make the one further change. We should get rid of the > init.sh in > the svn repository and instructions that say to use it. If you take > care of > init.sh in the cvs, I'll take care of the svn version. Thanks for > noticing > this. ... > On 8/6/07 10:14 PM, "William Kyngesburye" > wrote: >> I see that most of the wx changes are already in the GRASS cvs >> init.sh. The other option would be to update the readme install >> instructions - with one update to the CVS init.sh, this step could be >> removed. The one difference I found is the message about restarting/ >> starting the gui. This would take care of the different gui cases (I >> left out d.m): >> >> case "$GRASS_GUI" in >> tcltk | gis.m) >> echo "If required, restart the graphical user interface >> with: gis.m" >> ;; >> wx) >> echo "If required, restart the graphical user interface >> with: wxgrass &" >> ;; >> *) >> echo "Start the graphical user interface with: gis.m" >> ;; >> esac >> >> (I could apply that if you like.) >> ----- William Kyngesburye http://www.kyngchaos.com/ Theory of the Universe There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened. -Hitchhiker's Guide to the Galaxy 2nd season intro From michael.barton at asu.edu Tue Aug 7 17:32:30 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Aug 7 17:32:37 2007 Subject: [GRASS-dev] Re: wx init.sh needs updating In-Reply-To: Message-ID: I also took care of the README and deleted the old init.sh from the SVN gui folder. Michael On 8/7/07 7:24 AM, "William Kyngesburye" wrote: > Done. > > On Aug 7, 2007, at 12:44 AM, Michael Barton wrote: > >> William, >> >> I thought that the cvs version of init.sh was the one to use now. >> Please go >> ahead and make the one further change. We should get rid of the >> init.sh in >> the svn repository and instructions that say to use it. If you take >> care of >> init.sh in the cvs, I'll take care of the svn version. Thanks for >> noticing >> this. > ... >> On 8/6/07 10:14 PM, "William Kyngesburye" >> wrote: >>> I see that most of the wx changes are already in the GRASS cvs >>> init.sh. The other option would be to update the readme install >>> instructions - with one update to the CVS init.sh, this step could be >>> removed. The one difference I found is the message about restarting/ >>> starting the gui. This would take care of the different gui cases (I >>> left out d.m): >>> >>> case "$GRASS_GUI" in >>> tcltk | gis.m) >>> echo "If required, restart the graphical user interface >>> with: gis.m" >>> ;; >>> wx) >>> echo "If required, restart the graphical user interface >>> with: wxgrass &" >>> ;; >>> *) >>> echo "Start the graphical user interface with: gis.m" >>> ;; >>> esac >>> >>> (I could apply that if you like.) >>> > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > Theory of the Universe > > There is a theory which states that if ever anyone discovers exactly > what the universe is for and why it is here, it will instantly > disappear and be replaced by something even more bizarrely > inexplicable. There is another theory which states that this has > already happened. > > -Hitchhiker's Guide to the Galaxy 2nd season intro > > __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 michael.barton at asu.edu Tue Aug 7 17:57:17 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Aug 7 17:57:23 2007 Subject: [GRASS-dev] zomm issue with wx GUI In-Reply-To: <1975.144.82.106.51.1186476836.squirrel@webmail.mail.uni-kiel.de> Message-ID: Carlos and Benjamin, Thanks much. This is why we need more people to start using and testing the wx GUI. A couple responses below On 8/7/07 1:53 AM, "benjamin.ducke@ufg.uni-kiel.de" wrote: > I can confirm both these issues (on Gentoo Linux). > > If I leave a wx monitor open, after I quit GRASS, I will > not be able to close it at all and have to kill the underlying > process. If however, I also leave the main manager window open, > then I will be able to close that and it will in turn close > open map windows, even if I exited the GRASS shell already. How do you manage to keep a map display open and close the main window? My guess is that this is what is causing things to hang, not closing GRASS. Whenever I close the layer manager, all other GUI windows close too. This is what they are supposed to do. Probably, when you are closing the layer manager first and the map display is NOT closing, it is hanging waiting for *something* (I don't know what) in order to shut the whole GUI down. Do you get any python error messages eventually? This might help us track down why the GUI is not closing all windows as it should. > > I observe the same problem with zooming. I also can confirm this. It seems to be a more general issue in that the map gets resized to fit in the window horizontally, but not vertically. That is, if you make a tall, skinny map display and zoom to the map, it fits in horizontally (leaving a lot of white space on the top and bottom). But if you make a short, wide map display, the fitting does not work correctly. My colleagues on the GUI team seem to be out doing real work somewhere and I'm facing the need to do the same with classes starting shortly. But I'll try to track this down. > > Additionally, the manual pages in the wx module dialogs do not > show any bitmaps. But this may be a problem with my own wxPython > setup. I noticed this some time back and reported it to Daniel Cavelo, who is overseeing this part of the GUI. He has tracked down how to fix it but noted that if you click on of the links on a manual page, the new page WILL show the bitmaps. Something is not getting initialized somewhere. Especially for pages where someone has gone to the trouble of creating graphics, we need to get this resolved. Thanks again for the reports. Michael > > Benjamin > >> Just been paly around with the wx gui. Works fine, but there are some >> issues: >> >> if I hit crtl+d inthe terminal (as I usually do to exit grass), the >> gui remains open. and if I exit the gui (file-exit) the grass session >> remains open in the terminal. >> BTW, I am using it as the main gui, called from .grassrc6 >> >> Now the main one. If I set the zoom to some map, I don't get the whole >> map in the display! see the pictures to compare what happens in wx and >> tcl guis >> >> http://www.igc.usp.br/pessoais/guano/temp/tcl.jpg >> http://www.igc.usp.br/pessoais/guano/temp/wx.jpg >> (I put the images in this server because I'm not sure whats the limit >> for the dev list, although they are quite small) >> >> Carlos >> >> -- >> +-----------------------------------------------------------+ >> Carlos Henrique Grohmann - Guano >> Visiting Researcher at Kingston University London - UK >> Geologist M.Sc - Doctorate Student at IGc-USP - Brazil >> Linux User #89721 - carlos dot grohmann at gmail dot com >> +-----------------------------------------------------------+ >> _________________ >> "Good morning, doctors. I have taken the liberty of removing Windows >> 95 from my hard drive." >> --The winning entry in a "What were HAL's first words" contest judged >> by 2001: A SPACE ODYSSEY creator Arthur C. Clarke >> >> Can't stop the signal. >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev >> >> > > > __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 michael.barton at asu.edu Tue Aug 7 17:58:03 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Aug 7 18:00:24 2007 Subject: [GRASS-dev] problems compiling r.neighbors In-Reply-To: <18103.18967.457001.12407@cerise.gclements.plus.com> Message-ID: Thanks. We'll try compiling again. Michael On 8/6/07 9:19 AM, "Glynn Clements" wrote: > > Markus Neteler wrote: > >>>> /usr/bin/ld: Undefined symbols: >>>> _read_weights >>>> collect2: ld returned 1 exit status >>>> make: *** >>>> [/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.10.1/bin/r.neighb >>>> ors] >>>> Error 1 >>>> cmb-MBP:~/grass_dev/grass6/raster/r.neighbors cmbarton$ >>> I have the same problem. Last changes in r.neighbors seem to have generated >>> some problems. >> >> I think that file read_weights.c wasn't submitted to CVS. > > That's correct; sorry. It's there now. __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 michael.barton at asu.edu Tue Aug 7 18:02:56 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Aug 7 18:03:16 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: <98406.78280.qm@web60521.mail.yahoo.com> Message-ID: This is one of the few items on the Windows native GRASS that doesn't work (apparently some infuriating problems with attribute databases too). >From posts a couple months back, it seems that it DID work in this version early on and then stopped working. This suggests that there should be a way to get it running again. I am planning to use GRASS in a spatial tech class Spring semester and hope this can be resolved. Michael On 8/7/07 2:17 AM, "RAVI KUMAR" wrote: > Hi All, > been trying the latest GRASS 6.3 on windows O/S. > > NVIZ on D.M gives error > 'couldnt execute NVIZ' > > NVIZ on map display just doesnt work.. > Nothing happens when you click on it. > > Ravi Kumar > > > > ______________________________________________________________________________ > ______ > Choose the right car based on your needs. Check out Yahoo! Autos new Car > Finder tool. > http://autos.yahoo.com/carfinder/ > > __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 kyngchaos at kyngchaos.com Tue Aug 7 19:07:33 2007 From: kyngchaos at kyngchaos.com (William Kyngesburye) Date: Tue Aug 7 19:07:47 2007 Subject: [GRASS-dev] Re: wx init.sh needs updating In-Reply-To: References: Message-ID: On Aug 7, 2007, at 12:44 AM, Michael Barton wrote: > I started messing around with a python replacement for init.sh, > just to see > what is needed. It is going pretty well, but tedious. Once done (and > probably won't work right off) it could be a good opportunity to > clean up > the start up script for GRASS. Thinking ahead to a time when the > same script > can start GRASS on all platforms. > > Michael > Yeah, I just noticed a another oddity in init.sh related to wx - the gui dependency test is still based on X. While wxpython on other 'nix platforms may need X, it doesn't on OSX, and probably not on Windows either. Summarized: if DISPLAY set (though it may be set but no X is available, at least on OSX) test gui dependency - python for wx, wish for tcltk if it fails warn that *wish* doesn't work (oops) else no gui possible if a gui is set warn that *X* is not available, and there a gui is not possible (oops again) Instead of testing the gui dependency first, maybe this should test the gui setting first: case GRASS_GUI: tcltk, etc) test X availability or better, ignore DISPLAY and test only wish - if it works, X is implied, or whatever graphical base needed (this would take care of native tcltk implementations, like Aqua or Windows, not that they work well) wx) test python availability (X implied if needed - as long as python works) ...just some thoughts... ----- William Kyngesburye http://www.kyngchaos.com/ "We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty." "Don't you even hate 'em?" "What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the ____ it wouldn't kill one ___ nor shorten the war one day." "And it might give 'em all stomach ulcers." - Tarzan, on war From woklist at kyngchaos.com Tue Aug 7 19:13:04 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Tue Aug 7 19:13:15 2007 Subject: [GRASS-dev] Re: wx init.sh needs updating In-Reply-To: References: Message-ID: <29E479F3-4563-47AF-89BD-E6CD2A9AEF2F@kyngchaos.com> On Aug 7, 2007, at 12:44 AM, Michael Barton wrote: > I started messing around with a python replacement for init.sh, > just to see > what is needed. It is going pretty well, but tedious. Once done (and > probably won't work right off) it could be a good opportunity to > clean up > the start up script for GRASS. Thinking ahead to a time when the > same script > can start GRASS on all platforms. > > Michael > Yeah, I just noticed a another oddity in init.sh related to wx - the gui dependency test is still based on X. While wxpython on other 'nix platforms may need X, it doesn't on OSX, and probably not on Windows either. Summarized: if DISPLAY set (though it may be set but no X is available, at least on OSX) test gui dependency - python for wx, wish for tcltk if it fails warn that *wish* doesn't work (oops) else no gui possible if a gui is set warn that *X* is not available, and there a gui is not possible (oops again) Instead of testing the gui dependency first, maybe this should test the gui setting first: case GRASS_GUI: tcltk, etc) test X availability or better, ignore DISPLAY and test only wish - if it works, X is implied, or whatever graphical base needed (this would take care of native tcltk implementations, like Aqua or Windows, not that they work well) wx) test python availability (X implied if needed - as long as python works) ...just some thoughts... ----- William Kyngesburye http://www.kyngchaos.com/ "We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty." "Don't you even hate 'em?" "What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the ____ it wouldn't kill one ___ nor shorten the war one day." "And it might give 'em all stomach ulcers." - Tarzan, on war ----- William Kyngesburye http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy From glynn at gclements.plus.com Tue Aug 7 19:47:51 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Aug 7 19:48:14 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: References: <98406.78280.qm@web60521.mail.yahoo.com> Message-ID: <18104.45127.468813.123101@cerise.gclements.plus.com> Michael Barton wrote: > > been trying the latest GRASS 6.3 on windows O/S. > > > > NVIZ on D.M gives error > > 'couldnt execute NVIZ' > > > > NVIZ on map display just doesnt work.. > > Nothing happens when you click on it. > > This is one of the few items on the Windows native GRASS that doesn't work > (apparently some infuriating problems with attribute databases too). > > From posts a couple months back, it seems that it DID work in this version > early on and then stopped working. This suggests that there should be a way > to get it running again. It definitely used to work natively on Windows, and I think that it also worked natively on OSX. ISTR a comment that it stopped around the time that Bob changed NVIZ from being a self-contained C module to a combination of a script ($GIBASE/bin/nviz) and a modified wish ($GISBASE/etc/nviz2.2/nviz). That may just be a rumour, though. It would be nice if someone[1] could confirm this, by compiling versions before and after 2006-12-11 for native Windows. -- Glynn Clements From michael.barton at asu.edu Tue Aug 7 21:01:12 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Aug 7 21:01:21 2007 Subject: [GRASS-dev] Re: wx init.sh needs updating In-Reply-To: Message-ID: Sounds like this needs to be updated soon. I'm surprised that it doesn't kick out an error for the native Windows version. Michael On 8/7/07 10:07 AM, "William Kyngesburye" wrote: > On Aug 7, 2007, at 12:44 AM, Michael Barton wrote: > >> I started messing around with a python replacement for init.sh, >> just to see >> what is needed. It is going pretty well, but tedious. Once done (and >> probably won't work right off) it could be a good opportunity to >> clean up >> the start up script for GRASS. Thinking ahead to a time when the >> same script >> can start GRASS on all platforms. >> >> Michael >> > Yeah, I just noticed a another oddity in init.sh related to wx - the > gui dependency test is still based on X. While wxpython on other > 'nix platforms may need X, it doesn't on OSX, and probably not on > Windows either. Summarized: > > if DISPLAY set (though it may be set but no X is available, at least > on OSX) > test gui dependency - python for wx, wish for tcltk > if it fails > warn that *wish* doesn't work (oops) > else > no gui possible > if a gui is set > warn that *X* is not available, and there a gui is not possible > (oops again) > > Instead of testing the gui dependency first, maybe this should test > the gui setting first: > > case GRASS_GUI: > tcltk, etc) > test X availability > or better, ignore DISPLAY and test only wish - if it works, X is > implied, or whatever graphical base needed (this would take care of > native tcltk implementations, like Aqua or Windows, not that they > work well) > wx) > test python availability (X implied if needed - as long as > python works) > > > ...just some thoughts... > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > "We are at war with them. Neither in hatred nor revenge and with no > particular pleasure I shall kill every ___ I can until the war is > over. That is my duty." > > "Don't you even hate 'em?" > > "What good would it do if I did? If all the many millions of people > of the allied nations devoted an entire year exclusively to hating > the ____ it wouldn't kill one ___ nor shorten the war one day." > > "And it might give 'em all stomach ulcers." > > - Tarzan, on war > > __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 at gclements.plus.com Tue Aug 7 21:20:23 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Aug 7 21:20:50 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: <18104.45127.468813.123101@cerise.gclements.plus.com> References: <98406.78280.qm@web60521.mail.yahoo.com> <18104.45127.468813.123101@cerise.gclements.plus.com> Message-ID: <18104.50679.830154.347160@cerise.gclements.plus.com> Glynn Clements wrote: > > > been trying the latest GRASS 6.3 on windows O/S. > > > > > > NVIZ on D.M gives error > > > 'couldnt execute NVIZ' > > > > > > NVIZ on map display just doesnt work.. > > > Nothing happens when you click on it. > > > > This is one of the few items on the Windows native GRASS that doesn't work > > (apparently some infuriating problems with attribute databases too). > > > > From posts a couple months back, it seems that it DID work in this version > > early on and then stopped working. This suggests that there should be a way > > to get it running again. > > It definitely used to work natively on Windows, and I think that it > also worked natively on OSX. > > ISTR a comment that it stopped around the time that Bob changed NVIZ > from being a self-contained C module to a combination of a script > ($GIBASE/bin/nviz) and a modified wish ($GISBASE/etc/nviz2.2/nviz). > > That may just be a rumour, though. It would be nice if someone[1] > could confirm this, by compiling versions before and after 2006-12-11 > for native Windows. Done that. Yep, it's the script; MSys strikes again. I've added an nviz.bat script for use on Windows; I've also fixed the Makefile to ensure that the binary gets the .exe extension. -- Glynn Clements From michael.barton at asu.edu Tue Aug 7 21:23:23 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Aug 7 21:23:33 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: <18104.50679.830154.347160@cerise.gclements.plus.com> Message-ID: Hot dog!! Thanks a million. Michael On 8/7/07 12:20 PM, "Glynn Clements" wrote: > > Glynn Clements wrote: > >>>> been trying the latest GRASS 6.3 on windows O/S. >>>> >>>> NVIZ on D.M gives error >>>> 'couldnt execute NVIZ' >>>> >>>> NVIZ on map display just doesnt work.. >>>> Nothing happens when you click on it. >>> >>> This is one of the few items on the Windows native GRASS that doesn't work >>> (apparently some infuriating problems with attribute databases too). >>> >>> From posts a couple months back, it seems that it DID work in this version >>> early on and then stopped working. This suggests that there should be a way >>> to get it running again. >> >> It definitely used to work natively on Windows, and I think that it >> also worked natively on OSX. >> >> ISTR a comment that it stopped around the time that Bob changed NVIZ >> from being a self-contained C module to a combination of a script >> ($GIBASE/bin/nviz) and a modified wish ($GISBASE/etc/nviz2.2/nviz). >> >> That may just be a rumour, though. It would be nice if someone[1] >> could confirm this, by compiling versions before and after 2006-12-11 >> for native Windows. > > Done that. Yep, it's the script; MSys strikes again. > > I've added an nviz.bat script for use on Windows; I've also fixed the > Makefile to ensure that the binary gets the .exe extension. __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 bcovill at tekmap.ns.ca Tue Aug 7 21:39:39 2007 From: bcovill at tekmap.ns.ca (Bob Covill) Date: Tue Aug 7 21:37:12 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: <18104.50679.830154.347160@cerise.gclements.plus.com> References: <98406.78280.qm@web60521.mail.yahoo.com> <18104.45127.468813.123101@cerise.gclements.plus.com> <18104.50679.830154.347160@cerise.gclements.plus.com> Message-ID: <1186515579.20542.7.camel@linux.site> On Tue, 2007-08-07 at 20:20 +0100, Glynn Clements wrote: > Glynn Clements wrote: > > > > > been trying the latest GRASS 6.3 on windows O/S. > > > > > > > > NVIZ on D.M gives error > > > > 'couldnt execute NVIZ' > > > > > > > > NVIZ on map display just doesnt work.. > > > > Nothing happens when you click on it. > > > > > > This is one of the few items on the Windows native GRASS that doesn't work > > > (apparently some infuriating problems with attribute databases too). > > > > > > From posts a couple months back, it seems that it DID work in this version > > > early on and then stopped working. This suggests that there should be a way > > > to get it running again. > > > > It definitely used to work natively on Windows, and I think that it > > also worked natively on OSX. > > > > ISTR a comment that it stopped around the time that Bob changed NVIZ > > from being a self-contained C module to a combination of a script > > ($GIBASE/bin/nviz) and a modified wish ($GISBASE/etc/nviz2.2/nviz). > > > > That may just be a rumour, though. It would be nice if someone[1] > > could confirm this, by compiling versions before and after 2006-12-11 > > for native Windows. > > Done that. Yep, it's the script; MSys strikes again. > > I've added an nviz.bat script for use on Windows; I've also fixed the > Makefile to ensure that the binary gets the .exe extension. > This implements one of the suggestion I made for Windows back on May 19, 2007 (Subj.: Nviz on native Windows). I guess no one had tested them?? The other suggestion was try directly running nviz2.2_script .... > Another way, which may be a better solution for windows is to edit the > nviz2.2_script file and replace "#!/nviz -f" with "#! > $GISBASE/etc/nviz2.2/nviz -f". You may need to enter the full path for > $GISBASE. After editing the file copy it to $GISBASE/bin/nviz > (overwriting the old nviz script). Make sure it is executable. Run > nviz (formerly nviz2.2_script). -- Bob From glynn at gclements.plus.com Wed Aug 8 09:54:34 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Aug 8 09:55:11 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: <1186515579.20542.7.camel@linux.site> References: <98406.78280.qm@web60521.mail.yahoo.com> <18104.45127.468813.123101@cerise.gclements.plus.com> <18104.50679.830154.347160@cerise.gclements.plus.com> <1186515579.20542.7.camel@linux.site> Message-ID: <18105.30394.757196.332435@cerise.gclements.plus.com> Bob Covill wrote: > > I've added an nviz.bat script for use on Windows; I've also fixed the > > Makefile to ensure that the binary gets the .exe extension. > > This implements one of the suggestion I made for Windows back on May 19, > 2007 (Subj.: Nviz on native Windows). I guess no one had tested them?? Presumably not. This has always been the biggest problem with the Windows and MacOSX ports. Most developers don't use those platforms, and most of the people who do use them aren't developers. > The other suggestion was try directly running nviz2.2_script .... > > Another way, which may be a better solution for windows is to edit the > > nviz2.2_script file and replace "#!/nviz -f" with "#! > > $GISBASE/etc/nviz2.2/nviz -f". You may need to enter the full path for > > $GISBASE. After editing the file copy it to $GISBASE/bin/nviz > > (overwriting the old nviz script). Make sure it is executable. Run > > nviz (formerly nviz2.2_script). Anything involving "#!" won't work natively on Windows. Also, anything involving MSys' bash is asking for trouble. Real portability will likely only be obtained by scrapping the use of Bourne shell in favour of e.g. Python. -- Glynn Clements From mlennert at club.worldonline.be Wed Aug 8 11:07:51 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Aug 8 11:06:36 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: References: Message-ID: <62078.84.190.190.116.1186564071.squirrel@geog-pc40.ulb.ac.be> Thanks Glynn, I won't be able to provide new binaries before Aug. 20, so whoever wants to try this before will have to compile themselves. Moritz On Tue, August 7, 2007 21:23, Michael Barton wrote: > Hot dog!! > > Thanks a million. > > Michael > > > On 8/7/07 12:20 PM, "Glynn Clements" wrote: > >> >> Glynn Clements wrote: >> >>>>> been trying the latest GRASS 6.3 on windows O/S. >>>>> >>>>> NVIZ on D.M gives error >>>>> 'couldnt execute NVIZ' >>>>> >>>>> NVIZ on map display just doesnt work.. >>>>> Nothing happens when you click on it. >>>> >>>> This is one of the few items on the Windows native GRASS that doesn't >>>> work >>>> (apparently some infuriating problems with attribute databases too). >>>> >>>> From posts a couple months back, it seems that it DID work in this >>>> version >>>> early on and then stopped working. This suggests that there should be >>>> a way >>>> to get it running again. >>> >>> It definitely used to work natively on Windows, and I think that it >>> also worked natively on OSX. >>> >>> ISTR a comment that it stopped around the time that Bob changed NVIZ >>> from being a self-contained C module to a combination of a script >>> ($GIBASE/bin/nviz) and a modified wish ($GISBASE/etc/nviz2.2/nviz). >>> >>> That may just be a rumour, though. It would be nice if someone[1] >>> could confirm this, by compiling versions before and after 2006-12-11 >>> for native Windows. >> >> Done that. Yep, it's the script; MSys strikes again. >> >> I've added an nviz.bat script for use on Windows; I've also fixed the >> Makefile to ensure that the binary gets the .exe extension. > > __________________________________________ > Michael Barton, Professor of Anthropology > Director of Graduate Studies > 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 mmaldacker at gmail.com Wed Aug 8 14:20:09 2007 From: mmaldacker at gmail.com (maximilian maldacker) Date: Wed Aug 8 14:20:14 2007 Subject: [GRASS-dev] v.path.obstacles Message-ID: >Hello Wolf and Maximilian, >As promised I have just had a chance to try this - I too am impressed by >how fast it ran - however, it seems to be lacking a facility for entering >the desired start and finish points that the shortest path should be found >between - as far as I can see these need to also be included in the >visiblity graph for it to work properly? I suppose you could manually add >them to the obstacles map before starting, but people might not want to >have to edit it. Hmmm I'm not sure. Yes I've added this functionality. You can add as many points as you want before computing the visibility graph and you can also add points after the graph has been computed and new edges for those points will be computed. But should those new points and edges be added to a copy of the already computed visibility graph or added directly to the computed visibility graph? For now the input is the original file, the vis the computed graph and output a copy of vis with the new points and edges. It doesn't work yet as I get an error message when trying to write new points on the copy. >Nice idea it seems actually keeping the visiblity graph generation out as >a separate module - I guess that is just the logical way the idea >developed in the end? And then you could write a shell script to run this >module (v.net.visiblity sounds like a logical name) to generate a >temporary map and then run other v.net.* modules on it to generate the >shortest path. Have you any ideas/scenarios for how you think it might >eventually be used like this? I've tried using the other v.net.* modules on the generated graph and it works perfectly. So I guess I'll write some examples in the description file. The shell script is a good idea, is there a way to use a script like this directly in the grass command line? >A couple of comments on the code itself - I think it could do with being >compiled with -Wall being added to the EXTRA_CFLAGS to catch compiler >warnings, of which there are currently quite a lot. It seems to be the >general GRASS style to keep function prototypes for functions that are >not local to one file in a separate local_proto.h. Also the indentation, >in main.c anyway where I was reading, is quite inconsistent and makes it a >bit hard to read. There is a suggested set of commandline switches for the >"indent" command in the GRASS SUBMITTING file (top level directory in CVS) >- I'd suggest using this on the source files before they're committed to >CVS. Ok, no problem >But in general, looks good and seems to be quite useful. I would suggest >the example in the man page should show how it can be used in combination >with one of the other v.net.* commands - this wasn't obvious to me at all >at the start. I'll add that. Thanks, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070808/e7901839/attachment-0001.html From glynn at gclements.plus.com Wed Aug 8 14:28:26 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Aug 8 14:28:30 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: <62078.84.190.190.116.1186564071.squirrel@geog-pc40.ulb.ac.be> References: <62078.84.190.190.116.1186564071.squirrel@geog-pc40.ulb.ac.be> Message-ID: <18105.46826.338518.390250@cerise.gclements.plus.com> Moritz Lennert wrote: > >> I've added an nviz.bat script for use on Windows; I've also fixed the > >> Makefile to ensure that the binary gets the .exe extension. > > I won't be able to provide new binaries before Aug. 20, so whoever wants > to try this before will have to compile themselves. Nothing needs to be compiled. The only changes required are to add the the nviz.bat script to the $GISBASE/bin directory and rename the nviz binary (in $GISBASE/etc/nviz2.2) to nviz.exe. The nviz.bat script is just: "%GISBASE%\etc\nviz2.2\nviz.exe" -f "%GISBASE%\etc\nviz2.2\scripts\nviz2.2_script" %* -- Glynn Clements From grass-dev at grass.itc.it Wed Aug 8 19:01:30 2007 From: grass-dev at grass.itc.it (grass-dev@grass.itc.it) Date: Wed Aug 8 18:57:15 2007 Subject: [GRASS-dev] [grass-code I][455] r.proj segfaults after Jul 14 changes Message-ID: <20070808170130.A7AAA4007F@pyrosoma.intevation.org> code I item #455, was opened at 2007-08-08 12:01 Status: Open Priority: 3 Submitted By: William Kyngesburye (kyngchaos) Assigned to: Nobody (None) Summary: r.proj segfaults after Jul 14 changes Issue type: module bug Issue status: None GRASS version: CVS HEAD GRASS component: raster Operating system: MacOS X Operating system version: 10.4 GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: Something happened in the middle of the r.proj.seg->r.proj change that's causing a segfault on OSX. GRASS 6.3.cvs (us83-utm16):~ > r.proj loc=world1k map=globe in=globe met=cubic Input Projection Parameters: +proj=longlat +a=6378137 +rf=298.257223563 +no_defs +towgs84=0.000,0.000,0.000 Input Unit Factor: 1 Output Projection Parameters: +proj=utm +zone=16 +a=6378137 +rf=298.257222101 +no_defs +towgs84=0.000,0.000,0.000 Output Unit Factor: 1 Bus error Thread 0 Crashed: 0 libSystem.B.dylib 0x9000b3c0 __vfprintf + 479 1 libSystem.B.dylib 0x9002989c vsprintf + 476 2 libgrass_gis.dylib 0x00057cc7 G_message + 57 3 r.proj 0x00004003 main + 2209 4 r.proj 0x000024a2 _start + 216 5 r.proj 0x000023c9 start + 41 My build from Jul 14 works for r.proj.seg, but crashes for r.proj. I see in the CVS history that on Jul 14 some "Message/Debug cleaning" was done to r.proj, then probably applied to r.proj.seg on Jul 16 as "Synchronize messages with r.proj", and this seems to agree with the vsfprint crash above. More recent builds (I have one from Jul 30, as well as today), where r.proj.seg is now r.proj, also crash. In main.c of r.proj.seg, if I replace any G_message(NULL) with what it used to be: G_message(""), it doesn't segfault. And G_done_msg(NULL) -> G_done_msg(""). ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=455&group_id=21 From rez at touchofmadness.com Wed Aug 8 19:37:39 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Wed Aug 8 19:37:44 2007 Subject: [GRASS-dev] [grass-code I][455] r.proj segfaults after Jul 14 changes In-Reply-To: <20070808170130.A7AAA4007F@pyrosoma.intevation.org> References: <20070808170130.A7AAA4007F@pyrosoma.intevation.org> Message-ID: <1186594659.22591.278.camel@dev64.localdomain> On Wed, 2007-08-08 at 19:01 +0200, grass-dev@grass.itc.it wrote: > code I item #455, was opened at 2007-08-08 12:01 > Status: Open > Priority: 3 > Submitted By: William Kyngesburye (kyngchaos) > Assigned to: Nobody (None) > Summary: r.proj segfaults after Jul 14 changes > Issue type: module bug > Issue status: None > GRASS version: CVS HEAD > GRASS component: raster > Operating system: MacOS X > Operating system version: 10.4 > GRASS CVS checkout date, if applies (YYMMDD): Fixed in CVS. That was improper usage of G_done_msg() as noticed. -- 73, de Brad KB8UYR/6 From woklist at kyngchaos.com Wed Aug 8 19:54:21 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Wed Aug 8 19:54:26 2007 Subject: [GRASS-dev] [grass-code I][455] r.proj segfaults after Jul 14 changes In-Reply-To: <1186594659.22591.278.camel@dev64.localdomain> References: <20070808170130.A7AAA4007F@pyrosoma.intevation.org> <1186594659.22591.278.camel@dev64.localdomain> Message-ID: Actually, it's more than just G_done_msg - there are a few G_message (NULL) in there, and the r.proj source is really in r.proj.seg, the r.proj source folder is deprecated. Not to mention the other modules I found null messages in, as I mentioned in a followup to the bug report. If (NULL) is indeed improper use of the message functions, I could take care of them - I have my own CVS copy of r.proj.seg updated already, and I found those others already. On Aug 8, 2007, at 12:37 PM, Brad Douglas wrote: > On Wed, 2007-08-08 at 19:01 +0200, grass-dev@grass.itc.it wrote: >> code I item #455, was opened at 2007-08-08 12:01 >> Status: Open >> Priority: 3 >> Submitted By: William Kyngesburye (kyngchaos) >> Assigned to: Nobody (None) >> Summary: r.proj segfaults after Jul 14 changes >> Issue type: module bug >> Issue status: None >> GRASS version: CVS HEAD >> GRASS component: raster >> Operating system: MacOS X >> Operating system version: 10.4 >> GRASS CVS checkout date, if applies (YYMMDD): > > Fixed in CVS. That was improper usage of G_done_msg() as noticed. > ----- William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect From paul-grass at stjohnspoint.co.uk Wed Aug 8 20:11:14 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Wed Aug 8 20:11:32 2007 Subject: [GRASS-dev] [grass-code I][455] r.proj segfaults after Jul 14 changes In-Reply-To: References: <20070808170130.A7AAA4007F@pyrosoma.intevation.org> <1186594659.22591.278.camel@dev64.localdomain> Message-ID: On Wed, 8 Aug 2007, William Kyngesburye wrote: > Actually, it's more than just G_done_msg - there are a few G_message(NULL) in > there, and the r.proj source is really in r.proj.seg, the r.proj source > folder is deprecated. > > Not to mention the other modules I found null messages in, as I mentioned in > a followup to the bug report. > > If (NULL) is indeed improper use of the message functions, I could take care Well apart from passing NULL instead of an empty string being obviously wrong, a message that actually contains no information would appear to be improper use by definition, no? What's the point of it? Just seems like an obvious remark to make anyway... Paul From paul-grass at stjohnspoint.co.uk Wed Aug 8 20:49:00 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Wed Aug 8 20:51:17 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: <18104.50679.830154.347160@cerise.gclements.plus.com> References: <98406.78280.qm@web60521.mail.yahoo.com> <18104.45127.468813.123101@cerise.gclements.plus.com> <18104.50679.830154.347160@cerise.gclements.plus.com> Message-ID: On Tue, 7 Aug 2007, Glynn Clements wrote: > Done that. Yep, it's the script; MSys strikes again. > > I've added an nviz.bat script for use on Windows; I've also fixed the > Makefile to ensure that the binary gets the .exe extension. That's excellent - I can confirm that it works again for me too. Somehow I thought there was something else - I tried reverting to the way it was before but couldn't get it working again. But didn't think of adding a separate script start for Windows. I found another issue with the use of the cat command in part of an NVIZ Tcl script which I've also fixed, and it seems to be working well now. Grepping for "exec" in the other scripts I see a few more hackish-looking things that will need to be fixed to get all the NVIZ functionality working on Windows though. Paul From glynn at gclements.plus.com Wed Aug 8 22:19:34 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Aug 8 22:19:39 2007 Subject: [GRASS-dev] [grass-code I][455] r.proj segfaults after Jul 14 changes In-Reply-To: References: <20070808170130.A7AAA4007F@pyrosoma.intevation.org> <1186594659.22591.278.camel@dev64.localdomain> Message-ID: <18106.9558.524292.824201@cerise.gclements.plus.com> Paul Kelly wrote: > > Actually, it's more than just G_done_msg - there are a few G_message(NULL) in > > there, and the r.proj source is really in r.proj.seg, the r.proj source > > folder is deprecated. > > > > Not to mention the other modules I found null messages in, as I mentioned in > > a followup to the bug report. > > > > If (NULL) is indeed improper use of the message functions, I could take care > > Well apart from passing NULL instead of an empty string being obviously > wrong, a message that actually contains no information would appear to be > improper use by definition, no? What's the point of it? > Just seems like an obvious remark to make anyway... The G_message(NULL) calls appear between the code which prints the input and output regions. IOW, they're there to add blank lines. Personally, I think that section should use G_verbose_message(). -- Glynn Clements From kyngchaos at kyngchaos.com Thu Aug 9 05:01:13 2007 From: kyngchaos at kyngchaos.com (William Kyngesburye) Date: Thu Aug 9 05:01:23 2007 Subject: [GRASS-dev] A couple wx GUI problems Message-ID: A couple random WX GUI problems: - If I had previously run GRASS in a DB on an external disk, then unmounted the disk, when I run GRASS again with the wx GUI, GRASS complains that it can't find the DB and bails, instead of opening the gis_set.py dialog and letting me choose a different DB. The drag-n-drop I added to the OSX app works to reset this (and I imagine the equivalent CLI startup with a mapset path will do the same on other systems), but it's a bit annoying if I want to create a new location or mapset in a location - I have to open an existing one first. I recall someone had a similar problem a while back (which spurred me to add the drag-n-drop feature). Any progress made on this? - It appears that the dialogs from the command line still use TclTk. Totally separate from the wx GUI? I hope that changes in the future. ----- William Kyngesburye http://www.kyngchaos.com/ "I ache, therefore I am. Or in my case - I am, therefore I ache." - Marvin From michael.barton at asu.edu Thu Aug 9 08:27:47 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Aug 9 08:27:57 2007 Subject: [GRASS-dev] finally fixed rendering in wxPython GUI (I hope) Message-ID: Benjamin and Carlos I think I finally fixed the rendering in the wxPython GUI--at least I hope so. Now the map or area zoomed always fits in the display window. Previously, it was fitting sometimes and not fitting other times. With the previous partial fix, the problem was that repeatedly resizing the display could make the map shrink in the window. I don't understand why I was getting that effect, but it seems to be gone now. Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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/20070808/521ad569/attachment.html From michael.barton at asu.edu Thu Aug 9 08:35:49 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Aug 9 08:36:08 2007 Subject: [GRASS-dev] Re: [GRASSGUI] Re: ImportError: No module named aui In-Reply-To: Message-ID: You can use Python 2.4 or 2.5. You must have wxPython 2.8 or higher. Python and wxPython version numbers are not in sync with each other. wxPython version numbers are (I think) in sync with wxWidgets version numbers (since wxPython is built on wxWidgets). If you have Python 2.4, you must compile wxPython for Python 2.4 (or get a binary that is compiled for Python 2.4) If you have Python 2.5, you must compile wxPython for Python 2.5 (or get the proper binary). I recently saw come across the list the comment that wxPython 2.8 will work fine with things that need wxPython 2.6 (although the reverse is not true of course). Hope this clarifies things somewhat. Michael On 8/8/07 5:50 AM, "Tim Michelsen" wrote: > Thanks for your response. > >> As the errors indicate, you seem to have a mismatch between your wxPython >> and Python version. You need to have a version of wxPython 2.8 that uses the >> same version of Python you have on your computer--either 2.4 OR 2.5. > > How do I solve this mismatch? > How do I tell wxgrass which version to take? > > I need wxpython 2.4 for audacity, wxpython 2.6 for filezilla... > > All these versions make it really confusing... > > I am open for any hint! > > __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 michael.barton at asu.edu Thu Aug 9 08:41:46 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Aug 9 08:51:13 2007 Subject: [GRASS-dev] Re: [GRASSGUI] A couple wx GUI problems In-Reply-To: <0AD0F3BC-BF87-42E3-8897-EA18F79626EB@kyngchaos.com> Message-ID: On 8/8/07 8:15 PM, "William Kyngesburye" wrote: > A couple random WX GUI problems: > > > - If I had previously run GRASS in a DB on an external disk, then > unmounted the disk, when I run GRASS again with the wx GUI, GRASS > complains that it can't find the DB and bails, instead of opening the > gis_set.py dialog and letting me choose a different DB. This is a problem with init.sh I believe. It never even gets as far as gis_set.py (or gis_set.tcl for that matter). IMHO, if the gisdatabase, location, or mapset specified in .grassrc6 does not exists, then the program should simply default to the screen where you can pick them--gui or text. It should not bail. It's probably fairly easy to fix this somewhere in init.sh. But I haven't had time to search through and find the spot. > > The drag-n-drop I added to the OSX app works to reset this (and I > imagine the equivalent CLI startup with a mapset path will do the > same on other systems), but it's a bit annoying if I want to create a > new location or mapset in a location - I have to open an existing one > first. > > I recall someone had a similar problem a while back (which spurred me > to add the drag-n-drop feature). Any progress made on this? > > > - It appears that the dialogs from the command line still use TclTk. > Totally separate from the wx GUI? I hope that changes in the future. Yes. There has been some discussion about this on the dev list in the past week. It looks like it's fairly easy (for some who knows C) to fix. It will also require some tinkering with init.sh I suppose. Currently, if you type python $GISBASE/etc/wx/gui_modules/menuform.py , you'll get the wxPython version of the command dialog. Michael > > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > "I ache, therefore I am. Or in my case - I am, therefore I ache." > > - Marvin > > > > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > "Mon Dieu! but they are all alike. Cheating, murdering, lying, > fighting, and all for things that the beasts of the jungle would not > deign to possess - money to purchase the effeminate pleasures of > weaklings. And yet withal bound down by silly customs that make them > slaves to their unhappy lot while firm in the belief that they be the > lords of creation enjoying the only real pleasures of existence.... > > - the wisdom of Tarzan > > > __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 Thu Aug 9 08:57:52 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Thu Aug 9 08:57:57 2007 Subject: [GRASS-dev] [grass-code I][455] r.proj segfaults after Jul 14 changes In-Reply-To: References: <20070808170130.A7AAA4007F@pyrosoma.intevation.org> <1186594659.22591.278.camel@dev64.localdomain> Message-ID: <1186642672.22591.336.camel@dev64.localdomain> On Wed, 2007-08-08 at 12:54 -0500, William Kyngesburye wrote: > Actually, it's more than just G_done_msg - there are a few G_message > (NULL) in there, and the r.proj source is really in r.proj.seg, the > r.proj source folder is deprecated. Ugh. > Not to mention the other modules I found null messages in, as I > mentioned in a followup to the bug report. > > If (NULL) is indeed improper use of the message functions, I could > take care of them - I have my own CVS copy of r.proj.seg updated > already, and I found those others already. That is blatantly wrong. Does anyone actually test code they write? Please commit your changes. I'll update the documentation. -- 73, de Brad KB8UYR/6 From rez at touchofmadness.com Thu Aug 9 09:01:10 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Thu Aug 9 09:01:14 2007 Subject: [GRASS-dev] Re: [GRASSGUI] Re: ImportError: No module named aui In-Reply-To: References: Message-ID: <1186642870.22591.339.camel@dev64.localdomain> On Wed, 2007-08-08 at 23:35 -0700, Michael Barton wrote: > You can use Python 2.4 or 2.5. > > You must have wxPython 2.8 or higher. > > Python and wxPython version numbers are not in sync with each other. > > wxPython version numbers are (I think) in sync with wxWidgets version > numbers (since wxPython is built on wxWidgets). > > If you have Python 2.4, you must compile wxPython for Python 2.4 (or get a > binary that is compiled for Python 2.4) > > If you have Python 2.5, you must compile wxPython for Python 2.5 (or get the > proper binary). > > I recently saw come across the list the comment that wxPython 2.8 will work > fine with things that need wxPython 2.6 (although the reverse is not true of > course). I built RPMs for Fedora Core 6 x86_64 if anyone is interested. It'll save a lot of headaches. -- 73, de Brad KB8UYR/6 From carlos.grohmann at gmail.com Thu Aug 9 12:12:25 2007 From: carlos.grohmann at gmail.com (=?ISO-8859-1?Q?Carlos_"Gu=E2no"_Grohmann?=) Date: Thu Aug 9 12:12:29 2007 Subject: [GRASS-dev] Re: finally fixed rendering in wxPython GUI (I hope) In-Reply-To: References: Message-ID: OK. it works now! nice job. Altough I still miss the 'overlay' option set by default to rasters. And I still can't change the raster layer by double-clicking its name and changing the layer in the drop-down list. Carlos On 8/9/07, Michael Barton wrote: > > Benjamin and Carlos > > I think I finally fixed the rendering in the wxPython GUI--at least I hope > so. Now the map or area zoomed always fits in the display window. > Previously, it was fitting sometimes and not fitting other times. With the > previous partial fix, the problem was that repeatedly resizing the display > could make the map shrink in the window. I don't understand why I was > getting that effect, but it seems to be gone now. > > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > Director of Graduate Studies > 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 > > -- +-----------------------------------------------------------+ Carlos Henrique Grohmann - Guano Visiting Researcher at Kingston University London - UK Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - carlos dot grohmann at gmail dot com +-----------------------------------------------------------+ _________________ "Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive." --The winning entry in a "What were HAL's first words" contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke Can't stop the signal. From woklist at kyngchaos.com Thu Aug 9 16:27:31 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Thu Aug 9 16:27:37 2007 Subject: [GRASS-dev] [grass-code I][455] r.proj segfaults after Jul 14 changes In-Reply-To: <1186642672.22591.336.camel@dev64.localdomain> References: <20070808170130.A7AAA4007F@pyrosoma.intevation.org> <1186594659.22591.278.camel@dev64.localdomain> <1186642672.22591.336.camel@dev64.localdomain> Message-ID: <9444A8DC-4623-4246-8806-F51EDD3F887C@kyngchaos.com> On Aug 9, 2007, at 1:57 AM, Brad Douglas wrote: >> Not to mention the other modules I found null messages in, as I >> mentioned in a followup to the bug report. >> >> If (NULL) is indeed improper use of the message functions, I could >> take care of them - I have my own CVS copy of r.proj.seg updated >> already, and I found those others already. > > That is blatantly wrong. Does anyone actually test code they write? > Please commit your changes. I'll update the documentation. > That's interesting, because when I looked at the r.proj main.c history, the "Message/Debug cleaning" revision explicitly changed a couple G_message("") to G_message(NULL) (among other changes). To be fair, it may be that it worked for them (it only seems to cause trouble on OSX). They may or may not *know* if it's wrong (I didn't, tho I understood what it was meant to do). Anyways, I've changed all the NULL messages I found in CVS now. ----- William Kyngesburye http://www.kyngchaos.com/ Theory of the Universe There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened. -Hitchhiker's Guide to the Galaxy 2nd season intro From michael.barton at asu.edu Thu Aug 9 17:11:41 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Aug 9 17:11:59 2007 Subject: [GRASS-dev] Re: finally fixed rendering in wxPython GUI (I hope) In-Reply-To: Message-ID: On 8/9/07 3:12 AM, "Carlos "Gu?no" Grohmann" wrote: > OK. it works now! > > nice job. Thanks. > > Altough I still miss the 'overlay' option set by default to rasters. Me too. But we're trying to avoid having to manually update layer preference panels each time there is a change in the underlying module. So that means avoiding custom preference panels. This is why I recently added in a layer for d.shaded.map. So you can easily do a shaded relief map layer without the less obvious way with d.his. > > And I still can't change the raster layer by double-clicking its name > and changing the layer in the drop-down list. Are you selecting from the list or typing? I've found that selecting sometimes works when typing doesn't. I don't know why and it is one of those minor but annoying things that need to be fixed. Michael > > > Carlos > > > > On 8/9/07, Michael Barton wrote: >> >> Benjamin and Carlos >> >> I think I finally fixed the rendering in the wxPython GUI--at least I hope >> so. Now the map or area zoomed always fits in the display window. >> Previously, it was fitting sometimes and not fitting other times. With the >> previous partial fix, the problem was that repeatedly resizing the display >> could make the map shrink in the window. I don't understand why I was >> getting that effect, but it seems to be gone now. >> >> Michael >> __________________________________________ >> Michael Barton, Professor of Anthropology >> Director of Graduate Studies >> 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 >> >> > __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 kwythers at umn.edu Thu Aug 9 19:48:52 2007 From: kwythers at umn.edu (Kirk Wythers) Date: Thu Aug 9 19:49:07 2007 Subject: [GRASS-dev] r.proj bus error on 6.3.cvs Message-ID: I am getting a bus error with r.proj. It could be user error, however I was able to reproject a vector from the same location with no troubles. I am projecting from a UTM zone 15 location an to Albers Equal Area location using the current cvs version of 6.3 Here is the output from r.proj: GRASS 6.3.cvs (northcentralus_albersequalarea):~ > r.proj --verbose -- overwrite input=nlcd2001 location=northcentralus_utm mapset=nlcd2001 Input Projection Parameters: +proj=utm +no_defs +zone=15 +a=6378137 +rf=298.257222101 +towgs84=0.000,0.000,0.000 Input Unit Factor: 1 Output Projection Parameters: +proj=aea +lat_1=29.5 +lat_2=45.5 +lat_0=23 +lon_0=-96 +x_0=0 +y_0=0 +no_defs +a=6378137 +rf=298.257222101 +towgs84=0.000,0.000,0.000 Output Unit Factor: 1 Whereas v.proj GRASS 6.3.cvs (northcentralus_albersequalarea):~ > v.proj input=ls_fia_with_climate location=northcentralus_utm mapset=nlcd2001 Input Projection Parameters: +proj=utm +no_defs +zone=15 +a=6378137 +rf=298.257222101 +towgs84=0.000,0.000,0.000 Input Unit Factor: 1 Output Projection Parameters: +proj=aea +lat_1=29.5 +lat_2=45.5 +lat_0=23 +lon_0=-96 +x_0=0 +y_0=0 +no_defs +a=6378137 +rf=298.257222101 +towgs84=0.000,0.000,0.000 Output Unit Factor: 1 Re-projecting vector map... Building topology ... 154850 primitives registered Building areas: 100% 0 areas built 0 isles built Attaching islands: Attaching centroids: 100% Topology was built. Number of nodes : 51063 Number of primitives: 154850 Number of points : 154850 Number of lines : 0 Number of boundaries: 0 Number of centroids : 0 Number of areas : 0 Number of isles : 0 Any ideas? Thanks, Kirk From rez at touchofmadness.com Thu Aug 9 19:52:54 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Thu Aug 9 19:52:58 2007 Subject: [GRASS-dev] [grass-code I][455] r.proj segfaults after Jul 14 changes In-Reply-To: <9444A8DC-4623-4246-8806-F51EDD3F887C@kyngchaos.com> References: <20070808170130.A7AAA4007F@pyrosoma.intevation.org> <1186594659.22591.278.camel@dev64.localdomain> <1186642672.22591.336.camel@dev64.localdomain> <9444A8DC-4623-4246-8806-F51EDD3F887C@kyngchaos.com> Message-ID: <1186681974.22591.361.camel@dev64.localdomain> On Thu, 2007-08-09 at 09:27 -0500, William Kyngesburye wrote: > On Aug 9, 2007, at 1:57 AM, Brad Douglas wrote: > > >> Not to mention the other modules I found null messages in, as I > >> mentioned in a followup to the bug report. > >> > >> If (NULL) is indeed improper use of the message functions, I could > >> take care of them - I have my own CVS copy of r.proj.seg updated > >> already, and I found those others already. > > > > That is blatantly wrong. Does anyone actually test code they write? > > Please commit your changes. I'll update the documentation. > > > That's interesting, because when I looked at the r.proj main.c > history, the "Message/Debug cleaning" revision explicitly changed a > couple G_message("") to G_message(NULL) (among other changes). This is cause for some concern. If unsure, glance at the function code. It would have been more than obvious. > To be fair, it may be that it worked for them (it only seems to cause > trouble on OSX). They may or may not *know* if it's wrong (I didn't, > tho I understood what it was meant to do). Not all NULLs are treated equally by all systems. Turning -Wall on should have revealed it, too. It may have been an honest mistake, but it was a careless mistake. > Anyways, I've changed all the NULL messages I found in CVS now. Thank you. I updated the documentation this morning to explicitly warn against it. -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From glynn at gclements.plus.com Thu Aug 9 22:03:58 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Aug 9 22:04:00 2007 Subject: [GRASS-dev] r.proj bus error on 6.3.cvs In-Reply-To: References: Message-ID: <18107.29486.129944.684070@cerise.gclements.plus.com> Kirk Wythers wrote: > I am getting a bus error with r.proj. Known, found, fixed in CVS. -- Glynn Clements From hamish_nospam at yahoo.com Fri Aug 10 00:46:12 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Aug 10 00:46:15 2007 Subject: [GRASS-dev] [grass-code I][455] r.proj segfaults after Jul 14 changes In-Reply-To: Message-ID: <881666.66252.qm@web52707.mail.re2.yahoo.com> Paul Kelly wrote: > Well apart from passing NULL instead of an empty string being obviously > wrong, a message that actually contains no information would appear to be > improper use by definition, no? What's the point of it? It's valid for G_done_msg(), it outputs like: $MODULE complete. $* with "", it just says "$MOD complete. " So passing a message is optional extra. However, G_message(""); for a blank line is ugly ugly, I'd suggest either adding a new lib fn (lame solution) or removing whitespace stripping action from G_message(), and allow '\n' back in the string. The problem with this is that self-formatting gets abused, and perhaps confuses the line-wrap code? (this is just off the top of my head, I can't check what the code actually does right now) Hamish ____________________________________________________________________________________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC From woklist at kyngchaos.com Fri Aug 10 15:52:35 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Fri Aug 10 15:52:48 2007 Subject: [GRASS-dev] [grass-code I][455] r.proj segfaults after Jul 14 changes In-Reply-To: <881666.66252.qm@web52707.mail.re2.yahoo.com> References: <881666.66252.qm@web52707.mail.re2.yahoo.com> Message-ID: On Aug 9, 2007, at 5:46 PM, Hamish wrote: > Paul Kelly wrote: >> Well apart from passing NULL instead of an empty string being >> obviously >> wrong, a message that actually contains no information would >> appear to be >> improper use by definition, no? What's the point of it? > > It's valid for G_done_msg(), it outputs like: > $MODULE complete. $* > > with "", it just says "$MOD complete. " So passing a message is > optional extra. If it is intended to be optional for G_done_msg, then this needs to be fixed. It's the vsprintf(buffer,msg,ap); part in there that is causing trouble on OSX. If NULL is valid, then a check for NULL should be done before vsprintf is called. ----- William Kyngesburye http://www.kyngchaos.com/ "This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind?" - The Ruler of the Universe From paul-grass at stjohnspoint.co.uk Fri Aug 10 17:53:06 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Fri Aug 10 17:53:11 2007 Subject: [GRASS-dev] [grass-code I][455] r.proj segfaults after Jul 14 changes In-Reply-To: <881666.66252.qm@web52707.mail.re2.yahoo.com> References: <881666.66252.qm@web52707.mail.re2.yahoo.com> Message-ID: On Thu, 9 Aug 2007, Hamish wrote: > However, G_message(""); for a blank line is ugly ugly, I'd suggest either > adding a new lib fn (lame solution) or removing whitespace stripping action > from G_message(), and allow '\n' back in the string. The problem with this is Well yes - if it does that then that explains why people are passing an empty message. It's acting more like G_print_this_info_to_stderr() than a real G_message(). IMHO a message should be a distinct piece of information, that may or may not require multiple lines to get across. The calling modules should be able to add line breaks if they see fit. I also think G_message(), G_warning() etc. should only break lines if output is going to a terminal. When the messages are re-processed and displayed through the GUI the extraneous line breaks can look quite ugly in certain circumstances (e.g. pop-up dialog boxes containing warnings). Allowing newlines in messages passed to G_message() but then stripping them out strikes me as really messy, and just lazy - why not fix all the calls to G_message() instead to conform to the conventions? > that self-formatting gets abused, and perhaps confuses the line-wrap code? Hmm, what do you mean by abused? I feel that the programmer should be able to put newlines into a message if it is necessary to get the meaning across, and the function that prints/parses the output should respect the newlines. Paul From rez at touchofmadness.com Fri Aug 10 18:32:27 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Fri Aug 10 18:32:47 2007 Subject: [GRASS-dev] [grass-code I][455] r.proj segfaults after Jul 14 changes In-Reply-To: References: <881666.66252.qm@web52707.mail.re2.yahoo.com> Message-ID: <1186763547.2989.101.camel@dev64.localdomain> On Fri, 2007-08-10 at 08:52 -0500, William Kyngesburye wrote: > On Aug 9, 2007, at 5:46 PM, Hamish wrote: > > > Paul Kelly wrote: > >> Well apart from passing NULL instead of an empty string being > >> obviously > >> wrong, a message that actually contains no information would > >> appear to be > >> improper use by definition, no? What's the point of it? > > > > It's valid for G_done_msg(), it outputs like: > > $MODULE complete. $* > > > > with "", it just says "$MOD complete. " So passing a message is > > optional extra. > > If it is intended to be optional for G_done_msg, then this needs to > be fixed. It's the vsprintf(buffer,msg,ap); part in there that is > causing trouble on OSX. If NULL is valid, then a check for NULL > should be done before vsprintf is called. I'm opposed to adding largely unnecessary code. The console is NOT designed for well laid out display. It is there for informational purposes only. IMO, if you want pretty messages, use a GUI. -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From woklist at kyngchaos.com Fri Aug 10 19:07:07 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Fri Aug 10 19:07:21 2007 Subject: [GRASS-dev] [grass-code I][455] r.proj segfaults after Jul 14 changes In-Reply-To: <1186763547.2989.101.camel@dev64.localdomain> References: <881666.66252.qm@web52707.mail.re2.yahoo.com> <1186763547.2989.101.camel@dev64.localdomain> Message-ID: <0F1B5BE4-BD9A-4479-9BB0-A54E9860DC94@kyngchaos.com> On Aug 10, 2007, at 11:32 AM, Brad Douglas wrote: > On Fri, 2007-08-10 at 08:52 -0500, William Kyngesburye wrote: >> >> If it is intended to be optional for G_done_msg, then this needs to >> be fixed. It's the vsprintf(buffer,msg,ap); part in there that is >> causing trouble on OSX. If NULL is valid, then a check for NULL >> should be done before vsprintf is called. > > I'm opposed to adding largely unnecessary code. The console is NOT > designed for well laid out display. It is there for informational > purposes only. IMO, if you want pretty messages, use a GUI. > It's not a matter of changing the way it prints the message. The problem is that passing NULL to vsprintf() on OSX causes a bus error. If NULL is meant to be valid for G_done_msg(), then it needs to trap that so it doesn't pass it to vsprintf(). ----- 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 rez at touchofmadness.com Fri Aug 10 19:20:07 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Fri Aug 10 19:20:20 2007 Subject: [GRASS-dev] [grass-code I][455] r.proj segfaults after Jul 14 changes In-Reply-To: <0F1B5BE4-BD9A-4479-9BB0-A54E9860DC94@kyngchaos.com> References: <881666.66252.qm@web52707.mail.re2.yahoo.com> <1186763547.2989.101.camel@dev64.localdomain> <0F1B5BE4-BD9A-4479-9BB0-A54E9860DC94@kyngchaos.com> Message-ID: <1186766407.2989.120.camel@dev64.localdomain> On Fri, 2007-08-10 at 12:07 -0500, William Kyngesburye wrote: > On Aug 10, 2007, at 11:32 AM, Brad Douglas wrote: > > > On Fri, 2007-08-10 at 08:52 -0500, William Kyngesburye wrote: > >> > >> If it is intended to be optional for G_done_msg, then this needs to > >> be fixed. It's the vsprintf(buffer,msg,ap); part in there that is > >> causing trouble on OSX. If NULL is valid, then a check for NULL > >> should be done before vsprintf is called. > > > > I'm opposed to adding largely unnecessary code. The console is NOT > > designed for well laid out display. It is there for informational > > purposes only. IMO, if you want pretty messages, use a GUI. > > > It's not a matter of changing the way it prints the message. The > problem is that passing NULL to vsprintf() on OSX causes a bus > error. If NULL is meant to be valid for G_done_msg(), then it needs > to trap that so it doesn't pass it to vsprintf(). How many times to I have to state that passing NULL to *printf() va*() is absolutely, positively **WRONG**? And we should NOT be modifying the API to accommodate one person's stylistic choices. Is anyone listening? G_msg_done() is not living up to its intended use. It should probably be deprecated. -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From woklist at kyngchaos.com Fri Aug 10 20:42:09 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Fri Aug 10 20:42:26 2007 Subject: [GRASS-dev] [grass-code I][455] r.proj segfaults after Jul 14 changes In-Reply-To: <1186766407.2989.120.camel@dev64.localdomain> References: <881666.66252.qm@web52707.mail.re2.yahoo.com> <1186763547.2989.101.camel@dev64.localdomain> <0F1B5BE4-BD9A-4479-9BB0-A54E9860DC94@kyngchaos.com> <1186766407.2989.120.camel@dev64.localdomain> Message-ID: <30F67490-6D1E-4D3F-9A9C-673690FF2F42@kyngchaos.com> Sorry to cause a ruckus... Somewhere along the way it was suggested (maybe I misinterpreted that) that calling G_done_msg() with NULL was acceptable, though I completely understand that passing NULL to vsprintf is wrong (it just happens to work on some platforms). On Aug 10, 2007, at 12:20 PM, Brad Douglas wrote: > How many times to I have to state that passing NULL to *printf() va*() > is absolutely, positively **WRONG**? And we should NOT be modifying > the > API to accommodate one person's stylistic choices. ----- William Kyngesburye http://www.kyngchaos.com/ "This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind?" - The Ruler of the Universe From neteler at itc.it Sat Aug 11 10:14:34 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Aug 11 10:14:37 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation Message-ID: <20070811081434.GB28767@bartok.itc.it> Hi, I think that it is time to get out a GRASS 6.3.0 release (as sort of technology preview). It would be great to have it ready for FOSS4G2007, say, September. IMHO, GRASS 6.3-CVS is in a good shape. Thoughts? Markus From cavallini at faunalia.it Sat Aug 11 10:18:01 2007 From: cavallini at faunalia.it (Paolo Cavallini) Date: Sat Aug 11 10:18:06 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <20070811081434.GB28767@bartok.itc.it> References: <20070811081434.GB28767@bartok.itc.it> Message-ID: <46BD70B9.3010405@faunalia.it> It would be great, also to align versions with the grass plugin of qgis (0.9 should also be ready for FOSS4G). pc Markus Neteler ha scritto: > Hi, > > I think that it is time to get out a GRASS 6.3.0 release > (as sort of technology preview). It would be great to > have it ready for FOSS4G2007, say, September. > > IMHO, GRASS 6.3-CVS is in a good shape. Thoughts? > > Markus -- Paolo Cavallini, see: http://www.faunalia.it/pc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070811/36c95fdc/signature.bin From cavallini at faunalia.it Sat Aug 11 10:20:42 2007 From: cavallini at faunalia.it (Paolo Cavallini) Date: Sat Aug 11 10:20:46 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <20070811081434.GB28767@bartok.itc.it> References: <20070811081434.GB28767@bartok.itc.it> Message-ID: <46BD715A.4050501@faunalia.it> I think one problem could be with the new python gui: many distros do not have wx2.8 packaged, and this could slow down effective dissemination of the new version. Anybody knows more about this? pc Markus Neteler ha scritto: > Hi, > > I think that it is time to get out a GRASS 6.3.0 release > (as sort of technology preview). It would be great to > have it ready for FOSS4G2007, say, September. > > IMHO, GRASS 6.3-CVS is in a good shape. Thoughts? > > Markus -- Paolo Cavallini, see: http://www.faunalia.it/pc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070811/3322caca/signature.bin From paul-grass at stjohnspoint.co.uk Sat Aug 11 12:56:06 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sat Aug 11 12:56:26 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <46BD715A.4050501@faunalia.it> References: <20070811081434.GB28767@bartok.itc.it> <46BD715A.4050501@faunalia.it> Message-ID: On Sat, 11 Aug 2007, Paolo Cavallini wrote: > I think one problem could be with the new python gui: many distros do > not have wx2.8 packaged, and this could slow down effective > dissemination of the new version. > Anybody knows more about this? The new Python GUI isn't in 6.3.x, so it's not an issue - the main GUI for 6.3.x/6.4.x is still (a further improved) Tcl/Tk gis.m with more bugs fixed and more cross-platform compatibility. I was just thinking, the Python GUI can probably be merged into the CVS HEAD after a release branch has been created for 6.4.x (probably won't be ready for that for at least a couple of months). Then there will be 6.5.x - we can probably start making other major changes there and release it eventually as 7.0? How does that sound? Paul From glynn at gclements.plus.com Sat Aug 11 14:37:57 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Aug 11 14:38:07 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: References: <20070811081434.GB28767@bartok.itc.it> <46BD715A.4050501@faunalia.it> Message-ID: <18109.44453.864055.963012@cerise.gclements.plus.com> Paul Kelly wrote: > > I think one problem could be with the new python gui: many distros do > > not have wx2.8 packaged, and this could slow down effective > > dissemination of the new version. > > Anybody knows more about this? > > The new Python GUI isn't in 6.3.x, so it's not an issue - the main GUI for > 6.3.x/6.4.x is still (a further improved) Tcl/Tk gis.m with more bugs > fixed and more cross-platform compatibility. > > I was just thinking, the Python GUI can probably be merged into the CVS > HEAD after a release branch has been created for 6.4.x (probably won't be > ready for that for at least a couple of months). Then there will be 6.5.x > - we can probably start making other major changes there and release it > eventually as 7.0? How does that sound? I'm disinclined towards the creation of 6.4/6.5 versions. I would prefer to see stable = 6.3.x, dev = 7.0-cvs. -- Glynn Clements From grass-dev at grass.itc.it Sat Aug 11 16:28:57 2007 From: grass-dev at grass.itc.it (grass-dev@grass.itc.it) Date: Sat Aug 11 16:24:27 2007 Subject: [GRASS-dev] [grass-code I][458] d.slide.show was using --quiet option but that's not available in 6.2.x Message-ID: <20070811142857.27F384009D@pyrosoma.intevation.org> code I item #458, was opened at 2007-08-11 10:28 Status: Open Priority: 2 Submitted By: Scott Mitchell (smitch) Assigned to: Nobody (None) Summary: d.slide.show was using --quiet option but that's not available in 6.2.x Issue type: module bug Issue status: fixed in CVS GRASS version: 6.2 GRASS component: display Operating system: None Operating system version: GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: A colleague reported to me that d.slide.show was not working for him using the released 6.2.2, and that he had managed to make it work by removing the --quiet flag to the d.rast call in drawraster() Looking into it, I gather d.slide.show was back-ported from HEAD, but this particular change doesn't work because --quiet was not implemented in 6.2 I have removed --quiet from both the d.rast and d.vect calls in the release branch version of d.slide.show, but do not know if there are other related issues resulting from the backport, so am documenting it here. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=458&group_id=21 From yann.chemin at gmail.com Sat Aug 11 16:25:07 2007 From: yann.chemin at gmail.com (Yann) Date: Sat Aug 11 16:25:23 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <18109.44453.864055.963012@cerise.gclements.plus.com> References: <20070811081434.GB28767@bartok.itc.it> <18109.44453.864055.963012@cerise.gclements.plus.com> Message-ID: <200708112125.08385.yann.chemin@gmail.com> On Saturday 11 August 2007 19:37:57 Glynn Clements wrote: > I'm disinclined towards the creation of 6.4/6.5 versions. I would > prefer to see stable = 6.3.x, dev = 7.0-cvs. +1 Yann From cavallini at faunalia.it Sat Aug 11 16:46:46 2007 From: cavallini at faunalia.it (Paolo Cavallini) Date: Sat Aug 11 16:47:00 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <200708112125.08385.yann.chemin@gmail.com> References: <20070811081434.GB28767@bartok.itc.it> <18109.44453.864055.963012@cerise.gclements.plus.com> <200708112125.08385.yann.chemin@gmail.com> Message-ID: <46BDCBD6.1020607@faunalia.it> Mayor numbers are usually associated with a change in format, thus breaking retrocompatibility; would this mean you intend to change the (now very old) raster format? pc Yann ha scritto: > On Saturday 11 August 2007 19:37:57 Glynn Clements wrote: >> I'm disinclined towards the creation of 6.4/6.5 versions. I would >> prefer to see stable = 6.3.x, dev = 7.0-cvs. -- Paolo Cavallini, see: http://www.faunalia.it/pc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070811/02a3cf7a/signature.bin From michael.barton at asu.edu Sat Aug 11 17:23:43 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Aug 11 17:24:28 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <18109.44453.864055.963012@cerise.gclements.plus.com> Message-ID: I think that 6.3 stable is ready. With the exception of the the segfault with r.proj (fixed or on its way to being fixed), I don't know of any serious issues on-going with 6.3. Most of the recent changes I've seen come across the dev list have been improvements or enhancements. On 8/11/07 5:37 AM, "Glynn Clements" wrote: > > Paul Kelly wrote: > >>> I think one problem could be with the new python gui: many distros do >>> not have wx2.8 packaged, and this could slow down effective >>> dissemination of the new version. >>> Anybody knows more about this? >> >> The new Python GUI isn't in 6.3.x, so it's not an issue - the main GUI for >> 6.3.x/6.4.x is still (a further improved) Tcl/Tk gis.m with more bugs >> fixed and more cross-platform compatibility. >> >> I was just thinking, the Python GUI can probably be merged into the CVS >> HEAD after a release branch has been created for 6.4.x (probably won't be >> ready for that for at least a couple of months). Then there will be 6.5.x >> - we can probably start making other major changes there and release it >> eventually as 7.0? How does that sound? > > I'm disinclined towards the creation of 6.4/6.5 versions. I would > prefer to see stable = 6.3.x, dev = 7.0-cvs. I won't comment on how to best version this, but on a pathway for the new GUI. It is ready for inclusion to be packaged with GRASS as an alternative GUI now, but needs testing before it can become the primary GUI. My suggestion is ... 1) Get out a stable 6.3 without the new GUI 2) Package the new GUI in the subsequent dev release. A user should be able to activate it as a default GUI by setting GRASS_GUI=wx. This would include any module properties dialogs launched by typing the command at the GRASS prompt. Test and improve the new GUI until it is robust and stable. 3) Release a new dev version with the wxPython GUI as the default one, keeping TclTk as an alternate. 4) Release a new stable version with the wxPython GUI as default, keeping TclTk as an alternate. I realize that getting wxPython 2.8 on some systems is currently a problem, but this can be helped a lot by the release of wxPython packages for different Linux systems within the GRASS community (Mac and Windows binaries seem to be released along with any new wxPython version change). The recent prep of a Mandriva RPM by (sorry I can't remember) is a good example. Also, we never took advantage of the packaging features of TclTk, but could do so for a wxPython GUI to make this easier. Beyond the GUI, after the release of 6.3 stable, it would be good to think about how to transition to a new organization for raster file management that parallels the vector file model. IMHO, this is something that is needed and should happen at the 6/7 version boundary. Another largish 6/7 change would be revamping the display processes as Glynn has been discussing and moving towards. Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hmitaso at unity.ncsu.edu Sat Aug 11 18:31:13 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Sat Aug 11 18:31:19 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <20070811081434.GB28767@bartok.itc.it> References: <20070811081434.GB28767@bartok.itc.it> Message-ID: <618B7E68-CB5C-4D05-B94C-F8F83B0FE8A1@unity.ncsu.edu> On Aug 11, 2007, at 4:14 AM, Markus Neteler wrote: > Hi, > > I think that it is time to get out a GRASS 6.3.0 release > (as sort of technology preview). It would be great to > have it ready for FOSS4G2007, say, September. > > IMHO, GRASS 6.3-CVS is in a good shape. Thoughts? Before the release, can somebody please double check that the following works (most of this I believe was already discussed and should be fixed): - nviz: you can add additional surfaces using the Raster surfaces panel without crashing nviz (please try different resolutions, spatial extent, mapsets) - nviz: mask the displayed surface using a selected raster map from within nviz (in my version the mask only masked the displayed vector data) - nviz: save state - you can save the state and then load it and you can start working where you stoped when you saved your state - nviz: when saving the image, that the actual displayed image is saved rather than redrawn image (for example if you have loaded 4 surfaces and you display only one of them the automatic redraw during the saving procedure would display all four) - nviz: file sequencing tool saves the entire path rather than just the name of raster maps which nviz then cannot interpret when you try to play the script I hope that most of this has been already fixed but generally I have a 4 months old nviz on Mac having more capabilities fully functional than my few weeks old version on RedHat Linux, so it would be good to test before releasing. Otherwise GRASS63 is probably in better shape and more systematically tested than any previous release as both Markus and I ran almost all GRASS commands (not with all options though) and although there has been some level of frustration, most things work very well. If you ask me what was the most annoying (but not critica) thing that I have found when using GRASS under a deadline - then it was the large default size of the centroid symbol in d.vect. I had to go through large number of vector data when preparing the new data set and each time I forgot to set the size smaller I got the unreadable mess of overlapping crosses. So if we could change the default to something smaller - perhaps size 2 rather than 5, that would be great, because most of the time you really want to see your polygons not the centroids and they are quite visible at size 2 even with my old eyes (maybe make the default red as the default fill is grey). This was already discussed some time ago too. Helena > > Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From neteler at itc.it Sat Aug 11 18:59:56 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Aug 11 18:59:59 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <18109.44453.864055.963012@cerise.gclements.plus.com> References: <20070811081434.GB28767@bartok.itc.it> <46BD715A.4050501@faunalia.it> <18109.44453.864055.963012@cerise.gclements.plus.com> Message-ID: <12107117.post@talk.nabble.com> Glynn Clements wrote: > > Paul Kelly wrote: > >> > I think one problem could be with the new python gui: many distros do >> > not have wx2.8 packaged, and this could slow down effective >> > dissemination of the new version. >> > Anybody knows more about this? >> >> The new Python GUI isn't in 6.3.x, so it's not an issue - the main GUI >> for >> 6.3.x/6.4.x is still (a further improved) Tcl/Tk gis.m with more bugs >> fixed and more cross-platform compatibility. >> >> I was just thinking, the Python GUI can probably be merged into the CVS >> HEAD after a release branch has been created for 6.4.x (probably won't be >> ready for that for at least a couple of months). Then there will be 6.5.x >> - we can probably start making other major changes there and release it >> eventually as 7.0? How does that sound? > > I'm disinclined towards the creation of 6.4/6.5 versions. I would > prefer to see stable = 6.3.x, dev = 7.0-cvs. > I fully agree - time to start GRASS 7. Markus -- View this message in context: http://www.nabble.com/GRASS-6.3.0-release-preparation-tf4252794.html#a12107117 Sent from the Grass - Dev mailing list archive at Nabble.com. From neteler at itc.it Sat Aug 11 19:01:14 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Aug 11 19:01:17 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <46BDCBD6.1020607@faunalia.it> References: <20070811081434.GB28767@bartok.itc.it> <46BD715A.4050501@faunalia.it> <18109.44453.864055.963012@cerise.gclements.plus.com> <200708112125.08385.yann.chemin@gmail.com> <46BDCBD6.1020607@faunalia.it> Message-ID: <12107118.post@talk.nabble.com> Yes, the plan is to rewrite the raster data library for GRASS 7, let's discuss this in a different thread. Markus Paolo Cavallini wrote: > > Mayor numbers are usually associated with a change in format, thus > breaking retrocompatibility; would this mean you intend to change the > (now very old) raster format? > pc > > Yann ha scritto: >> On Saturday 11 August 2007 19:37:57 Glynn Clements wrote: >>> I'm disinclined towards the creation of 6.4/6.5 versions. I would >>> prefer to see stable = 6.3.x, dev = 7.0-cvs. > -- > Paolo Cavallini, see: http://www.faunalia.it/pc > > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- View this message in context: http://www.nabble.com/GRASS-6.3.0-release-preparation-tf4252794.html#a12107118 Sent from the Grass - Dev mailing list archive at Nabble.com. From neteler at itc.it Sat Aug 11 19:02:57 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Aug 11 19:02:59 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <46BD70B9.3010405@faunalia.it> References: <20070811081434.GB28767@bartok.itc.it> <46BD70B9.3010405@faunalia.it> Message-ID: <12107176.post@talk.nabble.com> Paolo, who is maintaining the plugin? This person should sync especially with the QGIS people. The GRASS 6.3 command API is pretty stable. Markus Paolo Cavallini wrote: > > It would be great, also to align versions with the grass plugin of qgis > (0.9 should also be ready for FOSS4G). > pc > > Markus Neteler ha scritto: >> Hi, >> >> I think that it is time to get out a GRASS 6.3.0 release >> (as sort of technology preview). It would be great to >> have it ready for FOSS4G2007, say, September. >> >> IMHO, GRASS 6.3-CVS is in a good shape. Thoughts? >> >> Markus > -- > Paolo Cavallini, see: http://www.faunalia.it/pc > -- View this message in context: http://www.nabble.com/GRASS-6.3.0-release-preparation-tf4252794.html#a12107176 Sent from the Grass - Dev mailing list archive at Nabble.com. From cavallini at faunalia.it Sat Aug 11 19:11:08 2007 From: cavallini at faunalia.it (Paolo Cavallini) Date: Sat Aug 11 19:11:16 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <12107176.post@talk.nabble.com> References: <20070811081434.GB28767@bartok.itc.it> <46BD70B9.3010405@faunalia.it> <12107176.post@talk.nabble.com> Message-ID: <46BDEDAC.8070100@faunalia.it> Markus Neteler ha scritto: > Paolo, > > who is maintaining the plugin? Nobody, really, I guess :( . However, Tim has been doing some work on this. This person should sync especially > with the QGIS people. The GRASS 6.3 command API is pretty stable. The win version is coming with 6.3 bundled, I believe. pc -- Paolo Cavallini, see: http://www.faunalia.it/pc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070811/597178e5/signature.bin From neteler at itc.it Sat Aug 11 19:13:24 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Aug 11 19:13:26 2007 Subject: [GRASS-dev] Launching GRASS 7 development Message-ID: <20070811171324.GB24682@bartok.itc.it> While we should concentrate now on getting out 6.3.0 (e.g., fixing issues indicated by Helena [1]), it is important to start planning for a GRASS 7 dev-branch management. For GRASS 6, we used for quite some time a mixed solution, with new code stored in the grass6/ repository and linking old, relevant code from grass[5]/ into it using some link scripts. I am not sure if we want the same for grass7/, too. On the other hand, replicating code is impossible since it won't be well maintained given our limited resources. Thoughts also here? Let's continue to maintain GRASS 7 ideas collection http://grass.gdf-hannover.de/wiki/GRASS_7_ideas_collection Markus [1] http://grass.itc.it/pipermail/grass-dev/2007-August/032579.html From glynn at gclements.plus.com Sat Aug 11 23:04:28 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Aug 11 23:05:02 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <46BDCBD6.1020607@faunalia.it> References: <20070811081434.GB28767@bartok.itc.it> <18109.44453.864055.963012@cerise.gclements.plus.com> <200708112125.08385.yann.chemin@gmail.com> <46BDCBD6.1020607@faunalia.it> Message-ID: <18110.9308.937203.488544@cerise.gclements.plus.com> Paolo Cavallini wrote: > Mayor numbers are usually associated with a change in format, thus > breaking retrocompatibility; would this mean you intend to change the > (now very old) raster format? The existing formats (at least, the most recent versions) would need to be supported. Also, the raster format has been extended before without a major revision (support for zlib-compressed integer maps). Substantial change to the raster format isn't high on my agenda, although allowing nulls to be embedded is. Anything beyond that really needs significant discussion and consideration before it is implemented. My first priority is cleaning up: simplifying the graphics API (no monitors, no mouse handling), eliminating terminal interaction (vask, curses, G_ask_*), eliminating the 4.x raster I/O functions, etc. -- Glynn Clements From glynn at gclements.plus.com Sat Aug 11 23:10:52 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Aug 11 23:11:00 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: References: <18109.44453.864055.963012@cerise.gclements.plus.com> Message-ID: <18110.9692.77672.812420@cerise.gclements.plus.com> Michael Barton wrote: > I won't comment on how to best version this, but on a pathway for the new > GUI. It is ready for inclusion to be packaged with GRASS as an alternative > GUI now, but needs testing before it can become the primary GUI. It also needs wxPython 2.8 to become widespread, and that's beyond our control. > I realize that getting wxPython 2.8 on some systems is currently a problem, > but this can be helped a lot by the release of wxPython packages for > different Linux systems within the GRASS community (Mac and Windows binaries > seem to be released along with any new wxPython version change). The recent > prep of a Mandriva RPM by (sorry I can't remember) is a good example. Also, > we never took advantage of the packaging features of TclTk, but could do so > for a wxPython GUI to make this easier. Even if we provide .rpm/.deb/etc files for every OS in existence, many people may be unwilling to use a third-party package which might conceivably conflict with the "vendor" version. -- Glynn Clements From glynn at gclements.plus.com Sat Aug 11 23:18:47 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Aug 11 23:18:50 2007 Subject: [GRASS-dev] Launching GRASS 7 development In-Reply-To: <20070811171324.GB24682@bartok.itc.it> References: <20070811171324.GB24682@bartok.itc.it> Message-ID: <18110.10167.537908.798478@cerise.gclements.plus.com> Markus Neteler wrote: > While we should concentrate now on getting out 6.3.0 (e.g., > fixing issues indicated by Helena [1]), it is important > to start planning for a GRASS 7 dev-branch management. > > For GRASS 6, we used for quite some time a mixed solution, > with new code stored in the grass6/ repository and linking > old, relevant code from grass[5]/ into it using some link > scripts. > > I am not sure if we want the same for grass7/, too. > On the other hand, replicating code is impossible since > it won't be well maintained given our limited resources. > > Thoughts also here? I found the "make mix" mechanism to be a nuisance. Also: 1. I was hoping to bulk-reformat the code with "indent" before we started doing any actual work on it (so we need to finalise the formatting conventions). AFAICT, bulk reformatting is safe. Compiling without -g [1] and with -DNODEBUG [2] then generating MD5 hashes for all of the .o files produces the same hashes before and after reformatting. [1] Debug information includes line numbers. [2] -DNODEBUG disables the assert() macro, which uses __LINE__ 2. Are we going to use CVS or Subversion for 7.x? -- Glynn Clements From michael.barton at asu.edu Sun Aug 12 01:00:38 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Aug 12 01:01:00 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <618B7E68-CB5C-4D05-B94C-F8F83B0FE8A1@unity.ncsu.edu> Message-ID: On 8/11/07 9:31 AM, "Helena Mitasova" wrote: > If you ask me what was the most annoying (but not critica) thing that > I have found when using > GRASS under a deadline - then it was the large default size of the > centroid symbol in d.vect. > I had to go through large number of vector data when preparing the > new data set > and each time I forgot to set the size smaller I got the unreadable > mess of overlapping crosses. > So if we could change the default to something smaller - perhaps size > 2 rather than 5, It looks like the default is 8, which is really large for centroids. would be fine for centroids. 5 is probably OK for points though. > that would be great, because most of the time you really want to see > your polygons > not the centroids and they are quite visible at size 2 even with my > old eyes Agreed. My preference would be have the centroids turned off by default, rather than on as is the current default. > (maybe make the default red as the default fill is grey). This was > already > discussed some time ago too. This is a problem since there is no way to set point colors separately from general line/fill colors that also affect polygons and arcs. I can see the benefit of it, but it would require yet another pair of options for d.vect (and updating of the TclTk options panel in the GUI). While we're on the subject of default preferences, I'd like to request that 'overlay' be the default for d.rast. Maybe I'm in the minority, but I nearly always want a raster to be able to overlay another so that the bottom one will show through the nulls of the top one--unless I want to set the nulls to some specific background color. Thinking about it, the whole thing could be handled in the background color setting. "None", the default, would make nulls transparent to underlying maps; picking any other color would make nulls opaque and set them to the desired color. Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 michael.barton at asu.edu Sun Aug 12 01:04:19 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Aug 12 01:05:09 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <18110.9692.77672.812420@cerise.gclements.plus.com> Message-ID: On 8/11/07 2:10 PM, "Glynn Clements" wrote: >> I realize that getting wxPython 2.8 on some systems is currently a problem, >> but this can be helped a lot by the release of wxPython packages for >> different Linux systems within the GRASS community (Mac and Windows binaries >> seem to be released along with any new wxPython version change). The recent >> prep of a Mandriva RPM by (sorry I can't remember) is a good example. Also, >> we never took advantage of the packaging features of TclTk, but could do so >> for a wxPython GUI to make this easier. > > Even if we provide .rpm/.deb/etc files for every OS in existence, many > people may be unwilling to use a third-party package which might > conceivably conflict with the "vendor" version. Sorry, but I don't understand your point here. How is providing a binary that is not available from the wxPython site in conflict with the 'vendor' version? This is just a convenience to make it easier for someone to install the software. They can always compile from source if they want a custom version. Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 massimodisasha at yahoo.it Sun Aug 12 01:58:10 2007 From: massimodisasha at yahoo.it (massimo di stefano) Date: Sun Aug 12 01:59:29 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <200708112105.l7BL5MSK026994@grass.itc.it> References: <200708112105.l7BL5MSK026994@grass.itc.it> Message-ID: Hi, i'm using 6.3-cvs on osx i compile it every 2-3 day on osx i found a problem running d.nviz from the gis.m button (fly trhough path for NVIZ) when press the related button i've this log : can't read "xmonlist": no such variable can't read "xmonlist": no such variable while executing "lindex $xmonlist 0" (procedure "guarantee_xmon" line 16) invoked from within "guarantee_xmon" (procedure "Gm::fly" line 3) invoked from within "Gm::fly" ("uplevel" body line 1) invoked from within "uplevel \#0 $cmd" (procedure "Button::_release" line 18) invoked from within "Button::_release .mainframe.topf.tb1.bbox4.b1" (command bound to event) runnig d.nviz directly from command line everyting works fine. to check if it is related to my ststem configuration i've compiled grass 6.2 using the same dependancie that i use for 6.3 release and i've that in grass-6.2 d.nviz works fine using the gis.m button nice to see that a7.0 is coming :-) really thanks to all developpers!!! Massimo Di Stefano Il giorno 11/ago/07, alle ore 23:05, Helena Mitasova ha scritto: > On Aug 11, 2007, at 4:14 AM, Markus Neteler wrote: > >> Hi, >> >> I think that it is time to get out a GRASS 6.3.0 release >> (as sort of technology preview). It would be great to >> have it ready for FOSS4G2007, say, September. >> >> IMHO, GRASS 6.3-CVS is in a good shape. Thoughts? > > Before the release, can somebody please double check that the > following works > (most of this I believe was already discussed and should be fixed): > > - nviz: you can add additional surfaces using the Raster surfaces > panel without crashing nviz > (please try different resolutions, spatial extent, mapsets) > - nviz: mask the displayed surface using a selected raster map from > within nviz (in my version the > mask only masked the displayed vector data) > - nviz: save state - you can save the state and then load it and > you can start working where you > stoped when you saved your state > - nviz: when saving the image, that the actual displayed image is > saved rather than redrawn image > (for example if you have loaded 4 surfaces and you display only one > of them the automatic redraw > during the saving procedure would display all four) > - nviz: file sequencing tool saves the entire path rather than just > the name of raster maps which > nviz then cannot interpret when you try to play the script > > I hope that most of this has been already fixed but generally I > have a 4 months old nviz on Mac > having more capabilities fully functional than my few weeks old > version on RedHat Linux, > so it would be good to test before releasing. > > Otherwise GRASS63 is probably in better shape and more > systematically tested than any > previous release as both Markus and I ran almost all GRASS commands > (not with all options though) > and although there has been some level of frustration, most things > work very well. > > If you ask me what was the most annoying (but not critica) thing > that I have found when using > GRASS under a deadline - then it was the large default size of the > centroid symbol in d.vect. > I had to go through large number of vector data when preparing the > new data set > and each time I forgot to set the size smaller I got the unreadable > mess of overlapping crosses. > So if we could change the default to something smaller - perhaps > size 2 rather than 5, > that would be great, because most of the time you really want to > see your polygons > not the centroids and they are quite visible at size 2 even with my > old eyes > (maybe make the default red as the default fill is grey). This was > already > discussed some time ago too. > > Helena > > > >> >> Markus -------------- parte successiva -------------- Un allegato HTML è stato rimosso... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070812/82c78c39/attachment-0001.html From hamish_nospam at yahoo.com Sun Aug 12 03:44:55 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Aug 12 03:44:58 2007 Subject: [GRASS-dev] [grass-code I][455] r.proj segfaults after Jul 14 changes In-Reply-To: Message-ID: <139411.37705.qm@web52710.mail.re2.yahoo.com> > > Paul Kelly wrote: > >> Well apart from passing NULL instead of an empty string being > >> obviously > >> wrong, a message that actually contains no information would > >> appear to be > >> improper use by definition, no? What's the point of it? Hamish: > > It's valid for G_done_msg(), it outputs like: > > $MODULE complete. $* > > > > with "", it just says "$MOD complete. " So passing a message is > > optional extra. William: > If it is intended to be optional for G_done_msg, then this needs to > be fixed. It's the vsprintf(buffer,msg,ap); part in there that is > causing trouble on OSX. If NULL is valid, then a check for NULL > should be done before vsprintf is called. Sorry, what I meant was it is valid for G_done_msg() to have an empty string as its argument, not that the empty string could be sent as NULL. Hamish ____________________________________________________________________________________ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ From hamish_nospam at yahoo.com Sun Aug 12 03:55:04 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Aug 12 03:55:08 2007 Subject: [GRASS-dev] [grass-code I][455] r.proj segfaults after Jul 14 changes In-Reply-To: <1186763547.2989.101.camel@dev64.localdomain> Message-ID: <46280.14246.qm@web52703.mail.re2.yahoo.com> >> G_done_msg() Brad Douglas wrote: > I'm opposed to adding largely unnecessary code. The console is NOT > designed for well laid out display. It is there for informational > purposes only. IMO, if you want pretty messages, use a GUI. A main reason for using G_done_msg() is that when run from a GUI it is not clear when the module has finished. Preferably the module's GUI output would print: [green check mark] "$MODULE complete." when the process has stopped but in the past (tcl gui) it was unclear how to do that. If the module is run from the command line the message is mostly redundant. Right now from the GUI you get output like: Loading raster map <> ... Processing ... Writing map ... n features cleaned But there really isn't any indication that the module is done. so really G_done_mgs() use is a sypmtom of a GUI shortcoming which is impinging onto other things. Hamish ____________________________________________________________________________________ Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/ From hamish_nospam at yahoo.com Sun Aug 12 04:50:00 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Aug 12 04:50:03 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <18109.44453.864055.963012@cerise.gclements.plus.com> Message-ID: <127118.68293.qm@web52701.mail.re2.yahoo.com> Paul: > > I was just thinking, the Python GUI can probably be merged into the CVS > > HEAD after a release branch has been created for 6.4.x (probably won't be > > ready for that for at least a couple of months). Then there will be 6.5.x > > - we can probably start making other major changes there and release it > > eventually as 7.0? How does that sound? Glynn: > I'm disinclined towards the creation of 6.4/6.5 versions. I would > prefer to see stable = 6.3.x, dev = 7.0-cvs. My inclination is to package 6.3.0 in the near future as a tech-preview release while keeping 6.2.x as the main stable line, and the version we recommend to brand new users. As I don't think it would break anything (or even touch anything other than init.sh), merging in the WxGUI from Markus's SVN before 6.3.0 release as a non-default optional GUI choice would be a nice thing. Lack of wx2.8 is a self-correcting problem with time; as long as Wx isn't the default GUI, we shouldn't worry ourselves about it. It's an optional extra. After 6.3.0(dev) is released get GRASSs' SVN running and start fresh GRASS 7.x devel there. (no comment right now on the 'make mix' question other than 1) I think the 5.7 transition worked very well, and 2) with 6.3.0(dev) released I don't mind the vast majority of development moving to the 7.x SVN- it isn't nearly as radical as migration as the 5.0->5.7 was for dev-users) If 7.0.0 is not ready for release in say 6 months, it might be nice to release a stable 6.4.0 dead-end release (much like 5.4.0 was). I don't like the idea of releasing 6.3.0 as a stable release, as: 1) we'd like to release it now, and IMO 6.3cvs isn't ready to be called stable [compared to 6.2.x's level of stability], which leads to: 2) 6.3.0 as devel release and 6.3.1 as stable sneds a mucky message to users. So I'd prefer a 6.4.0 --if it is decided in future to make another stable release in the 6.x line--. exec ver of suggestion: 1) wx -> CVS [soon] 2) release 6.3.0(dev) [just after that] 3) open SVN [just after that] 4) load indented 6.3-cvs as 7.0-dev in SVN, encourage all new devel to happen in 7.0-dev [just after that] [?? figure out in 'make mix' thread ??] 2c, Hamish ____________________________________________________________________________________ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ From paul-grass at stjohnspoint.co.uk Sun Aug 12 10:05:09 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sun Aug 12 10:05:21 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <18109.44453.864055.963012@cerise.gclements.plus.com> References: <20070811081434.GB28767@bartok.itc.it> <46BD715A.4050501@faunalia.it> <18109.44453.864055.963012@cerise.gclements.plus.com> Message-ID: On Sat, 11 Aug 2007, Glynn Clements wrote: > Paul Kelly wrote: > >> I was just thinking, the Python GUI can probably be merged into the CVS >> HEAD after a release branch has been created for 6.4.x (probably won't be >> ready for that for at least a couple of months). Then there will be 6.5.x >> - we can probably start making other major changes there and release it >> eventually as 7.0? How does that sound? > > I'm disinclined towards the creation of 6.4/6.5 versions. I would > prefer to see stable = 6.3.x, dev = 7.0-cvs. But that breaks with our convention of having odd sub-versions (5.3, 6.1 etc.) for incremental releases of "under-development" versions and even sub-versions (5.0, 5.4, 6.2 etc.) for releases of stable versions with incremental bugfixes. The way I see it, we should be making reasonably regular 6.3.x releases right now from the CVS HEAD. These are just development releases, to encourage people to test the latest developments, without having to get a CVS version. I actually think there's a good argument for releasing development versions at fixed intervals (e.g. every 2 months) - keeps everything well tested, adds a bit of motivation for developers to finish up new features shortly before a release is due and that kind of thing. With that logic in mind I really think we should release 6.3.0 straight away, right now - it isn't necessarily supposed to be totally stable - and then release successive 6.3.x releases, if necessary, in the next couple of months until we feel we're ready for a stable release - then we create a branch in CVS and release 6.4.0 from that. And after that the CVS HEAD is freed up to start putting major changes in. What the next version is called is a different issue though, but I think the move to SVN should be transparent and we don't need to use the actual move as a tool to help out version control - the situation with the two repositories for 5.0 and 6.0 resulted, as I understand it, because development on 6.x (then called 5.1.x) started way before 5.0.x had had its first stable release, and it was impractical to develop them both from the same repository. I think we're better organised enough now not to have to do that. Anyway version numbering - I don't see how we can ever call the CVS HEAD 7.0-CVS - because 0 is an even number - 7.0-CVS implies incremental bugfixes to an already-stable 7.0 version??? That's what it seems to me. How would incremental development versions be numbered then? Considering 6.2-CVS and 5.4-CVS - those both correspond to ultra-stable CVS branches that only have occasional bugfixes added to them. Much as in 5.7-CVS became the 6.0.0 stable release, it seems to me (or it *did* seem like that ;) that after the 6.4 branch is created, the CVS becomes 6.5-CVS, and this eventually becomes 7.0.0. BUT that breaks with the logic than changes in sub-version number should not result in major incompatible changes. This seems to be a flaw in our version-numbering system that I never noticed before, and I'm a bit stumped by it. Perhaps everyone else realises it already and that's why no one else is as pedantic about the version numbering as me. I suppose the question really boils down to are we going to abandon the sub-version numbering (odd development, even stable) system, or not? I feel it hasn't been totally unsucessful, but we really should have made more out of it by releasing more development versions. As far as I remember it was supposed to be similar to the Linux kernel system, and wonder how they handled the numbering of development releases before a major version number change - but (a) I don't think there's been one in the last 9 years, the time I've been using Linux anyway and (b) I suspect their system is also changing too as they find different ways of working. Bernhard used to have some interesting thoughts about this sort of thing; I wonder if he is still listening. Anyway, I just wanted to make clear why I suggested a 6.4 release branch followed by 6.5 CVS leading to 7.0.0. Although now I'm not quite as sure what's the most logical way forward... Paul From paul-grass at stjohnspoint.co.uk Sun Aug 12 10:15:51 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sun Aug 12 10:15:55 2007 Subject: [GRASS-dev] [grass-code I][455] r.proj segfaults after Jul 14 changes In-Reply-To: <46280.14246.qm@web52703.mail.re2.yahoo.com> References: <46280.14246.qm@web52703.mail.re2.yahoo.com> Message-ID: On Sat, 11 Aug 2007, Hamish wrote: > A main reason for using G_done_msg() is that when run from a GUI it is not > clear when the module has finished. Preferably the module's GUI output would > print: > > [green check mark] "$MODULE complete." > > when the process has stopped but in the past (tcl gui) it was unclear how to do > that. > > If the module is run from the command line the message is mostly redundant. > Right now from the GUI you get output like: > > Loading raster map <> ... > Processing ... > Writing map ... > n features cleaned > > > > But there really isn't any indication that the module is done. > > so really G_done_mgs() use is a sypmtom of a GUI shortcoming which is impinging > onto other things. ISTR if you look at the "title bar" for the currently running module in the gronsole screen there is a running man icon when the module is running, and it disappears when the module completes. Could def. be more obvious though. And if there is a lot of output it scrolls off the top of the screen and you don't see it. Paul From tutey at o2.pl Sun Aug 12 14:04:10 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sun Aug 12 14:04:33 2007 Subject: [GRASS-dev] [grass-code I][458] 6.2 modules using new parser flags Message-ID: <46BEF73A.7010806@o2.pl> code I item #458, was opened at 2007-08-11 16:28 Status: Open Priority: 2 Submitted By: Scott Mitchell (smitch) Assigned to: Nobody (None) >Summary: 6.2 modules using new parser flags Issue type: module bug Issue status: fixed in CVS GRASS version: 6.2 GRASS component: display >Operating system: all Operating system version: GRASS CVS checkout date, if applies (YYMMDD): >Comment By: Maciej Sieczka (msieczka) Date: 2007-08-11 22:44 Message: I have checked current 6.2 CVS source and I can find no occurences of --q or --v flags in use by any modules. BTW however, I have noticed that GEM already uses it's own --q flag (for --query, not for --quiet). I'm curious if this could cause any problems for the parser and if it should be changed. Apllies to both 6.2 and 6.3. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=458&group_id=21 From paul-grass at stjohnspoint.co.uk Sun Aug 12 14:11:19 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sun Aug 12 14:11:23 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <127118.68293.qm@web52701.mail.re2.yahoo.com> References: <127118.68293.qm@web52701.mail.re2.yahoo.com> Message-ID: On Sat, 11 Aug 2007, Hamish wrote: > Paul: >>> I was just thinking, the Python GUI can probably be merged into the CVS >>> HEAD after a release branch has been created for 6.4.x (probably won't be >>> ready for that for at least a couple of months). Then there will be 6.5.x >>> - we can probably start making other major changes there and release it >>> eventually as 7.0? How does that sound? > Glynn: >> I'm disinclined towards the creation of 6.4/6.5 versions. I would >> prefer to see stable = 6.3.x, dev = 7.0-cvs. > > > My inclination is to package 6.3.0 in the near future as a tech-preview release > while keeping 6.2.x as the main stable line, and the version we recommend to > brand new users. > > As I don't think it would break anything (or even touch anything other than > init.sh), merging in the WxGUI from Markus's SVN before 6.3.0 release as a > non-default optional GUI choice would be a nice thing. Lack of wx2.8 is a > self-correcting problem with time; as long as Wx isn't the default GUI, we > shouldn't worry ourselves about it. It's an optional extra. I think it would be bad to put it in now, because it would either (a) lead to too much extra work maintaining two versions of it in the 6.3/6.4 branch, and also in the 7.0 branch, or (b) we'd abandon it and put all effort into improvements and developments to the version in the 7.0 version, leaving people who've tried it in a 6.3/6.4 release with a different/poorer impression of the finished product compared to the version that will go along with 7.0.0. After the 6.4 stable release (or even before that - just as soon as we get some kind of division made by either creating a release branch or moving new development to SVN) it's likely we'll be making some quite big changes in the CVS HEAD, so I expect we'll be maintaining 6.4 in a "very usable and recommended" state for really quite a while - meaning there'll likely be a lot of improvements and changes to the wxpython GUI during the same period of time and it would really be a pain to backport them to 6.4. Especially if there are major changes in the display architecture and perhaps the way the wxpython GUI uses it? The same argument applies though to maintaining two versions of the Tcl/Tk gis.m. I wonder would it be too radical to delete gis.m from the CVS head after the 6.4 release branch has been created? It would keep things simple, in that bugfixes to gis.m could go into that branch and wouldn't affect anything else - it would also make it clear that wxpython is the only GUI we're supporting for 7.x and all efforts could go into it. Too radical? The other points I hope I mostly addressed in my last mail. Paul From glynn at gclements.plus.com Sun Aug 12 18:36:40 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Aug 12 18:36:58 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: References: <18110.9692.77672.812420@cerise.gclements.plus.com> Message-ID: <18111.14104.472057.460651@cerise.gclements.plus.com> Michael Barton wrote: > >> I realize that getting wxPython 2.8 on some systems is currently a problem, > >> but this can be helped a lot by the release of wxPython packages for > >> different Linux systems within the GRASS community (Mac and Windows binaries > >> seem to be released along with any new wxPython version change). The recent > >> prep of a Mandriva RPM by (sorry I can't remember) is a good example. Also, > >> we never took advantage of the packaging features of TclTk, but could do so > >> for a wxPython GUI to make this easier. > > > > Even if we provide .rpm/.deb/etc files for every OS in existence, many > > people may be unwilling to use a third-party package which might > > conceivably conflict with the "vendor" version. > > Sorry, but I don't understand your point here. How is providing a binary > that is not available from the wxPython site in conflict with the 'vendor' > version? This is just a convenience to make it easier for someone to install > the software. They can always compile from source if they want a custom > version. If the user already has e.g. wxPython 2.6 installed as part of the OS distribution, they may be reluctant to install any other version of wxPython. Not only do we need to ensure that a wxPython 2.8 package doesn't interfere with their existing installation in any way, but we also need to convince the user of that fact. We also need to ensure that the wxPython 2.8 package *does* get used by GRASS even though it doesn't get used by anything else which uses wxPython. Here, I set LD_LIBRARY_PATH and PYTHONPATH manually before running wxgrass. I'm not sure how easy it would be for GRASS to automate that, given that wxPython 2.8 is likely to be installed in such a way that it would normally be "invisible" to packages which use wxPython. -- Glynn Clements From glynn at gclements.plus.com Sun Aug 12 18:47:09 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Aug 12 18:47:12 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <127118.68293.qm@web52701.mail.re2.yahoo.com> References: <18109.44453.864055.963012@cerise.gclements.plus.com> <127118.68293.qm@web52701.mail.re2.yahoo.com> Message-ID: <18111.14733.802459.627471@cerise.gclements.plus.com> Hamish wrote: > Paul: > > > I was just thinking, the Python GUI can probably be merged into the CVS > > > HEAD after a release branch has been created for 6.4.x (probably won't be > > > ready for that for at least a couple of months). Then there will be 6.5.x > > > - we can probably start making other major changes there and release it > > > eventually as 7.0? How does that sound? > Glynn: > > I'm disinclined towards the creation of 6.4/6.5 versions. I would > > prefer to see stable = 6.3.x, dev = 7.0-cvs. > > > My inclination is to package 6.3.0 in the near future as a tech-preview release > while keeping 6.2.x as the main stable line, and the version we recommend to > brand new users. > > As I don't think it would break anything (or even touch anything other than > init.sh), merging in the WxGUI from Markus's SVN before 6.3.0 release as a > non-default optional GUI choice would be a nice thing. Lack of wx2.8 is a > self-correcting problem with time; as long as Wx isn't the default GUI, we > shouldn't worry ourselves about it. It's an optional extra. > > After 6.3.0(dev) is released get GRASSs' SVN running and start fresh GRASS 7.x > devel there. (no comment right now on the 'make mix' question other than 1) I > think the 5.7 transition worked very well, and 2) with 6.3.0(dev) released I > don't mind the vast majority of development moving to the 7.x SVN- it isn't > nearly as radical as migration as the 5.0->5.7 was for dev-users) > > If 7.0.0 is not ready for release in say 6 months, it might be nice to release > a stable 6.4.0 dead-end release (much like 5.4.0 was). I don't like the idea of > releasing 6.3.0 as a stable release, as: 1) we'd like to release it now, and > IMO 6.3cvs isn't ready to be called stable [compared to 6.2.x's level of > stability], which leads to: 2) 6.3.0 as devel release and 6.3.1 as stable sneds > a mucky message to users. So I'd prefer a 6.4.0 --if it is decided in future to > make another stable release in the 6.x line--. Once 6.3.0 is released, 6.3.x becomes stable insofar as future 6.3.x versions will be limited to bug-fixes. 7.0 is likely to diverge from 6.3.x rapidly enough that backporting typically won't be practical. -- Glynn Clements From glynn at gclements.plus.com Sun Aug 12 18:50:29 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Aug 12 18:50:33 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: References: <618B7E68-CB5C-4D05-B94C-F8F83B0FE8A1@unity.ncsu.edu> Message-ID: <18111.14933.302762.620223@cerise.gclements.plus.com> Michael Barton wrote: > While we're on the subject of default preferences, I'd like to request that > 'overlay' be the default for d.rast. Maybe I'm in the minority, but I nearly > always want a raster to be able to overlay another so that the bottom one > will show through the nulls of the top one--unless I want to set the nulls > to some specific background color. AFAICT, the -o switch is an artifact of 4.x lacking a distinct null value. -- Glynn Clements From michael.barton at asu.edu Sun Aug 12 18:50:44 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Aug 12 18:51:34 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: Message-ID: Massimo, Thanks for reporting this. I've been following up on your report and found very puzzling behavior, and finally identified the cause. I'll explain it and offer a couple ideas for a solution. The d.nviz button is a legacy of d.m because it allows you to interactively create a fly-though path by drawing with a mouse in an xterm display monitor. d.nviz then uses the result to create the path for NVIZ. In order to make it work with the new display system in the current GUI, the button first attempts to launch an xterm display monitor, using a TclTk procedure "guarantee_xmon". This procedure runs d.mon -L to see what display monitors are available and launches the first available one. It uses an xmon that is not currently running to avoid overwriting anything that you may be using an active xterm display monitor for. Although something of a kludge, the procedure works OK for the few commands that need it (e.g. r.digit) EXCEPT the d.nviz button. When the d.nviz button is pressed, a bit of debug code showed that ALL monitors were running and none were available to use for drawing a flight path. This is what is causing the error. The puzzling part is why ALL monitors should be running for the d.nviz button when NO xterm display monitors are running for any other command that needs an xterm. It turns out that an environmental variable "GRASS_RENDER_IMMEDIATE", which needs to be set to TRUE at the beginning of a TclTk GUI session for the display environment to work most efficiently, sets all xmons to running. This makes it impossible to open an unused xterm monitor for any command launched from the toolbar. So what to do... 1. Remove the nviz button and d.nviz buttons from the toolbar and put them back into the menu somewhere. There is no obvious place to put them (since nviz will display both rasters and vectors), but I guess the file menu would be OK. This should probably be done anyway to make sure a generic version of each command is available somewhere. It would be up to the user to launch an xmon and display a map in it for interactive fly-through creation. But the command would work. 2. Probably the best solution would be to put the d.nviz button into the mapdisplay toolbar and write a TclTk wrapper for d.nviz. This would let you draw the path on the map display canvas, grab the xy coordinates of each node, and send them to d.nviz for path creation. I don't know how difficult this would be to do. I'll look into it and report back. I also don't have a feel for how widely used this function is to justify the efforts for custom interface design. I'd appreciate any feedback on this. Michael On 8/11/07 4:58 PM, "massimo di stefano" wrote: > Hi, > > i'm using 6.3-cvs on osx? > i compile it every 2-3 day on osx > i found a problem running d.nviz from the gis.m button (fly trhough path for > NVIZ) > when press the related button i've this log : > > can't read "xmonlist": no such variable > can't read "xmonlist": no such variable > ? ? while executing > "lindex $xmonlist 0" > ? ? (procedure "guarantee_xmon" line 16) > ? ? invoked from within > "guarantee_xmon" > ? ? (procedure "Gm::fly" line 3) > ? ? invoked from within > "Gm::fly" > ? ? ("uplevel" body line 1) > ? ? invoked from within > "uplevel \#0 $cmd" > ? ? (procedure "Button::_release" line 18) > ? ? invoked from within > "Button::_release .mainframe.topf.tb1.bbox4.b1" > ? ? (command bound to event) > > runnig d.nviz directly from command line everyting works fine. > > to check if it is related to my ststem configuration? > i've compiled grass 6.2 using the same dependancie that i use for 6.3 release > and i've that?in grass-6.2 > d.nviz works fine using the gis.m button > > > > nice to see that a7.0 is coming :-) > > really thanks to all developpers!!! > > Massimo Di Stefano > > > Il giorno 11/ago/07, alle ore 23:05,?Helena Mitasova?ha scritto: > >> >> On Aug 11, 2007, at 4:14 AM, Markus Neteler wrote: >> >> >> >> >>> Hi, >>> >>> >>> >>> >>> >>> I think that it is time to get out a GRASS 6.3.0 release >>> >>> >>> (as sort of technology preview). It would be great to >>> >>> >>> have it ready for FOSS4G2007, say, September. >>> >>> >>> >>> >>> >>> IMHO, GRASS 6.3-CVS is in a good shape. Thoughts? >>> >> >> >> >> Before the release, can somebody please double check that the following works >> >> >> (most of this I believe was already discussed and should be fixed): >> >> >> >> >> >> - nviz: you can add additional surfaces using the Raster surfaces panel >> without crashing nviz >> >> >> ? (please try different resolutions, spatial extent, mapsets) >> >> >> - nviz: mask the displayed surface using a selected raster map from within >> nviz (in my version the >> >> >> mask only masked the displayed vector data) >> >> >> - nviz: save state - you can save the state and then load it and you can >> start working where you >> >> >> ? stoped when you saved your state >> >> >> - nviz: when saving the image, that the actual displayed image is saved >> rather than redrawn image >> >> >> (for example if you have loaded 4 surfaces and you display only one of them >> the automatic redraw >> >> >> ? during the saving procedure would display all four) >> >> >> - nviz: file sequencing tool saves the entire path rather than just the name >> of raster maps which >> >> >> ? nviz then cannot interpret when you try to play the script >> >> >> >> >> >> I hope that most of this has been already fixed but generally I have a 4 >> months old nviz on Mac >> >> >> having more capabilities fully functional than my few weeks old version on >> RedHat Linux, >> >> >> so it would be good to test before releasing. >> >> >> >> >> >> Otherwise GRASS63 is probably in better shape and more systematically tested >> than any >> >> >> previous release as both Markus and I ran almost all GRASS commands (not with >> all options though) >> >> >> and although there has been some level of frustration, most things work very >> well. >> >> >> >> >> >> If you ask me what was the most annoying (but not critica) thing that I have >> found when using >> >> >> GRASS under a deadline - then it was the large default size of the centroid >> symbol in d.vect. >> >> >> ?I had to go through large number of vector data when preparing the new data >> set >> >> >> and each time I forgot to set the size smaller I got the unreadable mess of >> overlapping crosses. >> >> >> So if we could change the default to something smaller - perhaps size 2 >> rather than 5, >> >> >> that would be great, because most of the time you really want to see your >> polygons >> >> >> not the centroids and they are quite visible at size 2 even with my old eyes >> >> >> (maybe make the default red as the default fill is grey). This was already >> >> >> discussed some time ago too. >> >> >> >> >> >> Helena >> >> >> >> >> >> >> >> >> >> >>> >>> >>> >>> Markus >>> > > __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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/20070812/2d994f48/attachment-0001.html From michael.barton at asu.edu Sun Aug 12 19:42:54 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Aug 12 19:43:22 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <18111.14104.472057.460651@cerise.gclements.plus.com> Message-ID: On 8/12/07 9:36 AM, "Glynn Clements" wrote: >>> Even if we provide .rpm/.deb/etc files for every OS in existence, many >>> people may be unwilling to use a third-party package which might >>> conceivably conflict with the "vendor" version. >> >> Sorry, but I don't understand your point here. How is providing a binary >> that is not available from the wxPython site in conflict with the 'vendor' >> version? This is just a convenience to make it easier for someone to install >> the software. They can always compile from source if they want a custom >> version. > > If the user already has e.g. wxPython 2.6 installed as part of the OS > distribution, they may be reluctant to install any other version of > wxPython. Thanks. I understand what you are getting at. I guess I'm accustomed to getting such software from the original distributor. E.g., Apple provides Python 2.3 with it's Mac distribution, but I've installed 2.5 directly from python.org. > > Not only do we need to ensure that a wxPython 2.8 package doesn't > interfere with their existing installation in any way, but we also > need to convince the user of that fact. I forget that many Linux users are accustomed to getting software from their distro repository. > > We also need to ensure that the wxPython 2.8 package *does* get used > by GRASS even though it doesn't get used by anything else which uses > wxPython. > > Here, I set LD_LIBRARY_PATH and PYTHONPATH manually before running > wxgrass. I'm not sure how easy it would be for GRASS to automate that, > given that wxPython 2.8 is likely to be installed in such a way that > it would normally be "invisible" to packages which use wxPython. Good points. I remember some directions at the wxPython download site for installing wxPython in non-standard locales and installing multiple versions. Maybe we could use those suggestions to deal with this. Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 michael.barton at asu.edu Sun Aug 12 19:47:33 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Aug 12 19:47:43 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <18111.14933.302762.620223@cerise.gclements.plus.com> Message-ID: On 8/12/07 9:50 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> While we're on the subject of default preferences, I'd like to request that >> 'overlay' be the default for d.rast. Maybe I'm in the minority, but I nearly >> always want a raster to be able to overlay another so that the bottom one >> will show through the nulls of the top one--unless I want to set the nulls >> to some specific background color. > > AFAICT, the -o switch is an artifact of 4.x lacking a distinct null > value. So is my suggestion doable? Maybe leave in -o for backward compatibility but have it do nothing, since this would be default behavior anyway. A script that depended on having nulls opaque (white) by leaving out the -flag and not setting a color probably would not be seriously harmed by this, though any underlying map might show through. Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 michael.barton at asu.edu Sun Aug 12 19:49:00 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Aug 12 19:49:08 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <127118.68293.qm@web52701.mail.re2.yahoo.com> Message-ID: On 8/11/07 7:50 PM, "Hamish" wrote: > As I don't think it would break anything (or even touch anything other than > init.sh), merging in the WxGUI from Markus's SVN before 6.3.0 release as a > non-default optional GUI choice would be a nice thing. Lack of wx2.8 is a > self-correcting problem with time; as long as Wx isn't the default GUI, we > shouldn't worry ourselves about it. It's an optional extra. > I'm for getting it distributed regularly as an optional alternative GUI ASAP for better testing. Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 Sun Aug 12 19:52:25 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Sun Aug 12 19:52:32 2007 Subject: [GRASS-dev] [grass-code I][455] r.proj segfaults after Jul 14 changes In-Reply-To: <46280.14246.qm@web52703.mail.re2.yahoo.com> References: <46280.14246.qm@web52703.mail.re2.yahoo.com> Message-ID: <1186941145.9282.68.camel@dev64.localdomain> On Sat, 2007-08-11 at 18:55 -0700, Hamish wrote: > >> G_done_msg() > > Brad Douglas wrote: > > I'm opposed to adding largely unnecessary code. The console is NOT > > designed for well laid out display. It is there for informational > > purposes only. IMO, if you want pretty messages, use a GUI. > > > A main reason for using G_done_msg() is that when run from a GUI it is not > clear when the module has finished. Preferably the module's GUI output would > print: > > [green check mark] "$MODULE complete." > > when the process has stopped but in the past (tcl gui) it was unclear how to do > that. > > If the module is run from the command line the message is mostly redundant. > Right now from the GUI you get output like: > > Loading raster map <> ... > Processing ... > Writing map ... > n features cleaned > > But there really isn't any indication that the module is done. > > so really G_done_mgs() use is a sypmtom of a GUI shortcoming which is impinging > onto other things. What I meant by "G_done_msg () is not living up to it's intended use" is that it should be re-implemented as a void function. Allowing people to add text to the string is causing too much confusion. It would be much easier to re-declare as 'G_done_msg (void)' and append it to modules that don't already use it to indicate completion. IMO, it should either be used everywhere or gotten rid of. -- 73, de Brad KB8UYR/6 From michael.barton at asu.edu Sun Aug 12 20:08:48 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Aug 12 20:08:59 2007 Subject: [GRASS-dev] fixing d.nviz access from GUI Message-ID: I did the first step I mentioned for dealing with d.nviz from the GUI. I removed the button for d.nviz and for nviz from the layer manager and added menu entries for both under a 3D rendering entry under the file menu. Now both commands can be launched in their generic forms from the GUI without an error. I'll still look into what it might take to do a TcloTk wrapper for d.nviz. I also tested multiple layers in nviz on the Mac with a version of 6.3 compiled on Friday. You can open multiple raster files, multiple color rasters, vector lines and vector points either by entering them into the GUI dialog before starting nviz or by adding them once you start nviz. This used to generate an error but works fine now. Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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/20070812/73ef1c73/attachment.html From wollez at gmx.net Sun Aug 12 21:20:43 2007 From: wollez at gmx.net (WolfgangZ) Date: Sun Aug 12 21:21:11 2007 Subject: [GRASS-dev] Launching GRASS 7 development In-Reply-To: <20070811171324.GB24682@bartok.itc.it> References: <20070811171324.GB24682@bartok.itc.it> Message-ID: Markus Neteler schrieb: > While we should concentrate now on getting out 6.3.0 (e.g., > fixing issues indicated by Helena [1]), it is important > to start planning for a GRASS 7 dev-branch management. > > For GRASS 6, we used for quite some time a mixed solution, > with new code stored in the grass6/ repository and linking > old, relevant code from grass[5]/ into it using some link > scripts. > > I am not sure if we want the same for grass7/, too. > On the other hand, replicating code is impossible since > it won't be well maintained given our limited resources. > > Thoughts also here? > > Let's continue to maintain > GRASS 7 ideas collection > http://grass.gdf-hannover.de/wiki/GRASS_7_ideas_collection > > Markus > > [1] http://grass.itc.it/pipermail/grass-dev/2007-August/032579.html I'm only a (non frequent) user of grass. But wouldn't it be nice to have grass7 with its own shell, to get rid of all these bash dependencies which make many modules hardly portable (I would prefer a python like shell). It is just a suggestion as I'm not able to contribute code. regards wolfgang From neteler at itc.it Sun Aug 12 21:40:29 2007 From: neteler at itc.it (Markus Neteler) Date: Sun Aug 12 21:40:31 2007 Subject: [GRASS-dev] Launching GRASS 7 development In-Reply-To: <18110.10167.537908.798478@cerise.gclements.plus.com> References: <20070811171324.GB24682@bartok.itc.it> <18110.10167.537908.798478@cerise.gclements.plus.com> Message-ID: <20070812194028.GA11020@bartok.itc.it> On Sat, Aug 11, 2007 at 10:18:47PM +0100, Glynn Clements wrote: > Markus Neteler wrote: > > While we should concentrate now on getting out 6.3.0 (e.g., > > fixing issues indicated by Helena [1]), it is important > > to start planning for a GRASS 7 dev-branch management. > > > > For GRASS 6, we used for quite some time a mixed solution, > > with new code stored in the grass6/ repository and linking > > old, relevant code from grass[5]/ into it using some link > > scripts. > > > > I am not sure if we want the same for grass7/, too. > > On the other hand, replicating code is impossible since > > it won't be well maintained given our limited resources. > > > > Thoughts also here? > > I found the "make mix" mechanism to be a nuisance. Me, too. > Also: > > 1. I was hoping to bulk-reformat the code with "indent" before we > started doing any actual work on it (so we need to finalise the > formatting conventions). > > AFAICT, bulk reformatting is safe. Compiling without -g [1] and with > -DNODEBUG [2] then generating MD5 hashes for all of the .o files > produces the same hashes before and after reformatting. > > [1] Debug information includes line numbers. > [2] -DNODEBUG disables the assert() macro, which uses __LINE__ This sounds very good. > 2. Are we going to use CVS or Subversion for 7.x? My suggestion is to start new repository from scratch in SVN using the *migrated* CVS repos to maintain history. This is essential, also for copyright issues and other reasons. Moving files around in SVN is very easy (while it is not in CVS). The hassle of double maintenance (backporting) would remain of course. Since the CVS admins signalled to have no time for a migration, we can temporarily start on "my" own SVN server or ask for an OSGeo SVN server repository. Still we have to figure out the flags of the cvs2svn conversion script. Markus From hmitaso at unity.ncsu.edu Sun Aug 12 23:00:31 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Sun Aug 12 23:00:38 2007 Subject: [GRASS-dev] Launching GRASS 7 development In-Reply-To: <20070812194028.GA11020@bartok.itc.it> References: <20070811171324.GB24682@bartok.itc.it> <18110.10167.537908.798478@cerise.gclements.plus.com> <20070812194028.GA11020@bartok.itc.it> Message-ID: <112EE923-A2EF-49B1-BB34-3EC02EA83A76@unity.ncsu.edu> On Aug 12, 2007, at 3:40 PM, Markus Neteler wrote: > On Sat, Aug 11, 2007 at 10:18:47PM +0100, Glynn Clements wrote: >> Markus Neteler wrote: >>> While we should concentrate now on getting out 6.3.0 (e.g., >>> fixing issues indicated by Helena [1]), it is important >>> to start planning for a GRASS 7 dev-branch management. >>> >>> For GRASS 6, we used for quite some time a mixed solution, >>> with new code stored in the grass6/ repository and linking >>> old, relevant code from grass[5]/ into it using some link >>> scripts. >>> >>> I am not sure if we want the same for grass7/, too. >>> On the other hand, replicating code is impossible since >>> it won't be well maintained given our limited resources. >>> >>> Thoughts also here? >> >> I found the "make mix" mechanism to be a nuisance. > > Me, too. > >> Also: >> >> 1. I was hoping to bulk-reformat the code with "indent" before we >> started doing any actual work on it (so we need to finalise the >> formatting conventions). >> >> AFAICT, bulk reformatting is safe. Compiling without -g [1] and with >> -DNODEBUG [2] then generating MD5 hashes for all of the .o files >> produces the same hashes before and after reformatting. >> >> [1] Debug information includes line numbers. >> [2] -DNODEBUG disables the assert() macro, which uses __LINE__ > > This sounds very good. > >> 2. Are we going to use CVS or Subversion for 7.x? > > My suggestion is to start new repository from scratch in SVN > using the *migrated* CVS repos to maintain history. This is essential, > also for copyright issues and other reasons. Moving files around in > SVN > is very easy (while it is not in CVS). The hassle of double > maintenance > (backporting) would remain of course. > > Since the CVS admins signalled to have no time for a migration, > we can temporarily start on "my" own SVN server or ask for an > OSGeo SVN server repository. Markus - I suggest to avoid temporary solutions because they tend to stick around for years. Let us try the OSGeo SVN server if you think that it will work - that may help to test and build a strong OSGeo infrastructure. Helena > > Still we have to figure out the flags of the cvs2svn conversion > script. > > Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From glynn at gclements.plus.com Sun Aug 12 23:33:11 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Aug 12 23:33:25 2007 Subject: [GRASS-dev] [grass-code I][458] 6.2 modules using new parser flags In-Reply-To: <46BEF73A.7010806@o2.pl> References: <46BEF73A.7010806@o2.pl> Message-ID: <18111.31895.413240.980275@cerise.gclements.plus.com> Maciej Sieczka wrote: > code I item #458, was opened at 2007-08-11 16:28 > Status: Open > Priority: 2 > Submitted By: Scott Mitchell (smitch) > Assigned to: Nobody (None) > >Summary: 6.2 modules using new parser flags > Issue type: module bug > Issue status: fixed in CVS > GRASS version: 6.2 > GRASS component: display > >Operating system: all > Operating system version: > GRASS CVS checkout date, if applies (YYMMDD): > > > >Comment By: Maciej Sieczka (msieczka) > Date: 2007-08-11 22:44 > > Message: > I have checked current 6.2 CVS source and I can find no occurences of > --q or --v flags in use by any modules. The --q[uiet] and --v[erbose] flags are implemented by G_parser(), and aren't present in 6.2.x. I'm unsure whether to remove the --quiet flags only from the 6.2.x version of d.slide.show, or also from the 6.3.x version. IMHO, d.slide.show should simply allow the d.rast/d.vect commands to operate at the verbosity level set by $GRASS_VERBOSE. If d.slide.show itself is passed --q or --v, GRASS_VERBOSE will be set accordingly, and the d.rast/d.vect commands will inherit that setting. Otherwise, they will inherit any existing setting of $GRASS_VERBOSE. Forcing the commands to operate quietly regardless of --v or any $GRASS_VERBOSE setting seems incorrect. -- Glynn Clements From glynn at gclements.plus.com Sun Aug 12 23:51:04 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Aug 12 23:51:10 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: References: <18111.14104.472057.460651@cerise.gclements.plus.com> Message-ID: <18111.32968.886499.481395@cerise.gclements.plus.com> Michael Barton wrote: > > We also need to ensure that the wxPython 2.8 package *does* get used > > by GRASS even though it doesn't get used by anything else which uses > > wxPython. > > > > Here, I set LD_LIBRARY_PATH and PYTHONPATH manually before running > > wxgrass. I'm not sure how easy it would be for GRASS to automate that, > > given that wxPython 2.8 is likely to be installed in such a way that > > it would normally be "invisible" to packages which use wxPython. > > Good points. I remember some directions at the wxPython download site for > installing wxPython in non-standard locales and installing multiple > versions. Maybe we could use those suggestions to deal with this. It can certainly be done; the issue is the effort required to do it reliably without user intervention. Off the top of my head: wxgrass will need to: 1. Catch any exceptions which arise from "import wx" (i.e. no wxPython as part of the standard Python installation) or "import wx.aui" (i.e. wxPython < 2.8). 2. Attempt to locate wxPython 2.8, by looking for directories where it is likely to be found (i.e. wherever the provided binary packages put it). 3. Re-invoke itself, after having updated LD_LIBRARY_PATH (or the equivalent for other platforms) and PYTHONPATH accordingly. If the user has built wxPython 2.8 themselves, or is using a binary package installed in a location unknown to #2, they will need to set LD_LIBRARY_PATH (etc) and PYTHONPATH themselves; that will prevent any exceptions at #1 (i.e. the package will appear to be part of the standard wxPython installation so far as wxgrass is concerned). -- Glynn Clements From glynn at gclements.plus.com Mon Aug 13 00:12:32 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Aug 13 00:12:34 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: References: <20070811081434.GB28767@bartok.itc.it> <46BD715A.4050501@faunalia.it> <18109.44453.864055.963012@cerise.gclements.plus.com> Message-ID: <18111.34256.453478.196314@cerise.gclements.plus.com> Paul Kelly wrote: > >> I was just thinking, the Python GUI can probably be merged into the CVS > >> HEAD after a release branch has been created for 6.4.x (probably won't be > >> ready for that for at least a couple of months). Then there will be 6.5.x > >> - we can probably start making other major changes there and release it > >> eventually as 7.0? How does that sound? > > > > I'm disinclined towards the creation of 6.4/6.5 versions. I would > > prefer to see stable = 6.3.x, dev = 7.0-cvs. > > But that breaks with our convention of having odd sub-versions (5.3, 6.1 > etc.) for incremental releases of "under-development" versions and even > sub-versions (5.0, 5.4, 6.2 etc.) for releases of stable versions with > incremental bugfixes. We haven't actually put much effort into following this convention. The 5.x numbering was somewhat screwed up by Radim arbitrarily picking a version for his own private branch. What has happened with 6.x so far is: 6.0-cvs ---+-- 6.1-cvs ---+------+--- 6.3-cvs --- | | | 6.0.0 6.1.0 6.2.0 | | | where the horizontal line is the trunk and the vertical lines the branches. IOW, we only started trying to follow the odd/even convention after 6.1.0 (a year ago yesterday: 2006-08-11). Personally, I'm not too concerned about how minor numbers are handled. Just wake me up when there's a 7.x branch where wholesale demolition and rebuilding can occur. -- Glynn Clements From glynn at gclements.plus.com Mon Aug 13 00:13:54 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Aug 13 00:13:58 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: References: <18111.14933.302762.620223@cerise.gclements.plus.com> Message-ID: <18111.34338.678404.316126@cerise.gclements.plus.com> Michael Barton wrote: > >> While we're on the subject of default preferences, I'd like to request that > >> 'overlay' be the default for d.rast. Maybe I'm in the minority, but I nearly > >> always want a raster to be able to overlay another so that the bottom one > >> will show through the nulls of the top one--unless I want to set the nulls > >> to some specific background color. > > > > AFAICT, the -o switch is an artifact of 4.x lacking a distinct null > > value. > > So is my suggestion doable? Maybe leave in -o for backward compatibility but > have it do nothing, since this would be default behavior anyway. A script > that depended on having nulls opaque (white) by leaving out the -flag and > not setting a color probably would not be seriously harmed by this, though > any underlying map might show through. I'd say leave it for 7.x. -- Glynn Clements From glynn at gclements.plus.com Mon Aug 13 00:20:27 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Aug 13 00:20:30 2007 Subject: [GRASS-dev] Launching GRASS 7 development In-Reply-To: References: <20070811171324.GB24682@bartok.itc.it> Message-ID: <18111.34731.240466.634245@cerise.gclements.plus.com> WolfgangZ wrote: > > While we should concentrate now on getting out 6.3.0 (e.g., > > fixing issues indicated by Helena [1]), it is important > > to start planning for a GRASS 7 dev-branch management. > > > > For GRASS 6, we used for quite some time a mixed solution, > > with new code stored in the grass6/ repository and linking > > old, relevant code from grass[5]/ into it using some link > > scripts. > > > > I am not sure if we want the same for grass7/, too. > > On the other hand, replicating code is impossible since > > it won't be well maintained given our limited resources. > > > > Thoughts also here? > > > > Let's continue to maintain > > GRASS 7 ideas collection > > http://grass.gdf-hannover.de/wiki/GRASS_7_ideas_collection > > > > Markus > > > > [1] http://grass.itc.it/pipermail/grass-dev/2007-August/032579.html > > I'm only a (non frequent) user of grass. But wouldn't it be nice to have > grass7 with its own shell, to get rid of all these bash dependencies > which make many modules hardly portable (I would prefer a python like > shell). The choice of shell must be up to the user. bash is a perfectly good interactive shell; it just sucks (badly) as a programming language, and will probably never be satisfactory on Windows. For 7.x, my choice would be to require the use of Python for any scripts which are part of GRASS, with the possible exception of any critical scripts (e.g. Init.sh), where it may be worthwhile maintaining at least minimal /bin/sh and cmd.exe versions, so that users who (for whatever reason) do not have Python can still use most of GRASS. -- Glynn Clements From michael.barton at asu.edu Mon Aug 13 03:07:37 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Aug 13 03:08:19 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <18111.32968.886499.481395@cerise.gclements.plus.com> Message-ID: All very good ideas. I'm copying others working on the wxPython GUI who might have ideas on how to do this. Michael On 8/12/07 2:51 PM, "Glynn Clements" wrote: > > Michael Barton wrote: > >>> We also need to ensure that the wxPython 2.8 package *does* get used >>> by GRASS even though it doesn't get used by anything else which uses >>> wxPython. >>> >>> Here, I set LD_LIBRARY_PATH and PYTHONPATH manually before running >>> wxgrass. I'm not sure how easy it would be for GRASS to automate that, >>> given that wxPython 2.8 is likely to be installed in such a way that >>> it would normally be "invisible" to packages which use wxPython. >> >> Good points. I remember some directions at the wxPython download site for >> installing wxPython in non-standard locales and installing multiple >> versions. Maybe we could use those suggestions to deal with this. > > It can certainly be done; the issue is the effort required to do it > reliably without user intervention. > > Off the top of my head: wxgrass will need to: > > 1. Catch any exceptions which arise from "import wx" (i.e. no wxPython > as part of the standard Python installation) or "import wx.aui" (i.e. > wxPython < 2.8). > > 2. Attempt to locate wxPython 2.8, by looking for directories where it > is likely to be found (i.e. wherever the provided binary packages put > it). > > 3. Re-invoke itself, after having updated LD_LIBRARY_PATH (or the > equivalent for other platforms) and PYTHONPATH accordingly. > > If the user has built wxPython 2.8 themselves, or is using a binary > package installed in a location unknown to #2, they will need to set > LD_LIBRARY_PATH (etc) and PYTHONPATH themselves; that will prevent any > exceptions at #1 (i.e. the package will appear to be part of the > standard wxPython installation so far as wxgrass is concerned). __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From tutey at o2.pl Mon Aug 13 22:43:32 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Aug 13 22:43:57 2007 Subject: [GRASS-dev] [grass-code I][458] 6.2 modules using new parser flags In-Reply-To: <18111.31895.413240.980275@cerise.gclements.plus.com> References: <46BEF73A.7010806@o2.pl> <18111.31895.413240.980275@cerise.gclements.plus.com> Message-ID: <46C0C274.9070301@o2.pl> Glynn Clements wrote: > Maciej Sieczka wrote: > >> code I item #458, was opened at 2007-08-11 16:28 >> Status: Open >> Priority: 2 >> Submitted By: Scott Mitchell (smitch) >> Assigned to: Nobody (None) >>> Summary: 6.2 modules using new parser flags >> Issue type: module bug >> Issue status: fixed in CVS >> GRASS version: 6.2 >> GRASS component: display >>> Operating system: all >> Operating system version: >> GRASS CVS checkout date, if applies (YYMMDD): >> >> >>> Comment By: Maciej Sieczka (msieczka) >> Date: 2007-08-11 22:44 >> >> Message: >> I have checked current 6.2 CVS source and I can find no occurences of >> --q or --v flags in use by any modules. > > The --q[uiet] and --v[erbose] flags are implemented by G_parser(), and > aren't present in 6.2.x. I meant that I checked if, in error, any of them was used in other 6.2 modules besides the d.slide.show. Maciek From neteler.osgeo at gmail.com Mon Aug 13 22:44:08 2007 From: neteler.osgeo at gmail.com (Markus Neteler) Date: Mon Aug 13 22:44:14 2007 Subject: [GRASS-dev] Fwd: Grass to Indian languages: Challenges Message-ID: <86782b610708131344k570dfac6wf4d82719e69b2958@mail.gmail.com> Here a FWD (with permission) to discuss the problem of Indian fonts support in GRASS. I wonder if the new fond infrastructure helps in this regards. additional message from jitendra: > Please do give your critical comments on the website > www.pcmcgisda.org.in Markus ---------- Forwarded message ---------- From: jitendra Date: Aug 10, 2007 7:23 PM Subject: Re: [OSGeo-Discuss] Grass to Indian languages : Challenges To: Ravi Vundavalli Cc: neteler.osgeo@gmail.com, Swapnil Hajare Dear Ravi, it is true that we had started translating grass (version 5.1 onwards ) into Hindi and marathi around the time of the birth of indictrans i.e circa 2003 as volunteers. However we couldnot keep pace and did find major changes coming up . In fact during 2004-2005, as a part of central govt project janabhaaratii, we had plans to translate grass on professional payment basis in 6 indian languages. But that too was not to be. My technical guru Swapnil had this to say," "We had attempted localization of GRASS GIS earlier. The existing translations for Hindi and Marathi are done by me only. But we stopped doing that mainly because we thought there is no point in translating interface in absence of support for rendering the indic text. GRASS uses Tcl/Tk for interface which doesnt have support for rendering Unicode Indic text. So even if we translate the po file, it won't be displayed properly. More important thing which I was more attracted to was to add support for Indic text label rendering in d.text.freetype (see http://indictrans.in/~swapnil/grass_indix2_20051201.png ). I had done this using Indix2 library which unfortunately is no more developed and is not available on Xorg (it only works on XFree86 < 4.1). So I was going to implement the same solution using widely used Indic rendering engine such as Pango or Qt. " My take on this is another short term solution pending a better solution . This is assuming that tcl/tk can render multibyte ttf font. If so, we can convert the text in unicode ( normally encoded to support opentype fonts which have a rendering program as part of the font) into another font (we call it setu series) , and use the same for display. There is as of now no support for input in setu. A program is available to convert the text from usual unicode to setu unicode. This will entail hardcoding the font setu with grass tcl/tk script. This font has been developed for devanagari but can be developed for all indian languages. The result of this approach can be seen on www.pcmcgisda.org.in where we have mapserver map labels in devanagari . This is a problem for all graphic programs which have been internationalised for CJK with multibyte unicode fonts but have no support for opentype. If osgeo (international or india )can financially support this work, we can put some effort to find a short term quick fix, get translations done systematically work towards a long term solution by proposing a research program If we put together a good effort and get support from grass developers, We can even write a proposal for support from the Government of India for research efforts for adding all indian language support . I am confident we can get the support as egovrnance inititives require GIS very intensely and widely. I have seen the bright eyes of many bureacrats who have seen the indian language on maps on the web to be so confident. warm regards jitendra From grass-dev at grass.itc.it Tue Aug 14 01:48:25 2007 From: grass-dev at grass.itc.it (grass-dev@grass.itc.it) Date: Tue Aug 14 01:43:49 2007 Subject: [GRASS-dev] [grass-code I][459] Bug in r.le.patch Message-ID: <20070813234825.19072B4005@pyrosoma.intevation.org> code I item #459, was opened at 2007-08-13 18:48 Status: Open Priority: 3 Submitted By: Pedro Camilo Alcantara C (camiloalcantara) Assigned to: Nobody (None) Summary: Bug in r.le.patch Issue type: module bug Issue status: confirmed GRASS version: 6.2.1 GRASS component: raster Operating system: Linux Operating system version: 2.6.22-1-686 (Debian 2.6.22-3) GRASS CVS checkout date, if applies (YYMMDD): 6.2.2 Initial Comment: r.le.patch -c map=forest sam=w att=a1,a2,a3,a4 siz=s1,s2,s7,s8 co1=5 co2=c1,c2,c3,c4 sh1=m1 sh2=h1,h2 per=p1,p2,p3 out=individual R.LE.PATCH IS WORKING....; *** glibc detected *** r.le.patch: free(): invalid next size (fast): 0x0c37d598 *** ======= Backtrace: ========= /lib/i686/cmov/libc.so.6[0xb7d9bcf5] /lib/i686/cmov/libc.so.6(cfree+0x90)[0xb7d9f790] /usr/local/grass-6.2.2/lib/libgrass_gis.so(G_free+0x1d)[0xb7ee5cfd] /usr/local/grass-6.2.2/lib/libgrass_gis.so(G__file_name+0x71)[0xb7ef3331] /usr/local/grass-6.2.2/lib/libgrass_gis.so(G_raster_map_type+0x5a)[0xb7f0302a] r.le.patch(cell_clip+0x73)[0x805f223] r.le.patch(cell_clip_drv+0x15b)[0x805fd3b] r.le.patch(whole_reg_driver+0x68)[0x804ab38] r.le.patch(patch_fore+0x96)[0x8054be6] r.le.patch(main+0x4c3)[0x8056f33] /lib/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7d48050] r.le.patch[0x804aa61] ======= Memory map: ======== 08048000-08064000 r-xp 00000000 03:01 591040 /usr/local/grass-6.2.2/bin/r.le.patch 08064000-08065000 rw-p 0001c000 03:01 591040 /usr/local/grass-6.2.2/bin/r.le.patch 08065000-0c383000 rw-p 08065000 00:00 0 [heap] b7c00000-b7c21000 rw-p b7c00000 00:00 0 b7c21000-b7d00000 ---p b7c21000 00:00 0 b7d25000-b7d2f000 r-xp 00000000 03:01 930565 /lib/libgcc_s.so.1 b7d2f000-b7d30000 rw-p 00009000 03:01 930565 /lib/libgcc_s.so.1 b7d30000-b7d32000 rw-p b7d30000 00:00 0 b7d32000-b7e74000 r-xp 00000000 03:01 962961 /lib/i686/cmov/libc-2.6.1.so b7e74000-b7e75000 r--p 00142000 03:01 962961 /lib/i686/cmov/libc- 2.6.1.so b7e75000-b7e77000 rw-p 00143000 03:01 962961 /lib/i686/cmov/libc- 2.6.1.so b7e77000-b7e7a000 rw-p b7e77000 00:00 0 b7e7a000-b7e9d000 r-xp 00000000 03:01 963090 /lib/i686/cmov/libm- 2.6.1.so b7e9d000-b7e9f000 rw-p 00023000 03:01 963090 /lib/i686/cmov/libm- 2.6.1.so b7e9f000-b7eb3000 r-xp 00000000 03:01 314656 /usr/lib/libz.so.1.2.3.3 b7eb3000-b7eb4000 rw-p 00013000 03:01 314656 /usr/lib/libz.so.1.2.3.3 b7ed0000-b7ed7000 r-xp 00000000 03:01 690236 /usr/local/grass-6.2.2/lib/libgrass_datetime.6.2.2.so b7ed7000-b7ed8000 rw-p 00006000 03:01 690236 /usr/local/grass- 6.2.2/lib/libgrass_datetime.6.2.2.so b7ed8000-b7f20000 r-xp 00000000 03:01 690239 /usr/local/grass-6.2.2/lib/libgrass_gis.6.2.2.so b7f20000-b7f21000 rw-p 00048000 03:01 690239 /usr/local/grass-6.2.2/lib/libgrass_gis.6.2.2.so b7f21000-b7f3a000 rw-p b7f21000 00:00 0 b7f3a000-b7f56000 r-xp 00000000 03:01 930319 /lib/ld-2.6.1.so b7f56000-b7f58000 rw-p 0001b000 03:01 930319 /lib/ld- 2.6.1.so bfb06000-bfb1b000 rw-p bfb06000 00:00 0 [stack] ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso] Aborted Markus Neteler replication of the bug: I can replicate this with Spearfish: GRASS 6.3.cvs (spearfish60):~ > g.copy fields,myfields GRASS 6.3.cvs (spearfish60):~ > gdb r.le.patch GNU gdb Red Hat Linux (6.3.0.0-1.143.el4rh) ... This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/tls/libthread_db.so.1". (gdb) r -c map=myfields sam=w att=a1,a2,a3,a4 siz=s1,s2,s7,s8 co1=5 co2=c1,c2,c3,c4 sh1=m1 sh2=h1,h2 per=p1,p2,p3 out=individual *** glibc detected *** free(): invalid next size (fast): 0x000000000064b900 *** Program received signal SIGABRT, Aborted. 0x00000037ba52e21d in raise () from /lib64/tls/libc.so.6 (gdb) bt #0 0x00000037ba52e21d in raise () from /lib64/tls/libc.so.6 #1 0x00000037ba52fa1e in abort () from /lib64/tls/libc.so.6 #2 0x00000037ba563451 in __libc_message () from /lib64/tls/libc.so.6 #3 0x00000037ba56906e in _int_free () from /lib64/tls/libc.so.6 #4 0x00000037ba5693b6 in free () from /lib64/tls/libc.so.6 #5 0x0000002a95569e77 in G_free (buf=0x64b900) at alloc.c:126 #6 0x0000002a95581301 in open_null_read (fd=6) at get_row.c:883 #7 0x0000002a95581544 in get_null_value_row_nomask (fd=6, flags=0x523f20 "h\031s?7", row=0) at get_row.c:948 #8 0x0000002a95581945 in get_null_value_row (fd=6, flags=0x523f20 "h\031s?7", row=0, with_mask=1) at get_row.c:1041 #9 0x0000002a955819fe in embed_nulls (fd=6, buf=0x64b520, row=0, map_type=0, null_is_zero=0, with_mask=1) at get_row.c:1060 #10 0x0000002a95580e7e in get_map_row_no_reclass (fd=6, rast=0x64b520, row=0, data_type=0, null_is_zero=0, with_mask=1) at get_row.c:594 #11 0x0000002a95580f5d in get_map_row (fd=6, rast=0x64b520, row=0, data_type=0, null_is_zero=0, with_mask=1) at get_row.c:625 #12 0x0000002a95581189 in G_get_raster_row (fd=6, buf=0x64b520, row=0, data_type=0) at get_row.c:787 #13 0x00000000004177dc in cell_clip (buf=0x529d90, null_buf=0x58a560, row0=0, col0=0, nrows=197, ncols=243, index=0, radius=0, centernull=0x7fbfffed74, empty=0x7fbfffed70) at trace.c:591 #14 0x00000000004168b4 in cell_clip_drv (col0=0, row0=0, ncols=243, nrows=197, value=0x0, index=0, radius=0) at trace.c:156 #15 0x000000000040cbbd in whole_reg_driver () at driver.c:2737 #16 0x00000000004035ae in patch_fore () at driver.c:111 #17 0x000000000040f756 in main (argc=12, argv=0x7fbfffef68) at main.c:151 (gdb) #0 0x00000037ba52e21d in raise () from /lib64/tls/libc.so.6 #1 0x00000037ba52fa1e in abort () from /lib64/tls/libc.so.6 #2 0x00000037ba563451 in __libc_message () from /lib64/tls/libc.so.6 #3 0x00000037ba56906e in _int_free () from /lib64/tls/libc.so.6 #4 0x00000037ba5693b6 in free () from /lib64/tls/libc.so.6 #5 0x0000002a95569e77 in G_free (buf=0x64b900) at alloc.c:126 #6 0x0000002a95581301 in open_null_read (fd=6) at get_row.c:883 #7 0x0000002a95581544 in get_null_value_row_nomask (fd=6, flags=0x523f20 "h\031s?7", row=0) at get_row.c:948 #8 0x0000002a95581945 in get_null_value_row (fd=6, flags=0x523f20 "h\031s?7", row=0, with_mask=1) at get_row.c:1041 #9 0x0000002a955819fe in embed_nulls (fd=6, buf=0x64b520, row=0, map_type=0, null_is_zero=0, with_mask=1) at get_row.c:1060 #10 0x0000002a95580e7e in get_map_row_no_reclass (fd=6, rast=0x64b520, row=0, data_type=0, null_is_zero=0, with_mask=1) at get_row.c:594 #11 0x0000002a95580f5d in get_map_row (fd=6, rast=0x64b520, row=0, data_type=0, null_is_zero=0, with_mask=1) at get_row.c:625 #12 0x0000002a95581189 in G_get_raster_row (fd=6, buf=0x64b520, row=0, data_type=0) at get_row.c:787 #13 0x00000000004177dc in cell_clip (buf=0x529d90, null_buf=0x58a560, row0=0, col0=0, nrows=197, ncols=243, index=0, radius=0, centernull=0x7fbfffed74, empty=0x7fbfffed70) at trace.c:591 #14 0x00000000004168b4 in cell_clip_drv (col0=0, row0=0, ncols=243, nrows=197, value=0x0, index=0, radius=0) at trace.c:156 #15 0x000000000040cbbd in whole_reg_driver () at driver.c:2737 #16 0x00000000004035ae in patch_fore () at driver.c:111 #17 0x000000000040f756 in main (argc=12, argv=0x7fbfffef68) at main.c:151 (gdb) #0 0x00000037ba52e21d in raise () from /lib64/tls/libc.so.6 #1 0x00000037ba52fa1e in abort () from /lib64/tls/libc.so.6 #2 0x00000037ba563451 in __libc_message () from /lib64/tls/libc.so.6 #3 0x00000037ba56906e in _int_free () from /lib64/tls/libc.so.6 #4 0x00000037ba5693b6 in free () from /lib64/tls/libc.so.6 #5 0x0000002a95569e77 in G_free (buf=0x64b900) at alloc.c:126 #6 0x0000002a95581301 in open_null_read (fd=6) at get_row.c:883 #7 0x0000002a95581544 in get_null_value_row_nomask (fd=6, flags=0x523f20 "h\031s?7", row=0) at get_row.c:948 #8 0x0000002a95581945 in get_null_value_row (fd=6, flags=0x523f20 "h\031s?7", row=0, with_mask=1) at get_row.c:1041 #9 0x0000002a955819fe in embed_nulls (fd=6, buf=0x64b520, row=0, map_type=0, null_is_zero=0, with_mask=1) at get_row.c:1060 #10 0x0000002a95580e7e in get_map_row_no_reclass (fd=6, rast=0x64b520, row=0, data_type=0, null_is_zero=0, with_mask=1) at get_row.c:594 #11 0x0000002a95580f5d in get_map_row (fd=6, rast=0x64b520, row=0, data_type=0, null_is_zero=0, with_mask=1) at get_row.c:625 #12 0x0000002a95581189 in G_get_raster_row (fd=6, buf=0x64b520, row=0, data_type=0) at get_row.c:787 #13 0x00000000004177dc in cell_clip (buf=0x529d90, null_buf=0x58a560, row0=0, col0=0, nrows=197, ncols=243, index=0, radius=0, centernull=0x7fbfffed74, empty=0x7fbfffed70) at trace.c:591 #14 0x00000000004168b4 in cell_clip_drv (col0=0, row0=0, ncols=243, nrows=197, value=0x0, index=0, radius=0) at trace.c:156 #15 0x000000000040cbbd in whole_reg_driver () at driver.c:2737 #16 0x00000000004035ae in patch_fore () at driver.c:111 #17 0x000000000040f756 in main (argc=12, argv=0x7fbfffef68) at main.c:151 (gdb) Markus ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=459&group_id=21 From glynn at gclements.plus.com Tue Aug 14 01:56:00 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Aug 14 01:56:17 2007 Subject: [GRASS-dev] Fwd: Grass to Indian languages: Challenges In-Reply-To: <86782b610708131344k570dfac6wf4d82719e69b2958@mail.gmail.com> References: <86782b610708131344k570dfac6wf4d82719e69b2958@mail.gmail.com> Message-ID: <18112.61328.423623.112752@cerise.gclements.plus.com> Markus Neteler wrote: > Here a FWD (with permission) to discuss the problem of Indian > fonts support in GRASS. I wonder if the new fond infrastructure > helps in this regards. Not really. So far as the GUI is concerned, wxWidgets might do a better job of it than Tcl/Tk, or it might not. GRASS itself is stuck with whatever text rendering the GUI toolkit provides. As for R_text(): the FreeType renderer should handle right-to-left or vertical fonts (whether or not R_get_text_box() handles them is a different matter), but it won't handle complex layout rules. Each character is drawn at the current point, and the current point is advanced by the character's width vector. Anything else (i.e. combining characters) will require someone to provide the necessary code in a form suitable for integration. -- Glynn Clements From hamish_nospam at yahoo.com Tue Aug 14 03:02:41 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Aug 14 03:02:48 2007 Subject: [GRASS-dev] Launching GRASS 7 development In-Reply-To: <20070812194028.GA11020@bartok.itc.it> References: <20070811171324.GB24682@bartok.itc.it> <18110.10167.537908.798478@cerise.gclements.plus.com> <20070812194028.GA11020@bartok.itc.it> Message-ID: <20070814130241.1400197c.hamish_nospam@yahoo.com> Markus Neteler wrote: > > Still we have to figure out the flags of the cvs2svn conversion > script. one problem I have seen before in CVS->SVN is binaries (ie image.gif) get corrupted if not -kb flagged in CVS. IIRC Glynn bulk corrected this some months ago, so hopefully that part will be smooth. I agree with Helena about avoiding double-handling. It's better to do the migration once, correctly. Is there anything the community can do to help getting the freegis.org server ready for SVN? CVS access & uptime from intevation.de has been excellent IMO. Hamish From rez at touchofmadness.com Tue Aug 14 04:57:39 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Tue Aug 14 04:57:58 2007 Subject: [GRASS-dev] GRASS 7 Message-ID: <1187060259.2839.113.camel@dev64.localdomain> Hello, Has there been any thought into possibly deprecating BLAS/LAPACK for GRASS 7? I need to get an idea if I should continue to use BLAS/LAPACK functions in modules or if I should write implementations of needed functions. Few modules use those libraries. -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From stephan.holl at intevation.de Tue Aug 14 06:44:29 2007 From: stephan.holl at intevation.de (Stephan Holl) Date: Tue Aug 14 08:03:19 2007 Subject: [GRASS-dev] Launching GRASS 7 development In-Reply-To: <20070814130241.1400197c.hamish_nospam@yahoo.com> References: <20070811171324.GB24682@bartok.itc.it> <20070812194028.GA11020@bartok.itc.it> <20070814130241.1400197c.hamish_nospam@yahoo.com> Message-ID: <200708140644.29982.stephan.holl@intevation.de> Am Dienstag, 14. August 2007 03:02 schrieb Hamish: > Markus Neteler wrote: > > Still we have to figure out the flags of the cvs2svn conversion > > script. > > one problem I have seen before in CVS->SVN is binaries (ie image.gif) > get corrupted if not -kb flagged in CVS. IIRC Glynn bulk corrected this > some months ago, so hopefully that part will be smooth. > > > I agree with Helena about avoiding double-handling. It's better to do > the migration once, correctly. > > Is there anything the community can do to help getting the freegis.org > server ready for SVN? CVS access & uptime from intevation.de has been > excellent IMO. Thanks. Actually our infrastructiure has SVN ready to start over. See on wald[1], there is already a GRASS-project where the trackers are running. Is that what you expect?! Best regards Stephan [1] http://wald.intevation.org -- Stephan Holl , http://intevation.de/~stephan Tel: +49 (0)541-33 50 8 32 | Intevation GmbH | AG Osnabr?ck - HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From neteler at itc.it Tue Aug 14 08:50:04 2007 From: neteler at itc.it (Markus Neteler) Date: Tue Aug 14 08:50:07 2007 Subject: [GRASS-dev] Launching GRASS 7 development In-Reply-To: <200708140644.29982.stephan.holl@intevation.de> References: <20070811171324.GB24682@bartok.itc.it> <18110.10167.537908.798478@cerise.gclements.plus.com> <20070812194028.GA11020@bartok.itc.it> <20070814130241.1400197c.hamish_nospam@yahoo.com> <200708140644.29982.stephan.holl@intevation.de> Message-ID: <12139583.post@talk.nabble.com> Stephan Holl-3 wrote: > > Am Dienstag, 14. August 2007 03:02 schrieb Hamish: >> Markus Neteler wrote: >> > Still we have to figure out the flags of the cvs2svn conversion >> > script. >> >> one problem I have seen before in CVS->SVN is binaries (ie image.gif) >> get corrupted if not -kb flagged in CVS. IIRC Glynn bulk corrected this >> some months ago, so hopefully that part will be smooth. >> >> >> I agree with Helena about avoiding double-handling. It's better to do >> the migration once, correctly. >> >> Is there anything the community can do to help getting the freegis.org >> server ready for SVN? CVS access & uptime from intevation.de has been >> excellent IMO. > > Thanks. Actually our infrastructiure has SVN ready to start over. See on > wald[1], there is already a GRASS-project where the trackers are running. > > Is that what you expect?! > > Best regards > > Stephan > > [1] http://wald.intevation.org > I don't know from the indicated wald page. What we need is that the CVS2SVN migration is launched on the CVS server and stuff migrated to SVN including code history. It was communicated by Bernhard that there is no time for that in the near future. But we should no longer wait, otherwise some developers may go away. Since OSGeo is offering SVN infrastructure to the OSGeo projects, this could be an alternative then. Markus -- View this message in context: http://www.nabble.com/Launching-GRASS-7-development-tf4254095.html#a12139583 Sent from the Grass - Dev mailing list archive at Nabble.com. From michael.barton at asu.edu Tue Aug 14 08:54:16 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Aug 14 08:54:27 2007 Subject: [GRASS-dev] d.nviz problem or question Message-ID: I've pretty much finished a TclTk wrapper for d.nviz. Now I've encountered a problem running it. In order to do this, I need to use TclTk to grab coordinate points (x,y pairs) for the route that d.nviz will use. These should go into the route= option. d.nviz is then run non-interactively to generate the script for NVIZ. However, when I try to run d.nviz with coordinate points, rather than running it interactively, I get the following errors. Note that this was run with the Spearfish elevation.dem raster with the region set to the map. The coordinate points ARE within the map region. I tried this with a much smaller layback distance and had the same result. GRASS 6.3.cvs (spearfish60_test):~ > d.nviz input=elevation.dem@PERMANENT output=fly2 name=NVIZ route=594890.607477,4915842.85047,598114.766355,4920072.71028,601368.504673, 4922882.75701,604770.140187,4925397.00935 dist=2000 ht=1000 frames=100 start=0 WARNING: Skipping this point, selected point is outside region. Perhaps the camera setback distance puts it beyond the edge? WARNING: Skipping this point, selected point is outside region. Perhaps the camera setback distance puts it beyond the edge? WARNING: Skipping this point, selected point is outside region. Perhaps the camera setback distance puts it beyond the edge? WARNING: Skipping this point, selected point is outside region. Perhaps the camera setback distance puts it beyond the edge? WARNING: Skipping this point, selected point is outside region. Perhaps the camera setback distance puts it beyond the edge? WARNING: Skipping this point, selected point is outside region. Perhaps the camera setback distance puts it beyond the edge? d.nviz complete. Created NVIZ script . The script produced does nothing because there are no coordinate points. If I do this interactively in an xterm, it works fine with exactly the same parameters. Any suggestions? Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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/20070813/89be6bb9/attachment.html From glynn at gclements.plus.com Tue Aug 14 17:47:42 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Aug 14 17:48:02 2007 Subject: [GRASS-dev] d.nviz problem or question In-Reply-To: References: Message-ID: <18113.52894.992720.909992@cerise.gclements.plus.com> Michael Barton wrote: > I've pretty much finished a TclTk wrapper for d.nviz. Now I've encountered a > problem running it. In order to do this, I need to use TclTk to grab > coordinate points (x,y pairs) for the route that d.nviz will use. These > should go into the route= option. d.nviz is then run non-interactively to > generate the script for NVIZ. > > However, when I try to run d.nviz with coordinate points, rather than > running it interactively, I get the following errors. Note that this was run > with the Spearfish elevation.dem raster with the region set to the map. The > coordinate points ARE within the map region. I tried this with a much > smaller layback distance and had the same result. > > GRASS 6.3.cvs (spearfish60_test):~ > d.nviz input=elevation.dem@PERMANENT > output=fly2 name=NVIZ > route=594890.607477,4915842.85047,598114.766355,4920072.71028,601368.504673, > 4922882.75701,604770.140187,4925397.00935 dist=2000 ht=1000 frames=100 > start=0 > WARNING: Skipping this point, selected point is outside region. Perhaps the > camera setback distance puts it beyond the edge? > WARNING: Skipping this point, selected point is outside region. Perhaps the > camera setback distance puts it beyond the edge? > WARNING: Skipping this point, selected point is outside region. Perhaps the > camera setback distance puts it beyond the edge? > WARNING: Skipping this point, selected point is outside region. Perhaps the > camera setback distance puts it beyond the edge? > WARNING: Skipping this point, selected point is outside region. Perhaps the > camera setback distance puts it beyond the edge? > WARNING: Skipping this point, selected point is outside region. Perhaps the > camera setback distance puts it beyond the edge? > d.nviz complete. Created NVIZ script . > > The script produced does nothing because there are no coordinate points. If > I do this interactively in an xterm, it works fine with exactly the same > parameters. > > Any suggestions? read_rast() is using D_u_to_a_{row,col}(), but the transformation parameters only get initialised (using D_setup()) if -i is given. I suggest the following addition: --- display/d.nviz/main.c 21 Nov 2006 23:06:31 -0000 2.9 +++ display/d.nviz/main.c 14 Aug 2007 15:46:03 -0000 @@ -156,6 +156,8 @@ /* get GRASS parameters */ G_get_window(&window); projection = G_projection(); + D_do_conversions(&window, 0, 1, 0, 1); + /* setup screen coords */ screen_x = ((int) D_get_d_west() + (int) D_get_d_east()) / 2; screen_y = ((int) D_get_d_north() + (int) D_get_d_south()) / 2; The screen coordinates don't matter for the u<->a conversions. If -i is given, D_setup() will override this with the actual frame boundaries. -- Glynn Clements From paul-grass at stjohnspoint.co.uk Tue Aug 14 22:55:14 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Aug 14 22:55:16 2007 Subject: [GRASS-dev] Verbosity in parser usage message Message-ID: I committed a change to lib/gis/parser.c to the effect that, if there is an error in the user-specified parameters for a module, after that error is printed, the Usage message will now not be printed if the verbosity level is set to quiet. I hope this is OK - to me it seems to tie in with the documentation that only errors and warnings are printed when verbosity is set to quiet. It is of use in GUI dialogs when displaying the error message from a module to a user without having all the usage information getting in the way. Specifically for some improvements to error reporting when creating a new location using gis_set.tcl, which I will commit soon. I was wondering also why it has to be written like if(G_verbose() > G_verbose_min()) i.e. why is the minimum verbosity level not just a compile-time constant like G_MINIMIUM_VERBOSITY or something like that. Seems like a bit of extra overhead to have to call a function. But I suppose not very important. Paul From paul-grass at stjohnspoint.co.uk Tue Aug 14 23:47:37 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Aug 14 23:47:39 2007 Subject: [GRASS-dev] Create new location from EPSG code backport problem In-Reply-To: References: <20070425192617.418b75ad.hamish_nospam@yahoo.com> Message-ID: On Wed, 25 Apr 2007, Paul Kelly wrote: > Hello Hamish > I'm not sure if it's correct/optimum in the current CVS. I posted some plans > here: > http://www.nabble.com/forum/ViewPost.jtp?post=9125507&framed=y > that I think should be fixed before it goes into a stable release. > > In particular I'm not sure if the logic in the Tcl code for the order of the > various g.proj calls and the value of the datumtrans= option is correct yet. > IIRC the location should be created on the first attempt if there is no list > of datum transformation paramters, and the default when there is a choice > should be 0 (unspecified) rather than forcing the first set. But the Tcl code > doesn't do this. > > Will try and find time to have a look at it. I've now revisited this and implemented most things I described in the link above apart from the region setting/verification dialog. I added a prettier radio button-based dialog for the datum transformation parameter selection. I also have hopefully tested it fairly robustly for a range of EPSG codes that result in various different warnings and error output from g.proj, and these should all be reported correctly now. The datum transformation selection / improved g.proj interaction needs to be implemented for the georeferenced file option as well as the EPSG option - I could have easily done this by copying and pasting code but that seemed very quick and dirty - would much rather reduce code repetition and share the necessary functions but I've already had enough Tcl for a little while :) Am starting to pick it up though. There seem to be some solid and clear design ideas behind it but the operating system interaction bits have a few quirks and I suppose we're pushing it pretty hard in gis.m. Paul From michael.barton at asu.edu Wed Aug 15 00:14:58 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Aug 15 00:15:05 2007 Subject: [GRASS-dev] Create new location from EPSG code backport problem In-Reply-To: Message-ID: I'm very happy that you were able to make this update. If there is anything you'd like me to do to help, please let me know. Also, we should probably port the functionality to the location wizard in wxPython. Michael On 8/14/07 2:47 PM, "Paul Kelly" wrote: > On Wed, 25 Apr 2007, Paul Kelly wrote: > >> Hello Hamish >> I'm not sure if it's correct/optimum in the current CVS. I posted some plans >> here: >> http://www.nabble.com/forum/ViewPost.jtp?post=9125507&framed=y >> that I think should be fixed before it goes into a stable release. >> >> In particular I'm not sure if the logic in the Tcl code for the order of the >> various g.proj calls and the value of the datumtrans= option is correct yet. >> IIRC the location should be created on the first attempt if there is no list >> of datum transformation paramters, and the default when there is a choice >> should be 0 (unspecified) rather than forcing the first set. But the Tcl code >> doesn't do this. >> >> Will try and find time to have a look at it. > > I've now revisited this and implemented most things I described in the > link above apart from the region setting/verification dialog. > I added a prettier radio button-based dialog for the datum transformation > parameter selection. I also have hopefully tested it fairly robustly for a > range of EPSG codes that result in various different warnings and error > output from g.proj, and these should all be reported correctly now. > > The datum transformation selection / improved g.proj interaction needs to > be implemented for the georeferenced file option as well as the EPSG > option - I could have easily done this by copying and pasting code but > that seemed very quick and dirty - would much rather reduce code > repetition and share the necessary functions but I've already had enough > Tcl for a little while :) Am starting to pick it up though. There seem to > be some solid and clear design ideas behind it but the operating system > interaction bits have a few quirks and I suppose we're pushing it pretty > hard in gis.m. > > Paul > > __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 landa.martin at gmail.com Wed Aug 15 09:45:49 2007 From: landa.martin at gmail.com (Martin Landa) Date: Wed Aug 15 09:46:35 2007 Subject: [GRASS-dev] [grass-code I][455] r.proj segfaults after Jul 14 changes In-Reply-To: <1186594659.22591.278.camel@dev64.localdomain> References: <20070808170130.A7AAA4007F@pyrosoma.intevation.org> <1186594659.22591.278.camel@dev64.localdomain> Message-ID: Hi, it was my mistake, sorry for that. Martin 2007/8/8, Brad Douglas : > On Wed, 2007-08-08 at 19:01 +0200, grass-dev@grass.itc.it wrote: > > code I item #455, was opened at 2007-08-08 12:01 > > Status: Open > > Priority: 3 > > Submitted By: William Kyngesburye (kyngchaos) > > Assigned to: Nobody (None) > > Summary: r.proj segfaults after Jul 14 changes > > Issue type: module bug > > Issue status: None > > GRASS version: CVS HEAD > > GRASS component: raster > > Operating system: MacOS X > > Operating system version: 10.4 > > GRASS CVS checkout date, if applies (YYMMDD): > > Fixed in CVS. That was improper usage of G_done_msg() as noticed. > > > -- > 73, de Brad KB8UYR/6 > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From neteler at itc.it Wed Aug 15 10:47:29 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Aug 15 10:47:33 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <618B7E68-CB5C-4D05-B94C-F8F83B0FE8A1@unity.ncsu.edu> References: <20070811081434.GB28767@bartok.itc.it> <618B7E68-CB5C-4D05-B94C-F8F83B0FE8A1@unity.ncsu.edu> Message-ID: <12158519.post@talk.nabble.com> Helena Mitasova wrote: > > On Aug 11, 2007, at 4:14 AM, Markus Neteler wrote: > ... > If you ask me what was the most annoying (but not critica) thing that > I have found when using GRASS under a deadline - then it was the large > default size of the centroid symbol in d.vect. I had to go through > large number of vector data when preparing the new data set and each > time I forgot to set the size smaller I got the unreadable mess of > overlapping crosses. So if we could change the default to something > smaller - perhaps size 2 rather than 5, that would be great, because > most of the time you really want to see your polygons not the > centroids and they are quite visible at size 2 even with my old eyes > (maybe make the default red as the default fill is grey). This was > already discussed some time ago too. > > Helena > For now I have changes the default symbol size (annoying crosses) from 8 to 5 - already looks way better. Maybe it should be default grey to be less dominant (would require new parameter scolor= symbol color). Markus -- View this message in context: http://www.nabble.com/GRASS-6.3.0-release-preparation-tf4252794.html#a12158519 Sent from the Grass - Dev mailing list archive at Nabble.com. From hamish_nospam at yahoo.com Wed Aug 15 11:48:48 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Aug 15 11:48:57 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: References: <618B7E68-CB5C-4D05-B94C-F8F83B0FE8A1@unity.ncsu.edu> Message-ID: <20070815214848.7919f4fb.hamish_nospam@yahoo.com> > Helena Mitasova wrote: > > If you ask me what was the most annoying (but not critica) thing > > that I have found when using GRASS under a deadline - then it was > > the large default size of the centroid symbol in d.vect. .. > > So if we could change the default to something smaller - perhaps > > size 2 rather than 5, Michael Barton wrote: > It looks like the default is 8, which is really large for centroids. > would be fine for centroids. 5 is probably OK for points though. .. > My preference would be have the centroids turned off by default, > rather than on as is the current default. Markus wrote: > For now I have changes the default symbol size (annoying crosses) from > 8 to 5 - already looks way better. Maybe it should be default grey to > be less dominant (would require new parameter scolor= symbol color). I think we need to separate discussion of defaults for the GUI from defaults for command line d.vect. Last time I checked the GUI uses size=5 filled circles for centroids. As I've complained before, this can be misleading if the data is a coastline with many small offshore islands which are smaller than the centroid circle. It effectively generalizes the offshore islands into circles and is easy to miss. I do like the circle as the default point feature symbol, but prefer the "x" as the default centroid symbol. In the GUI I prefer the centroids not be drawn by default, but I prefer d.vect from the command line to draw centroids. No idea how to make that happen, outside of feature type tabs and multiple d.vect calls from the WxGUI. Helena: > > (maybe make the default red as the default fill is grey). This was > > already discussed some time ago too. Michael: > This is a problem since there is no way to set point colors separately > from general line/fill colors that also affect polygons and arcs. I > can see the benefit of it, but it would require yet another pair of > options for d.vect (and updating of the TclTk options panel in the > GUI). but there is! Some time ago I added D_symbol2(): * The same as D_symbol(), but it uses a primary and secondary color * instead of line and fill color. The primary color is used to draw * stroke lines (STRINGs) and as the fill color for polygons. The * secondary color is used for polygon outlines. d.vect uses it for -c random colors. try: d.vect -c bugsites size=5 d.vect -c bugsites size=10 icon=basic/triangle neat, huh? Also you may notice that d.vect -c does some other magic, e.g. for the spearfish "fields" map, the areas are filled with random color but the centroids (icon=any) and boundary colors are steady; vs bugsites where the symbol color changes. Hamish From michael.barton at asu.edu Thu Aug 16 05:50:11 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Aug 16 05:50:25 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <20070815214848.7919f4fb.hamish_nospam@yahoo.com> Message-ID: On 8/15/07 2:48 AM, "Hamish" wrote: > Michael Barton wrote: >> It looks like the default is 8, which is really large for centroids. >> would be fine for centroids. 5 is probably OK for points though. > .. >> My preference would be have the centroids turned off by default, >> rather than on as is the current default. > > Markus wrote: >> For now I have changes the default symbol size (annoying crosses) from >> 8 to 5 - already looks way better. Maybe it should be default grey to >> be less dominant (would require new parameter scolor= symbol color). > > I think we need to separate discussion of defaults for the GUI from > defaults for command line d.vect. I don't think this is the real problem here (see below). The real problem is that centroids are treated like points for display. > > Last time I checked the GUI uses size=5 filled circles for centroids. > As I've complained before, this can be misleading if the data is a > coastline with many small offshore islands which are smaller than the > centroid circle. It effectively generalizes the offshore islands into > circles and is easy to miss. I do like the circle as the default point > feature symbol, but prefer the "x" as the default centroid symbol. In > the GUI I prefer the centroids not be drawn by default, but I prefer > d.vect from the command line to draw centroids. No idea how to make > that happen, outside of feature type tabs and multiple d.vect calls from > the WxGUI. The type= option will turn centroids on and off. If type is not given, all vector types will be drawn. If it is given, only the specified types will be drawn. BUT... Because centroids are treated like any other points by d.vect, a map with areas will have the centroids colored just like the areas (fill and line), as if points and areas were mixed in the same map (in fact, they are as far as d.vect is concerned). IMHO, for display purposes, GRASS should normally draw points, lines, and areas (and maybe faces, though I'm still not sure how these work in 2D displays). That is, these should be the feature types to display with type=. The underlying architecture of areas (closed lines=boundaries with a point=centroid inside) should not be part of the normal feature display, any more than we normally display the points that make of the nodes in lines. For those occasions when someone wants to display the components of an area (i.e. a centroid or a boundary) apart from its role in creating an area, these should be listed in the display= option (i.e., along with shape, cat, topo, dir, attr, and zcoor). For that matter, I'd suggest we also add line nodes here too. In terms of how they function, centroids and boundaries (along with line nodes) are better grouped with vector topology than with feature types. Treated in this way, we might not want to have centroids (or line nodes) behave like points for display or have boundaries behave like lines. These could have special displays to indicate they are part of the underlying architecture. For example, centroids could be x's, while points could not be x's, but could be pluses; boundaries could always be drawn as dotted lines or something. There is still the issue of vectors containing mixed feature types, such that lines, point borders, and area borders are controlled by the same options for line width and line color, and point and area files are controlled by the same option. However, standard practices is commonly to separate feature types into separate layers, especially if there is need to color them differently. So this is probably not a major problem. Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 neteler at itc.it Thu Aug 16 18:12:00 2007 From: neteler at itc.it (Markus Neteler) Date: Thu Aug 16 18:12:02 2007 Subject: [GRASS-dev] r.series threshold patch Message-ID: <20070816161159.GA6926@bartok.itc.it> Glynn, to easier operate on incomplete time series from MODIS (and others), we would like to suggest attached patch. It adds a threshold to filter out incomplete pixel series before calling the aggregation function which saves us to perform extra runs on counting valid pixels and to post-filter the aggregated results. Markus -------------- next part -------------- Index: raster/r.series/description.html =================================================================== RCS file: /grassrepository/grass6/raster/r.series/description.html,v retrieving revision 1.12 diff -u -r1.12 description.html --- raster/r.series/description.html 16 Jul 2007 07:44:31 -0000 1.12 +++ raster/r.series/description.html 16 Aug 2007 16:08:03 -0000 @@ -28,12 +28,16 @@ With -n flag, any cell for which any of the corresponding input cells are NULL is automatically set to NULL (NULL propagation). The aggregate function is not called, so all methods behave this way with respect to the -n flag. +With -n flag, the parameter threshold is ignored.

-Without -n flag, the complete list of inputs for each cell (including -NULLs) is passed to the aggregate function. Individual aggregates can -handle data as they choose. Mostly, they just compute the aggregate -over the non-NULL values, producing a NULL result only if all inputs -are NULL. +Without -n flag, the parameter threshold is used to decide +when to call the aggregate function: if the list of inputs for each cell +contains at least threshold non NULLs, then the complete list of +values (including NULLs) is passed over to the aggregate function. +

+Individual aggregates can handle data as they choose. Mostly, they just compute +the aggregate over the non-NULL values, producing a NULL result only if all +inputs are NULL.

The min_raster and max_raster methods generate a map with the number of the raster map that holds the minimum/maximum value of the Index: raster/r.series/main.c =================================================================== RCS file: /grassrepository/grass6/raster/r.series/main.c,v retrieving revision 2.16 diff -u -r2.16 main.c --- raster/r.series/main.c 23 Jul 2007 15:47:13 -0000 2.16 +++ raster/r.series/main.c 16 Aug 2007 16:08:03 -0000 @@ -77,7 +77,7 @@ { struct GModule *module; struct { - struct Option *input, *output, *method; + struct Option *input, *output, *method, *thresh; } parm; struct { /* please, remove before GRASS 7 released */ @@ -95,7 +95,7 @@ DCELL *out_buf; DCELL *values; int nrows, ncols; - int row, col; + int row, col, thresh; G_gisinit(argv[0]); @@ -117,6 +117,13 @@ parm.method->options = build_method_list(); parm.method->description= _("Aggregate operation") ; + parm.thresh = G_define_option() ; + parm.thresh->key = "threshold" ; + parm.thresh->type = TYPE_INTEGER ; + parm.thresh->required = NO ; + parm.thresh->answer = "1" ; + parm.thresh->description= _("Minimum number of non-NULL observations to perform computation") ; + /* please, remove before GRASS 7 released */ flag.quiet = G_define_flag(); flag.quiet->key = 'q'; @@ -177,6 +184,7 @@ /* process the output map */ out_name = parm.output->answer; + thresh = atoi(parm.thresh->answer); out_fd = G_open_raster_new(out_name, DCELL_TYPE); if (out_fd < 0) @@ -209,12 +217,12 @@ DCELL v = inputs[i].buf[col]; if (G_is_d_null_value(&v)) - null = 1; + null++; values[i] = v; } - if (null && flag.nulls->answer) + if ((null && flag.nulls->answer)||((num_inputs-null) < thresh)) G_set_d_null_value(&out_buf[col], 1); else (*method_fn)(&out_buf[col], values, num_inputs); From glynn at gclements.plus.com Thu Aug 16 20:59:22 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Aug 16 20:59:26 2007 Subject: [GRASS-dev] r.series threshold patch In-Reply-To: <20070816161159.GA6926@bartok.itc.it> References: <20070816161159.GA6926@bartok.itc.it> Message-ID: <18116.40586.591784.539172@cerise.gclements.plus.com> Markus Neteler wrote: > to easier operate on incomplete time series from MODIS (and > others), we would like to suggest attached patch. It > adds a threshold to filter out incomplete pixel series > before calling the aggregation function which saves us > to perform extra runs on counting valid pixels and to > post-filter the aggregated results. While I don't doubt that this is a useful optimisation for your particular case, I'm generally opposed to adding such optimisations for specific cases. A more general optimisation would be to extend the method= and output= options to accept multiple values, so that you can compute multiple aggregates in a single run. You would still need to combine the two outputs with e.g. r.mapcalc, but you would only need one run of r.series. -- Glynn Clements From rez at touchofmadness.com Fri Aug 17 06:09:44 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Fri Aug 17 06:09:49 2007 Subject: [GRASS-dev] BLAS/LAPACK (Part II) Message-ID: <1187323784.20635.111.camel@dev64.localdomain> Hello, I did not hear any response to my question of whether to continue using BLAS/LAPACK. This uncertainty has been particularly hard on me, being unable to complete some work waiting for an answer one way or the other and not wanting to implement my own version if not needed. Currently, there is no code in the tree that makes use of either library other than my own. In fact, others have implemented their own versions. What I propose is moving the matrix code from v.generalize (in particular, matrix_inverse() ) to lib/gmath and simplifying the existing MATRIX structure. -- 73, de Brad KB8UYR/6 From michael.barton at asu.edu Fri Aug 17 06:16:11 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Aug 17 06:16:24 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <12158519.post@talk.nabble.com> Message-ID: On 8/15/07 1:47 AM, "Markus Neteler" wrote: >> > > For now I have changes the default symbol size (annoying crosses) from > 8 to 5 - already looks way better. Maybe it should be default grey to be > less > dominant (would require new parameter scolor= symbol color). > Symbols need both a line color and a fill color. This is another reason to consider treating centroids differently from points for display. Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hmitaso at unity.ncsu.edu Fri Aug 17 07:05:32 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Fri Aug 17 07:05:39 2007 Subject: [GRASS-dev] Re: v.generalize In-Reply-To: <9211715e0708041357g7446308eqa5dee5ea51851c59@mail.gmail.com> References: <1185306826.8290.11.camel@dev64.localdomain> <20070724203521.GD15606@bartok.itc.it> <46A8E263.1080304@bergenheim.net> <9211715e0708041357g7446308eqa5dee5ea51851c59@mail.gmail.com> Message-ID: Daniel, Wolf many thanks for a great new module. I wanted to write just a few comments but I ended up doing a small "research project". My main interest was to find out how we can use line generalization to preprocess contours or profiles to avoid some notorius interpolation problems - I will write about that in my next message, first some comments: 1. It would be great if you could use the new data set at least for some examples in the tutorial and manual, Markus has just released version 06 - it is available from here: http://www.grassbook.org/data_menu3rd.php It has detailed streams and streets data where the differences between different methods nicely show up. I haven't tried any areas, but urban areas, soils and planimetry would be good candidates for generalization. 2. The module indeed needs a tutorial but make sure that you put sufficiently detailed description, notes and examples in the man page. The past experiences show that the man pages are being kept relatively up-to-date but the tutorials updates tend to be neglected. 3. On technical note - when I tried stream generalization with -r flag many internal stream segments got removed (the streams essentially fell appart) I assume I did not use this option as intended, you may want to explain the right use in the manual. 4. In relation to your answer to Paul's comments below - built-in functions for the work with the single points would be huge help and could eliminate the current mixture of old and new get-arounds / left-overs from the old site format and troubles with topology building for larger point data sets. I found the current handling of points really confusing and not very efficient. I would like to encourage others to test the module too so that it can be included into CVS. I have tried only very little from the rich set of options that the modules offers so more testing will help, 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 Aug 4, 2007, at 4:57 PM, Daniel Bundala wrote: > Hello Paul, Wolf and List > > On 8/4/07, Paul Kelly wrote: >> On Thu, 26 Jul 2007, Wolf Bergenheim wrote: >> >>> v.generalize: >>> ~~~~~~~~~~~~~ >>> v.generalize is fully functional complete with manual and >>> smoothing and >>> simplification operations. The module works with both areas and >>> lines. >>> Attribute tables are also copied and cats are preserved. Please >>> give the >>> module a try and send us feedback! >>> The rest of SoC will be spent in implementing other generalization >>> operations and getting all the rest of the bugs out. >> >> Hello Wolf and Daniel >> Now I've had time to look at v.generalize too and am very >> impressed. The >> amount of easily-accessible functionality that this module adds to >> the >> GRASS vector capabilities really seems to be something >> significant. At >> first glance the amount of options seemed overwhelming but on reading >> through the man page and looking at the references there it became >> much >> more obvious. I think it could still be made clearer, but there is >> already >> a lot of information and explanation there and also in the source >> code, >> which is good. > > This is true. Actually, the man page does not contain any examples. I > will try to improve this... Moreover, I am planning to write a > tutorial/GSoC Final Report which will demonstrate the capabilities of > this module with a lot of examples and nice pictures... > >> >> The main thing I was wondering about is whether the threshold >> parameter is >> dual-purpose? If I understand correctly, is it used in some >> algorithms but >> then again also at the end to remove lines left that are shorter >> and areas >> that are smaller than the threshold? Is that dual purpose use >> likely to >> cause any problems? Or should these be different parameters? > > Yes, you understand it correctly. But this happens only if you > simplify the lines. Just few days ago, I added new flag (-r) to the > module which specifies whether the small/short linear features are > romeved. It is also mentioned somewhere in the newest version of the > man page. > >> I am curious too as to the spelling of alfa rather than alpha! > > Oops. I think that this caused me some problems with TeX as well.... I > will change it. > >> >> Compiling with -Wall I see quite a lot of missing function >> prototypes - as >> for the other Summer of Code module I feel putting in a >> local_proto.h for >> the functions that can be called from other source files, and marking >> the functions local to each file as static, would make things a bit >> clearer. Also perhaps Doxygen-style documentation for the >> functions? This >> one's not a big deal at all. I know it's a bit of work but the >> functions >> look well organised already, so presumably there is a lot of thought >> behind the way they are and it should be easy enough to put that into >> words. But in general the code comments are really good and >> helpful - only >> there where they are needed and left out where it is obvious by >> reading >> the code, what is going on. > Glad you like me style of comments... You know, *the* most boring part > of the project. And I will check that -Wall stuff. > >> >> Was thinking too about all the matrix stuff in the matrix.c file - >> sorry >> for this lazy question, as if I had more time to look through and >> was more >> familiar with these things I could answer it myself - but is it >> better >> than the G_matrix_* functions in lib/gmath, or just an alternative? > > It is probably just an alternative, but it was meant to better:) In > the beginnings, it seemed that I will be working with the special type > of sparse matrices only. But this is no more the case. > >> Would also be interesting to hear if Daniel has any suggestions for >> improvements and tidying of the vector API in GRASS. I enjoyed >> reading the >> code and it seems to utilise the existing API very well, which >> makes me >> think it's possible suggestions for enhancements and further >> development >> of the API could even come out of this work. > > Hmmm, maybe, I was really missing built-in functions for the work with > the single points/vectors. (Vector from > mathematical/geometrical/physical point of view) Something I have > implemented in point.* > >> But in summary, I had to search hard to find these few suggestions >> for >> improvement! It looks like a really excellent piece of work and it >> will be >> great to have it in GRASS. >> >> Paul > > Thanks Paul for your feedback! > > I dont know what commit/version did you use, but from the above, it > seems that it was not the very last commit. Well, there were no > changes in the code, but I documented displacement and "network > generalization" operations. Just to keep you informed about the newest > functionalities of v.generalize:) To tell the truth, "displacement" > has very impressive results! (Stay tuned for the tutorial, everything > will be there:) > > Daniel >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev >> > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From hamish_nospam at yahoo.com Fri Aug 17 07:12:54 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Aug 17 07:13:09 2007 Subject: [GRASS-dev] BLAS/LAPACK (Part II) In-Reply-To: <1187323784.20635.111.camel@dev64.localdomain> References: <1187323784.20635.111.camel@dev64.localdomain> Message-ID: <20070817171254.530a8937.hamish_nospam@yahoo.com> Brad Douglas wrote: > > I did not hear any response to my question of whether to continue > using BLAS/LAPACK. > > This uncertainty has been particularly hard on me, being unable to > complete some work waiting for an answer one way or the other and not > wanting to implement my own version if not needed. > > Currently, there is no code in the tree that makes use of either > library other than my own. In fact, others have implemented their own > versions. If having it there is not hurting anything, I'd say leave it as-is. It is less work to maintain the configure scripts than it is to stay current with the latest advancements in the library. ie 5 years from now we'd have an unmaintained stale copy distributed with our source. BLAS/LAPACK are in common use elsewhere, so it's not like a user would have to spend time hunting down and compiling obscure software to use it. Take pride in being the first to use it, we've been waiting a while for someone to. :) > What I propose is moving the matrix code from v.generalize (in > particular, matrix_inverse() ) to lib/gmath and simplifying the > existing MATRIX structure. regardless of BLAS/LAPACK staying or going, consolidation, consistency, and anything else that makes the code easier to maintain is obviously a good thing. (but no idea about that specific code) Hamish From hmitaso at unity.ncsu.edu Fri Aug 17 07:19:46 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Fri Aug 17 07:19:51 2007 Subject: [GRASS-dev] Re: v.generalize and interpolation, dmax problem In-Reply-To: <9211715e0708041357g7446308eqa5dee5ea51851c59@mail.gmail.com> References: <1185306826.8290.11.camel@dev64.localdomain> <20070724203521.GD15606@bartok.itc.it> <46A8E263.1080304@bergenheim.net> <9211715e0708041357g7446308eqa5dee5ea51851c59@mail.gmail.com> Message-ID: <7C803776-3E5A-4CC6-BE10-12332F63D5A8@unity.ncsu.edu> As I have mentioned I hoped that generalization will help to solve some problems when interpolating by v.surf.rst from oversampled contours (as is the case for example when they are scanned) and the results were well beyond my expectations (at least for the small data set I used). First some test: Even with very small threshold, large number of points is eliminated without noticeable change in the contour geometry http://skagit.meas.ncsu.edu/~helena/grasswork/elcont1m_gen00.png (from 40,000 to 3,000 points) result with threshold 5 is more radical http://skagit.meas.ncsu.edu/~helena/grasswork/elcont1m_gen05.png (from 40,000 to 500 points) each line is generalized independently so eventually contours will cross, so small threshold is what we want to use (animation from threshold of 0.5 to 12) http://skagit.meas.ncsu.edu/~helena/grasswork/gencontanim2.gif Interpolation from given data (40,000 pts) using default parameters (note that the points along contours are practically continuous, there are visible segments on the top of the hill and the computation runs 8 min) http://skagit.meas.ncsu.edu/~helena/grasswork/rstint_default_pts.png There are many small segments and the data are not very well distributed within the segments http://skagit.meas.ncsu.edu/~helena/grasswork/rstint_default_seg.png we can improve the results by tuning dmin, npmin, tension and smoothing as we have done for years, but there is a better solution now, by running v.generalize first , with small threshold we have fewer than 3000 points : http://skagit.meas.ncsu.edu/~helena/grasswork/rstint_gen_pts.png Segments are larger and fewer - computation runs under 1 min http://skagit.meas.ncsu.edu/~helena/grasswork/rstint_gen_seg.png and the most important - the results are much better default interpolation with original data (there are visible segments and waves along contours) http://skagit.meas.ncsu.edu/~helena/grasswork/elev_rstcontdef3d.jpg default interpolation with generalized data (no segments and no waves) http://skagit.meas.ncsu.edu/~helena/grasswork/elev_rstcontgen013d.jpg BUT I had to set dmax to a large number (1000) - the default value added 100,000 (!) points right back on the contours. which brings me to the main question - are there any objections to make dmax default value as large as the region to make sure that it does not add any points (currently it is set to 1.25 resolution value which is obviously not enough)? I have been trying to eliminate this parameter for years as it usually causes more problems than it solves. Helena On Aug 4, 2007, at 4:57 PM, Daniel Bundala wrote: > Hello Paul, Wolf and List > > On 8/4/07, Paul Kelly wrote: >> On Thu, 26 Jul 2007, Wolf Bergenheim wrote: >> >>> v.generalize: >>> ~~~~~~~~~~~~~ >>> v.generalize is fully functional complete with manual and >>> smoothing and >>> simplification operations. The module works with both areas and >>> lines. >>> Attribute tables are also copied and cats are preserved. Please >>> give the >>> module a try and send us feedback! >>> The rest of SoC will be spent in implementing other generalization >>> operations and getting all the rest of the bugs out. >> >> Hello Wolf and Daniel >> Now I've had time to look at v.generalize too and am very >> impressed. The >> amount of easily-accessible functionality that this module adds to >> the >> GRASS vector capabilities really seems to be something >> significant. At >> first glance the amount of options seemed overwhelming but on reading >> through the man page and looking at the references there it became >> much >> more obvious. I think it could still be made clearer, but there is >> already >> a lot of information and explanation there and also in the source >> code, >> which is good. > > This is true. Actually, the man page does not contain any examples. I > will try to improve this... Moreover, I am planning to write a > tutorial/GSoC Final Report which will demonstrate the capabilities of > this module with a lot of examples and nice pictures... > >> >> The main thing I was wondering about is whether the threshold >> parameter is >> dual-purpose? If I understand correctly, is it used in some >> algorithms but >> then again also at the end to remove lines left that are shorter >> and areas >> that are smaller than the threshold? Is that dual purpose use >> likely to >> cause any problems? Or should these be different parameters? > > Yes, you understand it correctly. But this happens only if you > simplify the lines. Just few days ago, I added new flag (-r) to the > module which specifies whether the small/short linear features are > romeved. It is also mentioned somewhere in the newest version of the > man page. > >> I am curious too as to the spelling of alfa rather than alpha! > > Oops. I think that this caused me some problems with TeX as well.... I > will change it. > >> >> Compiling with -Wall I see quite a lot of missing function >> prototypes - as >> for the other Summer of Code module I feel putting in a >> local_proto.h for >> the functions that can be called from other source files, and marking >> the functions local to each file as static, would make things a bit >> clearer. Also perhaps Doxygen-style documentation for the >> functions? This >> one's not a big deal at all. I know it's a bit of work but the >> functions >> look well organised already, so presumably there is a lot of thought >> behind the way they are and it should be easy enough to put that into >> words. But in general the code comments are really good and >> helpful - only >> there where they are needed and left out where it is obvious by >> reading >> the code, what is going on. > Glad you like me style of comments... You know, *the* most boring part > of the project. And I will check that -Wall stuff. > >> >> Was thinking too about all the matrix stuff in the matrix.c file - >> sorry >> for this lazy question, as if I had more time to look through and >> was more >> familiar with these things I could answer it myself - but is it >> better >> than the G_matrix_* functions in lib/gmath, or just an alternative? > > It is probably just an alternative, but it was meant to better:) In > the beginnings, it seemed that I will be working with the special type > of sparse matrices only. But this is no more the case. > >> Would also be interesting to hear if Daniel has any suggestions for >> improvements and tidying of the vector API in GRASS. I enjoyed >> reading the >> code and it seems to utilise the existing API very well, which >> makes me >> think it's possible suggestions for enhancements and further >> development >> of the API could even come out of this work. > > Hmmm, maybe, I was really missing built-in functions for the work with > the single points/vectors. (Vector from > mathematical/geometrical/physical point of view) Something I have > implemented in point.* > >> But in summary, I had to search hard to find these few suggestions >> for >> improvement! It looks like a really excellent piece of work and it >> will be >> great to have it in GRASS. >> >> Paul > > Thanks Paul for your feedback! > > I dont know what commit/version did you use, but from the above, it > seems that it was not the very last commit. Well, there were no > changes in the code, but I documented displacement and "network > generalization" operations. Just to keep you informed about the newest > functionalities of v.generalize:) To tell the truth, "displacement" > has very impressive results! (Stay tuned for the tutorial, everything > will be there:) > > Daniel >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev >> > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From rez at touchofmadness.com Fri Aug 17 07:54:38 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Fri Aug 17 07:54:42 2007 Subject: [GRASS-dev] BLAS/LAPACK (Part II) In-Reply-To: <20070817171254.530a8937.hamish_nospam@yahoo.com> References: <1187323784.20635.111.camel@dev64.localdomain> <20070817171254.530a8937.hamish_nospam@yahoo.com> Message-ID: <1187330078.20635.134.camel@dev64.localdomain> On Fri, 2007-08-17 at 17:12 +1200, Hamish wrote: > Brad Douglas wrote: > > > > I did not hear any response to my question of whether to continue > > using BLAS/LAPACK. > > > > This uncertainty has been particularly hard on me, being unable to > > complete some work waiting for an answer one way or the other and not > > wanting to implement my own version if not needed. > > > > Currently, there is no code in the tree that makes use of either > > library other than my own. In fact, others have implemented their own > > versions. > > If having it there is not hurting anything, I'd say leave it as-is. > > It is less work to maintain the configure scripts than it is to stay > current with the latest advancements in the library. ie 5 years from > now we'd have an unmaintained stale copy distributed with our source. ? There's nothing to go stale. Or are you making my case for me? > BLAS/LAPACK are in common use elsewhere, so it's not like a user would > have to spend time hunting down and compiling obscure software to use > it. > > Take pride in being the first to use it, we've been waiting a while for > someone to. :) And then having modules become useless when the libraries aren't compiled in? > > What I propose is moving the matrix code from v.generalize (in > > particular, matrix_inverse() ) to lib/gmath and simplifying the > > existing MATRIX structure. > > regardless of BLAS/LAPACK staying or going, consolidation, consistency, > and anything else that makes the code easier to maintain is obviously a > good thing. (but no idea about that specific code) There are only a few functions in lib/gmath that make use of BLAS/LAPACK: G_matrix_product () G_matrix_LU_solve () G_vector_norm_euclid () G_matrix_inverse () -- calls G_matrix_LU_solve () v.generalize solves: G_matrix_product () G_matrix_inverse () G_matrix_LU_solve () So what's the point of having BLAS/LAPACK? -- 73, de Brad KB8UYR/6 From paul-grass at stjohnspoint.co.uk Fri Aug 17 11:21:59 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Fri Aug 17 11:22:41 2007 Subject: [GRASS-dev] Re: v.generalize and interpolation, dmax problem In-Reply-To: <7C803776-3E5A-4CC6-BE10-12332F63D5A8@unity.ncsu.edu> References: <1185306826.8290.11.camel@dev64.localdomain> <20070724203521.GD15606@bartok.itc.it> <46A8E263.1080304@bergenheim.net> <9211715e0708041357g7446308eqa5dee5ea51851c59@mail.gmail.com> <7C803776-3E5A-4CC6-BE10-12332F63D5A8@unity.ncsu.edu> Message-ID: On Fri, 17 Aug 2007, Helena Mitasova wrote: [Interesting/impressive test results...] > which brings me to the main question - are there any objections to make dmax > default value > as large as the region to make sure that it does not add any points > (currently it is set to 1.25 resolution value which is obviously not enough)? > I have been trying to eliminate this parameter for years > as it usually causes more problems than it solves. For 7.x perhaps you could drop both the dmin and dmax parameters, and add a note to the man page suggesting that the user preprocess their contour data with v.generalize to resolve issues with closely-spaced points, before running v.surf.rst? Just a thought Paul From dylan.beaudette at gmail.com Fri Aug 17 18:19:20 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Fri Aug 17 18:19:21 2007 Subject: [GRASS-dev] Re: v.generalize and interpolation, dmax problem In-Reply-To: References: <1185306826.8290.11.camel@dev64.localdomain> <7C803776-3E5A-4CC6-BE10-12332F63D5A8@unity.ncsu.edu> Message-ID: <200708170919.20387.dylan.beaudette@gmail.com> On Friday 17 August 2007 02:21, Paul Kelly wrote: > On Fri, 17 Aug 2007, Helena Mitasova wrote: > > [Interesting/impressive test results...] > > > which brings me to the main question - are there any objections to make > > dmax default value > > as large as the region to make sure that it does not add any points > > (currently it is set to 1.25 resolution value which is obviously not > > enough)? I have been trying to eliminate this parameter for years > > as it usually causes more problems than it solves. > > For 7.x perhaps you could drop both the dmin and dmax parameters, and add > a note to the man page suggesting that the user preprocess their contour > data with v.generalize to resolve issues with closely-spaced points, > before running v.surf.rst? > > Just a thought > > Paul Helena: Very interesting results- maybe consider writing this up in the OSGEO journal ? I agree with Paul, as I have struggled and fussed with those two options for v.surf.rst for years. Cheers, Dylan > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 From neteler at itc.it Fri Aug 17 18:34:02 2007 From: neteler at itc.it (Markus Neteler) Date: Fri Aug 17 18:34:04 2007 Subject: [GRASS-dev] r.series threshold patch In-Reply-To: <18116.40586.591784.539172@cerise.gclements.plus.com> References: <20070816161159.GA6926@bartok.itc.it> <18116.40586.591784.539172@cerise.gclements.plus.com> Message-ID: <46C5CDFA.8010707@itc.it> Glynn Clements wrote on 08/16/2007 08:59 PM: > Markus Neteler wrote: > > >> to easier operate on incomplete time series from MODIS (and >> others), we would like to suggest attached patch. It >> adds a threshold to filter out incomplete pixel series >> before calling the aggregation function which saves us >> to perform extra runs on counting valid pixels and to >> post-filter the aggregated results. >> > > While I don't doubt that this is a useful optimisation for your > particular case, I'm generally opposed to adding such optimisations > for specific cases. > > A more general optimisation would be to extend the method= and output= > options to accept multiple values, so that you can compute multiple > aggregates in a single run. You would still need to combine the two > outputs with e.g. r.mapcalc, but you would only need one run of > r.series. > The optimization you propose is of course far more general than what we did, and could be extremely valuable. Nonetheless, we think that introducing the threshold parameter is not really a special case hack: all it really does is a straightforward generalization of the current -n flag, transforming it from a ON/OFF switch to an integer value. The threshold parameter indicates the minimum number of non NULL inputs required for passing over the inputs to the aggregation function. It varies in the range [1,num_inputs]; thresh=num_inputs is equivalent to -n (return NULL unless the inputs are all non NULL), while thresh=1 is the standard behaviour (compute the aggregation if there is at least 1 non NULL input). Markus and Antonio ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From bundala at gmail.com Fri Aug 17 19:33:21 2007 From: bundala at gmail.com (Daniel Bundala) Date: Fri Aug 17 19:33:26 2007 Subject: [GRASS-dev] Re: v.generalize and interpolation, dmax problem In-Reply-To: <7C803776-3E5A-4CC6-BE10-12332F63D5A8@unity.ncsu.edu> References: <1185306826.8290.11.camel@dev64.localdomain> <20070724203521.GD15606@bartok.itc.it> <46A8E263.1080304@bergenheim.net> <9211715e0708041357g7446308eqa5dee5ea51851c59@mail.gmail.com> <7C803776-3E5A-4CC6-BE10-12332F63D5A8@unity.ncsu.edu> Message-ID: <9211715e0708171033v4530638bvf60754a24343bc13@mail.gmail.com> Helena, Your results seem very interesting and very encouraging. I did not expect such a wide aplications... -r flag removes lines which are shorter (after simplifiaction) than threshold. In your situations, it is very likely that the individual streams consist of many short segments/lines. Daniel On 8/17/07, Helena Mitasova wrote: > As I have mentioned I hoped that generalization will help > to solve some problems when interpolating by v.surf.rst from > oversampled contours > (as is the case for example when they are scanned) > and the results were well beyond my expectations > (at least for the small data set I used). > > First some test: > Even with very small threshold, large number of points is eliminated > without noticeable change in the contour geometry > http://skagit.meas.ncsu.edu/~helena/grasswork/elcont1m_gen00.png > (from 40,000 to 3,000 points) > result with threshold 5 is more radical > http://skagit.meas.ncsu.edu/~helena/grasswork/elcont1m_gen05.png > (from 40,000 to 500 points) > each line is generalized independently so eventually contours will > cross, so small threshold > is what we want to use (animation from threshold of 0.5 to 12) > http://skagit.meas.ncsu.edu/~helena/grasswork/gencontanim2.gif > > Interpolation from given data (40,000 pts) using default parameters > (note that the points along contours are practically continuous, > there are visible segments > on the top of the hill and the computation runs 8 min) > http://skagit.meas.ncsu.edu/~helena/grasswork/rstint_default_pts.png > There are many small segments and the data are not very well > distributed within the segments > http://skagit.meas.ncsu.edu/~helena/grasswork/rstint_default_seg.png > > we can improve the results by tuning dmin, npmin, tension and > smoothing as we have done for years, > but there is a better solution now, by running v.generalize first , > with small threshold we have fewer than 3000 points : > http://skagit.meas.ncsu.edu/~helena/grasswork/rstint_gen_pts.png > Segments are larger and fewer - computation runs under 1 min > http://skagit.meas.ncsu.edu/~helena/grasswork/rstint_gen_seg.png > > and the most important - the results are much better > default interpolation with original data (there are visible segments > and waves along contours) > http://skagit.meas.ncsu.edu/~helena/grasswork/elev_rstcontdef3d.jpg > > default interpolation with generalized data (no segments and no waves) > http://skagit.meas.ncsu.edu/~helena/grasswork/elev_rstcontgen013d.jpg > BUT I had to set dmax to a large number (1000) - the default value > added 100,000 (!) points right back on the contours. > > which brings me to the main question - are there any objections to > make dmax default value > as large as the region to make sure that it does not add any points > (currently it is set to 1.25 resolution value which is obviously not > enough)? > I have been trying to eliminate this parameter for years > as it usually causes more problems than it solves. > > Helena > > > On Aug 4, 2007, at 4:57 PM, Daniel Bundala wrote: > > > Hello Paul, Wolf and List > > > > On 8/4/07, Paul Kelly wrote: > >> On Thu, 26 Jul 2007, Wolf Bergenheim wrote: > >> > >>> v.generalize: > >>> ~~~~~~~~~~~~~ > >>> v.generalize is fully functional complete with manual and > >>> smoothing and > >>> simplification operations. The module works with both areas and > >>> lines. > >>> Attribute tables are also copied and cats are preserved. Please > >>> give the > >>> module a try and send us feedback! > >>> The rest of SoC will be spent in implementing other generalization > >>> operations and getting all the rest of the bugs out. > >> > >> Hello Wolf and Daniel > >> Now I've had time to look at v.generalize too and am very > >> impressed. The > >> amount of easily-accessible functionality that this module adds to > >> the > >> GRASS vector capabilities really seems to be something > >> significant. At > >> first glance the amount of options seemed overwhelming but on reading > >> through the man page and looking at the references there it became > >> much > >> more obvious. I think it could still be made clearer, but there is > >> already > >> a lot of information and explanation there and also in the source > >> code, > >> which is good. > > > > This is true. Actually, the man page does not contain any examples. I > > will try to improve this... Moreover, I am planning to write a > > tutorial/GSoC Final Report which will demonstrate the capabilities of > > this module with a lot of examples and nice pictures... > > > >> > >> The main thing I was wondering about is whether the threshold > >> parameter is > >> dual-purpose? If I understand correctly, is it used in some > >> algorithms but > >> then again also at the end to remove lines left that are shorter > >> and areas > >> that are smaller than the threshold? Is that dual purpose use > >> likely to > >> cause any problems? Or should these be different parameters? > > > > Yes, you understand it correctly. But this happens only if you > > simplify the lines. Just few days ago, I added new flag (-r) to the > > module which specifies whether the small/short linear features are > > romeved. It is also mentioned somewhere in the newest version of the > > man page. > > > >> I am curious too as to the spelling of alfa rather than alpha! > > > > Oops. I think that this caused me some problems with TeX as well.... I > > will change it. > > > >> > >> Compiling with -Wall I see quite a lot of missing function > >> prototypes - as > >> for the other Summer of Code module I feel putting in a > >> local_proto.h for > >> the functions that can be called from other source files, and marking > >> the functions local to each file as static, would make things a bit > >> clearer. Also perhaps Doxygen-style documentation for the > >> functions? This > >> one's not a big deal at all. I know it's a bit of work but the > >> functions > >> look well organised already, so presumably there is a lot of thought > >> behind the way they are and it should be easy enough to put that into > >> words. But in general the code comments are really good and > >> helpful - only > >> there where they are needed and left out where it is obvious by > >> reading > >> the code, what is going on. > > Glad you like me style of comments... You know, *the* most boring part > > of the project. And I will check that -Wall stuff. > > > >> > >> Was thinking too about all the matrix stuff in the matrix.c file - > >> sorry > >> for this lazy question, as if I had more time to look through and > >> was more > >> familiar with these things I could answer it myself - but is it > >> better > >> than the G_matrix_* functions in lib/gmath, or just an alternative? > > > > It is probably just an alternative, but it was meant to better:) In > > the beginnings, it seemed that I will be working with the special type > > of sparse matrices only. But this is no more the case. > > > >> Would also be interesting to hear if Daniel has any suggestions for > >> improvements and tidying of the vector API in GRASS. I enjoyed > >> reading the > >> code and it seems to utilise the existing API very well, which > >> makes me > >> think it's possible suggestions for enhancements and further > >> development > >> of the API could even come out of this work. > > > > Hmmm, maybe, I was really missing built-in functions for the work with > > the single points/vectors. (Vector from > > mathematical/geometrical/physical point of view) Something I have > > implemented in point.* > > > >> But in summary, I had to search hard to find these few suggestions > >> for > >> improvement! It looks like a really excellent piece of work and it > >> will be > >> great to have it in GRASS. > >> > >> Paul > > > > Thanks Paul for your feedback! > > > > I dont know what commit/version did you use, but from the above, it > > seems that it was not the very last commit. Well, there were no > > changes in the code, but I documented displacement and "network > > generalization" operations. Just to keep you informed about the newest > > functionalities of v.generalize:) To tell the truth, "displacement" > > has very impressive results! (Stay tuned for the tutorial, everything > > will be there:) > > > > Daniel > >> _______________________________________________ > >> grass-dev mailing list > >> grass-dev@grass.itc.it > >> http://grass.itc.it/mailman/listinfo/grass-dev > >> > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev > > From bundala at gmail.com Fri Aug 17 19:40:07 2007 From: bundala at gmail.com (Daniel Bundala) Date: Fri Aug 17 19:40:10 2007 Subject: [GRASS-dev] v.generalize tutorial Message-ID: <9211715e0708171040k2574728eq3f5f74fe9d2e26ad@mail.gmail.com> Dear Mr. List, I have just finished the promised tutorial for my GSoC module v.generalize. Temporarily, you can find it here: http://users.ox.ac.uk/~orie1848/tutorial.html It is the first public version. Unfortunately, the links are missing and also I need to complete the references. But, I hope, it presents the capabilities of this module and shows what is possible to achieve with v.generalize. Also, I did not have time to proofread it and it is very likely that it has many typos and (technical, grammatical...) mistakes If you have any comments, please write Daniel From dylan.beaudette at gmail.com Fri Aug 17 20:09:11 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Fri Aug 17 20:09:15 2007 Subject: [GRASS-dev] v.generalize tutorial In-Reply-To: <9211715e0708171040k2574728eq3f5f74fe9d2e26ad@mail.gmail.com> References: <9211715e0708171040k2574728eq3f5f74fe9d2e26ad@mail.gmail.com> Message-ID: <200708171109.11403.dylan.beaudette@gmail.com> On Friday 17 August 2007 10:40, Daniel Bundala wrote: > Dear Mr. List, > > I have just finished the promised tutorial for my GSoC module > v.generalize. Temporarily, you can find it here: > http://users.ox.ac.uk/~orie1848/tutorial.html > > It is the first public version. Unfortunately, the links are missing > and also I need to complete the references. But, I hope, it presents > the capabilities of this module and shows what is possible to achieve > with v.generalize. Also, I did not have time to proofread it and it is > very likely that it has many typos and (technical, grammatical...) > mistakes > > If you have any comments, please write > > Daniel > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev Daniel, This is truly fantastic work! Great job on the v.generalize module- this is something that many GRASS users have been wanting for a long time. Cheers, Dylan -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 From glynn at gclements.plus.com Fri Aug 17 23:51:53 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Aug 17 23:51:57 2007 Subject: [GRASS-dev] r.series threshold patch In-Reply-To: <46C5CDFA.8010707@itc.it> References: <20070816161159.GA6926@bartok.itc.it> <18116.40586.591784.539172@cerise.gclements.plus.com> <46C5CDFA.8010707@itc.it> Message-ID: <18118.6265.857512.653581@cerise.gclements.plus.com> Markus Neteler wrote: > >> to easier operate on incomplete time series from MODIS (and > >> others), we would like to suggest attached patch. It > >> adds a threshold to filter out incomplete pixel series > >> before calling the aggregation function which saves us > >> to perform extra runs on counting valid pixels and to > >> post-filter the aggregated results. > > > > While I don't doubt that this is a useful optimisation for your > > particular case, I'm generally opposed to adding such optimisations > > for specific cases. > > > > A more general optimisation would be to extend the method= and output= > > options to accept multiple values, so that you can compute multiple > > aggregates in a single run. You would still need to combine the two > > outputs with e.g. r.mapcalc, but you would only need one run of > > r.series. > > > The optimization you propose is of course far more general than what > we did, and could be extremely valuable. > > Nonetheless, we think that introducing the threshold parameter is not > really a special case hack: all it really does is a straightforward > generalization of the current -n flag, transforming it from a ON/OFF > switch to an integer value. > > The threshold parameter indicates the minimum number of non NULL > inputs required for passing over the inputs to the aggregation > function. > > It varies in the range [1,num_inputs]; thresh=num_inputs is equivalent > to -n (return NULL unless the inputs are all non NULL), while thresh=1 > is the standard behaviour (compute the aggregation if there is at > least 1 non NULL input). Actually, thresh=0 would give the existing behaviour. If -n isn't used, the values are always passed to the aggregate function. If all of the values are null, most aggregates will return null, but the "count" aggregate will return 0. -- Glynn Clements From cavallini at faunalia.it Sat Aug 18 19:03:56 2007 From: cavallini at faunalia.it (Paolo Cavallini) Date: Sat Aug 18 19:04:21 2007 Subject: [GRASS-dev] v.generalize tutorial In-Reply-To: <9211715e0708171040k2574728eq3f5f74fe9d2e26ad@mail.gmail.com> References: <9211715e0708171040k2574728eq3f5f74fe9d2e26ad@mail.gmail.com> Message-ID: <46C7267C.4060004@faunalia.it> Great thing, thanks a lot for your work. Just a couple of things: - orignal>original - the figures should be on a separate

Looking forward to have it on the main GRASS code, so everybody will be able to test and use it! All the best. pc Daniel Bundala ha scritto: > Dear Mr. List, > > I have just finished the promised tutorial for my GSoC module > v.generalize. Temporarily, you can find it here: > http://users.ox.ac.uk/~orie1848/tutorial.html > > It is the first public version. Unfortunately, the links are missing > and also I need to complete the references. But, I hope, it presents > the capabilities of this module and shows what is possible to achieve > with v.generalize. Also, I did not have time to proofread it and it is > very likely that it has many typos and (technical, grammatical...) > mistakes > > If you have any comments, please write -- Paolo Cavallini, see: http://www.faunalia.it/pc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070818/17b7d82a/signature-0001.bin From michael.barton at asu.edu Sun Aug 19 00:00:23 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Aug 19 00:00:33 2007 Subject: [GRASS-dev] wxgrass won't work - how to set up digitization? Message-ID: Martin, I just updated all and now wxgrass won't start. I get the following error... GRASS 6.3.cvs (spearfish60_test):~ > Traceback (most recent call last): File "/Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/wxgui.py", line 57, in import gui_modules.wxgui_utils as wxgui_utils File "/Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/gui_modules/wxg ui_utils.py", line 36, in import mapdisp File "/Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/gui_modules/map disp.py", line 55, in import toolbars File "/Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/gui_modules/too lbars.py", line 28, in from digit import Digit as Digit File "/Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/gui_modules/dig it.py", line 60, in from grass6_wxdriver import DisplayDriver ImportError: No module named grass6_wxdriver I assume that I need the new displaydriver C module you have written. I copied it into my running version and tried to make it, but got the following error... Last login: Sat Aug 18 11:48:21 on ttyp1 Welcome to Darwin! cmb-MBP:~ cmbarton$ cd /Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/display_driver/ cmb-MBP:/Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/display_ driver cmbarton$ make Makefile:17: warning: overriding commands for target `clean' ../../../include/Make/Rules.make:34: warning: ignoring old commands for target `clean' cat ./driver.i > grass6_wxdriver.i echo "/* auto-generate swig typedef file (with some GRASS functions removed) */" >> grass6_wxdriver.i cat ./driver.h >> grass6_wxdriver.i swig -c++ -python -shadow grass6_wxdriver.i make: swig: Command not found make: *** [grass6_wxdriver_wrap.cxx] Error 127 What do I need to do to make this work? BTW, my GRASS is compiled with PYTHON support, so swig *ought* to be there. I probably am just doing this wrong. Thanks Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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/20070818/dd6c5d4d/attachment.html From michael.barton at asu.edu Sun Aug 19 17:17:43 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Aug 19 17:17:52 2007 Subject: [GRASS-dev] Re: [GRASSGUI] cannot change the raster map in layer (wxpython) In-Reply-To: <46C80BD2.7060707@amu.edu.pl> Message-ID: Thanks for the details Jarek On 8/19/07 2:22 AM, "Jarek Jasiewicz" wrote: > I have wxgrass installed from 18.08.2007, morning, on ubuntu feisty > I add the layer, ad the raster map to layer and make refresh on map display. > Next step I call the properties window (both method) on layer choose > another map from combo menu, I press aplly and nothing change i.e map > remains the same > > I can change the map name manually, e.g I can type the name of the map > in the combo and that way it work. I hope I write it out in propertyly. This is important to know. I've sometimes had the reverse experience. If I pick from the combo box, it works. But if I type in manually it doesn't > > I assume that there is three ways: > -for unknow resason it do not works only on my machine > -it do not on ubuntu feisty on the whole > -there is small bug I'm guessing a bug. But maybe it's one that can have a workaround. I saw last night that there is a new wxPython release, with new installation for Debian. Maybe that will help. > > I rather expected that somebody confirm or not that problem. Most people working on this are still gone for the summer, and the semester is just starting for me, with a LOT of work at my REAL job ;-) I do not know the cause of your problem. Also, I can't personally test it because I work on a Mac and not a Debian system. HOWEVER... Hearing your description, suggests that some kind of change to the selection control bindings might help. When I get a chance, I'll try to follow this up. Also, other people working on wxgrass will start to be back over the next few weeks and might have some ideas. Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 michael.barton at asu.edu Sun Aug 19 18:47:26 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Aug 19 18:47:34 2007 Subject: [GRASS-dev] trying to compile wxPython digitizer display_driver Message-ID: Martin, I compiled swig, but still am not able to compile your new display driver for the wxPython GUI. I've had to drop back to the earlier (non-functional) version of digit.py just to get it all to run. I'm pretty sure that, after installing swig, the problem lies in the Makefile, which seems to be hard-coded to match your system. I've tried playing around with some of the parameters, but have been unsuccessful. I just don't know much about the details of compiling C code. The Makefile is short, so I'm including it below along with some of my comments. Maybe someone can offer suggestions as to 1) how to make it work with my Mac and 2) how to generalize it so it works more easily with other systems as well. With regard to swig, this adds a major new dependency to the wxPython GUI. It doesn't come on the Mac and I had to compile it from source. IT was pretty easy, but not something other most other Mac users will want to do. Same with Windows users. Maybe we'll want to have Python-swig as a requirement anyway. Several people have mentioned this. I know generally what it swig does, but not the details. An important question is...Is swig necessary for creating the driver for digitizing in wxPython or is there potentially another way to do this? That is, can we accomplish what you are trying to do without swig, oris it essential to make it work? I'm looking forward to trying the new digitizer after getting this driver up and working. Cheers Michal __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 Makefile below ========================== PYTHONVERSION=2.4 >>>> NOTE: this should be 2.4 or above rather than hard coded to 2.4 (I have 2.5, for example). I know that there is some way to specify this, but don't remember what it is. MODULE_TOPDIR = ../../.. include $(MODULE_TOPDIR)/include/Make/Lib.make include $(MODULE_TOPDIR)/include/Make/Doxygen.make >>>> NOTE: This seems to imply putting the source directory for display_driver somewhere in the GRASS source tree, but I can't figure out where it is supposed to go. I've tried putting it at the root, in lib, and another place or two. My GRASS source tree happens to be in /Users/cmbarton/grass_dev/grass6. SWIG=swig CFLAGS=-c -fpic -I/usr/include/python$(PYTHONVERSION) -I./ -I$(ARCH_DISTDIR)/include `wx-config --cxxflags` >>>> NOTE: My Python includes are in a completely different place. I'm not sure what ARCH_DISTDIR refers to but am guessing that this needs to be set to match each system. LDFLAGS=-shared -L$(ARCH_LIBDIR) -lgrass_vect -lgrass_gis `wx-config --libs` >>>> NOTE: This may need to be changed for Mac OS X if I am correctly remembering some discussions crossing the dev list. default: grass6_wxdriver.so clean: -rm -f *.o *.so grass6_wxdriver_wrap.cxx grass6_wxdriver.py grass6_wxdriver.i grass6_wxdriver.pyc grass6_wxdriver.i: cat ./driver.i > grass6_wxdriver.i echo "/* auto-generate swig typedef file (with some GRASS functions removed) */" >> grass6_wxdriver.i cat ./driver.h >> grass6_wxdriver.i grass6_wxdriver_wrap.cxx: grass6_wxdriver.i $(SWIG) -c++ -python -shadow $< grass6_wxdriver_wrap.o: grass6_wxdriver_wrap.cxx $(CXX) $(CFLAGS) $(INCLUDE_DIRS) $< driver.o: driver.cc $(CXX) $(CFLAGS) $(INCLUDE_DIRS) $< pseudodc.o: pseudodc.cpp $(CXX) $(CFLAGS) $(INCLUDE_DIRS) $< grass6_wxdriver.so: grass6_wxdriver_wrap.o driver.o pseudodc.o $(CXX) $(LDFLAGS) grass6_wxdriver_wrap.o driver.o pseudodc.o -o _grass6_wxdriver.so -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070819/818b262f/attachment.html From gnelson at uiuc.edu Sun Aug 19 19:07:33 2007 From: gnelson at uiuc.edu (Gerald Nelson) Date: Sun Aug 19 19:07:36 2007 Subject: [GRASS-dev] r.terraflow.html missing Message-ID: <20070819120733.AUT13624@expms1.cites.uiuc.edu> I was reading up on r.watershed in the grass-6.3.cvs wingrass version that was released in early August. The See Also section has a link to r.terrflow.html but it doesn't work. I searched in the grass directory and all subdirectories without success. Jerry Gerald Nelson Professor, Dept. of Agricultural and Consumer Economics University of Illinois, Urbana-Champaign office: 217-333-6465 cell: 217-390-7888 315 Mumford Hall 1301 W. Gregory Urbana, IL 61801 From woklist at kyngchaos.com Sun Aug 19 19:29:27 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Sun Aug 19 19:29:40 2007 Subject: [GRASS-dev] Re: [GRASSGUI] trying to compile wxPython digitizer display_driver In-Reply-To: References: Message-ID: On Aug 19, 2007, at 11:47 AM, Michael Barton wrote: > With regard to swig, this adds a major new dependency to the > wxPython GUI. It doesn't come on the Mac and I had to compile it > from source. IT was pretty easy, but not something other most other > Mac users will want to do. Same with Windows users. Maybe we'll > want to have Python-swig as a requirement anyway. Several people > have mentioned this. I know generally what it swig does, but not > the details. An important question is...Is swig necessary for > creating the driver for digitizing in wxPython or is there > potentially another way to do this? That is, can we accomplish what > you are trying to do without swig, oris it essential to make it work? > I think there are a couple levels to the SWIG setup. (ie see MapServer and GDAL) One is the developers - they need swig installed so they can generate the SWIG stuff in the GRASS source. The other is users - anyone who downloads the GRASS source should not need SWIG on their computer to compile GRASS, the SWIG bits are already generated by the developers. Dunno about how appropriate SWIG is, though... > Makefile below ========================== > [I'm responding to the OSX bit below, but felt I could answer some other questions also] > MODULE_TOPDIR = ../../.. > > include $(MODULE_TOPDIR)/include/Make/Lib.make > include $(MODULE_TOPDIR)/include/Make/Doxygen.make > > >>>> NOTE: This seems to imply putting the source directory for > display_driver somewhere in the GRASS source tree, but I can't > figure out where it is supposed to go. I've tried putting it at the > root, in lib, and another place or two. My GRASS source tree > happens to be in /Users/cmbarton/grass_dev/grass6. > MODULE_TOPDIR is the GRASS source top. Whereever you put the display driver source, the MODULE_TOPDIR = should backtrack to get to the source top. Someone else could probably answer off the top of their head, but a little poking around reveals: display/drivers in the GRASS source. > CFLAGS=-c -fpic -I/usr/include/python$(PYTHONVERSION) -I./ -I$ > (ARCH_DISTDIR)/include `wx-config --cxxflags` > > >>>> NOTE: My Python includes are in a completely different place. > I'm not sure what ARCH_DISTDIR refers to but am guessing that this > needs to be set to match each system. > ARCH_DISTDIR is where binaries are built into, dist-[platform] off the grass top dir. The includes above (Lib.make, ...) should set all the necessary make variables for you. > LDFLAGS=-shared -L$(ARCH_LIBDIR) -lgrass_vect -lgrass_gis `wx- > config --libs` > > >>>> NOTE: This may need to be changed for Mac OS X if I am > correctly remembering some discussions crossing the dev list. > -dynamiclib for OSX. But whatever it is for a platform, this is already in the GRASS makefile parts that are included, so -shared/- dynamiclib should be left out here. But it looks like display drivers are built as programs anyways, not libraries. Try using the PNG driver makefile as an example. ----- William Kyngesburye http://www.kyngchaos.com/ "Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence.... - the wisdom of Tarzan From woklist at kyngchaos.com Sun Aug 19 20:23:54 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Sun Aug 19 20:24:21 2007 Subject: [GRASS-dev] Re: [GRASSGUI] trying to compile wxPython digitizer display_driver In-Reply-To: References: Message-ID: <850FA6ED-4113-47E1-BD13-BE825106B552@kyngchaos.com> Ah, I missed a few points. - this driver is loaded by python, not GRASS, so the library form is probably correct. Though maybe not a library, but a "module" - OSX has a distinction between libraries loaded by the system dyld, and bundle modules loaded by programs (usually used for plugins). I think Python does this. There should be a way to automatically do this, but I think it involves using setup.py. (MapServer does this for Python Mapscript) - It's also C++, so the GRASS make system can't deal with it directly (like r.terraflow). So it *does* need the manual compile and link stuff in the makefile. But still can use GRASS make variables for most of it. - GRASS libraries should be specified with the makefile variables, ie $(VECTLIB). - the ARCH_DISTDIR include is in the makefile includes, so it doesn't need to be here. I started fiddling with it, then noticed this stuff. The SWIG stuff should probably be separated into optional make targets, for the developer side. Then the default make target will assume that these SWIG bits are made. On Aug 19, 2007, at 12:29 PM, William Kyngesburye wrote: >> Makefile below ========================== >> > [I'm responding to the OSX bit below, but felt I could answer some > other questions also] > >> MODULE_TOPDIR = ../../.. >> >> include $(MODULE_TOPDIR)/include/Make/Lib.make >> include $(MODULE_TOPDIR)/include/Make/Doxygen.make >> >> >>>> NOTE: This seems to imply putting the source directory for >> display_driver somewhere in the GRASS source tree, but I can't >> figure out where it is supposed to go. I've tried putting it at >> the root, in lib, and another place or two. My GRASS source tree >> happens to be in /Users/cmbarton/grass_dev/grass6. >> > MODULE_TOPDIR is the GRASS source top. Whereever you put the > display driver source, the MODULE_TOPDIR = should backtrack to get > to the source top. > > Someone else could probably answer off the top of their head, but a > little poking around reveals: display/drivers in the GRASS source. > >> CFLAGS=-c -fpic -I/usr/include/python$(PYTHONVERSION) -I./ -I$ >> (ARCH_DISTDIR)/include `wx-config --cxxflags` >> >> >>>> NOTE: My Python includes are in a completely different place. >> I'm not sure what ARCH_DISTDIR refers to but am guessing that this >> needs to be set to match each system. >> > ARCH_DISTDIR is where binaries are built into, dist-[platform] off > the grass top dir. The includes above (Lib.make, ...) should set > all the necessary make variables for you. > >> LDFLAGS=-shared -L$(ARCH_LIBDIR) -lgrass_vect -lgrass_gis `wx- >> config --libs` >> >> >>>> NOTE: This may need to be changed for Mac OS X if I am >> correctly remembering some discussions crossing the dev list. >> > -dynamiclib for OSX. But whatever it is for a platform, this is > already in the GRASS makefile parts that are included, so -shared/- > dynamiclib should be left out here. But it looks like display > drivers are built as programs anyways, not libraries. Try using > the PNG driver makefile as an example. ----- 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 tutey at o2.pl Sun Aug 19 20:36:15 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sun Aug 19 20:37:23 2007 Subject: [GRASS-dev] r.terraflow.html missing In-Reply-To: <20070819120733.AUT13624@expms1.cites.uiuc.edu> References: <20070819120733.AUT13624@expms1.cites.uiuc.edu> Message-ID: <46C88D9F.5040207@o2.pl> Gerald Nelson wrote: > I was reading up on r.watershed in the grass-6.3.cvs wingrass > version that was released in early August. The See Also section has > a link to r.terrflow.html but it doesn't work. I searched in the > grass directory and all subdirectories without success. This propably means that winGRASS package was not build with C++ support, required by r.terraflow which is a (only one?) GRASS module written in C++. The man page will be created only if the relevant module is built. If you only want to read about r.terraflow, there is an online manual for all GRASS modules on [1]. If you need r.terraflow for your work, you'd need to build GRASS --with-cxx. [1]http://grass.itc.it/grass63/manuals/html63_user/index.html Maciek From paul-grass at stjohnspoint.co.uk Sun Aug 19 23:20:35 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sun Aug 19 23:21:03 2007 Subject: [GRASS-dev] r.terraflow.html missing In-Reply-To: <46C88D9F.5040207@o2.pl> References: <20070819120733.AUT13624@expms1.cites.uiuc.edu> <46C88D9F.5040207@o2.pl> Message-ID: On Sun, 19 Aug 2007, Maciej Sieczka wrote: > Gerald Nelson wrote: >> I was reading up on r.watershed in the grass-6.3.cvs wingrass >> version that was released in early August. The See Also section has >> a link to r.terrflow.html but it doesn't work. I searched in the >> grass directory and all subdirectories without success. > > This propably means that winGRASS package was not build with C++ > support, required by r.terraflow which is a (only one?) GRASS module Good guess, but the answer is actually that r.terraflow does not build on MinGW. Output from make attached in case anybody would like to try and fix it (not me!). Paul > written in C++. The man page will be created only if the relevant > module is built. > > If you only want to read about r.terraflow, there is an online manual > for all GRASS modules on [1]. If you need r.terraflow for your work, > you'd need to build GRASS --with-cxx. > > [1]http://grass.itc.it/grass63/manuals/html63_user/index.html > > Maciek > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > > -------------- next part -------------- Makefile:78: warning: overriding commands for target `clean' ../../include/Make/Rules.make:34: warning: ignoring old commands for target `clean' mkdir -p OBJ.i686-pc-mingw32/FLOAT ; true mkdir -p OBJ.i686-pc-mingw32/SHORT ; true c++ -c -I/c/grass/grass6/dist.i686-pc-mingw32/include -I/c/grass/extra/include -g -O2 -I/c/grass/extra/include -I./IOStream/include -DUSER=\"\" -DNODATA_FIX -D_FILE_OFFSET_BITS=64 -DPACKAGE=\""grassmods"\" -DELEV_FLOAT main.cc -o OBJ.i686-pc-mingw32/FLOAT/main.o In file included from ./IOStream/include/ami.h:49, from common.h:49, from main.cc:60: ./IOStream/include/ami_stream.h: In member function `unsigned int AMI_STREAM::get_block_length()': ./IOStream/include/ami_stream.h:191: error: there are no arguments to `getpagesize' that depend on a template parameter, so a declaration of `getpagesize' must be available ./IOStream/include/ami_stream.h:191: error: (if you use `-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated) In file included from ./IOStream/include/ami_sort_impl.h:48, from ./IOStream/include/ami_sort.h:45, from ./IOStream/include/ami.h:55, from common.h:49, from main.cc:60: ./IOStream/include/quicksort.h: In function `void partition(T*, size_t, size_t&, CMPR&)': ./IOStream/include/quicksort.h:66: error: there are no arguments to `random' that depend on a template parameter, so a declaration of `random' must be available In file included from ./IOStream/include/ami_sort.h:45, from ./IOStream/include/ami.h:55, from common.h:49, from main.cc:60: ./IOStream/include/ami_sort_impl.h: In function `AMI_STREAM* singleMerge(queue*, Compare*)': ./IOStream/include/ami_sort_impl.h:300: error: there are no arguments to `getpagesize' that depend on a template parameter, so a declaration of `getpagesize' must be available In file included from ./IOStream/include/ami.h:66, from common.h:49, from main.cc:60: ./IOStream/include/rtimer.h:48:26: sys/resource.h: No such file or directory In file included from ./IOStream/include/ami.h:66, from common.h:49, from main.cc:60: ./IOStream/include/rtimer.h: At global scope: ./IOStream/include/rtimer.h:54: error: field `rut1' has incomplete type ./IOStream/include/rtimer.h:54: error: field `rut2' has incomplete type In file included from main.cc:64: grass2str.h: In function `AMI_STREAM* cell2stream(char*, elevation_type, long int*)': grass2str.h:65: error: `RUSAGE_SELF' undeclared (first use this function) grass2str.h:65: error: (Each undeclared identifier is reported only once for each function it appears in.) grass2str.h:65: error: 'struct Rtimer' has no member named 'rut1' grass2str.h:65: error: there are no arguments to `getrusage' that depend on a template parameter, so a declaration of `getrusage' must be available grass2str.h:167: error: 'struct Rtimer' has no member named 'rut2' grass2str.h:167: error: there are no arguments to `getrusage' that depend on a template parameter, so a declaration of `getrusage' must be available grass2str.h: In function `void stream2_CELL(AMI_STREAM*, dimension_type, dimension_type, char*, bool)': grass2str.h:186: error: `RUSAGE_SELF' undeclared (first use this function) grass2str.h:186: error: 'struct Rtimer' has no member named 'rut1' grass2str.h:186: error: there are no arguments to `getrusage' that depend on a template parameter, so a declaration of `getrusage' must be available grass2str.h:246: error: 'struct Rtimer' has no member named 'rut2' grass2str.h:246: error: there are no arguments to `getrusage' that depend on a template parameter, so a declaration of `getrusage' must be available grass2str.h: In function `void stream2_CELL(AMI_STREAM*, dimension_type, dimension_type, FUN, char*)': grass2str.h:273: error: `RUSAGE_SELF' undeclared (first use this function) grass2str.h:273: error: 'struct Rtimer' has no member named 'rut1' grass2str.h:273: error: there are no arguments to `getrusage' that depend on a template parameter, so a declaration of `getrusage' must be available grass2str.h:325: error: 'struct Rtimer' has no member named 'rut2' grass2str.h:325: error: there are no arguments to `getrusage' that depend on a template parameter, so a declaration of `getrusage' must be available grass2str.h: In function `void stream2_FCELL(AMI_STREAM*, dimension_type, dimension_type, FUN, char*)': grass2str.h:347: error: `RUSAGE_SELF' undeclared (first use this function) grass2str.h:347: error: 'struct Rtimer' has no member named 'rut1' grass2str.h:347: error: there are no arguments to `getrusage' that depend on a template parameter, so a declaration of `getrusage' must be available grass2str.h:399: error: 'struct Rtimer' has no member named 'rut2' grass2str.h:399: error: there are no arguments to `getrusage' that depend on a template parameter, so a declaration of `getrusage' must be available grass2str.h: In function `void stream2_FCELL(AMI_STREAM*, dimension_type, dimension_type, FUN1, FUN2, char*, char*)': grass2str.h:436: error: `RUSAGE_SELF' undeclared (first use this function) grass2str.h:436: error: 'struct Rtimer' has no member named 'rut1' grass2str.h:436: error: there are no arguments to `getrusage' that depend on a template parameter, so a declaration of `getrusage' must be available grass2str.h:514: error: 'struct Rtimer' has no member named 'rut2' grass2str.h:514: error: there are no arguments to `getrusage' that depend on a template parameter, so a declaration of `getrusage' must be available In file included from main.cc:66: sortutils.h: In function `void sort(AMI_STREAM**, FUN)': sortutils.h:63: error: `RUSAGE_SELF' undeclared (first use this function) sortutils.h:63: error: 'struct Rtimer' has no member named 'rut1' sortutils.h:63: error: there are no arguments to `getrusage' that depend on a template parameter, so a declaration of `getrusage' must be available sortutils.h:68: error: 'struct Rtimer' has no member named 'rut2' sortutils.h:68: error: there are no arguments to `getrusage' that depend on a template parameter, so a declaration of `getrusage' must be available sortutils.h: In function `AMI_STREAM* sort(AMI_STREAM*, FUN)': sortutils.h:92: error: `RUSAGE_SELF' undeclared (first use this function) sortutils.h:92: error: 'struct Rtimer' has no member named 'rut1' sortutils.h:92: error: there are no arguments to `getrusage' that depend on a template parameter, so a declaration of `getrusage' must be available sortutils.h:97: error: 'struct Rtimer' has no member named 'rut2' sortutils.h:97: error: there are no arguments to `getrusage' that depend on a template parameter, so a declaration of `getrusage' must be available main.cc: In function `void record_args(int, char**)': main.cc:349: error: `ctime_r' undeclared (first use this function) main.cc: In function `int main(int, char**)': main.cc:582: error: `RUSAGE_SELF' undeclared (first use this function) main.cc:582: error: 'struct Rtimer' has no member named 'rut1' main.cc:582: error: `getrusage' undeclared (first use this function) main.cc:646: error: 'struct Rtimer' has no member named 'rut2' grass2str.h: In function `AMI_STREAM* cell2stream(char*, elevation_type, long int*) [with T = elevation_type]': main.cc:589: instantiated from here grass2str.h:65: error: `getrusage' undeclared (first use this function) grass2str.h: In function `void stream2_CELL(AMI_STREAM*, dimension_type, dimension_type, char*, bool) [with T = direction_type]': main.cc:606: instantiated from here grass2str.h:186: error: `getrusage' undeclared (first use this function) grass2str.h: In function `void stream2_CELL(AMI_STREAM*, dimension_type, dimension_type, char*, bool) [with T = elevation_type]': main.cc:611: instantiated from here grass2str.h:186: error: `getrusage' undeclared (first use this function) grass2str.h: In function `void stream2_CELL(AMI_STREAM*, dimension_type, dimension_type, FUN, char*) [with T = labelElevType, FUN = labelElevTypePrintLabel]': main.cc:616: instantiated from here grass2str.h:273: error: `getrusage' undeclared (first use this function) grass2str.h: In function `void stream2_FCELL(AMI_STREAM*, dimension_type, dimension_type, FUN1, FUN2, char*, char*) [with T = sweepOutput, FUN1 = printAccumulation, FUN2 = printTci]': main.cc:637: instantiated from here grass2str.h:436: error: `getrusage' undeclared (first use this function) make: *** [OBJ.i686-pc-mingw32/FLOAT/main.o] Error 1 From woklist at kyngchaos.com Mon Aug 20 02:57:05 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Aug 20 02:57:21 2007 Subject: [GRASS-dev] Re: [GRASSGUI] trying to compile wxPython digitizer display_driver In-Reply-To: References: Message-ID: Hey guys, I worked out a setup.py script to build the display driver. This makes it easier to configure the installation of python and wxpython. I pulled bits from the MapServer and GDAL Python setup.py scripts. - no python version needed from configure for the makefile - doesn't hardwire the compile/link flags or grass libs - source compilation and linking is handled externally by python, only the swig step must be handled by the GRASS makefile A couple things to work out: - the OSX wx-config script is buried in a non-standard location (lib/ wxPython-unicode-[version]/bin). For now, add that to your path before building the driver. Eventually, it needs to be configured with something like a --with-wxpython= option. - installation - distutils builds in a subfolder, "build", with platform subfolders from that. The distutils install option knows where to find this, but that installs in the python site-packages folder. If we want to keep the driver within the GRASS installation, the makefile needs to figure out the platform folder to find it. Or there may be an option to setup.py to do this - I've only fiddled with distutils and don't know all its capabilities. - it's currently setup for grass_src/somefolder/gui/display_driver - that is, 3 levels deep. (this is for the MODULE_TOPDIR in the makefile and a couple items in setup.py) This should work with grass_src/swig/python/display_driver, as you seem to have it Martin. Or something like grass_src/gui/wx/display_driver. Here are the files: -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 650 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070819/9472eed6/Makefile.obj -------------- next part -------------- (note: don't need makefile.in) -------------- next part -------------- A non-text attachment was scrubbed... Name: setup.py Type: text/x-python-script Size: 3236 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070819/9472eed6/setup.bin -------------- next part -------------- ----- William Kyngesburye http://www.kyngchaos.com/ "Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life." - Marvin From hmitaso at unity.ncsu.edu Mon Aug 20 03:22:26 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Mon Aug 20 03:22:33 2007 Subject: [GRASS-dev] Re: v.generalize and interpolation, dmax problem In-Reply-To: References: <1185306826.8290.11.camel@dev64.localdomain> <20070724203521.GD15606@bartok.itc.it> <46A8E263.1080304@bergenheim.net> <9211715e0708041357g7446308eqa5dee5ea51851c59@mail.gmail.com> <7C803776-3E5A-4CC6-BE10-12332F63D5A8@unity.ncsu.edu> Message-ID: <65AD6170-10AA-44E2-925B-6CB2F6B17643@unity.ncsu.edu> On Aug 17, 2007, at 5:21 AM, Paul Kelly wrote: > On Fri, 17 Aug 2007, Helena Mitasova wrote: > > [Interesting/impressive test results...] > >> which brings me to the main question - are there any objections to >> make dmax default value >> as large as the region to make sure that it does not add any points >> (currently it is set to 1.25 resolution value which is obviously >> not enough)? >> I have been trying to eliminate this parameter for years >> as it usually causes more problems than it solves. > > For 7.x perhaps you could drop both the dmin and dmax parameters, > and add a note to the man page suggesting that the user preprocess > their contour data with v.generalize to resolve issues with closely- > spaced points, before running v.surf.rst? I will eliminate dmax in GRASS7 (if I still remember it) but dmin needs to stay. v.generalize applies only to lines or area boundaries so the preprocessing can be used only for contours - dmax applies only to contours (it does the same thing as v.to.point - vi ) - it does nothing if your input are scattered points. We still need dmin for preprocessing of scattered points and for elimination of points that may be too close to each other due to density of contours on steep slopes. Profiles that you may get from real time kinematic survey or single beam sonar have similar problem as contours with points being much denser along the profile compared to the distance between profiles, but they would require generalization in vertical plane rather than the horizontal plane. v.generalize should also help with v.surf.idw and kriging in case somebody wants to use those methods to grid from contours or isolines. Helena > > Just a thought > > Paul From michael.barton at asu.edu Mon Aug 20 05:11:32 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Aug 20 05:11:40 2007 Subject: [GRASS-dev] Re: [GRASSGUI] trying to compile wxPython digitizer display_driver In-Reply-To: Message-ID: William, Thanks for working on this. I just tried it. I seem to be missing something. I put the display_driver folder into ../grass6/gui/wxpython as you suggested. I copied your new Makefile and setup.py into the display_driver folder I then ran python setup.py I received the following error cmb-MBP:~/grass_dev/grass6/gui/wxpython/display_driver cmbarton$ python setup.pyusage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: setup.py --help [cmd1 cmd2 ...] or: setup.py --help-commands or: setup.py cmd --help I tried --help-commands, which gave me some options. So I tried build, build_py, and install as arguments to setup.py. The results are below. Any suggestions? Michael ======= attempts to run setup.py ============== cmb-MBP:~/grass_dev/grass6/gui/wxpython/display_driver cmbarton$ python setup.py build running build running build_py file grass6_wxdriver.py (for module grass6_wxdriver) not found file grass6_wxdriver.py (for module grass6_wxdriver) not found running build_ext building 'grass6_wxdriver' extension creating build creating build/temp.macosx-10.3-fat-2.5 gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -D__WXDEBUG__= -D__WXMAC__= -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES= -DNO_GCC_PRAGMA= -I/usr/lib/wx/include/mac-unicode-debug-2.5 -I/usr/include/wx-2.5 -I/Library/Frameworks/GDAL.framework/unix/include -I/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.10.1/include -I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -c grass6_wxdriver_wrap.cxx -o build/temp.macosx-10.3-fat-2.5/grass6_wxdriver_wrap.o powerpc-apple-darwin8-gcc-4.0.1: grass6_wxdriver_wrap.cxx: No such file or directory powerpc-apple-darwin8-gcc-4.0.1: no input files i686-apple-darwin8-gcc-4.0.1: grass6_wxdriver_wrap.cxx: No such file or directory i686-apple-darwin8-gcc-4.0.1: no input files lipo: can't figure out the architecture type of: /var/tmp//ccFKl9UF.out error: command 'gcc' failed with exit status 1 cmb-MBP:~/grass_dev/grass6/gui/wxpython/display_driver cmbarton$ python setup.py build_py running build_py file grass6_wxdriver.py (for module grass6_wxdriver) not found file grass6_wxdriver.py (for module grass6_wxdriver) not found cmb-MBP:~/grass_dev/grass6/gui/wxpython/display_driver cmbarton$ cmb-MBP:~/grass_dev/grass6/gui/wxpython/display_driver cmbarton$ python setup.py install running install running build running build_py file grass6_wxdriver.py (for module grass6_wxdriver) not found file grass6_wxdriver.py (for module grass6_wxdriver) not found running build_ext building 'grass6_wxdriver' extension gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -D__WXDEBUG__= -D__WXMAC__= -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES= -DNO_GCC_PRAGMA= -I/usr/lib/wx/include/mac-unicode-debug-2.5 -I/usr/include/wx-2.5 -I/Library/Frameworks/GDAL.framework/unix/include -I/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.10.1/include -I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -c grass6_wxdriver_wrap.cxx -o build/temp.macosx-10.3-fat-2.5/grass6_wxdriver_wrap.o i686-apple-darwin8-gcc-4.0.1: grass6_wxdriver_wrap.cxx: No such file or directory powerpc-apple-darwin8-gcc-4.0.1: i686-apple-darwin8-gcc-4.0.1: no input files grass6_wxdriver_wrap.cxx: No such file or directory powerpc-apple-darwin8-gcc-4.0.1: no input files lipo: can't figure out the architecture type of: /var/tmp//ccML6MOz.out error: command 'gcc' failed with exit status 1 cmb-MBP:~/grass_dev/grass6/gui/wxpython/display_driver cmbarton$ __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 woklist at kyngchaos.com Mon Aug 20 05:32:43 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Aug 20 05:32:55 2007 Subject: [GRASS-dev] Re: [GRASSGUI] trying to compile wxPython digitizer display_driver In-Reply-To: References: Message-ID: <22E9E84D-85C7-4A78-96E8-FEE15DDD0E4E@kyngchaos.com> It was meant to be run from the makefile. So just "make" and it should work. The makefile does the swig stuff. Then runs "python setup.py build". Also, before running make, set the shell PATH to include wxpython - for the 2.8.4 version I just installed today that would be: export PATH="/usr/local/lib/wxPython-unicode-2.8.4.2/bin:$PATH" On Aug 19, 2007, at 10:11 PM, Michael Barton wrote: > William, > > Thanks for working on this. I just tried it. I seem to be missing > something. > > I put the display_driver folder into ../grass6/gui/wxpython as you > suggested. > > I copied your new Makefile and setup.py into the display_driver folder > > I then ran > > python setup.py > > I received the following error > > cmb-MBP:~/grass_dev/grass6/gui/wxpython/display_driver cmbarton$ > python > setup.pyusage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 > [cmd2_opts] > ...] > or: setup.py --help [cmd1 cmd2 ...] > or: setup.py --help-commands > or: setup.py cmd --help ----- William Kyngesburye http://www.kyngchaos.com/ "Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence.... - the wisdom of Tarzan From michael.barton at asu.edu Mon Aug 20 06:36:38 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Aug 20 06:36:51 2007 Subject: [GRASS-dev] Re: [GRASSGUI] trying to compile wxPython digitizer display_driver In-Reply-To: <22E9E84D-85C7-4A78-96E8-FEE15DDD0E4E@kyngchaos.com> Message-ID: On 8/19/07 8:32 PM, "William Kyngesburye" wrote: > It was meant to be run from the makefile. So just "make" and it > should work. The makefile does the swig stuff. Then runs "python > setup.py build". Also, before running make, set the shell PATH to > include wxpython - for the 2.8.4 version I just installed today that > would be: > > export PATH="/usr/local/lib/wxPython-unicode-2.8.4.2/bin:$PATH" > I tried this but got the error... cmb-MBP:~/grass_dev/grass6/gui/wxpython/display_driver cmbarton$ make make: *** No targets. Stop. cmb-MBP:~/grass_dev/grass6/gui/wxpython/display_driver cmbarton$ Michael > On Aug 19, 2007, at 10:11 PM, Michael Barton wrote: > >> William, >> >> Thanks for working on this. I just tried it. I seem to be missing >> something. >> >> I put the display_driver folder into ../grass6/gui/wxpython as you >> suggested. >> >> I copied your new Makefile and setup.py into the display_driver folder >> >> I then ran >> >> python setup.py >> >> I received the following error >> >> cmb-MBP:~/grass_dev/grass6/gui/wxpython/display_driver cmbarton$ >> python >> setup.pyusage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 >> [cmd2_opts] >> ...] >> or: setup.py --help [cmd1 cmd2 ...] >> or: setup.py --help-commands >> or: setup.py cmd --help > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > "Mon Dieu! but they are all alike. Cheating, murdering, lying, > fighting, and all for things that the beasts of the jungle would not > deign to possess - money to purchase the effeminate pleasures of > weaklings. And yet withal bound down by silly customs that make them > slaves to their unhappy lot while firm in the belief that they be the > lords of creation enjoying the only real pleasures of existence.... > > - the wisdom of Tarzan > > __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 Aug 20 07:12:37 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Aug 20 07:12:47 2007 Subject: [GRASS-dev] starting NVIZ from tcl map display toolbar Message-ID: <20070820171237.766715c8.hamish_nospam@yahoo.com> Hi, with the latest 6.3cvs, the nviz button flashes up the wish x-window then pops away. adding a debug {puts "$cmd"} into group.tcl proc GmGroup::nvdisplay{} then running the output at the GRASS> command prompt shows the error: Error: Raster is outside of current region Load Failed I -assume- NVIZ from the Map Display window is starting with the computational region, not the display region, but haven't added 'g.region -p's into the tcl nvdisplay {} to check. Of course starting the command from the terminal prompt will use the gis region, not the active display region so my above test is a bit flawed. Perhaps the caught error could be sent to an error popup window? If the NVIZ button was on the GIS Manager window, it's plausable to use the computational region; if the button is on the Map Display toolbar, it should really use the Display region. path: set the region somewhere outside a raster map start gis.m from the command line add raster map layer using a raster map hit redraw button (you get a white rectangle on the canvas) Use the "zoom to selected map" button redraw button "Start NVIZ using active layers in current region" button a wish x-window flashes then goes away. thanks, Hamish From michael.barton at asu.edu Mon Aug 20 08:55:32 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Aug 20 08:55:42 2007 Subject: [GRASS-dev] problem with wxPython 2.8.4.2 on Mac Message-ID: I recently updated from wxPython 2.8.4.0 to 2.8.4.2 on my Mac, using the binaries supplied at the wxPython site. After updating, wxgrass crashed with the error listed below. After I uninstalled 2.8.4.2 and reinstalled 2.8.4.0, it runs fine. I've posted this to the wxPython bug list too. Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 ========== error generated by wxPython 2.8.4.2 =========== GRASS 6.3.cvs (spearfish60_test):~ > Digitization tool is disabled. Under development... CGBitmapContextCreate: invalid data bytes/row: should be at least 4 for 8 integer bits/component, 3 components, kCGImageAlphaNoneSkipFirst. CGContextConcatCTM: invalid context CGContextConcatCTM: invalid context Traceback (most recent call last): File "/Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/wxgui.py", line 945, in app = GMApp(0) File "//Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packa ges/wx-2.8-mac-unicode/wx/_core.py", line 7819, in __init__ self._BootstrapApp() File "//Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packa ges/wx-2.8-mac-unicode/wx/_core.py", line 7416, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File "/Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/wxgui.py", line 927, in OnInit mainframe = GMFrame(parent=None, id=wx.ID_ANY, title="") File "/Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/wxgui.py", line 189, in __init__ self.NewDisplay() File "/Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/wxgui.py", line 585, in NewDisplay auimgr=self._auimgr) File "/Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/gui_modules/wxg ui_utils.py", line 133, in __init__ Map=self.Map, auimgr=self.auimgr) File "/Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/gui_modules/map disp.py", line 1518, in __init__ self.MapWindow = BufferedWindow(self, id = wx.ID_ANY, Map=self.Map, tree=self.tree) File "/Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/gui_modules/map disp.py", line 212, in __init__ self.OnSize(None) File "/Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/gui_modules/map disp.py", line 409, in OnSize self._Buffer = wx.EmptyBitmap(self.Map.width, self.Map.height) File "//Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packa ges/wx-2.8-mac-unicode/wx/_gdi.py", line 718, in EmptyBitmap val = _gdi_.new_EmptyBitmap(*args, **kwargs) wx._core.PyAssertionError: C++ assertion "m_hBitmap" failed at /BUILD/wxPython-src-2.8.4.2/src/mac/carbon/bitmap.cpp(230) in Create(): Unable to create CGBitmapContext context GRASS 6.3.cvs (spearfish60_test):~ > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070819/00596f74/attachment.html From hamish_nospam at yahoo.com Mon Aug 20 10:45:28 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Aug 20 10:46:30 2007 Subject: [GRASS-dev] trying to compile wxPython digitizer display_driver In-Reply-To: References: Message-ID: <20070820204528.ae677e8f.hamish_nospam@yahoo.com> Michael Barton wrote: > With regard to swig, this adds a major new dependency to the wxPython GUI. .. > Martin Landa is using it to create a display driver for the wxPython GUI > digitizing module. It's a fundamental choice we will have to make. With it we can build much richer GUI tools. Without it we get simpler installs. We will most likely be able to do anything without resorting to SWIG if we try hard enough; but how much extra work would that then be to write/maintain new C code to act as a go between for libgis & python? I'd leave it to the binary packagers to worry about installing swig, if it's needed by the user at runtime. Hamish From wolf+grass at bergenheim.net Mon Aug 20 11:29:14 2007 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Mon Aug 20 11:30:01 2007 Subject: [GRASS-dev] BLAS/LAPACK (Part II) In-Reply-To: <1187323784.20635.111.camel@dev64.localdomain> References: <1187323784.20635.111.camel@dev64.localdomain> Message-ID: <46C95EEA.1040702@bergenheim.net> On 17.08.2007 07:09, Brad Douglas wrote: > > What I propose is moving the matrix code from v.generalize +1 > (in particular, matrix_inverse() ) to lib/gmath and simplifying the existing > MATRIX structure. > I think that would be a good idea, especially if you also want to use that code. It is easier to maintain the code in one place. Brad do you know of any additional mathematics or similar things you'd like to see in lib/gmath? Perhaps next year it could be a Summer of Code project to add them ;) --Wolf -- <:3 )---- Wolf Bergenheim ----( 8:> From landa.martin at gmail.com Mon Aug 20 12:45:57 2007 From: landa.martin at gmail.com (Martin Landa) Date: Mon Aug 20 12:46:03 2007 Subject: [GRASS-dev] Re: wxgrass won't work - how to set up digitization? In-Reply-To: References: Message-ID: Hi Michael, now fixed in SVN. The C++ driver is not finished yet. Martin 2007/8/19, Michael Barton : > > Martin, > > I just updated all and now wxgrass won't start. I get the following > error... > > GRASS 6.3.cvs (spearfish60_test):~ > Traceback (most recent call last): > File > "/Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/wxgui.py", > line 57, in > import gui_modules.wxgui_utils as wxgui_utils > File > "/Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/gui_modules/wxgui_utils.py", > line 36, in > import mapdisp > File > "/Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/gui_modules/mapdisp.py", > line 55, in > import toolbars > File > "/Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/gui_modules/toolbars.py", > line 28, in > from digit import Digit as Digit > File > "/Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/gui_modules/digit.py", > line 60, in > from grass6_wxdriver import DisplayDriver > ImportError: No module named grass6_wxdriver > > I assume that I need the new displaydriver C module you have written. I > copied it into my running version and tried to make it, but got the > following error... > > Last login: Sat Aug 18 11:48:21 on ttyp1 > Welcome to Darwin! > cmb-MBP:~ cmbarton$ cd > /Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/display_driver/ > cmb-MBP:/Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/display_driver > cmbarton$ make > Makefile:17: warning: overriding commands for target `clean' > ../../../include/Make/Rules.make:34: warning: ignoring old > commands for target `clean' > cat ./driver.i > grass6_wxdriver.i > echo "/* auto-generate swig typedef file (with some GRASS functions > removed) */" >> grass6_wxdriver.i > cat ./driver.h >> grass6_wxdriver.i > swig -c++ -python -shadow grass6_wxdriver.i > make: swig: Command not found > make: *** [grass6_wxdriver_wrap.cxx] Error 127 > > What do I need to do to make this work? > > BTW, my GRASS is compiled with PYTHON support, so swig *ought* to be there. > I probably am just doing this wrong. > > Thanks > Michael > > __________________________________________ > Michael Barton, Professor of Anthropology > Director of Graduate Studies > 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 > > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From landa.martin at gmail.com Mon Aug 20 13:13:06 2007 From: landa.martin at gmail.com (Martin Landa) Date: Mon Aug 20 13:13:18 2007 Subject: [GRASS-dev] Re: trying to compile wxPython digitizer display_driver In-Reply-To: References: Message-ID: Michael, I disabled loading the driver in digit.py today. The driver is not finished yet. The are parts of Makefile which are hardcoded (ugly), I will fix it. At the end of the week it should be stable and usable. Sorry, I am now busy with another work. I will tell you when it is ready for testing. Martin 2007/8/19, Michael Barton : > > Martin, > > I compiled swig, but still am not able to compile your new display driver > for the wxPython GUI. I've had to drop back to the earlier (non-functional) > version of digit.py just to get it all to run. > > I'm pretty sure that, after installing swig, the problem lies in the > Makefile, which seems to be hard-coded to match your system. I've tried > playing around with some of the parameters, but have been unsuccessful. I > just don't know much about the details of compiling C code. The Makefile is > short, so I'm including it below along with some of my comments. Maybe > someone can offer suggestions as to 1) how to make it work with my Mac and > 2) how to generalize it so it works more easily with other systems as well. > > With regard to swig, this adds a major new dependency to the wxPython GUI. > It doesn't come on the Mac and I had to compile it from source. IT was > pretty easy, but not something other most other Mac users will want to do. > Same with Windows users. Maybe we'll want to have Python-swig as a > requirement anyway. Several people have mentioned this. I know generally > what it swig does, but not the details. An important question is...Is swig > necessary for creating the driver for digitizing in wxPython or is there > potentially another way to do this? That is, can we accomplish what you are > trying to do without swig, oris it essential to make it work? > > I'm looking forward to trying the new digitizer after getting this driver > up and working. > > Cheers > Michal > __________________________________________ > Michael Barton, Professor of Anthropology > Director of Graduate Studies > 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 > > > Makefile below ========================== > > > PYTHONVERSION=2.4 > > >>>> NOTE: this should be 2.4 or above rather than hard coded to 2.4 (I > have 2.5, for example). I know that there is some way to specify this, but > don't remember what it is. > > MODULE_TOPDIR = ../../.. > > include $(MODULE_TOPDIR)/include/Make/Lib.make > include $(MODULE_TOPDIR)/include/Make/Doxygen.make > > >>>> NOTE: This seems to imply putting the source directory for > display_driver somewhere in the GRASS source tree, but I can't figure out > where it is supposed to go. I've tried putting it at the root, in lib, and > another place or two. My GRASS source tree happens to be in > /Users/cmbarton/grass_dev/grass6. > > SWIG=swig > > CFLAGS=-c -fpic -I/usr/include/python$(PYTHONVERSION) -I./ > -I$(ARCH_DISTDIR)/include `wx-config --cxxflags` > > >>>> NOTE: My Python includes are in a completely different place. I'm not > sure what ARCH_DISTDIR refers to but am guessing that this needs to be set > to match each system. > > LDFLAGS=-shared -L$(ARCH_LIBDIR) -lgrass_vect -lgrass_gis `wx-config > --libs` > > >>>> NOTE: This may need to be changed for Mac OS X if I am correctly > remembering some discussions crossing the dev list. > > default: grass6_wxdriver.so > > clean: > -rm -f *.o *.so grass6_wxdriver_wrap.cxx grass6_wxdriver.py > grass6_wxdriver.i grass6_wxdriver.pyc > > grass6_wxdriver.i: > cat ./driver.i > grass6_wxdriver.i > echo "/* auto-generate swig typedef file (with some GRASS functions > removed) */" >> grass6_wxdriver.i > cat ./driver.h >> grass6_wxdriver.i > > grass6_wxdriver_wrap.cxx: grass6_wxdriver.i > $(SWIG) -c++ -python -shadow $< > > grass6_wxdriver_wrap.o: grass6_wxdriver_wrap.cxx > $(CXX) $(CFLAGS) $(INCLUDE_DIRS) $< > > driver.o: driver.cc > $(CXX) $(CFLAGS) $(INCLUDE_DIRS) $< > > pseudodc.o: pseudodc.cpp > $(CXX) $(CFLAGS) $(INCLUDE_DIRS) $< > > grass6_wxdriver.so: grass6_wxdriver_wrap.o driver.o pseudodc.o > $(CXX) $(LDFLAGS) grass6_wxdriver_wrap.o driver.o pseudodc.o -o > _grass6_wxdriver.so > > > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From landa.martin at gmail.com Mon Aug 20 13:18:00 2007 From: landa.martin at gmail.com (Martin Landa) Date: Mon Aug 20 13:18:03 2007 Subject: [GRASS-dev] Re: [GRASSGUI] trying to compile wxPython digitizer display_driver In-Reply-To: References: Message-ID: Hi William, thanks for notes and scripts!! I will take a look at these files. Anyway I need to update the python code to enable this driver. I hope very soon available for testing. Martin 2007/8/20, William Kyngesburye : > Hey guys, > > I worked out a setup.py script to build the display driver. This > makes it easier to configure the installation of python and > wxpython. I pulled bits from the MapServer and GDAL Python setup.py > scripts. > > - no python version needed from configure for the makefile > > - doesn't hardwire the compile/link flags or grass libs > > - source compilation and linking is handled externally by python, > only the swig step must be handled by the GRASS makefile > > A couple things to work out: > > - the OSX wx-config script is buried in a non-standard location (lib/ > wxPython-unicode-[version]/bin). For now, add that to your path > before building the driver. Eventually, it needs to be configured > with something like a --with-wxpython= option. > > - installation - distutils builds in a subfolder, "build", with > platform subfolders from that. The distutils install option knows > where to find this, but that installs in the python site-packages > folder. If we want to keep the driver within the GRASS installation, > the makefile needs to figure out the platform folder to find it. Or > there may be an option to setup.py to do this - I've only fiddled > with distutils and don't know all its capabilities. > > - it's currently setup for grass_src/somefolder/gui/display_driver - > that is, 3 levels deep. (this is for the MODULE_TOPDIR in the > makefile and a couple items in setup.py) This should work with > grass_src/swig/python/display_driver, as you seem to have it Martin. > Or something like grass_src/gui/wx/display_driver. > > Here are the files: > > > > (note: don't need makefile.in) > > > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > "Oh, look, I seem to have fallen down a deep, dark hole. Now what > does that remind me of? Ah, yes - life." > > - Marvin > > > > > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From mlennert at club.worldonline.be Mon Aug 20 14:39:20 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Mon Aug 20 14:38:40 2007 Subject: [GRASS-dev] Re: [GRASSGUI] Re: wxgrass won't work - how to set up digitization? In-Reply-To: References: Message-ID: <46C98B78.7010204@club.worldonline.be> On 20/08/07 12:45, Martin Landa wrote: > Hi Michael, > > now fixed in SVN. The C++ driver is not finished yet. Does this mean we will have mission-critical elements (such as digitiation) in C++ ? In view of all the problems this has caused in the past, I would strongly plead against this. Moritz From woklist at kyngchaos.com Mon Aug 20 16:25:27 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Aug 20 16:25:43 2007 Subject: [GRASS-dev] Re: [GRASSGUI] trying to compile wxPython digitizer display_driver In-Reply-To: References: Message-ID: <0A349D34-BF8F-4AD2-8D7C-6E0CF7668C20@kyngchaos.com> Strange. It sees the makefile, or it it would also say it couldn't find one. All I can think of is that it somehow became empty or mangled. On Aug 19, 2007, at 11:36 PM, Michael Barton wrote: > On 8/19/07 8:32 PM, "William Kyngesburye" > wrote: > >> It was meant to be run from the makefile. So just "make" and it >> should work. The makefile does the swig stuff. Then runs "python >> setup.py build". Also, before running make, set the shell PATH to >> include wxpython - for the 2.8.4 version I just installed today that >> would be: >> >> export PATH="/usr/local/lib/wxPython-unicode-2.8.4.2/bin:$PATH" >> > > I tried this but got the error... > > cmb-MBP:~/grass_dev/grass6/gui/wxpython/display_driver cmbarton$ make > make: *** No targets. Stop. > cmb-MBP:~/grass_dev/grass6/gui/wxpython/display_driver cmbarton$ ----- William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect From soerengebbert at gmx.de Mon Aug 20 17:20:18 2007 From: soerengebbert at gmx.de (=?iso-8859-1?Q?=22S=F6ren_Gebbert=22?=) Date: Mon Aug 20 17:20:29 2007 Subject: [GRASS-dev] BLAS/LAPACK (Part II) In-Reply-To: <46C95EEA.1040702@bergenheim.net> References: <1187323784.20635.111.camel@dev64.localdomain> <46C95EEA.1040702@bergenheim.net> Message-ID: <20070820152018.211760@gmx.net> HI folks, -------- Original-Nachricht -------- > Datum: Mon, 20 Aug 2007 12:29:14 +0300 > Von: Wolf Bergenheim > An: GRASS Devel > CC: Daniel Bundala , Brad Douglas > Betreff: Re: [GRASS-dev] BLAS/LAPACK (Part II) > On 17.08.2007 07:09, Brad Douglas wrote: > > > > What I propose is moving the matrix code from v.generalize > > +1 > > > (in particular, matrix_inverse() ) to lib/gmath and simplifying the > existing > > MATRIX structure. > > I can easily integrate the matrix code from v.generailze into the gpde library, because the existing matrix structures are quite similar. Quadratic and sparse matrices are supported. The gpde library ships several vector-matrix and vector-vector functions with it, but currently as static functions within the krylov-space solvers. I can make them public (extern), so they can be accessed from out side of the krylov solvers. Many linear equation solvers are available within the gpde library: * direct solvers ** gauss elimination ** lu decomposition ** cholesky decomposition. * iterative solvers ** gauss seidel / SOR ** jacobi ** conjugate gradients (krylov space method) ** preconditioned conjugate gradients (krylov space method) ** biconjugate gradients stabilized (krylov space method) Everything is multithreaded with OpenMP (solver, matrix, vector operations and some array functions). And as you know, the lu code in gmath lib is a copy of the numerical recipes algorithm and not free. I would like to hear some suggestions. Best regards Soeren > > I think that would be a good idea, especially if you also want to use > that code. It is easier to maintain the code in one place. > > Brad do you know of any additional mathematics or similar things you'd > like to see in lib/gmath? Perhaps next year it could be a Summer of Code > project to add them ;) > > --Wolf > > -- > > <:3 )---- Wolf Bergenheim ----( 8:> > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Psssst! Schon vom neuen GMX MultiMessenger geh?rt? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger From neteler at itc.it Mon Aug 20 17:29:50 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Aug 20 17:29:55 2007 Subject: [GRASS-dev] r.series threshold patch In-Reply-To: <18118.6265.857512.653581@cerise.gclements.plus.com> References: <20070816161159.GA6926@bartok.itc.it> <18116.40586.591784.539172@cerise.gclements.plus.com> <46C5CDFA.8010707@itc.it> <18118.6265.857512.653581@cerise.gclements.plus.com> Message-ID: <12238104.post@talk.nabble.com> Glynn Clements wrote: > > Markus Neteler wrote: >> >> to easier operate on incomplete time series from MODIS (and >> >> others), we would like to suggest attached patch. It >> >> adds a threshold to filter out incomplete pixel series >> >> before calling the aggregation function which saves us >> >> to perform extra runs on counting valid pixels and to >> >> post-filter the aggregated results. >> > >> > While I don't doubt that this is a useful optimisation for your >> > particular case, I'm generally opposed to adding such optimisations >> > for specific cases. >> > >> > A more general optimisation would be to extend the method= and output= >> > options to accept multiple values, so that you can compute multiple >> > aggregates in a single run. You would still need to combine the two >> > outputs with e.g. r.mapcalc, but you would only need one run of >> > r.series. >> > >> The optimization you propose is of course far more general than what >> we did, and could be extremely valuable. >> >> Nonetheless, we think that introducing the threshold parameter is not >> really a special case hack: all it really does is a straightforward >> generalization of the current -n flag, transforming it from a ON/OFF >> switch to an integer value. >> >> The threshold parameter indicates the minimum number of non NULL >> inputs required for passing over the inputs to the aggregation >> function. >> >> It varies in the range [1,num_inputs]; thresh=num_inputs is equivalent >> to -n (return NULL unless the inputs are all non NULL), while thresh=1 >> is the standard behaviour (compute the aggregation if there is at >> least 1 non NULL input). > > Actually, thresh=0 would give the existing behaviour. If -n isn't > used, the values are always passed to the aggregate function. If all > of the values are null, most aggregates will return null, but the > "count" aggregate will return 0. > You are right. Do you still vote against the patch in general (along with better documentation)? Markus -- View this message in context: http://www.nabble.com/r.series-threshold-patch-tf4280608.html#a12238104 Sent from the Grass - Dev mailing list archive at Nabble.com. From mlennert at club.worldonline.be Mon Aug 20 17:37:06 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Mon Aug 20 17:36:26 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: References: <98406.78280.qm@web60521.mail.yahoo.com> <18104.45127.468813.123101@cerise.gclements.plus.com> <18104.50679.830154.347160@cerise.gclements.plus.com> Message-ID: <1527.164.15.134.164.1187624226.squirrel@geog-pc40.ulb.ac.be> On Wed, August 8, 2007 20:49, Paul Kelly wrote: > On Tue, 7 Aug 2007, Glynn Clements wrote: >> I've added an nviz.bat script for use on Windows; I've also fixed the >> Makefile to ensure that the binary gets the .exe extension. > > That's excellent - I can confirm that it works again for me too. Somehow I > thought there was something else - I tried reverting to the way it was > before but couldn't get it working again. But didn't think of adding a > separate script start for Windows. > > I found another issue with the use of the cat command in part of an NVIZ > Tcl script which I've also fixed, and it seems to be working well now. > Grepping for "exec" in the other scripts I see a few more hackish-looking > things that will need to be fixed to get all the NVIZ functionality > working on Windows though. > Just checked out latest CVS and recompiled, and now I get the following when I try to launch nviz from the menu (File -> 3D Rendering -> NVIZ): child killed: SIGABRT while executing "exec -- $program --tcltk" (procedure "run_ui" line 6) invoked from within "run_ui $cmd" (procedure "execute" line 3) invoked from within "execute nviz " (menu invoke) When I display the spearfish DEM in a display window and then click on the nviz button of that window, nothing happens. No error messages, nothing except for a brief appearance of r.info.exe in the Windows task manager. Moritz From michael.barton at asu.edu Mon Aug 20 17:42:18 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Aug 20 17:42:24 2007 Subject: [GRASS-dev] Re: [GRASSGUI] trying to compile wxPython digitizer display_driver In-Reply-To: Message-ID: Thanks William and Martin. I think this will be nice when it is all together. Martin, I add an optional dialog to the map selection control, specifically with the digitizer issues on Mac in mind. If you switch to that, using a button in the digitizing toolbar to select a map instead of the combobox control, it should display on a Mac. Michael On 8/20/07 4:18 AM, "Martin Landa" wrote: > Hi William, > > thanks for notes and scripts!! I will take a look at these files. > Anyway I need to update the python code to enable this driver. I hope > very soon available for testing. > > Martin > > 2007/8/20, William Kyngesburye : >> Hey guys, >> >> I worked out a setup.py script to build the display driver. This >> makes it easier to configure the installation of python and >> wxpython. I pulled bits from the MapServer and GDAL Python setup.py >> scripts. >> >> - no python version needed from configure for the makefile >> >> - doesn't hardwire the compile/link flags or grass libs >> >> - source compilation and linking is handled externally by python, >> only the swig step must be handled by the GRASS makefile >> >> A couple things to work out: >> >> - the OSX wx-config script is buried in a non-standard location (lib/ >> wxPython-unicode-[version]/bin). For now, add that to your path >> before building the driver. Eventually, it needs to be configured >> with something like a --with-wxpython= option. >> >> - installation - distutils builds in a subfolder, "build", with >> platform subfolders from that. The distutils install option knows >> where to find this, but that installs in the python site-packages >> folder. If we want to keep the driver within the GRASS installation, >> the makefile needs to figure out the platform folder to find it. Or >> there may be an option to setup.py to do this - I've only fiddled >> with distutils and don't know all its capabilities. >> >> - it's currently setup for grass_src/somefolder/gui/display_driver - >> that is, 3 levels deep. (this is for the MODULE_TOPDIR in the >> makefile and a couple items in setup.py) This should work with >> grass_src/swig/python/display_driver, as you seem to have it Martin. >> Or something like grass_src/gui/wx/display_driver. >> >> Here are the files: >> >> >> >> (note: don't need makefile.in) >> >> >> >> ----- >> William Kyngesburye >> http://www.kyngchaos.com/ >> >> "Oh, look, I seem to have fallen down a deep, dark hole. Now what >> does that remind me of? Ah, yes - life." >> >> - Marvin >> >> >> >> >> > __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Mon Aug 20 17:45:05 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Aug 20 17:45:12 2007 Subject: [GRASS-dev] starting NVIZ from tcl map display toolbar In-Reply-To: <20070820171237.766715c8.hamish_nospam@yahoo.com> Message-ID: On 8/19/07 10:12 PM, "Hamish" wrote: > If the NVIZ button was on the GIS Manager window, it's plausable to use > the computational region; if the button is on the Map Display toolbar, > it should really use the Display region. > > > path: > set the region somewhere outside a raster map > start gis.m from the command line > add raster map layer using a raster map > hit redraw button > (you get a white rectangle on the canvas) > Use the "zoom to selected map" button > redraw button > "Start NVIZ using active layers in current region" button > a wish x-window flashes then goes away. > Hamish, This is a very good point. As well as annoying, it is counter-intuitive that nviz opened on a display does not not show what is in the display. I'll see if there is anything that can be done about it. Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 neteler at itc.it Mon Aug 20 20:32:54 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Aug 20 20:32:57 2007 Subject: [GRASS-dev] BLAS/LAPACK (Part II) In-Reply-To: <20070820152018.211760@gmx.net> References: <1187323784.20635.111.camel@dev64.localdomain> <46C95EEA.1040702@bergenheim.net> <20070820152018.211760@gmx.net> Message-ID: <20070820183254.GG28104@bartok.itc.it> Hi Soeren, from my users point of view this sounds excellent. please go ahead... You had already suggested it and there were apparently no objections. thanks Markus On Mon, Aug 20, 2007 at 05:20:18PM +0200, "S?ren Gebbert" wrote: > HI folks, > > -------- Original-Nachricht -------- > > Datum: Mon, 20 Aug 2007 12:29:14 +0300 > > Von: Wolf Bergenheim > > An: GRASS Devel > > CC: Daniel Bundala , Brad Douglas > > Betreff: Re: [GRASS-dev] BLAS/LAPACK (Part II) > > > On 17.08.2007 07:09, Brad Douglas wrote: > > > > > > What I propose is moving the matrix code from v.generalize > > > > +1 > > > > > (in particular, matrix_inverse() ) to lib/gmath and simplifying the > > existing > > > MATRIX structure. > > > > > I can easily integrate the matrix code from v.generailze into > the gpde library, because the existing matrix structures are quite > similar. Quadratic and sparse matrices are supported. > The gpde library ships several vector-matrix and vector-vector > functions with it, but currently as static functions within the krylov-space solvers. I can make them public (extern), > so they can be accessed from out side of the krylov solvers. > > Many linear equation solvers are available > within the gpde library: > * direct solvers > ** gauss elimination > ** lu decomposition > ** cholesky decomposition. > * iterative solvers > ** gauss seidel / SOR > ** jacobi > ** conjugate gradients (krylov space method) > ** preconditioned conjugate gradients (krylov space method) > ** biconjugate gradients stabilized (krylov space method) > > Everything is multithreaded with OpenMP (solver, matrix, vector operations and some array functions). > > And as you know, the lu code in gmath lib is a copy > of the numerical recipes algorithm and not free. > > I would like to hear some suggestions. > > Best regards > Soeren > > > > > > I think that would be a good idea, especially if you also want to use > > that code. It is easier to maintain the code in one place. > > > > Brad do you know of any additional mathematics or similar things you'd > > like to see in lib/gmath? Perhaps next year it could be a Summer of Code > > project to add them ;) > > > > --Wolf > > > > -- > > > > <:3 )---- Wolf Bergenheim ----( 8:> > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev > > -- > Psssst! Schon vom neuen GMX MultiMessenger geh?rt? > Der kanns mit allen: http://www.gmx.net/de/go/multimessenger > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Markus Neteler http://mpa.itc.it/markus/ FBK-irst - Centro per la Ricerca Scientifica e Tecnologica MPBA - Predictive Models for Biol. & Environ. Data Analysis Via Sommarive, 18 - 38050 Povo (Trento), Italy From dylan.beaudette at gmail.com Mon Aug 20 21:58:43 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Mon Aug 20 21:58:22 2007 Subject: [GRASS-dev] Re: v.generalize and interpolation, dmax problem In-Reply-To: <65AD6170-10AA-44E2-925B-6CB2F6B17643@unity.ncsu.edu> References: <1185306826.8290.11.camel@dev64.localdomain> <65AD6170-10AA-44E2-925B-6CB2F6B17643@unity.ncsu.edu> Message-ID: <200708201258.43438.dylan.beaudette@gmail.com> On Sunday 19 August 2007 18:22, Helena Mitasova wrote: > Profiles that you may get from real time kinematic survey or single ? > beam sonar > have similar problem as contours with points being much denser along ? > the profile compared > to the distance between profiles, but they would require ? > generalization in vertical plane rather > than the horizontal plane. This might not be the best place to start a thread on this... However, I will be working on some RTK-based DEM creation stuff, and was about to ask the list for some pointers on planning out the survey. Dylan -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 From bundala at gmail.com Mon Aug 20 22:08:27 2007 From: bundala at gmail.com (Daniel Bundala) Date: Mon Aug 20 22:08:32 2007 Subject: [GRASS-dev] BLAS/LAPACK (Part II) In-Reply-To: <20070820183254.GG28104@bartok.itc.it> References: <1187323784.20635.111.camel@dev64.localdomain> <46C95EEA.1040702@bergenheim.net> <20070820152018.211760@gmx.net> <20070820183254.GG28104@bartok.itc.it> Message-ID: <9211715e0708201308p67fc89bak5dacfbce89c3467d@mail.gmail.com> Guys, It is quite interesting, but I have had plans to replace v.generalize matrix code by "yours" library code. I have not studied G_matrix_* code carefully, but it seems to me that it is superior. Firstly, Soeren wrote that the current code is multithreaded. Secondly, someone mentioned, that it supports the sparse matrices. Support of sparse matrices would increase the efficiency of v.generalize since it uses only the sparse matrices. Thirdly, Soeren mentioned that the current code supports many methods my code doesnt support. To tell the truth, I have never heard about many of them (Well, I am still (young) student...) The only thing I am missing in the current code is the direct access to the elements of a matrix. But, this is quite dangerous and I really doubt whether this is a good API-desing. On the other hand, it is true that the current code is quite obscure, say. Also, it is tempting to replace fortran code by C code. Therefore, my suggestons are: clean library code and replace the current code by v.generalize code only if it is really faster. Some benchmarks are probably required, but I doubt that my code beats (optimized) library code. Daniel On 8/20/07, Markus Neteler wrote: > Hi Soeren, > > from my users point of view this sounds excellent. please go ahead... > You had already suggested it and there were apparently no > objections. > > thanks > Markus > > On Mon, Aug 20, 2007 at 05:20:18PM +0200, "S?ren Gebbert" wrote: > > HI folks, > > > > -------- Original-Nachricht -------- > > > Datum: Mon, 20 Aug 2007 12:29:14 +0300 > > > Von: Wolf Bergenheim > > > An: GRASS Devel > > > CC: Daniel Bundala , Brad Douglas > > > Betreff: Re: [GRASS-dev] BLAS/LAPACK (Part II) > > > > > On 17.08.2007 07:09, Brad Douglas wrote: > > > > > > > > What I propose is moving the matrix code from v.generalize > > > > > > +1 > > > > > > > (in particular, matrix_inverse() ) to lib/gmath and simplifying the > > > existing > > > > MATRIX structure. > > > > > > > > I can easily integrate the matrix code from v.generailze into > > the gpde library, because the existing matrix structures are quite > > similar. Quadratic and sparse matrices are supported. > > The gpde library ships several vector-matrix and vector-vector > > functions with it, but currently as static functions within the krylov-space solvers. I can make them public (extern), > > so they can be accessed from out side of the krylov solvers. > > > > Many linear equation solvers are available > > within the gpde library: > > * direct solvers > > ** gauss elimination > > ** lu decomposition > > ** cholesky decomposition. > > * iterative solvers > > ** gauss seidel / SOR > > ** jacobi > > ** conjugate gradients (krylov space method) > > ** preconditioned conjugate gradients (krylov space method) > > ** biconjugate gradients stabilized (krylov space method) > > > > Everything is multithreaded with OpenMP (solver, matrix, vector operations and some array functions). > > > > And as you know, the lu code in gmath lib is a copy > > of the numerical recipes algorithm and not free. > > > > I would like to hear some suggestions. > > > > Best regards > > Soeren > > > > > > > > > > I think that would be a good idea, especially if you also want to use > > > that code. It is easier to maintain the code in one place. > > > > > > Brad do you know of any additional mathematics or similar things you'd > > > like to see in lib/gmath? Perhaps next year it could be a Summer of Code > > > project to add them ;) > > > > > > --Wolf > > > > > > -- > > > > > > <:3 )---- Wolf Bergenheim ----( 8:> > > > > > > _______________________________________________ > > > grass-dev mailing list > > > grass-dev@grass.itc.it > > > http://grass.itc.it/mailman/listinfo/grass-dev > > > > -- > > Psssst! Schon vom neuen GMX MultiMessenger geh?rt? > > Der kanns mit allen: http://www.gmx.net/de/go/multimessenger > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev > > -- > Markus Neteler http://mpa.itc.it/markus/ > FBK-irst - Centro per la Ricerca Scientifica e Tecnologica > MPBA - Predictive Models for Biol. & Environ. Data Analysis > Via Sommarive, 18 - 38050 Povo (Trento), Italy > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From glynn at gclements.plus.com Mon Aug 20 22:30:00 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Aug 20 22:33:17 2007 Subject: [GRASS-dev] Re: [GRASSGUI] Re: wxgrass won't work - how to set up digitization? In-Reply-To: <46C98B78.7010204@club.worldonline.be> References: <46C98B78.7010204@club.worldonline.be> Message-ID: <18121.63944.684946.165717@cerise.gclements.plus.com> Moritz Lennert wrote: > > now fixed in SVN. The C++ driver is not finished yet. > > Does this mean we will have mission-critical elements (such as > digitiation) in C++ ? In view of all the problems this has caused in the > past, I would strongly plead against this. For reasons which I've gone over more times that I care to remember, I strongly suggest that anything which links against GRASS libraries should be a separate program. -- Glynn Clements From gnelson at uiuc.edu Mon Aug 20 22:36:12 2007 From: gnelson at uiuc.edu (Jerry Nelson) Date: Mon Aug 20 22:38:41 2007 Subject: [GRASS-dev] Re: [GRASSGUI] Re: wxgrass won't work - how to set updigitization? In-Reply-To: <18121.63944.684946.165717@cerise.gclements.plus.com> References: <46C98B78.7010204@club.worldonline.be> <18121.63944.684946.165717@cerise.gclements.plus.com> Message-ID: <002501c7e369$bfae4950$3e40ae80@ace.uiuc.edu> Sounds like an item for a developer FAQ or maybe it should be a FMC (frequently made comment) ;-) Jerry -----Original Message----- From: grass-dev-bounces@grass.itc.it [mailto:grass-dev-bounces@grass.itc.it] On Behalf Of Glynn Clements Sent: Monday, August 20, 2007 3:30 PM To: Moritz Lennert Cc: Martin Landa; grass-gui; Michael Barton; GRASS developers list Subject: Re: [GRASS-dev] Re: [GRASSGUI] Re: wxgrass won't work - how to set updigitization? Moritz Lennert wrote: > > now fixed in SVN. The C++ driver is not finished yet. > > Does this mean we will have mission-critical elements (such as > digitiation) in C++ ? In view of all the problems this has caused in the > past, I would strongly plead against this. For reasons which I've gone over more times that I care to remember, I strongly suggest that anything which links against GRASS libraries should be a separate program. -- Glynn Clements _______________________________________________ grass-dev mailing list grass-dev@grass.itc.it http://grass.itc.it/mailman/listinfo/grass-dev From paul-grass at stjohnspoint.co.uk Mon Aug 20 22:38:41 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Aug 20 22:38:56 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: <1527.164.15.134.164.1187624226.squirrel@geog-pc40.ulb.ac.be> References: <98406.78280.qm@web60521.mail.yahoo.com> <18104.45127.468813.123101@cerise.gclements.plus.com> <18104.50679.830154.347160@cerise.gclements.plus.com> <1527.164.15.134.164.1187624226.squirrel@geog-pc40.ulb.ac.be> Message-ID: On Mon, 20 Aug 2007, Moritz Lennert wrote: > On Wed, August 8, 2007 20:49, Paul Kelly wrote: >> On Tue, 7 Aug 2007, Glynn Clements wrote: > >>> I've added an nviz.bat script for use on Windows; I've also fixed the >>> Makefile to ensure that the binary gets the .exe extension. >> >> That's excellent - I can confirm that it works again for me too. Somehow I >> thought there was something else - I tried reverting to the way it was >> before but couldn't get it working again. But didn't think of adding a >> separate script start for Windows. >> >> I found another issue with the use of the cat command in part of an NVIZ >> Tcl script which I've also fixed, and it seems to be working well now. >> Grepping for "exec" in the other scripts I see a few more hackish-looking >> things that will need to be fixed to get all the NVIZ functionality >> working on Windows though. >> > > Just checked out latest CVS and recompiled, and now I get the following > when I try to launch nviz from the menu (File -> 3D Rendering -> NVIZ): > > child killed: SIGABRT > while executing > "exec -- $program --tcltk" > (procedure "run_ui" line 6) > invoked from within > "run_ui $cmd" > (procedure "execute" line 3) > invoked from within > "execute nviz " > (menu invoke) > > > When I display the spearfish DEM in a display window and then click on the > nviz button of that window, nothing happens. No error messages, nothing > except for a brief appearance of r.info.exe in the Windows task manager. Hello Moritz, Works for me starting it both those ways, and also from command-line. I even tried make distclean and compiling from scratch in case there was something I'd manually fixed that kept it working on my system. So I don't know what could be up with yours. Maybe you have an old nviz.exe lying around in your PATH somewhere that is getting picked up when the GUI runs "nviz", instead of Glynn's new nviz.bat? A couple of side-notes though: 1) In general the GUI is terrible at catching and reporting errors from modules it calls in the background and this leads to cryptic error messages or nothing happening all over the place. IMHO it is a really pervasive problem that definitely needs fixed in the next GUI. Hopefully it already is there (ISTR discussions about every call to a GRASS module going through some other function where the error trapping could presumably be added, to avoid code repetition). 2) When the displayed layers start up in NVIZ the colour of the displayed vector map isn't preserved. I'm guessing this is because it can't be specified on the command-line, but perhaps the code that starts NVIZ using the displayed layers should write a temporary NVIZ state file and then start NVIZ with that file? I've no idea how complicated that would be to do though. E.g. might be better only focussing on it in the new GUI. I would love the functionality of NVIZ (most of which is implemented using the gsurf library AIUI), to be available from the command-line as well as through the Tcl/Tk interface. Would be cool to be able to generate 3-D images with specified observer location and attitude and so on from a shell script (or scripting language of your choice), rather than having to do it with Tcl scripting in NVIZ. Paul From hmitaso at unity.ncsu.edu Mon Aug 20 22:46:48 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Mon Aug 20 22:46:53 2007 Subject: [GRASS-dev] Re: v.generalize and interpolation, dmax problem In-Reply-To: <200708201258.43438.dylan.beaudette@gmail.com> References: <1185306826.8290.11.camel@dev64.localdomain> <65AD6170-10AA-44E2-925B-6CB2F6B17643@unity.ncsu.edu> <200708201258.43438.dylan.beaudette@gmail.com> Message-ID: <1187642808.1717.15.camel@deliboz> On Mon, 2007-08-20 at 12:58 -0700, Dylan Beaudette wrote: > On Sunday 19 August 2007 18:22, Helena Mitasova wrote: > > Profiles that you may get from real time kinematic survey or single > > beam sonar > > have similar problem as contours with points being much denser along > > the profile compared > > to the distance between profiles, but they would require > > generalization in vertical plane rather > > than the horizontal plane. > > This might not be the best place to start a thread on this... However, I will > be working on some RTK-based DEM creation stuff, and was about to ask the > list for some pointers on planning out the survey. Dylan, you can write me directly - we have done quite a bit of work on the design of RTKGPS surveys (and while looking for a paper for you to look at I realized that probably the most interesting part of it we have never published - apparently we should do it). The survey design matters a lot - we have sampled high resolution lidar-based DEM with various combinations of profiles to find out the best combination - I can write you more or find the relevant presentation if you are interested, here are some papers with related info: http://skagit.meas.ncsu.edu/~helena/publwork/papers/Freeman03.pdf http://www.geodynamicsgroup.com/jockeysridge.html http://skagit.meas.ncsu.edu/~helena/gmslab/papers/reveeg20.pdf http://skagit.meas.ncsu.edu/~helena/gmslab/papers/JRGeomorph2005.pdf (see fig 3A) Helena > > Dylan > > From glynn at gclements.plus.com Mon Aug 20 22:48:27 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Aug 20 22:48:30 2007 Subject: [GRASS-dev] r.series threshold patch In-Reply-To: <12238104.post@talk.nabble.com> References: <20070816161159.GA6926@bartok.itc.it> <18116.40586.591784.539172@cerise.gclements.plus.com> <46C5CDFA.8010707@itc.it> <18118.6265.857512.653581@cerise.gclements.plus.com> <12238104.post@talk.nabble.com> Message-ID: <18121.65051.597085.835950@cerise.gclements.plus.com> Markus Neteler wrote: > >> >> to easier operate on incomplete time series from MODIS (and > >> >> others), we would like to suggest attached patch. It > >> >> adds a threshold to filter out incomplete pixel series > >> >> before calling the aggregation function which saves us > >> >> to perform extra runs on counting valid pixels and to > >> >> post-filter the aggregated results. > >> > > >> > While I don't doubt that this is a useful optimisation for your > >> > particular case, I'm generally opposed to adding such optimisations > >> > for specific cases. > >> > > >> > A more general optimisation would be to extend the method= and output= > >> > options to accept multiple values, so that you can compute multiple > >> > aggregates in a single run. You would still need to combine the two > >> > outputs with e.g. r.mapcalc, but you would only need one run of > >> > r.series. > >> > > >> The optimization you propose is of course far more general than what > >> we did, and could be extremely valuable. > >> > >> Nonetheless, we think that introducing the threshold parameter is not > >> really a special case hack: all it really does is a straightforward > >> generalization of the current -n flag, transforming it from a ON/OFF > >> switch to an integer value. > >> > >> The threshold parameter indicates the minimum number of non NULL > >> inputs required for passing over the inputs to the aggregation > >> function. > >> > >> It varies in the range [1,num_inputs]; thresh=num_inputs is equivalent > >> to -n (return NULL unless the inputs are all non NULL), while thresh=1 > >> is the standard behaviour (compute the aggregation if there is at > >> least 1 non NULL input). > > > > Actually, thresh=0 would give the existing behaviour. If -n isn't > > used, the values are always passed to the aggregate function. If all > > of the values are null, most aggregates will return null, but the > > "count" aggregate will return 0. > > You are right. > Do you still vote against the patch in general (along with better > documentation)? I probably won't be extending r.series to support multiple aggregates and outputs in the near future, so I don't have any real objection to the patch. One minor nit: the test doesn't need any additional parentheses; using: if (null && flag.nulls->answer || num_inputs - null < thresh) is sufficient. C operator precedence (highest to lowest): application () [] -> . unary ! ~ ++ -- + - * (type) sizeof multiplicative * / % additive + - shift << >> inequality < <= > >= equality == != bitwise-and & bitwise-xor ^ bitwise-or | logical-and && logical-or || conditional ?: assignment = += -= *= /= %= &= ^= |= <<= >>= sequencing , The unary, conditional and assignment operators are right-associative, all others are left-associative. Briefly: arithmetic operators are higher than relational operators which are higher than logical operators, which is the most convenient order for if/while/etc tests, and && is higher than ||, so sum-of-products doesn't require parentheses. -- Glynn Clements From soerengebbert at googlemail.com Fri Aug 17 13:10:00 2007 From: soerengebbert at googlemail.com (Soeren Gebbert) Date: Tue Aug 21 07:09:36 2007 Subject: [GRASS-dev] BLAS/LAPACK (Part II) In-Reply-To: <1187330078.20635.134.camel@dev64.localdomain> References: <1187323784.20635.111.camel@dev64.localdomain> <20070817171254.530a8937.hamish_nospam@yahoo.com> <1187330078.20635.134.camel@dev64.localdomain> Message-ID: 2007/8/17, Brad Douglas : > On Fri, 2007-08-17 at 17:12 +1200, Hamish wrote: > > Brad Douglas wrote: > > > > > > I did not hear any response to my question of whether to continue > > > using BLAS/LAPACK. Well, i was responding ... . > > > > > > This uncertainty has been particularly hard on me, being unable to > > > complete some work waiting for an answer one way or the other and not > > > wanting to implement my own version if not needed. > > > > > > Currently, there is no code in the tree that makes use of either > > > library other than my own. In fact, others have implemented their own > > > versions. > > > > If having it there is not hurting anything, I'd say leave it as-is. > > > > It is less work to maintain the configure scripts than it is to stay > > current with the latest advancements in the library. ie 5 years from > > now we'd have an unmaintained stale copy distributed with our source. > > ? There's nothing to go stale. Or are you making my case for me? > > > BLAS/LAPACK are in common use elsewhere, so it's not like a user would > > have to spend time hunting down and compiling obscure software to use > > it. > > > > Take pride in being the first to use it, we've been waiting a while for > > someone to. :) > > And then having modules become useless when the libraries aren't > compiled in? > > > > What I propose is moving the matrix code from v.generalize (in > > > particular, matrix_inverse() ) to lib/gmath and simplifying the > > > existing MATRIX structure. > > > > regardless of BLAS/LAPACK staying or going, consolidation, consistency, > > and anything else that makes the code easier to maintain is obviously a > > good thing. (but no idea about that specific code) > > There are only a few functions in lib/gmath that make use of > BLAS/LAPACK: > > G_matrix_product () > G_matrix_LU_solve () > G_vector_norm_euclid () > G_matrix_inverse () -- calls G_matrix_LU_solve () > > v.generalize solves: > G_matrix_product () > G_matrix_inverse () > G_matrix_LU_solve () > > So what's the point of having BLAS/LAPACK? I think we shoudl keep the LAPACK/BLAS interface in GRASS, especially for high performance comnputing on cluster, the LAPACK interface makes much sense. I had a short look at matrix.c and matrix.h in v.generalize. Because of the similar implementation of the gpde library functionality, i am able to port the functionality of v.generalize/matrix stuff into the gpde library. And i will implement it multithreaded, like all the linear equation solvers within the gpde library. What do you think? Soeren > > > -- > 73, de Brad KB8UYR/6 > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From soerengebbert at googlemail.com Mon Aug 20 23:37:39 2007 From: soerengebbert at googlemail.com (Soeren Gebbert) Date: Tue Aug 21 07:09:38 2007 Subject: [GRASS-dev] BLAS/LAPACK (Part II) In-Reply-To: <9211715e0708201308p67fc89bak5dacfbce89c3467d@mail.gmail.com> References: <1187323784.20635.111.camel@dev64.localdomain> <46C95EEA.1040702@bergenheim.net> <20070820152018.211760@gmx.net> <20070820183254.GG28104@bartok.itc.it> <9211715e0708201308p67fc89bak5dacfbce89c3467d@mail.gmail.com> Message-ID: Hi Daniel, 2007/8/20, Daniel Bundala : > Guys, > > It is quite interesting, but I have had plans to replace v.generalize > matrix code by "yours" library code. I have not studied G_matrix_* > code carefully, but it seems to me that it is superior. Unfortunately there are two libraries which handle the solution of linear equation systems. The gmath library with the G_math_* and G_vector_* functions and the higher level gpde library with several multi threaded solvers (N_solver_cg ...). I have implemented the matrix vector functionality in the gpde library again, because i wanted them multi threaded and i have had no idea if the gmath functions are thread safe and easy to parallele. > > Firstly, Soeren wrote that the current code is multithreaded. Yes, the code from the gpde library is multi threaded, but you can link parallelled lapack and blas libraries to the gmath interface (scalapack). > Secondly, someone mentioned, that it supports the sparse matrices. The gpde library supports a simple sparse matrix implementation and the matrix vector product functions. > Support of sparse matrices would increase the efficiency of > v.generalize since it uses only the sparse matrices. > Thirdly, Soeren mentioned that the current code supports many methods > my code doesnt support. To tell the truth, I have never heard about > many of them (Well, I am still (young) student...) Of what kind are your matrices? There are two very efficient solver within the gpde lib: 1.) for sparse symmetric and positive definite matrices (conjugate gradients with preconditioning cg/pcg) http://en.wikipedia.org/wiki/Conjugate_gradient_method and 2.)for sparse non symmetric, non definite matrices (stabilized bi conjugate gradients) http://en.wikipedia.org/wiki/Biconjugate_gradient_method Those two methods are the most efficient linear equation solvers available for large matrices. > > The only thing I am missing in the current code is the direct access > to the elements of a matrix. But, this is quite dangerous and I really > doubt whether this is a good API-desing. The matrix implementation within the gpde library offers direct access to the matrix entries and supports row shuffling by setting the row pointer (important for for pivoting). So the programmer have to assure thread safe access by himself. > > On the other hand, it is true that the current code is quite obscure, > say. Also, it is tempting to replace fortran code by C code. > Therefore, my suggestons are: clean library code and replace the > current code by v.generalize code only if it is really faster. Some > benchmarks are probably required, but I doubt that my code beats > (optimized) library code. The gpde library implementation is IMHO not faster than the gmath and BLAS/LAPACK stuff. Eg: the gmath lu solver is 30% faster than the gpde lu solver with pivoting. But the gmath lu solver is code from the numerical recipes, we have to rewrite this method. And the gpde lu solver runs on multi processor machines. I will present an implementation of several matrix-vector functions in some days. And I'm open for any suggestions about API design. :) Best regards Soeren > > Daniel > > On 8/20/07, Markus Neteler wrote: > > Hi Soeren, > > > > from my users point of view this sounds excellent. please go ahead... > > You had already suggested it and there were apparently no > > objections. > > > > thanks > > Markus > > > > On Mon, Aug 20, 2007 at 05:20:18PM +0200, "S?ren Gebbert" wrote: > > > HI folks, > > > > > > -------- Original-Nachricht -------- > > > > Datum: Mon, 20 Aug 2007 12:29:14 +0300 > > > > Von: Wolf Bergenheim > > > > An: GRASS Devel > > > > CC: Daniel Bundala , Brad Douglas > > > > Betreff: Re: [GRASS-dev] BLAS/LAPACK (Part II) > > > > > > > On 17.08.2007 07:09, Brad Douglas wrote: > > > > > > > > > > What I propose is moving the matrix code from v.generalize > > > > > > > > +1 > > > > > > > > > (in particular, matrix_inverse() ) to lib/gmath and simplifying the > > > > existing > > > > > MATRIX structure. > > > > > > > > > > > I can easily integrate the matrix code from v.generailze into > > > the gpde library, because the existing matrix structures are quite > > > similar. Quadratic and sparse matrices are supported. > > > The gpde library ships several vector-matrix and vector-vector > > > functions with it, but currently as static functions within the krylov-space solvers. I can make them public (extern), > > > so they can be accessed from out side of the krylov solvers. > > > > > > Many linear equation solvers are available > > > within the gpde library: > > > * direct solvers > > > ** gauss elimination > > > ** lu decomposition > > > ** cholesky decomposition. > > > * iterative solvers > > > ** gauss seidel / SOR > > > ** jacobi > > > ** conjugate gradients (krylov space method) > > > ** preconditioned conjugate gradients (krylov space method) > > > ** biconjugate gradients stabilized (krylov space method) > > > > > > Everything is multithreaded with OpenMP (solver, matrix, vector operations and some array functions). > > > > > > And as you know, the lu code in gmath lib is a copy > > > of the numerical recipes algorithm and not free. > > > > > > I would like to hear some suggestions. > > > > > > Best regards > > > Soeren > > > > > > > > > > > > > > I think that would be a good idea, especially if you also want to use > > > > that code. It is easier to maintain the code in one place. > > > > > > > > Brad do you know of any additional mathematics or similar things you'd > > > > like to see in lib/gmath? Perhaps next year it could be a Summer of Code > > > > project to add them ;) > > > > > > > > --Wolf > > > > > > > > -- > > > > > > > > <:3 )---- Wolf Bergenheim ----( 8:> > > > > > > > > _______________________________________________ > > > > grass-dev mailing list > > > > grass-dev@grass.itc.it > > > > http://grass.itc.it/mailman/listinfo/grass-dev > > > > > > -- > > > Psssst! Schon vom neuen GMX MultiMessenger geh?rt? > > > Der kanns mit allen: http://www.gmx.net/de/go/multimessenger > > > > > > _______________________________________________ > > > grass-dev mailing list > > > grass-dev@grass.itc.it > > > http://grass.itc.it/mailman/listinfo/grass-dev > > > > -- > > Markus Neteler http://mpa.itc.it/markus/ > > FBK-irst - Centro per la Ricerca Scientifica e Tecnologica > > MPBA - Predictive Models for Biol. & Environ. Data Analysis > > Via Sommarive, 18 - 38050 Povo (Trento), Italy > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev > > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From gallegos3 at llnl.gov Fri Aug 10 22:01:49 2007 From: gallegos3 at llnl.gov (Gretchen Gallegos) Date: Tue Aug 21 07:09:55 2007 Subject: [GRASS-dev] Mac OS X newbie question Message-ID: Hi all, Off and on, for a number of years, I have trying to use GRASS on the Mac. (I became a little familiar with GIS when ESRI still made ArcView for the Mac, and created some data that I still need, and need a better way to update it.) I am again trying to use GRASS (but it does not come up in the GUI). I need to deal with the fact that my login is remote from the computer I use. I know that I need to set a PATH variable somewhere to make GRASS work, but I have virtually no Unix understanding. I am capable of creating/editing a .tcshrc file or .cshrc file, but I don't really know what to put in it. I realize this issue is probably addressed somewhere in the archive of the lists, and I was hoping that someone could point me in the right direction. Thanks, Gretchen Gallegos From hamish_nospam at yahoo.com Tue Aug 21 15:34:47 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Aug 21 15:34:51 2007 Subject: [GRASS-dev] Mac OS X newbie question In-Reply-To: Message-ID: <354687.89263.qm@web52704.mail.re2.yahoo.com> Hi Gretchen, > Off and on, for a number of years, I have trying to use GRASS on the > Mac. (I became a little familiar with GIS when ESRI still made > ArcView for the Mac, and created some data that I still need, and > need a better way to update it.) I am again trying to use GRASS (but > it does not come up in the GUI). I need to deal with the fact that my > login is remote from the computer I use. I know that I need to set a > PATH variable somewhere to make GRASS work, but I have virtually no > Unix understanding. I am capable of creating/editing a .tcshrc file > or .cshrc file, but I don't really know what to put in it. If you are trying to use the GUI remotely from a Mac you might try using -Y: ssh -Y user@hostname 'xeyes' is a good test if X will get passed over the remote connection. As long as the remote host is set up correctly I don't think you have to bother with any PATH or .grass.bashrc / .grass.cshrc files. Hamish ____________________________________________________________________________________ Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 From woklist at kyngchaos.com Tue Aug 21 16:19:04 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Tue Aug 21 16:19:21 2007 Subject: [GRASS-dev] Mac OS X newbie question In-Reply-To: <354687.89263.qm@web52704.mail.re2.yahoo.com> References: <354687.89263.qm@web52704.mail.re2.yahoo.com> Message-ID: <35ECCA14-D9DC-43BA-A8F8-2FF7C9145A49@kyngchaos.com> I guess I interpreted this differently. Just to be clear, do you mean you are connecting to a remote computer, where GRASS resides, from your Mac? Or do you mean your Mac login & home is on a remote OSX server (LDAP), and GRASS is on the local Mac? If it's a remote connection to GRASS, then it's as Glynn says. You will also have to make sure that the X11 aplication is running. I don't know if you can run it from a Terminal, you may need to use an xterm from X11. Note also that OSX now defaults to the bash shell, so it would be .bashrc/.bash_profile. If it's an LDAP login, then that doesn't matter. There may be some things to put in the .bash_profile (DISPLAY, PATH), but if you use the OSX .app build of GRASS, this is taken care of for you. GRASS 6.3 has this, and I've ported it over for my 6.2 OSX binaries. It also takes care of making sure that X11 is running and starts the Terminal for you. Just double-click GRASS.app. With a generic unix build, you'll have to start X11 yourself, and at least "export DISPLAY=:0.0" should be in your .bash_profile. The X11 frowarding capability brings up an interesting point - when the Python gui is default, and NVIZ doesn't need X11, breaking the ties to X11 (on OSX at least), this won't be possible. A more indirect method, like VNC, will have to be used. On Aug 21, 2007, at 8:34 AM, Hamish wrote: > Hi Gretchen, > >> Off and on, for a number of years, I have trying to use GRASS on the >> Mac. (I became a little familiar with GIS when ESRI still made >> ArcView for the Mac, and created some data that I still need, and >> need a better way to update it.) I am again trying to use GRASS (but >> it does not come up in the GUI). I need to deal with the fact that my >> login is remote from the computer I use. I know that I need to set a >> PATH variable somewhere to make GRASS work, but I have virtually no >> Unix understanding. I am capable of creating/editing a .tcshrc file >> or .cshrc file, but I don't really know what to put in it. > > If you are trying to use the GUI remotely from a Mac you might try > using -Y: > ssh -Y user@hostname > > 'xeyes' is a good test if X will get passed over the remote > connection. > > As long as the remote host is set up correctly I don't think you > have to bother > with any PATH or .grass.bashrc / .grass.cshrc files. > > > Hamish > > > > > ______________________________________________________________________ > ______________ > Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s > user panel and lay it on us. http://surveylink.yahoo.com/gmrs/ > yahoo_panel_invite.asp?a=7 > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev ----- William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect From hmitaso at unity.ncsu.edu Tue Aug 21 19:51:33 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Tue Aug 21 19:51:38 2007 Subject: [GRASS-dev] nviz save state Message-ID: <1187718693.7899.3.camel@deliboz> It looks like the Save state functionality for nviz broke when the interface to nviz was updated. I am hoping that it requires just a small fix - Michael can you please check your changes to see what might have broken it? When saving state it complains as follows (I am not concerned about these because none of what it complains about needs to be saved) Diagnostic: invalid command name "Nviz_sdiff_save" -- Save procedure for panel sdiff may not be defined Diagnostic: invalid command name "Nviz_query_save" -- Save procedure for panel query may not be defined Diagnostic: invalid command name "Nviz_pick_save" -- Save procedure for panel pick may not be defined Diagnostic: invalid command name "Nviz_animation_save" -- Save procedure for panel animation may not be defined Diagnostic: invalid command name "Nviz_kanimator_save" -- Save procedure for panel kanimator may not be defined But the problem is when loading the saved state : [...] Diagnostic: wrong # args: should be "set varName ?newValue?" -- Load procedure for panel main may not be defined Diagnostic: invalid command name "Nviz_720 752_load" -- Load procedure for panel 720 752 may not be defined Diagnostic: invalid command name "Nviz_22.0_load" -- Load procedure for panel 22.0 may not be defined Diagnostic: invalid command name "Nviz_4.462_load" -- Load procedure for panel 4.462 may not be defined Diagnostic: invalid command name "Nviz_379.50_load" -- Load procedure for panel 379.50 may not be defined Diagnostic: invalid command name "Nviz_0.504 0.984_load" -- Load procedure for panel 0.504 0.984 may not be defined Diagnostic: invalid command name "Nviz_1_load" -- Load procedure for panel 1 may not be defined Diagnostic: invalid command name "Nviz_234.500000 234.500000 120.363991_load" -- Load procedure for panel 234.500000 234.500000 120.363991 may not be defined From rez at touchofmadness.com Tue Aug 21 21:15:48 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Tue Aug 21 21:16:04 2007 Subject: [GRASS-dev] BLAS/LAPACK (Part II) In-Reply-To: <9211715e0708201308p67fc89bak5dacfbce89c3467d@mail.gmail.com> References: <1187323784.20635.111.camel@dev64.localdomain> <46C95EEA.1040702@bergenheim.net> <20070820152018.211760@gmx.net> <20070820183254.GG28104@bartok.itc.it> <9211715e0708201308p67fc89bak5dacfbce89c3467d@mail.gmail.com> Message-ID: <1187723748.9951.47.camel@dev64.localdomain> On Mon, 2007-08-20 at 22:08 +0200, Daniel Bundala wrote: > Guys, > > It is quite interesting, but I have had plans to replace v.generalize > matrix code by "yours" library code. I have not studied G_matrix_* > code carefully, but it seems to me that it is superior. BLAS/LAPACK are vastly superior. I have a couple modules I'm working on that I've either used or in process of converting to use G_matrix_*()/G_vector_*() functions that call BLAS/LAPACK. I would also like to expand the usage of BLAS/LAPACK by making additional functions available (I suspect this may be beneficial to you, also). > Firstly, Soeren wrote that the current code is multithreaded. Soeren's code does not use BLAS/LAPACK. It probably should. > Secondly, someone mentioned, that it supports the sparse matrices. > Support of sparse matrices would increase the efficiency of > v.generalize since it uses only the sparse matrices. > Thirdly, Soeren mentioned that the current code supports many methods > my code doesnt support. To tell the truth, I have never heard about > many of them (Well, I am still (young) student...) > > The only thing I am missing in the current code is the direct access > to the elements of a matrix. But, this is quite dangerous and I really > doubt whether this is a good API-desing. > > On the other hand, it is true that the current code is quite obscure, > say. Also, it is tempting to replace fortran code by C code. > Therefore, my suggestons are: clean library code and replace the > current code by v.generalize code only if it is really faster. Some > benchmarks are probably required, but I doubt that my code beats > (optimized) library code. One way or the other, it doesn't really matter to me. I just don't want to have modules with dependency requirements that others do not. BLAS/LAPACK are superior, but there's no since having it around if nobody is going to use it. It just becomes clutter at that point. IMO, few will compile it into their build if only a few obscure modules use it; leaving those with more specific needs at a disadvantage. -- 73, de Brad KB8UYR/6 From michael.barton at asu.edu Tue Aug 21 21:14:04 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Aug 21 21:20:36 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: Message-ID: > > Hello Moritz, > Works for me starting it both those ways, and also from command-line. I > even tried make distclean and compiling from scratch in case there was > something I'd manually fixed that kept it working on my system. So I don't > know what could be up with yours. Maybe you have an old nviz.exe lying > around in your PATH somewhere that is getting picked up when the GUI runs > "nviz", instead of Glynn's new nviz.bat? > > A couple of side-notes though: > 1) In general the GUI is terrible at catching and reporting errors from > modules it calls in the background and this leads to cryptic error > messages or nothing happening all over the place. IMHO it is a really > pervasive problem that definitely needs fixed in the next GUI. Hopefully > it already is there (ISTR discussions about every call to a GRASS module > going through some other function where the error trapping could > presumably be added, to avoid code repetition). Actually, error trapping is pretty good in the GUI now, except for NVIZ (but which doesn't run much in the way of GRASS commands anyway). There are traps around all (or perhaps nearly all) GRASS commands that run through the GUI that will kick out any GRASS errors to the terminal or a message box. However, on top of that are GUI errors. TclTk does a pretty good job of reporting these, but they only make sense if you understand TclTk of course. At least they are not obscure error codes. > > 2) When the displayed layers start up in NVIZ the colour of the displayed > vector map isn't preserved. I'm guessing this is because it can't be > specified on the command-line, but perhaps the code that starts NVIZ using > the displayed layers should write a temporary NVIZ state file and then > start NVIZ with that file? I've no idea ho