From michael.barton at asu.edu Wed Nov 1 06:39:20 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Nov 1 06:39:42 2006 Subject: [GRASS-dev] Zooming issue in gis manager Message-ID: Before we make these changes, I'd like to reiterate again what is going on with a bit of visual display to better show the issues. 1. There is not a systematic, major inaccuracy from zooming the display in the GIS Manager. 2. This inaccuracy reported only occurs with interactive zooming when displaying a raster map so that the raster grid squares are much larger than the pixel size. That is, when you can see only a few grid squares in the display. 3. It affects the number of grid cells displayed, not the actual computational or display regions. 4. It is primarily (or likely entirely) a function of using g.region -a to align the display region to the raster grid at the current resolution. I originally did NOT use this flag, because I was concerned about potentially uncontrolled changes to zoom precision, but added this to the zooming a few months back at the request of others. Please note the screen shots links below to help document this issue. These pretty much reconstruct the original steps to show the problem, but without region alignment. First, I took out the -a switch from the g.region command in mapcanvas.tcl Then I interactively zoomed (zoom box) the spearfish erosion map to show 7 rows by 13 columns This is shown in I then selected "save current region to match display" to make the WIND file match the display region set interactively with the zoom. I next selected "display region settings" from the menu This can be seen in Next, I switched to query mode and clicked the NW and SE corners of the display This can also be seen in output.jpg. Note that the xy values match those in the region extents output (within the small error of a mouse click) Finally, I selected "zoom to current region" to redraw the screen and make the display match the WIND file This can be seen in Note that display1.jpg and display2.jpg are identical. ***************** The reported problem with displaying grid cells at high magnification is primarily or entirely a function of how g.region -a aligns the region with the raster grid cell boundaries. I don't know how this works internally and someone with C programming experience will have to deal with it if we want it to work differently So, what do we want to do? We can either have 1. All zooming is aligned with the cell borders, matching the current resolution, with the possible result of a bit of rounding error in the display when zoomed in to a point where the cells are very large compared to pixel size--due to the way that g.region -a works. OR 2. Zooming is NOT aligned with the cell borders and the current resolution. In this case, what you see is very close to the actual region extents when zoomed in to a point where the cells are very large compared to pixel size. This is how I originally had it. Note that if you are NOT zoomed in to a point where grid cells look very large compared with pixels (i.e., most the the time in most maps), then the displays appear identical whether the region is aligned to the cell borders or not. We cannot have it both ways given how g.region -a works. That is, the underlying zoom math is correct and the same in both cases, but can either zoom with g.region -a or with g.region (without the -a flag). Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Hamish > Date: Tue, 31 Oct 2006 15:13:43 +1300 > To: Maciej Sieczka > Cc: , , > > Subject: Re: [GRASS-dev] d.m/d.gis mysteries.. > > Maciej Sieczka wrote: >> I, personally, would even prefer d.m as the default GUI back, > > > with a mind to making long term users happy, and making the wxpython > development easier, I'd like to extend the GRASS_GUI variable. > > currently it is both a startup shell variable and a GRASS gisenv > variable. (if it exists, the former sets the latter at startup) > > currently you can do > > GRASS_GUI=text grass63 > or > grass63 -text > > to start with the command line one > > GRASS_GUI=tcltk grass63 > or > grass63 -gui > or > grass63 -tcltk > > to start with the Tcl/Tk startup + gis.m > > > > with this patch you can also do > > grass63 -oldgui # for d.m > > or > > GRASS_GUI=d.m grass63 > > or > > GRASS_GUI=gis.m grass63 > > or even > > # rename it to whatever the wxpython GUI will be called > GRASS_GUI=wxpython grass63 > > when wx becomes the default just switch "grass63 -gui" to that target. > > > grass remembers the last one you used and uses that as the default. > > > WRT, d.zoom & gis.m zooming- the x monitors and d.zoom have had more > than a decade of heavy use to become mature. gis.m has had barely 9 > months of developer testing to become mature. And even then, most of the > long-time developers who hold the bulk of the "institutional knowledge" > only work from the command line.... it is really great that it has come > so far so fast. > > the zooming stuff is tricky business- even after all this time d.zoom > still has some problems and is far from elegant. accurate rendering & > point placement is the bread and butter of a GIS though, so it'd be nice > to have everyone happy with gis.m in the long term. Folks will be > picking points off the screen and writing down coordinates for their > field sites. All the time spent now perfecting the design choices will > pay off well, I am sure. Even if only for when we do the wxPython > version we can pick the best choices the first time. > > > choices are good, > Hamish __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20061031/07702456/attachment.html From michael.barton at asu.edu Wed Nov 1 06:45:12 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Nov 1 06:45:29 2006 Subject: [GRASS-dev] call for last minute testers In-Reply-To: <454741CF.4040803@o2.pl> Message-ID: Not related to the TclTk 8.3 changes. The duplicate raster bug is due to some past changes that just showed up as problematic. I put a fix into the cvs this evening. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Maciej Sieczka > Date: Tue, 31 Oct 2006 13:30:07 +0100 > To: Hamish > Cc: Michael Barton , grass5 > Subject: Re: [GRASS-dev] call for last minute testers > > I don't know if this is related to the recent tcltk 8.3-compatibility > fixes, but there are 2 cases when the gis.m freezes, so that you have > to close it and start again to continue your work: > > A: > 1. add a raster > 2. duplicate it ('Duplicate layer') > 3. display -> error: "can't read "opt(2,1,mod)": no such element in > array" amd freeze; see the attached A.txt for details From glynn at gclements.plus.com Wed Nov 1 07:38:55 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Nov 1 07:40:43 2006 Subject: [GRASS-dev] Zooming issue in gis manager In-Reply-To: References: Message-ID: <17736.16639.94435.508993@cerise.gclements.plus.com> Michael Barton wrote: > The reported problem with displaying grid cells at high magnification is > primarily or entirely a function of how g.region -a aligns the region with > the raster grid cell boundaries. I don't know how this works internally and > someone with C programming experience will have to deal with it if we want > it to work differently window.ns_res = x; window.ew_res = x; if (flag.res_set->answer) { window.north = ceil(window.north/x) * x ; window.south = floor(window.south/x) * x ; window.east = ceil(window.east/x) * x ; window.west = floor(window.west/x) * x ; } IOW, it essentially shifts the cell grid such that the origin of the coordinate system lies on the intersection between four cells. Given that the origin for most coordinate systems is a completely arbitrary location arising from various completely arbitrary constants (e.g. whichever round numbers where chosen as the false easting and northing), I have no idea what the intended purpose of the -a flag is, but I'm fairly sure that it shouldn't be used by default. -- Glynn Clements From tutey at o2.pl Wed Nov 1 07:59:26 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Nov 1 07:59:44 2006 Subject: [GRASS-dev] 6.2.0 release announcement fixes In-Reply-To: <4547D0A1.1040308@gmx.de> References: <44F6F44F.5000907@o2.pl> <20061027154502.08899edb.hamish_nospam@yahoo.com> <20061029192948.3763bd52.hamish_nospam@yahoo.com> <20061029203647.GB1135@bartok.itc.it> <4547D0A1.1040308@gmx.de> Message-ID: <454845CE.5020805@o2.pl> S?ren Gebbert wrote: > v.out.ascii prints also the header of a vector > (format=standard), the md5 > checksums differs from output to output if the creation date is set. > So i need to implement a header suppression flag to v.out.ascii to > generate "stable" md5 checksums. v.out.ascii | awk 'NR>10' | ... ? > But this have to wait, im very busy right now .... . :( Maciek From otto.dassau at gmx.de Wed Nov 1 09:32:44 2006 From: otto.dassau at gmx.de (Otto Dassau) Date: Wed Nov 1 09:33:05 2006 Subject: [GRASS-dev] call for last minute testers In-Reply-To: References: <20061031140513.315384ac@localhost.localdomain> Message-ID: <20061101093244.20b25bc6@localhost.localdomain> On Tue, 31 Oct 2006 12:18:38 -0700 Michael Barton wrote: > Otto, > > I had sent in the wrong version of a georectifier update last night. I sent > in a new one this morning to Markus, who put it into 6.2. I just added it to > 6.3 a moment ago. I don't know if this fixes the problem you are having, but > you might test it. Thanks for the info. Hi Michael, Thanks for the fix. I just tested it with the new snapshot from http://grass.itc.it/grass62/source/snapshot/ but with the same error. And another problem occurs. I am not able to create/edit a group anymore. The second button only works for vector rectification but not for raster. regards, Otto > Michale > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics and Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > > From: Otto Dassau > > Date: Tue, 31 Oct 2006 14:05:13 +0100 > > To: > > Subject: Re: [GRASS-dev] call for last minute testers > > > > On Tue, 31 Oct 2006 23:40:13 +1300 > > Hamish wrote: > > > >> Hi, > >> > >> Michael & myself have just applied some last minute patches to gis.m to > >> make it compatible with tcl/tk 8.3. As this will be released with 6.2.0 > >> without much (any) testing, if everyone could quickly update gis.m in > >> their cvs (6.3 is probably fine, 6.2 branch is better- it's the same), > >> make, and double check that we haven't broken anything? (main toolbar > >> and the georectifyer canvas toolbar) > > > > Hi, > > > > using the "clear all GPC entries" button (in the georectifyer) after setting > > various GCPs only clears the first 2 columns of the first line, but the > > forward > > and backward errors remain with following error message (command name below > > is the RMS error in line 1 third col): > > > > invalid command name "0.590568" > > invalid command name "0.590568" > > while executing > > "$fwd_error($gcpnum) delete 0 end" > > (procedure "GRMap::cleargcp" line 14) > > invoked from within > > "GRMap::cleargcp" > > ("uplevel" body line 1) > > invoked from within > > "uplevel \#0 $cmd" > > (procedure "Button::_release" line 18) > > invoked from within > > "Button::_release .gcpwin.mf.topf.tb0.bbox1.b1" > > (command bound to event > > > I tested with the 6.2 snapshot. Maybe someone can reproduce this? > > > > regards, > > Otto > > > >> thanks a lot, > >> Hamish > > From otto.dassau at gmx.de Wed Nov 1 10:58:48 2006 From: otto.dassau at gmx.de (Otto Dassau) Date: Wed Nov 1 10:59:03 2006 Subject: [GRASS-dev] call for last minute testers In-Reply-To: <20061101093244.20b25bc6@localhost.localdomain> References: <20061031140513.315384ac@localhost.localdomain> <20061101093244.20b25bc6@localhost.localdomain> Message-ID: <20061101105848.098acfaa@localhost.localdomain> On Wed, 1 Nov 2006 09:32:44 +0100 Otto Dassau wrote: > On Tue, 31 Oct 2006 12:18:38 -0700 > Michael Barton wrote: > > > Otto, > > > > I had sent in the wrong version of a georectifier update last night. I sent > > in a new one this morning to Markus, who put it into 6.2. I just added it to > > 6.3 a moment ago. I don't know if this fixes the problem you are having, but > > you might test it. Thanks for the info. > > Hi Michael, > > Thanks for the fix. I just tested it with the new snapshot from > http://grass.itc.it/grass62/source/snapshot/ but with the same error. > > And another problem occurs. I am not able to create/edit a group anymore. The > second button only works for vector rectification but not for raster. I also compiled grass-6.2.0.tar.gz but get the same error as with the latest 6.2 snapshot. regards, Otto > regards, > Otto > > > > Michale > > __________________________________________ > > Michael Barton, Professor of Anthropology > > School of Human Evolution & Social Change > > Center for Social Dynamics and Complexity > > Arizona State University > > > > phone: 480-965-6213 > > fax: 480-965-7671 > > www: http://www.public.asu.edu/~cmbarton > > > > > > > From: Otto Dassau > > > Date: Tue, 31 Oct 2006 14:05:13 +0100 > > > To: > > > Subject: Re: [GRASS-dev] call for last minute testers > > > > > > On Tue, 31 Oct 2006 23:40:13 +1300 > > > Hamish wrote: > > > > > >> Hi, > > >> > > >> Michael & myself have just applied some last minute patches to gis.m to > > >> make it compatible with tcl/tk 8.3. As this will be released with 6.2.0 > > >> without much (any) testing, if everyone could quickly update gis.m in > > >> their cvs (6.3 is probably fine, 6.2 branch is better- it's the same), > > >> make, and double check that we haven't broken anything? (main toolbar > > >> and the georectifyer canvas toolbar) > > > > > > Hi, > > > > > > using the "clear all GPC entries" button (in the georectifyer) after setting > > > various GCPs only clears the first 2 columns of the first line, but the > > > forward > > > and backward errors remain with following error message (command name below > > > is the RMS error in line 1 third col): > > > > > > invalid command name "0.590568" > > > invalid command name "0.590568" > > > while executing > > > "$fwd_error($gcpnum) delete 0 end" > > > (procedure "GRMap::cleargcp" line 14) > > > invoked from within > > > "GRMap::cleargcp" > > > ("uplevel" body line 1) > > > invoked from within > > > "uplevel \#0 $cmd" > > > (procedure "Button::_release" line 18) > > > invoked from within > > > "Button::_release .gcpwin.mf.topf.tb0.bbox1.b1" > > > (command bound to event > > > > > I tested with the 6.2 snapshot. Maybe someone can reproduce this? > > > > > > regards, > > > Otto > > > > > >> thanks a lot, > > >> Hamish > > > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- From paul-grass at stjohnspoint.co.uk Wed Nov 1 13:13:35 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Wed Nov 1 13:13:42 2006 Subject: [GRASS-dev] lib/pngdriver Mingw compile error In-Reply-To: <17735.52557.212969.241282@cerise.gclements.plus.com> References: <17734.49068.69597.651020@cerise.gclements.plus.com> <17735.52557.212969.241282@cerise.gclements.plus.com> Message-ID: On Tue, 31 Oct 2006, Glynn Clements wrote: > Paul Kelly wrote: > >> Next problem is this one here: >> [...] >> OBJ.i686-pc-mingw32/main.o(.text+0x188): In function `main': >> c:/grass/grass6/display/drivers/PNG/main.c:43: undefined reference to `LIB_main' >> >> collect2: ld returned 1 exit status >> make: *** [/c/grass/grass6/dist.i686-pc-mingw32/driver/PNG] Error 1 >> sh-2.04$ >> >> LIB_main() should be defined in libgrass_driver, right? > > Right; lib/driver/main.c. > >> Bit lost on this > > Same here. As it's linking with -lgrass_driver, I have no idea why you > are getting that error. Can you use nm or dlltool to check that the > symbol is actually present in libgrass_driver. It wasn't there! I think the problem is this bit in lib/driver/Makefile: ifneq ($(HAVE_SOCKET),) LIB_OBJS += \ main.o\ command.o\ connect_fifo.o\ connect_sock.o endif $HAVE_SOCKET is empty because the configure script isn't detecting sockets properly. This page: http://www.mingw.org/MinGWiki/index.php/sockets appears to give some useful information on what needs done but I'm not sure if some or any of it has been done already in other parts of GRASS? E.g. how have some people got native Windows GRASS working and not come across this before? Paul From michael.barton at asu.edu Wed Nov 1 15:59:53 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Nov 1 16:00:01 2006 Subject: [GRASS-dev] Zooming issue in gis manager In-Reply-To: <17736.16639.94435.508993@cerise.gclements.plus.com> Message-ID: This sounds like there is no good reason to set this for interactive zooming by default. If someone wants to use this feature, they could explicitly set it in g.region. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Glynn Clements > Date: Wed, 1 Nov 2006 06:38:55 +0000 > To: Michael Barton > Cc: grass-dev > Subject: Re: [GRASS-dev] Zooming issue in gis manager > > > Michael Barton wrote: > >> The reported problem with displaying grid cells at high magnification is >> primarily or entirely a function of how g.region -a aligns the region with >> the raster grid cell boundaries. I don't know how this works internally and >> someone with C programming experience will have to deal with it if we want >> it to work differently > > window.ns_res = x; > window.ew_res = x; > > if (flag.res_set->answer) { > window.north = ceil(window.north/x) * x ; > window.south = floor(window.south/x) * x ; > window.east = ceil(window.east/x) * x ; > window.west = floor(window.west/x) * x ; > } > > IOW, it essentially shifts the cell grid such that the origin of the > coordinate system lies on the intersection between four cells. > > Given that the origin for most coordinate systems is a completely > arbitrary location arising from various completely arbitrary constants > (e.g. whichever round numbers where chosen as the false easting and > northing), I have no idea what the intended purpose of the -a flag is, > but I'm fairly sure that it shouldn't be used by default. > > -- > Glynn Clements From tutey at o2.pl Wed Nov 1 16:47:05 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Nov 1 16:47:10 2006 Subject: [GRASS-dev] Zooming issue in gis manager In-Reply-To: References: Message-ID: <4548C179.8080801@o2.pl> Michael Barton wrote: > This sounds like there is no good reason to set this for interactive zooming > by default. If someone wants to use this feature, they could explicitly set > it in g.region. Glynn, gis.m zoom tools should preserve the resolution while zooming, and set the region extents properly. That's because there are tools in gis.m to set WIND to match gis.m display, and to make the display match the current region - thus these two operations should not lead to region or display settings the user not wanted. The problem is that they do, because: 1. If -a is not used in g.region calls in mapcanvas.tcl (like it was originally, few months ago), the gis.m zoom tools don't preserve the resolution while zooming; and I don't see a reason why the resolution should change while zooming, but do I see obvious reason why it shouldn't. Thus, I suggested a solution: use the g.region with -a. It fixed the resolution issue. 2. But, now it showed that if g.region -a is used in mapcanvas.tcl, the region extent is often not set properly. This is not acceptable either, is it? Removing the -a flag should fix issue 2, but it will bring the issue 1 back. What do we do then? Maciek From neteler at itc.it Wed Nov 1 18:13:48 2006 From: neteler at itc.it (Markus Neteler) Date: Wed Nov 1 18:13:50 2006 Subject: [GRASS-dev] gis.m fix commonlayer.tcl In-Reply-To: References: <20061031231041.GA10156@bartok.itc.it> Message-ID: <20061101171348.GD14404@bartok.itc.it> FWD to the list... On Tue, Oct 31, 2006 at 04:40:59PM -0700, Michael Barton wrote: > I think that I fixed this! I just committed it to the cvs. Could you see if > it works for you too? The updated file is commonlayer.tcl. > > The test is to add a raster layer and associate it with a file, then > duplicate the raster layer. Try to display. If it works, I've fixed it. > > Now if I just didn't break something else in the process... > > > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics and Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > > From: Markus Neteler > > Date: Wed, 1 Nov 2006 00:10:41 +0100 > > To: Michael Barton > > Subject: Re: need help in committing > > > > Michael, > > > > we can always get out 6.2.1 if this affects the 6.2.x > > as well. > > > > Happy hacking and thanks for your patience, > > Markus > > > > On Tue, Oct 31, 2006 at 03:51:49PM -0700, Michael Barton wrote: > >> Many congratulations! > >> > >> Thanks for the help in getting some things fixed. > >> > >> It turns out that the raster duplication error is the tip of a much larger > >> iceberg that resulted from something Cedric did sometime back. It was a good > >> idea, but led to problems that didn't surface until now. Simply a result of > >> a GUI being much more tightly coupled than many independent modules. I need > >> to think about the best way to deal with it. > >> > >> Michael From otto.dassau at gmx.de Wed Nov 1 19:34:11 2006 From: otto.dassau at gmx.de (Otto Dassau) Date: Wed Nov 1 19:34:15 2006 Subject: [GRASS-dev] gis.m fix commonlayer.tcl In-Reply-To: <20061101171348.GD14404@bartok.itc.it> References: <20061031231041.GA10156@bartok.itc.it> <20061101171348.GD14404@bartok.itc.it> Message-ID: <20061101193411.75f70b07@localhost.localdomain> On Wed, 1 Nov 2006 18:13:48 +0100 Markus Neteler wrote: > FWD to the list... > > On Tue, Oct 31, 2006 at 04:40:59PM -0700, Michael Barton wrote: > > I think that I fixed this! I just committed it to the cvs. Could you see if > > it works for you too? The updated file is commonlayer.tcl. > > > > The test is to add a raster layer and associate it with a file, then > > duplicate the raster layer. Try to display. If it works, I've fixed it. yes it is working now! Otto > > Now if I just didn't break something else in the process... > > > > Michael > > __________________________________________ > > Michael Barton, Professor of Anthropology > > School of Human Evolution & Social Change > > Center for Social Dynamics and Complexity > > Arizona State University > > > > phone: 480-965-6213 > > fax: 480-965-7671 > > www: http://www.public.asu.edu/~cmbarton > > > > > > > From: Markus Neteler > > > Date: Wed, 1 Nov 2006 00:10:41 +0100 > > > To: Michael Barton > > > Subject: Re: need help in committing > > > > > > Michael, > > > > > > we can always get out 6.2.1 if this affects the 6.2.x > > > as well. > > > > > > Happy hacking and thanks for your patience, > > > Markus > > > > > > On Tue, Oct 31, 2006 at 03:51:49PM -0700, Michael Barton wrote: > > >> Many congratulations! > > >> > > >> Thanks for the help in getting some things fixed. > > >> > > >> It turns out that the raster duplication error is the tip of a much larger > > >> iceberg that resulted from something Cedric did sometime back. It was a good > > >> idea, but led to problems that didn't surface until now. Simply a result of > > >> a GUI being much more tightly coupled than many independent modules. I need > > >> to think about the best way to deal with it. > > >> > > >> Michael > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- From michael.barton at asu.edu Wed Nov 1 19:38:19 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Nov 1 19:38:27 2006 Subject: [GRASS-dev] georectifier fixes In-Reply-To: <20061101160909.5b846cdd@localhost.localdomain> Message-ID: I just committed a set of fixes to the georectifier. This should fix all reported bugs. (can't speak for new ones, but hopefully there aren't any). Please test. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Otto Dassau > Date: Wed, 1 Nov 2006 16:09:09 +0100 > To: Michael Barton > Subject: Re: [GRASS-dev] call for last minute testers > > On Wed, 01 Nov 2006 07:53:09 -0700 > Michael Barton wrote: > >> Thanks. I'll check it out. You can always edit a group by running i.group >> from the xy location, but it ought to work from the georectifier. > > thanks a lot! > > Otto > > >> Michael >> __________________________________________ >> Michael Barton, Professor of Anthropology >> School of Human Evolution & Social Change >> Center for Social Dynamics & Complexity >> Arizona State University >> >> phone: 480-965-6213 >> fax: 480-965-7671 >> www: http://www.public.asu.edu/~cmbarton >> >> >> >>> From: Otto Dassau >>> Date: Wed, 1 Nov 2006 09:32:44 +0100 >>> To: Michael Barton >>> Cc: >>> Subject: Re: [GRASS-dev] call for last minute testers >>> >>> On Tue, 31 Oct 2006 12:18:38 -0700 >>> Michael Barton wrote: >>> >>>> Otto, >>>> >>>> I had sent in the wrong version of a georectifier update last night. I sent >>>> in a new one this morning to Markus, who put it into 6.2. I just added it > to >>>> 6.3 a moment ago. I don't know if this fixes the problem you are having, > but >>>> you might test it. Thanks for the info. >>> >>> Hi Michael, >>> >>> Thanks for the fix. I just tested it with the new snapshot from >>> http://grass.itc.it/grass62/source/snapshot/ but with the same error. >>> >>> And another problem occurs. I am not able to create/edit a group anymore. > The >>> second button only works for vector rectification but not for raster. >>> >>> regards, >>> Otto >>> >>> >>>> Michale >>>> __________________________________________ >>>> Michael Barton, Professor of Anthropology >>>> School of Human Evolution & Social Change >>>> Center for Social Dynamics and Complexity >>>> Arizona State University >>>> >>>> phone: 480-965-6213 >>>> fax: 480-965-7671 >>>> www: http://www.public.asu.edu/~cmbarton >>>> >>>> >>>>> From: Otto Dassau >>>>> Date: Tue, 31 Oct 2006 14:05:13 +0100 >>>>> To: >>>>> Subject: Re: [GRASS-dev] call for last minute testers >>>>> >>>>> On Tue, 31 Oct 2006 23:40:13 +1300 >>>>> Hamish wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Michael & myself have just applied some last minute patches to gis.m to >>>>>> make it compatible with tcl/tk 8.3. As this will be released with 6.2.0 >>>>>> without much (any) testing, if everyone could quickly update gis.m in >>>>>> their cvs (6.3 is probably fine, 6.2 branch is better- it's the same), >>>>>> make, and double check that we haven't broken anything? (main toolbar >>>>>> and the georectifyer canvas toolbar) >>>>> >>>>> Hi, >>>>> >>>>> using the "clear all GPC entries" button (in the georectifyer) after > setting >>>>> various GCPs only clears the first 2 columns of the first line, but the >>>>> forward >>>>> and backward errors remain with following error message (command name > below >>>>> is the RMS error in line 1 third col): >>>>> >>>>> invalid command name "0.590568" >>>>> invalid command name "0.590568" >>>>> while executing >>>>> "$fwd_error($gcpnum) delete 0 end" >>>>> (procedure "GRMap::cleargcp" line 14) >>>>> invoked from within >>>>> "GRMap::cleargcp" >>>>> ("uplevel" body line 1) >>>>> invoked from within >>>>> "uplevel \#0 $cmd" >>>>> (procedure "Button::_release" line 18) >>>>> invoked from within >>>>> "Button::_release .gcpwin.mf.topf.tb0.bbox1.b1" >>>>> (command bound to event >>>> >>>>> I tested with the 6.2 snapshot. Maybe someone can reproduce this? >>>>> >>>>> regards, >>>>> Otto >>>>> >>>>>> thanks a lot, >>>>>> Hamish >>>>> >>> >> > > > -- > From michael.barton at asu.edu Wed Nov 1 19:40:01 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Nov 1 19:41:42 2006 Subject: [GRASS-dev] FW: Labeling bug fix In-Reply-To: Message-ID: I fixed this PS labeling bug and committed this to the cvs this morning. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > > ------ Forwarded Message > From: Maciej Sieczka > Date: Tue, 31 Oct 2006 13:30:07 +0100 > To: Hamish > Cc: Michael Barton , grass5 > Subject: Re: [GRASS-dev] call for last minute testers > > B: > 1. press 'Add postcript labels layer (using v.labels file)' > 2. display -> error: "couldn't open > "/home/grassdata/spearfish60/sieczka/paint/labels/": no such file or > directory" and a freeze; see the attached B.txt for details > > ------ End of Forwarded Message > From michael.barton at asu.edu Wed Nov 1 20:15:06 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Nov 1 20:15:11 2006 Subject: [GRASS-dev] Zooming issue in gis manager In-Reply-To: <4548C179.8080801@o2.pl> Message-ID: To clarify a bit... In the "standard" mode, resolution and geometry are preserved by the display in all zooming. In fact, there is no way to change resolution in this mode, although you can interactively change the size and shape of a display region by zooming in or out. In the "explore" mode that Cedric Shock introduced, neither geometry nor resolution is preserved in the display in order to provide quick, full-screen views of maps. The display resolution changes to keep it proportional to the number of pixels and the map always fills the display. Users can switch back and forth between modes with the click of a button. In all cases, display resolution and geometry have no effects at all on computational geometry or region, although settings from the display region can be copied to the computational region and vice versa if the users wants to do so. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Maciej Sieczka > Date: Wed, 01 Nov 2006 16:47:05 +0100 > To: Glynn Clements > Cc: Michael Barton , grass-dev > > Subject: Re: [GRASS-dev] Zooming issue in gis manager > > Michael Barton wrote: >> This sounds like there is no good reason to set this for interactive zooming >> by default. If someone wants to use this feature, they could explicitly set >> it in g.region. > > Glynn, > > gis.m zoom tools should preserve the resolution while zooming, and set > the region extents properly. That's because there are tools in gis.m to > set WIND to match gis.m display, and to make the display match the > current region - thus these two operations should not lead to region or > display settings the user not wanted. The problem is that they do, because: > > 1. If -a is not used in g.region calls in mapcanvas.tcl (like it was > originally, few months ago), the gis.m zoom tools don't preserve the > resolution while zooming; and I don't see a reason why the resolution > should change while zooming, but do I see obvious reason why it > shouldn't. Thus, I suggested a solution: use the g.region with -a. It > fixed the resolution issue. > > 2. But, now it showed that if g.region -a is used in mapcanvas.tcl, the > region extent is often not set properly. This is not acceptable either, > is it? > > Removing the -a flag should fix issue 2, but it will bring the issue 1 > back. What do we do then? > > Maciek > > From michael.barton at asu.edu Wed Nov 1 20:15:40 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Nov 1 20:15:47 2006 Subject: [GRASS-dev] gis.m fix commonlayer.tcl In-Reply-To: <20061101193411.75f70b07@localhost.localdomain> Message-ID: Thanks for the confirmation. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Otto Dassau > Date: Wed, 1 Nov 2006 19:34:11 +0100 > To: > Subject: Re: [GRASS-dev] gis.m fix commonlayer.tcl > > On Wed, 1 Nov 2006 18:13:48 +0100 > Markus Neteler wrote: > >> FWD to the list... >> >> On Tue, Oct 31, 2006 at 04:40:59PM -0700, Michael Barton wrote: >>> I think that I fixed this! I just committed it to the cvs. Could you see if >>> it works for you too? The updated file is commonlayer.tcl. >>> >>> The test is to add a raster layer and associate it with a file, then >>> duplicate the raster layer. Try to display. If it works, I've fixed it. > > yes it is working now! > > Otto > >>> Now if I just didn't break something else in the process... >>> >>> Michael >>> __________________________________________ >>> Michael Barton, Professor of Anthropology >>> School of Human Evolution & Social Change >>> Center for Social Dynamics and Complexity >>> Arizona State University >>> >>> phone: 480-965-6213 >>> fax: 480-965-7671 >>> www: http://www.public.asu.edu/~cmbarton >>> >>> >>>> From: Markus Neteler >>>> Date: Wed, 1 Nov 2006 00:10:41 +0100 >>>> To: Michael Barton >>>> Subject: Re: need help in committing >>>> >>>> Michael, >>>> >>>> we can always get out 6.2.1 if this affects the 6.2.x >>>> as well. >>>> >>>> Happy hacking and thanks for your patience, >>>> Markus >>>> >>>> On Tue, Oct 31, 2006 at 03:51:49PM -0700, Michael Barton wrote: >>>>> Many congratulations! >>>>> >>>>> Thanks for the help in getting some things fixed. >>>>> >>>>> It turns out that the raster duplication error is the tip of a much > larger >>>>> iceberg that resulted from something Cedric did sometime back. It was a > good >>>>> idea, but led to problems that didn't surface until now. Simply a result > of >>>>> a GUI being much more tightly coupled than many independent modules. I > need >>>>> to think about the best way to deal with it. >>>>> >>>>> Michael >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev >> > > > -- > > From otto.dassau at gmx.de Wed Nov 1 20:20:21 2006 From: otto.dassau at gmx.de (Otto Dassau) Date: Wed Nov 1 20:20:24 2006 Subject: [GRASS-dev] Re: georectifier fixes In-Reply-To: References: <20061101160909.5b846cdd@localhost.localdomain> Message-ID: <20061101202021.136274d6@localhost.localdomain> On Wed, 01 Nov 2006 11:38:19 -0700 Michael Barton wrote: > I just committed a set of fixes to the georectifier. This should fix all > reported bugs. (can't speak for new ones, but hopefully there aren't any). > Please test. the "clear all GPC entries" button is working now - thanks a lot! It deletes all entries. Would it be possible that it depends on wether a GCP is used (selected) or not? I think that would be useful, after choosing the best GCPs I could delete the rest very easily. The second error still exists. The create/edit a group button doesn't work. kind regards, Otto > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics and Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > > From: Otto Dassau > > Date: Wed, 1 Nov 2006 16:09:09 +0100 > > To: Michael Barton > > Subject: Re: [GRASS-dev] call for last minute testers > > > > On Wed, 01 Nov 2006 07:53:09 -0700 > > Michael Barton wrote: > > > >> Thanks. I'll check it out. You can always edit a group by running i.group > >> from the xy location, but it ought to work from the georectifier. > > > > thanks a lot! > > > > Otto > > > > > >> Michael > >> __________________________________________ > >> Michael Barton, Professor of Anthropology > >> School of Human Evolution & Social Change > >> Center for Social Dynamics & Complexity > >> Arizona State University > >> > >> phone: 480-965-6213 > >> fax: 480-965-7671 > >> www: http://www.public.asu.edu/~cmbarton > >> > >> > >> > >>> From: Otto Dassau > >>> Date: Wed, 1 Nov 2006 09:32:44 +0100 > >>> To: Michael Barton > >>> Cc: > >>> Subject: Re: [GRASS-dev] call for last minute testers > >>> > >>> On Tue, 31 Oct 2006 12:18:38 -0700 > >>> Michael Barton wrote: > >>> > >>>> Otto, > >>>> > >>>> I had sent in the wrong version of a georectifier update last night. I sent > >>>> in a new one this morning to Markus, who put it into 6.2. I just added it > > to > >>>> 6.3 a moment ago. I don't know if this fixes the problem you are having, > > but > >>>> you might test it. Thanks for the info. > >>> > >>> Hi Michael, > >>> > >>> Thanks for the fix. I just tested it with the new snapshot from > >>> http://grass.itc.it/grass62/source/snapshot/ but with the same error. > >>> > >>> And another problem occurs. I am not able to create/edit a group anymore. > > The > >>> second button only works for vector rectification but not for raster. > >>> > >>> regards, > >>> Otto > >>> > >>> > >>>> Michale > >>>> __________________________________________ > >>>> Michael Barton, Professor of Anthropology > >>>> School of Human Evolution & Social Change > >>>> Center for Social Dynamics and Complexity > >>>> Arizona State University > >>>> > >>>> phone: 480-965-6213 > >>>> fax: 480-965-7671 > >>>> www: http://www.public.asu.edu/~cmbarton > >>>> > >>>> > >>>>> From: Otto Dassau > >>>>> Date: Tue, 31 Oct 2006 14:05:13 +0100 > >>>>> To: > >>>>> Subject: Re: [GRASS-dev] call for last minute testers > >>>>> > >>>>> On Tue, 31 Oct 2006 23:40:13 +1300 > >>>>> Hamish wrote: > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> Michael & myself have just applied some last minute patches to gis.m to > >>>>>> make it compatible with tcl/tk 8.3. As this will be released with 6.2.0 > >>>>>> without much (any) testing, if everyone could quickly update gis.m in > >>>>>> their cvs (6.3 is probably fine, 6.2 branch is better- it's the same), > >>>>>> make, and double check that we haven't broken anything? (main toolbar > >>>>>> and the georectifyer canvas toolbar) > >>>>> > >>>>> Hi, > >>>>> > >>>>> using the "clear all GPC entries" button (in the georectifyer) after > > setting > >>>>> various GCPs only clears the first 2 columns of the first line, but the > >>>>> forward > >>>>> and backward errors remain with following error message (command name > > below > >>>>> is the RMS error in line 1 third col): > >>>>> > >>>>> invalid command name "0.590568" > >>>>> invalid command name "0.590568" > >>>>> while executing > >>>>> "$fwd_error($gcpnum) delete 0 end" > >>>>> (procedure "GRMap::cleargcp" line 14) > >>>>> invoked from within > >>>>> "GRMap::cleargcp" > >>>>> ("uplevel" body line 1) > >>>>> invoked from within > >>>>> "uplevel \#0 $cmd" > >>>>> (procedure "Button::_release" line 18) > >>>>> invoked from within > >>>>> "Button::_release .gcpwin.mf.topf.tb0.bbox1.b1" > >>>>> (command bound to event > >>>> > >>>>> I tested with the 6.2 snapshot. Maybe someone can reproduce this? > >>>>> > >>>>> regards, > >>>>> Otto > >>>>> > >>>>>> thanks a lot, > >>>>>> Hamish > >>>>> > >>> > >> > > > > > > -- > > > -- From michael.barton at asu.edu Wed Nov 1 20:32:39 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Nov 1 20:32:49 2006 Subject: [GRASS-dev] Re: georectifier fixes In-Reply-To: <20061101202021.136274d6@localhost.localdomain> Message-ID: Otto, The idea about clearing all unchecked gcp's is easy to implement and sounds very useful. It is odd about the i.group problem. When I click the creat/edit group button, it switches to the xy location/mapset and runs i.group on my computer. What happens on yours? Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Otto Dassau > Date: Wed, 1 Nov 2006 20:20:21 +0100 > To: Michael Barton > Cc: Hamish , GRASS developers list > > Subject: Re: georectifier fixes > > On Wed, 01 Nov 2006 11:38:19 -0700 > Michael Barton wrote: >> I just committed a set of fixes to the georectifier. This should fix all >> reported bugs. (can't speak for new ones, but hopefully there aren't any). >> Please test. > > the "clear all GPC entries" button is working now - thanks a lot! > It deletes all entries. Would it be possible that it depends on wether a GCP > is > used (selected) or not? I think that would be useful, after choosing the best > GCPs I could delete the rest very easily. > > The second error still exists. The create/edit a group button doesn't work. > > kind regards, > Otto From otto.dassau at gmx.de Wed Nov 1 21:09:52 2006 From: otto.dassau at gmx.de (Otto Dassau) Date: Wed Nov 1 21:09:58 2006 Subject: [GRASS-dev] Re: georectifier fixes In-Reply-To: References: <20061101202021.136274d6@localhost.localdomain> Message-ID: <20061101210952.6afc8c6a@localhost.localdomain> Hi, On Wed, 01 Nov 2006 12:32:39 -0700 Michael Barton wrote: > Otto, > > The idea about clearing all unchecked gcp's is easy to implement and sounds > very useful. > > It is odd about the i.group problem. When I click the creat/edit group > button, it switches to the xy location/mapset and runs i.group on my > computer. What happens on yours? nothing, not even an error. I have a debian testing and compile GRASS with --with-tcltk-includes=/usr/include/tcl8.4. I don't know why it doesn't work. Maybe we should wait for someone else with debian testing who can try. Maybe I do something wrong. thanks Otto > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics and Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > > From: Otto Dassau > > Date: Wed, 1 Nov 2006 20:20:21 +0100 > > To: Michael Barton > > Cc: Hamish , GRASS developers list > > > > Subject: Re: georectifier fixes > > > > On Wed, 01 Nov 2006 11:38:19 -0700 > > Michael Barton wrote: > >> I just committed a set of fixes to the georectifier. This should fix all > >> reported bugs. (can't speak for new ones, but hopefully there aren't any). > >> Please test. > > > > the "clear all GPC entries" button is working now - thanks a lot! > > It deletes all entries. Would it be possible that it depends on wether a GCP > > is > > used (selected) or not? I think that would be useful, after choosing the best > > GCPs I could delete the rest very easily. > > > > The second error still exists. The create/edit a group button doesn't work. > > > > kind regards, > > Otto > -- From glynn at gclements.plus.com Wed Nov 1 21:39:02 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Nov 1 21:39:04 2006 Subject: [GRASS-dev] lib/pngdriver Mingw compile error In-Reply-To: References: <17734.49068.69597.651020@cerise.gclements.plus.com> <17735.52557.212969.241282@cerise.gclements.plus.com> Message-ID: <17737.1510.96961.948565@cerise.gclements.plus.com> Paul Kelly wrote: > >> Next problem is this one here: > >> > [...] > >> OBJ.i686-pc-mingw32/main.o(.text+0x188): In function `main': > >> c:/grass/grass6/display/drivers/PNG/main.c:43: undefined reference to `LIB_main' > >> > >> collect2: ld returned 1 exit status > >> make: *** [/c/grass/grass6/dist.i686-pc-mingw32/driver/PNG] Error 1 > >> sh-2.04$ > >> > >> LIB_main() should be defined in libgrass_driver, right? > > > > Right; lib/driver/main.c. > > > >> Bit lost on this > > > > Same here. As it's linking with -lgrass_driver, I have no idea why you > > are getting that error. Can you use nm or dlltool to check that the > > symbol is actually present in libgrass_driver. > > It wasn't there! I think the problem is this bit in lib/driver/Makefile: > ifneq ($(HAVE_SOCKET),) > LIB_OBJS += \ > main.o\ > command.o\ > connect_fifo.o\ > connect_sock.o > endif Oops. I forgot to mention that the display drivers simply won't compile on native Windows. I know that, but for some reason it didn't register when I was writing my reply. In my previous message, I mentioned: > That still leaves one more problem: > > 5. Native windows doesn't support PF_LOCAL (Unix-domain) sockets. This is the problem. > $HAVE_SOCKET is empty because the configure script isn't detecting sockets > properly. This page: http://www.mingw.org/MinGWiki/index.php/sockets > appears to give some useful information on what needs done but I'm not > sure if some or any of it has been done already in other parts of GRASS? > E.g. how have some people got native Windows GRASS working and not come > across this before? By ignoring any errors related to the drivers. Drivers don't work on native Windows; at all. That's why you have to use gis.m, which uses direct (driver-less) rendering. -- Glynn Clements From paul-grass at stjohnspoint.co.uk Wed Nov 1 21:48:00 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Wed Nov 1 21:48:03 2006 Subject: [GRASS-dev] Windows-style Pathnames Message-ID: While experimenting with native Windows GRASS I was having loads of problems getting anything to work at all because the GISDBASE path read from the GISRC file was being corrupted in some strange way. Eventually tracked it down to lots of MinGW-specific hacks in lib/gis/env.c. When I removed them all everything (that I've tried so far: text-based startup and quite a few different modules) worked fine. Really! I've included the patch that removes them below at the bottom of this e-mail. It appears to contain lots of stuff about prepending and stripping the hardcoded path to an Msys installation - what is that all about? Surely: 1) GRASS may be installed other places than under the Msys root 2) The correct solution is to pass the correct Windows-style path to whichever functions need it, rather than hacking about with it in the GIS library functions. OK maybe I've missed something but it really doesn't make sense to me and seems like (from what I can see) to be fixing the problem in the wrong place? There's lots of other MinGW hacks and ifdefs all over the place that look very dubious to me. An example is this one in lib/gis/parser.c: error = 0 ; need_first_opt = 1 ; i = strlen(pgm_name = argv[0]) ; while (--i >= 0) { #ifdef __MINGW32__ if (pgm_name[i] == '/' || pgm_name[i] == '\\') #else if (pgm_name[i] == '/') #endif { pgm_name += i+1; break; } } It looks to me like pgm_name[i] is the first character in an array, so how does it make sense to compare it to a two-character string? And if it is correct, why the #ifdef anyway? Why not do the logical or comparison on all platforms? I think the aim should be to try and find a way of doing things that works on all platforms, rather than putting in platform-specific bits like this. It is getting really annoying trying to debug things when you're never quite sure what seems to be happening is really happening, because there's a MinGW-specific hack in somewhere. Especially when (OK I'm generalising here but only because it's getting rather annoying!) that so many of the hacks seem to be rather bogus. Any opinions/justifications/flames? Paul Index: env.c =================================================================== RCS file: /home/grass/grassrepository/grass6/lib/gis/env.c,v retrieving revision 1.15 diff -u -r1.15 env.c --- env.c 2 Sep 2006 05:43:39 -0000 1.15 +++ env.c 1 Nov 2006 19:40:05 -0000 @@ -97,9 +97,6 @@ read_env ( int loc ) { char buf[200]; -#ifdef __MINGW32__ - char tmp[200]; -#endif char *name; char *value; @@ -125,31 +122,6 @@ *value++ = 0; G_strip (name); G_strip (value); -#ifdef __MINGW32__ - /* We need to prepend the MSYS base path (C:/msys/1.0) to any - * internal path variables since these variables cannot be - * auto-transformed to win32 path by the MSYS shell. */ - if (strcmp(name, "GISDBASE") == 0 && value[1] != ':') - { - char *p; - - sprintf(tmp, "%s", getenv("WD")); - /* the default $WD = C:\msys\1.0\\bin\ */ - for(p=tmp+strlen(tmp); --p>=tmp && *p=='\\';); - /* C:\msys\1.0\\bin */ - for(; --p>=tmp && *p!='\\';); - /* C:\msys\1.0\\ */ - for(; --p>=tmp && *p=='\\';); - /* C:\msys\1.0 */ - *(p+1) = 0; - for(p=tmp; *p; p++) - if(*p == '\\') - *p = '/'; - /* now tmp is "C:/msys/1.0" and value is "/posix/path" */ - strcat(tmp, value); - value = tmp; - } -#endif if (*name && *value) set_env (name, value, loc); } @@ -271,29 +243,7 @@ for (n = 0; n < count; n++) if (env[n].name && env[n].value && env[n].loc == loc && (sscanf (env[n].value,"%1s", dummy) == 1)) -#ifdef __MINGW32__ - /* Strip out the MSYS base path (C:/msys/1.0). */ - { - char *value = env[n].value; - char tmp[200]; - - if (strcmp(env[n].name, "GISDBASE") == 0 && value[1] == ':') - { - char *p; - - sprintf(tmp, "%s", getenv("WD")); - for(p=tmp+strlen(tmp); --p>=tmp && *p=='\\';); - for(; --p>=tmp && *p!='\\';); - for(; --p>=tmp && *p=='\\';); - *(p+1) = 0; - /* skip C:/msys/1.0 */ - value += p+1-tmp; - } - fprintf(fd,"%s: %s\n", env[n].name, value); - } -#else fprintf(fd,"%s: %s\n", env[n].name, env[n].value); -#endif fclose (fd); } @@ -324,11 +274,7 @@ /* TODO: better place ? */ read_env ( G_VAR_GISRC ); -#ifdef __MINGW32__ - sprintf ( buf, "%s\\%s\\VAR", G_location_path(), G_mapset() ); -#else sprintf ( buf, "%s/%s/VAR", G_location_path(), G_mapset() ); -#endif } return fopen (buf, mode); From glynn at gclements.plus.com Wed Nov 1 21:56:34 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Nov 1 21:57:40 2006 Subject: [GRASS-dev] Zooming issue in gis manager In-Reply-To: <4548C179.8080801@o2.pl> References: <4548C179.8080801@o2.pl> Message-ID: <17737.2562.965291.612957@cerise.gclements.plus.com> Maciej Sieczka wrote: > > This sounds like there is no good reason to set this for interactive zooming > > by default. If someone wants to use this feature, they could explicitly set > > it in g.region. > > gis.m zoom tools should preserve the resolution while zooming, and set > the region extents properly. That's because there are tools in gis.m to > set WIND to match gis.m display, and to make the display match the > current region - thus these two operations should not lead to region or > display settings the user not wanted. The problem is that they do, because: > > 1. If -a is not used in g.region calls in mapcanvas.tcl (like it was > originally, few months ago), the gis.m zoom tools don't preserve the > resolution while zooming; and I don't see a reason why the resolution > should change while zooming, but do I see obvious reason why it > shouldn't. Thus, I suggested a solution: use the g.region with -a. It > fixed the resolution issue. While -a will preserve the resolution, it does more than that. It doesn't just force the size of the region to be an exact multiple of the resolution, but also forces its position to be an exact multiple of the resolution. > 2. But, now it showed that if g.region -a is used in mapcanvas.tcl, the > region extent is often not set properly. This is not acceptable either, > is it? > > Removing the -a flag should fix issue 2, but it will bring the issue 1 > back. What do we do then? I think that the core problem is that d.rast cannot render an arbitrary portion of a map; the rendered image has to be aligned to the cell boundaries. The region always has an integer number of rows and columns. d.rast always ensures that the entire region just fits inside the frame; one pair of edges will always exactly touch the corresponding edges of the region. Thus, the rendered image will only ever show whole cells. You will never get a situation where part of a cell is shown and the other part cropped. At magnifications significantly above unity, this is likely to be problematic for interactive zooming. You either have to adjust the bounds so that they aligh with the existing cell grid, or adjust the resolution so that the cell grid aligns with the bounds. -- Glynn Clements From joel.pitt at gmail.com Wed Nov 1 22:08:48 2006 From: joel.pitt at gmail.com (Joel Pitt) Date: Wed Nov 1 22:08:51 2006 Subject: [GRASS-dev] Zooming issue in gis manager In-Reply-To: <17737.2562.965291.612957@cerise.gclements.plus.com> References: <4548C179.8080801@o2.pl> <17737.2562.965291.612957@cerise.gclements.plus.com> Message-ID: On 11/2/06, Glynn Clements wrote: > I think that the core problem is that d.rast cannot render an > arbitrary portion of a map; the rendered image has to be aligned to > the cell boundaries. > > The region always has an integer number of rows and columns. d.rast > always ensures that the entire region just fits inside the frame; one > pair of edges will always exactly touch the corresponding edges of the > region. > > Thus, the rendered image will only ever show whole cells. You will > never get a situation where part of a cell is shown and the other part > cropped. How much difficulty would it be to alter the behaviour of d.rast to allow partial cells to be rendered? If someone were to make the change, can anyone think of what flow on effects this would have for other components of GRASS? (Not too much of an issue since a flag could be added to d.rast to have this as optional behaviour). -- -Joel "Wish not to seem, but to be, the best." -- Aeschylus From glynn at gclements.plus.com Wed Nov 1 22:25:22 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Nov 1 22:25:26 2006 Subject: [GRASS-dev] Windows-style Pathnames In-Reply-To: References: Message-ID: <17737.4290.419895.264288@cerise.gclements.plus.com> Paul Kelly wrote: > While experimenting with native Windows GRASS I was having loads of > problems getting anything to work at all because the GISDBASE path read > from the GISRC file was being corrupted in some strange way. Eventually > tracked it down to lots of MinGW-specific hacks in lib/gis/env.c. When I > removed them all everything (that I've tried so far: text-based startup > and quite a few different modules) worked fine. Really! I've included the > patch that removes them below at the bottom of this e-mail. > > It appears to contain lots of stuff about prepending and stripping the > hardcoded path to an Msys installation - what is that all about? Surely: > 1) GRASS may be installed other places than under the Msys root > 2) The correct solution is to pass the correct Windows-style path to > whichever functions need it, rather than hacking about with it in the GIS > library functions. > OK maybe I've missed something but it really doesn't make sense to me and > seems like (from what I can see) to be fixing the problem in the wrong > place? Quite possibly. > There's lots of other MinGW hacks and ifdefs all over the place that look > very dubious to me. An example is this one in lib/gis/parser.c: > > error = 0 ; > need_first_opt = 1 ; > i = strlen(pgm_name = argv[0]) ; > while (--i >= 0) > { > #ifdef __MINGW32__ > if (pgm_name[i] == '/' || pgm_name[i] == '\\') > #else > if (pgm_name[i] == '/') > #endif > { > pgm_name += i+1; > break; > } > } > > It looks to me like pgm_name[i] is the first character in an array, so how > does it make sense to compare it to a two-character string? '\\' isn't a string, it's a character literal equal to 92 - the ASCII code for the backslash character (character literals support sequences such as '\n', so the backslash itself has to be preceded by a backslash). > And if it is > correct, why the #ifdef anyway? Why not do the logical or comparison on > all platforms? A backslash isn't a directory separator on Unix, it's a legal (albeit unlikely) character in filenames. > I think the aim should be to try and find a way of doing > things that works on all platforms, rather than putting in > platform-specific bits like this. For the above case, there should probably be a G_is_directory_separator() function which determines whether or not its argument is a directory separator on the host platform. There also needs to be a macro (e.g. DIRSEP) which expands to the preferred separator. While Windows accepts both / and \ in a lot of situations, there are some (notably command lines) where only \ works. > It is getting really annoying trying to > debug things when you're never quite sure what seems to be happening is > really happening, because there's a MinGW-specific hack in somewhere. > Especially when (OK I'm generalising here but only because it's getting > rather annoying!) that so many of the hacks seem to be rather bogus. > > Any opinions/justifications/flames? Windows isn't Unix. There will inevitably need to be some handling of platform-specific behaviour. However, it's far better to create a set of functions to handle such issues than to deal with individual files separately. > Index: env.c > -#ifdef __MINGW32__ > - /* We need to prepend the MSYS base path (C:/msys/1.0) to any > - * internal path variables since these variables cannot be > - * auto-transformed to win32 path by the MSYS shell. */ > - if (strcmp(name, "GISDBASE") == 0 && value[1] != ':') > - { > - char *p; > - > - sprintf(tmp, "%s", getenv("WD")); > - /* the default $WD = C:\msys\1.0\\bin\ */ > - for(p=tmp+strlen(tmp); --p>=tmp && *p=='\\';); > - /* C:\msys\1.0\\bin */ > - for(; --p>=tmp && *p!='\\';); > - /* C:\msys\1.0\\ */ > - for(; --p>=tmp && *p=='\\';); > - /* C:\msys\1.0 */ > - *(p+1) = 0; > - for(p=tmp; *p; p++) > - if(*p == '\\') > - *p = '/'; > - /* now tmp is "C:/msys/1.0" and value is "/posix/path" */ > - strcat(tmp, value); > - value = tmp; > - } > -#endif This is bogus, and should go. > if (*name && *value) > set_env (name, value, loc); > } > @@ -271,29 +243,7 @@ > for (n = 0; n < count; n++) > if (env[n].name && env[n].value && env[n].loc == loc > && (sscanf (env[n].value,"%1s", dummy) == 1)) > -#ifdef __MINGW32__ > - /* Strip out the MSYS base path (C:/msys/1.0). */ > - { > - char *value = env[n].value; > - char tmp[200]; > - > - if (strcmp(env[n].name, "GISDBASE") == 0 && value[1] == > ':') > - { > - char *p; > - > - sprintf(tmp, "%s", getenv("WD")); > - for(p=tmp+strlen(tmp); --p>=tmp && *p=='\\';); > - for(; --p>=tmp && *p!='\\';); > - for(; --p>=tmp && *p=='\\';); > - *(p+1) = 0; > - /* skip C:/msys/1.0 */ > - value += p+1-tmp; > - } > - fprintf(fd,"%s: %s\n", env[n].name, value); > - } > -#else Ditto. > -#ifdef __MINGW32__ > - sprintf ( buf, "%s\\%s\\VAR", G_location_path(), G_mapset() ); > -#else > sprintf ( buf, "%s/%s/VAR", G_location_path(), G_mapset() ); > -#endif This is arguably correct, although possbily better formulated as e.g.: sprintf ( buf, "%s" DIRSEP "%s" DIRSEP "VAR", G_location_path(), G_mapset() ); or: sprintf ( buf, "%s%s%s%sVAR", G_location_path(), DIRSEP, G_mapset(), DIRSEP ); rather than using a platform test. However, using / should work as an argument to fopen(). The issue is more significant if paths are constructed and stored for later use (e.g. in $GISRC). In that situation, we need to decide whether to: 1. create and store the pathname in the host's syntax, or 2. store it in Unix syntax and convert it as required. Either option will involve a lot of changes. #1 is easier to implement, but will probably need to be done in more places (it needs to be done for every pathname which might need to be in host syntax at some point). #2 is harder, but only needs to be performed in places where host syntax is known to be necessary. -- Glynn Clements From grass4u at gmail.com Wed Nov 1 22:52:11 2006 From: grass4u at gmail.com (Huidae Cho) Date: Wed Nov 1 22:52:54 2006 Subject: [GRASS-dev] Windows-style Pathnames In-Reply-To: <17737.4290.419895.264288@cerise.gclements.plus.com> References: <17737.4290.419895.264288@cerise.gclements.plus.com> Message-ID: <20061101215211.GA3922@localhost.tamu.edu> On Wed, Nov 01, 2006 at 09:25:22PM +0000, Glynn Clements wrote: > > Paul Kelly wrote: > > > While experimenting with native Windows GRASS I was having loads of > > problems getting anything to work at all because the GISDBASE path read > > from the GISRC file was being corrupted in some strange way. Eventually > > tracked it down to lots of MinGW-specific hacks in lib/gis/env.c. When I > > removed them all everything (that I've tried so far: text-based startup > > and quite a few different modules) worked fine. Really! I've included the > > patch that removes them below at the bottom of this e-mail. > > > > It appears to contain lots of stuff about prepending and stripping the > > hardcoded path to an Msys installation - what is that all about? Surely: > > 1) GRASS may be installed other places than under the Msys root > > 2) The correct solution is to pass the correct Windows-style path to > > whichever functions need it, rather than hacking about with it in the GIS > > library functions. > > OK maybe I've missed something but it really doesn't make sense to me and > > seems like (from what I can see) to be fixing the problem in the wrong > > place? > > Quite possibly. > > > There's lots of other MinGW hacks and ifdefs all over the place that look > > very dubious to me. An example is this one in lib/gis/parser.c: > > > > error = 0 ; > > need_first_opt = 1 ; > > i = strlen(pgm_name = argv[0]) ; > > while (--i >= 0) > > { > > #ifdef __MINGW32__ > > if (pgm_name[i] == '/' || pgm_name[i] == '\\') > > #else > > if (pgm_name[i] == '/') > > #endif > > { > > pgm_name += i+1; > > break; > > } > > } > > > > It looks to me like pgm_name[i] is the first character in an array, so how > > does it make sense to compare it to a two-character string? > > '\\' isn't a string, it's a character literal equal to 92 - the ASCII > code for the backslash character (character literals support sequences > such as '\n', so the backslash itself has to be preceded by a > backslash). > > > And if it is > > correct, why the #ifdef anyway? Why not do the logical or comparison on > > all platforms? > > A backslash isn't a directory separator on Unix, it's a legal (albeit > unlikely) character in filenames. > > > I think the aim should be to try and find a way of doing > > things that works on all platforms, rather than putting in > > platform-specific bits like this. > > For the above case, there should probably be a > G_is_directory_separator() function which determines whether or not > its argument is a directory separator on the host platform. > > There also needs to be a macro (e.g. DIRSEP) which expands to the > preferred separator. While Windows accepts both / and \ in a lot of > situations, there are some (notably command lines) where only \ works. > > > It is getting really annoying trying to > > debug things when you're never quite sure what seems to be happening is > > really happening, because there's a MinGW-specific hack in somewhere. > > Especially when (OK I'm generalising here but only because it's getting > > rather annoying!) that so many of the hacks seem to be rather bogus. > > > > Any opinions/justifications/flames? > > Windows isn't Unix. There will inevitably need to be some handling of > platform-specific behaviour. > > However, it's far better to create a set of functions to handle such > issues than to deal with individual files separately. > > > Index: env.c > > > -#ifdef __MINGW32__ > > - /* We need to prepend the MSYS base path (C:/msys/1.0) to any > > - * internal path variables since these variables cannot be > > - * auto-transformed to win32 path by the MSYS shell. */ > > - if (strcmp(name, "GISDBASE") == 0 && value[1] != ':') > > - { > > - char *p; > > - > > - sprintf(tmp, "%s", getenv("WD")); > > - /* the default $WD = C:\msys\1.0\\bin\ */ > > - for(p=tmp+strlen(tmp); --p>=tmp && *p=='\\';); > > - /* C:\msys\1.0\\bin */ > > - for(; --p>=tmp && *p!='\\';); > > - /* C:\msys\1.0\\ */ > > - for(; --p>=tmp && *p=='\\';); > > - /* C:\msys\1.0 */ > > - *(p+1) = 0; > > - for(p=tmp; *p; p++) > > - if(*p == '\\') > > - *p = '/'; > > - /* now tmp is "C:/msys/1.0" and value is "/posix/path" */ > > - strcat(tmp, value); > > - value = tmp; > > - } > > -#endif > > This is bogus, and should go. > > > if (*name && *value) > > set_env (name, value, loc); > > } > > @@ -271,29 +243,7 @@ > > for (n = 0; n < count; n++) > > if (env[n].name && env[n].value && env[n].loc == loc > > && (sscanf (env[n].value,"%1s", dummy) == 1)) > > -#ifdef __MINGW32__ > > - /* Strip out the MSYS base path (C:/msys/1.0). */ > > - { > > - char *value = env[n].value; > > - char tmp[200]; > > - > > - if (strcmp(env[n].name, "GISDBASE") == 0 && value[1] == > > ':') > > - { > > - char *p; > > - > > - sprintf(tmp, "%s", getenv("WD")); > > - for(p=tmp+strlen(tmp); --p>=tmp && *p=='\\';); > > - for(; --p>=tmp && *p!='\\';); > > - for(; --p>=tmp && *p=='\\';); > > - *(p+1) = 0; > > - /* skip C:/msys/1.0 */ > > - value += p+1-tmp; > > - } > > - fprintf(fd,"%s: %s\n", env[n].name, value); > > - } > > -#else > > Ditto. > > > -#ifdef __MINGW32__ > > - sprintf ( buf, "%s\\%s\\VAR", G_location_path(), G_mapset() ); > > -#else > > sprintf ( buf, "%s/%s/VAR", G_location_path(), G_mapset() ); > > -#endif > > This is arguably correct, although possbily better formulated as e.g.: > > sprintf ( buf, "%s" DIRSEP "%s" DIRSEP "VAR", G_location_path(), G_mapset() ); > or: > sprintf ( buf, "%s%s%s%sVAR", G_location_path(), DIRSEP, G_mapset(), DIRSEP ); > > rather than using a platform test. > > However, using / should work as an argument to fopen(). The issue is > more significant if paths are constructed and stored for later use > (e.g. in $GISRC). In that situation, we need to decide whether to: > > 1. create and store the pathname in the host's syntax, or > 2. store it in Unix syntax and convert it as required. The above code actually does #2 under the wrong assumption that GISDBASE is in an MSys installation directory. > > Either option will involve a lot of changes. #1 is easier to > implement, but will probably need to be done in more places (it needs > to be done for every pathname which might need to be in host syntax at > some point). #2 is harder, but only needs to be performed in places > where host syntax is known to be necessary. I found #2 a better choice becase MSys shell scripts will be happier with posix path. Huidae > > -- > Glynn Clements > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From glynn at gclements.plus.com Wed Nov 1 22:48:57 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Nov 1 23:03:23 2006 Subject: [GRASS-dev] Zooming issue in gis manager In-Reply-To: References: <4548C179.8080801@o2.pl> <17737.2562.965291.612957@cerise.gclements.plus.com> Message-ID: <17737.5705.548999.931493@cerise.gclements.plus.com> Joel Pitt wrote: > > I think that the core problem is that d.rast cannot render an > > arbitrary portion of a map; the rendered image has to be aligned to > > the cell boundaries. > > > > The region always has an integer number of rows and columns. d.rast > > always ensures that the entire region just fits inside the frame; one > > pair of edges will always exactly touch the corresponding edges of the > > region. > > > > Thus, the rendered image will only ever show whole cells. You will > > never get a situation where part of a cell is shown and the other part > > cropped. > > How much difficulty would it be to alter the behaviour of d.rast to > allow partial > cells to be rendered? > > If someone were to make the change, can anyone think of what flow on > effects this would have for other components of GRASS? (Not too much > of an issue since a flag could be added to d.rast to have this as > optional behaviour). It isn't trivial, for reasons of both implementation and design. d.rast uses various functions from lib/display to do most of the work. Either these functions would need to be changed, or d.rast would need to be re-implemented without them. The main one is D_do_conversions() from lib/display/cnversions.c, which is used by D_cell_draw_setup[_RGB](). This takes a Cell_head and a screen rectangle (integer coordinates), and determines the offset/scale parameters for a set of linear transformations which can convert between cell array indices, geographic coordinates and screen coordinates. These parameters are then used by D_u_to_a_row() etc, which in turn are used by D_draw_cell(). Probably the most viable solution would be an extended version of D_do_conversions() which takes two Cell_head structures. The first would be the current region (which determines the mapping between geographic coordinates and cell array indices), while the second would be the region to fit to the screen rectangle (only the bounds would be used, with the resolution and rows/cols being ignored). The existing D_do_conversions() would just call the extended version with the same Cell_head for both arguments. There would also need to be extended D_cell_draw_setup[_RGB] functions, and some means to tell d.rast (and d.rgb, d.his, ...) which region to draw (you can't use the current region, because the current region is always subdivided into an exact number of rows and columns, and changing that certainly isn't viable). -- Glynn Clements From tutey at o2.pl Wed Nov 1 23:08:54 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Nov 1 23:08:59 2006 Subject: [GRASS-dev] Zooming issue in gis manager In-Reply-To: <17737.2562.965291.612957@cerise.gclements.plus.com> References: <4548C179.8080801@o2.pl> <17737.2562.965291.612957@cerise.gclements.plus.com> Message-ID: <45491AF6.90200@o2.pl> Glynn Clements wrote: > Maciej Sieczka wrote: > >>> This sounds like there is no good reason to set this for interactive zooming >>> by default. If someone wants to use this feature, they could explicitly set >>> it in g.region. >> gis.m zoom tools should preserve the resolution while zooming, and set >> the region extents properly. That's because there are tools in gis.m to >> set WIND to match gis.m display, and to make the display match the >> current region - thus these two operations should not lead to region or >> display settings the user not wanted. The problem is that they do, because: >> >> 1. If -a is not used in g.region calls in mapcanvas.tcl (like it was >> originally, few months ago), the gis.m zoom tools don't preserve the >> resolution while zooming; and I don't see a reason why the resolution >> should change while zooming, but do I see obvious reason why it >> shouldn't. Thus, I suggested a solution: use the g.region with -a. It >> fixed the resolution issue. > > While -a will preserve the resolution, it does more than that. It > doesn't just force the size of the region to be an exact multiple of > the resolution, but also forces its position to be an exact multiple > of the resolution. > >> 2. But, now it showed that if g.region -a is used in mapcanvas.tcl, the >> region extent is often not set properly. This is not acceptable either, >> is it? >> >> Removing the -a flag should fix issue 2, but it will bring the issue 1 >> back. What do we do then? > > I think that the core problem is that d.rast cannot render an > arbitrary portion of a map; the rendered image has to be aligned to > the cell boundaries. Thanks Glynn. Another question - so how does is happen that the X monitors don't have that problem, while gis.m displays do? I mean: 1. When I set a region to match, say, 5 cols/6 rows (using g.region) and d.rast on X monitor - I see 5 cols/6 rows of a raster. 2. And when I use d.zoom and set the display on X monitor so that I see, say, 3 cols/7 rows, and I do g.region -p - I see that my region indeed has 3 cols/7 rows, and the resolution has not changed while zooming. But when gis.m interacts modifies WIND to match it's display, we have, either, only the resolution, or only the number or rows and cols set properly, depending on if the g.region is used with or without -a. > The region always has an integer number of rows and columns. d.rast > always ensures that the entire region just fits inside the frame; one > pair of edges will always exactly touch the corresponding edges of the > region. > Thus, the rendered image will only ever show whole cells. You will > never get a situation where part of a cell is shown and the other part > cropped. But I don't even want it. I'm saying that gis.m interaction with WIND must not corrupt the resolution or the number of rows and cols. If that is not possible, then we should not ask people to use gis.m yet. Or disable the WIND<->gis.m interaction alltogether. > At magnifications significantly above unity, this is likely to be > problematic for interactive zooming. You either have to adjust the > bounds so that they aligh with the existing cell grid, or adjust the > resolution so that the cell grid aligns with the bounds. So having both bounds and resolution preserved when gis.m interatcs with WIND is not possible, is that what you mean? Maciek From tutey at o2.pl Wed Nov 1 23:09:56 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Nov 1 23:10:02 2006 Subject: [GRASS-dev] Zooming issue in gis manager In-Reply-To: References: Message-ID: <45491B34.7030200@o2.pl> Michael Barton wrote: > To clarify a bit... > > In the "standard" mode, resolution and geometry are preserved by the display > in all zooming. Michael, Not really. The resolution is preserved *only* if -a flag is set in g.region call in mapcanvas.tcl, lines 1068/1066. If this -a flag is removed, the res is not preserved when you set WIND to match the gis.m display (eg. instead of 30 you get 29.56552545). Try to reproduce that, can you? And do you confirm my observation or not? As to preserving the region extent - this is achieved only if the -a flag in question is removed (however, the number of cols on the status bar below still doesn't match, interestingly). So we can't currently have both: the resolution and the number of rows and cols to be preserved when setting WIND to match the gis.m display. But we need both. Could we have them? Maciek From woklist at kyngchaos.com Wed Nov 1 23:29:13 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Wed Nov 1 23:29:27 2006 Subject: [GRASS-dev] OSX/X11 GLX improvements Message-ID: <316ADC1C-64B9-4846-AC65-9549128AA798@kyngchaos.com> It's not often that Apple updates their X11 installation. Something that directly affects NVIZ: " This update addresses several issues in the X11 for Mac OS X package, enabling it to better handle: - GLX stereo visuals - offscreen rendering to GLX Pbuffers and Pixmaps " It should show up in my next 6.3 CVS build if configure picks it up. It's only for the current Tiger 10.4.8, not Panther, so that would break Panther compatibility unless I force-disable pbuffers or generate separate binaries (bleh). Note: this is just an X11 update, and probably won't affect the Aqua NVIZ issue. ----- William Kyngesburye http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy From michael.barton at asu.edu Wed Nov 1 23:30:06 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Nov 1 23:30:22 2006 Subject: [GRASS-dev] Zooming issue in gis manager In-Reply-To: Message-ID: I've looked even further and found that as Glynn notes, d.rast also will align with cells, even if the -a flag is not set in g.region. It also seems to do so somewhat more accurately than with the -a flag set. That is, it produces a much better (exact?) match between the display and computational region in a more predictable way, as you can see in the graphics I showed last night. However, if you want to *really* see where the grid cells are at high magnification, try the explore mode. Because it increases the resolution as you zoom in (to keep a constant number of cells/pixel) you can set the display to zoom across original cell boundaries. It also shows a point overlaying cells in a slightly differently place even than "normal" display mode with -a not set--by about a quarter of a cell on the display I'm looking at. With -a set, the difference is more than 1/2 cell in the other direction. I can't tell which is "right" for certain. That is, I'm not sure how to tell mathematically where the cell boundaries ought to lie with respect to their actual coordinates and where a point should lie within a cell. I'm betting that explore mode is the most "accurate" in terms of the relationship between cells and a point. How can we determine what the cell boundaries ought to be? Since this is a function of the interaction between g.region and the display driver, do we need to do anything about it (as Joel asks)? If so, what? Also, I assume that this is only affecting the graphics created out of d.rast (and d.vect??), and does not affect any overlay operations. So how should it be prioritized? Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Joel Pitt > Reply-To: > Date: Thu, 2 Nov 2006 10:08:48 +1300 > To: Glynn Clements > Cc: Maciej Sieczka , Michael Barton , > grass-dev > Subject: Re: [GRASS-dev] Zooming issue in gis manager > > On 11/2/06, Glynn Clements wrote: >> I think that the core problem is that d.rast cannot render an >> arbitrary portion of a map; the rendered image has to be aligned to >> the cell boundaries. >> >> The region always has an integer number of rows and columns. d.rast >> always ensures that the entire region just fits inside the frame; one >> pair of edges will always exactly touch the corresponding edges of the >> region. >> >> Thus, the rendered image will only ever show whole cells. You will >> never get a situation where part of a cell is shown and the other part >> cropped. > > How much difficulty would it be to alter the behaviour of d.rast to > allow partial > cells to be rendered? > > If someone were to make the change, can anyone think of what flow on > effects this would have for other components of GRASS? (Not too much > of an issue since a flag could be added to d.rast to have this as > optional behaviour). > > -- > -Joel > > "Wish not to seem, but to be, the best." > -- Aeschylus From paul-grass at stjohnspoint.co.uk Wed Nov 1 23:56:21 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Wed Nov 1 23:56:23 2006 Subject: [GRASS-dev] Windows-style Pathnames In-Reply-To: <20061101215211.GA3922@localhost.tamu.edu> References: <17737.4290.419895.264288@cerise.gclements.plus.com> <20061101215211.GA3922@localhost.tamu.edu> Message-ID: On Wed, 1 Nov 2006, Glynn Clements wrote: > Windows isn't Unix. There will inevitably need to be some handling of > platform-specific behaviour. > > However, it's far better to create a set of functions to handle such > issues than to deal with individual files separately. Yes I agree with that; I think that's what I was trying to say but hadn't thought it through. E.g. a G_mkdir() to abstract the fact that Unix and Windows mkdir() require a different number of arguments, that kind of thing. On Wed, 1 Nov 2006, Huidae Cho wrote: > On Wed, Nov 01, 2006 at 09:25:22PM +0000, Glynn Clements wrote: >> >>> -#ifdef __MINGW32__ >>> - sprintf ( buf, "%s\\%s\\VAR", G_location_path(), G_mapset() ); >>> -#else >>> sprintf ( buf, "%s/%s/VAR", G_location_path(), G_mapset() ); >>> -#endif >> >> This is arguably correct, although possbily better formulated as e.g.: >> >> sprintf ( buf, "%s" DIRSEP "%s" DIRSEP "VAR", G_location_path(), G_mapset() ); >> or: >> sprintf ( buf, "%s%s%s%sVAR", G_location_path(), DIRSEP, G_mapset(), DIRSEP ); >> >> rather than using a platform test. >> >> However, using / should work as an argument to fopen(). The issue is >> more significant if paths are constructed and stored for later use >> (e.g. in $GISRC). In that situation, we need to decide whether to: >> >> 1. create and store the pathname in the host's syntax, or >> 2. store it in Unix syntax and convert it as required. > > The above code actually does #2 under the wrong assumption that GISDBASE > is in an MSys installation directory. When we are talking about host syntax or Unix syntax, do we mean only the difference between / and \ for directory separators in pathnames? I mean c:\grass\grassdata format is more correct, although as Glynn said c:/grass/grassdata works in a lot of circumstances and means very little in GRASS has to be changed (there are lots of C routines that form pathnames by concatenating strings with /). /c/grass/grassdata is Msys-specific and is specially interpreted by the Msys shell, right? I don't think there should be a need to use that format at all (except see Huidae's comment below). >> Either option will involve a lot of changes. #1 is easier to >> implement, but will probably need to be done in more places (it needs >> to be done for every pathname which might need to be in host syntax at >> some point). #2 is harder, but only needs to be performed in places >> where host syntax is known to be necessary. > > I found #2 a better choice becase MSys shell scripts will be happier > with posix path. Using the form c:/grass/grassdata rather than /c/grass/grassdata has proven OK for me so far (mostly in the configure script and bits of shell scripting done in the installation process and Makefiles). Were there many examples where this format was problematic? Paul From grass4u at gmail.com Thu Nov 2 00:42:28 2006 From: grass4u at gmail.com (Huidae Cho) Date: Thu Nov 2 00:43:11 2006 Subject: [GRASS-dev] Windows-style Pathnames In-Reply-To: References: <17737.4290.419895.264288@cerise.gclements.plus.com> <20061101215211.GA3922@localhost.tamu.edu> Message-ID: <20061101234228.GA5009@localhost.tamu.edu> On Wed, Nov 01, 2006 at 10:54:09PM +0000, Paul D Kelly wrote: > On Wed, 1 Nov 2006, Glynn Clements wrote: > > >Windows isn't Unix. There will inevitably need to be some handling of > >platform-specific behaviour. > >However, it's far better to create a set of functions to handle such > >issues than to deal with individual files separately. > > Yes I agree with that; I think that's what I was trying to say but hadn't > thought it through. E.g. a G_mkdir() to abstract the fact that Unix and > Windows mkdir() require a different number of arguments, that kind of > thing. > > > On Wed, 1 Nov 2006, Huidae Cho wrote: > > >On Wed, Nov 01, 2006 at 09:25:22PM +0000, Glynn Clements wrote: > >>>-#ifdef __MINGW32__ > >>>- sprintf ( buf, "%s\\%s\\VAR", G_location_path(), G_mapset() ); > >>>-#else > >>> sprintf ( buf, "%s/%s/VAR", G_location_path(), G_mapset() ); > >>>-#endif > >>This is arguably correct, although possbily better formulated as e.g.: > >> sprintf ( buf, "%s" DIRSEP "%s" DIRSEP "VAR", G_location_path(), G_mapset() > >>); > >>or: > >> sprintf ( buf, "%s%s%s%sVAR", G_location_path(), DIRSEP, G_mapset(), DIRSEP > >>); > >>rather than using a platform test. > >>However, using / should work as an argument to fopen(). The issue is > >>more significant if paths are constructed and stored for later use > >>(e.g. in $GISRC). In that situation, we need to decide whether to: > >>1. create and store the pathname in the host's syntax, or > >>2. store it in Unix syntax and convert it as required. > >The above code actually does #2 under the wrong assumption that GISDBASE > >is in an MSys installation directory. > > When we are talking about host syntax or Unix syntax, do we mean only the > difference between / and \ for directory separators in pathnames? > No. MSys has a virtual root to wherever it is installed, so /usr/... should be transformed to something like c:\msys\1.0\usr\... I doubt we can completely avoid using this convention in winGRASS. > I mean c:\grass\grassdata format is more correct, although as Glynn said > c:/grass/grassdata works in a lot of circumstances and means very little in > GRASS has to be changed (there are lots of C routines that form pathnames by > concatenating strings with /). /c/grass/grassdata is Msys-specific and is > specially interpreted by the Msys shell, right? I don't think there should be a > need to use that format at all (except see Huidae's comment below). > > >>Either option will involve a lot of changes. #1 is easier to > >>implement, but will probably need to be done in more places (it needs > >>to be done for every pathname which might need to be in host syntax at > >>some point). #2 is harder, but only needs to be performed in places > >>where host syntax is known to be necessary. > >I found #2 a better choice becase MSys shell scripts will be happier > >with posix path. > > Using the form c:/grass/grassdata rather than /c/grass/grassdata has proven OK > for me so far (mostly in the configure script and bits of shell scripting done > in the installation process and Makefiles). Were there many examples where this > format was problematic? One example is $PATH. ':' cannot be used in PATH because ':' is already used for path separators in the MSys environment. For example, exporting "PATH=c:/grass/bin:c:/msys/bin" in a shell script is problematic while setting "PATH=c:/grass/bin;c:/msys/bin" (note ';' separator) in a batch file (e.g., c:\msys\1.0\msys.bat) is OK since MSys takes care of converting it to PATH=/c/grass/bin:/c/msys/bin. The Windows-style path causes another problem/inconvenience when it comes to shell scripting because scripts have to deal with two types of path styles in some cases. For example, it would be complicated to implement "which" using $FOO if the script reads in a config file directly. For this reason, I prefer UNIX-style pathnames even if host syntax looks more reasonable. Huidae > > Paul > From grass-bugs at intevation.de Thu Nov 2 02:18:11 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Nov 2 02:18:12 2006 Subject: [GRASS-dev] [bug #5252] (grass) Multicore hardware and grass Message-ID: <20061102011811.55E19101EE0@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5252 ------------------------------------------------------------------------- Subject: Multicore hardware and grass Platform: GNU/Linux/x86_64 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources This time next year dual quad - core desktop systems should be readily available. What level of effort would it take for GRASS to be able to split the processing load between the multiple cores? Doug Newcomb ( obviously not a C programmer :-)) -------------------------------------------- Managed by Request Tracker From glynn at gclements.plus.com Thu Nov 2 02:40:41 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Nov 2 02:42:32 2006 Subject: [GRASS-dev] Zooming issue in gis manager In-Reply-To: <45491AF6.90200@o2.pl> References: <4548C179.8080801@o2.pl> <17737.2562.965291.612957@cerise.gclements.plus.com> <45491AF6.90200@o2.pl> Message-ID: <17737.19609.232888.737802@cerise.gclements.plus.com> Maciej Sieczka wrote: > > I think that the core problem is that d.rast cannot render an > > arbitrary portion of a map; the rendered image has to be aligned to > > the cell boundaries. > > Thanks Glynn. Another question - so how does is happen that the X > monitors don't have that problem, while gis.m displays do? X displays have exactly the same problem. gis.m might have some *other* problems, but the d.rast/libdisplay issue I was discussing applies regardless. > I mean: > > 1. When I set a region to match, say, 5 cols/6 rows (using g.region) > and d.rast on X monitor - I see 5 cols/6 rows of a raster. > > 2. And when I use d.zoom and set the display on X monitor so that I > see, say, 3 cols/7 rows, and I do g.region -p - I see that my region > indeed has 3 cols/7 rows, and the resolution has not changed while zooming. > > But when gis.m interacts modifies WIND to match it's display, we have, > either, only the resolution, or only the number or rows and cols set > properly, depending on if the g.region is used with or without -a. I would guess that d.zoom adjusts the bounds manually, whereas gis.m uses "g.region -a". The latter does more than just preserve the resolution; it also aligns the grid with the coordinate system's origin, then aligns the bounds with that grid, rounding outwards (i.e. enlarging the region). Thus, "panning" (moving the region without changing the e-w or n-s differences) with "g.region -a" will change the size of the region if the requested bounds aren't aligned to the grid, as it will round opposing edges in opposite directions. > > The region always has an integer number of rows and columns. d.rast > > always ensures that the entire region just fits inside the frame; one > > pair of edges will always exactly touch the corresponding edges of the > > region. > > > Thus, the rendered image will only ever show whole cells. You will > > never get a situation where part of a cell is shown and the other part > > cropped. > > But I don't even want it. I'm saying that gis.m interaction with WIND > must not corrupt the resolution or the number of rows and cols. If that > is not possible, then we should not ask people to use gis.m yet. Or > disable the WIND<->gis.m interaction alltogether. So, you're complaining about the fact that preserving the resolution means moving the bounds outwards by up to 1 cell in each direction, right? Or something else? If it's the former, gis.m will need to adjust the bounds itself; there isn't any g.region option which will do the right thing (it's possible that this was what -a was supposed to do; it would make more sense than the existing behaviour). If it's the latter, you'll need to explain more clearly. > > At magnifications significantly above unity, this is likely to be > > problematic for interactive zooming. You either have to adjust the > > bounds so that they aligh with the existing cell grid, or adjust the > > resolution so that the cell grid aligns with the bounds. > > So having both bounds and resolution preserved when gis.m interatcs > with WIND is not possible, is that what you mean? The distance between opposing edges has to be an integer multiple of the resolution (i.e. the number of rows and columns must be integers). But that should be true even within gis.m. It's possible that gis.m fails to enforce this requirement, in which case, it will end up being enforced whenever gis.m interfaces with the rest of GRASS, either by adjusting the bounds to fit the resolution or by adjusting the resolution to fit the bounds. That isn't limited to updating the WIND file; it will also affect rendering. If gis.m is reporting region parameters which don't satisfy the "integer multiple" requirement, it's lying; the numbers will get "corrected" as soon as they leave gis.m. -- Glynn Clements From hamish_nospam at yahoo.com Thu Nov 2 03:03:16 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Nov 2 03:03:21 2006 Subject: [GRASS-dev] Re: [bug #5247] (grass) references to In-Reply-To: <20061031191056.62FF41006DD@lists.intevation.de> References: <20061031191056.62FF41006DD@lists.intevation.de> Message-ID: <20061102150316.656bee8d.hamish_nospam@yahoo.com> Markus Neteler via RT wrote: > I have fixed all relevant cases in 6.2 and 6.3. > Please verify, though. does that include grass60, grass57, grass53, grass51 references? posted in the bug history: https://intevation.de/rt/webrt?serial_num=5247 thanks, Hamish From glynn at gclements.plus.com Thu Nov 2 03:05:00 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Nov 2 03:05:04 2006 Subject: [GRASS-dev] Windows-style Pathnames In-Reply-To: References: <17737.4290.419895.264288@cerise.gclements.plus.com> <20061101215211.GA3922@localhost.tamu.edu> Message-ID: <17737.21068.670434.23541@cerise.gclements.plus.com> Paul Kelly wrote: > >> However, using / should work as an argument to fopen(). The issue is > >> more significant if paths are constructed and stored for later use > >> (e.g. in $GISRC). In that situation, we need to decide whether to: > >> > >> 1. create and store the pathname in the host's syntax, or > >> 2. store it in Unix syntax and convert it as required. > > > > The above code actually does #2 under the wrong assumption that GISDBASE > > is in an MSys installation directory. > > When we are talking about host syntax or Unix syntax, do we mean only the > difference between / and \ for directory separators in pathnames? Mostly, although there's also the issue of drive letters and UNC paths. > I mean c:\grass\grassdata format is more correct, although as Glynn said > c:/grass/grassdata works in a lot of circumstances and means very little > in GRASS has to be changed (there are lots of C routines that form > pathnames by concatenating strings with /). /c/grass/grassdata is > Msys-specific and is specially interpreted by the Msys shell, right? Right. It won't work with fopen() etc. > I don't think there should be a need to use that format at all Agreed. > (except see Huidae's comment below). > > >> Either option will involve a lot of changes. #1 is easier to > >> implement, but will probably need to be done in more places (it needs > >> to be done for every pathname which might need to be in host syntax at > >> some point). #2 is harder, but only needs to be performed in places > >> where host syntax is known to be necessary. > > > > I found #2 a better choice becase MSys shell scripts will be happier > > with posix path. > > Using the form c:/grass/grassdata rather than /c/grass/grassdata has > proven OK for me so far (mostly in the configure script and bits of shell > scripting done in the installation process and Makefiles). Were there many > examples where this format was problematic? It doesn't work with Windows command-line (console) programs, which treat / as a switch indicator, regardless of whether or not it is preceded by whitespace. E.g.: C:\>dir c:/windows Parameter format not correct - "windows". C:\>dir c:\windows Volume in drive C has no label. Volume Serial Number is 20AA-2D84 Directory of c:\windows ... MSys' bash accepts proper Windows pathnames, at least those which are fully qualified, e.g.: sh-2.04$ ls c:\\windows\\system AVICAP.DLL MCIAVI.DRV MOUSE.DRV SOUND.DRV VGA.DRV stdole.tlb AVIFILE.DLL MCISEQ.DRV MSVIDEO.DLL SYSTEM.DRV WFWNET.DRV COMMDLG.DLL MCIWAVE.DRV OLECLI.DLL TAPI.DLL WINSPOOL.DRV KEYBOARD.DRV MMSYSTEM.DLL OLESVR.DLL TIMER.DRV d3dx9_24.dll LZEXPAND.DLL MMTASK.TSK SHELL.DLL VER.DLL setup.inf Note that the backslash is a shell metacharacter, so it will have to be protected from interpretation if it appears directly in a script or user input. The biggest problem with scripts is when MSys decides to be "clever" and do automatic translation. IMHO, we would be better off using host syntax throughout. So far as I'm concerned, the "Windows" version should be just that, and not an "MSys" version. If people can live without the contents of the scripts directory, it shouldn't be necessary for end users to even have MSys. -- Glynn Clements From hamish_nospam at yahoo.com Thu Nov 2 03:27:41 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Nov 2 03:50:45 2006 Subject: [GRASS-dev] Re: georectifier fixes In-Reply-To: References: <20061101202021.136274d6@localhost.localdomain> Message-ID: <20061102152741.6de23aed.hamish_nospam@yahoo.com> Michael Barton wrote: > > The idea about clearing all unchecked gcp's is easy to implement and > sounds very useful. what about a "quit georectifier" button to exit? Hamish From hamish_nospam at yahoo.com Thu Nov 2 03:41:55 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Nov 2 03:55:04 2006 Subject: [GRASS-dev] Re: georectifier fixes In-Reply-To: <20061101210952.6afc8c6a@localhost.localdomain> References: <20061101202021.136274d6@localhost.localdomain> <20061101210952.6afc8c6a@localhost.localdomain> Message-ID: <20061102154155.7a5cfa31.hamish_nospam@yahoo.com> Otto Dassau wrote: > > It is odd about the i.group problem. When I click the creat/edit > > group button, it switches to the xy location/mapset and runs i.group > > on my computer. What happens on yours? > > nothing, not even an error. I have a debian testing and compile GRASS > with --with-tcltk-includes=/usr/include/tcl8.4. > > I don't know why it doesn't work. Maybe we should wait for someone > else with debian testing who can try. Maybe I do something wrong. [debian/stable (sarge)] the problem I got: gis.m file->georectify "2. Create edit group" switches to source location/mapset, but then switches back to original mapset right away, so i.group runs in the target mapset instead of source mapset. if you had already created a group in the source mapset you can continue, but otherwise you're stuck. If I modify the source, adding "after 5000" to have the Tcl sleep for 5sec after running i.group, I can get i.group to act in the source mapset for a fleeting moment, but if I then cancel & reclick the folder icon I then see the available groups in the originial (target) mapset. That is what happens with 6.2.0. With the latest 6.3, clicking the "2." button does nothing (although mapset changes fly by in the output window). Hamish From ychemin at gmail.com Thu Nov 2 04:07:22 2006 From: ychemin at gmail.com (Yann Chemin) Date: Thu Nov 2 04:07:25 2006 Subject: [GRASS-dev] [bug #5252] (grass) Multicore hardware and grass In-Reply-To: <20061102011811.55E19101EE0@lists.intevation.de> References: <20061102011811.55E19101EE0@lists.intevation.de> Message-ID: <6278879c0611011907u31e691eauf66981a9d2ba9e7e@mail.gmail.com> Hi list, Jason and I have been doing some limited tests, it looks like some functions r.* get to be twice faster on a dual-core than on a P4. I guess Jason still has the numbers, could you please share them? I am out of office right now... However, it seems that it is not the same for all functions/modules... cheers, Yann On 02/11/06, Request Tracker wrote: > this bug's URL: http://intevation.de/rt/webrt?serial_num=5252 > ------------------------------------------------------------------------- > > Subject: Multicore hardware and grass > > Platform: GNU/Linux/x86_64 > grass obtained from: Trento Italy site > grass binary for platform: Compiled from Sources > > This time next year dual quad - core desktop systems should be readily available. What level of effort would it take for GRASS to be able to split the processing load between the multiple cores? > > Doug Newcomb ( obviously not a C programmer :-)) > > > -------------------------------------------- Managed by Request Tracker > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- Some Google Working rules: * Developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team. * There aren't very many meetings. I'd say an average developer attends perhaps 3 meetings a week. * Google has a philosophy of not ever telling developers what to work on, and they take it pretty seriously. * Google tends not to pre-announce. They really do understand that you can't rush good cooking, you can't rush babies out, and you can't rush software development. From hamish_nospam at yahoo.com Thu Nov 2 04:20:50 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Nov 2 04:21:43 2006 Subject: [GRASS-dev] collecting grass (future) concepts In-Reply-To: <0CC755C1-9F04-4E33-A081-88518142694D@unity.ncsu.edu> References: <0CC755C1-9F04-4E33-A081-88518142694D@unity.ncsu.edu> Message-ID: <20061102162050.73b1d2ff.hamish_nospam@yahoo.com> Martin: > > from my personal point of view (as a relatively new/young GRASS > > "power" user) I suggest to create a new GRASS mailing list (e.g. > > grass-concepts, or grass-future, etc.), where developers and users > > could discuss the new/modified GIS concepts for future version of > > GRASS. E.g. idea concept like object-orientated and layer-orientated > > data approach, full 2D-2.5D-3D-4D GIS implementation, and in the > > future more technical issues (working on the new core libraries, > > core programming language issue, etc.). > > > > I hope that this mailing list (and of course GRASS-Wiki) might help > > to collect and crystallize ideas about GRASS future. Helena wrote: > There is also wiki for grass future ideas and IRC chat can be used > too. futute development wiki page: http://grass.gdf-hannover.de/wiki/Development#Plans Hamish From hamish_nospam at yahoo.com Thu Nov 2 04:16:41 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Nov 2 04:22:12 2006 Subject: [GRASS-dev] GRASS/KerGIS fonts: hershey revival In-Reply-To: <20061031104523.GA232@polynum.com> References: <20061031012132.GA5880@polynum.com> <200610311049.20816.maris.gis@gmail.com> <20061031104523.GA232@polynum.com> Message-ID: <20061102161641.4e031c0e.hamish_nospam@yahoo.com> > M?ris Narti?s wrote: > > Using fonts to show various symbols is easyest and common used trick > > (look ar ArcView), but it has drawbacks - user has to create new > > font to get own symbols for displaying and that's not good. In > > ArcView I also have run into different problems coming from font > > usage as symbol. Having all code already in GRASS is good, but I > > would better see as GRASS 7 wish SVG vector symbol support. QGIS > > already to that way - You can draw image in any vector image > > manipulation soft (Inkscape, CorelDraw etc.) and just show in right > > place. Size, rotation is not a problem. Pros: Scalable ;) , color, > > easy to add own symbols. Cons: adds another dependency for GRASS. tlaronde wrote: > But you have already programs in CERL GRASS based GIS to draw "icons" > (legacy and postscript). They can just be changed to generate symbols > in the description format used for the fonts---or, as I'm doing at the > moment, generate them with v.in.* (here v.in.dxf); could have v.in.svg > (v.in.metapost... since I do use it too), etc. In grass 6.2 check out the d.graph symbol command. There is scale and rotate infrastructure there, although rotate isn't fully implimented. d.vect and ps.map can also use these symbols, and ps.map does support simple .eps icons as well (incl. rotation). see D_symbol() and http://grass.gdf-hannover.de/wiki/IconSymbols There is no .eps, .svg -> d.graph or symbol converter, but it would be really great (and probably not that hard) for someone to write one. It's been a long standing wish. regards, Hamish From glynn at gclements.plus.com Thu Nov 2 04:23:03 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Nov 2 04:23:05 2006 Subject: [GRASS-dev] [bug #5252] (grass) Multicore hardware and grass In-Reply-To: <20061102011811.55E19101EE0@lists.intevation.de> References: <20061102011811.55E19101EE0@lists.intevation.de> Message-ID: <17737.25751.37693.82497@cerise.gclements.plus.com> Request Tracker wrote: > this bug's URL: http://intevation.de/rt/webrt?serial_num=5252 > This time next year dual quad - core desktop systems should be readily > available. What level of effort would it take for GRASS to be able to > split the processing load between the multiple cores? Most of GRASS' processing is in the individual modules, so you would have to re-write individual modules using multi-threaded algorithms. It doesn't help that the core GRASS libraries aren't remotely thread-safe, and can't readily be made so given the nature of the existing API. -- Glynn Clements From hamish_nospam at yahoo.com Thu Nov 2 05:03:51 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Nov 2 05:04:05 2006 Subject: [GRASS-dev] r.resamp.stats method=sum artifacts In-Reply-To: <200610311117.58316.dylan.beaudette@gmail.com> References: <20061030174705.7d4b55fa.hamish_nospam@yahoo.com> <17734.24775.637180.964134@cerise.gclements.plus.com> <20061031170006.27954610.hamish_nospam@yahoo.com> <200610311117.58316.dylan.beaudette@gmail.com> Message-ID: <20061102170351.49fc2644.hamish_nospam@yahoo.com> Hi, I've added r.resamp.stats and r.resamp.interp to the GUI menus. (Raster->Devel) should r.resample be tagged for future removal? (same result as with: 'r.resamp.interp method=nearest' ???). Hamish From hamish_nospam at yahoo.com Thu Nov 2 04:27:52 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Nov 2 05:06:58 2006 Subject: [GRASS-dev] [bug #5241] (grass) Option text line does not wrap in tk dialogs In-Reply-To: <20061027154406.5A6131006B1@lists.intevation.de> References: <20061027154406.5A6131006B1@lists.intevation.de> Message-ID: <20061102162752.58929686.hamish_nospam@yahoo.com> Request Tracker wrote: > this bug's URL: http://intevation.de/rt/webrt?serial_num=5241 > --------------------------------------------------------------------- > Subject: Option text line does not wrap in tk dialogs .. > GRASS Version: 6.2.0.rc3 > > In GUI dialogs generated by parser, option (flag) texts are not > wrapped. Some option descriptions tend to be really long (i.e. > v.distance -a flag). Same applays to option lists (i.e. v.clean > "Cleaning tool"). > > Really small, but annoying bug :) note parameter descriptions do wrap already, so the code is already there, just needs to be applied. Hamish From glynn at gclements.plus.com Thu Nov 2 05:26:00 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Nov 2 05:26:04 2006 Subject: [GRASS-dev] r.resamp.stats method=sum artifacts In-Reply-To: <20061102170351.49fc2644.hamish_nospam@yahoo.com> References: <20061030174705.7d4b55fa.hamish_nospam@yahoo.com> <17734.24775.637180.964134@cerise.gclements.plus.com> <20061031170006.27954610.hamish_nospam@yahoo.com> <200610311117.58316.dylan.beaudette@gmail.com> <20061102170351.49fc2644.hamish_nospam@yahoo.com> Message-ID: <17737.29528.199863.47406@cerise.gclements.plus.com> Hamish wrote: > I've added r.resamp.stats and r.resamp.interp to the GUI menus. > (Raster->Devel) > > should r.resample be tagged for future removal? (same result as with: > 'r.resamp.interp method=nearest' ???). No. r.resample uses libgis' built-in resampling, so it is guaranteed to resample in an identical manner to other commands. "r.resamp.interp method=nearest" performs the resampling itself, so it could produce slightly different results due to rounding errors. The method=nearest option was only included for completeness; if you want nearest-neighbour resampling, r.resample is preferred. -- Glynn Clements From michael.barton at asu.edu Thu Nov 2 06:17:56 2006 From: michael.barton at asu.edu (Michael Barton) Date: Thu Nov 2 06:18:10 2006 Subject: [GRASS-dev] Zooming issue in gis manager In-Reply-To: <45491B34.7030200@o2.pl> Message-ID: You are correct. If -a is not set in g.region it makes small rounding errors every time you change the region, even if you do not change the resolution or even if you try to set it explicitly. Given this, I guess it's better to avoid the small, but annoying rounding errors of g.region at common map scales than to keep the aligned region display appearing to be more accurate in less common close-ups of rasters, especially given that explore mode can be used to produce a display that correctly matches a region of a few original grid cells in close-ups. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Maciej Sieczka > Date: Wed, 01 Nov 2006 23:09:56 +0100 > To: grass-dev > Cc: Michael Barton > Subject: Re: [GRASS-dev] Zooming issue in gis manager > > Michael Barton wrote: >> To clarify a bit... >> >> In the "standard" mode, resolution and geometry are preserved by the display >> in all zooming. > > Michael, > > Not really. The resolution is preserved *only* if -a flag is set in > g.region call in mapcanvas.tcl, lines 1068/1066. If this -a flag is > removed, the res is not preserved when you set WIND to match the gis.m > display (eg. instead of 30 you get 29.56552545). Try to reproduce that, > can you? And do you confirm my observation or not? > > As to preserving the region extent - this is achieved only if the -a > flag in question is removed (however, the number of cols on the status > bar below still doesn't match, interestingly). > > So we can't currently have both: the resolution and the number of rows > and cols to be preserved when setting WIND to match the gis.m display. > But we need both. Could we have them? > > Maciek > > From hamish_nospam at yahoo.com Thu Nov 2 06:14:41 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Nov 2 06:23:24 2006 Subject: [GRASS-dev] Windows-style Pathnames In-Reply-To: <17737.4290.419895.264288@cerise.gclements.plus.com> References: <17737.4290.419895.264288@cerise.gclements.plus.com> Message-ID: <20061102181441.462c86e8.hamish_nospam@yahoo.com> Glynn Clements wrote: > However, using / should work as an argument to fopen(). The issue is > more significant if paths are constructed and stored for later use > (e.g. in $GISRC). In that situation, we need to decide whether to: > > 1. create and store the pathname in the host's syntax, or > 2. store it in Unix syntax and convert it as required. > > Either option will involve a lot of changes. #1 is easier to > implement, but will probably need to be done in more places (it needs > to be done for every pathname which might need to be in host syntax at > some point). #2 is harder, but only needs to be performed in places > where host syntax is known to be necessary. option #1 means that moving a GISDBASE from window->unix will result in breakage? If it were limited to .grassrc6 it wouldn't be too much of a problem, but what about path names stored in the data? G63> cd $MAPSET G63> cat VAR GV_DRIVER: dbf GV_DATABASE: $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ DB_DRIVER: dbf DB_DATABASE: $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ G63> cat vector/$VECT_MAP/dbln 1 Depth cat $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ dbf so option #2 is probably more robust. Hamish From michael.barton at asu.edu Thu Nov 2 06:53:43 2006 From: michael.barton at asu.edu (Michael Barton) Date: Thu Nov 2 06:53:51 2006 Subject: FW: [GRASS-dev] Zooming issue in gis manager In-Reply-To: Message-ID: The original post here didn't make it past the list file size filter. So I've reduced it to one graphic that should make it. I've also done a few more tests. In addition to what I mention below, g.region run without the -a flag creates rounding errors in resolution--minimal but annoying. Without the -a flag, the number of cells displayed accurately reflects the actual display region setting. So if you save the display region to the WIND file, and reset the display to match the new current region (i.e., WIND file), it looks the same as before. But, as noted below, it does this by shrinking the cells a bit to make them squeeze into the PPM output created by the PNG driver (could the X-driver be doing this differently???). With the -a flag, the number of rows or columns displayed is one or two less than the number in the display region. This is not noticeable (and maybe doesn't even happen) when there are a lot of cells in the display, but can be noticeable when there are very few cells in the display. The result is that if you copy the display region to the WIND file and display it back again, you see more cells than you started with. This is the "correct" number of rows and columns, but it not what was displayed. However, there are no rounding errors in the resolution as reported by g.region. Is this all happening in g.region? The display driver? Or both? As I say below, I can't think of how gis.m could compensate for this. In the region computation, it would involve 'rounding' to the nearest resolution value. But how can you round to the nearest 0.0001543 degrees? ...or even the nearest 25m? There is no 'starting place' to round from, since the region boundary can potentially be anywhere theoretically. I'm going to put the -a flag back into gis.m to keep the resolution rounding errors out. If you want to set region with precision, especially in a close-up view with few cells showing in a raster, you need to use g.region. If you want to display a region in a close-up view of a raster, where the cell sizes are large compared with the display and pixel size, you'll need to use explore mode for now at least. As documented below and in the attached graphic, this does a good job of making a display with accurately rendered raster cells. Vectors either don't face these issues or have different ones, as they are not behaving parallel to rasters in this. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton ------ Forwarded Message From: Michael Barton Date: Wed, 01 Nov 2006 22:01:24 -0700 To: Glynn Clements Cc: grass-dev Conversation: [GRASS-dev] Zooming issue in gis manager Subject: Re: [GRASS-dev] Zooming issue in gis manager Glynn, This may not be the issue, but it does illustrate what you are talking about. I've shrunk the images quite a bit in the hopes they make it by the developer list filter. Both images are close-ups of Spearfish elevation_dem, with a 30m vector grid drawn over it (origin at 0,20 to make it align with the raster cells). G.region is run without the -a flag in both examples. "normal_mode.jpg" shows the map grid cells in the "normal" display mode that preserves resolution in the display region settings. Note the 30m resolution at the bottom of the display [THIS GRAPHIC IS NO LONGER ATTACHED; YOU JUST HAVE TO IMAGINE IT] "explore_mode.jpg" shows the same part of the map in the "explore" mode that greatly increases resolution when zoomed in like this. Note the 0.7m resolution at the bottom of the of the display. The overlaid vector grid ought to line up with the cells. In explore mode it does line up, because the 30m "cells" of the original DEM are actually composed of >1800 cells in this close-up display. D.rast is aligning with the tiny new cells, not the original 30m cells, and this is not noticeable because the new cells are so small compared with the display and pixel size. In normal mode, the grid cells are indeed 30x30m and d.rast does whatever it does to squeeze an integer number of cells into the display. This is noticeable because the cells are large relative to the display. The vector grid does not line up with the cells. I have no idea how the GIS Manager displays could compensate for d.rast behavior like this, though it only is a problem when the cell size is very large compared to pixel size. Ideally, I guess it should always "snap" to the grid resolution when displaying rasters (vectors seem to be another matter). But I haven't the foggiest notion of how this could be done with continuously variable window sizing and zoom box sizing. I'm not even clear if this is better done when setting the display resolution somehow (but what happens if you set the display to match the WIND file or a map?), or if this should be done when coming up with output PPM geometry (but how do you make it fit a canvas then?). If someone wants to give it a try, more power to them. Fortunately, the explore mode approach works quite nicely to produce a display of zoomed in cells that is precisely rendered. If you want to set the computational region from the display, switch to normal mode first (I took out the -a switch today, so this is working fine in that the region gets set to what it appears to be in the display); then switch back to explore mode to look at it. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Glynn Clements > Date: Thu, 2 Nov 2006 01:40:41 +0000 > To: Maciej Sieczka > Cc: Michael Barton , grass-dev > > Subject: Re: [GRASS-dev] Zooming issue in gis manager > > > Maciej Sieczka wrote: > >>> I think that the core problem is that d.rast cannot render an >>> arbitrary portion of a map; the rendered image has to be aligned to >>> the cell boundaries. >> >> Thanks Glynn. Another question - so how does is happen that the X >> monitors don't have that problem, while gis.m displays do? > > X displays have exactly the same problem. gis.m might have some > *other* problems, but the d.rast/libdisplay issue I was discussing > applies regardless. > >> I mean: >> >> 1. When I set a region to match, say, 5 cols/6 rows (using g.region) >> and d.rast on X monitor - I see 5 cols/6 rows of a raster. >> >> 2. And when I use d.zoom and set the display on X monitor so that I >> see, say, 3 cols/7 rows, and I do g.region -p - I see that my region >> indeed has 3 cols/7 rows, and the resolution has not changed while zooming. >> >> But when gis.m interacts modifies WIND to match it's display, we have, >> either, only the resolution, or only the number or rows and cols set >> properly, depending on if the g.region is used with or without -a. > > I would guess that d.zoom adjusts the bounds manually, whereas gis.m > uses "g.region -a". The latter does more than just preserve the > resolution; it also aligns the grid with the coordinate system's > origin, then aligns the bounds with that grid, rounding outwards (i.e. > enlarging the region). > > Thus, "panning" (moving the region without changing the e-w or n-s > differences) with "g.region -a" will change the size of the region if > the requested bounds aren't aligned to the grid, as it will round > opposing edges in opposite directions. > >>> The region always has an integer number of rows and columns. d.rast >>> always ensures that the entire region just fits inside the frame; one >>> pair of edges will always exactly touch the corresponding edges of the >>> region. >> >>> Thus, the rendered image will only ever show whole cells. You will >>> never get a situation where part of a cell is shown and the other part >>> cropped. >> >> But I don't even want it. I'm saying that gis.m interaction with WIND >> must not corrupt the resolution or the number of rows and cols. If that >> is not possible, then we should not ask people to use gis.m yet. Or >> disable the WIND<->gis.m interaction alltogether. > > So, you're complaining about the fact that preserving the resolution > means moving the bounds outwards by up to 1 cell in each direction, > right? Or something else? > > If it's the former, gis.m will need to adjust the bounds itself; there > isn't any g.region option which will do the right thing (it's possible > that this was what -a was supposed to do; it would make more sense > than the existing behaviour). > > If it's the latter, you'll need to explain more clearly. > >>> At magnifications significantly above unity, this is likely to be >>> problematic for interactive zooming. You either have to adjust the >>> bounds so that they aligh with the existing cell grid, or adjust the >>> resolution so that the cell grid aligns with the bounds. >> >> So having both bounds and resolution preserved when gis.m interatcs >> with WIND is not possible, is that what you mean? > > The distance between opposing edges has to be an integer multiple of > the resolution (i.e. the number of rows and columns must be integers). > > But that should be true even within gis.m. It's possible that gis.m > fails to enforce this requirement, in which case, it will end up being > enforced whenever gis.m interfaces with the rest of GRASS, either by > adjusting the bounds to fit the resolution or by adjusting the > resolution to fit the bounds. > > That isn't limited to updating the WIND file; it will also affect > rendering. If gis.m is reporting region parameters which don't satisfy > the "integer multiple" requirement, it's lying; the numbers will get > "corrected" as soon as they leave gis.m. > > -- > Glynn Clements ------ End of Forwarded Message -------------- next part -------------- A non-text attachment was scrubbed... Name: explore_mode.jpg Type: application/octet-stream Size: 43062 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061101/15506007/explore_mode-0001.obj From michael.barton at asu.edu Thu Nov 2 07:03:12 2006 From: michael.barton at asu.edu (Michael Barton) Date: Thu Nov 2 07:03:24 2006 Subject: [GRASS-dev] Re: georectifier fixes In-Reply-To: <20061102154155.7a5cfa31.hamish_nospam@yahoo.com> Message-ID: Hamish > From: Hamish > Date: Thu, 2 Nov 2006 15:41:55 +1300 > To: Otto Dassau > Cc: , > Subject: Re: georectifier fixes > > Otto Dassau wrote: >>> It is odd about the i.group problem. When I click the creat/edit >>> group button, it switches to the xy location/mapset and runs i.group >>> on my computer. What happens on yours? >> >> nothing, not even an error. I have a debian testing and compile GRASS >> with --with-tcltk-includes=/usr/include/tcl8.4. >> >> I don't know why it doesn't work. Maybe we should wait for someone >> else with debian testing who can try. Maybe I do something wrong. > > [debian/stable (sarge)] > > the problem I got: gis.m file->georectify "2. Create edit group" > switches to source location/mapset, but then switches back to original > mapset right away, so i.group runs in the target mapset instead of > source mapset. if you had already created a group in the source mapset > you can continue, but otherwise you're stuck. I "fixed" this by having i.group run modally. The georectifier script should not continue until you close i.group > > If I modify the source, adding "after 5000" to have the Tcl sleep for > 5sec after running i.group, I can get i.group to act in the source > mapset for a fleeting moment, but if I then cancel & reclick the folder > icon I then see the available groups in the originial (target) mapset. > This won't work, as you noted. > > That is what happens with 6.2.0. With the latest 6.3, clicking the "2." > button does nothing (although mapset changes fly by in the output > window). i.group is running as a modal command under x11 on my Mac. Obviously it is not running modally on your Debian system. Maybe Glynn or someone can offer a clue. I am running it in TclTk as ... Set cmd "i.group" Catch {exec -- $cmd} [I use catch because closing the i.group dialog generates a non-meaningful, non-fatal, but annoying TclTk error message] > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hamish_nospam at yahoo.com Thu Nov 2 07:56:44 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Nov 2 07:57:15 2006 Subject: [GRASS-dev] GRASS_GUI= at startup In-Reply-To: <20061031151343.005aba8a.hamish_nospam@yahoo.com> References: <4545CEE8.5050404@club.worldonline.be> <4545F60B.7090109@o2.pl> <2987.164.15.134.84.1162215086.squirrel@164.15.134.161> <45460D59.8020002@o2.pl> <20061031151343.005aba8a.hamish_nospam@yahoo.com> Message-ID: <20061102195644.0aabe524.hamish_nospam@yahoo.com> Hamish wrote: > with a mind to making long term users happy, and making the wxpython > development easier, I'd like to extend the GRASS_GUI variable. .. > with this patch you can also do > > grass63 -oldgui # for d.m > or > GRASS_GUI=d.m grass63 > or > GRASS_GUI=gis.m grass63 > or even > # rename it to whatever the wxpython GUI will be called > GRASS_GUI=wxpython grass63 > > when wx becomes the default just switch "grass63 -gui" to that target. > > grass remembers the last one you used and uses that as the default. now applied to 6.3-cvs. tweak as needed. (did we ever come up with a good name for the wxpython gui?) Hamish From hamish_nospam at yahoo.com Thu Nov 2 08:12:21 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Nov 2 08:13:12 2006 Subject: [GRASS-dev] Zooming issue in gis manager In-Reply-To: <17736.16639.94435.508993@cerise.gclements.plus.com> References: <17736.16639.94435.508993@cerise.gclements.plus.com> Message-ID: <20061102201221.7f34a035.hamish_nospam@yahoo.com> Glynn Clements wrote: > Given that the origin for most coordinate systems is a completely > arbitrary location arising from various completely arbitrary constants > (e.g. whichever round numbers where chosen as the false easting and > northing), I have no idea what the intended purpose of the -a flag is, > but I'm fairly sure that it shouldn't be used by default. it keeps you from needlessly resampling (degrading) your raster data as you zoom+pan around & create new maps using the new map bounds? Hamish From hamish_nospam at yahoo.com Thu Nov 2 08:16:01 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Nov 2 08:18:03 2006 Subject: [GRASS-dev] Zooming issue in gis manager In-Reply-To: <17737.2562.965291.612957@cerise.gclements.plus.com> References: <4548C179.8080801@o2.pl> <17737.2562.965291.612957@cerise.gclements.plus.com> Message-ID: <20061102201601.74f27776.hamish_nospam@yahoo.com> maybe "d.grid size=$res" helps explain what's going on in those screenshots a bit better. and/or v.mkgrid at the given resolution/origin. Hamish From hamish_nospam at yahoo.com Thu Nov 2 08:24:12 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Nov 2 08:26:50 2006 Subject: [GRASS-dev] Zooming issue in gis manager In-Reply-To: <17737.2562.965291.612957@cerise.gclements.plus.com> References: <4548C179.8080801@o2.pl> <17737.2562.965291.612957@cerise.gclements.plus.com> Message-ID: <20061102202412.588216ba.hamish_nospam@yahoo.com> Glynn Clements wrote: > > At magnifications significantly above unity, this is likely to be > problematic for interactive zooming. You either have to adjust the > bounds so that they aligh with the existing cell grid, or adjust the > resolution so that the cell grid aligns with the bounds. Surely adjusting the region bounds to match the data is better than adjusting the data (visually) to fit in the region bounds. The data is sacrosanct. The region bounds are a temporary whim. As long as the gui window's x,y cursor output etc keeps up to date with any adjustments, it doesn't seem very problematic to me to slightly nudge the zoom box to fit the data's resolution before rendering. Hamish From otto.dassau at gmx.de Thu Nov 2 08:31:54 2006 From: otto.dassau at gmx.de (Otto Dassau) Date: Thu Nov 2 08:31:56 2006 Subject: [GRASS-dev] Re: georectifier fixes In-Reply-To: <20061102154155.7a5cfa31.hamish_nospam@yahoo.com> References: <20061101202021.136274d6@localhost.localdomain> <20061101210952.6afc8c6a@localhost.localdomain> <20061102154155.7a5cfa31.hamish_nospam@yahoo.com> Message-ID: <20061102083154.0306f2a2@localhost.localdomain> On Thu, 2 Nov 2006 15:41:55 +1300 Hamish wrote: > Otto Dassau wrote: > > > It is odd about the i.group problem. When I click the creat/edit > > > group button, it switches to the xy location/mapset and runs i.group > > > on my computer. What happens on yours? > > > > nothing, not even an error. I have a debian testing and compile GRASS > > with --with-tcltk-includes=/usr/include/tcl8.4. > > > > I don't know why it doesn't work. Maybe we should wait for someone > > else with debian testing who can try. Maybe I do something wrong. > > [debian/stable (sarge)] > > the problem I got: gis.m file->georectify "2. Create edit group" > switches to source location/mapset, but then switches back to original > mapset right away, so i.group runs in the target mapset instead of > source mapset. if you had already created a group in the source mapset > you can continue, but otherwise you're stuck. > > If I modify the source, adding "after 5000" to have the Tcl sleep for > 5sec after running i.group, I can get i.group to act in the source > mapset for a fleeting moment, but if I then cancel & reclick the folder > icon I then see the available groups in the originial (target) mapset. > > > That is what happens with 6.2.0. With the latest 6.3, clicking the "2." > button does nothing (although mapset changes fly by in the output > window). changing line 347 as proposed by Michael in $GISBASE/etc/gm/georect.tcl # catch {exec -- $cmd} exec -- $cmd sais sth. like: Error: Parameter not set: maybe this helps: In GRASS 6.2.0RC3 it worked. Otto From hamish_nospam at yahoo.com Thu Nov 2 09:11:25 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Nov 2 09:14:54 2006 Subject: [GRASS-dev] Re: georectifier fixes In-Reply-To: <20061102083154.0306f2a2@localhost.localdomain> References: <20061101202021.136274d6@localhost.localdomain> <20061101210952.6afc8c6a@localhost.localdomain> <20061102154155.7a5cfa31.hamish_nospam@yahoo.com> <20061102083154.0306f2a2@localhost.localdomain> Message-ID: <20061102211125.51f86470.hamish_nospam@yahoo.com> Otto Dassau wrote: > > changing line 347 as proposed by Michael in > $GISBASE/etc/gm/georect.tcl > > # catch {exec -- $cmd} > exec -- $cmd > > sais sth. like: > > Error: Parameter not set: > > maybe this helps: In GRASS 6.2.0RC3 it worked. try exec -- $cmd --ui to force GUI mode. but is that running in current mapset (wrong) or switched to target mapset (correct)? Hamish From otto.dassau at gmx.de Thu Nov 2 10:11:33 2006 From: otto.dassau at gmx.de (Otto Dassau) Date: Thu Nov 2 10:11:36 2006 Subject: [GRASS-dev] Re: georectifier fixes In-Reply-To: <20061102211125.51f86470.hamish_nospam@yahoo.com> References: <20061101202021.136274d6@localhost.localdomain> <20061101210952.6afc8c6a@localhost.localdomain> <20061102154155.7a5cfa31.hamish_nospam@yahoo.com> <20061102083154.0306f2a2@localhost.localdomain> <20061102211125.51f86470.hamish_nospam@yahoo.com> Message-ID: <20061102101133.279759b7@localhost.localdomain> On Thu, 2 Nov 2006 21:11:25 +1300 Hamish wrote: > Otto Dassau wrote: > > > > changing line 347 as proposed by Michael in > > $GISBASE/etc/gm/georect.tcl > > > > # catch {exec -- $cmd} > > exec -- $cmd > > > > sais sth. like: > > > > Error: Parameter not set: > > > > maybe this helps: In GRASS 6.2.0RC3 it worked. > > > try > > exec -- $cmd --ui > > to force GUI mode. now it works. Clicking on the edit/create button opens the i.group window. > but is that running in current mapset (wrong) or switched to target > mapset (correct)? what do you mean here, it is running in current mapset. I list my procedure, maybe I missunderstand: - I start GRASS in spearfish/PERMANENT - I Import a not geocoded map (topographic map) - I start georectifier - I choose mapset PERMANENT - I choose a new group and the map I want to rectify - When I close the i.group window following message appears, but it still works: child process exited abnormally child process exited abnormally while executing "exec -- $cmd --ui" (procedure "GRMap::group" line 17) invoked from within "GRMap::group" ("uplevel" body line 1) invoked from within "uplevel \#0 $cmd" (procedure "Button::_release" line 18) invoked from within "Button::_release .grstart.mf.frame.group.a" (command bound to event) and set GCPs - Then I select the group a just created - I select the map to rectify - I start to set my GCPs and rectify. - The result is ok and in stored the current mapset PERMANENT. BTW: Is it intended that there are two ways to use the module? a) I set GCPs and fill in the appropriate coordinates in the 2nd column manually. b) I set GCPs and fill in the appropriate coordinates interactively opening a second monitor with a reference map where I click in the map to find the right coordinates. The coordinates are inserted in the rectifier then... regards, Otto > Hamish > From paul-grass at stjohnspoint.co.uk Thu Nov 2 10:48:42 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Thu Nov 2 10:48:47 2006 Subject: [GRASS-dev] Windows-style Pathnames In-Reply-To: <20061101234228.GA5009@localhost.tamu.edu> References: <17737.4290.419895.264288@cerise.gclements.plus.com> <20061101215211.GA3922@localhost.tamu.edu> <20061101234228.GA5009@localhost.tamu.edu> Message-ID: On Wed, 1 Nov 2006, Huidae Cho wrote: > No. MSys has a virtual root to wherever it is installed, so /usr/... > should be transformed to something like c:\msys\1.0\usr\... I doubt we > can completely avoid using this convention in winGRASS. But what I mean is if we avoid using this Msys-specific syntax to start with, then there should be no need to transform it into proper Windows pathnames. Where are the pathnames that you need to transform to Windows syntax being generated from? > >> I mean c:\grass\grassdata format is more correct, although as Glynn said >> c:/grass/grassdata works in a lot of circumstances and means very little in >> GRASS has to be changed (there are lots of C routines that form pathnames by >> concatenating strings with /). /c/grass/grassdata is Msys-specific and is >> specially interpreted by the Msys shell, right? I don't think there should be a >> need to use that format at all (except see Huidae's comment below). >> >>>> Either option will involve a lot of changes. #1 is easier to >>>> implement, but will probably need to be done in more places (it needs >>>> to be done for every pathname which might need to be in host syntax at >>>> some point). #2 is harder, but only needs to be performed in places >>>> where host syntax is known to be necessary. >>> I found #2 a better choice becase MSys shell scripts will be happier >>> with posix path. >> >> Using the form c:/grass/grassdata rather than /c/grass/grassdata has proven OK >> for me so far (mostly in the configure script and bits of shell scripting done >> in the installation process and Makefiles). Were there many examples where this >> format was problematic? > > One example is $PATH. ':' cannot be used in PATH because ':' is > already used for path separators in the MSys environment. For example, > exporting "PATH=c:/grass/bin:c:/msys/bin" in a shell script is > problematic while setting "PATH=c:/grass/bin;c:/msys/bin" (note ';' > separator) in a batch file (e.g., c:\msys\1.0\msys.bat) is OK since MSys > takes care of converting it to PATH=/c/grass/bin:/c/msys/bin. Good point. Perhaps there is an Msys command that can convert paths to Msys format before including them in the PATH? I feel though that this is a very specific problem with scripts changing the PATH and not worth changing the behaviour of the rest of GRASS just for it. > The Windows-style path causes another problem/inconvenience when it > comes to shell scripting because scripts have to deal with two types of > path styles in some cases. For example, it would be complicated to > implement "which" using $FOO if the script reads in a config file > directly. For this reason, I prefer UNIX-style pathnames even if host > syntax looks more reasonable. Not sure what you mean about implementing "which" using $FOO? How big a problem do you think this is? I would hazard a guess that in most cases Msys/Unix commands used in scripts will work OK with c:/grass/grassdata style paths used throughout. How many scripts set the PATH? Are there standard Msys functions or commands for converting a path between formats that we could use in some way? Paul From paul-grass at stjohnspoint.co.uk Thu Nov 2 10:58:16 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Thu Nov 2 10:58:19 2006 Subject: [GRASS-dev] Windows-style Pathnames In-Reply-To: <17737.21068.670434.23541@cerise.gclements.plus.com> References: <17737.4290.419895.264288@cerise.gclements.plus.com> <20061101215211.GA3922@localhost.tamu.edu> <17737.21068.670434.23541@cerise.gclements.plus.com> Message-ID: On Thu, 2 Nov 2006, Glynn Clements wrote: > Note that the backslash is a shell metacharacter, so it will have to > be protected from interpretation if it appears directly in a script or > user input. For that reason alone, perhaps easiest to use c:/grass/grassdata format as much as possible, at least as an interim measure? > The biggest problem with scripts is when MSys decides to be "clever" > and do automatic translation. IMHO, we would be better off using host > syntax throughout. OK but whether we use c:/ or c:\ we still have the same problem with setting the PATH in scripts Huidae was talking about. But it remains to be seen how big a problem it is I guess. > So far as I'm concerned, the "Windows" version > should be just that, and not an "MSys" version. If people can live > without the contents of the scripts directory, it shouldn't be > necessary for end users to even have MSys. Yes. I thought that but wasn't sure. So Msys and MinGW are needed only for compilation? And it should be possible for a user to run the scripts if necessary using another shell, not necessarily the Msys one? Perhaps determined by a GRASS_SH environment variable. And it's the shell's responsibility to make sure that the various Unix commands work OK when called from within its environment then. Am I making sense? From neteler at itc.it Thu Nov 2 11:15:01 2006 From: neteler at itc.it (Markus Neteler) Date: Thu Nov 2 11:15:02 2006 Subject: [GRASS-dev] r.resamp.stats method=sum artifacts In-Reply-To: <17737.29528.199863.47406@cerise.gclements.plus.com> References: <20061030174705.7d4b55fa.hamish_nospam@yahoo.com> <17734.24775.637180.964134@cerise.gclements.plus.com> <20061031170006.27954610.hamish_nospam@yahoo.com> <200610311117.58316.dylan.beaudette@gmail.com> <20061102170351.49fc2644.hamish_nospam@yahoo.com> <17737.29528.199863.47406@cerise.gclements.plus.com> Message-ID: <4549C525.7040701@itc.it> Glynn Clements wrote on 11/02/2006 05:26 AM: > Hamish wrote: > > >> I've added r.resamp.stats and r.resamp.interp to the GUI menus. >> (Raster->Devel) >> >> should r.resample be tagged for future removal? (same result as with: >> 'r.resamp.interp method=nearest' ???). >> > > No. > > r.resample uses libgis' built-in resampling, so it is guaranteed to > resample in an identical manner to other commands. > > "r.resamp.interp method=nearest" performs the resampling itself, so it > could produce slightly different results due to rounding errors. The > method=nearest option was only included for completeness; if you want > nearest-neighbour resampling, r.resample is preferred. > Honestly, this sounds confusing to me. Having NN method twice which produces slightly different results, is hard to explain to users. Markus From maris.gis at gmail.com Thu Nov 2 11:51:03 2006 From: maris.gis at gmail.com (=?utf-8?q?M=C4=81ris_Narti=C5=A1s?=) Date: Thu Nov 2 11:51:30 2006 Subject: [GRASS-dev] [bug #5252] (grass) Multicore hardware and grass In-Reply-To: <17737.25751.37693.82497@cerise.gclements.plus.com> References: <20061102011811.55E19101EE0@lists.intevation.de> <17737.25751.37693.82497@cerise.gclements.plus.com> Message-ID: <200611021251.04744.maris.gis@gmail.com> Hi, I'm not an expert in this area, but as troll (http://en.wikipedia.org/wiki/Internet_troll), I want to add my 0.02. Glynn is right - GRASS is not monolite app, that could be tweaked to work in paralell/threads. But individual modules could benefit from paralel processing. And here we come to political decision - how to paralelise it? It's realy important, because GRASS should use one paralelisation mehanism (we don't need one module that works with threads, second - Beowulfs and third works in SSI systems) and there are more than one option. Do we need GRASS to run on clusters? With modifications (like MPI for Beowulf) or by simply launching mupltiple processes (openMosx and other SSI). Or using threads (POSIX or GNU or ?) on slingle machine will be enough? IMHO result of such discussion should be a note to GRASS programmers manual like: "When You develop new module to work in paralel, You should use FOO to make it work on/like BAR". Maris. PS. Some time a go there where efforts to make GRASS run on Beowulf clusters. Is this subproject dead? On Thursday 02 November 2006 05:23, Glynn Clements wrote: > Request Tracker wrote: > > this bug's URL: http://intevation.de/rt/webrt?serial_num=5252 > > > > This time next year dual quad - core desktop systems should be readily > > available. What level of effort would it take for GRASS to be able to > > split the processing load between the multiple cores? > > Most of GRASS' processing is in the individual modules, so you would > have to re-write individual modules using multi-threaded algorithms. > > It doesn't help that the core GRASS libraries aren't remotely > thread-safe, and can't readily be made so given the nature of the > existing API. From grass4u at gmail.com Thu Nov 2 12:15:09 2006 From: grass4u at gmail.com (Huidae Cho) Date: Thu Nov 2 12:15:51 2006 Subject: [GRASS-dev] Windows-style Pathnames In-Reply-To: References: <17737.4290.419895.264288@cerise.gclements.plus.com> <20061101215211.GA3922@localhost.tamu.edu> <20061101234228.GA5009@localhost.tamu.edu> Message-ID: <20061102111509.GA21098@localhost.tamu.edu> On Thu, Nov 02, 2006 at 09:48:42AM +0000, Paul Kelly wrote: > On Wed, 1 Nov 2006, Huidae Cho wrote: > > >No. MSys has a virtual root to wherever it is installed, so /usr/... > >should be transformed to something like c:\msys\1.0\usr\... I doubt we > >can completely avoid using this convention in winGRASS. > > But what I mean is if we avoid using this Msys-specific syntax to start with, > then there should be no need to transform it into proper Windows pathnames. Got your point. > Where are the pathnames that you need to transform to Windows syntax being > generated from? Nothing comes up in my mind at the moment. > > >>I mean c:\grass\grassdata format is more correct, although as Glynn said > >>c:/grass/grassdata works in a lot of circumstances and means very little in > >>GRASS has to be changed (there are lots of C routines that form pathnames by > >>concatenating strings with /). /c/grass/grassdata is Msys-specific and is > >>specially interpreted by the Msys shell, right? I don't think there should > >>be a > >>need to use that format at all (except see Huidae's comment below). > >>>>Either option will involve a lot of changes. #1 is easier to > >>>>implement, but will probably need to be done in more places (it needs > >>>>to be done for every pathname which might need to be in host syntax at > >>>>some point). #2 is harder, but only needs to be performed in places > >>>>where host syntax is known to be necessary. > >>>I found #2 a better choice becase MSys shell scripts will be happier > >>>with posix path. > >>Using the form c:/grass/grassdata rather than /c/grass/grassdata has proven > >>OK > >>for me so far (mostly in the configure script and bits of shell scripting > >>done > >>in the installation process and Makefiles). Were there many examples where > >>this > >>format was problematic? > >One example is $PATH. ':' cannot be used in PATH because ':' is > >already used for path separators in the MSys environment. For example, > >exporting "PATH=c:/grass/bin:c:/msys/bin" in a shell script is > >problematic while setting "PATH=c:/grass/bin;c:/msys/bin" (note ';' > >separator) in a batch file (e.g., c:\msys\1.0\msys.bat) is OK since MSys > >takes care of converting it to PATH=/c/grass/bin:/c/msys/bin. > > Good point. Perhaps there is an Msys command that can convert paths to Msys > format before including them in the PATH? AFAIK, there are no converters for that. PATH was just an example. > I feel though that this is a very specific problem with scripts changing the > PATH and not worth changing the behaviour of the rest of GRASS just for it. > > >The Windows-style path causes another problem/inconvenience when it > >comes to shell scripting because scripts have to deal with two types of > >path styles in some cases. For example, it would be complicated to > >implement "which" using $FOO if the script reads in a config file > >directly. For this reason, I prefer UNIX-style pathnames even if host > >syntax looks more reasonable. > > Not sure what you mean about implementing "which" using $FOO? See #5 in SUBMITTING_SCRIPTS. What I mean is if we accept Windows-style path names, scripts should deal with both POSIX (/) and Windows (:, \) path names in some (maybe few?) cases. > How big a problem do you think this is? I would hazard a guess that in most I don't think this is a big problem. I'm wondering how many shell/GRASS variables actually store absolute paths. Probably, only GISDBASE in GISRC? As Hamish pointed out, since the data stores path names with / separator, c:/ is probably better than c:\? Huidae > cases Msys/Unix commands used in scripts will work OK with c:/grass/grassdata > style paths used throughout. How many scripts set the PATH? Are there standard > Msys functions or commands for converting a path between formats that we could > use in some way? > > Paul From grass4u at gmail.com Thu Nov 2 12:40:03 2006 From: grass4u at gmail.com (Huidae Cho) Date: Thu Nov 2 12:40:45 2006 Subject: [GRASS-dev] Windows-style Pathnames In-Reply-To: References: <17737.4290.419895.264288@cerise.gclements.plus.com> <20061101215211.GA3922@localhost.tamu.edu> <17737.21068.670434.23541@cerise.gclements.plus.com> Message-ID: <20061102114003.GB21098@localhost.tamu.edu> On Thu, Nov 02, 2006 at 09:58:16AM +0000, Paul Kelly wrote: > On Thu, 2 Nov 2006, Glynn Clements wrote: > > >Note that the backslash is a shell metacharacter, so it will have to > >be protected from interpretation if it appears directly in a script or > >user input. > > For that reason alone, perhaps easiest to use c:/grass/grassdata format as much > as possible, at least as an interim measure? > > >The biggest problem with scripts is when MSys decides to be "clever" > >and do automatic translation. IMHO, we would be better off using host > >syntax throughout. > > OK but whether we use c:/ or c:\ we still have the same problem with setting > the PATH in scripts Huidae was talking about. But it remains to be seen how big > a problem it is I guess. > > >So far as I'm concerned, the "Windows" version > >should be just that, and not an "MSys" version. If people can live > >without the contents of the scripts directory, it shouldn't be > >necessary for end users to even have MSys. > > Yes. I thought that but wasn't sure. So Msys and MinGW are needed only for > compilation? And it should be possible for a user to run the scripts if > necessary using another shell, not necessarily the Msys one? Perhaps determined > by a GRASS_SH environment variable. And it's the shell's responsibility to make > sure that the various Unix commands work OK when called from within its > environment then. Am I making sense? Then, can we safely assume that either c:/ or c:\ works well with ANY shell implementation? Huidae > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From soerengebbert at gmx.de Thu Nov 2 13:34:29 2006 From: soerengebbert at gmx.de (=?UTF-8?B?U8O2cmVuIEdlYmJlcnQ=?=) Date: Thu Nov 2 13:34:39 2006 Subject: [GRASS-dev] [bug #5252] (grass) Multicore hardware and grass In-Reply-To: <200611021251.04744.maris.gis@gmail.com> References: <20061102011811.55E19101EE0@lists.intevation.de> <17737.25751.37693.82497@cerise.gclements.plus.com> <200611021251.04744.maris.gis@gmail.com> Message-ID: <4549E5D5.3090708@gmx.de> Hi, there was a discussion on IRC how to parallelize grass to run on multicore computers. We came to the same conclusion as Glynn. The design of the GRASS core libs is not thread safe. And to port the core of grass to run in parallel on Beowulf clusters or SSI clusters is not practical. But GRASS can work in parallel already. :) Just start several modules on several maps and hope the disk IO is not the limiting factor. And this works on SSI clusters as well. I think we should think more simple. Since gcc version 4.2, OpenMP is available for normal C/C++/Fortran developers without access to commercial compilers. Individual modules can be parallelized for multicore systems with OpenMP (http://www.openmp.org). And i think to work with OpenMP is much easier than posix threads, MPI, BSP or SunGrid and stuff. But the main issues with GRASS and OpenMP are: 1.) You need some parallel programming experience or your programs will become slower in the end with OpenMP 2.) To debug multi threaded software is much harder than single thread software. 3.) The core libs are not thread safe, so you have to careful choose the library functions which are to use in parallel 4.) The data access to the harddisk dont scale in parallel on a single disk/conroler system, you will only benfit from OpenMP if you load the data to process completely in the memory 5.) ... So there are only a few modules which will benefit from simple parallelizing with OpenMP. To change this, the core of grass have to be implemented in a new and different way. But i think the grass developers have to think about to parallelize grass. Because the future computer generations will work with multiple cores (2 - 128?) and the users will expect that programms like grass will use the multicore power to work. This is not an easy task and needs a lot of programming knowledge ... well this can be added to the wish section for grass version 10? :) Just my two cent Soeren M?ris Narti?s schrieb: > Hi, > > I'm not an expert in this area, but as troll > (http://en.wikipedia.org/wiki/Internet_troll), I want to add my 0.02. > > Glynn is right - GRASS is not monolite app, that could be tweaked to work in > paralell/threads. But individual modules could benefit from paralel > processing. > > And here we come to political decision - how to paralelise it? It's realy > important, because GRASS should use one paralelisation mehanism (we don't > need one module that works with threads, second - Beowulfs and third works in > SSI systems) and there are more than one option. Do we need GRASS to run on > clusters? With modifications (like MPI for Beowulf) or by simply launching > mupltiple processes (openMosx and other SSI). Or using threads (POSIX or GNU > or ?) on slingle machine will be enough? > > IMHO result of such discussion should be a note to GRASS programmers manual > like: "When You develop new module to work in paralel, You should use FOO to > make it work on/like BAR". > > Maris. > > PS. Some time a go there where efforts to make GRASS run on Beowulf clusters. > Is this subproject dead? > > On Thursday 02 November 2006 05:23, Glynn Clements wrote: >> Request Tracker wrote: >>> this bug's URL: http://intevation.de/rt/webrt?serial_num=5252 >>> >>> This time next year dual quad - core desktop systems should be readily >>> available. What level of effort would it take for GRASS to be able to >>> split the processing load between the multiple cores? >> Most of GRASS' processing is in the individual modules, so you would >> have to re-write individual modules using multi-threaded algorithms. >> >> It doesn't help that the core GRASS libraries aren't remotely >> thread-safe, and can't readily be made so given the nature of the >> existing API. > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > > From michael.barton at asu.edu Thu Nov 2 14:22:56 2006 From: michael.barton at asu.edu (Michael Barton) Date: Thu Nov 2 14:23:06 2006 Subject: [GRASS-dev] Re: georectifier fixes In-Reply-To: <20061102101133.279759b7@localhost.localdomain> Message-ID: I'm a bit confused. Could clarify the following. 1. Did the new georect.tcl work -- the one in the 6.3 head? This one *should* switch to the source mapset, run i.group, and wait until you're done before switching back to the target mapset. 2. If it did not work, did you get the following error with the newest georect.tcl? Error: Parameter not set: This is an i.group error that suggests this grass command failed for some reason 3. If the newest version (i.e., in the 6.3 head) works with adding the --ui switch, that's fantastic. But I need to know if that actually fixes it for you guys or if it was already fixed without this. MIchael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Otto Dassau > Date: Thu, 2 Nov 2006 10:11:33 +0100 > To: Hamish > Cc: , > Subject: Re: georectifier fixes > > On Thu, 2 Nov 2006 21:11:25 +1300 > Hamish wrote: > >> Otto Dassau wrote: >>> >>> changing line 347 as proposed by Michael in >>> $GISBASE/etc/gm/georect.tcl >>> >>> # catch {exec -- $cmd} >>> exec -- $cmd >>> >>> sais sth. like: >>> >>> Error: Parameter not set: >>> >>> maybe this helps: In GRASS 6.2.0RC3 it worked. >> >> >> try >> >> exec -- $cmd --ui >> >> to force GUI mode. > > now it works. Clicking on the edit/create button opens the i.group window. > >> but is that running in current mapset (wrong) or switched to target >> mapset (correct)? > > what do you mean here, it is running in current mapset. I list my procedure, > maybe I missunderstand: > > - I start GRASS in spearfish/PERMANENT > - I Import a not geocoded map (topographic map) > - I start georectifier > - I choose mapset PERMANENT > - I choose a new group and the map I want to rectify > - When I close the i.group window following message appears, but it still > works: > > child process exited abnormally > child process exited abnormally > while executing > "exec -- $cmd --ui" > (procedure "GRMap::group" line 17) > invoked from within > "GRMap::group" > ("uplevel" body line 1) > invoked from within > "uplevel \#0 $cmd" > (procedure "Button::_release" line 18) > invoked from within > "Button::_release .grstart.mf.frame.group.a" > (command bound to event) > and set GCPs > > - Then I select the group a just created > - I select the map to rectify > - I start to set my GCPs and rectify. > - The result is ok and in stored the current mapset PERMANENT. > > > BTW: Is it intended that there are two ways to use the module? > > a) I set GCPs and fill in the appropriate coordinates in the 2nd column > manually. > b) I set GCPs and fill in the appropriate coordinates interactively opening a > second monitor with a reference map where I click in the map to find > the right coordinates. The coordinates are inserted in the rectifier then... > > regards, > Otto > >> Hamish >> > From tlaronde at polynum.com Thu Nov 2 14:35:41 2006 From: tlaronde at polynum.com (tlaronde@polynum.com) Date: Thu Nov 2 14:32:46 2006 Subject: [GRASS-dev] GRASS/KerGIS fonts: hershey revival In-Reply-To: <20061031012132.GA5880@polynum.com> References: <20061031012132.GA5880@polynum.com> Message-ID: <20061102133541.GA616@polynum.com> On Tue, Oct 31, 2006 at 02:21:32AM +0100, tlaronde@polynum.com wrote: > > What has to be done, is to map the glyph number in the occidental and > oriental sets to some well-known encoding. That's where the GPL GRASS > user base, specially for the oriental set, could help. Never mind. As usual, due to the lack of interest of others, I have found a way to do the mapping by myself even if I do no nothing about Kanji etc... Unicode.org has pdf with the glyphes representation and their unicode. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C From michael.barton at asu.edu Thu Nov 2 15:39:51 2006 From: michael.barton at asu.edu (Michael Barton) Date: Thu Nov 2 15:40:08 2006 Subject: [GRASS-dev] GRASS/KerGIS fonts: hershey revival In-Reply-To: <20061102133541.GA616@polynum.com> Message-ID: Sorry Thierry. Everyone was working overtime to get GRASS 6.2 out the door. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: > Date: Thu, 2 Nov 2006 14:35:41 +0100 > To: grass developers list > Subject: Re: [GRASS-dev] GRASS/KerGIS fonts: hershey revival > > On Tue, Oct 31, 2006 at 02:21:32AM +0100, tlaronde@polynum.com wrote: >> >> What has to be done, is to map the glyph number in the occidental and >> oriental sets to some well-known encoding. That's where the GPL GRASS >> user base, specially for the oriental set, could help. > > Never mind. As usual, due to the lack of interest of others, I have > found a way to do the mapping by myself even if I do no nothing about > Kanji etc... Unicode.org has pdf with the glyphes representation and > their unicode. > -- > Thierry Laronde (Alceste) > http://www.kergis.com/ > Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C > > From ychemin at gmail.com Thu Nov 2 16:02:49 2006 From: ychemin at gmail.com (Yann Chemin) Date: Thu Nov 2 16:02:53 2006 Subject: [GRASS-dev] [bug #5252] (grass) Multicore hardware and grass In-Reply-To: <4549E5D5.3090708@gmx.de> References: <20061102011811.55E19101EE0@lists.intevation.de> <17737.25751.37693.82497@cerise.gclements.plus.com> <200611021251.04744.maris.gis@gmail.com> <4549E5D5.3090708@gmx.de> Message-ID: <6278879c0611020702q3ced1ec1rc1152dc548986f23@mail.gmail.com> > > But i think the grass developers have to think about to parallelize > grass. Because the future computer generations will work with multiple > cores (2 - 128?) and the users will expect that programms like grass > will use the multicore power to work. This is not an easy task and needs > a lot of programming knowledge ... well this can be added to the wish > section for grass version 10? :) > I'd like to work on that for version 10+ of GRASS (i'll have to learn a lot, but ready to!) Yep, i also think that users will expect such thing from GRASS/any GIS software. From otto.dassau at gmx.de Thu Nov 2 19:40:48 2006 From: otto.dassau at gmx.de (Otto Dassau) Date: Thu Nov 2 19:40:47 2006 Subject: [GRASS-dev] Re: georectifier fixes In-Reply-To: References: <20061102101133.279759b7@localhost.localdomain> Message-ID: <20061102194048.3138c81d@localhost.localdomain> On Thu, 02 Nov 2006 06:22:56 -0700 Michael Barton wrote: > I'm a bit confused. Could clarify the following. Hi, > 1. Did the new georect.tcl work -- the one in the 6.3 head? This one > *should* switch to the source mapset, run i.group, and wait until you're > done before switching back to the target mapset. yes, it works in the 6.3 head here. I rectified a map this morning using the georectifier in 6.3 head. > 2. If it did not work, did you get the following error with the newest > georect.tcl? > Error: Parameter not set: > This is an i.group error that suggests this grass command failed for some > reason > > 3. If the newest version (i.e., in the 6.3 head) works with adding the --ui > switch, that's fantastic. But I need to know if that actually fixes it for > you guys or if it was already fixed without this. the i.group window opens, but when I close the "error" message below appears, but I can still go on rectiifying. child process exited abnormally child process exited abnormally while executing "exec -- $cmd --ui" (procedure "GRMap::group" line 17) invoked from within "GRMap::group" ("uplevel" body line 1) invoked from within "uplevel \#0 $cmd" (procedure "Button::_release" line 18) invoked from within "Button::_release .grstart.mf.frame.group.a" (command bound to event) and set GCPs is it clearer now? regards, Otto PS: currently I am only online from time to time - sorry. > > works: > MIchael > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > > > From: Otto Dassau > > Date: Thu, 2 Nov 2006 10:11:33 +0100 > > To: Hamish > > Cc: , > > Subject: Re: georectifier fixes > > > > On Thu, 2 Nov 2006 21:11:25 +1300 > > Hamish wrote: > > > >> Otto Dassau wrote: > >>> > >>> changing line 347 as proposed by Michael in > >>> $GISBASE/etc/gm/georect.tcl > >>> > >>> # catch {exec -- $cmd} > >>> exec -- $cmd > >>> > >>> sais sth. like: > >>> > >>> Error: Parameter not set: > >>> > >>> maybe this helps: In GRASS 6.2.0RC3 it worked. > >> > >> > >> try > >> > >> exec -- $cmd --ui > >> > >> to force GUI mode. > > > > now it works. Clicking on the edit/create button opens the i.group window. > > > >> but is that running in current mapset (wrong) or switched to target > >> mapset (correct)? > > > > what do you mean here, it is running in current mapset. I list my procedure, > > maybe I missunderstand: > > > > - I start GRASS in spearfish/PERMANENT > > - I Import a not geocoded map (topographic map) > > - I start georectifier > > - I choose mapset PERMANENT > > - I choose a new group and the map I want to rectify > > - When I close the i.group window following message appears, but it still > > works: > > > > child process exited abnormally > > child process exited abnormally > > while executing > > "exec -- $cmd --ui" > > (procedure "GRMap::group" line 17) > > invoked from within > > "GRMap::group" > > ("uplevel" body line 1) > > invoked from within > > "uplevel \#0 $cmd" > > (procedure "Button::_release" line 18) > > invoked from within > > "Button::_release .grstart.mf.frame.group.a" > > (command bound to event) > > and set GCPs > > > > - Then I select the group a just created > > - I select the map to rectify > > - I start to set my GCPs and rectify. > > - The result is ok and in stored the current mapset PERMANENT. > > > > > > BTW: Is it intended that there are two ways to use the module? > > > > a) I set GCPs and fill in the appropriate coordinates in the 2nd column > > manually. > > b) I set GCPs and fill in the appropriate coordinates interactively opening a > > second monitor with a reference map where I click in the map to find > > the right coordinates. The coordinates are inserted in the rectifier then... > > > > regards, > > Otto > > > >> Hamish > >> > > > -- From michael.barton at asu.edu Thu Nov 2 20:10:15 2006 From: michael.barton at asu.edu (Michael Barton) Date: Thu Nov 2 20:10:45 2006 Subject: [GRASS-dev] Re: georectifier fixes In-Reply-To: <20061102194048.3138c81d@localhost.localdomain> Message-ID: It sounds like you just need to put it back the way it was before. That is, put the "catch {exec -- $cmd}" back in. Using the "catch" statement traps this annoying error message. Do you need the --ui flag? Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Otto Dassau > Date: Thu, 2 Nov 2006 19:40:48 +0100 > To: Michael Barton > Cc: Hamish , > Subject: Re: georectifier fixes > > On Thu, 02 Nov 2006 06:22:56 -0700 > Michael Barton wrote: > >> I'm a bit confused. Could clarify the following. > > Hi, > >> 1. Did the new georect.tcl work -- the one in the 6.3 head? This one >> *should* switch to the source mapset, run i.group, and wait until you're >> done before switching back to the target mapset. > > yes, it works in the 6.3 head here. I rectified a map this morning using the > georectifier in 6.3 head. > >> 2. If it did not work, did you get the following error with the newest >> georect.tcl? >> Error: Parameter not set: >> This is an i.group error that suggests this grass command failed for some >> reason >> >> 3. If the newest version (i.e., in the 6.3 head) works with adding the --ui >> switch, that's fantastic. But I need to know if that actually fixes it for >> you guys or if it was already fixed without this. > > the i.group window opens, but when I close the "error" message below appears, > but I can still go on rectiifying. > > child process exited abnormally > child process exited abnormally > while executing > "exec -- $cmd --ui" > (procedure "GRMap::group" line 17) > invoked from within > "GRMap::group" > ("uplevel" body line 1) > invoked from within > "uplevel \#0 $cmd" > (procedure "Button::_release" line 18) > invoked from within > "Button::_release .grstart.mf.frame.group.a" > (command bound to event) > and set GCPs > > is it clearer now? > > regards, > Otto > > PS: currently I am only online from time to time - sorry. > >>> works: > >> MIchael >> __________________________________________ >> Michael Barton, Professor of Anthropology >> School of Human Evolution & Social Change >> Center for Social Dynamics & Complexity >> Arizona State University >> >> phone: 480-965-6213 >> fax: 480-965-7671 >> www: http://www.public.asu.edu/~cmbarton >> >> >> >>> From: Otto Dassau >>> Date: Thu, 2 Nov 2006 10:11:33 +0100 >>> To: Hamish >>> Cc: , >>> Subject: Re: georectifier fixes >>> >>> On Thu, 2 Nov 2006 21:11:25 +1300 >>> Hamish wrote: >>> >>>> Otto Dassau wrote: >>>>> >>>>> changing line 347 as proposed by Michael in >>>>> $GISBASE/etc/gm/georect.tcl >>>>> >>>>> # catch {exec -- $cmd} >>>>> exec -- $cmd >>>>> >>>>> sais sth. like: >>>>> >>>>> Error: Parameter not set: >>>>> >>>>> maybe this helps: In GRASS 6.2.0RC3 it worked. >>>> >>>> >>>> try >>>> >>>> exec -- $cmd --ui >>>> >>>> to force GUI mode. >>> >>> now it works. Clicking on the edit/create button opens the i.group window. >>> >>>> but is that running in current mapset (wrong) or switched to target >>>> mapset (correct)? >>> >>> what do you mean here, it is running in current mapset. I list my procedure, >>> maybe I missunderstand: >>> >>> - I start GRASS in spearfish/PERMANENT >>> - I Import a not geocoded map (topographic map) >>> - I start georectifier >>> - I choose mapset PERMANENT >>> - I choose a new group and the map I want to rectify >>> - When I close the i.group window following message appears, but it still >>> works: >>> >>> child process exited abnormally >>> child process exited abnormally >>> while executing >>> "exec -- $cmd --ui" >>> (procedure "GRMap::group" line 17) >>> invoked from within >>> "GRMap::group" >>> ("uplevel" body line 1) >>> invoked from within >>> "uplevel \#0 $cmd" >>> (procedure "Button::_release" line 18) >>> invoked from within >>> "Button::_release .grstart.mf.frame.group.a" >>> (command bound to event) >>> and set GCPs >>> >>> - Then I select the group a just created >>> - I select the map to rectify >>> - I start to set my GCPs and rectify. >>> - The result is ok and in stored the current mapset PERMANENT. >>> >>> >>> BTW: Is it intended that there are two ways to use the module? >>> >>> a) I set GCPs and fill in the appropriate coordinates in the 2nd column >>> manually. >>> b) I set GCPs and fill in the appropriate coordinates interactively opening > a >>> second monitor with a reference map where I click in the map to find >>> the right coordinates. The coordinates are inserted in the rectifier then... >>> >>> regards, >>> Otto >>> >>>> Hamish >>>> >>> >> > > > -- > From paul-grass at stjohnspoint.co.uk Thu Nov 2 20:52:08 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Thu Nov 2 20:52:20 2006 Subject: [GRASS-dev] Windows-style Pathnames In-Reply-To: <17737.4290.419895.264288@cerise.gclements.plus.com> References: <17737.4290.419895.264288@cerise.gclements.plus.com> Message-ID: On Wed, 1 Nov 2006, Glynn Clements wrote: > For the above case, there should probably be a > G_is_directory_separator() function which determines whether or not > its argument is a directory separator on the host platform. OK, I'm looking at this now. So on Windows that function would return true for both '\\' and '/' being passed to it, and on Unix only for '/'? > There also needs to be a macro (e.g. DIRSEP) which expands to the > preferred separator. While Windows accepts both / and \ in a lot of > situations, there are some (notably command lines) where only \ works. Yes. Although when constructing a command line, often part of the path is already constructed for you (e.g. the output of G_gisbase() ). So I think perhaps a function that took a string as an argument and made sure all the directory separators in it were the preferred ones for that host, might be useful. I'll look at doing that. From michael.barton at asu.edu Thu Nov 2 23:40:02 2006 From: michael.barton at asu.edu (Michael Barton) Date: Thu Nov 2 23:40:19 2006 Subject: [GRASS-dev] Re: georectifier fixes for Debian In-Reply-To: <20061102194048.3138c81d@localhost.localdomain> Message-ID: Otto and Hamish, I got a student here with Debian Ubuntu (Mepis) to try the --ui switch for the i.group command in georectify.tcl. It seems to solve the problem of i.group flashing on and off. Thanks very much Hamish for suggesting it. It's in the cvs now. I'm copying Markus so that he can backport it to 6.2.1 Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Otto Dassau > Date: Thu, 2 Nov 2006 19:40:48 +0100 > To: Michael Barton > Cc: Hamish , > Subject: Re: georectifier fixes > > On Thu, 02 Nov 2006 06:22:56 -0700 > Michael Barton wrote: > >> I'm a bit confused. Could clarify the following. > > Hi, > >> 1. Did the new georect.tcl work -- the one in the 6.3 head? This one >> *should* switch to the source mapset, run i.group, and wait until you're >> done before switching back to the target mapset. > > yes, it works in the 6.3 head here. I rectified a map this morning using the > georectifier in 6.3 head. > >> 2. If it did not work, did you get the following error with the newest >> georect.tcl? >> Error: Parameter not set: >> This is an i.group error that suggests this grass command failed for some >> reason >> >> 3. If the newest version (i.e., in the 6.3 head) works with adding the --ui >> switch, that's fantastic. But I need to know if that actually fixes it for >> you guys or if it was already fixed without this. > > the i.group window opens, but when I close the "error" message below appears, > but I can still go on rectiifying. > > child process exited abnormally > child process exited abnormally > while executing > "exec -- $cmd --ui" > (procedure "GRMap::group" line 17) > invoked from within > "GRMap::group" > ("uplevel" body line 1) > invoked from within > "uplevel \#0 $cmd" > (procedure "Button::_release" line 18) > invoked from within > "Button::_release .grstart.mf.frame.group.a" > (command bound to event) > and set GCPs > > is it clearer now? > > regards, > Otto > > PS: currently I am only online from time to time - sorry. > >>> works: > >> MIchael >> __________________________________________ >> Michael Barton, Professor of Anthropology >> School of Human Evolution & Social Change >> Center for Social Dynamics & Complexity >> Arizona State University >> >> phone: 480-965-6213 >> fax: 480-965-7671 >> www: http://www.public.asu.edu/~cmbarton >> >> >> >>> From: Otto Dassau >>> Date: Thu, 2 Nov 2006 10:11:33 +0100 >>> To: Hamish >>> Cc: , >>> Subject: Re: georectifier fixes >>> >>> On Thu, 2 Nov 2006 21:11:25 +1300 >>> Hamish wrote: >>> >>>> Otto Dassau wrote: >>>>> >>>>> changing line 347 as proposed by Michael in >>>>> $GISBASE/etc/gm/georect.tcl >>>>> >>>>> # catch {exec -- $cmd} >>>>> exec -- $cmd >>>>> >>>>> sais sth. like: >>>>> >>>>> Error: Parameter not set: >>>>> >>>>> maybe this helps: In GRASS 6.2.0RC3 it worked. >>>> >>>> >>>> try >>>> >>>> exec -- $cmd --ui >>>> >>>> to force GUI mode. >>> >>> now it works. Clicking on the edit/create button opens the i.group window. >>> >>>> but is that running in current mapset (wrong) or switched to target >>>> mapset (correct)? >>> >>> what do you mean here, it is running in current mapset. I list my procedure, >>> maybe I missunderstand: >>> >>> - I start GRASS in spearfish/PERMANENT >>> - I Import a not geocoded map (topographic map) >>> - I start georectifier >>> - I choose mapset PERMANENT >>> - I choose a new group and the map I want to rectify >>> - When I close the i.group window following message appears, but it still >>> works: >>> >>> child process exited abnormally >>> child process exited abnormally >>> while executing >>> "exec -- $cmd --ui" >>> (procedure "GRMap::group" line 17) >>> invoked from within >>> "GRMap::group" >>> ("uplevel" body line 1) >>> invoked from within >>> "uplevel \#0 $cmd" >>> (procedure "Button::_release" line 18) >>> invoked from within >>> "Button::_release .grstart.mf.frame.group.a" >>> (command bound to event) >>> and set GCPs >>> >>> - Then I select the group a just created >>> - I select the map to rectify >>> - I start to set my GCPs and rectify. >>> - The result is ok and in stored the current mapset PERMANENT. >>> >>> >>> BTW: Is it intended that there are two ways to use the module? >>> >>> a) I set GCPs and fill in the appropriate coordinates in the 2nd column >>> manually. >>> b) I set GCPs and fill in the appropriate coordinates interactively opening > a >>> second monitor with a reference map where I click in the map to find >>> the right coordinates. The coordinates are inserted in the rectifier then... >>> >>> regards, >>> Otto >>> >>>> Hamish >>>> >>> >> > > > -- > From neteler at itc.it Fri Nov 3 00:13:45 2006 From: neteler at itc.it (Markus Neteler) Date: Fri Nov 3 00:13:47 2006 Subject: [GRASS-dev] Re: georectifier fixes for Debian In-Reply-To: References: <20061102194048.3138c81d@localhost.localdomain> Message-ID: <20061102231345.GA18908@bartok.itc.it> Michael, all, I have backported the today's changes to gis.m in 6.2-cvs. Also re-done the CVS snapshot for easy testing: http://grass.itc.it/grass62/source/snapshot/ Markus On Thu, Nov 02, 2006 at 03:40:02PM -0700, Michael Barton wrote: > Otto and Hamish, > > I got a student here with Debian Ubuntu (Mepis) to try the --ui switch for > the i.group command in georectify.tcl. It seems to solve the problem of > i.group flashing on and off. > > Thanks very much Hamish for suggesting it. It's in the cvs now. I'm copying > Markus so that he can backport it to 6.2.1 > > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics and Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > > From: Otto Dassau > > Date: Thu, 2 Nov 2006 19:40:48 +0100 > > To: Michael Barton > > Cc: Hamish , > > Subject: Re: georectifier fixes > > > > On Thu, 02 Nov 2006 06:22:56 -0700 > > Michael Barton wrote: > > > >> I'm a bit confused. Could clarify the following. > > > > Hi, > > > >> 1. Did the new georect.tcl work -- the one in the 6.3 head? This one > >> *should* switch to the source mapset, run i.group, and wait until you're > >> done before switching back to the target mapset. > > > > yes, it works in the 6.3 head here. I rectified a map this morning using the > > georectifier in 6.3 head. > > > >> 2. If it did not work, did you get the following error with the newest > >> georect.tcl? > >> Error: Parameter not set: > >> This is an i.group error that suggests this grass command failed for some > >> reason > >> > >> 3. If the newest version (i.e., in the 6.3 head) works with adding the --ui > >> switch, that's fantastic. But I need to know if that actually fixes it for > >> you guys or if it was already fixed without this. > > > > the i.group window opens, but when I close the "error" message below appears, > > but I can still go on rectiifying. > > > > child process exited abnormally > > child process exited abnormally > > while executing > > "exec -- $cmd --ui" > > (procedure "GRMap::group" line 17) > > invoked from within > > "GRMap::group" > > ("uplevel" body line 1) > > invoked from within > > "uplevel \#0 $cmd" > > (procedure "Button::_release" line 18) > > invoked from within > > "Button::_release .grstart.mf.frame.group.a" > > (command bound to event) > > and set GCPs > > > > is it clearer now? > > > > regards, > > Otto > > > > PS: currently I am only online from time to time - sorry. > > > >>> works: > > > >> MIchael > >> __________________________________________ > >> Michael Barton, Professor of Anthropology > >> School of Human Evolution & Social Change > >> Center for Social Dynamics & Complexity > >> Arizona State University > >> > >> phone: 480-965-6213 > >> fax: 480-965-7671 > >> www: http://www.public.asu.edu/~cmbarton > >> > >> > >> > >>> From: Otto Dassau > >>> Date: Thu, 2 Nov 2006 10:11:33 +0100 > >>> To: Hamish > >>> Cc: , > >>> Subject: Re: georectifier fixes > >>> > >>> On Thu, 2 Nov 2006 21:11:25 +1300 > >>> Hamish wrote: > >>> > >>>> Otto Dassau wrote: > >>>>> > >>>>> changing line 347 as proposed by Michael in > >>>>> $GISBASE/etc/gm/georect.tcl > >>>>> > >>>>> # catch {exec -- $cmd} > >>>>> exec -- $cmd > >>>>> > >>>>> sais sth. like: > >>>>> > >>>>> Error: Parameter not set: > >>>>> > >>>>> maybe this helps: In GRASS 6.2.0RC3 it worked. > >>>> > >>>> > >>>> try > >>>> > >>>> exec -- $cmd --ui > >>>> > >>>> to force GUI mode. > >>> > >>> now it works. Clicking on the edit/create button opens the i.group window. > >>> > >>>> but is that running in current mapset (wrong) or switched to target > >>>> mapset (correct)? > >>> > >>> what do you mean here, it is running in current mapset. I list my procedure, > >>> maybe I missunderstand: > >>> > >>> - I start GRASS in spearfish/PERMANENT > >>> - I Import a not geocoded map (topographic map) > >>> - I start georectifier > >>> - I choose mapset PERMANENT > >>> - I choose a new group and the map I want to rectify > >>> - When I close the i.group window following message appears, but it still > >>> works: > >>> > >>> child process exited abnormally > >>> child process exited abnormally > >>> while executing > >>> "exec -- $cmd --ui" > >>> (procedure "GRMap::group" line 17) > >>> invoked from within > >>> "GRMap::group" > >>> ("uplevel" body line 1) > >>> invoked from within > >>> "uplevel \#0 $cmd" > >>> (procedure "Button::_release" line 18) > >>> invoked from within > >>> "Button::_release .grstart.mf.frame.group.a" > >>> (command bound to event) > >>> and set GCPs > >>> > >>> - Then I select the group a just created > >>> - I select the map to rectify > >>> - I start to set my GCPs and rectify. > >>> - The result is ok and in stored the current mapset PERMANENT. > >>> > >>> > >>> BTW: Is it intended that there are two ways to use the module? > >>> > >>> a) I set GCPs and fill in the appropriate coordinates in the 2nd column > >>> manually. > >>> b) I set GCPs and fill in the appropriate coordinates interactively opening > > a > >>> second monitor with a reference map where I click in the map to find > >>> the right coordinates. The coordinates are inserted in the rectifier then... > >>> > >>> regards, > >>> Otto > >>> > >>>> Hamish > >>>> > >>> > >> > > > > > > -- > > > -- Markus Neteler http://mpa.itc.it/markus/ ITC-irst - Centro per la Ricerca Scientifica e Tecnologica MPBA - Predictive Models for Biol. & Environ. Data Analysis Via Sommarive, 18 - 38050 Povo (Trento), Italy From neteler at itc.it Fri Nov 3 00:14:24 2006 From: neteler at itc.it (Markus Neteler) Date: Fri Nov 3 00:14:25 2006 Subject: [GRASS-dev] CVS: all images touched? Message-ID: <20061102231423.GB18908@bartok.itc.it> Hi, something strange happened: all images in 6.2 and 6.3 were re-downloaded from CVS while syncing. How come? In the commit-logs is nothing. Markus From hamish_nospam at yahoo.com Fri Nov 3 00:26:55 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Nov 3 00:44:17 2006 Subject: [GRASS-dev] Zooming issue in gis manager In-Reply-To: <17737.5705.548999.931493@cerise.gclements.plus.com> References: <4548C179.8080801@o2.pl> <17737.2562.965291.612957@cerise.gclements.plus.com> <17737.5705.548999.931493@cerise.gclements.plus.com> Message-ID: <20061103122655.6608d707.hamish_nospam@yahoo.com> Glynn Clements wrote: > > How much difficulty would it be to alter the behaviour of d.rast to > > allow partial > > cells to be rendered? > > > > If someone were to make the change, can anyone think of what flow on > > effects this would have for other components of GRASS? (Not too much > > of an issue since a flag could be added to d.rast to have this as > > optional behaviour). > > It isn't trivial, for reasons of both implementation and design. > > d.rast uses various functions from lib/display to do most of the work. > > Either these functions would need to be changed, or d.rast would need > to be re-implemented without them. > > The main one is D_do_conversions() from lib/display/cnversions.c, > which is used by D_cell_draw_setup[_RGB](). This takes a Cell_head and > a screen rectangle (integer coordinates), and determines the > offset/scale parameters for a set of linear transformations which can > convert between cell array indices, geographic coordinates and screen > coordinates. > > These parameters are then used by D_u_to_a_row() etc, which in turn > are used by D_draw_cell(). > > Probably the most viable solution would be an extended version of > D_do_conversions() which takes two Cell_head structures. > > The first would be the current region (which determines the mapping > between geographic coordinates and cell array indices), while the > second would be the region to fit to the screen rectangle (only the > bounds would be used, with the resolution and rows/cols being > ignored). > > The existing D_do_conversions() would just call the extended version > with the same Cell_head for both arguments. > > There would also need to be extended D_cell_draw_setup[_RGB] > functions, and some means to tell d.rast (and d.rgb, d.his, ...) which > region to draw (you can't use the current region, because the current > region is always subdivided into an exact number of rows and columns, > and changing that certainly isn't viable). .. the resultant module should proabably be called something other than "d.rast". ("d.raster", "d.rast.fuzzy",...) Hamish From hamish_nospam at yahoo.com Fri Nov 3 01:05:57 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Nov 3 01:06:01 2006 Subject: [GRASS-dev] CVS: all images touched? In-Reply-To: <20061102231423.GB18908@bartok.itc.it> References: <20061102231423.GB18908@bartok.itc.it> Message-ID: <20061103130557.1a6cd454.hamish_nospam@yahoo.com> Markus Neteler wrote: > > something strange happened: all images in 6.2 and 6.3 > were re-downloaded from CVS while syncing. > How come? In the commit-logs is nothing. I think Glynn tagged them as "binary" files (-kb) in the CVS. (only done for images missing that, check CVS/Entries record) this avoids newline translation problems for binary files. Hamish From glynn at gclements.plus.com Fri Nov 3 01:09:20 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Nov 3 01:11:53 2006 Subject: FW: [GRASS-dev] Zooming issue in gis manager In-Reply-To: References: Message-ID: <17738.34992.698281.420054@cerise.gclements.plus.com> Michael Barton wrote: > The original post here didn't make it past the list file size filter. So > I've reduced it to one graphic that should make it. I've also done a few > more tests. > > In addition to what I mention below, g.region run without the -a flag > creates rounding errors in resolution--minimal but annoying. > > Without the -a flag, the number of cells displayed accurately reflects the > actual display region setting. So if you save the display region to the WIND > file, and reset the display to match the new current region (i.e., WIND > file), it looks the same as before. But, as noted below, it does this by > shrinking the cells a bit to make them squeeze into the PPM output created > by the PNG driver (could the X-driver be doing this differently???). There is no difference between the X and PNG drivers. However, using direct rendering can potentially produce different results to using a driver. Each display frame can have a geographic region associated with it. If the current frame has a region, this is used in place of the current region (whether from the WIND file, $WIND_OVERRIDE or $GRASS_REGION). If you draw something on a monitor, change the current region, then draw something else without running d.erase, it will use the region stored on the frame rather than the current region. This can't happen with direct rendering, as nothing persists between commands. > With the -a flag, the number of rows or columns displayed is one or two less > than the number in the display region. This is not noticeable (and maybe > doesn't even happen) when there are a lot of cells in the display, but can > be noticeable when there are very few cells in the display. The result is > that if you copy the display region to the WIND file and display it back > again, you see more cells than you started with. This is the "correct" > number of rows and columns, but it not what was displayed. However, there > are no rounding errors in the resolution as reported by g.region. "g.region -a" expands the region so that the bounds are aligned to a grid whose spacing is determine by the existing resolution and whose alignment is such that the origin of the coordinate system falls on a grid point (an intersection between four cells). > Is this all happening in g.region? g.region. > The display driver? Or both? As I say > below, I can't think of how gis.m could compensate for this. In the region > computation, it would involve 'rounding' to the nearest resolution value. > But how can you round to the nearest 0.0001543 degrees? ...or even the > nearest 25m? There is no 'starting place' to round from, since the region > boundary can potentially be anywhere theoretically. First, you have to choose some point which will not change as a result of the adjustment, e.g. the centre or one of the four corners. If you pick the south-west corner, then you adjust the north and east bounds so that the height and width of the region are multiples of the resolution, i.e. width = east - west height = north - south width = (width / ewres + 0.5) * ewres # round to nearest integer multiple of ewres height = (height / nsres + 0.5) * nsres # round to nearest integer multiple of nsres east = west + width north = south + height The same applies for any other corner, except that either or both of the last two lines would be replaced by: west = east - width south = north - height To keep the centre fixed, the last two lines would be replaced by: cx = (east + west ) / 2 cy = (north + south) / 2 east = cx + width / 2 west = cx - width / 2 north = cy + height / 2 south = cy - height / 2 The end result will be similar to using "g.region -a", except that: 1. The grid is anchored at either the centre or a corner of the region, not the origin of the coordinate system. 2. Each bound is aligned to the nearest grid line, rather than always rounding outwards. When panning, you might want to align the region to the previous grid. If (px, py) is some point which is aligned to the previous grid (e.g. one corner of a region which was so aligned), then you can align with: east = px + ((east - px) / ewres) * ewres west = px + ((west - px) / ewres) * ewres north = py + ((north - py) / nsres) * nsres south = py + ((south - py) / nsres) * nsres > I'm going to put the -a flag back into gis.m to keep the resolution rounding > errors out. If you want to set region with precision, especially in a > close-up view with few cells showing in a raster, you need to use g.region. > If you want to display a region in a close-up view of a raster, where the > cell sizes are large compared with the display and pixel size, you'll need > to use explore mode for now at least. As documented below and in the > attached graphic, this does a good job of making a display with accurately > rendered raster cells. Vectors either don't face these issues or have > different ones, as they are not behaving parallel to rasters in this. I think the main point is that you need to keep gis.m's internal regions valid at all times. Whenever a new region is created due to zooming or panning, it should be adjusted (so that its size is an integer multiple of the resolution) as soon as it is created, rather than storing an invalid region and relying upon it being coerced into compliance when passed to GRASS (G__read_Cell_head_array() calls G_adjust_Cell_head(), which affects anything which reads a region). E.g. if the user marks a rectangle on a map, it should ideally be adjusted as it is being entered, so that WYSIWYG. -- Glynn Clements From glynn at gclements.plus.com Fri Nov 3 01:44:49 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Nov 3 01:45:57 2006 Subject: [GRASS-dev] Zooming issue in gis manager In-Reply-To: <20061102202412.588216ba.hamish_nospam@yahoo.com> References: <4548C179.8080801@o2.pl> <17737.2562.965291.612957@cerise.gclements.plus.com> <20061102202412.588216ba.hamish_nospam@yahoo.com> Message-ID: <17738.37121.680843.571622@cerise.gclements.plus.com> Hamish wrote: > > At magnifications significantly above unity, this is likely to be > > problematic for interactive zooming. You either have to adjust the > > bounds so that they aligh with the existing cell grid, or adjust the > > resolution so that the cell grid aligns with the bounds. > > Surely adjusting the region bounds to match the data is better than > adjusting the data (visually) to fit in the region bounds. > > The data is sacrosanct. The region bounds are a temporary whim. It's not an issue of adjusting the "data" versus the bounds. It's an issue of adjusting the resolution versus the bounds. Which one should be adjusted depends upon which one is known to be correct and which one is an arbitrary figure pulled out of thin air. FWIW, G_adjust_Cell_head() (and thus everything which uses it, e.g. G_get_window() etc) always adjusts the resolution rather than the bounds. If you want the bounds to be adjusted in order to preserve the resolution, you have to do it yourself. > As long as the gui window's x,y cursor output etc keeps up to date with > any adjustments, it doesn't seem very problematic to me to slightly > nudge the zoom box to fit the data's resolution before rendering. If you want to preserve the resolution, then you need to adjust the bounds yourself. Not just when exporting to the WIND file, but also in the region passed to d.rast etc. If the region passed to a GRASS module (via WIND, $WIND_OVERRIDE or $GRASS_REGION) doesn't satisfy the requirements that (east-west)/ewres and (north-south)/nsres are integers, libgis will modify ewres and nsres accordingly. -- Glynn Clements From glynn at gclements.plus.com Fri Nov 3 01:33:49 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Nov 3 01:47:56 2006 Subject: [GRASS-dev] Zooming issue in gis manager In-Reply-To: References: <45491B34.7030200@o2.pl> Message-ID: <17738.36461.964635.588871@cerise.gclements.plus.com> Michael Barton wrote: > You are correct. If -a is not set in g.region it makes small rounding errors > every time you change the region, even if you do not change the resolution > or even if you try to set it explicitly. > > Given this, I guess it's better to avoid the small, but annoying rounding > errors of g.region at common map scales than to keep the aligned region > display appearing to be more accurate in less common close-ups of rasters, > especially given that explore mode can be used to produce a display that > correctly matches a region of a few original grid cells in close-ups. There are better ways to preserve the resolution than "g.region -a", i.e. setting valid bounds yourself. -- Glynn Clements From glynn at gclements.plus.com Fri Nov 3 02:03:03 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Nov 3 02:03:05 2006 Subject: [GRASS-dev] r.resamp.stats method=sum artifacts In-Reply-To: <4549C525.7040701@itc.it> References: <20061030174705.7d4b55fa.hamish_nospam@yahoo.com> <17734.24775.637180.964134@cerise.gclements.plus.com> <20061031170006.27954610.hamish_nospam@yahoo.com> <200610311117.58316.dylan.beaudette@gmail.com> <20061102170351.49fc2644.hamish_nospam@yahoo.com> <17737.29528.199863.47406@cerise.gclements.plus.com> <4549C525.7040701@itc.it> Message-ID: <17738.38215.60067.687312@cerise.gclements.plus.com> Markus Neteler wrote: > >> I've added r.resamp.stats and r.resamp.interp to the GUI menus. > >> (Raster->Devel) > >> > >> should r.resample be tagged for future removal? (same result as with: > >> 'r.resamp.interp method=nearest' ???). > >> > > > > No. > > > > r.resample uses libgis' built-in resampling, so it is guaranteed to > > resample in an identical manner to other commands. > > > > "r.resamp.interp method=nearest" performs the resampling itself, so it > > could produce slightly different results due to rounding errors. The > > method=nearest option was only included for completeness; if you want > > nearest-neighbour resampling, r.resample is preferred. > > Honestly, this sounds confusing to me. Having NN method twice which produces > slightly different results, is hard to explain to users. It's largely inevitable. Even if r.resample is removed, it can (mostly) be duplicated with e.g. "r.mapcalc dst = src", which also isn't guaranteed to produce the same results as r.resamp.interp. Similarly for any other module which can be made to perform a "copy" operation by some setting of its parameters (r.mfilter with a 1x1 kernel, maybe?). I could remove method=nearest from r.resamp.interp, but if it's ever extended to support more advanced interpolation schemes with parameters, the same issue could arise. Ultimately, nearest-neighbour resampling will always have boundary cases where the centre of an output cell falls on the boundary between two or four input cells. In that situation, the end result will depend upon everything which can affect the rounding error: the algorithm used, the compiler, the compilation switches, the architecture, etc. -- Glynn Clements From glynn at gclements.plus.com Fri Nov 3 01:52:23 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Nov 3 02:10:44 2006 Subject: [GRASS-dev] Zooming issue in gis manager In-Reply-To: <20061102201221.7f34a035.hamish_nospam@yahoo.com> References: <17736.16639.94435.508993@cerise.gclements.plus.com> <20061102201221.7f34a035.hamish_nospam@yahoo.com> Message-ID: <17738.37575.757841.21698@cerise.gclements.plus.com> Hamish wrote: > > Given that the origin for most coordinate systems is a completely > > arbitrary location arising from various completely arbitrary constants > > (e.g. whichever round numbers where chosen as the false easting and > > northing), I have no idea what the intended purpose of the -a flag is, > > but I'm fairly sure that it shouldn't be used by default. > > it keeps you from needlessly resampling (degrading) your raster data as > you zoom+pan around & create new maps using the new map bounds? Oh, I get the point about preserving the resolution, but I would have thought that there would have been a better way to choose the alignment. If the resolution doesn't change, you probably want to retain the alignment. Similarly, if the resolution increases or decreases by an integer multiple (the former has an unambiguously correct answer; the latter involves an arbitrary choice, but not as arbitrary as the coordinate system's origin). In the case where the resolution changes arbitrarily, there isn't any "correct" alignment, so I think I see where the behaviour of -a comes from (i.e. a cop-out on the part of the programmer). But in the case where the resolution doesn't change, I'm even more confident that "g.region -a" is the wrong approach; the original grid (both resolution and alignment) should be preserved, IMHO. -- Glynn Clements From glynn at gclements.plus.com Fri Nov 3 02:27:23 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Nov 3 02:27:29 2006 Subject: [GRASS-dev] [bug #5252] (grass) Multicore hardware and grass In-Reply-To: <4549E5D5.3090708@gmx.de> References: <20061102011811.55E19101EE0@lists.intevation.de> <17737.25751.37693.82497@cerise.gclements.plus.com> <200611021251.04744.maris.gis@gmail.com> <4549E5D5.3090708@gmx.de> Message-ID: <17738.39675.6435.295937@cerise.gclements.plus.com> S?ren Gebbert wrote: > there was a discussion on IRC how to parallelize grass to run on > multicore computers. > We came to the same conclusion as Glynn. > The design of the GRASS core libs > is not thread safe. And to port the core of grass to run in parallel on > Beowulf clusters or SSI clusters is not practical. > > But GRASS can work in parallel already. :) > Just start several modules on several maps and hope the disk IO is > not the limiting factor. ... and hope that the modules don't try to modify shared data (e.g. the WIND file, $GISRC, etc) concurrently. Certainly, multiple concurrent processes is the easiest way to take advantage of multiple cores. This is easier to do for server environments (e.g. web applications) than for "desktop" use. > And this works on SSI clusters as well. > > I think we should think more simple. Since gcc version 4.2, OpenMP is > available for normal C/C++/Fortran developers without access to > commercial compilers. > Individual modules can be parallelized for multicore systems with OpenMP > (http://www.openmp.org). > And i think to work with OpenMP is much easier than posix threads, MPI, > BSP or SunGrid and stuff. > > But the main issues with GRASS and OpenMP are: > > 1.) You need some parallel programming experience or your programs will > become slower in the end with OpenMP > 2.) To debug multi threaded software is much harder than single thread > software. Not to mention writing it in the first place. Personally, I would rule out writing multi-threading modules simply on the basis that most GRASS developers don't have enough experience in concurrent programming. [Programming experience in general is a relatively limited commodity around here. Most GRASS developers are geoscientists with the kind and level of programming experience normally acquired in scientific disciplines.] Writing (reliable) concurrent code is hard. Worse still, most testing methodologies are poor at detecting concurrency-related bugs. Asking relatively inexperienced programmers to write concurrent code is a recipe for software which passes the test suite then regularly suffers from intermittent (and usually non-repeatable) failures in actual use. > 3.) The core libs are not thread safe, so you have to careful choose the > library functions which are to use in parallel IOW, you have to restrict the use of GRASS to one thread, with other threads being used for "pure" computation. Unfortunately, most GRASS code doesn't readily fit into that kind of model. It would be more viable for certain computationally intensive modules, particularly those which read an entire map into memory, do a lot of processing, then write out results at the end. Reading entire maps into memory is something we normally try to avoid, and only use where the algorithm inherently requires random access (so can't readily be adapted to a sequential-I/O strategy). > 4.) The data access to the harddisk dont scale in parallel on a single > disk/conroler system, you will only benfit from OpenMP if you load > the data to process completely in the memory > 5.) ... > > > So there are only a few modules which will benefit from simple > parallelizing with OpenMP. > To change this, the core of grass have to be implemented in > a new and different way. > > But i think the grass developers have to think about to parallelize > grass. Because the future computer generations will work with multiple > cores (2 - 128?) and the users will expect that programms like grass > will use the multicore power to work. This is not an easy task and needs > a lot of programming knowledge ... well this can be added to the wish > section for grass version 10? :) ;) Version 10 sounds about right. A lot of the problem is that: 1. The libraries can't readily be parallelised without changing the API. 2. Changing the API means re-writing modules which use it. 3. Much of GRASS' value is in the modules, so re-writing the modules equates to re-writing most of GRASS. There might be some specific cases which are amenable to parallelisation. E.g. it might be possible to re-write the core raster I/O to use threads in a producer-consumer model, so that get-row/put-row operations essentially take no time (i.e. the module runs entirely in the main thread, while a separate thread performs the raster I/O). That might give a 2x speed-up on a dual-core system, but still wouldn't scale to larger numbers of cores (i.e. you would still only get a 2x speed-up on a 16-core system). -- Glynn Clements From glynn at gclements.plus.com Fri Nov 3 03:11:46 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Nov 3 03:11:49 2006 Subject: [GRASS-dev] Windows-style Pathnames In-Reply-To: References: <17737.4290.419895.264288@cerise.gclements.plus.com> <20061101215211.GA3922@localhost.tamu.edu> <17737.21068.670434.23541@cerise.gclements.plus.com> Message-ID: <17738.42338.869940.724212@cerise.gclements.plus.com> Paul Kelly wrote: > > Note that the backslash is a shell metacharacter, so it will have to > > be protected from interpretation if it appears directly in a script or > > user input. > > For that reason alone, perhaps easiest to use c:/grass/grassdata format as > much as possible, at least as an interim measure? Maybe. We'll need to convert it for e.g. system(). > > The biggest problem with scripts is when MSys decides to be "clever" > > and do automatic translation. IMHO, we would be better off using host > > syntax throughout. > > OK but whether we use c:/ or c:\ we still have the same problem with > setting the PATH in scripts Huidae was talking about. But it remains to be > seen how big a problem it is I guess. Most scripts don't set PATH. For a native Windows version, I would be strongly in favour of replacing init.sh with a Windows command file. Actually, if users only need to use gis.m, it should be possible to start it as a GUI application without cmd.exe, bash or a console ever getting involved. > > So far as I'm concerned, the "Windows" version > > should be just that, and not an "MSys" version. If people can live > > without the contents of the scripts directory, it shouldn't be > > necessary for end users to even have MSys. > > Yes. I thought that but wasn't sure. So Msys and MinGW are needed only for > compilation? MSys is needed for shell scripts, of which there are currently a fair number. > And it should be possible for a user to run the scripts if > necessary using another shell, not necessarily the Msys one? Perhaps > determined by a GRASS_SH environment variable. Currently, a lot of GRASS assumes that scripts can be treated as executables, as they are on Unix. I.e. you can call system("foo") and it doesn't matter whether foo is a compiled executable or a script. You can do this on Windows, but the file needs to have an extension to indicate how it is run (Unix detects this from the file's header, e.g. #! for scripts). The PATHEXT environment variable contains a semicolon-separated list of extensions which are treated as indicating an executable. On my system, it is set to: PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH If you execute a "command" without a directory or extension, Windows will consider files with any of those extensions when trying to resolve the command name to an executable, effectively doing: for dir in $PATH ; do for ext in $PATHEXT ; do if [ -f $dir/$cmd$ext] ; then exec $dir/$cmd$ext fi done done AFAICT, the "interpreter" is selected according the registry entry corresponding to the extension, the same as if you had double-clicked on the file's icon from an Explorer window. So, if we were to add ".sh" extensions to all of the scripts, and add ".sh" to PATHEXT, calling e.g. system("r.out.gdal ...") should run r.out.gdal.sh using the program associated with ".sh" in the registry. > And it's the shell's > responsibility to make sure that the various Unix commands work OK when > called from within its environment then. Am I making sense? Well, a Bourne-shell script needs a Bourne-compatible shell to run. However, the main job of a shell is to run external commands. The arguments to those commands may be generated (or hard-coded) within the shell, or passed to the shell as arguments. Most of the time, the shell is just passing strings around. If it gets a filename from one program and passes it to another, both programs have to be using the same syntax. Windows programs will always use Windows syntax. We get to choose the syntax used by GRASS programs. If MSys uses Unix syntax, either MSys will either have to convert it, or the script will. AFAICT, MSys converts environment variables to Windows syntax, and converts pathnames to half-way syntax (with a forward slash, e.g. c:/windows) when it recognises that it's passing a pathname to an external command, but there are cases where Unix syntax doesn't get converted. -- Glynn Clements From glynn at gclements.plus.com Fri Nov 3 03:16:17 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Nov 3 03:16:20 2006 Subject: [GRASS-dev] Windows-style Pathnames In-Reply-To: <20061102181441.462c86e8.hamish_nospam@yahoo.com> References: <17737.4290.419895.264288@cerise.gclements.plus.com> <20061102181441.462c86e8.hamish_nospam@yahoo.com> Message-ID: <17738.42609.165646.42513@cerise.gclements.plus.com> Hamish wrote: > > However, using / should work as an argument to fopen(). The issue is > > more significant if paths are constructed and stored for later use > > (e.g. in $GISRC). In that situation, we need to decide whether to: > > > > 1. create and store the pathname in the host's syntax, or > > 2. store it in Unix syntax and convert it as required. > > > > Either option will involve a lot of changes. #1 is easier to > > implement, but will probably need to be done in more places (it needs > > to be done for every pathname which might need to be in host syntax at > > some point). #2 is harder, but only needs to be performed in places > > where host syntax is known to be necessary. > > option #1 means that moving a GISDBASE from window->unix will result in > breakage? > > If it were limited to .grassrc6 it wouldn't be too much of a problem, > but what about path names stored in the data? > > G63> cd $MAPSET > G63> cat VAR > GV_DRIVER: dbf > GV_DATABASE: $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ > DB_DRIVER: dbf > DB_DATABASE: $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ > > G63> cat vector/$VECT_MAP/dbln > 1 Depth cat $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ dbf Pathnames stored in data aren't generally portable between any two systems, even if they're running the same OS. There's no reason to believe that any given path will exist on the destination system. The specific case of the above would have been better dealt with by treating relative pathnames as being relative to the mapset directory, so you would just store "dbf" in the above case. -- Glynn Clements From glynn at gclements.plus.com Fri Nov 3 03:21:19 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Nov 3 03:21:20 2006 Subject: [GRASS-dev] Windows-style Pathnames In-Reply-To: References: <17737.4290.419895.264288@cerise.gclements.plus.com> Message-ID: <17738.42911.27591.437610@cerise.gclements.plus.com> Paul Kelly wrote: > > For the above case, there should probably be a > > G_is_directory_separator() function which determines whether or not > > its argument is a directory separator on the host platform. > > OK, I'm looking at this now. So on Windows that function would return true > for both '\\' and '/' being passed to it, and on Unix only for '/'? Yes. Also, look at Tcl's file(n) manpage for ideas for functions which might be needed. Note that Tcl also uses c:/path/to/file syntax on Windows in most cases, with "file nativename ..." being used if you need an entirely native filename. -- Glynn Clements From grass-bugs at intevation.de Fri Nov 3 04:37:22 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Fri Nov 3 04:37:23 2006 Subject: [GRASS-dev] [bug #5253] (grass) grass-fc4.rpm dependency breaks fontserver (xfs) Message-ID: <20061103033722.7CDD11006AB@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5253 ------------------------------------------------------------------------- Subject: grass-fc4.rpm dependency breaks fontserver (xfs) Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Downloaded precompiled Binaries GRASS Version: grass-6.2.0-1.fdr.fc4.i386.rpm Problem is not with GRASS, but with installation of GRASS from rpm, which caused xfs to fail and, therefore, X server to not start. Can be very frightening for non-computer people (i.e. me!). Details follow: OS = FC5 (2.6.17-1.2187_FC5-i686 kernel) with latest updates (yum, as at 01 November 2006, excluding latest kernel and openoffice). Tcl=8.4.13. Nvidia driver from livna. Running Grass6.2.0RC1 compiled from source on FC2 a short time before upgrade to FC5. All running fine until 02 Nov 2006. Installed grass-6.2.0-1.fdr.fc4.i386.rpm on 01 November 2006 (immediately following yum update noted above), plus all other rpm's present at http://grass.itc.it/grass62/binary/linux/ to ensure up-to-date installation. Following packages (most recent available) were also installed same date to satisfy dependencies claimed when installing grass-6.2.0-1.fdr.fc4.i386.rpm: 1) xorg-x11-libs-6.8.2-37.FC4.49.2.1.i386.rpm 2) xorg-x11-Mesa-ligGL-6.8.2-37.FC4.49.2.1.i386.rpm All appeared fine, but following first shut-down (for the night) and reboot on morning of 02 Nov 2006, X-server (per xorg.conf) could not init font path "unix/:7100 (font-server network link broken?), resulting in X server not being able to open default font 'fixed' (but font and index .dir and .alias files present, fontpaths all fine and identified), resulting in X-server not starting. Traced problem to one of the files (/usr/X11R6/lib/libFS.so.6?) in xorg-x11-libs-6.8.2-37.FC4.49.2.1.i386.rpm package. Removing package (using --nodeps, as rpm installer complained that grass, mplayer, terraform and opendx all needed package) solved the problem. Curious thing, however, is that grass, mplayer and opendx all seem to function fine so far (and newer rpm of opendx installed fine) without this package! Suggestion: review rpm spec for Grass as relates to dependency for shared libraries in xorg-x11-libs-6.8.2-37.FC4.49.2.1.i386.rpm and/or other X-related packages. Other than this incident, I am very pleased with the fine job developing this recent version of Grass ... hats off to a job well done folks! Regards, Rick -------------------------------------------- Managed by Request Tracker From michael.barton at asu.edu Fri Nov 3 05:19:54 2006 From: michael.barton at asu.edu (Michael Barton) Date: Fri Nov 3 05:25:02 2006 Subject: [GRASS-dev] Zooming issue in gis manager In-Reply-To: <17738.34992.698281.420054@cerise.gclements.plus.com> Message-ID: Glynn, This is very helpful, though I'll have to sort through this and follow-up messages to see if and where they can fit into the existing algorithms. Thanks much. A couple of things bother me that perhaps you could clear up. First is that it looks like your examples below and some of the follow-ups assume that resolution is always an integer. Although the number of rows and columns are, of course, integers, I'm sure that ewres and nsres can take on any float value. This makes what you are suggesting more complicated I think. The other issue is that even when I take out the -a flag, d.rast makes some kind of adjustments to the way that grid cells are displayed such that they appear to be somewhat different sized when you make the resolution=1 grid cell and when you make the resolution>>1 (original) grid cell. Maybe this is what you are referring to in some places below and other posts. Finally, is there any reason that I need to be concerned about the values of GRASS_WIDTH and GRASS_HEIGHT for PPM output? Thanks again Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Glynn Clements > Date: Fri, 3 Nov 2006 00:09:20 +0000 > To: Michael Barton > Cc: grass-dev > Subject: Re: FW: [GRASS-dev] Zooming issue in gis manager > > > Michael Barton wrote: > >> The original post here didn't make it past the list file size filter. So >> I've reduced it to one graphic that should make it. I've also done a few >> more tests. >> >> In addition to what I mention below, g.region run without the -a flag >> creates rounding errors in resolution--minimal but annoying. >> >> Without the -a flag, the number of cells displayed accurately reflects the >> actual display region setting. So if you save the display region to the WIND >> file, and reset the display to match the new current region (i.e., WIND >> file), it looks the same as before. But, as noted below, it does this by >> shrinking the cells a bit to make them squeeze into the PPM output created >> by the PNG driver (could the X-driver be doing this differently???). > > There is no difference between the X and PNG drivers. > > However, using direct rendering can potentially produce different > results to using a driver. > > Each display frame can have a geographic region associated with it. If > the current frame has a region, this is used in place of the current > region (whether from the WIND file, $WIND_OVERRIDE or $GRASS_REGION). > > If you draw something on a monitor, change the current region, then > draw something else without running d.erase, it will use the region > stored on the frame rather than the current region. > > This can't happen with direct rendering, as nothing persists between > commands. > >> With the -a flag, the number of rows or columns displayed is one or two less >> than the number in the display region. This is not noticeable (and maybe >> doesn't even happen) when there are a lot of cells in the display, but can >> be noticeable when there are very few cells in the display. The result is >> that if you copy the display region to the WIND file and display it back >> again, you see more cells than you started with. This is the "correct" >> number of rows and columns, but it not what was displayed. However, there >> are no rounding errors in the resolution as reported by g.region. > > "g.region -a" expands the region so that the bounds are aligned to a > grid whose spacing is determine by the existing resolution and whose > alignment is such that the origin of the coordinate system falls on a > grid point (an intersection between four cells). > >> Is this all happening in g.region? > > g.region. > >> The display driver? Or both? As I say >> below, I can't think of how gis.m could compensate for this. In the region >> computation, it would involve 'rounding' to the nearest resolution value. >> But how can you round to the nearest 0.0001543 degrees? ...or even the >> nearest 25m? There is no 'starting place' to round from, since the region >> boundary can potentially be anywhere theoretically. > > First, you have to choose some point which will not change as a result > of the adjustment, e.g. the centre or one of the four corners. > > If you pick the south-west corner, then you adjust the north and east > bounds so that the height and width of the region are multiples of the > resolution, i.e. > > width = east - west > height = north - south > > width = (width / ewres + 0.5) * ewres # round to nearest integer multiple of > ewres > height = (height / nsres + 0.5) * nsres # round to nearest integer multiple of > nsres > > east = west + width > north = south + height > > The same applies for any other corner, except that either or both of > the last two lines would be replaced by: > > west = east - width > south = north - height > > To keep the centre fixed, the last two lines would be replaced by: > > cx = (east + west ) / 2 > cy = (north + south) / 2 > east = cx + width / 2 > west = cx - width / 2 > north = cy + height / 2 > south = cy - height / 2 > > The end result will be similar to using "g.region -a", except that: > > 1. The grid is anchored at either the centre or a corner of the > region, not the origin of the coordinate system. > > 2. Each bound is aligned to the nearest grid line, rather than always > rounding outwards. > > When panning, you might want to align the region to the previous grid. > > If (px, py) is some point which is aligned to the previous grid (e.g. > one corner of a region which was so aligned), then you can align with: > > east = px + ((east - px) / ewres) * ewres > west = px + ((west - px) / ewres) * ewres > north = py + ((north - py) / nsres) * nsres > south = py + ((south - py) / nsres) * nsres > >> I'm going to put the -a flag back into gis.m to keep the resolution rounding >> errors out. If you want to set region with precision, especially in a >> close-up view with few cells showing in a raster, you need to use g.region. >> If you want to display a region in a close-up view of a raster, where the >> cell sizes are large compared with the display and pixel size, you'll need >> to use explore mode for now at least. As documented below and in the >> attached graphic, this does a good job of making a display with accurately >> rendered raster cells. Vectors either don't face these issues or have >> different ones, as they are not behaving parallel to rasters in this. > > I think the main point is that you need to keep gis.m's internal > regions valid at all times. Whenever a new region is created due to > zooming or panning, it should be adjusted (so that its size is an > integer multiple of the resolution) as soon as it is created, rather > than storing an invalid region and relying upon it being coerced into > compliance when passed to GRASS (G__read_Cell_head_array() calls > G_adjust_Cell_head(), which affects anything which reads a region). > > E.g. if the user marks a rectangle on a map, it should ideally be > adjusted as it is being entered, so that WYSIWYG. > > -- > Glynn Clements From hamish_nospam at yahoo.com Fri Nov 3 05:28:52 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Nov 3 05:28:57 2006 Subject: [GRASS-dev] v.digit clipping Message-ID: <20061103172852.5739ad3e.hamish_nospam@yahoo.com> Hi, v.digit clips digitized lines to within the current region, although actual data points are recorded. (if you pan over you see all points were in fact recorded) This is quite weird if you don't have a backdrop raster and you have big off-region bands on two sides of the xmon. Lines just disappear for "no reason". As exact region edges are non-important for vector maps, it would be nice to render these lines regardless of region clipping. Usually it would be a case of replacing D_move_abs() and D_cont_abs() with R_move_abs() and R_cont_abs() in vector/v.digit/driver.c, but G_setup_plot() expects Move and Cont args to return int (as D_*_abs() do), but R_*_abs() return void. what's the correct solution? - re-type R_*_abs(), R_*_rel() fns to int? - cast void->int in v.digit's G_setup_plot() args? - modify G_setup_plot() to take "int clip={TRUE|FALSE}" instead of function names? (major breakage, e.g. v.to.rast/raster.c) - something else? Hamish From grass-bugs at intevation.de Fri Nov 3 05:57:20 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Fri Nov 3 05:57:22 2006 Subject: [GRASS-dev] [bug #5254] (grass) enable v.what to report on more that one category Message-ID: <20061103045720.0A9E21006AB@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5254 ------------------------------------------------------------------------- Subject: enable v.what to report on more that one category Platform: GNU/Linux/x86 A wish for Grass 6.3? I don't know how often situations like this might arise, however... I have a database with over 75000 records (~30 fields/record) which is poorly georeferenced (it uses an odd alpha-numeric mapping reference involving map book pages, etc), such that locations can be defined only to the nearest 1km by 1km area. I have calculated UTM centered on the 1 km squares for each record using a spreadsheed. These 75000 records imported into Grass result in approx. 12500 points (too much data to sort on a spreadsheet). While some data points may contain as many as 20 categories, it appears that v.what can report on only one category (the first one encountered?). It would be nice if v.what could "drill through" all categories at each point to report all data. In addition, it would be nice if a new Grass module could be developed to allow functions like mean, max, min, etc., to be done for the various fields available in this too-many-categories-per-point database, in which case some very useful surface maps could be produced. I do not write code and so cannot contribute directly to development, but I introduce the concept here in the hope that someone who can write might find this change to v.what and/or a new function handy. I am willing to make parts of the database available for such development and can participate in testing. Regards, Rick -------------------------------------------- Managed by Request Tracker From hamish_nospam at yahoo.com Fri Nov 3 06:36:45 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Nov 3 06:36:50 2006 Subject: [GRASS-dev] [bug #5254] (grass) enable v.what to report on more that one category In-Reply-To: <20061103045720.0A9E21006AB@lists.intevation.de> References: <20061103045720.0A9E21006AB@lists.intevation.de> Message-ID: <20061103183645.24d4bb8f.hamish_nospam@yahoo.com> Request Tracker wrote: > this bug's URL: http://intevation.de/rt/webrt?serial_num=5254 > --------------------------------------------------------------------- > > Subject: enable v.what to report on more that one category > > Platform: GNU/Linux/x86 > A wish for Grass 6.3? > > I don't know how often situations like this might arise, however... > > I have a database with over 75000 records (~30 fields/record) which is > poorly georeferenced (it uses an odd alpha-numeric mapping reference > involving map book pages, etc), such that locations can be defined > only to the nearest 1km by 1km area. I have calculated UTM centered on > the 1 km squares for each record using a spreadsheed. These 75000 > records imported into Grass result in approx. 12500 points (too much > data to sort on a spreadsheet). > > While some data points may contain as many as 20 categories, it > appears that v.what can report on only one category (the first one > encountered?). It would be nice if v.what could "drill through" all > categories at each point to report all data. In addition, it would be > nice if a new Grass module could be developed to allow functions like > mean, max, min, etc., to be done for the various fields available in > this too-many-categories-per-point database, in which case some very > useful surface maps could be produced. > > I do not write code and so cannot contribute directly to development, > but I introduce the concept here in the hope that someone who can > write might find this change to v.what and/or a new function handy. I > am willing to make parts of the database available for such > development and can participate in testing. does v.perturb help to get the points directly off the top of one another? if error is +/- 500m anyway, introducing a few cm won't harm.. Hamish From hamish_nospam at yahoo.com Fri Nov 3 07:35:02 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Nov 3 07:41:44 2006 Subject: [GRASS-dev] Zooming issue in gis manager In-Reply-To: <17737.19609.232888.737802@cerise.gclements.plus.com> References: <4548C179.8080801@o2.pl> <17737.2562.965291.612957@cerise.gclements.plus.com> <45491AF6.90200@o2.pl> <17737.19609.232888.737802@cerise.gclements.plus.com> Message-ID: <20061103193502.4cfb98d3.hamish_nospam@yahoo.com> Glynn Clements wrote: > > I would guess that d.zoom adjusts the bounds manually, whereas gis.m > uses "g.region -a". The latter does more than just preserve the > resolution; it also aligns the grid with the coordinate system's > origin, then aligns the bounds with that grid, rounding outwards (i.e. > enlarging the region). > > Thus, "panning" (moving the region without changing the e-w or n-s > differences) with "g.region -a" will change the size of the region if > the requested bounds aren't aligned to the grid, as it will round > opposing edges in opposite directions. here's a little example that demonstrates a problem with the existing d.zoom, g.region -a: g.region n=1025 s=-1025 w=-1025 e=1025 res=50 r.mapcalc xy="x()*y()" r.mapcalc xy_centre="if(abs(xy) < 50000)" r.to.vect in=xy_centre out=Xy_centre feature=area r.colors xy rule=ramp d.rast xy d.vect Xy_centre type=boundary d.grid 1000 # note 0,0 crosses middle of cells d.zoom # zoom to middle blob g.region -p # region is now aligned to 0,0 origin instead of 25,25 # ** data appears "moved" 1/2 a cell in x and y # 'd.zoom -p' has the same effect g.region rast=xy d.redraw d.zoom -p g.region -p # as does 'g.region -a' g.region rast=xy d.redraw g.region res=50 -ap d.redraw in this case changing to a resolution of 25 stops the data shift (as a deadline work-around). Hamish From hamish_nospam at yahoo.com Fri Nov 3 08:00:38 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Nov 3 08:02:18 2006 Subject: [GRASS-dev] Re: georectifier fixes for Debian In-Reply-To: References: <20061102194048.3138c81d@localhost.localdomain> Message-ID: <20061103200038.1d31075a.hamish_nospam@yahoo.com> Michael Barton wrote: > I got a student here with Debian Ubuntu (Mepis) to try the --ui switch > for the i.group command in georectify.tcl. It seems to solve the > problem of i.group flashing on and off. I have just updated to the latest CVS and the georectifier is now working properly (AFAIU), running i.group from the other side of the looking glass & all. great! > Thanks very much Hamish for suggesting it. It's in the cvs now. I'm > copying Markus so that he can backport it to 6.2.1 in 6.2.0 the "2. create a group" button now is a no-op for me (note I'm currently at 100% cpu + 80% RAM for a modelling task, so race-for- resource errors might be different). Not a big deal, but we'll have to answer the question of how to set the group up in another grass session eventually. If this is the only last-minute 6.2.0 breakage I'll be very happy. Otto: > > the i.group window opens, but when I close the "error" message below > > appears, but I can still go on rectiifying. > > > > child process exited abnormally > > child process exited abnormally > > while executing > > "exec -- $cmd --ui" > > (procedure "GRMap::group" line 17) > > invoked from within > > "GRMap::group" > > ("uplevel" body line 1) > > invoked from within > > "uplevel \#0 $cmd" > > (procedure "Button::_release" line 18) > > invoked from within > > "Button::_release .grstart.mf.frame.group.a" > > (command bound to event) > > and set GCPs No harm in it, AFAIK, just normal termination(?). The "catch" statement hides this error message. Unfortunately the "catch" was also catching a genuine error (expecting command line options; thus it needs a --ui GUI [why is that?]). >From what I've heard here the Tcl return test is bogus so there is no way to test a good exit from a bad one? perhaps gis.m could use a global DEBUG 0/1 setting like the start of the nviz2.2_script has. With it changed to 1 it could disable the catches, etc. or maybe better it could test on startup if the gisenv DEBUG was > 0 to set a global DEBUG var. Hamish From otto.dassau at gmx.de Fri Nov 3 10:54:11 2006 From: otto.dassau at gmx.de (Otto Dassau) Date: Fri Nov 3 10:54:14 2006 Subject: [GRASS-dev] Re: georectifier fixes for Debian In-Reply-To: <20061103200038.1d31075a.hamish_nospam@yahoo.com> References: <20061102194048.3138c81d@localhost.localdomain> <20061103200038.1d31075a.hamish_nospam@yahoo.com> Message-ID: <20061103105411.50f08aab@localhost.localdomain> On Fri, 3 Nov 2006 20:00:38 +1300 Hamish wrote: > Michael Barton wrote: > > I got a student here with Debian Ubuntu (Mepis) to try the --ui switch > > for the i.group command in georectify.tcl. It seems to solve the > > problem of i.group flashing on and off. > > I have just updated to the latest CVS and the georectifier is now > working properly (AFAIU), running i.group from the other side of the > looking glass & all. > > great! > > > Thanks very much Hamish for suggesting it. It's in the cvs now. I'm > > copying Markus so that he can backport it to 6.2.1 > > in 6.2.0 the "2. create a group" button now is a no-op for me (note I'm > currently at 100% cpu + 80% RAM for a modelling task, so race-for- > resource errors might be different). Not a big deal, but we'll have to > answer the question of how to set the group up in another grass session > eventually. If this is the only last-minute 6.2.0 breakage I'll be very > happy. > > > Otto: > > > the i.group window opens, but when I close the "error" message below > > > appears, but I can still go on rectiifying. > > > > > > child process exited abnormally > > > child process exited abnormally > > > while executing > > > "exec -- $cmd --ui" > > > (procedure "GRMap::group" line 17) > > > invoked from within > > > "GRMap::group" > > > ("uplevel" body line 1) > > > invoked from within > > > "uplevel \#0 $cmd" > > > (procedure "Button::_release" line 18) > > > invoked from within > > > "Button::_release .grstart.mf.frame.group.a" > > > (command bound to event) > > > and set GCPs > > No harm in it, AFAIK, just normal termination(?). The "catch" statement > hides this error message. Unfortunately the "catch" was also catching a > genuine error (expecting command line options; thus it needs a --ui GUI > [why is that?]). ok, thanks a lot for your help and fixes. I tested the current cvs version Grass 6.3 head and the georectifier is working very well now - great!! thanks a lot Otto > From what I've heard here the Tcl return test is bogus so there is no > way to test a good exit from a bad one? > > perhaps gis.m could use a global DEBUG 0/1 setting like the start of the > nviz2.2_script has. With it changed to 1 it could disable the catches, > etc. or maybe better it could test on startup if the gisenv DEBUG was > > 0 to set a global DEBUG var. > > > Hamish > -- From cavallini at faunalia.it Fri Nov 3 13:09:26 2006 From: cavallini at faunalia.it (Paolo Cavallini) Date: Fri Nov 3 13:09:31 2006 Subject: [GRASS-dev] r.li 0.2.7 Message-ID: <454B3176.6040706@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 New version available. Several bugs have been fixed. pc - -- Paolo Cavallini email+jabber: cavallini@faunalia.it www.faunalia.it Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFSzF2/NedwLUzIr4RAiafAKCHHwbuPQvJ+EUG0b+2NpajPVZh9gCffsDf Jn5I+JE8B5lawySwS4R+pTU= =AXgU -----END PGP SIGNATURE----- From dylan.beaudette at gmail.com Fri Nov 3 19:48:19 2006 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Fri Nov 3 19:20:16 2006 Subject: [GRASS-dev] r.resamp.stats method=sum artifacts In-Reply-To: <17738.38215.60067.687312@cerise.gclements.plus.com> References: <20061030174705.7d4b55fa.hamish_nospam@yahoo.com> <4549C525.7040701@itc.it> <17738.38215.60067.687312@cerise.gclements.plus.com> Message-ID: <200611031048.19138.dylan.beaudette@gmail.com> On Thursday 02 November 2006 17:03, Glynn Clements wrote: > Markus Neteler wrote: > > >> I've added r.resamp.stats and r.resamp.interp to the GUI menus. > > >> (Raster->Devel) > > >> > > >> should r.resample be tagged for future removal? (same result as with: > > >> 'r.resamp.interp method=nearest' ???). > > > > > > No. > > > > > > r.resample uses libgis' built-in resampling, so it is guaranteed to > > > resample in an identical manner to other commands. > > > > > > "r.resamp.interp method=nearest" performs the resampling itself, so it > > > could produce slightly different results due to rounding errors. The > > > method=nearest option was only included for completeness; if you want > > > nearest-neighbour resampling, r.resample is preferred. > > > > Honestly, this sounds confusing to me. Having NN method twice which > > produces slightly different results, is hard to explain to users. > > It's largely inevitable. > > Even if r.resample is removed, it can (mostly) be duplicated with e.g. > "r.mapcalc dst = src", which also isn't guaranteed to produce the same > results as r.resamp.interp. Similarly for any other module which can > be made to perform a "copy" operation by some setting of its > parameters (r.mfilter with a 1x1 kernel, maybe?). > > I could remove method=nearest from r.resamp.interp, but if it's ever > extended to support more advanced interpolation schemes with > parameters, the same issue could arise. > > Ultimately, nearest-neighbour resampling will always have boundary > cases where the centre of an output cell falls on the boundary between > two or four input cells. In that situation, the end result will depend > upon everything which can affect the rounding error: the algorithm > used, the compiler, the compilation switches, the architecture, etc. This is deviating someone from the NN issues... but: I have been noticing some odd edge effects when using r.resamp.stats method=mode .... i.e. i am getting a "ring" of cells with 0-value around the actual data. Within the "ring" the results appear to match those obtained with an alternate raster-vector-starspan-raster approach to doing the same operation. a graphical summary can be found here: http://169.237.35.250/~dylan/temp/method_mode-test.png Details on the raster-vector-raster approach are listed here: http://casoilresource.lawr.ucdavis.edu/drupal/node/275 cheers, -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 From grass-bugs at intevation.de Fri Nov 3 21:09:16 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Fri Nov 3 21:09:19 2006 Subject: [GRASS-dev] [bug #5255] (grass) Solaris 10 includes fail to copy Message-ID: <20061103200916.DA9431005DB@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5255 ------------------------------------------------------------------------- Subject: Solaris 10 includes fail to copy Platform: Solaris2.x/Sparc grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: 6.2.0 ./configure --srcdir=/usr/local/src/grass-6.2.0 --enable-64bit --enable-64bit-vis --with-gdal=/usr/local/bin/gdal-config --enable-largefile --with-python --with-postgres --with-proj-includes=/usr/local/include --with-proj-libs=/usr/local/lib --with-proj-share=/usr/local/share/proj --with-postgres-includes=/usr/local/pgsql/include --with-postgres-libs=/usr/local/pgsql/lib --with-fftw-includes=/usr/local/include --with-fftw-libs=/usr/local/lib bash-3.00# make mkdir -p /usr/local/src/grass-6.2.0/bin.sparc-sun-solaris2.10 mkdir -p /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/include/grass mkdir -p /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/lib mkdir -p /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/bin mkdir -p /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/etc mkdir -p /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/driver mkdir -p /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/driver/db mkdir -p /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/fonts test -d /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10 || mkdir -p -m 755 /usr/local/src/grass-6.2.0/dist.sparc-sun -solaris2.10 tar cBf - demolocation | (cd /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/ ; tar xBfo - ) 2>/dev/null chmod 744 install-sh make[1]: Entering directory `/usr/local/src/grass-6.2.0/lib' ../include/Make/Html.make:32: warning: overriding commands for target `htmlgen' ../include/Make/Html.make:32: warning: ignoring old commands for target `htmlgen' ../include/Make/Html.make:101: warning: overriding commands for target `htmlcmd1' ../include/Make/Html.make:101: warning: ignoring old commands for target `htmlcmd1' ../include/Make/Html.make:107: warning: overriding commands for target `htmlscript1' ../include/Make/Html.make:107: warning: ignoring old commands for target `htmlscript1' ../include/Make/Html.make:117: warning: overriding commands for target `htmletc1' ../include/Make/Html.make:117: warning: ignoring old commands for target `htmletc1' ../include/Make/Html.make:123: warning: overriding commands for target `htmldir1' ../include/Make/Html.make:123: warning: ignoring old commands for target `htmldir1' ../include/Make/Html.make:128: warning: overriding commands for target `htmlmulti' ../include/Make/Html.make:128: warning: ignoring old commands for target `htmlmulti' if [ ! -d /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/include/grass ]; then mkdir -p /usr/local/src/grass-6.2.0/ dist.sparc-sun-solaris2.10/include/grass; fi if [ ! -d /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/include/grass/vect ]; then mkdir -p /usr/local/src/grass-6 .2.0/dist.sparc-sun-solaris2.10/include/grass/vect; fi /usr/local/src/grass-6.2.0/install-sh -c -m 644 ../include/*.h /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/incl ude/grass/ /usr/local/src/grass-6.2.0/install-sh -c -m 644 ../include/vect/*.h /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10 /include/grass/vect/ datetime make[2]: Entering directory `/usr/local/src/grass-6.2.0/lib/datetime' gcc -I/usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/include -g -O2 -fPIC -DPACKAGE=\""grasslibs"\" -DPA CKAGE=\""grasslibs"\" -I/usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/include \ -o OBJ.sparc-sun-solaris2.10/between.o -c between.c gcc -I/usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/include -g -O2 -fPIC -DPACKAGE=\""grasslibs"\" -DPA CKAGE=\""grasslibs"\" -I/usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/include \ -o OBJ.sparc-sun-solaris2.10/copy.o -c copy.c copy.c:7:28: grass/datetime.h: No such file or directory copy.c:28: error: syntax error before '*' token copy.c: In function `datetime_copy': copy.c:30: error: `dst' undeclared (first use in this function) copy.c:30: error: (Each undeclared identifier is reported only once copy.c:30: error: for each function it appears in.) copy.c:30: error: `src' undeclared (first use in this function) copy.c:30: error: `DateTime' undeclared (first use in this function) make[2]: *** [OBJ.sparc-sun-solaris2.10/copy.o] Error 1 make[2]: Leaving directory `/usr/local/src/grass-6.2.0/lib/datetime' gis make[2]: Entering directory `/usr/local/src/grass-6.2.0/lib/gis' gcc -I/usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/include -g -O2 -fPIC -DPACKAGE=\""grasslibs"\" -D_FILE_ OFFSET_BITS=64 -DPACKAGE=\""grasslibs"\" -I/usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/include \ -o OBJ.sparc-sun-solaris2.10/adj_cellhd.o -c adj_cellhd.c adj_cellhd.c:1:23: grass/gis.h: No such file or directory adj_cellhd.c:2:27: grass/glocale.h: No such file or directory >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bash-3.00# ls -R /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/ /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/: bin demolocation driver etc fonts include lib /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/bin: /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/demolocation: PERMANENT /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/demolocation/PERMANENT: DEFAULT_WIND MYNAME PROJ_UNITS WIND3 dig_att site_lists DEFAULT_WIND3 PROJ_INFO WIND dig dig_plus /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/demolocation/PERMANENT/dig: point /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/demolocation/PERMANENT/dig_att: point /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/demolocation/PERMANENT/dig_plus: point /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/demolocation/PERMANENT/site_lists: mysites /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/driver: db /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/driver/db: /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/etc: /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/fonts: /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/include: grass /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/include/grass: CC.h vect /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/include/grass/vect: dig_defines.h /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/lib: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HACK FIX >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cp include/*.h /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/include/grass cp include/vect/*.h /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/include/grass/vect/ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Not sure if this is a problem but it looks odd >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> make[3]: Entering directory `/usr/local/src/grass-6.2.0/db/base' Makefile:22: warning: overriding commands for target `/usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/bin/db.columns' ../../include/Make/Module.make:31: warning: ignoring old commands for target `/usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/bin/ GISRC=/usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/demolocation/.grassrc62 GISBASE=/usr/local/src/grass-6.2.0/dist.sparc-sun-so rc/grass-6.2.0/dist.sparc-sun-solaris2.10/bin:$PATH LD_LIBRARY_PATH="/usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/lib:" LC_ALL= 0/dist.sparc-sun-solaris2.10/bin/db.columns --html-description | grep -v '\|' > db.columns.tmp.html ; true /bin/sh: !: not found /bin/sh: !: not found /bin/sh: !: not found mkdir -p /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/docs/html mv -f db.columns.tmp.html /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/docs/html/db.columns.html for file in *.png *.jpg ; do \ head -n 1 $file | grep '^#!' > /dev/null ; \ if [ $? -ne 0 ] ; then \ /usr/local/src/grass-6.2.0/install-sh -c -m 644 $file /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/docs/htm fi \ done 2> /dev/null ; true install: *.png does not exist install: *.jpg does not exist make[3]: Leaving directory `/usr/local/src/grass-6.2.0/db/base' This happens to a bunch of directories but finishes with no errors and runs. Generating HTML manual pages index (help system)... Generated HTML docs in ../dist.sparc-sun-solaris2.10/docs/html/index.html ---------------------------------------------------------------------- Following modules are missing the 'description.html' file in src code: i.find photo.elev ---------------------------------------------------------------------- GRASS GIS compilation log ------------------------- Started compilation: Fri Nov 3 11:33:53 PST 2006 -- Errors in: -- Finished compilation: Fri Nov 3 11:53:13 PST 2006 (In case of errors please change into the directory with error and run 'make') -------------------------------------------- Managed by Request Tracker From paul-grass at stjohnspoint.co.uk Fri Nov 3 21:10:17 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Fri Nov 3 21:10:25 2006 Subject: [GRASS-dev] Some native Windows changes committed Message-ID: I've committed quite a few MINGW-related changes to CVS there now. I hope that in the long run they will make it easier to make further changes to port GRASS to native Windows, although in the meantime I'm slightly worried they might upset the way GRASS can be cross-compiled for Windows from Linux; that needs to be tested and I can't do that. More detail on the changes below. Configure script and Makefiles ============================== Make an effort to separate the use of variables GISBASE and ARCH_DISTDIR. GISBASE is the location of the temporary location and used when creating manpages - this path needs to be in a form understood by the native operating system (i.e. c:/grass/grassdata format is OK) for opening files etc. ARCH_DISTDIR is where things are installed during the build process and should be in Msys format (i.e. /c/grass/grassdata-style). GISBASE and ARCH_DISTDIR are used interchangeably in Makefiles and unfortunately GISBASE was used far too widely to make it feasible to change it so there is a new variable called RUN_GISBASE which is used when needed for the fake/demo location. Originally I had it that the configure script tested if the pwd command accepts a -W option (for Windows-style pathnames) and if so used that to populate RUN_GISBASE. The Msys-style pathname goes into ARCH_DISTDIR and is used for everything else. But some pwds seem to return true even when used with a non-existent flag so I've changed that to a simple test for MINGW32. Apart from that removed all explicit MinGW conditional stuff from Makefiles and configure script (I think). It means the shared library status and stuff is detected and configured for MINGW the same as for other systems now. MinGW conditionals were a bit mixed up with Cross-compiling conditionals but should be OK now. Wasn't too sure about the GDAL cross-compiling test - couldn't see what it did so have left it out for now. This might affect the stuff Radim does with the Windows GRASS/QGIS combination? I will try to fix it if anyone has any problems as a result of the changes. Also removed the fmode.o stuff that was linked against all the Windows binaries. Saw some discussion about this on the list - binary mode? but everything is working fine for me without it so have left it out. If it needs to go back in it should go in some of the variables in the MinGW section in aclocal.m4 I think. One thing that I'm really not too sure about is the code that creates a copy of the GRASS shared libraries with the GRASS version number (6.3.cvs) as part of the filename and then creates symlinks to those without the version number in the filename. I'm not sure why it does this. It was disabled for Mingw but I re-enabled it for consistency. Maybe it leads to two copies of the libraries now if the Windows filesystem doesn't support symlinks. But can anybody say what it is really needed for? Display lib and PNGdriver fixes =============================== As discussed on the mailing list: http://grass.itc.it/pipermail/grass-dev/2006-October/026963.html Directory separator charcter stuff ================================== New macros added to gis.h: GRASS_DIRSEP and HOST_DIRSEP The idea being that internal to GRASS, as much as possible we use GRASS_DIRSEP (which is /). HOST_DIRSEP and GRASS_DIRSEP are used by the following new functions: /* paths.c */ int G_is_dirsep(char); char *G_convert_dirseps_to_host(char *); char *G_convert_dirseps_from_host(char *); I've used G_convert_dirseps_to_host() in a few places already. Mostly when passing pathnames to the system() function. In that file there is also int G_mkdir(const char *); and also I've changed G_clear_screen() so that it uses cls instead of clear on Windows. In lib/gis/env.c I've removed all the MINGW stuff as discussed on the list. datum and ellipsoid reading functions fixed to handle DOS line endings in text files and handle GRASS_PAGER environment variable in a cross-platform way. g.parser changed to handle scripts with DOS line endings. {G_strip() --> G_chop()} Started to abandon the use of G_system() because it hardcodes the use of /bin/sh. The way it stops Ctrl-C interrupts being passed to the parent calling program is useful in some situations but I'm not sure how to make it work on Windows. Chane Init.sh to set GRASS_PAGER to "more" on Windows if other options fail - it should always be there. Change to G_gets() to handle the carriage return-line feed sequence found on Windows. I hope this change is OK: eof = fgets(p,100,stdin); /* strip the EOL character */ - p[strlen(p)-1]='\0'; + if( strlen(p) > 1 && p[strlen(p)-1] == '\n' && p[strlen(p)-2] == '\r' ) + p[strlen(p)-2]='\0'; /* Handles DOS/Windows "\r\n" */ + else + p[strlen(p)-1]='\0'; /* Handles Unix "\n" or old Mac "\r" */ /* buf could be any length. Any overflow will occur here. */ strcpy(buf,p); In many places in modules we have to change calls to G_getl() to G_getl2() to enable them to handle Windows newline sequences - I wonder why G_getl() was not just changed in CVS and then it would fix everything? Changing G_gets() like this to catch everything seems to me like definitely the easiest solution. lib/init and g.setproj ====================== lib/init/mke_loc.c, set_data.c, g.setproj: fixes to system() calls etc. to make interactive location set-up work. Replace system("clear") call in Vasklib V_init() function with G_clear_screen(). Fixes problem discussed on list here: http://grass.itc.it/pipermail/grass5/2006-October/026824.html r.out.png ========= Updates to add a .png extension to the output file if it isn't there. r.average ========= Fix so calling other modules with system() will work on Windows From michael.barton at asu.edu Fri Nov 3 21:17:48 2006 From: michael.barton at asu.edu (Michael Barton) Date: Fri Nov 3 21:17:57 2006 Subject: [GRASS-dev] more precise zooming -- hopefully Message-ID: Thanks to various contributions, but especially to Glynn who provided details about the mysterious workings of g.region and sent me a set of algorithms, I think I?ve fixed the problem with zooming in to a tiny region for a raster map, such that the grid-cell size is much larger than display pixels. This seemed to be an intractable problem. Essentially, due to the way g.region works at these combinations of resolutions and region size (at least this becomes apparent at this scale), the GIS Manager has to handle a lot of the details of managing extents and resolution that g.region does in most normal circumstances. However, Glynn?s algorithms seem to work well on my Mac (using x11) in UTM and latlon regions, and on one of my student?s Debian machines. So I?ve gone ahead and committed this to the cvs for others to test. I?m also copying Markus. If it works well, it should be backported to 6.2.1. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20061103/ad1ccbdd/attachment.html From tutey at o2.pl Fri Nov 3 22:36:38 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Fri Nov 3 22:36:41 2006 Subject: [GRASS-dev] more precise zooming -- hopefully In-Reply-To: References: Message-ID: <454BB666.2040406@o2.pl> The rows, cols and res are now OK, after setting the WIND to match gis.m display. But, the bounds are set wrong - eg., I get: $ g.region -g n=4920084.41676 s=4919934.41676 w=599434.138252 e=599614.138252 nsres=30 ewres=30 rows=5 cols=6 while it should be: n=4920090 s=4919940 w=599430 e=599610 nsres=30 ewres=30 rows=5 cols=6 Maciek From glynn at gclements.plus.com Fri Nov 3 22:36:53 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Nov 3 22:36:55 2006 Subject: [GRASS-dev] CVS: all images touched? In-Reply-To: <20061103130557.1a6cd454.hamish_nospam@yahoo.com> References: <20061102231423.GB18908@bartok.itc.it> <20061103130557.1a6cd454.hamish_nospam@yahoo.com> Message-ID: <17739.46709.171775.170067@cerise.gclements.plus.com> Hamish wrote: > > something strange happened: all images in 6.2 and 6.3 > > were re-downloaded from CVS while syncing. > > How come? In the commit-logs is nothing. > > I think Glynn tagged them as "binary" files (-kb) in the CVS. > (only done for images missing that, check CVS/Entries record) Correct. The command was "cvs admin -kb ...". As "cvs admin" applies to the file as a whole rather than to a specific version, it doesn't appear in the file's history, so probably won't show up in the commit logs. -- Glynn Clements From glynn at gclements.plus.com Fri Nov 3 22:49:34 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Nov 3 22:52:04 2006 Subject: [GRASS-dev] Zooming issue in gis manager In-Reply-To: References: <17738.34992.698281.420054@cerise.gclements.plus.com> Message-ID: <17739.47470.326954.882432@cerise.gclements.plus.com> Michael Barton wrote: > This is very helpful, though I'll have to sort through this and follow-up > messages to see if and where they can fit into the existing algorithms. > Thanks much. > > A couple of things bother me that perhaps you could clear up. First is that > it looks like your examples below and some of the follow-ups assume that > resolution is always an integer. Although the number of rows and columns > are, of course, integers, I'm sure that ewres and nsres can take on any > float value. This makes what you are suggesting more complicated I think. Oops. In the equations I gave, there should have been some integer casts, e.g.: width = (width / ewres + 0.5) * ewres height = (height / nsres + 0.5) * nsres should be: width = (int)(width / ewres + 0.5) * ewres height = (int)(height / nsres + 0.5) * nsres The bounds and resolution don't have to be integers. Essentially, width/ewres is the number of columns, so the above adjusts the width to be an integer multiple of ewres. ewres itself doesn't have to be an integer. > The other issue is that even when I take out the -a flag, d.rast makes some > kind of adjustments to the way that grid cells are displayed such that they > appear to be somewhat different sized when you make the resolution=1 grid > cell and when you make the resolution>>1 (original) grid cell. Maybe this is > what you are referring to in some places below and other posts. Yes. G_get_window() etc ultimately calls G__read_Cell_head_array() to parse the contents of WIND, $WIND_OVERRIDE, or $GRASS_REGION. In turn, that calls G_adjust_Cell_head(). G_adjust_Cell_head() recomputes the resolution by dividing the width and height of the region by the number of columns and rows. Thus, if the current region (WIND, $WIND_OVERRIDE, or $GRASS_REGION) isn't valid (i.e. (n-s)/rows != nsres or (e-w)/cols != ewres), the resolution will automatically be changed accordingly. The solution is to ensure that the region is always valid, i.e. its width and height are multiples of the resolution. If you obtained the bounds from the user (e.g. marking a rectangle on the canvas), you will have to enforce this requirement somehow. > Finally, is there any reason that I need to be concerned about the values > of GRASS_WIDTH and GRASS_HEIGHT for PPM output? In what sense? -- Glynn Clements From michael.barton at asu.edu Fri Nov 3 23:07:04 2006 From: michael.barton at asu.edu (Michael Barton) Date: Fri Nov 3 23:07:35 2006 Subject: [GRASS-dev] Zooming issue in gis manager In-Reply-To: <17739.47470.326954.882432@cerise.gclements.plus.com> Message-ID: OK. I think I've worked these things out in the version that is now in the cvs. I made a slight change in how the equations below are done in TclTk to round them to the nearest integer value. width = round(width / ewres) * ewres height = round(height / nsres) * nsres Thanks again for pointing the way to solve this. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Glynn Clements > Date: Fri, 3 Nov 2006 21:49:34 +0000 > To: Michael Barton > Cc: grass-dev > Subject: Re: [GRASS-dev] Zooming issue in gis manager > > > Michael Barton wrote: > >> This is very helpful, though I'll have to sort through this and follow-up >> messages to see if and where they can fit into the existing algorithms. >> Thanks much. >> >> A couple of things bother me that perhaps you could clear up. First is that >> it looks like your examples below and some of the follow-ups assume that >> resolution is always an integer. Although the number of rows and columns >> are, of course, integers, I'm sure that ewres and nsres can take on any >> float value. This makes what you are suggesting more complicated I think. > > Oops. In the equations I gave, there should have been some integer > casts, e.g.: > > width = (width / ewres + 0.5) * ewres > height = (height / nsres + 0.5) * nsres > > should be: > > width = (int)(width / ewres + 0.5) * ewres > height = (int)(height / nsres + 0.5) * nsres > > The bounds and resolution don't have to be integers. > > Essentially, width/ewres is the number of columns, so the above > adjusts the width to be an integer multiple of ewres. ewres itself > doesn't have to be an integer. > >> The other issue is that even when I take out the -a flag, d.rast makes some >> kind of adjustments to the way that grid cells are displayed such that they >> appear to be somewhat different sized when you make the resolution=1 grid >> cell and when you make the resolution>>1 (original) grid cell. Maybe this is >> what you are referring to in some places below and other posts. > > Yes. > > G_get_window() etc ultimately calls G__read_Cell_head_array() to parse > the contents of WIND, $WIND_OVERRIDE, or $GRASS_REGION. In turn, that > calls G_adjust_Cell_head(). > > G_adjust_Cell_head() recomputes the resolution by dividing the width > and height of the region by the number of columns and rows. Thus, if > the current region (WIND, $WIND_OVERRIDE, or $GRASS_REGION) isn't > valid (i.e. (n-s)/rows != nsres or (e-w)/cols != ewres), the > resolution will automatically be changed accordingly. > > The solution is to ensure that the region is always valid, i.e. its > width and height are multiples of the resolution. If you obtained the > bounds from the user (e.g. marking a rectangle on the canvas), you > will have to enforce this requirement somehow. > >> Finally, is there any reason that I need to be concerned about the values >> of GRASS_WIDTH and GRASS_HEIGHT for PPM output? > > In what sense? > > -- > Glynn Clements From glynn at gclements.plus.com Fri Nov 3 23:51:15 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Nov 3 23:51:20 2006 Subject: [GRASS-dev] r.resamp.stats method=sum artifacts In-Reply-To: <200611031048.19138.dylan.beaudette@gmail.com> References: <20061030174705.7d4b55fa.hamish_nospam@yahoo.com> <4549C525.7040701@itc.it> <17738.38215.60067.687312@cerise.gclements.plus.com> <200611031048.19138.dylan.beaudette@gmail.com> Message-ID: <17739.51171.613993.565599@cerise.gclements.plus.com> Dylan Beaudette wrote: > I have been noticing some odd edge effects when using r.resamp.stats > method=mode .... i.e. i am getting a "ring" of cells with 0-value around the > actual data. Within the "ring" the results appear to match those obtained > with an alternate raster-vector-starspan-raster approach to doing the same > operation. > > a graphical summary can be found here: > http://169.237.35.250/~dylan/temp/method_mode-test.png I wasn't making the source window large enough, with the result that edge cells were using garbage values from outside of the source buffer. [r.resamp.stats was derived from r.resamp.interp. The window-setting code was left untouched, but r.resamp.interp only needs source values corresponding to the destination cell's centre +/- 2 source cells, while r.resamp.stats needs source values for the whole of the destination cell's area.] I've committed the attached patch to CVS. Let me know if you still encounter problems. -- Glynn Clements -------------- next part -------------- Index: main.c =================================================================== RCS file: /grassrepository/grass6/raster/r.resamp.stats/main.c,v retrieving revision 1.6 diff -u -r1.6 main.c --- main.c 31 Oct 2006 22:34:41 -0000 1.6 +++ main.c 3 Nov 2006 22:40:00 -0000 @@ -290,14 +290,10 @@ /* enlarge source window */ { - double north = G_row_to_northing(0.5, &dst_w); - double south = G_row_to_northing(dst_w.rows - 0.5, &dst_w); - int r0 = (int) floor(G_northing_to_row(north, &src_w) - 0.5) - 1; - int r1 = (int) floor(G_northing_to_row(south, &src_w) - 0.5) + 3; - double west = G_col_to_easting(0.5, &dst_w); - double east = G_col_to_easting(dst_w.cols - 0.5, &dst_w); - int c0 = (int) floor(G_easting_to_col(west, &src_w) - 0.5) - 1; - int c1 = (int) floor(G_easting_to_col(east, &src_w) - 0.5) + 3; + int r0 = (int) floor(G_northing_to_row(dst_w.north, &src_w)); + int r1 = (int) ceil (G_northing_to_row(dst_w.south, &src_w)); + int c0 = (int) floor(G_easting_to_col(dst_w.west, &src_w)); + int c1 = (int) ceil (G_easting_to_col(dst_w.east, &src_w)); src_w.south -= src_w.ns_res * (r1 - src_w.rows); src_w.north += src_w.ns_res * (-r0); From glynn at gclements.plus.com Sat Nov 4 00:15:05 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Nov 4 00:15:08 2006 Subject: [GRASS-dev] [bug #5255] (grass) Solaris 10 includes fail to copy In-Reply-To: <20061103200916.DA9431005DB@lists.intevation.de> References: <20061103200916.DA9431005DB@lists.intevation.de> Message-ID: <17739.52601.430030.920632@cerise.gclements.plus.com> Request Tracker wrote: > this bug's URL: http://intevation.de/rt/webrt?serial_num=5255 > ------------------------------------------------------------------------- > > Subject: Solaris 10 includes fail to copy > > Platform: Solaris2.x/Sparc > grass obtained from: Trento Italy site > grass binary for platform: Compiled from Sources > GRASS Version: 6.2.0 > make[1]: Entering directory `/usr/local/src/grass-6.2.0/lib' > /usr/local/src/grass-6.2.0/install-sh -c -m 644 ../include/*.h /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/include/grass/ > /usr/local/src/grass-6.2.0/install-sh -c -m 644 ../include/vect/*.h /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/include/grass/vect/ > make[2]: Entering directory `/usr/local/src/grass-6.2.0/lib/datetime' > copy.c:7:28: grass/datetime.h: No such file or directory > bash-3.00# ls -R /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/ > /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/include: > grass > /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/include/grass: > CC.h vect > /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/include/grass/vect: dig_defines.h $(INSTALL) isn't guaranteed to work for multiple files. Clearly, on this platform, it *doesn't* work for multiple files. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > HACK FIX > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > cp include/*.h /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/include/grass > cp include/vect/*.h /usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/include/grass/vect/ IMHO, the correct fix is: - $(INSTALL) -m 644 ../include/*.h $(GISBASE)/include/grass/ - $(INSTALL) -m 644 ../include/vect/*.h $(GISBASE)/include/grass/vect/ + for file in ../include/*.h ; do $(INSTALL) -m 644 $$file $(GISBASE)/include/grass/ ; done + for file in ../include/vect/*.h ; do $(INSTALL) -m 644 $$file $(GISBASE)/include/grass/vect/ ; done "cp" preserves the file's permissions, which isn't a good idea (e.g. if the files were checked out with restrictive permissions, they will be installed that way). > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Not sure if this is a problem but it looks odd > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > make[3]: Entering directory `/usr/local/src/grass-6.2.0/db/base' > Makefile:22: warning: overriding commands for target `/usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/bin/db.columns' > ../../include/Make/Module.make:31: warning: ignoring old commands for target `/usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/bin/ > GISRC=/usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/demolocation/.grassrc62 GISBASE=/usr/local/src/grass-6.2.0/dist.sparc-sun-so > rc/grass-6.2.0/dist.sparc-sun-solaris2.10/bin:$PATH LD_LIBRARY_PATH="/usr/local/src/grass-6.2.0/dist.sparc-sun-solaris2.10/lib:" LC_ALL= > 0/dist.sparc-sun-solaris2.10/bin/db.columns --html-description | grep -v '\|' > db.columns.tmp.html ; true > /bin/sh: !: not found > /bin/sh: !: not found > /bin/sh: !: not found Do you get correct HTML documentation? I interpret the above error as suggesting that the shell doesn't support "!" as in "if ! grep ...". If you have bash installed, you could try e.g. "make SHELL=/usr/local/bin/bash". -- Glynn Clements From glynn at gclements.plus.com Sat Nov 4 00:34:46 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Nov 4 00:34:50 2006 Subject: [GRASS-dev] Some native Windows changes committed In-Reply-To: References: Message-ID: <17739.53782.891034.602696@cerise.gclements.plus.com> Paul Kelly wrote: > One thing that I'm really not too sure about is the code that creates a > copy of the GRASS shared libraries with the GRASS version number (6.3.cvs) > as part of the filename and then creates symlinks to those without the > version number in the filename. > I'm not sure why it does this. It was disabled for Mingw but I re-enabled > it for consistency. Maybe it leads to two copies of the libraries now if > the Windows filesystem doesn't support symlinks. But can anybody say what > it is really needed for? AFAICT, the version number doesn't have any real purpose. The GRASS shared libraries aren't versioned in the sense that most shared libraries are (i.e. with a trailing version number, incorporated in the library's soname). The main reason being that there isn't any point unless you increment the version number whenever the ABI changes, and the GRASS development process isn't really disciplined enough to do that. > Started to abandon the use of G_system() because it hardcodes the use of > /bin/sh. G_system() specifically uses command.com on Windows: #ifdef __MINGW32__ signal (SIGINT, SIG_DFL); _spawnl ( P_WAIT, "command", "command", "/c", command, NULL ); #else If anything, we should move towards G_system() rather than away from it. That would allow various portability hacks to be localised in one place rather than spread across modules. Better still would be to implement G_spawn[_ex] on Windows and use that instead. Those functions don't use a shell, which eliminates a major source of potential problems. > The way it stops Ctrl-C interrupts being passed to the parent > calling program is useful in some situations but I'm not sure how to make > it work on Windows. Note that system() behaves in the same way; at least, it's supposed to. The comments for that function suggest that it was implemented as a workaround for platforms with broken system() functions. > In many places in modules we have to change calls to G_getl() to G_getl2() > to enable them to handle Windows newline sequences - I wonder why G_getl() > was not just changed in CVS and then it would fix everything? Changing > G_gets() like this to catch everything seems to me like definitely the > easiest solution. Probably because someone thought that there *might* be a situation where the CR needed to be preserved, and didn't want to scan the entire source tree to check. > lib/init and g.setproj > ====================== > > lib/init/mke_loc.c, set_data.c, g.setproj: fixes to system() calls etc. to > make interactive location set-up work. Replace system("clear") call in > Vasklib V_init() function with G_clear_screen(). Fixes problem discussed > on list here: The vask library should just use the curses clear() function. The "problem" with it not "working" on xterm isn't a problem, but a feature. Using system("clear") etc is a hack for programs which want to clear the screen (and many of these probably *shouldn't* be clearing the screen) but where using curses would be overkill. -- Glynn Clements From grass-bugs at intevation.de Sat Nov 4 08:56:10 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sat Nov 4 08:56:12 2006 Subject: [GRASS-dev] [bug #5257] (grass) Tcl install copy fails Message-ID: <20061104075610.436C4101EE3@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5257 ------------------------------------------------------------------------- Subject: Tcl install copy fails Platform: Solaris2.x/Sparc grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: 6.2.0 Tcl not copied during install Solaris 10 HACK FIX cp /usr/local/src/grass-6.2.0/lib/gtcltk/*.tcl /usr/local/grass-6.2.0/etc/gtcltk/ cp /usr/local/src/grass-6.2.0/lib/external/bwidget/*.tcl /usr/local/grass-6.2.0/bwidget/ -------------------------------------------- Managed by Request Tracker From tutey at o2.pl Sat Nov 4 11:22:05 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Sat Nov 4 11:22:11 2006 Subject: [GRASS-dev] Re: [GRASS-CVS] michael: grass6/gui/tcltk/gis.m mapcanvas.tcl, 1.48, 1.49 In-Reply-To: <20061104000148.3F79B1005C1@lists.intevation.de> References: <20061104000148.3F79B1005C1@lists.intevation.de> Message-ID: <454C69CD.8040206@o2.pl> grass@intevation.de wrote: > Author: michael > > Update of /grassrepository/grass6/gui/tcltk/gis.m > In directory doto:/tmp/cvs-serv2677 > > Modified Files: > mapcanvas.tcl > Log Message: > Slight update to align starting point for display with resolution With this fix the gis.m - WIND interaction seems all OK for me. Great! Maciek From tutey at o2.pl Sat Nov 4 11:59:48 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Sat Nov 4 11:59:54 2006 Subject: [GRASS-dev] single-click zoom doesn't preserve aspect ratio Message-ID: <454C72A4.8090302@o2.pl> Michael, Now that the gis.m - WIND interaction is OK, I would like to raise the remaining issue with zooming in gis.m: The single-click zoom in/out doesn't preserve the aspect ratio, in the constrained zoom mode; it expands the region to fill the whole map display canvas instead, like if it was the "Map fills display window" mode. Maciek P.S. Trying to switch to "Map fills display window" mode, I get an error: can't read "nsres": no such variable can't read "nsres": no such variable while executing "expr round(abs($n-$s)/$nsres)" (procedure "MapCanvas::currentzoom" line 27) invoked from within "MapCanvas::currentzoom $mon" (procedure "MapCanvas::runprograms" line 24) invoked from within "MapCanvas::runprograms $mon [expr {$mymodified != 0}]" (procedure "MapCanvas::drawmap" line 38) invoked from within "MapCanvas::drawmap $mon" (procedure "MapCanvas::display_server" line 9) invoked from within "MapCanvas::display_server" ("after" script) From spano at cli.di.unipi.it Sat Nov 4 15:53:12 2006 From: spano at cli.di.unipi.it (Davide Spano) Date: Sat Nov 4 15:53:41 2006 Subject: [GRASS-dev] [bug #5252] (grass) Multicore hardware and grass In-Reply-To: <454ADDB7.9040006@faunalia.it> References: <454ADDB7.9040006@faunalia.it> Message-ID: <6242A8E2-B160-4CA1-8829-C868699B0271@cli.di.unipi.it> Hi, I'm Davide Spano, student of Computer Science, Univesity of Pisa, I'd like to comment last Glynn mail > > ;) Version 10 sounds about right. > > A lot of the problem is that: > > 1. The libraries can't readily be parallelised without changing the > API. > 2. Changing the API means re-writing modules which use it. > 3. Much of GRASS' value is in the modules, so re-writing the modules > equates to re-writing most of GRASS. That is dramatically true not only for GRASS, but also for all OS we use. The first try for parallelization is to introduce locks on olds APIs, this is not a good idea because the improvement is 1.5x max. This phenomenom is known as software lockout: the CPUs spends more time in synchonization rather than calculation. We did not use CPUs with more than two cores for this reason... > > There might be some specific cases which are amenable to > parallelisation. E.g. it might be possible to re-write the core raster > I/O to use threads in a producer-consumer model, so that > get-row/put-row operations essentially take no time (i.e. the module > runs entirely in the main thread, while a separate thread performs the > raster I/O). That might give a 2x speed-up on a dual-core system, but > still wouldn't scale to larger numbers of cores (i.e. you would still > only get a 2x speed-up on a 16-core system). > Because this kinds of parallelisations are not the best solutions, I suggest first to read some literature that covers standartd techniques: farm, pipelining, map etc... The real core of this problem is the interprocess communication, for 16x or more improvements we need to overlap IPC to internal calculation, and it is really possible only if the OS offers a support. Davide From tutey at o2.pl Sat Nov 4 16:17:03 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Sat Nov 4 16:17:19 2006 Subject: [GRASS-dev] GRASS at GForge first steps Message-ID: <454CAEEF.7020506@o2.pl> Hi, Thanks to Sascha Wilde the problem I had with rights assignement at GForge is gone. It seems it was a user (my) error. Before new GRASS tracker is announced for users, I'm kindly asking developers to have a look at what I have done and let me know if there is something that needs a change or fix. Under GRASS GForge project [4] I have set up two trackers for GRASS: issues [1] and patches [2]. Issues tracker is for bugs, defects, wishes. I will take care of it in terms of sorting out bugs which are doubtfull or lacking information. I can also fix some minor stuff like docs, typos in the code, shell scripts etc.. Patches tracker is for storing and managing the patches candidates (both code and docs). Currently, they are often sent to dev list. If they are not reacted upon quickly, or too intrusive to be applied right away but valuable for future developmement, they happen to be forgotten. The tracker might help us to manage them in a convenient way. Jachym volunteered to maintain the code patches submitted. Thanks Jachym! Is there somebody willing to take care of docs submitted? Trackers are available for public view, but in order to be able to post (including creating a new report), you must setup your account at GForge first [3]. This is to avoid http spam. All the trackers' posts are automatically forwarded to grass-dev list currently. If you want to be able to modify the contents of Trackers, you should request to join the GRASS project at GForge as developer [5]. GForge provides many functionalities. AFAIK, it was aggreed that we are currently going to use only the Trackers, as all the other functionalities are implemented in the current GRASS infrastructure (besides surveys, which I discuss later in this mail). Thus, although there are various project member Roles possible to define, IMHO we should only use 3: admin, user and developer: 1. Admin is in charge of accepting requests to join the project and configuring the GRASS project at GForge. Currently I'm the only admin. We need 2 (3?), in case I'm not available. Candidates? 2. Developer can do most of the things that admin can. Only that he doesn't have his duties and he can't remove the whole project, add/modify/delete trackers. He also can't delete a ticket permanently - only the admin can. I think such restrictions are sane - getting familiar with GForge options takes some time, and we don't want accdental corruptions. Eg. I happened to remove a tracker by accident when learning GForge. And I'm definitely not an expert yet. 3. User. He can open new tickets in the trackers and participate it surveys (Admin and developer can too, of course). Talking of surveys - Jachym suggested using this nice GForge feature. Any GRASS project member at GForge can vote on the survey. Admin can access the survey results, and create new ones. I was wondering if GRASS folks find it usefull. Thus, I have created a survey for that :) [7]. Opinions? The possible problem I see is that only admin can access the survey results :(, and there is no way to change this (CCing Bernhard if he has an idea). You can see an example results in the picture attached (I accidently voted twice - as admin and as a testing user). GForge manuals are here: [6]. [1]http://wald.intevation.org/tracker/?atid=182&group_id=21&func=browse [2]http://wald.intevation.org/tracker/?atid=183&group_id=21&func=browse [3]http://wald.intevation.org/account/register.php [4]http://wald.intevation.org/projects/grass/ [5]http://wald.intevation.org/project/request.php?group_id=21 [6]http://gforge.org/docman/index.php?group_id=1&selected_doc_group_id=5&language_id=1 Maciek -------------- next part -------------- A non-text attachment was scrubbed... Name: survey.png Type: image/png Size: 3781 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061104/be41f414/survey-0001.png From grass-bugs at intevation.de Sat Nov 4 16:28:24 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sat Nov 4 16:28:25 2006 Subject: [GRASS-dev] [bug #5258] (grass) v.in.region does not create db table (in postgresql) Message-ID: <20061104152824.2322A101F00@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5258 ------------------------------------------------------------------------- Subject: v.in.region does not create db table (in postgresql) Platform: GNU/Linux/x86 grass obtained from: CVS grass binary for platform: Compiled from Sources GRASS Version: 6.3cvs Generating a new vector (area) file with the current region extent by the v.in.region command does not create automatically a corresponding database table in PosgreSQL. This results in errors when trying to rename the file or when using this vector file in certain overlay procedures, such as v.patch and v.overlay, when table contents should be inherited: v.patch -e input=paguirre2006base4,testarea output=testpatch --overwrite GRASS_INFO_ERROR(28119,1): Missing table Manually creating a database table in PostgreSQL, connecting it to the vector file (v.db.connect) and updloading the cat values is a simple workaround so far. Sincerely, Guido Lorenz Universidad Nacional de Santiago del Estero Argentina -------------------------------------------- Managed by Request Tracker From tutey at o2.pl Sat Nov 4 16:34:04 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Sat Nov 4 16:34:08 2006 Subject: [GRASS-dev] BT status Message-ID: <454CB2EC.60703@o2.pl> Dear Developers, We did our best to clean up the BT as far as possible. Work has still to be done in regard to older bugs, but you can assume that vast most of reports newer than 3 months is double checked and left open as still valid. I've been following the GRASS CVS commit and GRASS dev lists in recent months to make sure I don't miss any relevant changes in the source code. This makes quite a huge list of open issues. Please don't take it as a demanding, but just as a reminder, a note on things left not fixed despite of being known. It would be great if these bugs and defects could be dealt with. I'm propably the last person to remind any hard-working Developer to do something, but since few weeks ago, in my email to Glynn and dev-list I promised a list of valid bugs to be taken care of - here it is. Regards, Maciek From grass-bugs at intevation.de Sat Nov 4 16:46:50 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sat Nov 4 16:46:53 2006 Subject: [GRASS-dev] [bug #5259] (grass) reply to Hamish on Ticket 5254: enable v.what to report on more than one category Message-ID: <20061104154650.EA0CE101F01@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5259 ------------------------------------------------------------------------- >> I don't know how often situations like this might arise, however... >>=20 >> I have a database with over 75000 records (~30 fields/record) which is > >poorly georeferenced (it uses an odd alpha-numeric mapping reference >> involving map book pages, etc), such that locations can be defined >> only to the nearest 1km by 1km area. I have calculated UTM centered on > >the 1 km squares for each record using a spreadsheed. These 75000 > >records imported into Grass result in approx. 12500 points (too much > >data to sort on a spreadsheet). >>=20 >> While some data points may contain as many as 20 categories, it > >appears that v.what can report on only one category (the first one > >encountered?). It would be nice if v.what could "drill through" all > >categories at each point to report all data. In addition, it would be > >nice if a new Grass module could be developed to allow functions like > >mean, max, min, etc., to be done for the various fields available in > >this too-many-categories-per-point database, in which case some very > >useful surface maps could be produced. >>=20 > >I do not write code and so cannot contribute directly to development, > >but I introduce the concept here in the hope that someone who can > >write might find this change to v.what and/or a new function handy. I > >am willing to make parts of the database available for such > >development and can participate in testing. > does v.perturb help to get the points directly off the top of one > another? if error is +/- 500m anyway, introducing a few cm won't harm.. > Hamish Hamish, thanks for your quick reply. I tried to respond via the bugtracking system, but my reply for some reason= =20 does not appear on the Web page. Thus this email to you. I have tried v.perturb and I can "unstack" the data points nicely so to be = =20 able to query each individually while keeping spatial error low. However, =20 this requires clicking on each point individually instead of being able to = =20 produce a display or printed records of all data at that location. Thus my = =20 wish to "drill" through the data at each location as one item. This database is large, with over 75000 records (~30 attributes per record)= =20 and point "stacks" at over 12500 locations, with 1 point only in the stack = at =20 some locations, but over 50 in the stack at others. These "stacks" are =20 compilations of records which were known to be present within given 1km^2 =20 areas, but for which no better georeferencing is available. Thus my decisio= n =20 to center data (point) "stacks" within 1km squares. What I need to do with this data is to find count, max, min, mode, median, = =20 average, std, etc. for a number of attributes for the stacked sets of point= s, =20 from which I could then do surfaces to analyze the data. If something like = =20 r.neighbor existed for work on vectors (points), then I could accomplish th= is =20 following a v.perturb. I cannot do v.to.rast and then apply r.neighbor or =20 v.neighbour, as the conversion to raster of over 50 points into a raster wi= th =20 25m by 25m cells would result in lost data and/or too large and inconsisten= t =20 (uncontrolled) spatial error. I am guessing that data analysis situations such as mine must arise fairly = =20 frequently. Thus my wish for a new Grass module (v.neighbor2 perhaps?). One= =20 that could perhaps (after doing v.perturb) report statistics on points on o= ne =20 vector map surrounding a certain distance around points on another vector m= ap =20 (note that points could also read "line" or "area")? Regards, Rick --- Headers Follow --- >From rg-ewc@waterwatch.com Sat Nov 4 16:46:50 2006 Return-Path: Delivered-To: grass-bugs@lists.intevation.de Received: from kolab.intevation.de (aktaia [212.95.126.10]) by lists.intevation.de (Postfix) with ESMTP id BF2C4101F00 for ; Sat, 4 Nov 2006 16:46:50 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id A6ED81139C1 for ; Sat, 4 Nov 2006 16:46:50 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 7BDDA1858B8 for ; Sat, 4 Nov 2006 16:46:50 +0100 (CET) Received: from simmts6-srv.bellnexxia.net (simmts6.bellnexxia.net [206.47.199.164]) by kolab.intevation.de (Postfix) with ESMTP id 144771139C1 for ; Sat, 4 Nov 2006 16:46:48 +0100 (CET) Received: from rick3.ewc ([142.167.245.179]) by simmts6-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20061104154642.XCLS25660.simmts6-srv.bellnexxia.net@rick3.ewc> for ; Sat, 4 Nov 2006 10:46:42 -0500 Date: Sat, 04 Nov 2006 11:46:41 -0400 From: "Richard Gagne P.Geo." Reply-To: rg-ewc@waterwatch.com Subject: reply to Hamish on Ticket 5254: enable v.what to report on more than one category To: grass-bugs@intevation.de X-Mailer: Balsa 2.3.12 Message-Id: <1162655201l.2446l.0l@rick3.ewc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at intevation.de X-Spam-Status: No, hits=-4.961 tagged_above=-999 required=3 tests=[BAYES_00=-5, MIME_QP_LONG_LINE=0.039] X-Spam-Level: -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Sat Nov 4 18:09:21 2006 From: grass-bugs at intevation.de (Markus Neteler via RT) Date: Sat Nov 4 18:09:25 2006 Subject: [GRASS-dev] [bug #1977] (grass) d.histogram produces illegible axes labels Message-ID: <20061104170921.E36E2101F00@lists.intevation.de> https://intevation.de/rt/webrt?serial_num=1977 > When using the d.histogram feature on a floating point raster such as > elevations, the resulting axis tic marks and labels are often illegible. > > Workaround: Greatly reducing the number of bins (nsteps) in the histogram will > produce resonable axes tic marks. > > Axes labels and tic marks should handle large numbers of bins gracefully. It would be really good to get the horizontal ticks/labels problem fixed. Is there anyone who is willing to take a look? I tried a while but didn't find a solution (maybe it isn't that hard, though). Markus -------------------------------------------- Managed by Request Tracker From Florian.Kindl at uibk.ac.at Sat Nov 4 18:13:07 2006 From: Florian.Kindl at uibk.ac.at (Florian Kindl) Date: Sat Nov 4 18:13:09 2006 Subject: [GRASS-dev] do not get debug messages in 63-cvs Message-ID: Hello list! For some time the debug messages in grass63-cvs are no longer working for me. `g.gisenv set=DEBUG=5` seems to do its job as `g.gisenv DEBUG` returns "5" but no debug messages are printed when I call a module. I tried a `make distclean`, even a complete new install of the whole source tree, but the problem is still there. `./configure` and `make` run without errors... It works fine in grass6.2.0-RC3 on the same machine, configured and compiled the same way. Any ideas where the problem lies or what I did wrong? Thank you, Florian -- Florian Kindl Institute of Geography University of Innsbruck From paul-grass at stjohnspoint.co.uk Sat Nov 4 22:31:23 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sat Nov 4 22:31:25 2006 Subject: [GRASS-dev] Some native Windows changes committed In-Reply-To: References: Message-ID: On Fri, 3 Nov 2006, Paul Kelly wrote: > Also removed the fmode.o stuff that was linked against all the Windows > binaries. Saw some discussion about this on the list - binary mode? but > everything is working fine for me without it so have left it out. If it needs > to go back in it should go in some of the variables in the MinGW section in > aclocal.m4 I think. I added that back in as I don't know the extent of the problems it fixes. Creating files in non-binary mode was the problem with lib/fonts/for_grass failing to compile anyway. From cavallini at faunalia.it Sat Nov 4 22:38:30 2006 From: cavallini at faunalia.it (Paolo Cavallini) Date: Sat Nov 4 22:38:33 2006 Subject: [GRASS-dev] Re: [GRASS-PSC] adding r.li to GRASS: speed In-Reply-To: <454AFE79.7020606@faunalia.it> References: <454A2D2C.6080906@itc.it> <20061103124221.673cfc39.hamish_nospam@yahoo.com> <454AEE4F.2060906@faunalia.it> <454AFD5E.9010601@supsi.ch> <454AFE79.7020606@faunalia.it> Message-ID: <454D0856.6000008@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all. Some speed testing; on the same data set: rows: 451 cols: 652 cells: 294052 moving window 10x10 Shannon analysis is almost 3 times faster: r.li.shannon real 7m41.768s user 0m43.475s sys 1m15.213s r.le real 21m47.613s user 13m56.812s sys 2m41.030s AFAICU, IO (disk access) time is the limiting factor. All the best. pc - -- Paolo Cavallini email+jabber: cavallini@faunalia.it www.faunalia.it Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFTQhV/NedwLUzIr4RAtSzAJ4tIg8tC9DWyox4XHkY2pl2w8K7wACfT7YF yBk7mkbgk0RUH5LyNB7IZtA= =Mv1g -----END PGP SIGNATURE----- From landa.martin at gmail.com Sat Nov 4 23:31:45 2006 From: landa.martin at gmail.com (Martin Landa) Date: Sat Nov 4 23:31:47 2006 Subject: [GRASS-dev] do not get debug messages in 63-cvs In-Reply-To: References: Message-ID: Hi, see http://grass.itc.it/pipermail/grass-dev/2006-October/026644.html Best, Martin 2006/11/4, Florian Kindl : > Hello list! > > For some time the debug messages in grass63-cvs are no longer working for > me. > > `g.gisenv set=DEBUG=5` seems to do its job as `g.gisenv DEBUG` returns > "5" but no debug messages are printed when I call a module. > > I tried a `make distclean`, even a complete new install of the whole > source tree, but the problem is still there. > `./configure` and `make` run without errors... > > It works fine in grass6.2.0-RC3 on the same machine, configured and > compiled the same way. > > Any ideas where the problem lies or what I did wrong? > > Thank you, > Florian > > > > > -- > Florian Kindl > Institute of Geography > University of Innsbruck > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From landa.martin at gmail.com Sat Nov 4 23:48:02 2006 From: landa.martin at gmail.com (Martin Landa) Date: Sat Nov 4 23:48:05 2006 Subject: [GRASS-dev] GRASS at GForge first steps In-Reply-To: <454CAEEF.7020506@o2.pl> References: <454CAEEF.7020506@o2.pl> Message-ID: Hi Maciek, 2006/11/4, Maciej Sieczka : [snip] > Patches tracker is for storing and managing the patches candidates > (both code and docs). Currently, they are often sent to dev list. If > they are not reacted upon quickly, or too intrusive to be applied right > away but valuable for future developmement, they happen to be > forgotten. The tracker might help us to manage them in a convenient > way. Jachym volunteered to maintain the code patches submitted. Thanks > Jachym! Is there somebody willing to take care of docs submitted? I can do it (not sure whether I am the right person for managing docs...) [snip] > GForge provides many functionalities. AFAIK, it was aggreed that we are > currently going to use only the Trackers, as all the other > functionalities are implemented in the current GRASS infrastructure > (besides surveys, which I discuss later in this mail). Thus, although > there are various project member Roles possible to define, IMHO we > should only use 3: admin, user and developer: > > 1. Admin is in charge of accepting requests to join the project and > configuring the GRASS project at GForge. Currently I'm the only admin. > We need 2 (3?), in case I'm not available. Candidates? +1 (if needed, BUT no experience with GForge) > 2. Developer can do most of the things that admin can. Only that he > doesn't have his duties and he can't remove the whole project, > add/modify/delete trackers. He also can't delete a ticket permanently - > only the admin can. I think such restrictions are sane - getting > familiar with GForge options takes some time, and we don't want > accdental corruptions. Eg. I happened to remove a tracker by accident > when learning GForge. And I'm definitely not an expert yet. > > 3. User. He can open new tickets in the trackers and participate it > surveys (Admin and developer can too, of course). > > Talking of surveys - Jachym suggested using this nice GForge feature. > Any GRASS project member at GForge can vote on the survey. Admin can > access the survey results, and create new ones. I was wondering if > GRASS folks find it usefull. Thus, I have created a survey for that :) > [7]. Opinions? The possible problem I see is that only admin can access > the survey results :(, and there is no way to change this (CCing > Bernhard if he has an idea). You can see an example results in the > picture attached (I accidently voted twice - as admin and as a testing > user). > > GForge manuals are here: [6]. > > [1]http://wald.intevation.org/tracker/?atid=182&group_id=21&func=browse > [2]http://wald.intevation.org/tracker/?atid=183&group_id=21&func=browse > [3]http://wald.intevation.org/account/register.php > [4]http://wald.intevation.org/projects/grass/ > [5]http://wald.intevation.org/project/request.php?group_id=21 > [6]http://gforge.org/docman/index.php?group_id=1&selected_doc_group_id=5&language_id=1 Best regards, Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From hamish_nospam at yahoo.com Sun Nov 5 04:23:50 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Nov 5 04:24:12 2006 Subject: [GRASS-dev] Re: [GRASS-user] Compilation failure r.in.xyz on FreeBSD In-Reply-To: <20061104173442.GA4641@bogodyn.org> References: <20061104173442.GA4641@bogodyn.org> Message-ID: <20061105162350.21b2d979.hamish_nospam@yahoo.com> Tom Russo wrote: > I just tried to build today's CVS checkout, and got a compilation > failure in r.in.xyz on my FreeBSD system. The problem is the last > commit changed the type of the "filesize" variable to off_t, but on > FreeBSD it is necessary to have an explicit include of > to get the off_t typedef. > > Inserting a > #include > immediately before the include of fixed the problem. ok, I guess that wasn't as safe as I though it was. should the "#include " be included in or placed by hand in each module that uses "off_t"? Hamish From hamish_nospam at yahoo.com Sun Nov 5 04:26:07 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Nov 5 04:26:12 2006 Subject: [GRASS-dev] do not get debug messages in 63-cvs In-Reply-To: References: Message-ID: <20061105162607.3ef9cea3.hamish_nospam@yahoo.com> Florian Kindl wrote: > > For some time the debug messages in grass63-cvs are no longer working > for me. > > `g.gisenv set=DEBUG=5` seems to do its job as `g.gisenv DEBUG` returns > "5" but no debug messages are printed when I call a module. > > I tried a `make distclean`, even a complete new install of the whole > source tree, but the problem is still there. > `./configure` and `make` run without errors... > > It works fine in grass6.2.0-RC3 on the same machine, configured and > compiled the same way. > > Any ideas where the problem lies or what I did wrong? I have the same trouble. I don't know why it happens. It works fine for me in 6.2. Hamish From hamish_nospam at yahoo.com Sun Nov 5 04:40:39 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Nov 5 04:40:46 2006 Subject: [GRASS-dev] [bug #1977] (grass) d.histogram produces illegible axes labels In-Reply-To: <20061104170921.E36E2101F00@lists.intevation.de> References: <20061104170921.E36E2101F00@lists.intevation.de> Message-ID: <20061105164039.4ddc34b0.hamish_nospam@yahoo.com> Markus Neteler via RT wrote: > https://intevation.de/rt/webrt?serial_num=1977 > > > When using the d.histogram feature on a floating point raster such > > as elevations, the resulting axis tic marks and labels are often > > illegible. > > > > Workaround: Greatly reducing the number of bins (nsteps) in the > > histogram will produce resonable axes tic marks. > > > > Axes labels and tic marks should handle large numbers of bins > > gracefully. > > It would be really good to get the horizontal ticks/labels problem > fixed. Is there anyone who is willing to take a look? I tried a while > but didn't find a solution (maybe it isn't that hard, though). from previous attempt at fixing this bug: ============================================== From: Hamish Subject: Re: d.histogram label bug Date: Wed, 5 Apr 2006 13:01:34 +1200 To: Markus > you will probably know the attached d.histogram label > bug (see screenshot). yes > It seems to be "just" the density of tics/labels > which isn't estimated correctly (maybe divide by 10 > or so to make it readable). > > The raster map stats are: > > n: 1116427 > minimum: -23.1376 > maximum: -8.79618 > range: 14.3414 > mean: -16.509 > standard deviation: 2.02468 > variance: 4.09934 > variation coefficient: -12.2641 % > sum: -18431148.6160733774 AFAICT it only happens with FP maps, and if you stretch the window larger or smaller it can fix itself. > I have tried a while but don't really understand > how it works in bar.c. > > Maybe you could take a few minutes to investigate? It's a bit complicated... default for fs maps is to reduce to 255 cats as in r.stats, but the calculation for tick spacing is using the FP range: conflict of units. As proof of concept this fixes the ticks (I think, not a proper fix), but the labels need changing too, as now they won't match up. bar.c line ~120 // while((range_dmax - range_dmin)/tics[i].every > max_tics) while ((num_cats/tics[i].every) > max_tics) i++; but I'm not sure if ticks should line up with the 255 rectangles or line up with whole numbers of the FP range. anyway, some why. Maybe I will look into it further once I have my next batch of models running. Hamish From glynn at gclements.plus.com Sun Nov 5 06:41:03 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Nov 5 06:42:01 2006 Subject: [GRASS-dev] Re: [GRASS-user] Compilation failure r.in.xyz on FreeBSD In-Reply-To: <20061105162350.21b2d979.hamish_nospam@yahoo.com> References: <20061104173442.GA4641@bogodyn.org> <20061105162350.21b2d979.hamish_nospam@yahoo.com> Message-ID: <17741.31087.965141.731828@cerise.gclements.plus.com> Hamish wrote: > > I just tried to build today's CVS checkout, and got a compilation > > failure in r.in.xyz on my FreeBSD system. The problem is the last > > commit changed the type of the "filesize" variable to off_t, but on > > FreeBSD it is necessary to have an explicit include of > > to get the off_t typedef. > > > > Inserting a > > #include > > immediately before the include of fixed the problem. > > ok, I guess that wasn't as safe as I though it was. > > should the "#include " be included in or > placed by hand in each module that uses "off_t"? The latter. OTOH, if we add G_fseek/G_ftell functions which take/return off_t, then it would need to go into . -- Glynn Clements From hamish_nospam at yahoo.com Sun Nov 5 06:44:55 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Nov 5 06:44:59 2006 Subject: [GRASS-dev] [bug #5258] (grass) v.in.region does not create db table (in postgresql) In-Reply-To: <20061104152824.2322A101F00@lists.intevation.de> References: <20061104152824.2322A101F00@lists.intevation.de> Message-ID: <20061105184455.5836636e.hamish_nospam@yahoo.com> > this bug's URL: http://intevation.de/rt/webrt?serial_num=5258 > --------------------------------------------------------------------- > > Subject: v.in.region does not create db table (in postgresql) .. > Generating a new vector (area) file with the current region extent by > the v.in.region command does not create automatically a corresponding > database table in PosgreSQL. This results in errors when trying to > rename the file or when using this vector file in certain overlay > procedures, such as v.patch and v.overlay, when table contents should > be inherited: > > v.patch -e input=paguirre2006base4,testarea output=testpatch > --overwrite GRASS_INFO_ERROR(28119,1): Missing table > > > Manually creating a database table in PostgreSQL, connecting it to the > vector file (v.db.connect) and updloading the cat values is a simple > workaround so far. v.in.region creates a vector box -- it has no attributes that need storing in a table. I can't comment on PosgreSQL or deriative needs. Hamish From hamish_nospam at yahoo.com Sun Nov 5 06:48:12 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Nov 5 06:48:17 2006 Subject: [GRASS-dev] GRASS at GForge first steps In-Reply-To: <454CAEEF.7020506@o2.pl> References: <454CAEEF.7020506@o2.pl> Message-ID: <20061105184812.4796fb6c.hamish_nospam@yahoo.com> Maciej Sieczka wrote: > > Issues tracker is for bugs, defects, wishes. I will take care of it in > terms of sorting out bugs which are doubtfull or lacking information. > I can also fix some minor stuff like docs, typos in the code, shell > scripts etc.. why not a separate tracker for bugs, wishes, docs, website, install probs... then people who want to work on fixing docs but not C code can quickly see that there are 3 open doc bugs they can work on, instead of spending a lot of time going through 56 open bugs of all types to find any doc ones. ?? if separate, can issues be moved between trackers (wish filed as a bug) how is a defect different than a bug? While we commision the new tracker(s), I would like to see the old bug tracker kept alive for some time, even if less used. > Talking of surveys I think this is a nice feature, perhaps more interesting than useful, but still good. Hamish From hamish_nospam at yahoo.com Sun Nov 5 06:51:12 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Nov 5 06:51:17 2006 Subject: [GRASS-dev] [bug #5259] (grass) reply to Hamish on Ticket 5254: enable v.what to report on more than one category In-Reply-To: <20061104154650.EA0CE101F01@lists.intevation.de> References: <20061104154650.EA0CE101F01@lists.intevation.de> Message-ID: <20061105185112.6c48c4df.hamish_nospam@yahoo.com> Request Tracker wrote: > > What I need to do with this data is to find count, max, min, mode, > median, average, std, etc. for a number of attributes for the stacked > sets of points, May I suggest using r.in.xyz on the point data with appropriately designed g.region settings. Hamish From landa.martin at gmail.com Sun Nov 5 10:23:31 2006 From: landa.martin at gmail.com (Martin Landa) Date: Sun Nov 5 10:23:33 2006 Subject: [GRASS-dev] do not get debug messages in 63-cvs In-Reply-To: <20061105162607.3ef9cea3.hamish_nospam@yahoo.com> References: <20061105162607.3ef9cea3.hamish_nospam@yahoo.com> Message-ID: Hi all, it seems that the problem is calling G_getl2() function [grass63] in lib/gis/env.c diff grass62-> grass63 --- env.c 2006-11-05 10:18:28.000000000 +0100 +++ /usr/src/gis/grass6-6.2/lib/gis/env.c 2006-02-09 04:08:56.000000000 +0100 @@ -111,7 +111,7 @@ if ((fd = open_env ("r", loc))) { - while (G_getl2 (buf, sizeof buf, fd)) + while (G_getl (buf, sizeof buf, fd)) { for (name = value = buf; *value; value++) if (*value == ':') [snip] G_getl2() call G_debug() before reading DEBUG value, in the result static variable grass_debug_level in lib/gis/debug.c is set to 0. Best, Martin 2006/11/5, Hamish : > Florian Kindl wrote: > > > > For some time the debug messages in grass63-cvs are no longer working > > for me. > > > > `g.gisenv set=DEBUG=5` seems to do its job as `g.gisenv DEBUG` returns > > "5" but no debug messages are printed when I call a module. > > > > I tried a `make distclean`, even a complete new install of the whole > > source tree, but the problem is still there. > > `./configure` and `make` run without errors... > > > > It works fine in grass6.2.0-RC3 on the same machine, configured and > > compiled the same way. > > > > Any ideas where the problem lies or what I did wrong? > > > I have the same trouble. I don't know why it happens. It works fine for > me in 6.2. > > > > > Hamish > > _______________________________________________ > 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 Florian.Kindl at uibk.ac.at Sun Nov 5 10:43:59 2006 From: Florian.Kindl at uibk.ac.at (Florian Kindl) Date: Sun Nov 5 10:44:03 2006 Subject: [GRASS-dev] do not get debug messages in 63-cvs In-Reply-To: References: <20061105162607.3ef9cea3.hamish_nospam@yahoo.com> Message-ID: On Sun, 5 Nov 2006, Martin Landa wrote: > Hi all, > > it seems that the problem is calling G_getl2() function [grass63] in > lib/gis/env.c > > [snip] > > G_getl2() call G_debug() before reading DEBUG value, in the result > static variable grass_debug_level in lib/gis/debug.c is set to 0. > Thank you, Martin! I don't know how to repair G_getl2() properly, but commenting out the G_debug() statement in lib/gis/getl.c (veeeery dirty, I know...) fixes it for the moment... thanks, -Flo. -- Florian Kindl Institute of Geography University of Innsbruck From tutey at o2.pl Sun Nov 5 10:57:50 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Sun Nov 5 10:57:53 2006 Subject: [GRASS-dev] GRASS at GForge first steps In-Reply-To: <20061105184812.4796fb6c.hamish_nospam@yahoo.com> References: <454CAEEF.7020506@o2.pl> <20061105184812.4796fb6c.hamish_nospam@yahoo.com> Message-ID: <454DB59E.1030600@o2.pl> Hamish wrote: > Maciej Sieczka wrote: >> Issues tracker is for bugs, defects, wishes. I will take care of it in >> terms of sorting out bugs which are doubtfull or lacking information. >> I can also fix some minor stuff like docs, typos in the code, shell >> scripts etc.. > why not a separate tracker for bugs, wishes, docs, website, install > probs... then people who want to work on fixing docs but not C code can > quickly see that there are 3 open doc bugs they can work on, instead of > spending a lot of time going through 56 open bugs of all types to find > any doc ones. Good point. I'll separate them. Maybe today. If not - next days. > ?? if separate, can issues be moved between trackers (wish filed as a > bug) Yes, they can. > how is a defect different than a bug? Call it "bad feature". I sometimes was told that I was reporting something as a bug while actually it was a feature. Although that feature was not good - eg. the current memory overhaed in GRASS vectors and dbf driver. Do you want a separate tracker for defects and bugs (I'd prefer them kept in one tracker, so that defects are as attended as bugs are). > While we commision the new tracker(s), I would like to see the old bug > tracker kept alive for some time, even if less used. This was already agreed on the dev list IIRC. Old GRASS RT is going to be used for the old bugs, since nobody seems to be able to transfer them to GForge. New bugs will be reported at GForge - not yet though, GRASS' GForge is still at development stage :) - give some more time. >> Talking of surveys > I think this is a nice feature, perhaps more interesting than useful, > but still good. Maciek From landa.martin at gmail.com Sun Nov 5 11:03:20 2006 From: landa.martin at gmail.com (Martin Landa) Date: Sun Nov 5 11:03:22 2006 Subject: [GRASS-dev] r.out.gdal segfault in XY location Message-ID: Hi, I just realize that r.out.gdal2 crashes with segmentation fault in XY (unprojected) location. If there is no objections I will fix it in CVS (see the patch). Best, Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * -------------- next part -------------- Index: main.c =================================================================== RCS file: /home/grass/grassrepository/grass6/raster/r.out.gdal/main.c,v retrieving revision 1.3 diff -u -r1.3 main.c --- main.c 4 Nov 2006 23:10:14 -0000 1.3 +++ main.c 5 Nov 2006 09:59:16 -0000 @@ -333,10 +333,14 @@ adfGeoTransform[3] = cellhead.north; adfGeoTransform[4] = 0.0; adfGeoTransform[5] = -1*cellhead.ns_res; - if ( GDALSetGeoTransform( hCurrDS, adfGeoTransform ) >=CE_Failure) G_warning(_("Couldn't set geo transform ...\n")); + if ( GDALSetGeoTransform( hCurrDS, adfGeoTransform ) >=CE_Failure) G_warning(_("Couldn't set geo transform.")); /* Set Projection */ - if ( GDALSetProjection( hCurrDS, srswkt ) >=CE_Failure) G_warning(_("Couldn't set projection ...\n")); + CPLErr ret; + if (srswkt) + ret = GDALSetProjection( hCurrDS, srswkt ); + if (!srswkt || ret == CE_Failure) + G_warning(_("Couldn't set projection.")); /* Add metadata */ AttachMetadata( hCurrDS, metaopt->answers ); From landa.martin at gmail.com Sun Nov 5 11:22:53 2006 From: landa.martin at gmail.com (Martin Landa) Date: Sun Nov 5 11:22:56 2006 Subject: [GRASS-dev] do not get debug messages in 63-cvs In-Reply-To: References: <20061105162607.3ef9cea3.hamish_nospam@yahoo.com> Message-ID: Hi Florian, I am also not sure, is this patch enough to fix it? Best, Martin 2006/11/5, Florian Kindl : > On Sun, 5 Nov 2006, Martin Landa wrote: > > > Hi all, > > > > it seems that the problem is calling G_getl2() function [grass63] in > > lib/gis/env.c > > > > [snip] > > > > G_getl2() call G_debug() before reading DEBUG value, in the result > > static variable grass_debug_level in lib/gis/debug.c is set to 0. > > > > Thank you, Martin! > > I don't know how to repair G_getl2() properly, but commenting out the > G_debug() statement in lib/gis/getl.c (veeeery dirty, I know...) fixes it > for the moment... > > thanks, > -Flo. > > > -- > Florian Kindl > Institute of Geography > University of Innsbruck > > > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * -------------- next part -------------- Index: lib/gis/getl.c =================================================================== RCS file: /home/grass/grassrepository/grass6/lib/gis/getl.c,v retrieving revision 2.4 diff -u -r2.4 getl.c --- lib/gis/getl.c 9 Feb 2006 03:08:56 -0000 2.4 +++ lib/gis/getl.c 5 Nov 2006 10:18:48 -0000 @@ -82,7 +82,8 @@ } buf[i] = '\0'; - G_debug ( 4, "G_getl2: ->%s<-", buf ); + if (G__getenv ("DEBUG")) + G_debug ( 4, "G_getl2: ->%s<-", buf ); return ret; } From landa.martin at gmail.com Sun Nov 5 11:36:29 2006 From: landa.martin at gmail.com (Martin Landa) Date: Sun Nov 5 11:36:31 2006 Subject: [GRASS-dev] Re: r.out.gdal segfault in XY location In-Reply-To: References: Message-ID: Hi all, BTW I have submitted the patch to Gforge [1] (just testing:-) Martin [1] http://wald.intevation.org/tracker/index.php?group_id=21&atid=183 PS: If I understand well -- patches should be submitted to Gforge in the future and not sent as the attachment to the grass-dev list, right? 2006/11/5, Martin Landa : > Hi, > > I just realize that r.out.gdal2 crashes with segmentation fault in XY > (unprojected) location. If there is no objections I will fix it in CVS > (see the patch). > > Best, Martin > > -- > Martin Landa * http://gama.fsv.cvut.cz/~landa * > > > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From tutey at o2.pl Sun Nov 5 11:46:38 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Sun Nov 5 11:46:43 2006 Subject: [GRASS-dev] Re: r.out.gdal segfault in XY location In-Reply-To: References: Message-ID: <454DC10E.8020004@o2.pl> Martin Landa wrote: > BTW I have submitted the patch to Gforge [1] (just testing:-) Oh, OK - ignore my email I sent you offlist just a while ago, then. > [1] http://wald.intevation.org/tracker/index.php?group_id=21&atid=183 > > PS: If I understand well -- patches should be submitted to Gforge in > the future and not sent as the attachment to the grass-dev list, > right? That's how I imagine this. Is that OK for devs? Maciek From grass-bugs at intevation.de Sun Nov 5 12:31:35 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Sun Nov 5 12:31:36 2006 Subject: [GRASS-dev] [bug #5258] (grass) v.patch: crash or ERROR, if tables missing in input Message-ID: <20061105113135.791AD1005C9@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5258 hamish_nospam@yahoo.com wrote (Sun, Nov 5 2006 06:45:09): > Guido Lorenz wrote: >> v.patch -e input=paguirre2006base4,testarea output=testpatch >> --overwrite GRASS_INFO_ERROR(28119,1): Missing table >> >> Manually creating a database table in PostgreSQL, connecting it to the >> vector file (v.db.connect) and updloading the cat values is a simple >> workaround so far. > v.in.region creates a vector box -- it has no attributes that need > storing in a table. The problem is with v.patch. It will not work if used with -e while any of the input vectors doesn't have a table. I'm renaming the bug. > I can't comment on PosgreSQL or deriative needs. This is not related to Postgres. With DBF it's the same. Moreover, v.patch segfaults if used with -e while *neither* input vector has a table. See the follwoing examples: in spearfish60: $ v.random out=pt1 n=10 $ v.random out=pt2 n=10 ### CASE 1: neither input vector has a table: $ v.patch input=pt1,pt2 out=ptp -e Segmentation fault (core dumped) $ gdb v.patch core (gdb) bt #0 0x0804a29f in main (argc=0, argv=0xbfcdf604) at main.c:193 (gdb) q ### CASE 2: only one input vector doesn't have a table: $ v.db.addtable pt1 columns="cat integer" $ v.patch input=pt1,pt2 out=ptp -e ERROR: Missing table ### CASE 3: both input vectors have a table: $ v.db.addtable pt2 columns="cat integer" $ v.patch input=pt1,pt2 out=ptp -e (works) Maciek -------------------------------------------- Managed by Request Tracker From tutey at o2.pl Sun Nov 5 13:00:05 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Sun Nov 5 13:00:14 2006 Subject: [GRASS-dev] GRASS at GForge first steps In-Reply-To: <454DB59E.1030600@o2.pl> References: <454CAEEF.7020506@o2.pl> <20061105184812.4796fb6c.hamish_nospam@yahoo.com> <454DB59E.1030600@o2.pl> Message-ID: <454DD245.1080405@o2.pl> Maciej Sieczka wrote: > Hamish wrote: >> Maciej Sieczka wrote: >>> Issues tracker is for bugs, defects, wishes. I will take care of it in >>> terms of sorting out bugs which are doubtfull or lacking information. >>> I can also fix some minor stuff like docs, typos in the code, shell >>> scripts etc.. > >> why not a separate tracker for bugs, wishes, docs, website, install >> probs... then people who want to work on fixing docs but not C code can >> quickly see that there are 3 open doc bugs they can work on, instead of >> spending a lot of time going through 56 open bugs of all types to find >> any doc ones. > > Good point. I'll separate them. Maybe today. If not - next days. Hamish, I forgot there is a "Build query" feature for each tracker. Every project member can create any number of queries suiting his needs. You can create a query for open bugs, docs, etc. Wouldn't that be good enough, instead of separate trackers? You can create a few testing tickets and see how it works for you (I have disabled forwarding GRASS project GForge traffic to the dev list until we have it working properly, so don't hesitate). Same for patches tracker. Maciek From paulk at ukshells.co.uk Wed Nov 1 23:54:09 2006 From: paulk at ukshells.co.uk (Paul D Kelly) Date: Sun Nov 5 20:41:07 2006 Subject: [GRASS-dev] Windows-style Pathnames In-Reply-To: <20061101215211.GA3922@localhost.tamu.edu> References: <17737.4290.419895.264288@cerise.gclements.plus.com> <20061101215211.GA3922@localhost.tamu.edu> Message-ID: On Wed, 1 Nov 2006, Glynn Clements wrote: > Windows isn't Unix. There will inevitably need to be some handling of > platform-specific behaviour. > > However, it's far better to create a set of functions to handle such > issues than to deal with individual files separately. Yes I agree with that; I think that's what I was trying to say but hadn't thought it through. E.g. a G_mkdir() to abstract the fact that Unix and Windows mkdir() require a different number of arguments, that kind of thing. On Wed, 1 Nov 2006, Huidae Cho wrote: > On Wed, Nov 01, 2006 at 09:25:22PM +0000, Glynn Clements wrote: >> >>> -#ifdef __MINGW32__ >>> - sprintf ( buf, "%s\\%s\\VAR", G_location_path(), G_mapset() ); >>> -#else >>> sprintf ( buf, "%s/%s/VAR", G_location_path(), G_mapset() ); >>> -#endif >> >> This is arguably correct, although possbily better formulated as e.g.: >> >> sprintf ( buf, "%s" DIRSEP "%s" DIRSEP "VAR", G_location_path(), G_mapset() ); >> or: >> sprintf ( buf, "%s%s%s%sVAR", G_location_path(), DIRSEP, G_mapset(), DIRSEP ); >> >> rather than using a platform test. >> >> However, using / should work as an argument to fopen(). The issue is >> more significant if paths are constructed and stored for later use >> (e.g. in $GISRC). In that situation, we need to decide whether to: >> >> 1. create and store the pathname in the host's syntax, or >> 2. store it in Unix syntax and convert it as required. > > The above code actually does #2 under the wrong assumption that GISDBASE > is in an MSys installation directory. When we are talking about host syntax or Unix syntax, do we mean only the difference between / and \ for directory separators in pathnames? I mean c:\grass\grassdata format is more correct, although as Glynn said c:/grass/grassdata works in a lot of circumstances and means very little in GRASS has to be changed (there are lots of C routines that form pathnames by concatenating strings with /). /c/grass/grassdata is Msys-specific and is specially interpreted by the Msys shell, right? I don't think there should be a need to use that format at all (except see Huidae's comment below). >> Either option will involve a lot of changes. #1 is easier to >> implement, but will probably need to be done in more places (it needs >> to be done for every pathname which might need to be in host syntax at >> some point). #2 is harder, but only needs to be performed in places >> where host syntax is known to be necessary. > > I found #2 a better choice becase MSys shell scripts will be happier > with posix path. Using the form c:/grass/grassdata rather than /c/grass/grassdata has proven OK for me so far (mostly in the configure script and bits of shell scripting done in the installation process and Makefiles). Were there many examples where this format was problematic? Paul From michael.barton at asu.edu Thu Nov 2 06:01:24 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sun Nov 5 20:41:08 2006 Subject: [GRASS-dev] Zooming issue in gis manager In-Reply-To: <17737.19609.232888.737802@cerise.gclements.plus.com> Message-ID: Glynn, This may not be the issue, but it does illustrate what you are talking about. I've shrunk the images quite a bit in the hopes they make it by the developer list filter. Both images are close-ups of Spearfish elevation_dem, with a 30m vector grid drawn over it (origin at 0,20 to make it align with the raster cells). G.region is run without the -a flag in both examples. "normal_mode.jpg" shows the map grid cells in the "normal" display mode that preserves resolution in the display region settings. Note the 30m resolution at the bottom of the display "explore_mode.jpg" shows the same part of the map in the "explore" mode that greatly increases resolution when zoomed in like this. Note the 0.7m resolution at the bottom of the of the display. The overlaid vector grid ought to line up with the cells. In explore mode it does line up, because the 30m "cells" of the original DEM are actually composed of >1800 cells in this close-up display. D.rast is aligning with the tiny new cells, not the original 30m cells, and this is not noticeable because the new cells are so small compared with the display and pixel size. In normal mode, the grid cells are indeed 30x30m and d.rast does whatever it does to squeeze an integer number of cells into the display. This is noticeable because the cells are large relative to the display. The vector grid does not line up with the cells. I have no idea how the GIS Manager displays could compensate for d.rast behavior like this, though it only is a problem when the cell size is very large compared to pixel size. Ideally, I guess it should always "snap" to the grid resolution when displaying rasters (vectors seem to be another matter). But I haven't the foggiest notion of how this could be done with continuously variable window sizing and zoom box sizing. I'm not even clear if this is better done when setting the display resolution somehow (but what happens if you set the display to match the WIND file or a map?), or if this should be done when coming up with output PPM geometry (but how do you make it fit a canvas then?). If someone wants to give it a try, more power to them. Fortunately, the explore mode approach works quite nicely to produce a display of zoomed in cells that is precisely rendered. If you want to set the computational region from the display, switch to normal mode first (I took out the -a switch today, so this is working fine in that the region gets set to what it appears to be in the display); then switch back to explore mode to look at it. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Glynn Clements > Date: Thu, 2 Nov 2006 01:40:41 +0000 > To: Maciej Sieczka > Cc: Michael Barton , grass-dev > > Subject: Re: [GRASS-dev] Zooming issue in gis manager > > > Maciej Sieczka wrote: > >>> I think that the core problem is that d.rast cannot render an >>> arbitrary portion of a map; the rendered image has to be aligned to >>> the cell boundaries. >> >> Thanks Glynn. Another question - so how does is happen that the X >> monitors don't have that problem, while gis.m displays do? > > X displays have exactly the same problem. gis.m might have some > *other* problems, but the d.rast/libdisplay issue I was discussing > applies regardless. > >> I mean: >> >> 1. When I set a region to match, say, 5 cols/6 rows (using g.region) >> and d.rast on X monitor - I see 5 cols/6 rows of a raster. >> >> 2. And when I use d.zoom and set the display on X monitor so that I >> see, say, 3 cols/7 rows, and I do g.region -p - I see that my region >> indeed has 3 cols/7 rows, and the resolution has not changed while zooming. >> >> But when gis.m interacts modifies WIND to match it's display, we have, >> either, only the resolution, or only the number or rows and cols set >> properly, depending on if the g.region is used with or without -a. > > I would guess that d.zoom adjusts the bounds manually, whereas gis.m > uses "g.region -a". The latter does more than just preserve the > resolution; it also aligns the grid with the coordinate system's > origin, then aligns the bounds with that grid, rounding outwards (i.e. > enlarging the region). > > Thus, "panning" (moving the region without changing the e-w or n-s > differences) with "g.region -a" will change the size of the region if > the requested bounds aren't aligned to the grid, as it will round > opposing edges in opposite directions. > >>> The region always has an integer number of rows and columns. d.rast >>> always ensures that the entire region just fits inside the frame; one >>> pair of edges will always exactly touch the corresponding edges of the >>> region. >> >>> Thus, the rendered image will only ever show whole cells. You will >>> never get a situation where part of a cell is shown and the other part >>> cropped. >> >> But I don't even want it. I'm saying that gis.m interaction with WIND >> must not corrupt the resolution or the number of rows and cols. If that >> is not possible, then we should not ask people to use gis.m yet. Or >> disable the WIND<->gis.m interaction alltogether. > > So, you're complaining about the fact that preserving the resolution > means moving the bounds outwards by up to 1 cell in each direction, > right? Or something else? > > If it's the former, gis.m will need to adjust the bounds itself; there > isn't any g.region option which will do the right thing (it's possible > that this was what -a was supposed to do; it would make more sense > than the existing behaviour). > > If it's the latter, you'll need to explain more clearly. > >>> At magnifications significantly above unity, this is likely to be >>> problematic for interactive zooming. You either have to adjust the >>> bounds so that they aligh with the existing cell grid, or adjust the >>> resolution so that the cell grid aligns with the bounds. >> >> So having both bounds and resolution preserved when gis.m interatcs >> with WIND is not possible, is that what you mean? > > The distance between opposing edges has to be an integer multiple of > the resolution (i.e. the number of rows and columns must be integers). > > But that should be true even within gis.m. It's possible that gis.m > fails to enforce this requirement, in which case, it will end up being > enforced whenever gis.m interfaces with the rest of GRASS, either by > adjusting the bounds to fit the resolution or by adjusting the > resolution to fit the bounds. > > That isn't limited to updating the WIND file; it will also affect > rendering. If gis.m is reporting region parameters which don't satisfy > the "integer multiple" requirement, it's lying; the numbers will get > "corrected" as soon as they leave gis.m. > > -- > Glynn Clements -------------- next part -------------- A non-text attachment was scrubbed... Name: normal_mode.jpg Type: application/octet-stream Size: 44412 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061101/94f6e0e8/normal_mode-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: explore_mode.jpg Type: application/octet-stream Size: 43062 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061101/94f6e0e8/explore_mode-0001.obj From russo at bogodyn.org Sun Nov 5 05:05:59 2006 From: russo at bogodyn.org (Tom Russo) Date: Sun Nov 5 20:41:09 2006 Subject: [GRASS-dev] Re: [GRASS-user] Compilation failure r.in.xyz on FreeBSD In-Reply-To: <20061105162350.21b2d979.hamish_nospam@yahoo.com> References: <20061104173442.GA4641@bogodyn.org> <20061105162350.21b2d979.hamish_nospam@yahoo.com> Message-ID: <20061105040559.GA63342@bogodyn.org> On Sun, Nov 05, 2006 at 04:23:50PM +1300, we recorded a bogon-computron collision of the flavor, containing: > Tom Russo wrote: > > I just tried to build today's CVS checkout, and got a compilation > > failure in r.in.xyz on my FreeBSD system. The problem is the last > > commit changed the type of the "filesize" variable to off_t, but on > > FreeBSD it is necessary to have an explicit include of > > to get the off_t typedef. > > > > Inserting a > > #include > > immediately before the include of fixed the problem. > > > ok, I guess that wasn't as safe as I thought it was. > > should the "#include " be included in or > placed by hand in each module that uses "off_t"? I dunno, I guess it'd be safe to include sys/types.h in config.h, but perhaps it would be better to probe for off_t in "configure", so that the include is really only pulled in on systems that require it? -- Tom Russo KM5VY SAR502 DM64ux http://www.swcp.com/~russo/ Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM "And, isn't sanity really just a one-trick pony anyway? I mean all you get is one trick, rational thinking, but when you're good and crazy, oooh, oooh, oooh, the sky is the limit!" --- The Tick From grass-patches at wald.intevation.org Sun Nov 5 11:31:20 2006 From: grass-patches at wald.intevation.org (grass-patches@wald.intevation.org) Date: Sun Nov 5 20:41:10 2006 Subject: [GRASS-dev] [grass-patches][220] r.out.gdal2 crashes with segfault in XY (unprojected) location Message-ID: <20061105103120.E267518017D4@pyrosoma.intevation.org> patches item #220, was opened at 2006-11-05 11:31 You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=183&aid=220&group_id=21 Or by replying to this e-mail entering your response between the following markers: #+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ (enter your response here) #+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ Status: Open Priority: 3 Submitted By: Martin Landa (martinl) Assigned to: Nobody (None) Summary: r.out.gdal2 crashes with segfault in XY (unprojected) location Patch status: None Patch type: software fix GRASS component: raster Initial Comment: ... ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=183&aid=220&group_id=21 From grass-patches at wald.intevation.org Sun Nov 5 11:38:49 2006 From: grass-patches at wald.intevation.org (grass-patches@wald.intevation.org) Date: Sun Nov 5 20:41:10 2006 Subject: [GRASS-dev] [grass-patches][220] r.out.gdal2 crashes with segfault in XY (unprojected) location Message-ID: <20061105103849.7E74E18017D4@pyrosoma.intevation.org> patches item #220, was opened at 2006-11-05 11:31 You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=183&aid=220&group_id=21 Or by replying to this e-mail entering your response between the following markers: #+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ (enter your response here) #+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ Status: Open Priority: 3 Submitted By: Martin Landa (martinl) Assigned to: Nobody (None) Summary: r.out.gdal2 crashes with segfault in XY (unprojected) location Patch status: None Patch type: software fix GRASS component: raster Initial Comment: ... ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=183&aid=220&group_id=21 From rez at touchofmadness.com Sun Nov 5 21:44:20 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Sun Nov 5 21:44:30 2006 Subject: [GRASS-dev] Re: [GRASS-user] Compilation failure r.in.xyz on FreeBSD In-Reply-To: <20061105040559.GA63342@bogodyn.org> References: <20061104173442.GA4641@bogodyn.org> <20061105162350.21b2d979.hamish_nospam@yahoo.com> <20061105040559.GA63342@bogodyn.org> Message-ID: <1162759460.32534.139.camel@devel> On Sat, 2006-11-04 at 21:05 -0700, Tom Russo wrote: > On Sun, Nov 05, 2006 at 04:23:50PM +1300, we recorded a bogon-computron collision of the flavor, containing: > > Tom Russo wrote: > > > I just tried to build today's CVS checkout, and got a compilation > > > failure in r.in.xyz on my FreeBSD system. The problem is the last > > > commit changed the type of the "filesize" variable to off_t, but on > > > FreeBSD it is necessary to have an explicit include of > > > to get the off_t typedef. > > > > > > Inserting a > > > #include > > > immediately before the include of fixed the problem. > > > > > > ok, I guess that wasn't as safe as I thought it was. > > > > should the "#include " be included in or > > placed by hand in each module that uses "off_t"? > > I dunno, I guess it'd be safe to include sys/types.h in config.h, but > perhaps it would be better to probe for off_t in "configure", so > that the include is really only pulled in on systems that require it? No. config.h is only used to define whether specific functions/features exist. Defining include files there is not appropriate. It enables us to conditionally define sections in source (eg.): #ifdef HAVE_SYS_TYPES_H #include #endif config.h is a result of the 'configure' script. There is no need to "probe" for off_t. It is part of the POSIX specification and I believe 'configure' has sufficient support to determine the size of off_t. All POSIX systems that want largefile support must use off_t and use the appropriate compile macros for that arch. 'int' and 'long' are not of sufficient length. -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From grass-bugs at intevation.de Mon Nov 6 00:10:26 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Mon Nov 6 00:10:27 2006 Subject: [GRASS-dev] [bug #5260] (grass) r.terraflow will not compile Message-ID: <20061105231026.188041005DB@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5260 ------------------------------------------------------------------------- Subject: r.terraflow will not compile Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: 6.2.0 & latest 6.3 CVS I could not compile r.terraflow in Fedora Core 6. Another user had similar error. See: http://grass.itc.it/pipermail/grass-dev/2006-October/026953.html I found thread where 5.7 apparently had same or similar problem. I was able to compile by removing on line 120 in replacementHeap.h and on line 122 in replacementHeapBlock.h I have not tested it but it does compile without errors after those changes. Regards, Floyd -------------------------------------------- Managed by Request Tracker From glynn at gclements.plus.com Mon Nov 6 00:44:01 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Nov 6 00:44:10 2006 Subject: [GRASS-dev] [bug #5257] (grass) Tcl install copy fails In-Reply-To: <20061104075610.436C4101EE3@lists.intevation.de> References: <20061104075610.436C4101EE3@lists.intevation.de> Message-ID: <17742.30529.369386.702500@cerise.gclements.plus.com> Request Tracker wrote: > this bug's URL: http://intevation.de/rt/webrt?serial_num=5257 > ------------------------------------------------------------------------- > > Subject: Tcl install copy fails > > Platform: Solaris2.x/Sparc > grass obtained from: Trento Italy site > grass binary for platform: Compiled from Sources > GRASS Version: 6.2.0 > > Tcl not copied during install Solaris 10 > > HACK FIX > > cp /usr/local/src/grass-6.2.0/lib/gtcltk/*.tcl /usr/local/grass-6.2.0/etc/gtcltk/ > cp /usr/local/src/grass-6.2.0/lib/external/bwidget/*.tcl /usr/local/grass-6.2.0/bwidget/ Fixed in CVS, similar to [bug #5255] -- Glynn Clements From rez at touchofmadness.com Mon Nov 6 01:27:43 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Mon Nov 6 01:27:48 2006 Subject: [GRASS-dev] OpenMotif Message-ID: <1162772863.32534.166.camel@devel> Hello, It has come to my attention that openmotif is not compatible with the GRASS license. Most of the functionality has been duplicated in lesstif, which has a compatible license. I've been able to successfully compile GRASS using lesstif as a drop-in replacement. Should we move GRASS to lesstif? All that really needs to be done is simply replace text that says openmotif/motif with lesstif (ie. cosmetics). Redhat has officially dropped support for openmotif and anything that won't compile without it as of Fedora Core 6. I assume other vendors will follow. -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From smitch at mac.com Mon Nov 6 04:04:56 2006 From: smitch at mac.com (Scott Mitchell) Date: Mon Nov 6 04:05:13 2006 Subject: [GRASS-dev] OpenMotif In-Reply-To: <1162772863.32534.166.camel@devel> References: <1162772863.32534.166.camel@devel> Message-ID: <25F970E1-BDFC-4081-B360-8332AE8BEC0C@mac.com> On 5 Nov 2006, at 19:27, Brad Douglas wrote: > Hello, > > It has come to my attention that openmotif is not compatible with the > GRASS license. Most of the functionality has been duplicated in > lesstif, which has a compatible license. > > I've been able to successfully compile GRASS using lesstif as a > drop-in > replacement. I've been compiling GRASS against lesstif for years on Linux and MacOSX, no troubles, although I have only actually used the xanim program once or twice. > > Should we move GRASS to lesstif? All that really needs to be done is > simply replace text that says openmotif/motif with lesstif (ie. > cosmetics). What text do you mean? REQUIREMENTS.html lists lesstif as the suggested dependency, and a google search for Motif and GRASS only finds mailing list discussions and pointers to packages... ah-ha, that's one place I guess, the rpm spec files... Debian is already using lesstif. Anything else that I'm missing? Scott Mitchell smitch@mac.com From rez at touchofmadness.com Mon Nov 6 04:30:21 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Mon Nov 6 04:30:27 2006 Subject: [GRASS-dev] OpenMotif In-Reply-To: <25F970E1-BDFC-4081-B360-8332AE8BEC0C@mac.com> References: <1162772863.32534.166.camel@devel> <25F970E1-BDFC-4081-B360-8332AE8BEC0C@mac.com> Message-ID: <1162783822.32534.221.camel@devel> On Sun, 2006-11-05 at 22:04 -0500, Scott Mitchell wrote: > On 5 Nov 2006, at 19:27, Brad Douglas wrote: > > > Hello, > > > > It has come to my attention that openmotif is not compatible with the > > GRASS license. Most of the functionality has been duplicated in > > lesstif, which has a compatible license. > > > > I've been able to successfully compile GRASS using lesstif as a > > drop-in > > replacement. > > I've been compiling GRASS against lesstif for years on Linux and > MacOSX, no troubles, although I have only actually used the xanim > program once or twice. I guess I'm a little slow, then. :-) I was not aware of lesstif until recently. I obviously missed it in REQUIREMENTS.html. Thank you for pointing that out. > > Should we move GRASS to lesstif? All that really needs to be done is > > simply replace text that says openmotif/motif with lesstif (ie. > > cosmetics). > > What text do you mean? REQUIREMENTS.html lists lesstif as the > suggested dependency, and a google search for Motif and GRASS only > finds mailing list discussions and pointers to packages... ah-ha, > that's one place I guess, the rpm spec files... Debian is already > using lesstif. Anything else that I'm missing? I'm talking about things like the 'configure' script. Change '--with-motif' to '--with-lesstif'. That kind of stuff. '--with-motif' implies openmotif, not lesstif. -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From hamish_nospam at yahoo.com Mon Nov 6 05:57:44 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Nov 6 06:13:23 2006 Subject: [GRASS-dev] Re: [GRASS-PSC] OpenMotif In-Reply-To: <1162772863.32534.166.camel@devel> References: <1162772863.32534.166.camel@devel> Message-ID: <20061106175744.12b0855b.hamish_nospam@yahoo.com> Brad Douglas wrote: > It has come to my attention that openmotif is not compatible with the > GRASS license. Most of the functionality has been duplicated in > lesstif, which has a compatible license. > > I've been able to successfully compile GRASS using lesstif as a > drop-in replacement. > > Should we move GRASS to lesstif? All that really needs to be done is > simply replace text that says openmotif/motif with lesstif (ie. > cosmetics). > > Redhat has officially dropped support for openmotif and anything that > won't compile without it as of Fedora Core 6. I assume other vendors > will follow. FWIW I've been running GRASS with lesstif (Debian) for years. REQUIREMENTS.html already points towards lesstif's version. Hamish From hamish_nospam at yahoo.com Mon Nov 6 06:26:03 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Nov 6 06:26:11 2006 Subject: [GRASS-dev] Re: r.out.gdal segfault in XY location In-Reply-To: <454DC10E.8020004@o2.pl> References: <454DC10E.8020004@o2.pl> Message-ID: <20061106182603.431cfd67.hamish_nospam@yahoo.com> Maciej Sieczka wrote: > > > PS: If I understand well -- patches should be submitted to Gforge in > > the future and not sent as the attachment to the grass-dev list, > > right? > > That's how I imagine this. Is that OK for devs? probaby depends on the size of the patch. For a few lines it's probably not worth the trouble of using the patch tracker. For larger patches and module submission it is more appropriate than sending 50kb emails to the entire list. Say, could a tracker hold Wiki Add-ons scripts & modules? I always worry that old scripts will be lost when people switch ISPs, jobs, graduate, etc. Hamish From grasschoper at rediffmail.com Mon Nov 6 06:37:08 2006 From: grasschoper at rediffmail.com (Nitin) Date: Mon Nov 6 06:40:34 2006 Subject: [GRASS-dev] what should be optimum hardware for GRASS? Message-ID: <20061106053708.22466.qmail@webmail105.rediffmail.com> i am looking for optimum hardware specification for running and developing GRASS. Main tool used will be nviz and network analysis tools and similar computation intensive work for ecology related tasks.can  anyone suggest me anything in this regard. grasschoper -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20061106/1221e613/attachment.html From landa.martin at gmail.com Mon Nov 6 07:05:36 2006 From: landa.martin at gmail.com (Martin Landa) Date: Mon Nov 6 07:05:38 2006 Subject: [GRASS-dev] do not get debug messages in 63-cvs In-Reply-To: References: <20061105162607.3ef9cea3.hamish_nospam@yahoo.com> Message-ID: Hi, 2006/11/5, Florian Kindl : > On Sun, 5 Nov 2006, Martin Landa wrote: > > > I am also not sure, is this patch enough to fix it? > > - G_debug ( 4, "G_getl2: ->%s<-", buf ); > > + if (G__getenv ("DEBUG")) > > + G_debug ( 4, "G_getl2: ->%s<-", buf ); > > > > here, it works ... yes, I meant -- when you do not set up DEBUG variable and call G_getl2() function no debug message (inside the function) will be printed. It is not nice solution. Cheers, Martin > -- > Florian Kindl > Institute of Geography > University of Innsbruck > > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From michael.barton at asu.edu Mon Nov 6 08:02:16 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Nov 6 08:02:30 2006 Subject: [GRASS-dev] How to change fonts in gis manager? Message-ID: Glynn, I?ve created a nice TclTk panel for d.text.new in the GIS Manager. It works fine. Now I?d like to be able to change the fonts it uses. Currently, it only seems to use romans. I?ve taken out the hard coded d.font romans from the gis.m display routine as it seems to be no longer needed with the new drivers. But still, when I run d.font (which requires an x.mon to run) and d.font.freetype, it has no effects on d.text.new. I want to embed font selection in the d.text.new panel but want to make sure it works and see what format of fonts definitions it will accept. Do you have any idea why changing the fonts doesn?t have any effects on d.text.new? Thanks Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20061106/1a876294/attachment.html From tutey at o2.pl Mon Nov 6 08:46:06 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Nov 6 08:46:09 2006 Subject: [GRASS-dev] Re: r.out.gdal segfault in XY location In-Reply-To: <20061106182603.431cfd67.hamish_nospam@yahoo.com> References: <454DC10E.8020004@o2.pl> <20061106182603.431cfd67.hamish_nospam@yahoo.com> Message-ID: <454EE83E.40706@o2.pl> Hamish wrote: > Maciej Sieczka wrote: >>> PS: If I understand well -- patches should be submitted to Gforge in >>> the future and not sent as the attachment to the grass-dev list, >>> right? >> That's how I imagine this. Is that OK for devs? > > > probaby depends on the size of the patch. For a few lines it's probably > not worth the trouble of using the patch tracker. For larger patches and > module submission it is more appropriate than sending 50kb emails to the > entire list. IMO, the main reason to use the tracker instead of sumbitting patches just to the dev list is to keep the track of them :). So that we can easilly access the patches that have been sent half a year ago, and were ignored then, but now they could be usefull. For this, I believe, any patch should be submitted by the user to the tracker, instead of the list directly (the message will be forwarded to the list from the tracker anyway). Once it is apllied (or used as a protype for another patch), it's ticket should be closed. > Say, could a tracker hold Wiki Add-ons scripts & modules? I always worry > that old scripts will be lost when people switch ISPs, jobs, graduate, > etc. We could have a separate tracker for this, or use the the GForge ftp space (there is such thing). Bernhard, What is file size limit and the overall quota, in the tracker and the ftp space? Better ideas? Maciek From landa.martin at gmail.com Mon Nov 6 10:26:52 2006 From: landa.martin at gmail.com (Martin Landa) Date: Mon Nov 6 10:26:54 2006 Subject: [GRASS-dev] Re: r.out.gdal segfault in XY location In-Reply-To: References: Message-ID: Hi, 2006/11/5, Martin Landa : > I just realize that r.out.gdal2 crashes with segmentation fault in XY > (unprojected) location. If there is no objections I will fix it in CVS > (see the patch). fixed in CVS. Best, Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From landa.martin at gmail.com Mon Nov 6 11:09:10 2006 From: landa.martin at gmail.com (Martin Landa) Date: Mon Nov 6 11:09:13 2006 Subject: [GRASS-dev] collecting grass (future) concepts In-Reply-To: <20061031190919.GB22016@bartok.itc.it> References: <20061031190919.GB22016@bartok.itc.it> Message-ID: Hi all, sorry for the late response. First of all, thanks for your opinions. The main reason why I suggested to create a new specialized mailing list -- it is very difficult to find topic-orientated (e.g. concepts, etc.) messages in grass-dev. On the other hand the better medium for collecting ideas is the wiki. BTW, there is lot of GRASS mailing list with (very) low traffic. Maybe we should open discussion to decrease this number. Just idea;-) Cheers, Martin 2006/10/31, Markus Neteler : > Hi, > > please let's keep the discussion here on grass-dev. > We have already too many mailing lists to follow. > > Markus > > On Tue, Oct 31, 2006 at 07:53:42AM -0700, Michael Barton wrote: > > Martin, > > > > This would be useful. There is already a GRASS-GUI list if you want to use > > that. > > > > Michael > > __________________________________________ > > Michael Barton, Professor of Anthropology > > School of Human Evolution & Social Change > > Center for Social Dynamics & Complexity > > Arizona State University > > > > phone: 480-965-6213 > > fax: 480-965-7671 > > www: http://www.public.asu.edu/~cmbarton > > > > > > > > > From: Martin Landa > > > Date: Tue, 31 Oct 2006 12:14:57 +0100 > > > To: grass-dev > > > Subject: [GRASS-dev] collecting grass (future) concepts > > > > > > Hi all, > > > > > > from my personal point of view (as a relatively new/young GRASS > > > "power" user) I suggest to create a new GRASS mailing list (e.g. > > > grass-concepts, or grass-future, etc.), where developers and users > > > could discuss the new/modified GIS concepts for future version of > > > GRASS. E.g. idea concept like object-orientated and layer-orientated > > > data approach, full 2D-2.5D-3D-4D GIS implementation, and in the > > > future more technical issues (working on the new core libraries, core > > > programming language issue, etc.). > > > > > > I hope that this mailing list (and of course GRASS-Wiki) might help to > > > collect and crystallize ideas about GRASS future. In any case GRASS > > > should build on the current versions and continue in "GRASS way of > > > thinking". > > > > > > Would do you think? > > > > > > Best regards, Martin > > > > > > -- > > > Martin Landa * http://gama.fsv.cvut.cz/~landa * > > > > > > > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev > > -- > Markus Neteler http://mpa.itc.it/markus/ > ITC-irst - Centro per la Ricerca Scientifica e Tecnologica > MPBA - Predictive Models for Biol. & Environ. Data Analysis > Via Sommarive, 18 - 38050 Povo (Trento), Italy > > _______________________________________________ > 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 glynn at gclements.plus.com Mon Nov 6 15:22:29 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Nov 6 15:22:32 2006 Subject: [GRASS-dev] OpenMotif In-Reply-To: <1162783822.32534.221.camel@devel> References: <1162772863.32534.166.camel@devel> <25F970E1-BDFC-4081-B360-8332AE8BEC0C@mac.com> <1162783822.32534.221.camel@devel> Message-ID: <17743.17701.193923.549815@cerise.gclements.plus.com> Brad Douglas wrote: > It has come to my attention that openmotif is not compatible with the > GRASS license. That's debatable. Ironically, commercially-licenced versions of Motif are potentially less of a problem, as the GPL provides an exception for "major components ... of the operating system". On commercial Unices, Motif is frequently part of the OS. So, the issue primarily relates to OpenMotif (which is just a copy of Motif distributed under the Open Group Public Licence; at a technical level, OpenMotif is the same product as a commercial version of Motif). Even there, it's only an issue insofar as Motif isn't considered "standard" on platforms for which the OpenMotif licence applies. > > > Should we move GRASS to lesstif? All that really needs to be done is > > > simply replace text that says openmotif/motif with lesstif (ie. > > > cosmetics). > > > > What text do you mean? REQUIREMENTS.html lists lesstif as the > > suggested dependency, and a google search for Motif and GRASS only > > finds mailing list discussions and pointers to packages... ah-ha, > > that's one place I guess, the rpm spec files... Debian is already > > using lesstif. Anything else that I'm missing? > > I'm talking about things like the 'configure' script. Change > '--with-motif' to '--with-lesstif'. That kind of stuff. '--with-motif' > implies openmotif, not lesstif. No, it implies something compatible with IEEE 1295, i.e. Motif (whether OpenMotif or a commercial version), or a clone thereof. BTW, a version linked against OpenMotif (or even a commercial version) should work with LessTif and vice-versa, although you might need to add a symlink to cater for different major version numbers. -- Glynn Clements From bernhard at intevation.de Mon Nov 6 15:23:31 2006 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon Nov 6 15:23:39 2006 Subject: [GRASS-dev] GRASS at GForge first steps In-Reply-To: <454CAEEF.7020506@o2.pl> References: <454CAEEF.7020506@o2.pl> Message-ID: <200611061523.35572.bernhard@intevation.de> On Saturday 04 November 2006 16:17, Maciej Sieczka wrote: > Trackers are available for public view, but in order to be able to > post (including creating a new report), you must setup your account at > GForge first [3]. This is to avoid http spam. All the trackers' posts > are automatically forwarded to grass-dev list currently. > > If you want to be able to modify the contents of Trackers, you should > request to join the GRASS project at GForge as developer [5]. I think it might be useful to keep the ability for people that are not registered with the wald GRASS project to submit bugs and also manupliate their owns. (I currently do not know how to model this on wald, but this is stating the goal.) > 1. Admin is in charge of accepting requests to join the project and > configuring the GRASS project at GForge. Currently I'm the only admin. > We need 2 (3?), in case I'm not available. Candidates? I am willing to help out as backup. Our system administrators at Intevation of course also have higher powers over wald, for emergencies. > Talking of surveys > The possible problem I see is that only admin can access > the survey results :(, and there is no way to change this (CCing > Bernhard if he has an idea). Not directly out of the top of my head. You can file this as a wish with wald. Bernhard -- Managing Director - Owner, www.intevation.net (Free Software Company) Germany Coordinator, fsfeurope.org (Non-Profit Org for Free Software) www.kolab-konsortium.com (Email/Groupware Solution, Professional Service) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061106/80555b8b/attachment.bin From bernhard at intevation.de Mon Nov 6 15:27:51 2006 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon Nov 6 15:28:17 2006 Subject: [GRASS-dev] GRASS at GForge first steps In-Reply-To: <454DB59E.1030600@o2.pl> References: <454CAEEF.7020506@o2.pl> <20061105184812.4796fb6c.hamish_nospam@yahoo.com> <454DB59E.1030600@o2.pl> Message-ID: <200611061527.52734.bernhard@intevation.de> On Sunday 05 November 2006 10:57, Maciej Sieczka wrote: > > how is a defect different than a bug? > > Call it "bad feature". I sometimes was told that I was reporting > something as a bug while actually it was a feature. Although that > feature was not good - eg. the current memory overhaed in GRASS vectors > and dbf driver. Do you want a separate tracker for defects and bugs > (I'd prefer them kept in one tracker, so that defects are as attended > as bugs are). I think a bug is also too general as a term. Zeller 2006 explains this and uses "defect". See http://www.whyprogramsfail.com/ > > While we commision the new tracker(s), I would like to see the old bug > > tracker kept alive for some time, even if less used. > > This was already agreed on the dev list IIRC. Old GRASS RT is going to > be used for the old bugs, since nobody seems to be able to transfer > them to GForge. It is a matter of effort and time, but not technically impossible. :) > New bugs will be reported at GForge - not yet though, > GRASS' GForge is still at development stage :) - give some more time. -- Managing Director - Owner, www.intevation.net (Free Software Company) Germany Coordinator, fsfeurope.org (Non-Profit Org for Free Software) www.kolab-konsortium.com (Email/Groupware Solution, Professional Service) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061106/ff20f5e7/attachment-0001.bin From glynn at gclements.plus.com Mon Nov 6 15:40:34 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Nov 6 15:43:07 2006 Subject: [GRASS-dev] How to change fonts in gis manager? In-Reply-To: References: Message-ID: <17743.18786.799533.511272@cerise.gclements.plus.com> Michael Barton wrote: > I?ve created a nice TclTk panel for d.text.new in the GIS Manager. It works > fine. Now I?d like to be able to change the fonts it uses. Currently, it > only seems to use romans. > > I?ve taken out the hard coded d.font romans from the gis.m display routine > as it seems to be no longer needed with the new drivers. > > But still, when I run d.font (which requires an x.mon to run) and > d.font.freetype, it has no effects on d.text.new. I want to embed font > selection in the d.text.new panel but want to make sure it works and see > what format of fonts definitions it will accept. > > Do you have any idea why changing the fonts doesn?t have any effects on > d.text.new? d.font and d.font.freetype don't work with direct rendering, as there is no monitor process to retain state between d.* commands; each d.* command runs as if with a freshly-started monitor. Similarly, d.frame and d.save don't work, for the same reason. To set the default font for direct rendering, you have to use the environment variables: GRASS_FT_FONT GRASS_FT_ENCODING GRASS_FONT Note that GRASS_FONT accepts either FreeType or stroke fonts, while GRASS_FT_FONT only accepts FreeType fonts. If both are set, GRASS_FT_FONT takes precedence over GRASS_FONT. If neither are set, "romans" is used. For GRASS_FONT, the value is passed directly to R_font(), and should be one of: 1. The full path to a stroke font, beginning with $GISBASE/fonts. 2. The full path to a FreeType font (.ttf file). 3. The name of a FreeType font from the freetypecap file. 4. The name of a stroke font in the $GISBASE/fonts directory. If the value begins with a "/", it's a full path. If it begins with (the expansion of) $GISBASE/fonts, it's assumed to be a stroke font, otherwise a freetype font. If the value doesn't begin with a "/", it's first searched for in the freetypecap file; if it isn't found, it's assumed to be the name of a stroke font. -- Glynn Clements From michael.barton at asu.edu Mon Nov 6 16:10:29 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Nov 6 16:11:12 2006 Subject: [GRASS-dev] How to change fonts in gis manager? In-Reply-To: <17743.18786.799533.511272@cerise.gclements.plus.com> Message-ID: Glynn, Thanks. I can do something to implement these. I have a related question. TclTk (and wxPython) have built-in utilities to allow the user to select a "system" font of some kind (e.g., {timeroman 12 bold}). Is there any way that GRASS can recognize these? Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Glynn Clements > Date: Mon, 6 Nov 2006 14:40:34 +0000 > To: Michael Barton > Cc: grass-dev > Subject: Re: [GRASS-dev] How to change fonts in gis manager? > > For GRASS_FONT, the value is passed directly to R_font(), and should > be one of: > > 1. The full path to a stroke font, beginning with $GISBASE/fonts. > 2. The full path to a FreeType font (.ttf file). > 3. The name of a FreeType font from the freetypecap file. > 4. The name of a stroke font in the $GISBASE/fonts directory. From bernhard at intevation.de Mon Nov 6 16:12:52 2006 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon Nov 6 16:13:00 2006 Subject: wald, space (Re: [GRASS-dev] Re: r.out.gdal segfault in XY location) In-Reply-To: <454EE83E.40706@o2.pl> References: <20061106182603.431cfd67.hamish_nospam@yahoo.com> <454EE83E.40706@o2.pl> Message-ID: <200611061612.56868.bernhard@intevation.de> On Monday 06 November 2006 08:46, Maciej Sieczka wrote: > Hamish wrote: > > Maciej Sieczka wrote: > >>> PS: If I understand well -- patches should be submitted to Gforge in > >>> the future and not sent as the attachment to the grass-dev list, > >>> right? > >> > >> That's how I imagine this. Is that OK for devs? > > > > probaby depends on the size of the patch. For a few lines it's probably > > not worth the trouble of using the patch tracker. For larger patches and > > module submission it is more appropriate than sending 50kb emails to the > > entire list. > > IMO, the main reason to use the tracker instead of sumbitting patches > just to the dev list is to keep the track of them :). So that we can > easilly access the patches that have been sent half a year ago, and > were ignored then, but now they could be usefull. For this, I believe, > any patch should be submitted by the user to the tracker, instead of > the list directly (the message will be forwarded to the list from the > tracker anyway). Once it is apllied (or used as a protype for another > patch), it's ticket should be closed. I think it is good to track patches, even small ones. Still there are situations where I would want to mail a patch to the list. Especially when I am in a process of changing or discussing a change or I know I will commit this tomorrow anyway. Otherwise, at the end of a working session, it is good to publish something and a tracker can help a lot to create a mini-discussion place for a specific change. > > Say, could a tracker hold Wiki Add-ons scripts & modules? I always worry > > that old scripts will be lost when people switch ISPs, jobs, graduate, > > etc. > > We could have a separate tracker for this, or use the the GForge ftp > space (there is such thing). > > Bernhard, > > What is file size limit and the overall quota, in the tracker and the > ftp space? Better ideas? There is no specific quota (yet) as disc space is reasonable cheap (though backspace is not). We might introduce a quota in the future. I am not quite sure that I know what "Wiki Add-ons scripts & modules" precisly are, but if this is useful for GRASS to track and reaonably seperate from other things. By all means: Track it. :) You can use the documentation space or another svn module if a tracker is not appropriate, so there are enough possibility to model a solution. Bernhard -- Managing Director - Owner, www.intevation.net (Free Software Company) Germany Coordinator, fsfeurope.org (Non-Profit Org for Free Software) www.kolab-konsortium.com (Email/Groupware Solution, Professional Service) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061106/62ca2e3a/attachment.bin From neteler.osgeo at gmail.com Mon Nov 6 16:41:23 2006 From: neteler.osgeo at gmail.com (Markus Neteler) Date: Mon Nov 6 16:41:34 2006 Subject: [GRASS-dev] Re: [GRASS-PSC] adding r.li to GRASS In-Reply-To: References: <86782b610611060700w5dc4f759mf896e603ffa1d66f@mail.gmail.com> Message-ID: <86782b610611060741w10181babjb0ddc53e45813fa1@mail.gmail.com> Let me suggest to move these technical questions back to the dev list (I should have done so, too, sorry). Markus On 11/6/06, Michael Barton wrote: > Once this is all done, we need to decide if it should replace r.le in the > menu, and if so what are the specific modules that need to be run. Also, > does this **require** an interactive xterm like parts of r.le? > > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > > > From: Markus Neteler > > Date: Mon, 6 Nov 2006 16:00:51 +0100 > > To: Paolo Cavallini > > Cc: , Serena Pallecchi > > Subject: Re: [GRASS-PSC] adding r.li to GRASS > > > > Paolo, Serena, > > > > I have now submitted your latest version to CVS in > > raster/r.li/ to simplify the further development. > > > > A few remaining things should be done soon: > > - add relevant references > > - change AUTHORS as indicated by you (offlist, see below) > > - fix static local r.li.daemon library "libr_li.a" to dynamic > > (see raster/simwe/simlib/ how to do that) > > - fix "clean" target in r.li.daemon (ipc binary and library) > > > > So far I didn't add r.li yet to raster/Makefile . > > > > We should also discuss CVS write access for the future r.li > > development. > > > > Thanks again for the r.li development > > and congrats! > > > > Markus From jachym.cepicky at centrum.cz Mon Nov 6 19:04:30 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Mon Nov 6 19:04:31 2006 Subject: [GRASS-dev] GRASS at GForge first steps In-Reply-To: <454CAEEF.7020506@o2.pl> References: <454CAEEF.7020506@o2.pl> Message-ID: <20061106180429.GA3346@localdomain> Hallo, great work, Maciek. One question from my side: On Sat, Nov 04, 2006 at 04:17:03PM +0100, Maciej Sieczka wrote: > Patches tracker is for storing and managing the patches candidates > (both code and docs). Currently, they are often sent to dev list. If > they are not reacted upon quickly, or too intrusive to be applied right > away but valuable for future developmement, they happen to be > forgotten. The tracker might help us to manage them in a convenient > way. Jachym volunteered to maintain the code patches submitted. Thanks > Jachym! Is there somebody willing to take care of docs submitted? I will do it (try to do it). What exactly am I supposed to do? My imaginatio is following: - Someone will submit some patch to wald - I (or someone else) will examine the patch, look if it does what it is supposed to do and paste my comment about this patch to grass-dev list - If it will be only small correction, I'll apply the patch to CVS immediately - If it will be bigger change and nobody will complain in grass-dev within a week or so, I'll commit the change too. Anything else? Or do I understand this task completely wrong? Thanks Jachym -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc ----------------------------------------- OFFICE: Department of Geoinformation Technologies Zemedelska 3 613 00, Brno Czech Republick e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz Tel.: +420 545 134 514 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061106/7676abb7/attachment.bin From neteler at itc.it Mon Nov 6 21:06:46 2006 From: neteler at itc.it (Markus Neteler) Date: Mon Nov 6 21:06:48 2006 Subject: [GRASS-dev] collecting grass (future) concepts In-Reply-To: References: <20061031190919.GB22016@bartok.itc.it> Message-ID: <20061106200646.GA30068@bartok.itc.it> Hi, here my candidates for merge/removal: grassgui GRASSGUI mailing list nvizlist List to discuss GRASS/NVIZ visualization tools sqlgrass GRASS and SQL support If you look at http://grass.itc.it/pipermail/nvizlist/ http://grass.itc.it/pipermail/grassgui/ http://grass.itc.it/pipermail/sqlgrass/ you can see that they are basically unused. As a first attempt we could simply remove them from http://grass.itc.it/community/support.php to not mislead people (who do not receive answers there). Then I could close them for further subscription but leave the archives alive. Markus On Mon, Nov 06, 2006 at 11:09:10AM +0100, Martin Landa wrote: > Hi all, > > sorry for the late response. > > First of all, thanks for your opinions. > > The main reason why I suggested to create a new specialized mailing > list -- it is very difficult to find topic-orientated (e.g. concepts, > etc.) messages in grass-dev. On the other hand the better medium for > collecting ideas is the wiki. > > BTW, there is lot of GRASS mailing list with (very) low traffic. Maybe > we should open discussion to decrease this number. Just idea;-) > > Cheers, Martin > > 2006/10/31, Markus Neteler : > >Hi, > > > >please let's keep the discussion here on grass-dev. > >We have already too many mailing lists to follow. > > > >Markus From paul-grass at stjohnspoint.co.uk Mon Nov 6 22:12:36 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Nov 6 22:12:39 2006 Subject: [GRASS-dev] Improved ellipsoid name support Message-ID: Yesterday I committed to CVS some updates to the gproj library that I'd had sitting around for ages. They do the following things: 1. When generating a WKT projection description, put the full ellipsoid name from ellipse.table in the "SPHEROID" section. The short name stil goes in the "GEOGCS" section. 2. When generating a GRASS PROJ_INFO file from an input projection description, try to put the ellipsoid name into the PROJ_INFO where possible, instead of just a and es parameters. People had complained about this before. The new functionality works as follows: a) If a datum name is specified, use the ellipsoid associated with that datum (i.e. ignore the ellipsoid parameters) b) If there is no datum specified, try and match the ellipsoid parameters against the known ellipsoids in ellipse.table (within a specified tolerance - see the code in lib/proj/convert.c around line 521; comments welcome) and use the first one that matches c) Only if a) and b) both fail, put the a and es parameters into PROJ_INFO directly as present These changes should make the PROJ_INFO files generated by g.proj (and r.in.gdal, v.in.ogr) more like those generated by g.setproj and should hopefully make it more viable to use these functions as some kind of total replacement for g.setproj in the future (at present I'm not sure how!). Paul From paul-grass at stjohnspoint.co.uk Mon Nov 6 23:09:30 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Nov 6 23:09:33 2006 Subject: [GRASS-dev] Quick gis.m test on Windows Message-ID: Just tried it and it seems to have a few problems with Msys-based assumptions: I eventually found it works OK if I start it from the Msys terminal but we should in theory be able to get everything except scripts working without Msys. Anyway I'm not great at debugging Tcl but when first starting up I got this error: couldn't write file "/dev/null": no such file or directory couldn't write file "/dev/null": no such file or directory while executing "exec -- d.font romans >& /dev/null" ("eval" body line 1) invoked from within "eval [list exec -- $cmd] $args >& $devnull" (procedure "run" line 12) invoked from within "run d.font romans" ("eval" body line 1) invoked from within "eval run $cmd $args" (procedure "runcmd" line 6) invoked from within "runcmd "d.font romans"" (procedure "MapCanvas::runprograms" line 63) invoked from within "MapCanvas::runprograms $mon [expr {$mymodified != 0}]" (procedure "MapCanvas::drawmap" line 38) invoked from within "MapCanvas::drawmap $mon" (procedure "MapCanvas::display_server" line 9) invoked from within "MapCanvas::display_server" ("after" script) Found a place in gm.tcl that seemed to be setting an mingw variable to true if Msys was detected - I changed that to be unconditional and got a bit further to the following error when trying to display a map: can't read "_data(.gronsole.gronsole,2,donecmd)": no such element in array can't read "_data(.gronsole.gronsole,2,donecmd)": no such element in array while executing "set donecmd $_data($path,$ci,donecmd)" (procedure "Gronsole::done_command" line 3) invoked from within "Gronsole::done_command $path $ci" (procedure "Gronsole::execout" line 26) invoked from within "Gronsole::execout $path $cmd $ci Gronsole::execwait" (procedure "Gronsole::run_wait" line 6) invoked from within "Gronsole::run_wait .gronsole.gronsole {d.rast map=geology@PERMANENT -o} gism" ("eval" body line 1) invoked from within "eval Gronsole::$cmd .gronsole.gronsole $args" (procedure ".gronsole.gronsole" line 1) invoked from within "$gronsole run_wait $cmd gism" (procedure "run_panel" line 4) invoked from within "run_panel $cmd" (procedure "GmCommonLayer::display_commands" line 33) invoked from within "GmCommonLayer::display_commands $namespace $id [list $cmd]" (procedure "GmCommonLayer::display_command" line 2) invoked from within "GmCommonLayer::display_command [namespace current] $id $cmd" (procedure "GmRaster::display" line 63) invoked from within "GmRaster::display $node $mod" ("raster" arm line 2) invoked from within "switch $type { group { GmGroup::display $node $mod } raster { GmRaster::display $node $mod } labels { GmLabels::disp..." (procedure "GmTree::display_node" line 7) invoked from within "GmTree::display_node $n $mod" (procedure "GmGroup::display" line 22) invoked from within "GmGroup::display "root" $mod" (procedure "MapCanvas::runprograms" line 63) invoked from within "MapCanvas::runprograms $mon [expr {$mymodified != 0}]" (procedure "MapCanvas::drawmap" line 38) invoked from within "MapCanvas::drawmap $mon" (procedure "MapCanvas::display_server" line 9) invoked from within "MapCanvas::display_server" ("after" script) Hope it's helpful for debugging. Paul From paul-grass at stjohnspoint.co.uk Mon Nov 6 23:34:36 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Nov 6 23:34:37 2006 Subject: [GRASS-dev] Windows-style Pathnames In-Reply-To: <17738.42338.869940.724212@cerise.gclements.plus.com> References: <17737.4290.419895.264288@cerise.gclements.plus.com> <20061101215211.GA3922@localhost.tamu.edu> <17737.21068.670434.23541@cerise.gclements.plus.com> <17738.42338.869940.724212@cerise.gclements.plus.com> Message-ID: On Fri, 3 Nov 2006, Glynn Clements wrote: > > Paul Kelly wrote: > >>> Note that the backslash is a shell metacharacter, so it will have to >>> be protected from interpretation if it appears directly in a script or >>> user input. >> >> For that reason alone, perhaps easiest to use c:/grass/grassdata format as >> much as possible, at least as an interim measure? > > Maybe. We'll need to convert it for e.g. system(). Yes. The way I've done that in the is first to pass the string containing the path to G_convert_dirseps_to_host(), which will replace all occurences of / by \, and then quote the path name with \"escaped double quotes\" within the argument supplied to system() - I think this should cover both eventualities of the pathname containing spaces, *and* the backslashes possibly being misinterpreted by a shell. Although as we've seen it should normally by cmd.exe invoked for this. >> OK but whether we use c:/ or c:\ we still have the same problem with >> setting the PATH in scripts Huidae was talking about. But it remains to be >> seen how big a problem it is I guess. > > Most scripts don't set PATH. Yes I think the only example I've seen is the HTML documentation generation thing in the Makefiles and that is easily handled as it's done within Msys and using Msys-style paths anyway. > For a native Windows version, I would be strongly in favour of > replacing init.sh with a Windows command file. Actually, if users only > need to use gis.m, it should be possible to start it as a GUI > application without cmd.exe, bash or a console ever getting involved. Yes I agree. But a batch/command file that sets the appropriate environment variables and prompt to run command-line GRASS from a cmd.exe shell would also be a nice touch to include, especially if we get display drivers working. >> And it should be possible for a user to run the scripts if >> necessary using another shell, not necessarily the Msys one? Perhaps >> determined by a GRASS_SH environment variable. > > Currently, a lot of GRASS assumes that scripts can be treated as > executables, as they are on Unix. I.e. you can call system("foo") and > it doesn't matter whether foo is a compiled executable or a script. > > You can do this on Windows, but the file needs to have an extension to > indicate how it is run (Unix detects this from the file's header, e.g. > #! for scripts). The PATHEXT environment variable contains a > semicolon-separated list of extensions which are treated as indicating > an executable. On my system, it is set to: > > PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH > > If you execute a "command" without a directory or extension, Windows > will consider files with any of those extensions when trying to > resolve the command name to an executable, effectively doing: > > for dir in $PATH ; do > for ext in $PATHEXT ; do > if [ -f $dir/$cmd$ext] ; then > exec $dir/$cmd$ext > fi > done > done > > AFAICT, the "interpreter" is selected according the registry entry > corresponding to the extension, the same as if you had double-clicked > on the file's icon from an Explorer window. > > So, if we were to add ".sh" extensions to all of the scripts, and add > ".sh" to PATHEXT, calling e.g. system("r.out.gdal ...") should run > r.out.gdal.sh using the program associated with ".sh" in the registry. That sounds like a fairly handy way of doing it. Does the installing user need to be an administator on the Windows machine to change the registry to do this file extension association? Or the other way that was discussed before was some kind of launcher executable program. I was thinking that it could even be installed instead of all the scripts like "front.end" used to be, and it would check the contents of the real scripts and start them with the shell specified in a GRASS_SH environment variable. But that might be a bit complicated and prone to going wrong whereas the first approach would be more understandable for experienced Windows users. From hamish_nospam at yahoo.com Tue Nov 7 04:16:17 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Nov 7 04:38:48 2006 Subject: wald, space (Re: [GRASS-dev] Re: r.out.gdal segfault in XY location) In-Reply-To: <200611061612.56868.bernhard@intevation.de> References: <20061106182603.431cfd67.hamish_nospam@yahoo.com> <454EE83E.40706@o2.pl> <200611061612.56868.bernhard@intevation.de> Message-ID: <20061107161617.4192fae0.hamish_nospam@yahoo.com> HB: > > > Say, could a tracker hold Wiki Add-ons scripts & modules? I always > > > worry that old scripts will be lost when people switch ISPs, jobs, > > > graduate, etc. MS: > > We could have a separate tracker for this, or use the the GForge ftp > > space (there is such thing). > > > > What is file size limit and the overall quota, in the tracker and > > the ftp space? Better ideas? BR: > There is no specific quota (yet) as disc space is reasonable cheap > (though backspace is not). We might introduce a quota in the future. usual FTP policy is anonomous upload to an incoming/ dir is allowed, but the contents of that dir is only viewable by the site admin who then moves the file to the public dir. incoming/ should be in its own partition or be subject lots of space checks to avoid a general denial of service attack. there used to be such a ftp upload space @itc, don't know if that is still active. I don't think anyone has needed to use it in a long while. > I am not quite sure that I know what "Wiki Add-ons scripts & modules" > precisly are, but if this is useful for GRASS to track and reaonably > seperate from other things. By all means: Track it. :) user contributions: http://grass.gdf-hannover.de/wiki/GRASS_AddOns > You can use the documentation space or another svn module if > a tracker is not appropriate, so there are enough possibility to model > a solution. thanks, Hamish From hamish_nospam at yahoo.com Tue Nov 7 04:25:04 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Nov 7 04:42:39 2006 Subject: [GRASS-dev] How to change fonts in gis manager? In-Reply-To: References: Message-ID: <20061107162504.6618f093.hamish_nospam@yahoo.com> Michael Barton wrote: > > I?ve created a nice TclTk panel for d.text.new in the GIS Manager. we should probably pick a better name than "d.text.new", it tells you nothing about what the module does vs other d.text modules and will become an anachronism before very long. thanks, Hamish From michael.barton at asu.edu Tue Nov 7 04:52:31 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Nov 7 04:52:48 2006 Subject: [GRASS-dev] Re: [GRASS-PSC] adding r.li to GRASS In-Reply-To: <454F546E.5090004@faunalia.it> Message-ID: Paolo, I'm in the process of redoing the GIS Manager menu. Should it just be an additional entry in the 'landscape structure modeling' submenu under raster? Or are there multiple files? Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Paolo Cavallini > Date: Mon, 06 Nov 2006 16:27:42 +0100 > To: Michael Barton > Cc: Markus Neteler , , Serena > Pallecchi , Claudio Porta , > Davide Spano > Subject: Re: [GRASS-PSC] adding r.li to GRASS > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Michael Barton ha scritto: >> Once this is all done, we need to decide if it should replace r.le in the >> menu, and if so what are the specific modules that need to be run. > > As for now, r.li calculates less indices than r.le, so it cannot be > considered a full replacement. > >> Also, >> does this **require** an interactive xterm like parts of r.le? > > It shouldn't, AFAIK. > pc > - -- > Paolo Cavallini > email+jabber: cavallini@faunalia.it > www.faunalia.it > Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFFT1Ru/NedwLUzIr4RAvRhAJ9Y4EbN/Z/lHewkCBgcWnV7UBRS4wCgrh04 > 7s+g6xwfO+xo0cv9Xv0Sip8= > =R1c7 > -----END PGP SIGNATURE----- From hamish_nospam at yahoo.com Tue Nov 7 05:09:03 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Nov 7 05:09:09 2006 Subject: [GRASS-dev] Improved ellipsoid name support In-Reply-To: References: Message-ID: <20061107170903.7c1c6893.hamish_nospam@yahoo.com> Paul Kelly wrote: > > 1. When generating a WKT projection description, put the full > ellipsoid name from ellipse.table in the "SPHEROID" section. The > short name still goes in the "GEOGCS" section. I'd like to update the "GIS concepts" part of the GRASS Wiki. http://grass.gdf-hannover.de/wiki/Gis_Concepts WRT proj jargon, my understanding is: ellipsoid and spheroid are the same thing, some people use one, some the other.. and ellipsoid is arguably the better choice ? datum = [ellipsoid, origin] ? thanks, Hamish From hamish_nospam at yahoo.com Tue Nov 7 05:24:41 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Nov 7 05:24:51 2006 Subject: [GRASS-dev] Windows-style Pathnames In-Reply-To: References: <17737.4290.419895.264288@cerise.gclements.plus.com> <20061101215211.GA3922@localhost.tamu.edu> <17737.21068.670434.23541@cerise.gclements.plus.com> <17738.42338.869940.724212@cerise.gclements.plus.com> Message-ID: <20061107172441.2928b9a2.hamish_nospam@yahoo.com> Paul Kelly wrote: > Yes. The way I've done that in the is first to pass the string > containing the path to G_convert_dirseps_to_host(), which will > replace all occurences of / by \, and then quote the path name with > \"escaped double quotes\" within the argument supplied to system() - > I think this should cover both eventualities of the pathname > containing spaces, *and* the backslashes possibly being > misinterpreted by a shell. Although as we've seen it should normally > by cmd.exe invoked for this. does it check/strip existing " before adding new ones? > especially if we get display drivers working. it would be nice to go directly to a simple wxPython canvas window that could take d.* cmds, instead of bothering to adapt XDRIVER... but the PNG driver was a problem too, yes? So we need a socket-less PNG driver? or a new direct rendering wxDRIVER? (simple d.mon replacement, probably nothing to do with gis manager gui canvas?) Glynn: > > So, if we were to add ".sh" extensions to all of the scripts, and > > add ".sh" to PATHEXT, calling e.g. system("r.out.gdal ...") should > > run r.out.gdal.sh using the program associated with ".sh" in the > > registry. I hope this is done in the windows build process (like "gcc -o ${module}.exe", and not for all platforms. i.e. "g.script" works from the command line on all platforms without having to type ".sh" in unix. Hamish From hamish_nospam at yahoo.com Tue Nov 7 05:57:51 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Nov 7 05:57:57 2006 Subject: [GRASS-dev] GRASS at GForge first steps In-Reply-To: <200611061527.52734.bernhard@intevation.de> References: <454CAEEF.7020506@o2.pl> <20061105184812.4796fb6c.hamish_nospam@yahoo.com> <454DB59E.1030600@o2.pl> <200611061527.52734.bernhard@intevation.de> Message-ID: <20061107175751.620a3274.hamish_nospam@yahoo.com> Hamish: > > > how is a defect different than a bug? Maciej: > > Call it "bad feature". I sometimes was told that I was reporting > > something as a bug while actually it was a feature. Although that > > feature was not good - eg. the current memory overhaed in GRASS > > vectors and dbf driver. Do you want a separate tracker for defects > > and bugs (I'd prefer them kept in one tracker, so that defects are > > as attended as bugs are). Bernhard: > I think a bug is also too general as a term. Zeller 2006 explains > this and uses "defect". > See http://www.whyprogramsfail.com/ FWIW, Debian has a "wontfix" tag for bugs. I think to say all features which do something other than what a user might expect at first are "misfeatures" or a "defect" is wrong. Some are real defects/shortcomings, but others are counter-intuitive yet correct design choices. (shrug) Hamish From hamish_nospam at yahoo.com Tue Nov 7 06:11:08 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Nov 7 06:11:19 2006 Subject: [GRASS-dev] GRASS at GForge first steps In-Reply-To: <20061106180429.GA3346@localdomain> References: <454CAEEF.7020506@o2.pl> <20061106180429.GA3346@localdomain> Message-ID: <20061107181108.2dd03ed1.hamish_nospam@yahoo.com> Jachym Cepicky wrote: > > I will do it (try to do it). What exactly am I supposed to do? My > imaginatio is following: > > - Someone will submit some patch to wald > - I (or someone else) will examine the patch, look if it does what > it is supposed to do and paste my comment about this patch to > grass-dev list > - If it will be only small correction, I'll apply the patch to CVS > immediately > - If it will be bigger change and nobody will complain in > grass-dev > within a week or so, I'll commit the change too. > > Anything else? Or do I understand this task completely wrong? I prefer to be more conservative, adding code to CVS should be opt-in not opt-out. A patch needs a developer-supporter to give it the ok, versus falling into CVS by default. (see PSC code accountability requirements) I don't think it is bad that many patches could collect there, or at least that is better than bad patches falling into CVS by default because devels were busy that week. 10c, (NZ just abolished the 5c coin, and abolished the 1,2c coins in the early 90s; but after the exchange rate the 10c is a lot less than it sounds ;) Hamish From glynn at gclements.plus.com Tue Nov 7 06:25:39 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Nov 7 06:25:41 2006 Subject: [GRASS-dev] Quick gis.m test on Windows In-Reply-To: References: Message-ID: <17744.6355.558902.763637@cerise.gclements.plus.com> Paul Kelly wrote: > Just tried it and it seems to have a few problems with Msys-based > assumptions: I eventually found it works OK if I start it from the Msys > terminal but we should in theory be able to get everything except scripts > working without Msys. > Anyway I'm not great at debugging Tcl but when first starting up I got > this error: > couldn't write file "/dev/null": no such file or directory > couldn't write file "/dev/null": no such file or directory It's called "NUL:" on Windows, although ... > while executing > "exec -- d.font romans >& /dev/null" ... gis.m probably shouldn't be running d.font. I thought it was using direct rendering now, in which case d.font won't work. -- Glynn Clements From glynn at gclements.plus.com Tue Nov 7 06:34:34 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Nov 7 06:36:15 2006 Subject: [GRASS-dev] How to change fonts in gis manager? In-Reply-To: References: <17743.18786.799533.511272@cerise.gclements.plus.com> Message-ID: <17744.6890.35571.792357@cerise.gclements.plus.com> Michael Barton wrote: > Thanks. I can do something to implement these. I have a related question. > TclTk (and wxPython) have built-in utilities to allow the user to select a > "system" font of some kind (e.g., {timeroman 12 bold}). Is there any way > that GRASS can recognize these? No. At least, not without adding code to use whatever interface(s) Tk/wxPython use. AFAICT, Tk doesn't use any standard interface (at least not on X), so we would have to either take the code which Tk uses and add it to lib/driver, or make lib/driver depend upon Tk. Even that might not be sufficient; Tk just needs to get a reference to the font which it can pass to the window system; GRASS needs the actual glyph bitmaps. -- Glynn Clements From glynn at gclements.plus.com Tue Nov 7 06:39:30 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Nov 7 06:40:25 2006 Subject: [GRASS-dev] How to change fonts in gis manager? In-Reply-To: <20061107162504.6618f093.hamish_nospam@yahoo.com> References: <20061107162504.6618f093.hamish_nospam@yahoo.com> Message-ID: <17744.7186.127219.570280@cerise.gclements.plus.com> Hamish wrote: > > I?ve created a nice TclTk panel for d.text.new in the GIS Manager. > > we should probably pick a better name than "d.text.new", it tells you > nothing about what the module does vs other d.text modules and will > become an anachronism before very long. If it's deemed to be work adequately, it should supersede d.text (i.e. change PGM to d.text in display/d.text.new/Makefile and remove d.text from SUBDIRS in display/Makefile). -- Glynn Clements From glynn at gclements.plus.com Tue Nov 7 07:00:01 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Nov 7 07:00:04 2006 Subject: [GRASS-dev] Windows-style Pathnames In-Reply-To: References: <17737.4290.419895.264288@cerise.gclements.plus.com> <20061101215211.GA3922@localhost.tamu.edu> <17737.21068.670434.23541@cerise.gclements.plus.com> <17738.42338.869940.724212@cerise.gclements.plus.com> Message-ID: <17744.8417.439364.190253@cerise.gclements.plus.com> Paul Kelly wrote: > > AFAICT, the "interpreter" is selected according the registry entry > > corresponding to the extension, the same as if you had double-clicked > > on the file's icon from an Explorer window. > > > > So, if we were to add ".sh" extensions to all of the scripts, and add > > ".sh" to PATHEXT, calling e.g. system("r.out.gdal ...") should run > > r.out.gdal.sh using the program associated with ".sh" in the registry. > > That sounds like a fairly handy way of doing it. Does the installing user > need to be an administator on the Windows machine to change the registry > to do this file extension association? I think that you might need to be at least "Power User" to add the interpreter to the registry, but a normal user can change the association between the extension and the interpreter. > Or the other way that was discussed before was some kind of launcher > executable program. I was thinking that it could even be installed instead > of all the scripts like "front.end" used to be, and it would check the > contents of the real scripts and start them with the shell specified in a > GRASS_SH environment variable. But that might be a bit complicated and > prone to going wrong whereas the first approach would be more > understandable for experienced Windows users. Using extensions has the advantage that it will work within cmd.exe without having to manually invoke the launcher/interpreter. -- Glynn Clements From glynn at gclements.plus.com Tue Nov 7 07:03:34 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Nov 7 07:03:37 2006 Subject: [GRASS-dev] Windows-style Pathnames In-Reply-To: <20061107172441.2928b9a2.hamish_nospam@yahoo.com> References: <17737.4290.419895.264288@cerise.gclements.plus.com> <20061101215211.GA3922@localhost.tamu.edu> <17737.21068.670434.23541@cerise.gclements.plus.com> <17738.42338.869940.724212@cerise.gclements.plus.com> <20061107172441.2928b9a2.hamish_nospam@yahoo.com> Message-ID: <17744.8630.666179.799659@cerise.gclements.plus.com> Hamish wrote: > > Yes. The way I've done that in the is first to pass the string > > containing the path to G_convert_dirseps_to_host(), which will > > replace all occurences of / by \, and then quote the path name with > > \"escaped double quotes\" within the argument supplied to system() - > > I think this should cover both eventualities of the pathname > > containing spaces, *and* the backslashes possibly being > > misinterpreted by a shell. Although as we've seen it should normally > > by cmd.exe invoked for this. > > does it check/strip existing " before adding new ones? > > > especially if we get display drivers working. > > it would be nice to go directly to a simple wxPython canvas window that > could take d.* cmds, instead of bothering to adapt XDRIVER... but the > PNG driver was a problem too, yes? So we need a socket-less PNG driver? > or a new direct rendering wxDRIVER? (simple d.mon replacement, probably > nothing to do with gis manager gui canvas?) The problem is specifically with standalone drivers; driver-less rendering works on Windows. A GUI application shouldn't be using standalone drivers, and I'd rather see a remote-control feature added to the GUI than putting significant effort into making mon.start work on Windows. -- Glynn Clements From michael.barton at asu.edu Tue Nov 7 07:18:02 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Nov 7 07:18:10 2006 Subject: [GRASS-dev] How to change fonts in gis manager? In-Reply-To: <20061107162504.6618f093.hamish_nospam@yahoo.com> Message-ID: IMHO, it should simply replace d.text. It has all d.text features and more. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Hamish > Date: Tue, 7 Nov 2006 16:25:04 +1300 > To: Michael Barton > Cc: , > Subject: Re: [GRASS-dev] How to change fonts in gis manager? > > Michael Barton wrote: >> >> I?ve created a nice TclTk panel for d.text.new in the GIS Manager. > > > we should probably pick a better name than "d.text.new", it tells you > nothing about what the module does vs other d.text modules and will > become an anachronism before very long. > > > > thanks, > Hamish From michael.barton at asu.edu Tue Nov 7 07:22:06 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Nov 7 07:22:16 2006 Subject: [GRASS-dev] How to change fonts in gis manager? In-Reply-To: <17744.6890.35571.792357@cerise.gclements.plus.com> Message-ID: Too bad. It is easy enough to make an interface that will pull up GRASS fonts and the few TrueType fonts that live in the X11 directory, and offer a browser to let the users pick others. I've done that now. However, it would be nice if GRASS could somehow easily recognize all the standard system fonts on different OS's. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Glynn Clements > Date: Tue, 7 Nov 2006 05:34:34 +0000 > To: Michael Barton > Cc: grass-dev > Subject: Re: [GRASS-dev] How to change fonts in gis manager? > > > Michael Barton wrote: > >> Thanks. I can do something to implement these. I have a related question. >> TclTk (and wxPython) have built-in utilities to allow the user to select a >> "system" font of some kind (e.g., {timeroman 12 bold}). Is there any way >> that GRASS can recognize these? > > No. > > At least, not without adding code to use whatever interface(s) > Tk/wxPython use. AFAICT, Tk doesn't use any standard interface (at > least not on X), so we would have to either take the code which Tk > uses and add it to lib/driver, or make lib/driver depend upon Tk. > > Even that might not be sufficient; Tk just needs to get a reference to > the font which it can pass to the window system; GRASS needs the > actual glyph bitmaps. > > -- > Glynn Clements From michael.barton at asu.edu Tue Nov 7 07:35:36 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Nov 7 07:36:11 2006 Subject: [GRASS-dev] Quick gis.m test on Windows In-Reply-To: Message-ID: Paul, I'm not sure exactly what you're trying to do. I'll offer a bit of insight and maybe you can clarify your objective more. I think that Huidae Cho put in the MinGW/Msys pieces into the TclTk code a month or so back to get the current alpha winGRASS to run. I've pretty much left them alone (except for once when I accidentally committed a new version that left some out). Later this week, I'll be committing some changes to the GIS Manager for GRASS 6.3 now that 6.2 is out the door. The main thing is adding support for a text layer based on the new d.text version. The second is mouse placement for text items, legends, and barscales. Doing this, led to a cascade of some other changes of course. One of these is that the problematic d.font romans statement below is no more. Glynn's recent changes to the display drivers made this unnecessary. Cedric Shock did the gronsole stuff and I still don't quite follow it. It looks like the second problem may be because it is getting hung up when gronsole tries to echo the series of display commands back to the TclTk command console (gronsole). I don't know why, however. What do you mean that you changed the variable to be unconditional? Did you take out an if clause? What did it do? I'll try to help you as much as I can on this. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Paul Kelly > Date: Mon, 6 Nov 2006 22:09:30 +0000 (GMT) > To: > Subject: [GRASS-dev] Quick gis.m test on Windows > > Just tried it and it seems to have a few problems with Msys-based > assumptions: I eventually found it works OK if I start it from the Msys > terminal but we should in theory be able to get everything except scripts > working without Msys. > Anyway I'm not great at debugging Tcl but when first starting up I got > this error: > couldn't write file "/dev/null": no such file or directory > couldn't write file "/dev/null": no such file or directory > while executing > "exec -- d.font romans >& /dev/null" > ("eval" body line 1) > invoked from within > "eval [list exec -- $cmd] $args >& $devnull" > (procedure "run" line 12) > invoked from within > "run d.font romans" > ("eval" body line 1) > invoked from within > "eval run $cmd $args" > (procedure "runcmd" line 6) > invoked from within > "runcmd "d.font romans"" > (procedure "MapCanvas::runprograms" line 63) > invoked from within > "MapCanvas::runprograms $mon [expr {$mymodified != 0}]" > (procedure "MapCanvas::drawmap" line 38) > invoked from within > "MapCanvas::drawmap $mon" > (procedure "MapCanvas::display_server" line 9) > invoked from within > "MapCanvas::display_server" > ("after" script) > > Found a place in gm.tcl that seemed to be setting an mingw variable to > true if Msys was detected - I changed that to be unconditional and got a > bit further to the following error when trying to display a map: > can't read "_data(.gronsole.gronsole,2,donecmd)": no such element in array > can't read "_data(.gronsole.gronsole,2,donecmd)": no such element in array > while executing > "set donecmd $_data($path,$ci,donecmd)" > (procedure "Gronsole::done_command" line 3) > invoked from within > "Gronsole::done_command $path $ci" > (procedure "Gronsole::execout" line 26) > invoked from within > "Gronsole::execout $path $cmd $ci Gronsole::execwait" > (procedure "Gronsole::run_wait" line 6) > invoked from within > "Gronsole::run_wait .gronsole.gronsole {d.rast map=geology@PERMANENT -o} > gism" > ("eval" body line 1) > invoked from within > "eval Gronsole::$cmd .gronsole.gronsole $args" > (procedure ".gronsole.gronsole" line 1) > invoked from within > "$gronsole run_wait $cmd gism" > (procedure "run_panel" line 4) > invoked from within > "run_panel $cmd" > (procedure "GmCommonLayer::display_commands" line 33) > invoked from within > "GmCommonLayer::display_commands $namespace $id [list $cmd]" > (procedure "GmCommonLayer::display_command" line 2) > invoked from within > "GmCommonLayer::display_command [namespace current] $id $cmd" > (procedure "GmRaster::display" line 63) > invoked from within > "GmRaster::display $node $mod" > ("raster" arm line 2) > invoked from within > "switch $type { > group { > GmGroup::display $node $mod > } > raster { > GmRaster::display $node $mod > } > labels { > GmLabels::disp..." > (procedure "GmTree::display_node" line 7) > invoked from within > "GmTree::display_node $n $mod" > (procedure "GmGroup::display" line 22) > invoked from within > "GmGroup::display "root" $mod" > (procedure "MapCanvas::runprograms" line 63) > invoked from within > "MapCanvas::runprograms $mon [expr {$mymodified != 0}]" > (procedure "MapCanvas::drawmap" line 38) > invoked from within > "MapCanvas::drawmap $mon" > (procedure "MapCanvas::display_server" line 9) > invoked from within > "MapCanvas::display_server" > ("after" script) > > Hope it's helpful for debugging. > > Paul > > From michael.barton at asu.edu Tue Nov 7 07:39:07 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Nov 7 07:39:24 2006 Subject: [GRASS-dev] Windows-style Pathnames In-Reply-To: <20061107172441.2928b9a2.hamish_nospam@yahoo.com> Message-ID: This feature is already up and running in the prototype wxPython GRASS GUI. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Hamish > Date: Tue, 7 Nov 2006 17:24:41 +1300 > To: Paul Kelly > Cc: , > Subject: Re: [GRASS-dev] Windows-style Pathnames > > it would be nice to go directly to a simple wxPython canvas window that > could take d.* cmds, instead of bothering to adapt XDRIVER... but the > PNG driver was a problem too, yes? So we need a socket-less PNG driver? > or a new direct rendering wxDRIVER? (simple d.mon replacement, probably > nothing to do with gis manager gui canvas?) > From cavallini at faunalia.it Tue Nov 7 08:01:50 2006 From: cavallini at faunalia.it (Paolo Cavallini) Date: Tue Nov 7 08:02:01 2006 Subject: [GRASS-dev] Re: [GRASS-PSC] adding r.li to GRASS In-Reply-To: References: Message-ID: <45502F5E.9060402@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Michael. Thanks for this. There are multiple files, more or less like r.le (a setup + various analyses). Presumably more analyses will follow. All the best. pc Michael Barton ha scritto: > Paolo, > > I'm in the process of redoing the GIS Manager menu. Should it just be an > additional entry in the 'landscape structure modeling' submenu under raster? > Or are there multiple files? > > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton - -- Paolo Cavallini email+jabber: cavallini@faunalia.it www.faunalia.it Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFUC9e/NedwLUzIr4RAoE4AKC0vnYscoAQk7Ear88KMn/0uHQQsQCglI3Y 9ZsnBWzmtOFGeKlmp+jpAko= =Eg4i -----END PGP SIGNATURE----- From jachym.cepicky at centrum.cz Tue Nov 7 08:10:59 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Tue Nov 7 08:11:00 2006 Subject: [GRASS-dev] GRASS at GForge first steps In-Reply-To: <20061107181108.2dd03ed1.hamish_nospam@yahoo.com> References: <454CAEEF.7020506@o2.pl> <20061106180429.GA3346@localdomain> <20061107181108.2dd03ed1.hamish_nospam@yahoo.com> Message-ID: <20061107071053.GA7056@localdomain> On Tue, Nov 07, 2006 at 06:11:08PM +1300, Hamish wrote: > Jachym Cepicky wrote: > > > > I will do it (try to do it). What exactly am I supposed to do? My > > imaginatio is following: > > > > - Someone will submit some patch to wald > > - I (or someone else) will examine the patch, look if it does what > > it is supposed to do and paste my comment about this patch to > > grass-dev list > > - If it will be only small correction, I'll apply the patch to CVS > > immediately > > - If it will be bigger change and nobody will complain in > > grass-dev > > within a week or so, I'll commit the change too. > > > > Anything else? Or do I understand this task completely wrong? > > > I prefer to be more conservative, adding code to CVS should be opt-in > not opt-out. A patch needs a developer-supporter to give it the ok, > versus falling into CVS by default. So if I understand it right, the last point in my decision tree will sound: - If it will be bigger change and there will be no consensus agreement, I'll leave the patch uncommited. Is it right? Jachym > (see PSC code accountability > requirements) I don't think it is bad that many patches could collect > there, or at least that is better than bad patches falling into CVS by > default because devels were busy that week. > > 10c, (NZ just abolished the 5c coin, and abolished the 1,2c coins in the > early 90s; but after the exchange rate the 10c is a lot less than it > sounds ;) > > Hamish -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc ----------------------------------------- OFFICE: Department of Geoinformation Technologies Zemedelska 3 613 00, Brno Czech Republick e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz Tel.: +420 545 134 514 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061107/45054817/attachment-0001.bin From mlennert at club.worldonline.be Tue Nov 7 09:26:05 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Nov 7 09:25:24 2006 Subject: [GRASS-dev] collecting grass (future) concepts In-Reply-To: <20061106200646.GA30068@bartok.itc.it> References: <20061031190919.GB22016@bartok.itc.it> <20061106200646.GA30068@bartok.itc.it> Message-ID: <4550431D.6020700@club.worldonline.be> Markus Neteler wrote: > Hi, > > here my candidates for merge/removal: > > grassgui GRASSGUI mailing list > nvizlist List to discuss GRASS/NVIZ visualization tools > sqlgrass GRASS and SQL support > > > If you look at > http://grass.itc.it/pipermail/nvizlist/ > http://grass.itc.it/pipermail/grassgui/ > http://grass.itc.it/pipermail/sqlgrass/ > > you can see that they are basically unused. As a first attempt > we could simply remove them from > http://grass.itc.it/community/support.php > to not mislead people (who do not receive answers there). > > Then I could close them for further subscription but leave > the archives alive. +1 Moritz > > Markus > > On Mon, Nov 06, 2006 at 11:09:10AM +0100, Martin Landa wrote: >> Hi all, >> >> sorry for the late response. >> >> First of all, thanks for your opinions. >> >> The main reason why I suggested to create a new specialized mailing >> list -- it is very difficult to find topic-orientated (e.g. concepts, >> etc.) messages in grass-dev. On the other hand the better medium for >> collecting ideas is the wiki. >> >> BTW, there is lot of GRASS mailing list with (very) low traffic. Maybe >> we should open discussion to decrease this number. Just idea;-) >> >> Cheers, Martin >> >> 2006/10/31, Markus Neteler : >>> Hi, >>> >>> please let's keep the discussion here on grass-dev. >>> We have already too many mailing lists to follow. >>> >>> Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From landa.martin at gmail.com Tue Nov 7 09:41:40 2006 From: landa.martin at gmail.com (Martin Landa) Date: Tue Nov 7 09:41:45 2006 Subject: [GRASS-dev] collecting grass (future) concepts In-Reply-To: <4550431D.6020700@club.worldonline.be> References: <20061031190919.GB22016@bartok.itc.it> <20061106200646.GA30068@bartok.itc.it> <4550431D.6020700@club.worldonline.be> Message-ID: +2 2006/11/7, Moritz Lennert : > Markus Neteler wrote: > > Hi, > > > > here my candidates for merge/removal: > > > > grassgui GRASSGUI mailing list > > nvizlist List to discuss GRASS/NVIZ visualization tools > > sqlgrass GRASS and SQL support > > > > > > If you look at > > http://grass.itc.it/pipermail/nvizlist/ > > http://grass.itc.it/pipermail/grassgui/ > > http://grass.itc.it/pipermail/sqlgrass/ > > > > you can see that they are basically unused. As a first attempt > > we could simply remove them from > > http://grass.itc.it/community/support.php > > to not mislead people (who do not receive answers there). > > > > Then I could close them for further subscription but leave > > the archives alive. > > +1 > > Moritz > > > > > Markus > > > > On Mon, Nov 06, 2006 at 11:09:10AM +0100, Martin Landa wrote: > >> Hi all, > >> > >> sorry for the late response. > >> > >> First of all, thanks for your opinions. > >> > >> The main reason why I suggested to create a new specialized mailing > >> list -- it is very difficult to find topic-orientated (e.g. concepts, > >> etc.) messages in grass-dev. On the other hand the better medium for > >> collecting ideas is the wiki. > >> > >> BTW, there is lot of GRASS mailing list with (very) low traffic. Maybe > >> we should open discussion to decrease this number. Just idea;-) > >> > >> Cheers, Martin > >> > >> 2006/10/31, Markus Neteler : > >>> Hi, > >>> > >>> please let's keep the discussion here on grass-dev. > >>> We have already too many mailing lists to follow. > >>> > >>> Markus > > > > _______________________________________________ > > 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 > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From bernhard at intevation.de Tue Nov 7 11:13:57 2006 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue Nov 7 11:14:02 2006 Subject: [GRASS-dev] GRASS at GForge first steps In-Reply-To: <20061107175751.620a3274.hamish_nospam@yahoo.com> References: <454CAEEF.7020506@o2.pl> <200611061527.52734.bernhard@intevation.de> <20061107175751.620a3274.hamish_nospam@yahoo.com> Message-ID: <200611071113.58665.bernhard@intevation.de> On Tuesday 07 November 2006 05:57, Hamish wrote: > Hamish: > > > > how is a defect different than a bug? > > Maciej: > > > Call it "bad feature". I sometimes was told that I was reporting > > > something as a bug while actually it was a feature. Although that > > > feature was not good - eg. the current memory overhaed in GRASS > > > vectors and dbf driver. Do you want a separate tracker for defects > > > and bugs (I'd prefer them kept in one tracker, so that defects are > > > as attended as bugs are). > > Bernhard: > > I think a bug is also too general as a term. Zeller 2006 explains > > this and uses "defect". > > See http://www.whyprogramsfail.com/ > > FWIW, Debian has a "wontfix" tag for bugs. Often I have seen this used to turn down people. > I think to say all features which do something other than what a user > might expect at first are "misfeatures" or a "defect" is wrong. Some are > real defects/shortcomings, but others are counter-intuitive yet correct > design choices. I follow Zeller pretty much here, but his writing goes into a lot more detail of course. He just says that "bug" is quite general. To me something that is "counter-intuitive" can be an issue and a usuability problem. Speaking of an "issue report" or "problem report" is a good general term, because this does not judge to early what kind of problem the user or developer has. Bernhard -- Managing Director - Owner, www.intevation.net (Free Software Company) Germany Coordinator, fsfeurope.org (Non-Profit Org for Free Software) www.kolab-konsortium.com (Email/Groupware Solution, Professional Service) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061107/2aae23ab/attachment.bin From landa.martin at gmail.com Tue Nov 7 11:16:40 2006 From: landa.martin at gmail.com (Martin Landa) Date: Tue Nov 7 11:16:44 2006 Subject: [GRASS-dev] do not get debug messages in 63-cvs In-Reply-To: References: <20061105162607.3ef9cea3.hamish_nospam@yahoo.com> Message-ID: Dear developers, 2006/11/6, Martin Landa : [snip] > > > I am also not sure, is this patch enough to fix it? > > > - G_debug ( 4, "G_getl2: ->%s<-", buf ); > > > + if (G__getenv ("DEBUG")) > > > + G_debug ( 4, "G_getl2: ->%s<-", buf ); > > > > > > > here, it works ... > > yes, I meant -- when you do not set up DEBUG variable and call > G_getl2() function no debug message (inside the function) will be > printed. It is not nice solution. I would like to kindly ask you -- is it good enough for committing to CVS? [no objections or feedback ~= can be commited;-). Debug messages are still broken in grass63. Best regards, Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From neteler at itc.it Tue Nov 7 12:27:31 2006 From: neteler at itc.it (Markus Neteler) Date: Tue Nov 7 12:27:34 2006 Subject: [GRASS-dev] ETRS_1989_LAEA issue Message-ID: <20061107112731.GF916@bartok.itc.it> Hi, I tried to create a new location from the CLC2000 data from EEA, distributed on DVD. The SHAPE file comes with a .proj file: ogrinfo -so 100kmE58N17.shp 100kmE58N17 INFO: Open of `100kmE58N17.shp' using driver `ESRI Shapefile' successful. Layer name: 100kmE58N17 Geometry: Polygon Feature Count: 392 Extent: (5800000.000180, 1699999.999117) - (5867022.238090, 1799999.999127) Layer SRS WKT: PROJCS["ETRS_1989_LAEA", GEOGCS["GCS_ETRS_1989", DATUM["ETRS_1989", SPHEROID["GRS_1980",6378137.0,298.257222101]], PRIMEM["Greenwich",0.0], UNIT["Degree",0.0174532925199433]], PROJECTION["Lambert_Azimuthal_Equal_Area"], PARAMETER["False_Easting",4321000.0], PARAMETER["False_Northing",3210000.0], PARAMETER["Central_Meridian",10.0], PARAMETER["Latitude_Of_Origin",52.0], UNIT["Meter",1.0]] CODE_00: String (3.0) AREA_HA: Real (17.5) SHAPE_area: Real (19.11) SHAPE_len: Real (19.11) But GRASS creates the location like this: GRASS 6.3.cvs (clc2000):/tmp > g.proj -w PROJCS["Lambert Azimuthal Equal Area", GEOGCS["unnamed", DATUM["unknown", SPHEROID["unnamed",6378137,298.257222101]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433]], PROJECTION["Lambert_Azimuthal_Equal_Area"], PARAMETER["latitude_of_center",52], PARAMETER["longitude_of_center",10], PARAMETER["false_easting",4321000], PARAMETER["false_northing",3210000], UNIT["Meter",1]] g.proj -p -PROJ_INFO------------------------------------------------- name : Lambert Azimuthal Equal Area proj : laea a : 6378137.0 es : 0.006694380022900787 lat_0 : 52 lon_0 : 10 x_0 : 4321000 y_0 : 3210000 no_defs : defined -PROJ_UNITS------------------------------------------------ unit : Meter units : Meters meters : 1 What's the trick to make GRASS recognize it completely? thanks, Markus From paul-grass at stjohnspoint.co.uk Tue Nov 7 12:45:29 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Nov 7 12:45:32 2006 Subject: [GRASS-dev] ETRS_1989_LAEA issue In-Reply-To: <20061107112731.GF916@bartok.itc.it> References: <20061107112731.GF916@bartok.itc.it> Message-ID: Hello Markus ETRS_1989 is a non-standard datum name (i.e. not what's in the EPSG database) - it should be European_Terrestrial_Reference_System_1989. I've committed a patch to CVS to handle the non-standard version so you should try it now. BTW (not relevant after the above patch, but interesting anyway) with my updates from Sunday night I would think it should at least recognise the ellipsoid, but it will probably put in WGS_1984 instead of GRS_1980 as they are the same within the tolerances we can check - I'm not sure which I should have first in the ellipsoid table (the first matching one will be reported)! Paul On Tue, 7 Nov 2006, Markus Neteler wrote: > Hi, > > I tried to create a new location from the CLC2000 data from > EEA, distributed on DVD. The SHAPE file comes with a .proj file: > > ogrinfo -so 100kmE58N17.shp 100kmE58N17 > INFO: Open of `100kmE58N17.shp' > using driver `ESRI Shapefile' successful. > > Layer name: 100kmE58N17 > Geometry: Polygon > Feature Count: 392 > Extent: (5800000.000180, 1699999.999117) - (5867022.238090, 1799999.999127) > Layer SRS WKT: > PROJCS["ETRS_1989_LAEA", > GEOGCS["GCS_ETRS_1989", > DATUM["ETRS_1989", > SPHEROID["GRS_1980",6378137.0,298.257222101]], > PRIMEM["Greenwich",0.0], > UNIT["Degree",0.0174532925199433]], > PROJECTION["Lambert_Azimuthal_Equal_Area"], > PARAMETER["False_Easting",4321000.0], > PARAMETER["False_Northing",3210000.0], > PARAMETER["Central_Meridian",10.0], > PARAMETER["Latitude_Of_Origin",52.0], > UNIT["Meter",1.0]] > CODE_00: String (3.0) > AREA_HA: Real (17.5) > SHAPE_area: Real (19.11) > SHAPE_len: Real (19.11) > > > But GRASS creates the location like this: > > GRASS 6.3.cvs (clc2000):/tmp > g.proj -w > PROJCS["Lambert Azimuthal Equal Area", > GEOGCS["unnamed", > DATUM["unknown", > SPHEROID["unnamed",6378137,298.257222101]], > PRIMEM["Greenwich",0], > UNIT["degree",0.0174532925199433]], > PROJECTION["Lambert_Azimuthal_Equal_Area"], > PARAMETER["latitude_of_center",52], > PARAMETER["longitude_of_center",10], > PARAMETER["false_easting",4321000], > PARAMETER["false_northing",3210000], > UNIT["Meter",1]] > > g.proj -p > -PROJ_INFO------------------------------------------------- > name : Lambert Azimuthal Equal Area > proj : laea > a : 6378137.0 > es : 0.006694380022900787 > lat_0 : 52 > lon_0 : 10 > x_0 : 4321000 > y_0 : 3210000 > no_defs : defined > -PROJ_UNITS------------------------------------------------ > unit : Meter > units : Meters > meters : 1 > > > What's the trick to make GRASS recognize it completely? > > thanks, > Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From neteler at itc.it Tue Nov 7 13:54:36 2006 From: neteler at itc.it (Markus Neteler) Date: Tue Nov 7 13:54:38 2006 Subject: [GRASS-dev] ETRS_1989_LAEA issue In-Reply-To: References: <20061107112731.GF916@bartok.itc.it> Message-ID: <20061107125436.GJ916@bartok.itc.it> Hello Paul, all the funny non-standard datum names, sigh (official EU data file!). The original .prj content is: PROJCS["ETRS_1989_LAEA",GEOGCS["GCS_ETRS_1989",DATUM["D_ETRS_1989",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Lambert_Azimuthal_Equal_Area"],PARAMETER["False_Easting",4321000.0],PARAMETER["False_Northing",3210000.0],PARAMETER["Central_Meridian",10.0],PARAMETER["Latitude_Of_Origin",52.0],UNIT["Meter",1.0]] Using your recent patch, it seems to work: g.proj -w PROJCS["Lambert Azimuthal Equal Area", GEOGCS["grs80", DATUM["European_Terrestrial_Reference_System_1989", SPHEROID["Geodetic_Reference_System_1980",6378137,298.257222101]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433]], PROJECTION["Lambert_Azimuthal_Equal_Area"], PARAMETER["latitude_of_center",52], PARAMETER["longitude_of_center",10], PARAMETER["false_easting",4321000], PARAMETER["false_northing",3210000], UNIT["Meter",1]] "grs80" was well detected. Thanks for the quick fix, I have merged it into the 6.2-relbranch for 6.2.1. Markus On Tue, Nov 07, 2006 at 11:45:29AM +0000, Paul Kelly wrote: > Hello Markus > ETRS_1989 is a non-standard datum name (i.e. not what's in the EPSG > database) - it should be European_Terrestrial_Reference_System_1989. I've > committed a patch to CVS to handle the non-standard version so you should > try it now. > > BTW (not relevant after the above patch, but interesting anyway) with my > updates from Sunday night I would think it should at least recognise the > ellipsoid, but it will probably put in WGS_1984 instead of GRS_1980 as > they are the same within the tolerances we can check - I'm not sure which > I should have first in the ellipsoid table (the first matching one will be > reported)! > > Paul > > On Tue, 7 Nov 2006, Markus Neteler wrote: > > >Hi, > > > >I tried to create a new location from the CLC2000 data from > >EEA, distributed on DVD. The SHAPE file comes with a .proj file: > > > >ogrinfo -so 100kmE58N17.shp 100kmE58N17 > >INFO: Open of `100kmE58N17.shp' > > using driver `ESRI Shapefile' successful. > > > >Layer name: 100kmE58N17 > >Geometry: Polygon > >Feature Count: 392 > >Extent: (5800000.000180, 1699999.999117) - (5867022.238090, 1799999.999127) > >Layer SRS WKT: > >PROJCS["ETRS_1989_LAEA", > > GEOGCS["GCS_ETRS_1989", > > DATUM["ETRS_1989", > > SPHEROID["GRS_1980",6378137.0,298.257222101]], > > PRIMEM["Greenwich",0.0], > > UNIT["Degree",0.0174532925199433]], > > PROJECTION["Lambert_Azimuthal_Equal_Area"], > > PARAMETER["False_Easting",4321000.0], > > PARAMETER["False_Northing",3210000.0], > > PARAMETER["Central_Meridian",10.0], > > PARAMETER["Latitude_Of_Origin",52.0], > > UNIT["Meter",1.0]] > >CODE_00: String (3.0) > >AREA_HA: Real (17.5) > >SHAPE_area: Real (19.11) > >SHAPE_len: Real (19.11) > > > > > >But GRASS creates the location like this: > > > >GRASS 6.3.cvs (clc2000):/tmp > g.proj -w > >PROJCS["Lambert Azimuthal Equal Area", > > GEOGCS["unnamed", > > DATUM["unknown", > > SPHEROID["unnamed",6378137,298.257222101]], > > PRIMEM["Greenwich",0], > > UNIT["degree",0.0174532925199433]], > > PROJECTION["Lambert_Azimuthal_Equal_Area"], > > PARAMETER["latitude_of_center",52], > > PARAMETER["longitude_of_center",10], > > PARAMETER["false_easting",4321000], > > PARAMETER["false_northing",3210000], > > UNIT["Meter",1]] > > > >g.proj -p > >-PROJ_INFO------------------------------------------------- > >name : Lambert Azimuthal Equal Area > >proj : laea > >a : 6378137.0 > >es : 0.006694380022900787 > >lat_0 : 52 > >lon_0 : 10 > >x_0 : 4321000 > >y_0 : 3210000 > >no_defs : defined > >-PROJ_UNITS------------------------------------------------ > >unit : Meter > >units : Meters > >meters : 1 > > > > > >What's the trick to make GRASS recognize it completely? > > > >thanks, > >Markus > > > >_______________________________________________ > >grass-dev mailing list > >grass-dev@grass.itc.it > >http://grass.itc.it/mailman/listinfo/grass-dev > > -- Markus Neteler http://mpa.itc.it/markus/ ITC-irst - Centro per la Ricerca Scientifica e Tecnologica MPBA - Predictive Models for Biol. & Environ. Data Analysis Via Sommarive, 18 - 38050 Povo (Trento), Italy From neteler at itc.it Tue Nov 7 14:32:05 2006 From: neteler at itc.it (Markus Neteler) Date: Tue Nov 7 14:32:08 2006 Subject: [GRASS-dev] collecting grass (future) concepts In-Reply-To: <20061107163642.1ee18252.hamish_nospam@yahoo.com> References: <20061031190919.GB22016@bartok.itc.it> <20061106200646.GA30068@bartok.itc.it> <20061107163642.1ee18252.hamish_nospam@yahoo.com> Message-ID: <20061107133205.GL916@bartok.itc.it> [from GRASS-dev list discussion to reduce number of lists] On Tue, Nov 07, 2006 at 04:36:42PM +1300, Hamish wrote: > Markus Neteler wrote: > > > > here my candidates for merge/removal: > > > > grassgui GRASSGUI mailing list > > nvizlist List to discuss GRASS/NVIZ visualization tools > > sqlgrass GRASS and SQL support > > > > > > If you look at > > http://grass.itc.it/pipermail/nvizlist/ > > http://grass.itc.it/pipermail/grassgui/ > > http://grass.itc.it/pipermail/sqlgrass/ > > > > you can see that they are basically unused. As a first attempt > > we could simply remove them from > > http://grass.itc.it/community/support.php > > to not mislead people (who do not receive answers there). > > > > Then I could close them for further subscription but leave > > the archives alive. > > > > this sounds like a good plan to me, > > > Hamish Due to various positive feedbacks: Done so. It is no longer possible to subscribe to above lists, they have been removed from the Web site listing of mailing lists. The archives are still accessible and searchable. I didn't actively unsubscribe people but would just leave it as-is. Markus From mlennert at club.worldonline.be Tue Nov 7 14:59:03 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Nov 7 14:58:13 2006 Subject: [GRASS-dev] windows binaries Message-ID: <45509127.9020501@club.worldonline.be> Hello Paul, Are you planning on publishing wingrass binaries at any point ? And could you maybe post details of all you did to compile wingrass (which other packages have to be installed, which configure flags, etc) ? As I said, I will have a bit more time in the near future and am more than willing to help with wingrass. For our needs here I will at one point have to attack the challenge of rewriting d.vect.thematic in C, but maybe we should make the current GRASS version work reasonably well before going for that. Please tell me what you think would be a priority for me to work on. Thanks ! Moritz From hmitaso at unity.ncsu.edu Tue Nov 7 14:59:48 2006 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Tue Nov 7 14:59:54 2006 Subject: [GRASS-dev] collecting grass (future) concepts In-Reply-To: <20061106200646.GA30068@bartok.itc.it> References: <20061031190919.GB22016@bartok.itc.it> <20061106200646.GA30068@bartok.itc.it> Message-ID: <3174D7BC-C8E6-4C26-BF23-B31593710CF0@unity.ncsu.edu> On Nov 6, 2006, at 3:06 PM, Markus Neteler wrote: > Hi, > > here my candidates for merge/removal: > > grassgui GRASSGUI mailing list > nvizlist List to discuss GRASS/NVIZ visualization tools > sqlgrass GRASS and SQL support > > > If you look at > http://grass.itc.it/pipermail/nvizlist/ > http://grass.itc.it/pipermail/grassgui/ > http://grass.itc.it/pipermail/sqlgrass/ > > you can see that they are basically unused. As a first attempt > we could simply remove them from > http://grass.itc.it/community/support.php > to not mislead people (who do not receive answers there). > > Then I could close them for further subscription but leave > the archives alive. yes, I think that is a good way how to close them, Helena > > Markus > > On Mon, Nov 06, 2006 at 11:09:10AM +0100, Martin Landa wrote: >> Hi all, >> >> sorry for the late response. >> >> First of all, thanks for your opinions. >> >> The main reason why I suggested to create a new specialized mailing >> list -- it is very difficult to find topic-orientated (e.g. concepts, >> etc.) messages in grass-dev. On the other hand the better medium for >> collecting ideas is the wiki. >> >> BTW, there is lot of GRASS mailing list with (very) low traffic. >> Maybe >> we should open discussion to decrease this number. Just idea;-) >> >> Cheers, Martin >> >> 2006/10/31, Markus Neteler : >>> Hi, >>> >>> please let's keep the discussion here on grass-dev. >>> We have already too many mailing lists to follow. >>> >>> Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From mlennert at club.worldonline.be Tue Nov 7 16:01:08 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Nov 7 16:00:18 2006 Subject: [GRASS-dev] Re: single-click zoom doesn't preserve aspect ratio Message-ID: <45509FB4.5050808@club.worldonline.be> Maciej Sieczka wrote: > Trying to switch to "Map fills display window" mode, I get an error: > > can't read "nsres": no such variable > can't read "nsres": no such variable > while executing > "expr round(abs($n-$s)/$nsres)" > (procedure "MapCanvas::currentzoom" line 27) > invoked from within > "MapCanvas::currentzoom $mon" > (procedure "MapCanvas::runprograms" line 24) > invoked from within > "MapCanvas::runprograms $mon [expr {$mymodified != 0}]" > (procedure "MapCanvas::drawmap" line 38) > invoked from within > "MapCanvas::drawmap $mon" > (procedure "MapCanvas::display_server" line 9) > invoked from within > "MapCanvas::display_server" > ("after" script) I can confirm this. Changing nsres and ewres (in the next line) to explore_nsres and explore_ewres apparently solves the problem for me, but I'm not sure whether this is the correct way to do it. Michael ? However, this raises another in my eyes more fundamental issue with gis.m: when such an error happens, the display canvas becomes unresponsive and even if I close it and open another canvas, I still cannot display anything. I have to close gis.m and relaunch it to be able to display again. This seems to be an issue with catching the error. Any ideas on how to solve this ? Moritz From mlennert at club.worldonline.be Tue Nov 7 16:06:09 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Nov 7 16:05:26 2006 Subject: [GRASS-dev] Re: single-click zoom doesn't preserve aspect ratio In-Reply-To: <45509FB4.5050808@club.worldonline.be> References: <45509FB4.5050808@club.worldonline.be> Message-ID: <4550A0E1.3060509@club.worldonline.be> Moritz Lennert wrote: > Maciej Sieczka wrote: >> Trying to switch to "Map fills display window" mode, I get an error: >> >> can't read "nsres": no such variable >> can't read "nsres": no such variable >> while executing >> "expr round(abs($n-$s)/$nsres)" >> (procedure "MapCanvas::currentzoom" line 27) >> invoked from within >> "MapCanvas::currentzoom $mon" >> (procedure "MapCanvas::runprograms" line 24) >> invoked from within >> "MapCanvas::runprograms $mon [expr {$mymodified != 0}]" >> (procedure "MapCanvas::drawmap" line 38) >> invoked from within >> "MapCanvas::drawmap $mon" >> (procedure "MapCanvas::display_server" line 9) >> invoked from within >> "MapCanvas::display_server" >> ("after" script) > > I can confirm this. Changing nsres and ewres (in the next line) to > explore_nsres and explore_ewres apparently solves the problem for me, > but I'm not sure whether this is the correct way to do it. Michael ? Sorry, forgot to include the patch: Index: mapcanvas.tcl =================================================================== RCS file: /grassrepository/grass6/gui/tcltk/gis.m/mapcanvas.tcl,v retrieving revision 1.49 diff -u -r1.49 mapcanvas.tcl --- mapcanvas.tcl 4 Nov 2006 00:01:43 -0000 1.49 +++ mapcanvas.tcl 7 Nov 2006 15:04:15 -0000 @@ -969,8 +969,8 @@ # Calculate the resolutions proportional to the map size set explore_nsres [expr {1.0 * ($n - $s) / $canvas_h($mon)}] set explore_ewres [expr {1.0 * ($e - $w) / $canvas_w($mon)}] - set explore_rows [expr round(abs($n-$s)/$nsres)] - set explore_cols [expr round(abs($e-$w)/$ewres)] + set explore_rows [expr round(abs($n-$s)/$explore_nsres)] + set explore_cols [expr round(abs($e-$w)/$explore_ewres)] lappend expanded_region $explore_nsres $explore_ewres $explore_rows $explore_cols set region $expanded_region } Moritz From tutey at o2.pl Tue Nov 7 18:40:18 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Nov 7 18:40:24 2006 Subject: [GRASS-dev] GRASS at GForge first steps In-Reply-To: <20061107071053.GA7056@localdomain> References: <454CAEEF.7020506@o2.pl> <20061106180429.GA3346@localdomain> <20061107181108.2dd03ed1.hamish_nospam@yahoo.com> <20061107071053.GA7056@localdomain> Message-ID: <4550C502.4060801@o2.pl> Jachym Cepicky wrote: > On Tue, Nov 07, 2006 at 06:11:08PM +1300, Hamish wrote: >> Jachym Cepicky wrote: >>> I will do it (try to do it). What exactly am I supposed to do? My >>> imaginatio is following: >>> >>> - Someone will submit some patch to wald >>> - I (or someone else) will examine the patch, look if it does what >>> it is supposed to do and paste my comment about this patch to >>> grass-dev list >>> - If it will be only small correction, I'll apply the patch to CVS >>> immediately >>> - If it will be bigger change and nobody will complain in >>> grass-dev >>> within a week or so, I'll commit the change too. >>> >>> Anything else? Or do I understand this task completely wrong? >> >> I prefer to be more conservative, adding code to CVS should be opt-in >> not opt-out. A patch needs a developer-supporter to give it the ok, >> versus falling into CVS by default. > > So if I understand it right, the last point in my decision tree will > sound: > - If it will be bigger change and there will be no consensus > agreement, I'll leave the patch uncommited. > > Is it right? Jachym, I think that's OK and I agree with Hamish. We'll adapt as the situation developes. In general I think the patches maintainer should a kind of an interface between the patch submitter and the GRASS developers. Coordinating the way the patch is dealt with, IOW. Not the ultimate patch master ;). Maciek From tutey at o2.pl Tue Nov 7 18:51:33 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Nov 7 18:51:37 2006 Subject: [GRASS-dev] GRASS at GForge first steps In-Reply-To: <200611061523.35572.bernhard@intevation.de> References: <454CAEEF.7020506@o2.pl> <200611061523.35572.bernhard@intevation.de> Message-ID: <4550C7A5.1000000@o2.pl> Bernhard Reiter wrote: > On Saturday 04 November 2006 16:17, Maciej Sieczka wrote: >> Trackers are available for public view, but in order to be able to >> post (including creating a new report), you must setup your account at >> GForge first [3]. This is to avoid http spam. All the trackers' posts >> are automatically forwarded to grass-dev list currently. >> >> If you want to be able to modify the contents of Trackers, you should >> request to join the GRASS project at GForge as developer [5]. > > I think it might be useful to keep the ability for people that > are not registered with the wald GRASS project to submit bugs > and also manupliate their owns. That would be very usefull. > (I currently do not know how > to model this on wald, but this is stating the goal.) Please keep us informed. >> 1. Admin is in charge of accepting requests to join the project and >> configuring the GRASS project at GForge. Currently I'm the only admin. >> We need 2 (3?), in case I'm not available. Candidates? > > I am willing to help out as backup. That's great! Will you join the GRASS project are you going to pull the strings incognito :)? > Our system administrators at Intevation of course also have > higher powers over wald, for emergencies. >> Talking of surveys >> The possible problem I see is that only admin can access >> the survey results :(, and there is no way to change this (CCing >> Bernhard if he has an idea). > Not directly out of the top of my head. > You can file this as a wish with wald. Done: http://wald.intevation.org/tracker/index.php?func=detail&aid=228&group_id=1&atid=162 Thanks, Maciek From tutey at o2.pl Tue Nov 7 18:54:04 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Nov 7 18:54:07 2006 Subject: [GRASS-dev] GRASS at GForge first steps In-Reply-To: <0E5A77B55A57D511BB3F0002A537C26208C55C1B@s5-dar-r1.nrn.nrcan.gc.ca> References: <0E5A77B55A57D511BB3F0002A537C26208C55C1B@s5-dar-r1.nrn.nrcan.gc.ca> Message-ID: <4550C83C.4000306@o2.pl> Patton, Eric wrote: > Thanks for the update and links! This is very encouraging. > I'll have to try to read through the GForge docs to familiarize myself with how it works. > Did Martin already volunteer for docs patches maintainer? Yes, he has. They will make a good team with Jachym. Best, Maciek From tutey at o2.pl Tue Nov 7 18:56:19 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Nov 7 18:56:23 2006 Subject: [GRASS-dev] collecting grass (future) concepts In-Reply-To: <20061107133205.GL916@bartok.itc.it> References: <20061031190919.GB22016@bartok.itc.it> <20061106200646.GA30068@bartok.itc.it> <20061107163642.1ee18252.hamish_nospam@yahoo.com> <20061107133205.GL916@bartok.itc.it> Message-ID: <4550C8C3.60200@o2.pl> Markus Neteler wrote: >> Hamish wrote > [from GRASS-dev list discussion to reduce number of lists] >>> Then I could close them for further subscription but leave >>> the archives alive. >> this sounds like a good plan to me, > Due to various positive feedbacks: > > Done so. Good move. Best, Maciek From tutey at o2.pl Tue Nov 7 19:28:07 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Nov 7 19:28:11 2006 Subject: wald, space (Re: [GRASS-dev] Re: r.out.gdal segfault in XY location) In-Reply-To: <20061107161617.4192fae0.hamish_nospam@yahoo.com> References: <20061106182603.431cfd67.hamish_nospam@yahoo.com> <454EE83E.40706@o2.pl> <200611061612.56868.bernhard@intevation.de> <20061107161617.4192fae0.hamish_nospam@yahoo.com> Message-ID: <4550D037.4050801@o2.pl> Hamish wrote: > BR: >> I am not quite sure that I know what "Wiki Add-ons scripts & modules" >> precisly are, but if this is useful for GRASS to track and reaonably >> seperate from other things. By all means: Track it. :) HB: > user contributions: > http://grass.gdf-hannover.de/wiki/GRASS_AddOns >> You can use the documentation space or another svn module if >> a tracker is not appropriate, so there are enough possibility to model >> a solution. The SVN might be too complicated for many submitters and the documentation module lacks necessary features compared to tracker. I think the tracker should be fine. Bernhard, How do I clone the bug tracker under some other name (I'd like to use it as prototype for addons tracker). Best, Maciek From bernhard at intevation.de Tue Nov 7 19:28:18 2006 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue Nov 7 19:28:26 2006 Subject: [GRASS-dev] GRASS at GForge first steps In-Reply-To: <4550C7A5.1000000@o2.pl> References: <454CAEEF.7020506@o2.pl> <200611061523.35572.bernhard@intevation.de> <4550C7A5.1000000@o2.pl> Message-ID: <200611071928.19092.bernhard@intevation.de> On Tuesday 07 November 2006 18:51, Maciej Sieczka wrote: > >> 1. Admin is in charge of accepting requests to join the project and > >> configuring the GRASS project at GForge. Currently I'm the only admin. > >> We need 2 (3?), in case I'm not available. Candidates? > > > > I am willing to help out as backup. > > That's great! Will you join the GRASS project are you going to pull the > strings incognito :)? Feel free to join me as administrator, my user id is "bernhard". -- Managing Director - Owner, www.intevation.net (Free Software Company) Germany Coordinator, fsfeurope.org (Non-Profit Org for Free Software) www.kolab-konsortium.com (Email/Groupware Solution, Professional Service) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061107/a25a2d40/attachment.bin From bernhard at intevation.de Tue Nov 7 19:30:30 2006 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue Nov 7 19:30:36 2006 Subject: wald, space (Re: [GRASS-dev] Re: r.out.gdal segfault in =?iso-8859-2?q?XY=09location?=) In-Reply-To: <4550D037.4050801@o2.pl> References: <20061107161617.4192fae0.hamish_nospam@yahoo.com> <4550D037.4050801@o2.pl> Message-ID: <200611071930.31670.bernhard@intevation.de> On Tuesday 07 November 2006 19:28, Maciej Sieczka wrote: > How do I clone the bug tracker under some other name (I'd like to use > it as prototype for addons tracker). I am currently careful with the clone option of gforge, as I am not sure what is cloned where right now. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061107/b2afa8e3/attachment-0001.bin From paul-grass at stjohnspoint.co.uk Tue Nov 7 20:19:43 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Nov 7 20:19:45 2006 Subject: [GRASS-dev] Windows-style Pathnames In-Reply-To: <20061107172441.2928b9a2.hamish_nospam@yahoo.com> References: <17737.4290.419895.264288@cerise.gclements.plus.com> <20061101215211.GA3922@localhost.tamu.edu> <17737.21068.670434.23541@cerise.gclements.plus.com> <17738.42338.869940.724212@cerise.gclements.plus.com> <20061107172441.2928b9a2.hamish_nospam@yahoo.com> Message-ID: On Tue, 7 Nov 2006, Hamish wrote: > Paul Kelly wrote: >> Yes. The way I've done that in the is first to pass the string >> containing the path to G_convert_dirseps_to_host(), which will >> replace all occurences of / by \, and then quote the path name with >> \"escaped double quotes\" within the argument supplied to system() - >> I think this should cover both eventualities of the pathname >> containing spaces, *and* the backslashes possibly being >> misinterpreted by a shell. Although as we've seen it should normally >> by cmd.exe invoked for this. > > does it check/strip existing " before adding new ones? The function doesn't add " characters - they were just added in the argument passed to the system() function. I wouldn't expect any filename strings being passed around to already contain " characters? > Glynn: >>> So, if we were to add ".sh" extensions to all of the scripts, and >>> add ".sh" to PATHEXT, calling e.g. system("r.out.gdal ...") should >>> run r.out.gdal.sh using the program associated with ".sh" in the >>> registry. > > I hope this is done in the windows build process (like "gcc -o > ${module}.exe", and not for all platforms. i.e. "g.script" works from > the command line on all platforms without having to type ".sh" in unix. Yes it would just be Windows-specific like .exe is already added to executable modules in Windows. Shouldn't be hard to do at all and then we just need to provide instructions to people on how to set up the file association, or maybe that can be done some scriptable way? From paul-grass at stjohnspoint.co.uk Tue Nov 7 20:13:09 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Nov 7 20:27:00 2006 Subject: [GRASS-dev] gis.m in wingrass: using where clause in d.vect causes error :can't read "_data(.gronsole.gronsole, 9, donecmd)": no such element in array In-Reply-To: <17706.10826.18404.911170@cerise.gclements.plus.com> References: <45267957.2020505@club.worldonline.be> <20061008155945.57c29721.hamish_nospam@yahoo.com> <42215.85.10.65.158.1160296222.squirrel@geog-pc40.ulb.ac.be> <43559.85.10.65.158.1160296669.squirrel@geog-pc40.ulb.ac.be> <452A095C.2050005@club.worldonline.be> <17706.10826.18404.911170@cerise.gclements.plus.com> Message-ID: On Mon, 9 Oct 2006, Glynn Clements wrote: > > Moritz Lennert wrote: > >>>>>> Using a where clause in vector display in gis.m causes the following >>>>>> error under WinGRASS. Any suggestions ? >>>>>> (WinGRASS version 2006-09-17) >>>>>> >>>>>> can't read "_data(.gronsole.gronsole,9,donecmd)": no such element in >>>>>> array can't read "_data(.gronsole.gronsole,9,donecmd)": no such >>>>>> element in array >>>>>> while executing >>>>>> "set donecmd $_data($path,$ci,donecmd)" >>>>> >>>>> also seen on Linux, GRASS versions 6.3 and 6.2-rc1 IF you put the >>>>> query in the "query cat values" box by mistake. >>>> I am not near a windows box right now, but I am quite positive that this >>>> is not the problem here. I entered the query in the where box, not the cat >>>> box. >>>> >>>> But I'll make sure tomorrow. >>> >>> Actually I just managed to test (Qemu over NX, quite an experience ;-) ), >>> and I can confirm that the problem is with the sql query box. So it is not >>> the same problem as the one described by Hamish. >> >> Huidae or Glynn, any ideas on this ? > > # Actually run the program > if { $mingw == "1" } { > # shell scripts require sh.exe. > set cmd [concat | sh -c '$cmd'] > } else { > set cmd [concat | $cmd 2>@ stdout] > } > > If you want to use "sh -c ...", you have to escape any shell > metacharacters, otherwise commands which happen to contain shell > metacharacters (e.g. "<" or ">" in a SQL "WHERE" clause) won't work. I got this working by changing the above (in gronsole.tcl) to: # Actually run the program if { $mingw == "1" } { set cmd [concat | $cmd |& cat] } else { set cmd [concat | $cmd 2>@ stdout] } A few Tcl help-related webpages recommend using "|& cat" to merge stdout and stderr. Unfortunately that's using the cat command that was installed with Msys, ideally we should get it working without Msys but all it needs is a simple program that reads from stdin and copies to stdout? Then it could be a cross-platform solution and we could get rid of the Mingw checks - I like doing that :). In a few places also needed to change if {[info exists env(MSYSCON)]} to if {[info exists env(OS)] && $env(OS) == "Windows_NT"} which is still ugly but at least not Msys-specific. Will comment more on it later; just noting this to the list now as I have a million other things going on in my head and might forget (this solves the problem I reported with gis.m earlier today - it wasn't with gis.m at all (sorry) but with the auto-generated Tcl/Tk dialog boxes for modules). Paul From paul-grass at stjohnspoint.co.uk Tue Nov 7 20:41:14 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Nov 7 20:41:17 2006 Subject: [GRASS-dev] Re: g.proj and datum information (and gis.m) In-Reply-To: References: Message-ID: On Fri, 20 Oct 2006, Michael Barton wrote: >> From: Paul Kelly >> Date: Sat, 21 Oct 2006 02:03:18 +0100 (BST) >> >> I haven't used gis.m, but why can the output window not accept user input? >> I think it would be cool if GRASS could work a bit like AutoCAD and Matlab >> which, while mostly GUI-oriented, still have a command line available. IIRC >> the way Radim integrated GRASS with QGIS on Windows with the GRASS shell >> inside QGIS worked something like this? > > You simply can't have an interactive xterm from inside a TclTk GUI. The > info gets returned to stderr, which TclTk treats as an error, or to stdout, > which TclTk treats (correctly) as information output from the command. There > is no way to communicate back from a simply text output window because it is > not an interactive xterm. I wasn't talking specifically about interactivity, just being able to run a command by manually typing it in. And I've just seen that you CAN do this! In the gis.m output window, you can type in any GRASS command you want and click run and you see any output in the Window above. That's exactly what I was looking for - I think it's really cool that GRASS has this. :) Paul From paul-grass at stjohnspoint.co.uk Tue Nov 7 21:31:52 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Nov 7 21:31:55 2006 Subject: [GRASS-dev] Windows-style Pathnames In-Reply-To: <20061102111509.GA21098@localhost.tamu.edu> References: <17737.4290.419895.264288@cerise.gclements.plus.com> <20061101215211.GA3922@localhost.tamu.edu> <20061101234228.GA5009@localhost.tamu.edu> <20061102111509.GA21098@localhost.tamu.edu> Message-ID: On Thu, 2 Nov 2006, Huidae Cho wrote: >>> comes to shell scripting because scripts have to deal with two types of >>> path styles in some cases. For example, it would be complicated to >>> implement "which" using $FOO if the script reads in a config file >>> directly. For this reason, I prefer UNIX-style pathnames even if host >>> syntax looks more reasonable. >> >> Not sure what you mean about implementing "which" using $FOO? > > See #5 in SUBMITTING_SCRIPTS. What I mean is if we accept Windows-style > path names, scripts should deal with both POSIX (/) and Windows (:, \) > path names in some (maybe few?) cases. OK yes. I think we maybe need to revise/remove that point from SUBMITTING_SCRIPTS. There was some discussion recently that came to the conclusion that it was OK to use "which", but I can't find it now in a quick search of the list. From paul-grass at stjohnspoint.co.uk Tue Nov 7 22:28:48 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Nov 7 22:28:51 2006 Subject: [GRASS-dev] Windows-style Pathnames In-Reply-To: <17738.42338.869940.724212@cerise.gclements.plus.com> References: <17737.4290.419895.264288@cerise.gclements.plus.com> <20061101215211.GA3922@localhost.tamu.edu> <17737.21068.670434.23541@cerise.gclements.plus.com> <17738.42338.869940.724212@cerise.gclements.plus.com> Message-ID: On Fri, 3 Nov 2006, Glynn Clements wrote: > Currently, a lot of GRASS assumes that scripts can be treated as > executables, as they are on Unix. I.e. you can call system("foo") and > it doesn't matter whether foo is a compiled executable or a script. > > You can do this on Windows, but the file needs to have an extension to > indicate how it is run (Unix detects this from the file's header, e.g. > #! for scripts). The PATHEXT environment variable contains a > semicolon-separated list of extensions which are treated as indicating > an executable. On my system, it is set to: > > PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH > > If you execute a "command" without a directory or extension, Windows > will consider files with any of those extensions when trying to > resolve the command name to an executable, effectively doing: > > for dir in $PATH ; do > for ext in $PATHEXT ; do > if [ -f $dir/$cmd$ext] ; then > exec $dir/$cmd$ext > fi > done > done > > AFAICT, the "interpreter" is selected according the registry entry > corresponding to the extension, the same as if you had double-clicked > on the file's icon from an Explorer window. > > So, if we were to add ".sh" extensions to all of the scripts, and add > ".sh" to PATHEXT, calling e.g. system("r.out.gdal ...") should run > r.out.gdal.sh using the program associated with ".sh" in the registry. Yes, I can confirm that this works. I guess we can handle the change to %PATHEXT% in a batch file that starts GRASS; FWIW here's what I had to do to set up the file association: Open any Windows Explorer window Go to Tools --> Folder Options --> File Types Click New, type sh for the extension and click OK Click on the new SH/SH File item in the list and click Advanced Pick an icon, Enter "Bourne Shell Script" or something similar in the text box at the top of the dialog box. Click New.. to create a new action Put run for the action name and in "Application used to perform action" type: (keep the quotes): "c:\msys\bin\sh.exe" "%1" %* where c:\msys\bin\sh.exe is the path to your shell interpreter. Click OK, OK again and close. And then with PATHEXT and a few other environment variables set up properly you should be able to run GRASS scripts (as well as other GRASS commands) from a Windows command prompt. Other variables that are probably necessary: GISRC GISBASE GRASS_PAGER GRASS_WISH PATH Unfortunately, Tcl seems to ignore the PATHEXT variable and according to http://www.tcl.tk/man/tcl8.4/TclCmd/exec.htm is hardcoded to only look for executable files with .com, .exe and .bat extensions. (Tcl is actually quite annoying.) But that's a problem for another day (which actually might involve forgetting about everything else above!). Paul From paul-grass at stjohnspoint.co.uk Tue Nov 7 22:49:30 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Nov 7 22:49:33 2006 Subject: [GRASS-dev] Re: windows binaries In-Reply-To: <45509127.9020501@club.worldonline.be> References: <45509127.9020501@club.worldonline.be> Message-ID: Hello Moritz On Tue, 7 Nov 2006, Moritz Lennert wrote: > Hello Paul, > > Are you planning on publishing wingrass binaries at any point ? And could you I guess I would if I think it's working well enough. If I got it to a stage where there was one zip file you could unzip anywhere, and an easy-to-edit Windows batch/command file to put a few paths into and save somewhere, I would consider that working well enough! > maybe post details of all you did to compile wingrass (which other packages > have to be installed, which configure flags, etc) ? OK don't have much time to say now but basically I followed Glynn's instructions posted to the list a week or two ago, with the difference that I was able to get shared libraries working OK. I haven't tried relocating anything or installing it on a different machine, or one wiithout Msys - that's a big challenge. You need to install Mingw and Msys to give you the build environment, and then you run configure and make from within there. But once compiled you don't need to run GRASS from within the Msys environment. There are a few places in the source code where the assumption "Msys == Windows" has been made in the past and it's so tedious tracking them down! I compiled and installed xdr lib, zlib and png lib in the Mingw lib/include directories. Used proj-4.5.0 and GDAL CVS from 2006-10-29 - the latest stable version of GDAL didn't work. I can't find any notes of my configure options from compiling those so I guess they weren't too important. Apart from Glynn's list I also installed Activestate Tcl. It seemed like a genuine native Windows Tcl version with no Cygwin or Msys influences so I thought it would be a good robust test. My configure options were: ./configure --prefix=c:/grass --bindir=c:/grass/bin \ --with-includes=/c/grass/include --with-libs=/c/grass/lib --with-cxx \ --without-jpeg --without-tiff --without-postgres --without-opengl \ --without-fftw --without-x --enable-x11=no --enable-shared=yes \ --with-tcltk-includes=/c/tcl/include --with-tcltk-libs=/c/tcl/bin > As I said, I will have a bit more time in the near future and am more than > willing to help with wingrass. > > For our needs here I will at one point have to attack the challenge of > rewriting d.vect.thematic in C, but maybe we should make the current GRASS > version work reasonably well before going for that. Didn't I read that d.vect.thematic needs the PNG driver to work. Have to confess that I'm not sure what it does - could it use ps.map? Anyway it won't be working on Windows in the near future so would be worthwhile I'm sure. > Please tell me what you think would be a priority for me to work on. I guess when people start using the native Windows they will mostly be doing it from the GUI and when things go wrong the error messages won't be entirely obvious. So it might be a good idea to investigate as much as possible from the command line whether most modules are working normally. Maybe the test suite could be useful. I came across loads of issues just while testing a few of my favourite modules. Look out for strange things like text strings apparently over-writing each other - caused by extraneous carriage return characters read in from text lines with \r\n line-endings. And pathnames and when the windows-style with backslashes absolutely has to be used is another useful thing to look out for. Trying to run things from a cmd.exe prompt rather than /bin/sh is probably helpful for looking out for native Windows issues. Paul From michael.barton at asu.edu Tue Nov 7 23:10:55 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Nov 7 23:11:45 2006 Subject: [GRASS-dev] Re: single-click zoom doesn't preserve aspect ratio In-Reply-To: <45509FB4.5050808@club.worldonline.be> Message-ID: This should already be in the cvs, as I sent it in on Saturday (I've been out of the office). If not either you can fix it or I can do it tomorrow. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Moritz Lennert > Date: Tue, 07 Nov 2006 16:01:08 +0100 > To: Maciej Sieczka > Cc: Grass Developers List , Michael Barton > > Subject: Re: single-click zoom doesn't preserve aspect ratio > > Maciej Sieczka wrote: >> Trying to switch to "Map fills display window" mode, I get an error: >> >> can't read "nsres": no such variable >> can't read "nsres": no such variable >> while executing >> "expr round(abs($n-$s)/$nsres)" >> (procedure "MapCanvas::currentzoom" line 27) >> invoked from within >> "MapCanvas::currentzoom $mon" >> (procedure "MapCanvas::runprograms" line 24) >> invoked from within >> "MapCanvas::runprograms $mon [expr {$mymodified != 0}]" >> (procedure "MapCanvas::drawmap" line 38) >> invoked from within >> "MapCanvas::drawmap $mon" >> (procedure "MapCanvas::display_server" line 9) >> invoked from within >> "MapCanvas::display_server" >> ("after" script) > > I can confirm this. Changing nsres and ewres (in the next line) to > explore_nsres and explore_ewres apparently solves the problem for me, > but I'm not sure whether this is the correct way to do it. Michael ? > > However, this raises another in my eyes more fundamental issue with > gis.m: when such an error happens, the display canvas becomes > unresponsive and even if I close it and open another canvas, I still > cannot display anything. I have to close gis.m and relaunch it to be > able to display again. This seems to be an issue with catching the > error. Any ideas on how to solve this ? > > Moritz From michael.barton at asu.edu Tue Nov 7 23:41:54 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Nov 7 23:42:00 2006 Subject: [GRASS-dev] Re: g.proj and datum information (and gis.m) In-Reply-To: Message-ID: Yes. That is the way it will work much better with Windows--when you can just type a command with all the arguments and have it do its thing. The same kind of thing, with a bit more sophistication, is going into the wxPython GUI. Where the problem lies, is with modules that assume you have an xterm, send messages to the xterm, then wait for your reply before proceeding. These are what won't work with TclTk (at least not without some kind of special massaging). Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Paul Kelly > Date: Tue, 7 Nov 2006 19:41:14 +0000 (GMT) > To: Michael Barton > Cc: Grass Developers List > Subject: Re: [GRASS-dev] Re: g.proj and datum information (and gis.m) > > On Fri, 20 Oct 2006, Michael Barton wrote: > >>> From: Paul Kelly >>> Date: Sat, 21 Oct 2006 02:03:18 +0100 (BST) >>> >>> I haven't used gis.m, but why can the output window not accept user input? >>> I think it would be cool if GRASS could work a bit like AutoCAD and Matlab >>> which, while mostly GUI-oriented, still have a command line available. IIRC >>> the way Radim integrated GRASS with QGIS on Windows with the GRASS shell >>> inside QGIS worked something like this? >> >> You simply can't have an interactive xterm from inside a TclTk GUI. The >> info gets returned to stderr, which TclTk treats as an error, or to stdout, >> which TclTk treats (correctly) as information output from the command. There >> is no way to communicate back from a simply text output window because it is >> not an interactive xterm. > > I wasn't talking specifically about interactivity, just being able to run > a command by manually typing it in. And I've just seen that you CAN do > this! In the gis.m output window, you can type in any GRASS command you > want and click run and you see any output in the Window above. That's > exactly what I was looking for - I think it's really cool that GRASS has > this. :) > > Paul From michael.barton at asu.edu Tue Nov 7 23:52:03 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Nov 7 23:53:33 2006 Subject: [GRASS-dev] Re: single-click zoom doesn't preserve aspect ratio In-Reply-To: <45509FB4.5050808@club.worldonline.be> Message-ID: There are probably ways to trap errors more gracefully. The best way is not to have them of course, but it would be good if the program continued even if it encountered one. I can't put a "catch" command on everything in every script (this is one way to trap), but it would be good to know which kinds of errors create this kind of freeze (not all do). As I encounter them, I try to trap them, but I'm not sure what to look for to do this proactively. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Moritz Lennert > Date: Tue, 07 Nov 2006 16:01:08 +0100 > To: Maciej Sieczka > Cc: Michael Barton , Grass Developers List > > Subject: [GRASS-dev] Re: single-click zoom doesn't preserve aspect ratio > > However, this raises another in my eyes more fundamental issue with > gis.m: when such an error happens, the display canvas becomes > unresponsive and even if I close it and open another canvas, I still > cannot display anything. I have to close gis.m and relaunch it to be > able to display again. This seems to be an issue with catching the > error. Any ideas on how to solve this ? From hamish_nospam at yahoo.com Wed Nov 8 04:05:19 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Nov 8 04:05:37 2006 Subject: [GRASS-dev] Re: windows binaries In-Reply-To: References: <45509127.9020501@club.worldonline.be> Message-ID: <20061108160519.360636a6.hamish_nospam@yahoo.com> Paul Kelly wrote: > > Didn't I read that d.vect.thematic needs the PNG driver to work. Have > to confess that I'm not sure what it does - could it use ps.map? d.graph would be an easier path I think. Hamish From hamish_nospam at yahoo.com Wed Nov 8 04:22:27 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Nov 8 04:22:36 2006 Subject: [GRASS-dev] Windows-style Pathnames In-Reply-To: References: <17737.4290.419895.264288@cerise.gclements.plus.com> <20061101215211.GA3922@localhost.tamu.edu> <20061101234228.GA5009@localhost.tamu.edu> <20061102111509.GA21098@localhost.tamu.edu> Message-ID: <20061108162227.228a7e23.hamish_nospam@yahoo.com> > >> Not sure what you mean about implementing "which" using $FOO? > > > > See #5 in SUBMITTING_SCRIPTS. What I mean is if we accept > > Windows-style path names, scripts should deal with both POSIX (/) > > and Windows (:, \) path names in some (maybe few?) cases. Paul: > OK yes. I think we maybe need to revise/remove that point from > SUBMITTING_SCRIPTS. There was some discussion recently that came to > the conclusion that it was OK to use "which", but I can't find it now > in a quick search of the list. post to grass-dev on Aug 29, 2006: "Re: [GRASS-dev] hardcoded 'xterm': wrapper?" http://thread.gmane.org/gmane.comp.gis.grass.devel/14702/focus=14735 Hamish From glynn at gclements.plus.com Wed Nov 8 05:14:49 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Nov 8 05:14:53 2006 Subject: [GRASS-dev] Windows-style Pathnames In-Reply-To: References: <17737.4290.419895.264288@cerise.gclements.plus.com> <20061101215211.GA3922@localhost.tamu.edu> <17737.21068.670434.23541@cerise.gclements.plus.com> <17738.42338.869940.724212@cerise.gclements.plus.com> <20061107172441.2928b9a2.hamish_nospam@yahoo.com> Message-ID: <17745.22969.12652.606501@cerise.gclements.plus.com> Paul Kelly wrote: > >>> So, if we were to add ".sh" extensions to all of the scripts, and > >>> add ".sh" to PATHEXT, calling e.g. system("r.out.gdal ...") should > >>> run r.out.gdal.sh using the program associated with ".sh" in the > >>> registry. > > > > I hope this is done in the windows build process (like "gcc -o > > ${module}.exe", and not for all platforms. i.e. "g.script" works from > > the command line on all platforms without having to type ".sh" in unix. > > Yes it would just be Windows-specific like .exe is already added to > executable modules in Windows. Shouldn't be hard to do at all and then we > just need to provide instructions to people on how to set up the file > association, or maybe that can be done some scriptable way? You can do this using the "assoc" and "ftype" commands (these are built in to cmd.exe rather than separate programs) . However, there appears to be more to this than what I can find in Microsoft's documentation. The assoc and ftype commands affect the keys in HKEY_CLASSES_ROOT (which is synthesised by merging HKEY_LOCAL_MACHINE\Software\Classes and HKEY_CURRENT_USER\Software\Classes). However, experimentation suggests that: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\\Application is used if that is set. It's quite possible that other "desktop" settings may also affect the process. My guess is that assoc/ftype will be sufficient if the user doesn't have any existing settings for the extension. If they do, all bets are off; I wouldn't count on the precise behaviour being documented anywhere. -- Glynn Clements From hamish_nospam at yahoo.com Wed Nov 8 05:50:18 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Nov 8 05:52:22 2006 Subject: [GRASS-dev] Re: single-click zoom doesn't preserve aspect ratio In-Reply-To: References: <45509FB4.5050808@club.worldonline.be> Message-ID: <20061108175018.5b3d0058.hamish_nospam@yahoo.com> Michael Barton wrote: > > There are probably ways to trap errors more gracefully. The best way is not > to have them of course, but it would be good if the program continued even > if it encountered one. I can't put a "catch" command on everything in every > script (this is one way to trap), but it would be good to know which kinds > of errors create this kind of freeze (not all do). As I encounter them, I > try to trap them, but I'm not sure what to look for to do this proactively. I would suggest this one as a candidate for catching: http://article.gmane.org/gmane.comp.gis.grass.user/16199 > GRASS 6.2.0 (Arctic):~ > gis.m > GRASS 6.2.0 (Arctic):~ > Error in startup script: can't read > "parts(n)": no such variable > while executing > "MapCanvas::zoom_new $mon $parts(n) $parts(s) $parts(e) $parts(w) > $parts(nsres) $parts(ewres)" > (procedure "MapCanvas::zoom_gregion" line 11) > invoked from within > "MapCanvas::zoom_gregion $mon" > (procedure "MapCanvas::create" line 40) .. and then reword the error to something meaninful .. Hamish From hamish_nospam at yahoo.com Wed Nov 8 06:31:54 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Nov 8 06:32:03 2006 Subject: [GRASS-dev] d.redraw -> g.parser Message-ID: <20061108183154.0d45ad25.hamish_nospam@yahoo.com> Hi, currently d.redraw doesn't use the parser as it takes no options. For man pages, etc it is nice to use it. There is --ui to force the GUI in parser.c, but no --no-ui to avoid it. And no enviro vars to control this either, AFAICT. Any problem with adding the --q flag to get the same effect? -#GUI is not very useful here, commented: -#if [ "$1" != "@ARGS_PARSED@" ] ; then -# exec g.parser "$0" "$@" -#fi +#GUI is not very useful here, +if [ "$1" != "@ARGS_PARSED@" ] ; then + exec g.parser "$0" "$@" --q +fi ? thanks, Hamish From hamish_nospam at yahoo.com Wed Nov 8 07:47:17 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Nov 8 07:47:32 2006 Subject: [GRASS-dev] drop db.droptable man page? Message-ID: <20061108194717.5cec8660.hamish_nospam@yahoo.com> Hi, db.droptable's man page still gets generated even though the module has been removed* from the Makefile. * rev 1.23: http://freegis.org/cgi-bin/viewcvs.cgi/grass6/db/base/Makefile is this patch correct? Hamish Index: db/base/Makefile =================================================================== RCS file: /home/grass/grassrepository/grass6/db/base/Makefile,v retrieving revision 1.27 diff -u -r1.27 Makefile --- db/base/Makefile 22 Sep 2006 16:30:51 -0000 1.27 +++ db/base/Makefile 8 Nov 2006 06:45:30 -0000 @@ -54,6 +54,6 @@ $(BIN)/db.connect$(EXE): $(OBJDIR)/connect.o $(CC) $(LDFLAGS) -o $@ $(OBJDIR)/connect.o $(FMODE_OBJ) $(LIBES) $(XDRLIB) $(MATHLIB) -#not used: db.createdb db.dropdb db.databases -PROGRAMS = db.columns db.copy db.droptable db.describe db.drivers db.execute db.select db.tables db.connect +#not used: db.createdb db.dropdb db.databases db.droptable +PROGRAMS = db.columns db.copy db.describe db.drivers db.execute db.select db.tables db.connect From hamish_nospam at yahoo.com Wed Nov 8 08:48:36 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Nov 8 08:48:48 2006 Subject: [GRASS-dev] g.parser use G_parser()? Message-ID: <20061108204836.1b9c34e3.hamish_nospam@yahoo.com> Is there a reason that the g.parser module doesn't use G_parser() for itself? general/g.parser/main.c: /* Detect request to get strings to translate from a file */ /* It comes BEFORE the filename to completely avoid confusion with parser.c behaviours */ if (argc >= 2 && (strcmp (argv[1], "-t") == 0)) { /* Turn on translation output */ translate_output = 1; } if (argc < 2 + translate_output) { fprintf(stderr, "Usage: %s [-t] [ ...]\n", argv[0]); return 1; } Hamish From neteler at itc.it Wed Nov 8 09:05:59 2006 From: neteler at itc.it (Markus Neteler) Date: Wed Nov 8 09:06:15 2006 Subject: [GRASS-dev] drop db.droptable man page? In-Reply-To: <20061108194717.5cec8660.hamish_nospam@yahoo.com> References: <20061108194717.5cec8660.hamish_nospam@yahoo.com> Message-ID: <20061108080559.GA6440@bartok.itc.it> Hamish, looks reasonable... Markus On Wed, Nov 08, 2006 at 07:47:17PM +1300, Hamish wrote: > Hi, > > > db.droptable's man page still gets generated even though the module has > been removed* from the Makefile. > > * rev 1.23: > http://freegis.org/cgi-bin/viewcvs.cgi/grass6/db/base/Makefile > > > is this patch correct? > > > Hamish > > > > Index: db/base/Makefile > =================================================================== > RCS file: /home/grass/grassrepository/grass6/db/base/Makefile,v > retrieving revision 1.27 > diff -u -r1.27 Makefile > --- db/base/Makefile 22 Sep 2006 16:30:51 -0000 1.27 > +++ db/base/Makefile 8 Nov 2006 06:45:30 -0000 > @@ -54,6 +54,6 @@ > $(BIN)/db.connect$(EXE): $(OBJDIR)/connect.o > $(CC) $(LDFLAGS) -o $@ $(OBJDIR)/connect.o $(FMODE_OBJ) $(LIBES) $(XDRLIB) $(MATHLIB) > > -#not used: db.createdb db.dropdb db.databases > -PROGRAMS = db.columns db.copy db.droptable db.describe db.drivers db.execute db.select db.tables db.connect > +#not used: db.createdb db.dropdb db.databases db.droptable > +PROGRAMS = db.columns db.copy db.describe db.drivers db.execute db.select db.tables db.connect > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Markus Neteler http://mpa.itc.it/markus/ ITC-irst - Centro per la Ricerca Scientifica e Tecnologica MPBA - Predictive Models for Biol. & Environ. Data Analysis Via Sommarive, 18 - 38050 Povo (Trento), Italy From glynn at gclements.plus.com Wed Nov 8 13:38:14 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Nov 8 13:38:16 2006 Subject: [GRASS-dev] d.redraw -> g.parser In-Reply-To: <20061108183154.0d45ad25.hamish_nospam@yahoo.com> References: <20061108183154.0d45ad25.hamish_nospam@yahoo.com> Message-ID: <17745.53174.466785.704577@cerise.gclements.plus.com> Hamish wrote: > currently d.redraw doesn't use the parser as it takes no options. > > For man pages, etc it is nice to use it. > > There is --ui to force the GUI in parser.c, but no --no-ui to avoid it. > And no enviro vars to control this either, AFAICT. What would --no-ui achieve? The GUI dialog should only be generated if you don't pass any arguments but the program has at least one required argument. However, currently it's up to the module to implement this. Modules which can be run without arguments should skip calling G_parser() if no arguments are given, e.g.: if (argc > 1 && G_parser(argc, argv)) exit(1); If necessary, this could be added to G_parser(); relying upon the module to do it saves G_parser() from having to determine whether there are any required arguments. Apart from that, the only use for a --no-ui switch which I can see is to force an error message (rather than a dialog) when one or more arguments are required but none are given. Or am I missing something? > Any problem with adding the --q flag to get the same effect? --q is for the user. If the user doesn't use --q, they presumably want their normal verbosity settings to be honoured. > -#GUI is not very useful here, commented: > -#if [ "$1" != "@ARGS_PARSED@" ] ; then > -# exec g.parser "$0" "$@" > -#fi > +#GUI is not very useful here, > +if [ "$1" != "@ARGS_PARSED@" ] ; then > + exec g.parser "$0" "$@" --q > +fi If you want an error message instead of a GUI when no arguments are given, you could use: if [ "$1" != "@ARGS_PARSED@" ] ; then if [ "$#" = 0 ] ; then exec g.parser "$0" "$@" --q else exec g.parser "$0" "$@" fi fi -- Glynn Clements From glynn at gclements.plus.com Wed Nov 8 14:04:10 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Nov 8 14:04:14 2006 Subject: [GRASS-dev] g.parser use G_parser()? In-Reply-To: <20061108204836.1b9c34e3.hamish_nospam@yahoo.com> References: <20061108204836.1b9c34e3.hamish_nospam@yahoo.com> Message-ID: <17745.54730.864396.994986@cerise.gclements.plus.com> Hamish wrote: > Is there a reason that the g.parser module doesn't use G_parser() for itself? It can't call G_parser() until it has set up all of the options and flags, but translate_output has to be set before it can do that. Even if that wasn't the case, there would be other issues, e.g. scripts being unable to have a -t flag, or being able to omit the option name for the the first argument. -- Glynn Clements From mlennert at club.worldonline.be Wed Nov 8 14:10:28 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Nov 8 14:09:37 2006 Subject: [GRASS-dev] Re: single-click zoom doesn't preserve aspect ratio In-Reply-To: <4550A0E1.3060509@club.worldonline.be> References: <45509FB4.5050808@club.worldonline.be> <4550A0E1.3060509@club.worldonline.be> Message-ID: <4551D744.4040603@club.worldonline.be> Moritz Lennert wrote: > Moritz Lennert wrote: >> Maciej Sieczka wrote: >>> Trying to switch to "Map fills display window" mode, I get an error: >>> >>> can't read "nsres": no such variable >>> can't read "nsres": no such variable >>> while executing >>> "expr round(abs($n-$s)/$nsres)" >>> (procedure "MapCanvas::currentzoom" line 27) >>> invoked from within >>> "MapCanvas::currentzoom $mon" >>> (procedure "MapCanvas::runprograms" line 24) >>> invoked from within >>> "MapCanvas::runprograms $mon [expr {$mymodified != 0}]" >>> (procedure "MapCanvas::drawmap" line 38) >>> invoked from within >>> "MapCanvas::drawmap $mon" >>> (procedure "MapCanvas::display_server" line 9) >>> invoked from within >>> "MapCanvas::display_server" >>> ("after" script) >> >> I can confirm this. Changing nsres and ewres (in the next line) to >> explore_nsres and explore_ewres apparently solves the problem for me, >> but I'm not sure whether this is the correct way to do it. Michael ? > > Sorry, forgot to include the patch: > > Index: mapcanvas.tcl > =================================================================== > RCS file: /grassrepository/grass6/gui/tcltk/gis.m/mapcanvas.tcl,v > retrieving revision 1.49 > diff -u -r1.49 mapcanvas.tcl > --- mapcanvas.tcl 4 Nov 2006 00:01:43 -0000 1.49 > +++ mapcanvas.tcl 7 Nov 2006 15:04:15 -0000 > @@ -969,8 +969,8 @@ > # Calculate the resolutions proportional to the map size > set explore_nsres [expr {1.0 * ($n - $s) / > $canvas_h($mon)}] > set explore_ewres [expr {1.0 * ($e - $w) / > $canvas_w($mon)}] > - set explore_rows [expr round(abs($n-$s)/$nsres)] > - set explore_cols [expr round(abs($e-$w)/$ewres)] > + set explore_rows [expr round(abs($n-$s)/$explore_nsres)] > + set explore_cols [expr round(abs($e-$w)/$explore_ewres)] > lappend expanded_region $explore_nsres $explore_ewres > $explore_rows $explore_cols > set region $expanded_region > } > Just comitted this fix. Moritz From michael.barton at asu.edu Wed Nov 8 15:47:50 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Nov 8 15:48:02 2006 Subject: [GRASS-dev] Re: windows binaries In-Reply-To: <20061108160519.360636a6.hamish_nospam@yahoo.com> Message-ID: Disclaimer: I only see a fragment of the entire post, and might misunderstand. D.vect.thematic does not require any particular driver. It uses d.vect (iterated over different theme values) to render the final map. This is why it can work with either an xmonitor or a TclTk canvas (the latter via the PNG driver and immediate rendering mode.) D.vect.thematic should become a C-module like d.vect.chart. But since I don't know C I simply wish. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Hamish > Date: Wed, 8 Nov 2006 16:05:19 +1300 > To: Paul Kelly > Cc: > Subject: Re: [GRASS-dev] Re: windows binaries > > Paul Kelly wrote: >> >> Didn't I read that d.vect.thematic needs the PNG driver to work. Have >> to confess that I'm not sure what it does - could it use ps.map? > > d.graph would be an easier path I think. > > > Hamish > > From mlennert at club.worldonline.be Wed Nov 8 16:05:14 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Nov 8 16:04:22 2006 Subject: [GRASS-dev] Re: windows binaries In-Reply-To: References: Message-ID: <4551F22A.5050009@club.worldonline.be> Michael Barton wrote: > Disclaimer: I only see a fragment of the entire post, and might > misunderstand. > > D.vect.thematic does not require any particular driver. It uses d.vect > (iterated over different theme values) to render the final map. > > This is why it can work with either an xmonitor or a TclTk canvas (the > latter via the PNG driver and immediate rendering mode.) It won't work in immediate rendering mode since, as you say, it calls d.vect several times and in immediate rendering mode each call creates a new map from scratch, thus losing the overlaying of the different classes. This is why, in order to make it work with gis.m, it is (as far as I know) the only module using the PNG driver, and not immediate rendering. However, the PNG driver is not available in wingrass. > D.vect.thematic should become a C-module like d.vect.chart. But since I > don't know C I simply wish. It is high on my priority list as it will be a convincing argument for my colleagues if I can present them a nice module for thematic mapping. Up to now, I was thinking neither in terms of ps.map, nor in terms of d.graph, but rather in terms of direct access to rendering. In my current understanding this means finding out how d.vect works in detail and applying that to d.vect.thematic. But maybe using do_poly() and do_color() from d.graph might be another solution, but I will have to look at these in detail to understand. I think I will try to quite quickly draw up a description of what I am aiming for and then ask y'all to advise me at how to do it. Moritz > > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > >> From: Hamish >> Date: Wed, 8 Nov 2006 16:05:19 +1300 >> To: Paul Kelly >> Cc: >> Subject: Re: [GRASS-dev] Re: windows binaries >> >> Paul Kelly wrote: >>> Didn't I read that d.vect.thematic needs the PNG driver to work. Have >>> to confess that I'm not sure what it does - could it use ps.map? >> d.graph would be an easier path I think. >> >> >> Hamish >> >> > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From ychemin at gmail.com Wed Nov 8 16:43:56 2006 From: ychemin at gmail.com (Yann Chemin) Date: Wed Nov 8 16:43:59 2006 Subject: [GRASS-dev] how to add metadata in a raster file? Message-ID: <6278879c0611080743n5eb7ddd6jcf30db75cc482fde@mail.gmail.com> Hello, while modifying a Landsat7 import module to read data from the .met (metadata) file, i wondered how i could store some of this useful information as appendix to the raster layer created. What is the way to do that in C? thanks, Yann From michael.barton at asu.edu Wed Nov 8 17:05:33 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Nov 8 17:05:48 2006 Subject: [GRASS-dev] Re: windows binaries In-Reply-To: <4551F22A.5050009@club.worldonline.be> Message-ID: Moritz, I looked at the script and you are indeed correct. I guess I'd forgotten about this. Why is the PNG driver not available in wingrass when immediate rendering works (AFAIK using the same underlying driver code and the PNG driver)? I could rewrite d.vect.thematic as a TclTk module, but am reluctant to do so because it would make it unavailable to people not using the TclTk GUI--and make it more work to port to a new GUI platform. I very much appreciate your efforts to start a C version. I won't be able to advise you on coding, but might be able to offer some more general advice. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Moritz Lennert > Date: Wed, 08 Nov 2006 16:05:14 +0100 > To: Michael Barton > Cc: Hamish , Paul Kelly > , > Subject: Re: [GRASS-dev] Re: windows binaries > > Michael Barton wrote: >> Disclaimer: I only see a fragment of the entire post, and might >> misunderstand. >> >> D.vect.thematic does not require any particular driver. It uses d.vect >> (iterated over different theme values) to render the final map. >> >> This is why it can work with either an xmonitor or a TclTk canvas (the >> latter via the PNG driver and immediate rendering mode.) > > It won't work in immediate rendering mode since, as you say, it calls > d.vect several times and in immediate rendering mode each call creates a > new map from scratch, thus losing the overlaying of the different > classes. This is why, in order to make it work with gis.m, it is (as far > as I know) the only module using the PNG driver, and not immediate > rendering. However, the PNG driver is not available in wingrass. > >> D.vect.thematic should become a C-module like d.vect.chart. But since I >> don't know C I simply wish. > > It is high on my priority list as it will be a convincing argument for > my colleagues if I can present them a nice module for thematic mapping. > > Up to now, I was thinking neither in terms of ps.map, nor in terms of > d.graph, but rather in terms of direct access to rendering. In my > current understanding this means finding out how d.vect works in detail > and applying that to d.vect.thematic. > > But maybe using do_poly() and do_color() from d.graph might be another > solution, but I will have to look at these in detail to understand. > > I think I will try to quite quickly draw up a description of what I am > aiming for and then ask y'all to advise me at how to do it. > > Moritz > >> >> Michael >> __________________________________________ >> Michael Barton, Professor of Anthropology >> School of Human Evolution & Social Change >> Center for Social Dynamics & Complexity >> Arizona State University >> >> phone: 480-965-6213 >> fax: 480-965-7671 >> www: http://www.public.asu.edu/~cmbarton >> >> >> >>> From: Hamish >>> Date: Wed, 8 Nov 2006 16:05:19 +1300 >>> To: Paul Kelly >>> Cc: >>> Subject: Re: [GRASS-dev] Re: windows binaries >>> >>> Paul Kelly wrote: >>>> Didn't I read that d.vect.thematic needs the PNG driver to work. Have >>>> to confess that I'm not sure what it does - could it use ps.map? >>> d.graph would be an easier path I think. >>> >>> >>> Hamish >>> >>> >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev > From mlennert at club.worldonline.be Wed Nov 8 17:26:31 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Nov 8 17:25:39 2006 Subject: [GRASS-dev] Re: windows binaries In-Reply-To: References: Message-ID: <45520537.1090205@club.worldonline.be> Michael Barton wrote: > Moritz, > > I looked at the script and you are indeed correct. I guess I'd forgotten > about this. Why is the PNG driver not available in wingrass when immediate > rendering works (AFAIK using the same underlying driver code and the PNG > driver)? Direct rendering does not use the PNG monitor driver which uses UNIX sockets, but renders directly. AFAIU, in MS Windows we don't have the UNIX sockets that the monitors depend on. > I could rewrite d.vect.thematic as a TclTk module, but am reluctant > to do so because it would make it unavailable to people not using the TclTk > GUI--and make it more work to port to a new GUI platform. I agree. > > I very much appreciate your efforts to start a C version. I won't be able to > advise you on coding, but might be able to offer some more general advice. Thanks. Moritz > > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics and Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > >> From: Moritz Lennert >> Date: Wed, 08 Nov 2006 16:05:14 +0100 >> To: Michael Barton >> Cc: Hamish , Paul Kelly >> , >> Subject: Re: [GRASS-dev] Re: windows binaries >> >> Michael Barton wrote: >>> Disclaimer: I only see a fragment of the entire post, and might >>> misunderstand. >>> >>> D.vect.thematic does not require any particular driver. It uses d.vect >>> (iterated over different theme values) to render the final map. >>> >>> This is why it can work with either an xmonitor or a TclTk canvas (the >>> latter via the PNG driver and immediate rendering mode.) >> It won't work in immediate rendering mode since, as you say, it calls >> d.vect several times and in immediate rendering mode each call creates a >> new map from scratch, thus losing the overlaying of the different >> classes. This is why, in order to make it work with gis.m, it is (as far >> as I know) the only module using the PNG driver, and not immediate >> rendering. However, the PNG driver is not available in wingrass. >> >>> D.vect.thematic should become a C-module like d.vect.chart. But since I >>> don't know C I simply wish. >> It is high on my priority list as it will be a convincing argument for >> my colleagues if I can present them a nice module for thematic mapping. >> >> Up to now, I was thinking neither in terms of ps.map, nor in terms of >> d.graph, but rather in terms of direct access to rendering. In my >> current understanding this means finding out how d.vect works in detail >> and applying that to d.vect.thematic. >> >> But maybe using do_poly() and do_color() from d.graph might be another >> solution, but I will have to look at these in detail to understand. >> >> I think I will try to quite quickly draw up a description of what I am >> aiming for and then ask y'all to advise me at how to do it. >> >> Moritz >> >>> Michael >>> __________________________________________ >>> Michael Barton, Professor of Anthropology >>> School of Human Evolution & Social Change >>> Center for Social Dynamics & Complexity >>> Arizona State University >>> >>> phone: 480-965-6213 >>> fax: 480-965-7671 >>> www: http://www.public.asu.edu/~cmbarton >>> >>> >>> >>>> From: Hamish >>>> Date: Wed, 8 Nov 2006 16:05:19 +1300 >>>> To: Paul Kelly