From glynn at gclements.plus.com Sun Jul 1 04:35:19 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jul 1 04:35:22 2007 Subject: [GRASS-dev] Re: [Quantum GIS] #736: Some GRASS commands broken In-Reply-To: <20070629130018.GA15214@bartok.itc.it> References: <034.c56263f8c39bd2f3f2a31fbbd544909d@qgis.org> <20070629130018.GA15214@bartok.itc.it> Message-ID: <18055.4839.961477.319684@cerise.gclements.plus.com> Markus Neteler wrote: > a colleague has found some strange problems in winQGIS/GRASS, signalled > to the QGIS team. I wonder if the problem could be GRASS related. > > Hints welcome, > > r.median base=CEA_cat@CEA_dati cover=CEA_aspect@CEA_dati > > output=aspect_median > > > > Illegal filename. Character <'> not allowed. r.median invokes r.stats via system(), using a single quote: strcpy (command, "r.stats -a '"); strcat (command, G_fully_qualified_name (basemap, base_mapset)); strcat (command, ","); strcat (command, G_fully_qualified_name (covermap, cover_mapset)); strcat (command, "'"); /* strcpy (command,"cat /tmp/t"); */ stats_fd = popen (command, "r"); sprintf (command, "r.reclass i='%s' o='%s'", G_fully_qualified_name (basemap, base_mapset), outmap); system() uses the platform's shell: /bin/sh on Unix, cmd.exe on Windows NT/2K/XP, command.com on 95/98/ME. Single quotes won't work with the Windows shells. r.average doesn't quote the map names, and uses double quotes around the output filename: sprintf (command, "%s -anC input=%s,%s fs=space > \"%s\"", STATS, basemap->answer, covermap->answer, tempfile1); Using double quotes should suffice so long as the map name doesn't contain $ or ` (a double quote would also be problematic, but isn't legal in map names). Ultimately, we need a Windows implementation of G_spawn_ex(), so that we can avoid the shell altogether. -- Glynn Clements From glynn at gclements.plus.com Sun Jul 1 04:43:06 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jul 1 04:43:09 2007 Subject: [GRASS-dev] cvs compilation problem - nviz? In-Reply-To: <4686BAB0.3070908@laserdata.at> References: <4686BAB0.3070908@laserdata.at> Message-ID: <18055.5306.430438.363624@cerise.gclements.plus.com> Volker Wichmann wrote: > almost similar to a recent post of Helena, I have problems compiling cvs > on a fedora 7 / NVIDIA machine. But I get another error: > Errors in: > /usr/local/src/grass-cvs/grass6/lib/ogsf > /usr/local/src/grass-cvs/grass6/visualization/nviz > > Changing to /lib/ogsf and running make: > gcc -I/usr/local/src/grass-cvs/grass6/dist.i686-pc-linux-gnu/include -g > -O2 -fPIC -DPACKAGE=\""grasslibs"\" -I/usr/local/include > -DPACKAGE=\""grasslibs"\" -I/usr/local/include/ffmpeg > -I/usr/local/src/grass-cvs/grass6/dist.i686-pc-linux-gnu/include \ > -o OBJ.i686-pc-linux-gnu/gsd_img_ppm.o -c gsd_img_ppm.c > In file included from gsd_img_ppm.c:20: > /usr/local/include/ffmpeg/avcodec.h:2252: warning: "ImgReSampleContext" is deprecated > /usr/local/include/ffmpeg/avcodec.h:2258: warning: "ImgReSampleContext" is deprecated > gsd_img_ppm.c: In function "gsd_init_mpeg": > gsd_img_ppm.c:122: error: "mpeg1video_encoder" undeclared (first use in this function) > gsd_img_ppm.c:122: error: (Each undeclared identifier is reported only once > gsd_img_ppm.c:122: error: for each function it appears in.) > make: *** [OBJ.i686-pc-linux-gnu/gsd_img_ppm.o] Error 1 > > As far as I can tell ffmpeg is installed correctly (mpeg1video_encoder > is defined in config.h, no errors) ... any tip? It should be declared in avcodec.h: extern AVCodec mpeg1video_encoder; I don't have a config.h in the ffmpeg include directory, and gsd_image_ppm.c doesn't #include it (in fact, if it did have "#include ", there's no guarantee that it would be ffmpeg's config.h which was included; config.h is a rather common name). It appears that your version of ffmpeg isn't compatible with the OGSF library; I can only suggest removing --with-ffmpeg from your configure command. -- Glynn Clements From michael.barton at asu.edu Sun Jul 1 08:20:41 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Jul 1 08:20:52 2007 Subject: [GRASS-dev] reading georeferencing tables for GRASS Message-ID: Paul and Glynn, I'm ready to move ahead and try to create PROJ.4 strings in the wxgrass location wizard, but am confused about the parameters tables in $GISBASE/etc. It looks kind of like proj-params.table and maybe proj-units.table are the files used by g.setproj and that the others (datum.table, datumtranform.table, ellipse.table, and projections) are there to help create a PROJ.4 string for GRASS. Is this correct? If this is the case, I'm not quite sure how to use these. The datumtransforms.table seems the most straightforward--just search for the line with a projection that matches the location projection and read of the datum transformation parameters ("towgs84=24,-130,-92") as a single PROJ.4 string to add on to the PROJ.4 string of the location projection. I do use projections? That is, choose the projection code that is appropriate for the description that I want. the datum.table and ellipse.table are more confusing. The datum table seems to include ellipsoids, but only a subset and does not include the ellipsoid parameters. I can look up the ellipsoid in the ellipse.table file that matches the ellipsoid in the datum.table file and grab the ellipsoid parameters. But what about all the ellipsoids that are not in the datum.table file? Can they be used? It seems that, hypothetically, you could use a different ellipsoid with a datum besides the one associated with it in the datum.table file. But I don't know why those particular ellipsoids are in the datum.table file. Are these simply the most common for that datum or do I *need* to use the ellipsoid associated with that datum? I hope that you can help me get it clear how these 2 tables are related so that I can begin to parse them into a PROJ.4 string. Thanks Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070630/ebc27517/attachment.html From glynn at gclements.plus.com Sun Jul 1 08:41:14 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jul 1 08:41:16 2007 Subject: [GRASS-dev] DBF driver: semicolon and select troubles In-Reply-To: <4683B8E4.8090606@itc.it> References: <4683B8E4.8090606@itc.it> Message-ID: <18055.19594.101910.617117@cerise.gclements.plus.com> Markus Neteler wrote: > Hi, > > when having a semicolon at the end of a statement, the DBF driver gives > an error: > > echo "select start_map, end_map, start_mp, start_off, end_mp, end_off, > lid from route_lrs where lcat = 1;" | db.select > DBMI-DBF driver error: > SQL parser error: syntax error, unexpected $undefined, expecting $end > processing ';' > in statement: > select start_map, end_map, start_mp, start_off, end_mp, end_off, lid > from route_lrs where lcat = 1; > Error in db_open_select_cursor() > > This is a problem, because other drivers seem to require it (see > v.lrs.label). > > Without semicolon, it works: > echo "select start_map, end_map, start_mp, start_off, end_mp, end_off, > lid from route_lrs where lcat = 1" | db.select > start_map|end_map|start_mp|start_off|end_mp|end_off|lid > 185.206836|596.743043|6|0|7|0|22 > > How to enable the DBF driver to also accept the semicolon here? Untested: --- lib/db/sqlp/yac.y 4 Mar 2007 08:34:44 -0000 1.27 +++ lib/db/sqlp/yac.y 1 Jul 2007 06:39:47 -0000 @@ -102,6 +102,7 @@ | y_select | y_update | y_delete + | y_sql ';' ; y_alter: -- Glynn Clements From neteler at itc.it Sun Jul 1 10:55:23 2007 From: neteler at itc.it (Markus Neteler) Date: Sun Jul 1 10:55:26 2007 Subject: [GRASS-dev] DBF driver: semicolon and select troubles In-Reply-To: <18055.19594.101910.617117@cerise.gclements.plus.com> References: <4683B8E4.8090606@itc.it> <18055.19594.101910.617117@cerise.gclements.plus.com> Message-ID: <11380125.post@talk.nabble.com> Glynn Clements wrote: > > > Markus Neteler wrote: > >> Hi, >> >> when having a semicolon at the end of a statement, the DBF driver gives >> an error: >> >> echo "select start_map, end_map, start_mp, start_off, end_mp, end_off, >> lid from route_lrs where lcat = 1;" | db.select >> DBMI-DBF driver error: >> SQL parser error: syntax error, unexpected $undefined, expecting $end >> processing ';' >> in statement: >> select start_map, end_map, start_mp, start_off, end_mp, end_off, lid >> from route_lrs where lcat = 1; >> Error in db_open_select_cursor() >> >> This is a problem, because other drivers seem to require it (see >> v.lrs.label). >> >> Without semicolon, it works: >> echo "select start_map, end_map, start_mp, start_off, end_mp, end_off, >> lid from route_lrs where lcat = 1" | db.select >> start_map|end_map|start_mp|start_off|end_mp|end_off|lid >> 185.206836|596.743043|6|0|7|0|22 >> >> How to enable the DBF driver to also accept the semicolon here? > > Untested: > > --- lib/db/sqlp/yac.y 4 Mar 2007 08:34:44 -0000 1.27 > +++ lib/db/sqlp/yac.y 1 Jul 2007 06:39:47 -0000 > @@ -102,6 +102,7 @@ > | y_select > | y_update > | y_delete > + | y_sql ';' > ; > > y_alter: > > -- > Glynn Clements > Excellent, works. I have added it to 6.2.2-CVS, too. Unrelated: I get these warnings on Mandriva: bison -y -d -v yac.y yac.y:74.15-19: Warnung: symbol TABLE redeclared yac.y:75.8-11: Warnung: symbol DROP redeclared yac.y:75.13-17: Warnung: symbol TABLE redeclared bison --version bison (GNU Bison) 2.3 It this harmful? Markus -- View this message in context: http://www.nabble.com/DBF-driver%3A-semicolon-and-select-troubles-tf3994416.html#a11380125 Sent from the Grass - Dev mailing list archive at Nabble.com. From neteler at itc.it Sun Jul 1 21:05:09 2007 From: neteler at itc.it (Markus Neteler) Date: Sun Jul 1 21:05:11 2007 Subject: [GRASS-dev] time to release 6.2.2 Message-ID: <20070701190509.GA28159@bartok.itc.it> Hi, during the testing period of 6.2.2-RC1 we got the following issues fixed: * DBF driver: fix semicolon problem (Glynn Clements) * SQLite transactions to speed up execute (Antonio Galea) * GUI startup: fixes browsing for EPSG file not updating path to it (Maris Nartiss) * GUI startup: fixes browsing for new location path (Maris Nartiss) * nviz compilation fix for MacOSX (Markus Neteler) * r.in.gdalwarp: remove bashisms (Hamish Bowman) * v.dissolve: fix for DBMI error if input map is specified with @mapset (Markus Neteler) * v.lrs.* fixes backported + new documentation (Markus Neteler) * Czech translation updated (Jachym Cepicky) See http://grass.gdf-hannover.de/wiki/GRASS_6.2_Feature_Plan#Fixed_post-RC1 I would suggest to release 6.2.2 officially the next days if nobody objects. Markus -- Markus Neteler http://mpa.itc.it/markus/ FBK-irst - Centro per la Ricerca Scientifica e Tecnologica MPBA - Predictive Models for Biol. & Environ. Data Analysis Via Sommarive, 18 - 38050 Povo (Trento), Italy From paul-grass at stjohnspoint.co.uk Sun Jul 1 22:13:48 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sun Jul 1 22:13:53 2007 Subject: [GRASS-dev] time to release 6.2.2 In-Reply-To: <20070701190509.GA28159@bartok.itc.it> References: <20070701190509.GA28159@bartok.itc.it> Message-ID: Hello Markus As I noted before (http://grass.itc.it/pipermail/grass-dev/2007-May/031699.html) Grass 6.2.2 seems to already be tagged (as grass_6_2_2) in CVS. I wonder how/when this happened, but it was definitely before 28th May as that was when I sent that e-mail. I still think it is a good idea to include the date of releases in the tag name, less confusion that way, e.g. release_20070702_grass_6_2_2 - what do you think? Or is there any other way of telling from CVS on what date the tag was created? Paul On Sun, 1 Jul 2007, Markus Neteler wrote: > Hi, > > during the testing period of 6.2.2-RC1 we got the following > issues fixed: > * DBF driver: fix semicolon problem (Glynn Clements) > * SQLite transactions to speed up execute (Antonio Galea) > * GUI startup: fixes browsing for EPSG file not updating path to it (Maris Nartiss) > * GUI startup: fixes browsing for new location path (Maris Nartiss) > * nviz compilation fix for MacOSX (Markus Neteler) > * r.in.gdalwarp: remove bashisms (Hamish Bowman) > * v.dissolve: fix for DBMI error if input map is specified with @mapset (Markus Neteler) > * v.lrs.* fixes backported + new documentation (Markus Neteler) > * Czech translation updated (Jachym Cepicky) > > See > http://grass.gdf-hannover.de/wiki/GRASS_6.2_Feature_Plan#Fixed_post-RC1 > > I would suggest to release 6.2.2 officially the next days if nobody > objects. > > Markus > -- > Markus Neteler http://mpa.itc.it/markus/ > FBK-irst - Centro per la Ricerca Scientifica e Tecnologica > MPBA - Predictive Models for Biol. & Environ. Data Analysis > Via Sommarive, 18 - 38050 Povo (Trento), Italy > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > > From hamish_nospam at yahoo.com Mon Jul 2 02:11:04 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jul 2 02:11:07 2007 Subject: [GRASS-dev] time to release 6.2.2 In-Reply-To: <20070701190509.GA28159@bartok.itc.it> Message-ID: <477146.14550.qm@web52706.mail.re2.yahoo.com> Markus: > I would suggest to release 6.2.2 officially the next days if nobody > objects. Hi, While at sea I found a glitch with v.in.gpsbabel on the Mac which I'd like to fix before release. (unportable call to "stat -c%s" for file size during XML parsing; replaced with "wc -c") I've a huge pile of data, unpacking, and gear repairs stacked up in the middle of my lab to deal with, but I'll try to get the fix into CVS later today or tomorrow. Hamish ____________________________________________________________________________________ Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367 From glynn at gclements.plus.com Mon Jul 2 05:26:14 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jul 2 05:26:21 2007 Subject: [GRASS-dev] reading georeferencing tables for GRASS In-Reply-To: References: Message-ID: <18056.28758.642557.955719@cerise.gclements.plus.com> Michael Barton wrote: > I'm ready to move ahead and try to create PROJ.4 strings in the wxgrass > location wizard, but am confused about the parameters tables in > $GISBASE/etc. > > It looks kind of like proj-params.table and maybe proj-units.table are the > files used by g.setproj. Yes. These files contain data which was previously hard-coded in lib/gis/geo_init.c. They determine the set of available projections, along with the parameters will be prompted for when you select a particular projection. > and that the others (datum.table, > datumtranform.table, ellipse.table, and projections) are there to help > create a PROJ.4 string for GRASS. Is this correct? At least datum.table and ellipse.table are used by libgis functions which don't require proj, e.g. G_get_datum_by_name() and G_get_ellipsoid_by_name(). > If this is the case, I'm not quite sure how to use these. All of the tables essentially describe choices which are made by the user. > The datumtransforms.table seems the most straightforward--just search for > the line with a projection that matches the location projection and read of > the datum transformation parameters ("towgs84=24,-130,-92") as a single > PROJ.4 string to add on to the PROJ.4 string of the location projection. The first column of datumtransform.table is a datum name. Many datums have multiple entries (e.g. nad27 has 9 entries). The idea is to select all entries matching the desired datum, display a list of the corresponding names and/or descriptions (columns 3 and 4) to the user, then use the PROJ string (column 2) for the entry which the user selects. > I do use projections? That is, choose the projection code that is > appropriate for the description that I want. Display the descriptions (column 2) to the users, record the GRASS/PROJ code (column 1) for the entry which the user selects. > the datum.table and ellipse.table are more confusing. The datum table seems > to include ellipsoids, but only a subset and does not include the ellipsoid > parameters. I can look up the ellipsoid in the ellipse.table file that > matches the ellipsoid in the datum.table file and grab the ellipsoid > parameters. But what about all the ellipsoids that are not in the > datum.table file? Can they be used? The user can choose to use an ellipsoid without choosing a datum. If a datum is chosen, then the ellipsoid is determined by the datum; if no datum is chosen, the ellipsoid must be chosen manually. Also, the user could choose a named ellipsoid along with a custom datum (i.e. a 3- or 7-parameter transform specified by its coefficients), or a custom ellipsoid specified by its equatorial axis and either the polar axis, flattening, or eccentricity-squared with either a custom datum or no datum. > It seems that, hypothetically, you could use a different ellipsoid with a > datum besides the one associated with it in the datum.table file. But I > don't know why those particular ellipsoids are in the datum.table file. Are > these simply the most common for that datum or do I *need* to use the > ellipsoid associated with that datum? AFAIK, it doesn't make any sense to use an ellipsoid other than the one associated with the datum. -- Glynn Clements From glynn at gclements.plus.com Mon Jul 2 05:31:39 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jul 2 05:31:41 2007 Subject: [GRASS-dev] DBF driver: semicolon and select troubles In-Reply-To: <11380125.post@talk.nabble.com> References: <4683B8E4.8090606@itc.it> <18055.19594.101910.617117@cerise.gclements.plus.com> <11380125.post@talk.nabble.com> Message-ID: <18056.29083.160844.69202@cerise.gclements.plus.com> Markus Neteler wrote: > Unrelated: I get these warnings on Mandriva: > > bison -y -d -v yac.y > yac.y:74.15-19: Warnung: symbol TABLE redeclared > yac.y:75.8-11: Warnung: symbol DROP redeclared > yac.y:75.13-17: Warnung: symbol TABLE redeclared > > bison --version > bison (GNU Bison) 2.3 > > It this harmful? I don't think so. They've always been there, and they're due to: 63 %token DROP 73 %token ALTER TABLE 74 %token CREATE TABLE 75 %token DROP TABLE DROP is defined on 63 then defined again on 75. TABLE is defined on 73 then again on 74 and 75. A %token directive with multiple tokens is exactly equivalent to multiple %token directives. You can eliminate the warnings with: --- lib/db/sqlp/yac.y 1 Jul 2007 08:52:49 -0000 1.28 +++ lib/db/sqlp/yac.y 2 Jul 2007 03:30:05 -0000 @@ -71,8 +71,7 @@ %token OR %token NOT %token ALTER TABLE -%token CREATE TABLE -%token DROP TABLE +%token CREATE %token NULL_VALUE %token VARCHAR %token INT -- Glynn Clements From michael.barton at asu.edu Mon Jul 2 06:48:47 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Jul 2 06:49:02 2007 Subject: [GRASS-dev] time to release 6.2.2 In-Reply-To: <20070701190509.GA28159@bartok.itc.it> Message-ID: OK by me. Michael On 7/1/07 12:05 PM, "Markus Neteler" wrote: > Hi, > > during the testing period of 6.2.2-RC1 we got the following > issues fixed: > * DBF driver: fix semicolon problem (Glynn Clements) > * SQLite transactions to speed up execute (Antonio Galea) > * GUI startup: fixes browsing for EPSG file not updating path to it (Maris > Nartiss) > * GUI startup: fixes browsing for new location path (Maris Nartiss) > * nviz compilation fix for MacOSX (Markus Neteler) > * r.in.gdalwarp: remove bashisms (Hamish Bowman) > * v.dissolve: fix for DBMI error if input map is specified with @mapset > (Markus Neteler) > * v.lrs.* fixes backported + new documentation (Markus Neteler) > * Czech translation updated (Jachym Cepicky) > > See > http://grass.gdf-hannover.de/wiki/GRASS_6.2_Feature_Plan#Fixed_post-RC1 > > I would suggest to release 6.2.2 officially the next days if nobody > objects. > > Markus __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From neteler at itc.it Mon Jul 2 10:45:31 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Jul 2 10:45:33 2007 Subject: [GRASS-dev] time to release 6.2.2 In-Reply-To: References: <20070701190509.GA28159@bartok.itc.it> Message-ID: <4688BB2B.8030908@itc.it> Paul Kelly wrote on 07/01/2007 10:13 PM: > Hello Markus > As I noted before > (http://grass.itc.it/pipermail/grass-dev/2007-May/031699.html) Grass > 6.2.2 seems to already be tagged (as grass_6_2_2) in CVS. I wonder > how/when this happened, but it was definitely before 28th May as that > was when I sent that e-mail. Mea culpa! I want to shift this tag now to remove the mess. The "enter" key was too close, I hit it before starting thinking. Sorry. > I still think it is a good idea to include the date of releases in the > tag name, less confusion that way, e.g. release_20070702_grass_6_2_2 - > what do you think? Or is there any other way of telling from CVS on > what date the tag was created? I don't know but I remember that someone (Glynn?) suggested to NOT include the date so that it wasn't done any more. Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From paul-grass at stjohnspoint.co.uk Mon Jul 2 11:33:51 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Jul 2 11:33:54 2007 Subject: [GRASS-dev] time to release 6.2.2 In-Reply-To: <4688BB2B.8030908@itc.it> References: <20070701190509.GA28159@bartok.itc.it> <4688BB2B.8030908@itc.it> Message-ID: On Mon, 2 Jul 2007, Markus Neteler wrote: > Paul Kelly wrote on 07/01/2007 10:13 PM: >> I still think it is a good idea to include the date of releases in the >> tag name, less confusion that way, e.g. release_20070702_grass_6_2_2 - >> what do you think? Or is there any other way of telling from CVS on >> what date the tag was created? > I don't know but I remember that someone (Glynn?) suggested to NOT > include the > date so that it wasn't done any more. Well that's fine then if it has been discussed - I guess I just missed that when it happened but there were I'm sure good reasons for it then. FWIW my reasons for keeping with the old-style tags would be (a) less likely to create a tag by accident as you're putting a meaningful date into it and have to stop and think about that and (b) easy quick reference looking back through the web-based CVS browser as to the dates of the earlier releases. But neither of those are particularly important. Good luck in shifting the tag! Paul From grass-codei at wald.intevation.org Mon Jul 2 18:33:33 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Mon Jul 2 18:32:30 2007 Subject: [GRASS-dev] [grass-code I][437] Duplicated option description in r.bilinear Message-ID: <20070702163333.0582D400E4@pyrosoma.intevation.org> code I item #437, was opened at 2007-07-02 18:33 Status: Open Priority: 3 Submitted By: Carlos D?vila (carluti) Assigned to: Nobody (None) Summary: Duplicated option description in r.bilinear Issue type: module bug Issue status: None GRASS version: CVS HEAD GRASS component: raster Operating system: Linux Operating system version: debian testing GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: r.bilinear has the same description for two different options: Parameters: *north*=float specific input value to be assigned to the *north and/or south* poles for longitude-latitude grids *east*=float specific input value to be assigned to the *north and/or south* poles for longitude-latitude grids Is it a copy/paste error? ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=437&group_id=21 From neteler at itc.it Mon Jul 2 18:55:12 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Jul 2 18:55:14 2007 Subject: [GRASS-dev] time to release 6.2.2 In-Reply-To: References: <20070701190509.GA28159@bartok.itc.it> <4688BB2B.8030908@itc.it> Message-ID: <46892DF0.2000003@itc.it> Paul Kelly wrote on 07/02/2007 11:33 AM: > On Mon, 2 Jul 2007, Markus Neteler wrote: > >> Paul Kelly wrote on 07/01/2007 10:13 PM: >>> I still think it is a good idea to include the date of releases in the >>> tag name, less confusion that way, e.g. release_20070702_grass_6_2_2 - >>> what do you think? Or is there any other way of telling from CVS on >>> what date the tag was created? >> I don't know but I remember that someone (Glynn?) suggested to NOT >> include the >> date so that it wasn't done any more. > > Well that's fine then if it has been discussed - I guess I just missed > that when it happened but there were I'm sure good reasons for it > then. FWIW my reasons for keeping with the old-style tags would be (a) > less likely to create a tag by accident as you're putting a meaningful > date into it and have to stop and think about that and (b) easy quick > reference looking back through the web-based CVS browser as to the > dates of the earlier releases. > > But neither of those are particularly important. Good luck in shifting > the tag! > I found this documentation: http://cvsnt.org/manual/html/Modifying-tags.html Anyone with experience...? thanks Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From cdavilam at jemila.jazztel.es Mon Jul 2 19:04:59 2007 From: cdavilam at jemila.jazztel.es (=?ISO-8859-15?Q?Carlos_D=E1vila?=) Date: Mon Jul 2 19:02:23 2007 Subject: [GRASS-dev] Some questions about standardization Message-ID: <4689303B.4050604@jemila.jazztel.es> Hello all I would like to get some feedback about the changes I'm doing to standardize. As some questions in the air do not get answers I'm following what is in wiki, but I wouldn't like to bother anyone with the changes. I need some help to continue with further changes. As I'm not programmer I don't know well what can be changed in code and what can't, so I ask you some cases: a) %s: can't open tempfile -> Unable to open temporary file <%s> (does it affect where is the %s?) b) can't open raster map <%s> in mapset %s -> Unable to open raster map <%s> (Can I drop last %s without problems?) c) How can I pass from "Unable to open the temporary file." to "Unable to open temporary file <%s>"? E.g. from /display/d.text.freetype/main.c: tmpfile = G_tempfile(); if(!(fp = fopen(tmpfile, "w"))) error(_("Unable to write the temporary file")); Regards Carlos From glynn at gclements.plus.com Mon Jul 2 21:11:52 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jul 2 21:11:54 2007 Subject: [GRASS-dev] time to release 6.2.2 In-Reply-To: <4688BB2B.8030908@itc.it> References: <20070701190509.GA28159@bartok.itc.it> <4688BB2B.8030908@itc.it> Message-ID: <18057.19960.314582.189066@cerise.gclements.plus.com> Markus Neteler wrote: > > I still think it is a good idea to include the date of releases in the > > tag name, less confusion that way, e.g. release_20070702_grass_6_2_2 - > > what do you think? Or is there any other way of telling from CVS on > > what date the tag was created? > > I don't know but I remember that someone (Glynn?) suggested to NOT > include the date so that it wasn't done any more. I don't have any recollection of that. -- Glynn Clements From glynn at gclements.plus.com Mon Jul 2 21:22:05 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jul 2 21:22:08 2007 Subject: [GRASS-dev] time to release 6.2.2 In-Reply-To: <46892DF0.2000003@itc.it> References: <20070701190509.GA28159@bartok.itc.it> <4688BB2B.8030908@itc.it> <46892DF0.2000003@itc.it> Message-ID: <18057.20573.933692.445915@cerise.gclements.plus.com> Markus Neteler wrote: > >>> I still think it is a good idea to include the date of releases in the > >>> tag name, less confusion that way, e.g. release_20070702_grass_6_2_2 - > >>> what do you think? Or is there any other way of telling from CVS on > >>> what date the tag was created? > >> I don't know but I remember that someone (Glynn?) suggested to NOT > >> include the > >> date so that it wasn't done any more. > > > > Well that's fine then if it has been discussed - I guess I just missed > > that when it happened but there were I'm sure good reasons for it > > then. FWIW my reasons for keeping with the old-style tags would be (a) > > less likely to create a tag by accident as you're putting a meaningful > > date into it and have to stop and think about that and (b) easy quick > > reference looking back through the web-based CVS browser as to the > > dates of the earlier releases. > > > > But neither of those are particularly important. Good luck in shifting > > the tag! > > I found this documentation: > http://cvsnt.org/manual/html/Modifying-tags.html > > Anyone with experience...? If you want to discard the existing grass_6_2_2 tag and tag the current version: cvs rtag -d grass_6_2_2 grass6 cvs tag -c release_20070702_grass_6_2_2 If you just want to rename the existing tag, ignoring any updates on the branch: cvs rtag -r grass_6_2_2 release_20070702_grass_6_2_2 grass6 cvs rtag -d grass_6_2_2 grass6 -- Glynn Clements From grass-coder at wald.intevation.org Mon Jul 2 22:06:45 2007 From: grass-coder at wald.intevation.org (grass-coder@wald.intevation.org) Date: Mon Jul 2 22:05:36 2007 Subject: [GRASS-dev] [grass-code R][438] min:max options for r.recode Message-ID: <20070702200645.6155F400D3@pyrosoma.intevation.org> code R item #438, was opened at 2007-07-02 20:06 Status: Open Priority: 3 Submitted By: Carlos Grohmann (guano) Assigned to: Nobody (None) Summary: min:max options for r.recode Issue status: None GRASS component: raster Operating system: Linux Operating system version: Initial Comment: It would be really great if r.recode had a flag/option where the min:max:0:255 operation would automatically performed. This is a very useful option. Also, if the keywords "min" and "max" could be included as permitted in the rules, much time would be saved. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=188&aid=438&group_id=21 From wichmann at laserdata.at Mon Jul 2 22:09:46 2007 From: wichmann at laserdata.at (Volker Wichmann) Date: Mon Jul 2 22:10:50 2007 Subject: [GRASS-dev] cvs compilation problem - nviz? In-Reply-To: <18055.5306.430438.363624@cerise.gclements.plus.com> References: <4686BAB0.3070908@laserdata.at> <18055.5306.430438.363624@cerise.gclements.plus.com> Message-ID: <46895B8A.7070308@laserdata.at> Glynn Clements wrote: > Volker Wichmann wrote: > > >> almost similar to a recent post of Helena, I have problems compiling cvs >> on a fedora 7 / NVIDIA machine. But I get another error: >> Errors in: >> /usr/local/src/grass-cvs/grass6/lib/ogsf >> /usr/local/src/grass-cvs/grass6/visualization/nviz >> >> Changing to /lib/ogsf and running make: >> gcc -I/usr/local/src/grass-cvs/grass6/dist.i686-pc-linux-gnu/include -g >> -O2 -fPIC -DPACKAGE=\""grasslibs"\" -I/usr/local/include >> -DPACKAGE=\""grasslibs"\" -I/usr/local/include/ffmpeg >> -I/usr/local/src/grass-cvs/grass6/dist.i686-pc-linux-gnu/include \ >> -o OBJ.i686-pc-linux-gnu/gsd_img_ppm.o -c gsd_img_ppm.c >> In file included from gsd_img_ppm.c:20: >> /usr/local/include/ffmpeg/avcodec.h:2252: warning: "ImgReSampleContext" is deprecated >> /usr/local/include/ffmpeg/avcodec.h:2258: warning: "ImgReSampleContext" is deprecated >> gsd_img_ppm.c: In function "gsd_init_mpeg": >> gsd_img_ppm.c:122: error: "mpeg1video_encoder" undeclared (first use in this function) >> gsd_img_ppm.c:122: error: (Each undeclared identifier is reported only once >> gsd_img_ppm.c:122: error: for each function it appears in.) >> make: *** [OBJ.i686-pc-linux-gnu/gsd_img_ppm.o] Error 1 >> >> As far as I can tell ffmpeg is installed correctly (mpeg1video_encoder >> is defined in config.h, no errors) ... any tip? >> > > It should be declared in avcodec.h: > > extern AVCodec mpeg1video_encoder; > I checked out ffmpeg svn and in avcodec.h there is just extern AVCodec *first_avcodec; > I don't have a config.h in the ffmpeg include directory, and > gsd_image_ppm.c doesn't #include it (in fact, if it did have > "#include ", there's no guarantee that it would be ffmpeg's > config.h which was included; config.h is a rather common name). > > It appears that your version of ffmpeg isn't compatible with the OGSF > library; I can only suggest removing --with-ffmpeg from your configure > command. > > After removing --with-ffmpeg compilation is fine. I'm not really satisfied with that solution, but at the moment it seems I have to live with it and move on. Thanks! Volker From carlos.grohmann at gmail.com Mon Jul 2 23:01:19 2007 From: carlos.grohmann at gmail.com (=?ISO-8859-1?Q?Carlos_"Gu=E2no"_Grohmann?=) Date: Mon Jul 2 23:01:22 2007 Subject: [GRASS-dev] info buttons in gis.m (tcltk) Message-ID: Hi all, I always thought it would be nice to have a "info" button on gism, so it wouldn't be necessary to go all the way down the menus to get to r.info or v.info (it's a long way..), so I made this little hack in the tcl code. If you want to try, just replace raster.tcl and vector.tcl in $GRASS/etc/gm, and the gif icon goes to $GRASS/etc/gui/icons. hope you enjoy and don't mind about me messing around. cheers carlos -- +-----------------------------------------------------------+ Carlos Henrique Grohmann - Guano Visiting Researcher at Kingston University London - UK Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - carlos dot grohmann at gmail dot com +-----------------------------------------------------------+ _________________ "Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive." --The winning entry in a "What were HAL's first words" contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke -------------- next part -------------- A non-text attachment was scrubbed... Name: raster.tcl Type: application/x-tcl Size: 13334 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070702/ae0f6cea/raster-0001.tcl -------------- next part -------------- A non-text attachment was scrubbed... Name: vector.tcl Type: application/x-tcl Size: 27195 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070702/ae0f6cea/vector-0001.tcl -------------- next part -------------- A non-text attachment was scrubbed... Name: module-rv.info.gif Type: image/gif Size: 116 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070702/ae0f6cea/module-rv.info-0001.gif From carlos.grohmann at gmail.com Mon Jul 2 23:15:11 2007 From: carlos.grohmann at gmail.com (=?ISO-8859-1?Q?Carlos_"Gu=E2no"_Grohmann?=) Date: Mon Jul 2 23:15:14 2007 Subject: [GRASS-dev] how to deal with the @mapset in scripts? Message-ID: Helo all, I am writing some scripts, but I can't make them work with the @mapset in the rasters names. any special trick? there is one script attached. thanks Carlos -- +-----------------------------------------------------------+ Carlos Henrique Grohmann - Guano Visiting Researcher at Kingston University London - UK Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - carlos dot grohmann at gmail dot com +-----------------------------------------------------------+ _________________ "Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive." --The winning entry in a "What were HAL's first words" contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke -------------- next part -------------- A non-text attachment was scrubbed... Name: r.roughness.window.area Type: application/octet-stream Size: 4916 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070702/5cf2d54c/r.roughness.window.obj From michael.barton at asu.edu Mon Jul 2 23:43:23 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Jul 2 23:44:07 2007 Subject: [GRASS-dev] Re: gis.m/geocoding tool broken? In-Reply-To: <20070702165306.GL4727@bartok.itc.it> Message-ID: Found and fixed this. Now in the CVS What I think happened is that several months ago, it became (or I learned that it was) no longer necessary to set and unset GRASS_RENDER_IMMEDIATE for the GUI. Just set it and leave it set. I took this out of the main GUI code (mapcanvas.tcl), but forgot to take it out of the georect.tcl code (which does a replication of the same rendering commands to display a georect map. the result was that every time you displayed a map in the georectifier window, it would set, then UNSET GRASS_RENDER_IMMEDIATE. With this environmental variable unset, the main GUI (which no longer set and unset this variable at each display) was looking for a driver for outputting the display. I took this unnecessary code out of georect.tcl and it all works fine. ***How can I find out if this needs to be backported to 6.2.2?****** It WILL need to be backported if the command to set/unset GRASS_RENDER_IMMEDIATE has been removed from mapcanvas.tcl. If this command is still in mapcanvas.tcl, georect.tcl ALSO needs this command (i.e., what I just removed). Michael On 7/2/07 9:53 AM, "Markus Neteler" wrote: > Michael, > > On Mon, Jul 02, 2007 at 09:49:53AM -0700, Michael Barton wrote: >> Markus, >> >> The error you get indicates that the PNG driver has been 'turned off'. There >> is no clue in the list of commands you sent as to why this is so. Do you >> have the TclTk error message? > > I'll try to generate it again but it was than x0 isn't found (I think > as in the error log). > >> Today is kind of busy, but I'll try to do some testing here as soon as I >> can. > > thanks! > > markus > >> Michael >> >> >> On 7/1/07 1:02 PM, "Markus Neteler" wrote: >> >>> Michael, >>> >>> this evening I wanted to update the geocoding section >>> in the upcoming GRASS book, but it failed... Some weeks >>> ago I co-registered two raster maps successfully, today >>> I tried the first time to register against a geocoded >>> vector map. It fails to find the tcl "monitor", see error.log >>> attached. >>> >>> I would be gratefule if you could take a look. >>> thanks >>> markus >>> >>> ------------------ >>> ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler >>> ITC -> since 1 March 2007 Fondazione Bruno Kessler >>> ------------------ >> >> __________________________________________ >> Michael Barton, Professor of Anthropology >> Director of Graduate Studies >> School of Human Evolution & Social Change >> Center for Social Dynamics and Complexity >> Arizona State University >> >> phone: 480-965-6213 >> fax: 480-965-7671 >> www: http://www.public.asu.edu/~cmbarton >> > > ------------------ > ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler > ITC -> since 1 March 2007 Fondazione Bruno Kessler > ------------------ __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From harkiisk at utu.fi Mon Jul 2 23:52:58 2007 From: harkiisk at utu.fi (Harri Kiiskinen) Date: Mon Jul 2 23:53:02 2007 Subject: [GRASS-dev] how to deal with the @mapset in scripts? In-Reply-To: References: Message-ID: <1183413178.25087.103.camel@localhost.localdomain> On Mon, 2007-07-02 at 22:15 +0100, Carlos "Gu?no" Grohmann wrote: > Helo all, > > I am writing some scripts, but I can't make them work with the @mapset > in the rasters names. any special trick? > > there is one script attached. Hello Carlos, in g.findfile documentation it says, that the mapset has to be set using its own option, and then it will look in that mapset for the file. The case 'map1@mapset1' should be done: g.findfile element=cell mapset=mapset1 file=map1 whereas your script seems to do: g.findfile element=cell file='map1@mapset1' In the latter case, I guess the g.findfile only looks in the current mapset, and even thought there might be a file called 'map1' there probably isn't a file called 'map1@mapset1'. I guess you probably need to parse the 'map' option of your script and separate the mapname from the mapsetname. Just my theory, Harri K. From michael.barton at asu.edu Mon Jul 2 23:57:10 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Jul 2 23:57:15 2007 Subject: [GRASS-dev] info buttons in gis.m (tcltk) In-Reply-To: Message-ID: Carlos, I think that this is very nice. I have only 2 suggestions: 1) make the icon 24x24 to match the size of all other icons (just add more white border or make it 24x24 with a transparent background). This would make its button match all the others. 2) name the icon gui-rv.info.gif, or make 2 icons--one for each command. The convention is that icons named module-* actually run real GRASS modules. So, you could have module-r.info.gif and module-v.info.gif (and make them identical) or have a special GUI module named gui-rv.info.gif. If others think also think this is handy, we should go ahead and put them in the cvs. Michael On 7/2/07 2:01 PM, "Carlos "Gu?no" Grohmann" wrote: > Hi all, > > I always thought it would be nice to have a "info" button on gism, so > it wouldn't be necessary to go all the way down the menus to get to > r.info or v.info (it's a long way..), so I made this little hack in > the tcl code. If you want to try, just replace raster.tcl and > vector.tcl in $GRASS/etc/gm, and the gif icon goes to > $GRASS/etc/gui/icons. > > hope you enjoy and don't mind about me messing around. > > cheers > > carlos __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From carlos.grohmann at gmail.com Tue Jul 3 01:04:20 2007 From: carlos.grohmann at gmail.com (=?ISO-8859-1?Q?Carlos_"Gu=E2no"_Grohmann?=) Date: Tue Jul 3 01:04:24 2007 Subject: [GRASS-dev] how to deal with the @mapset in scripts? In-Reply-To: <1183413178.25087.103.camel@localhost.localdomain> References: <1183413178.25087.103.camel@localhost.localdomain> Message-ID: I went look in r.shade.relief, so I changed if [ -z `g.findfile elem=cell file="$GIS_OPT_SLOPE" | grep ^file | cut -f2 -d=` ] ; then g.message -e "<$GIS_OPT_SLOPE> does not exist! Aborting." exit 1 fi by slope=$GIS_OPT_SLOPE eval `g.findfile element=cell file=$slope` if [ -z "$name" ] ; then g.message -e "Map <$slope> not found! Aborting." exit 1 fi and now it works fine. thanks Carlos On 7/2/07, Harri Kiiskinen wrote: > On Mon, 2007-07-02 at 22:15 +0100, Carlos "Gu?no" Grohmann wrote: > > Helo all, > > > > I am writing some scripts, but I can't make them work with the @mapset > > in the rasters names. any special trick? > > > > there is one script attached. > > Hello Carlos, > > in g.findfile documentation it says, that the mapset has to be set using > its own option, and then it will look in that mapset for the file. The > case 'map1@mapset1' should be done: > > g.findfile element=cell mapset=mapset1 file=map1 > > whereas your script seems to do: > > g.findfile element=cell file='map1@mapset1' > > In the latter case, I guess the g.findfile only looks in the current > mapset, and even thought there might be a file called 'map1' there > probably isn't a file called 'map1@mapset1'. I guess you probably need > to parse the 'map' option of your script and separate the mapname from > the mapsetname. > > Just my theory, > > Harri K. > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- +-----------------------------------------------------------+ Carlos Henrique Grohmann - Guano Visiting Researcher at Kingston University London - UK Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - carlos dot grohmann at gmail dot com +-----------------------------------------------------------+ _________________ "Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive." --The winning entry in a "What were HAL's first words" contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke From neteler at itc.it Tue Jul 3 01:07:38 2007 From: neteler at itc.it (Markus Neteler) Date: Tue Jul 3 01:07:42 2007 Subject: [GRASS-dev] gis.m/geocoding tool broken? In-Reply-To: References: Message-ID: <11403608.post@talk.nabble.com> Great, Michael. I'll test tomorrow. Concerning 6.2: cd clean_releasebranch_6_2/gui/tcltk/gis.m grep GRASS_RENDER_IMMEDIATE * georect.tcl: set env(GRASS_RENDER_IMMEDIATE) "TRUE" georect.tcl: unset env(GRASS_RENDER_IMMEDIATE) mapcanvas.tcl: set env(GRASS_RENDER_IMMEDIATE) "TRUE" mapcanvas.tcl: unset env(GRASS_RENDER_IMMEDIATE) Apparently nothing to do there? Markus Michael Barton wrote: > > Found and fixed this. Now in the CVS > > What I think happened is that several months ago, it became (or I learned > that it was) no longer necessary to set and unset GRASS_RENDER_IMMEDIATE > for > the GUI. Just set it and leave it set. I took this out of the main GUI > code > (mapcanvas.tcl), but forgot to take it out of the georect.tcl code (which > does a replication of the same rendering commands to display a georect > map. > the result was that every time you displayed a map in the georectifier > window, it would set, then UNSET GRASS_RENDER_IMMEDIATE. With this > environmental variable unset, the main GUI (which no longer set and unset > this variable at each display) was looking for a driver for outputting the > display. > > I took this unnecessary code out of georect.tcl and it all works fine. > > ***How can I find out if this needs to be backported to 6.2.2?****** > > It WILL need to be backported if the command to set/unset > GRASS_RENDER_IMMEDIATE has been removed from mapcanvas.tcl. If this > command > is still in mapcanvas.tcl, georect.tcl ALSO needs this command (i.e., what > I > just removed). > > Michael > > > On 7/2/07 9:53 AM, "Markus Neteler" wrote: > >> Michael, >> >> On Mon, Jul 02, 2007 at 09:49:53AM -0700, Michael Barton wrote: >>> Markus, >>> >>> The error you get indicates that the PNG driver has been 'turned off'. >>> There >>> is no clue in the list of commands you sent as to why this is so. Do you >>> have the TclTk error message? >> >> I'll try to generate it again but it was than x0 isn't found (I think >> as in the error log). >> >>> Today is kind of busy, but I'll try to do some testing here as soon as I >>> can. >> >> thanks! >> >> markus >> >>> Michael >>> >>> >>> On 7/1/07 1:02 PM, "Markus Neteler" wrote: >>> >>>> Michael, >>>> >>>> this evening I wanted to update the geocoding section >>>> in the upcoming GRASS book, but it failed... Some weeks >>>> ago I co-registered two raster maps successfully, today >>>> I tried the first time to register against a geocoded >>>> vector map. It fails to find the tcl "monitor", see error.log >>>> attached. >>>> >>>> I would be gratefule if you could take a look. >>>> thanks >>>> markus >>>> >>>> ------------------ >>>> ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler >>>> ITC -> since 1 March 2007 Fondazione Bruno Kessler >>>> ------------------ >>> >>> __________________________________________ >>> Michael Barton, Professor of Anthropology >>> Director of Graduate Studies >>> School of Human Evolution & Social Change >>> Center for Social Dynamics and Complexity >>> Arizona State University >>> >>> phone: 480-965-6213 >>> fax: 480-965-7671 >>> www: http://www.public.asu.edu/~cmbarton >>> >> >> ------------------ >> ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler >> ITC -> since 1 March 2007 Fondazione Bruno Kessler >> ------------------ > > __________________________________________ > Michael Barton, Professor of Anthropology > Director of Graduate Studies > School of Human Evolution & Social Change > Center for Social Dynamics and Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > > -- View this message in context: http://www.nabble.com/Re%3A-gis.m-geocoding-tool-broken--tf4015091.html#a11403608 Sent from the Grass - Dev mailing list archive at Nabble.com. From michael.barton at asu.edu Tue Jul 3 03:14:14 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jul 3 03:14:26 2007 Subject: [GRASS-dev] gis.m/geocoding tool broken? In-Reply-To: <11403608.post@talk.nabble.com> Message-ID: On 7/2/07 4:07 PM, "Markus Neteler" wrote: > > Great, Michael. I'll test tomorrow. > > Concerning 6.2: > > cd clean_releasebranch_6_2/gui/tcltk/gis.m > grep GRASS_RENDER_IMMEDIATE * > georect.tcl: set env(GRASS_RENDER_IMMEDIATE) "TRUE" > georect.tcl: unset env(GRASS_RENDER_IMMEDIATE) > mapcanvas.tcl: set env(GRASS_RENDER_IMMEDIATE) "TRUE" > mapcanvas.tcl: unset env(GRASS_RENDER_IMMEDIATE) > > Apparently nothing to do there? Looks like it's fine the way it is. No change needed. Thanks for checking. Michael > > Markus > > > Michael Barton wrote: >> >> Found and fixed this. Now in the CVS >> >> What I think happened is that several months ago, it became (or I learned >> that it was) no longer necessary to set and unset GRASS_RENDER_IMMEDIATE >> for >> the GUI. Just set it and leave it set. I took this out of the main GUI >> code >> (mapcanvas.tcl), but forgot to take it out of the georect.tcl code (which >> does a replication of the same rendering commands to display a georect >> map. >> the result was that every time you displayed a map in the georectifier >> window, it would set, then UNSET GRASS_RENDER_IMMEDIATE. With this >> environmental variable unset, the main GUI (which no longer set and unset >> this variable at each display) was looking for a driver for outputting the >> display. >> >> I took this unnecessary code out of georect.tcl and it all works fine. >> >> ***How can I find out if this needs to be backported to 6.2.2?****** >> >> It WILL need to be backported if the command to set/unset >> GRASS_RENDER_IMMEDIATE has been removed from mapcanvas.tcl. If this >> command >> is still in mapcanvas.tcl, georect.tcl ALSO needs this command (i.e., what >> I >> just removed). >> >> Michael >> >> >> On 7/2/07 9:53 AM, "Markus Neteler" wrote: >> >>> Michael, >>> >>> On Mon, Jul 02, 2007 at 09:49:53AM -0700, Michael Barton wrote: >>>> Markus, >>>> >>>> The error you get indicates that the PNG driver has been 'turned off'. >>>> There >>>> is no clue in the list of commands you sent as to why this is so. Do you >>>> have the TclTk error message? >>> >>> I'll try to generate it again but it was than x0 isn't found (I think >>> as in the error log). >>> >>>> Today is kind of busy, but I'll try to do some testing here as soon as I >>>> can. >>> >>> thanks! >>> >>> markus >>> >>>> Michael >>>> >>>> >>>> On 7/1/07 1:02 PM, "Markus Neteler" wrote: >>>> >>>>> Michael, >>>>> >>>>> this evening I wanted to update the geocoding section >>>>> in the upcoming GRASS book, but it failed... Some weeks >>>>> ago I co-registered two raster maps successfully, today >>>>> I tried the first time to register against a geocoded >>>>> vector map. It fails to find the tcl "monitor", see error.log >>>>> attached. >>>>> >>>>> I would be gratefule if you could take a look. >>>>> thanks >>>>> markus >>>>> >>>>> ------------------ >>>>> ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler >>>>> ITC -> since 1 March 2007 Fondazione Bruno Kessler >>>>> ------------------ >>>> >>>> __________________________________________ >>>> Michael Barton, Professor of Anthropology >>>> Director of Graduate Studies >>>> School of Human Evolution & Social Change >>>> Center for Social Dynamics and Complexity >>>> Arizona State University >>>> >>>> phone: 480-965-6213 >>>> fax: 480-965-7671 >>>> www: http://www.public.asu.edu/~cmbarton >>>> >>> >>> ------------------ >>> ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler >>> ITC -> since 1 March 2007 Fondazione Bruno Kessler >>> ------------------ >> >> __________________________________________ >> Michael Barton, Professor of Anthropology >> Director of Graduate Studies >> School of Human Evolution & Social Change >> Center for Social Dynamics and Complexity >> Arizona State University >> >> phone: 480-965-6213 >> fax: 480-965-7671 >> www: http://www.public.asu.edu/~cmbarton >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev >> >> __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hamish_nospam at yahoo.com Tue Jul 3 05:46:15 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jul 3 05:46:26 2007 Subject: [GRASS-dev] time to release 6.2.2 In-Reply-To: <46892DF0.2000003@itc.it> References: <20070701190509.GA28159@bartok.itc.it> <4688BB2B.8030908@itc.it> <46892DF0.2000003@itc.it> Message-ID: <20070703154615.4ce506cf.hamish_nospam@yahoo.com> Markus: > I would suggest to release 6.2.2 officially the next days if nobody > objects. Hamish: > I found a glitch with v.in.gpsbabel on the Mac which I'd like to fix > before release. done. Paul: > As I noted before (..) Grass 6.2.2 seems to already be tagged (as > grass_6_2_2) in CVS. .. > I still think it is a good idea to include the date of releases in the > tag name, less confusion that way, e.g. release_20070702_grass_6_2_2 - I agree, it reduces confusion about a CVS tag being a conceptual alias to a timestamp, as opposed to a separate working CVS branch line. "grass_x_y_z" by itself is easily confused with a release branch line. summary of previously used tags: http://freegis.org/cgi-bin/viewcvs.cgi/grass/GPL.TXT http://freegis.org/cgi-bin/viewcvs.cgi/grass6/GPL.TXT "release_YYYYMMDD_grass_x_y_z" (or "YYYYMMDD_grass_x_y_z", or some other combination) sorts well. nb. "release" and "grass" may be redundant noise in the tag name Paul: > Good luck in shifting the tag! Markus: > I found this documentation: > http://cvsnt.org/manual/html/Modifying-tags.html > > Anyone with experience...? Glynn: > If you want to discard the existing grass_6_2_2 tag and tag the > current version: > > cvs rtag -d grass_6_2_2 grass6 > cvs tag -c release_20070702_grass_6_2_2 see also http://article.gmane.org/gmane.comp.gis.grass.devel/21022 Hamish From grass-codei at wald.intevation.org Tue Jul 3 07:03:20 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Tue Jul 3 07:02:15 2007 Subject: [GRASS-dev] [grass-code I][440] d.zoom panning "shrinking" region Message-ID: <20070703050320.88A55400D3@pyrosoma.intevation.org> code I item #440, was opened at 2007-07-03 00:03 Status: Open Priority: 3 Submitted By: Pedro Camilo Alcantara C (camiloalcantara) Assigned to: Nobody (None) Summary: d.zoom panning "shrinking" region Issue type: module bad feature Issue status: None GRASS version: 6.2.1 GRASS component: display Operating system: Windows Operating system version: XP GRASS CVS checkout date, if applies (YYMMDD): 070316 Initial Comment: While panning, with the command "d.zoom -p" over any image on a regular monitor (e.g x1), the region is "shrinking" by one pixel on each side of the window. It is not a big deal when panning a map once or two times, but if panning is done several times to explore at a larger scale a map it could be annoying. The other problem is that we can lost control on the working region if we want to perform a calculation over a given area. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=440&group_id=21 From wolf+grass at bergenheim.net Tue Jul 3 07:27:34 2007 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Tue Jul 3 07:28:07 2007 Subject: [GRASS-dev] Some questions about standardization In-Reply-To: <4689303B.4050604@jemila.jazztel.es> References: <4689303B.4050604@jemila.jazztel.es> Message-ID: <4689DE46.80800@bergenheim.net> On 02.07.2007 20:04, Carlos D?vila wrote: > > I need some help to continue with further changes. As I'm not programmer > I don't know well what can be changed in code and what can't, so I ask > you some cases: > a) %s: can't open tempfile -> Unable to open temporary file <%s> (does > it affect where is the %s?) No, except as long as it doesn't pass another %-expression (which it doesn't in this case). %s is replaced with the next string given in the parameter list (the variable names after the ','). Actually it is replaced with the value of the next argument treated as a char pointer. So if the next value is an integer with the value of 5 then the 5 is treated as a pointer and tries to read memory at location 5 which will result in a crash. > b) can't open raster map <%s> in mapset %s -> Unable to open raster map > <%s> (Can I drop last %s without problems?) No you can't. You also need to drop the third argument which is the mapset. > c) How can I pass from "Unable to open the temporary file." to "Unable > to open temporary file <%s>"? E.g. from /display/d.text.freetype/main.c: > > tmpfile = G_tempfile(); > if(!(fp = fopen(tmpfile, "w"))) > error(_("Unable to write the temporary file")); > Do this: tmpfile = G_tempfile(); if(!(fp = fopen(tmpfile, "w"))) error(_("Unable to write temporary file <%s>"), tempfile); --Wolf -- <:3 )---- Wolf Bergenheim ----( 8:> From hamish_nospam at yahoo.com Tue Jul 3 08:06:23 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jul 3 08:06:38 2007 Subject: [GRASS-dev] Searching for output messages In-Reply-To: References: <468425AD.9080007@jemila.jazztel.es> Message-ID: <20070703180623.2f01929b.hamish_nospam@yahoo.com> Carlos D?vila: > > What tool may I use to extract all output messages given by a > > certain function (e.g. G_fatal_error) in the whole grass6 cvs tree? Martin: > If I understand well... > > E.g. (need improvements) > > $ grep "G_fatal_error" * -R | grep .c: | cut -d'"' -f2 In the past when writing new code or i18n'ing old code, to see the already translated error msg options for a specific lib fn I've done like: grep -rI -A3 G_open_cell * | grep G_fatal_error but to save time start in the raster/ dir for eg raster msgs. Hamish From yann.chemin at gmail.com Tue Jul 3 08:29:04 2007 From: yann.chemin at gmail.com (Yann) Date: Tue Jul 3 08:30:17 2007 Subject: [GRASS-dev] using slope/aspect functions inside our module Message-ID: <200707031329.04522.yann.chemin@gmail.com> Hello, In a given chain processing module (DN->high-level product) in development, there is a need of calculating slope and aspect, i would like to use the existing code as a library or something to the similar effect. Anyone could explain if it is possible and how it could be possible? thank you Yann From hamish_nospam at yahoo.com Tue Jul 3 08:56:21 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jul 3 08:56:35 2007 Subject: [GRASS-dev] barscale in latlong region In-Reply-To: References: Message-ID: <20070703185621.66ce6b21.hamish_nospam@yahoo.com> Michael Barton wrote: > > I know this has come up before, but I wanted to see if there might be > a way to fix this now. see http://thread.gmane.org/gmane.comp.gis.grass.devel/2794/focus=2841 > I don't work much with latlon locations, but I know that a lot of > people do. For large areas especially, it is one of the main ways to > manage geospatial data. GRASS has pretty good tools for dealing with > latlon and its idiosyncrasies. However, a peculiar gap is that the > barscale tool won't work in latlon. Given that I'm told that there are > GRASS libraries already in existence to deal with latlon to metric > conversions, it seems odd that we can't put a scale on a latlon map. > > Is this actually a very difficult problem to solve, or just one that > no one has yet gotten around to doing--I know that you all have sooo > much free time on your hands ;-) It's a problem of correctness, not a technical/time issue. A horizontal plate carr?e scale is only valid at a single lat, and becomes more wrong as you zoom out or look up and down the map. See a National Geographic map for a solution which has a series of scales in the shape of a horn, where you choose a scale depending on the lat. Glynn's suggestion in the above thread of changing the units to degrees (or min,sec) could work. But then you could use d.grid for that. note "d.barscale -n" will work in lat/lon as that doesn't need scale. (north arrow only). Better: replace "d.barscale -n" with a symbol so you can optionally draw the compass or fancy_compass under the "N" text instead of the arrow-head. Hamish From michael.barton at asu.edu Tue Jul 3 09:16:55 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jul 3 09:17:00 2007 Subject: [GRASS-dev] barscale in latlong region In-Reply-To: <20070703185621.66ce6b21.hamish_nospam@yahoo.com> Message-ID: How about making d.barscale be approximately accurate in latlon near the bottom of the map and say so in the docs? Not ideal, but useable perhaps. Michael On 7/2/07 11:56 PM, "Hamish" wrote: > Michael Barton wrote: >> >> I know this has come up before, but I wanted to see if there might be >> a way to fix this now. > > see http://thread.gmane.org/gmane.comp.gis.grass.devel/2794/focus=2841 > >> I don't work much with latlon locations, but I know that a lot of >> people do. For large areas especially, it is one of the main ways to >> manage geospatial data. GRASS has pretty good tools for dealing with >> latlon and its idiosyncrasies. However, a peculiar gap is that the >> barscale tool won't work in latlon. Given that I'm told that there are >> GRASS libraries already in existence to deal with latlon to metric >> conversions, it seems odd that we can't put a scale on a latlon map. >> >> Is this actually a very difficult problem to solve, or just one that >> no one has yet gotten around to doing--I know that you all have sooo >> much free time on your hands ;-) > > > It's a problem of correctness, not a technical/time issue. > A horizontal plate carr?e scale is only valid at a single lat, and > becomes more wrong as you zoom out or look up and down the map. See a > National Geographic map for a solution which has a series of scales in > the shape of a horn, where you choose a scale depending on the lat. > > > Glynn's suggestion in the above thread of changing the units to degrees > (or min,sec) could work. But then you could use d.grid for that. > > > note "d.barscale -n" will work in lat/lon as that doesn't need scale. > (north arrow only). Better: replace "d.barscale -n" with a symbol so you > can optionally draw the compass or fancy_compass under the "N" text > instead of the arrow-head. > > > Hamish __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hamish_nospam at yahoo.com Tue Jul 3 09:47:17 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jul 3 09:47:36 2007 Subject: [GRASS-dev] inverted color scales In-Reply-To: <18051.37155.688091.305962@cerise.gclements.plus.com> References: <4682804D.7020704@o2.pl> <18051.37155.688091.305962@cerise.gclements.plus.com> Message-ID: <20070703194717.6b960f06.hamish_nospam@yahoo.com> > > What do you guys think of a flag in r.colors to apply an > > > _inverted_ color scale? > > > > Sounds really usefull to me. I've wanted this for a long time too. Glynn: > Sounds really trivial to implement, too. > > "struct Colors" already has an "invert" field, which can be inverted > with G_invert_colors(). > > AFAICT, you just need e.g.: > > flag.n = G_define_flag(); > flag.n->key = 'n'; > flag.n->description = _("Invert colors"); > > ... > > if (flag.n->answer) > { > G_invert_colors(&colors); [//] colors = colors_tmp; > } done in 6.3 CVS. > The only issue is whether the inversion should come before or after > logarithmic scaling (I think that it matters, although I haven't > actually checked). I think that it matters too, and I put it before the scaling. (flipping it is conceptually a linear operation, don't apply a linear operation to log-transformed data; or if you prefer, keep the rule defn code separate from the math post-processing code) Hamish From hamish_nospam at yahoo.com Tue Jul 3 10:49:04 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jul 3 10:49:15 2007 Subject: [GRASS-dev] Error and warning messages in output In-Reply-To: <46827E2E.3070802@jemila.jazztel.es> References: <46827E2E.3070802@jemila.jazztel.es> Message-ID: <20070703204904.24bdaf1a.hamish_nospam@yahoo.com> Carlos D?vila wrote: > There's a lot of error and warning messages that are shown in the > output of different modules and scripts that are not included in po > files. IMHO these messages should be translated, as they are the key > for the user to know what is being done wrong and correct it. > > Usually they are written in the way: g.message flag > "what_you_want_to_say" I've tried adding _( ) but it doesn't work. > > So I have two questions: > Do you agree they should be included in po files? > If so, how to include them? "g.parser -t" is currently only picking up #% description text, not g.message messages. g.parser help page: ================================= TRANSLATION g.parser provides some support for translating the options of scripts. If called with the -t switch before the script filename like this g.parser -t somescriptfile g.parser will print the text of the translatable options to stdout, one per line, and exit. This is for internal use within the build system to prepare GRASS scripts for translation. ================================= e.g G63> g.parser -t `which v.in.gpsbabel` | wc -l 12 G63> grep g.message `which v.in.gpsbabel` | wc -l 54 "g.parser -t" or g.message needs to be extended somehow. You can extract the messages with SCRIPT=v.in.gpsbabel grep g.message `which $SCRIPT` | \ sed -e 's/-w \|-e \|-v \|-i //' \ -e 's/.*g.message //' \ -e 's/^message=//'| grep -v '^""$' saving `grep g.message` to a TMP file and running it gives the messages, but the shell processes all $VARIABLES (mostly to ""), which may be needed. double and single quotes are important (e.g. '!'), and I'm not sure how g.parser coule paste in the translations, I'm doubtful that this is even possible with g.parser -- it probably needs to happen in g.message, with .po lists generated as above. ???, Hamish From hamish_nospam at yahoo.com Tue Jul 3 11:50:32 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jul 3 11:50:46 2007 Subject: [GRASS-dev] Re: [GRASS-user] Line of sight and r.cva In-Reply-To: References: <4683C2DA.6090401@ing.unitn.it> Message-ID: <20070703215032.059d44d9.hamish_nospam@yahoo.com> Michael Barton wrote: > > IMHO, r.cva is a good candidate to consider for the regular GRASS > distribution. According to Benjamin Ducke (who built on Mark Lake's > original code to bring this to GRASS 6), it could use some > optimization improvements because it is VERY slow at times. yes, but IIRC the author has copyright problems from his university which wouldn't let him release it as GPL. Otherwise it would have replaced r.los a long time ago. IIRC2 as mentioned in the Google SOC project thread that even with the r.cva improvements the base r.los algorithm is badly inefficient, and could be implemented a lot better. Hamish From hamish_nospam at yahoo.com Tue Jul 3 12:39:16 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jul 3 12:39:23 2007 Subject: [GRASS-dev] new d.grid textcolor= option; nzgd2k datum offset versus WGS84 Message-ID: <20070703223916.253e38cf.hamish_nospam@yahoo.com> Hi, I added a new d.grid textcolor= option in 6.3-cvs. Also I removed the lat/lon border skipping as it seems to work. (no new code, just deleted the LL check+warning) If it proves problematic I think we should keep the border but disable the tick marks. outstanding wish: for a long time I've wanted GMT-style black/white bar scale border for d.grid and ps.map. I noiced something odd: using the NZTM projection (EPSG #2193), "d.grid -g" and "d.grid -w" are approx 17.50 meters different. -g Draw geographic grid (referenced to current ellipsoid) -w Draw geographic grid (referenced to WGS84 ellipsoid) EPSG file: # NZGD2000 / New Zealand Transverse Mercator <2193> +proj=tmerc +lat_0=0 +lon_0=173 +k=0.999600 +x_0=1600000 +y_0=10000000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs <> AFAIR, NZ Geoid Datum 2000 should be at most 10cm different in the vertical versus WGS84 and virtually the same in the horizontal. so why the difference? datum: nzgd2k ellipsoid: grs80 north: 4962100 south: 4961800 west: 1123250 east: 1123550 d.grid 0:00:05 -w d.grid 0:00:05 -g -PROJ_INFO------------------------------------------------- name : Transverse Mercator datum : nzgd2k towgs84 : 0.000,0.000,0.000 proj : tmerc ellps : grs80 a : 6378137.0000000000 es : 0.0066943800 f : 298.2572221010 lat_0 : 0.0000000000 lon_0 : 173.0000000000 k_0 : 0.9996000000 x_0 : 1600000.0000000000 y_0 : 10000000.0000000000 ??, Hamish From hamish_nospam at yahoo.com Tue Jul 3 12:54:51 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jul 3 12:55:04 2007 Subject: [GRASS-dev] barscale in latlong region In-Reply-To: References: <20070703185621.66ce6b21.hamish_nospam@yahoo.com> Message-ID: <20070703225451.2f4f4a53.hamish_nospam@yahoo.com> Michael Barton wrote: > > How about making d.barscale be approximately accurate in latlon near > the bottom of the map and say so in the docs? Not ideal, but useable > perhaps. In short, no. e.g. whole world etopo2/nasa blue marble/admin98: g.region n=90 s=-90 w=-180 e=180 horizontal scale at the bottom of the map (s pole) is a singularity. even if you use the center of the region (equator) it is badly wrong over most of the map. I though about testing to see if the region was small enough for the scale not to change much (>1-2 pixel) over the spread of the map, but then it is still a different scale in the x and y dirs unless you are on the equator. Hamish From epatton at nrcan.gc.ca Tue Jul 3 14:33:42 2007 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Tue Jul 3 14:35:14 2007 Subject: [GRASS-dev] info buttons in gis.m (tcltk) References: Message-ID: >If others think also think this is handy, we should go ahead and put them in >the cvs. >Michael I think it would be useful functionality. ~ Eric. From glynn at gclements.plus.com Tue Jul 3 14:58:10 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jul 3 14:58:13 2007 Subject: [GRASS-dev] [grass-code R][438] min:max options for r.recode In-Reply-To: <20070702200645.6155F400D3@pyrosoma.intevation.org> References: <20070702200645.6155F400D3@pyrosoma.intevation.org> Message-ID: <18058.18402.641144.399513@cerise.gclements.plus.com> grass-coder@wald.intevation.org wrote: > code R item #438, was opened at 2007-07-02 20:06 > Status: Open > Priority: 3 > Submitted By: Carlos Grohmann (guano) > Assigned to: Nobody (None) > Summary: min:max options for r.recode > Issue status: None > GRASS component: raster > Operating system: Linux > Operating system version: > > > Initial Comment: > It would be really great if r.recode had a flag/option where the > min:max:0:255 > operation would automatically performed. This is a very useful option. > > Also, if the keywords "min" and "max" could be included as permitted > in the rules, much time would be saved. Alternatively, allow percentages as with colour rules (i.e. 0% = min, 100% = max). -- Glynn Clements From glynn at gclements.plus.com Tue Jul 3 15:02:27 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jul 3 15:02:31 2007 Subject: [GRASS-dev] how to deal with the @mapset in scripts? In-Reply-To: References: <1183413178.25087.103.camel@localhost.localdomain> Message-ID: <18058.18659.813821.751284@cerise.gclements.plus.com> "Carlos \"Gu?no\" Grohmann" wrote: > I went look in r.shade.relief, so I changed > > if [ -z `g.findfile elem=cell file="$GIS_OPT_SLOPE" | grep ^file | cut > -f2 -d=` ] ; then > g.message -e "<$GIS_OPT_SLOPE> does not exist! Aborting." > exit 1 > fi > > by > slope=$GIS_OPT_SLOPE > > eval `g.findfile element=cell file=$slope` > if [ -z "$name" ] ; then > g.message -e "Map <$slope> not found! Aborting." > exit 1 > fi > > and now it works fine. Why do you actually need to use g.findfile? In most cases, you should just pass the map name directly to the command, and let the command handle the checking. Also, if you use g.parser and the options have the appropriate "gisprompt" setting, g.parser will perform the relevant checks, so there's no need to repeat them. -- Glynn Clements From glynn at gclements.plus.com Tue Jul 3 15:07:36 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jul 3 15:07:38 2007 Subject: [GRASS-dev] inverted color scales In-Reply-To: <20070703194717.6b960f06.hamish_nospam@yahoo.com> References: <4682804D.7020704@o2.pl> <18051.37155.688091.305962@cerise.gclements.plus.com> <20070703194717.6b960f06.hamish_nospam@yahoo.com> Message-ID: <18058.18968.83603.484322@cerise.gclements.plus.com> Hamish wrote: > > > What do you guys think of a flag in r.colors to apply an > > > > _inverted_ color scale? > > > > > > Sounds really usefull to me. > > I've wanted this for a long time too. > > > Glynn: > > Sounds really trivial to implement, too. > > > > "struct Colors" already has an "invert" field, which can be inverted > > with G_invert_colors(). > > > > AFAICT, you just need e.g.: > > > > flag.n = G_define_flag(); > > flag.n->key = 'n'; > > flag.n->description = _("Invert colors"); > > > > ... > > > > if (flag.n->answer) > > { > > G_invert_colors(&colors); > [//] colors = colors_tmp; Nope; unlike the other transformations, G_invert_colors() operates "in-place" (it simply inverts the "invert" flag in the structure). In the above, colors_tmp essentially contains garbage; it may not have even been initialised. -- Glynn Clements From carlos.grohmann at gmail.com Tue Jul 3 15:42:02 2007 From: carlos.grohmann at gmail.com (=?ISO-8859-1?Q?Carlos_"Gu=E2no"_Grohmann?=) Date: Tue Jul 3 15:42:05 2007 Subject: [GRASS-dev] how to deal with the @mapset in scripts? In-Reply-To: <18058.18659.813821.751284@cerise.gclements.plus.com> References: <1183413178.25087.103.camel@localhost.localdomain> <18058.18659.813821.751284@cerise.gclements.plus.com> Message-ID: I just copied the stuff from r.shaded.relief.. On 7/3/07, Glynn Clements wrote: > > "Carlos \"Gu?no\" Grohmann" wrote: > > > I went look in r.shade.relief, so I changed > > > > if [ -z `g.findfile elem=cell file="$GIS_OPT_SLOPE" | grep ^file | cut > > -f2 -d=` ] ; then > > g.message -e "<$GIS_OPT_SLOPE> does not exist! Aborting." > > exit 1 > > fi > > > > by > > slope=$GIS_OPT_SLOPE > > > > eval `g.findfile element=cell file=$slope` > > if [ -z "$name" ] ; then > > g.message -e "Map <$slope> not found! Aborting." > > exit 1 > > fi > > > > and now it works fine. > > Why do you actually need to use g.findfile? In most cases, you should > just pass the map name directly to the command, and let the command > handle the checking. > > Also, if you use g.parser and the options have the appropriate > "gisprompt" setting, g.parser will perform the relevant checks, so > there's no need to repeat them. > > -- > Glynn Clements > -- +-----------------------------------------------------------+ Carlos Henrique Grohmann - Guano Visiting Researcher at Kingston University London - UK Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - carlos dot grohmann at gmail dot com +-----------------------------------------------------------+ _________________ "Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive." --The winning entry in a "What were HAL's first words" contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke From benjamin.ducke at ufg.uni-kiel.de Tue Jul 3 15:50:21 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Tue Jul 3 15:50:58 2007 Subject: [GRASS-dev] moving r.cva into GRASS CVS Message-ID: <468A541D.6060308@ufg.uni-kiel.de> I am getting more and more requests about r.cva. Obviously, there is a lot of people who know about and want to use it. So far, none of them has been able to make any sense of the GEM installation routine. I suggest we include r.cva in the main GRASS CVS tree. It is stable but with some poorly tested options. Together, we could test and improve it in time for the GRASS 6.2.3 release. With some recent fixes I made, r.cva (as opposed to r.los) runs fine on Win32, as well. Since r.cva can do all that r.los can do, I suggest replacing r.los with a script that calls r.cva with the same parameters you would pass to r.los. That way, we need to maintain only on code base. It would probably be necessary to add an option to r.cva to specify observer coordinates directly but that should not be hard to do. If you all agree to that, I will just get in touch with Mark Lake to make sure we have no licensing issues here and can put the code under GPL. Benjamin -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From carlos.grohmann at gmail.com Tue Jul 3 16:18:48 2007 From: carlos.grohmann at gmail.com (=?ISO-8859-1?Q?Carlos_"Gu=E2no"_Grohmann?=) Date: Tue Jul 3 16:18:52 2007 Subject: [GRASS-dev] how to deal with the @mapset in scripts? In-Reply-To: References: <1183413178.25087.103.camel@localhost.localdomain> <18058.18659.813821.751284@cerise.gclements.plus.com> Message-ID: I said it worked but I shouldn't. the @mapset is not a problem when the maps are used by some command, like r.mapcalc, bu it is a problem because the default output map (if you don't give a name) will be based on the input, like: input : in_map output : in_map_roughness_3x3 so I need to get rid of the @mapset, or else it will be set to in_map@mapset_roughness_3x3 and r.mapcalc will fail. Carlos On 7/3/07, Carlos Gu?no Grohmann wrote: > I just copied the stuff from r.shaded.relief.. > > > > On 7/3/07, Glynn Clements wrote: > > > > "Carlos \"Gu?no\" Grohmann" wrote: > > > > > I went look in r.shade.relief, so I changed > > > > > > if [ -z `g.findfile elem=cell file="$GIS_OPT_SLOPE" | grep ^file | cut > > > -f2 -d=` ] ; then > > > g.message -e "<$GIS_OPT_SLOPE> does not exist! Aborting." > > > exit 1 > > > fi > > > > > > by > > > slope=$GIS_OPT_SLOPE > > > > > > eval `g.findfile element=cell file=$slope` > > > if [ -z "$name" ] ; then > > > g.message -e "Map <$slope> not found! Aborting." > > > exit 1 > > > fi > > > > > > and now it works fine. > > > > Why do you actually need to use g.findfile? In most cases, you should > > just pass the map name directly to the command, and let the command > > handle the checking. > > > > Also, if you use g.parser and the options have the appropriate > > "gisprompt" setting, g.parser will perform the relevant checks, so > > there's no need to repeat them. > > > > -- > > Glynn Clements > > > > > -- > +-----------------------------------------------------------+ > Carlos Henrique Grohmann - Guano > Visiting Researcher at Kingston University London - UK > Geologist M.Sc - Doctorate Student at IGc-USP - Brazil > Linux User #89721 - carlos dot grohmann at gmail dot com > +-----------------------------------------------------------+ > _________________ > "Good morning, doctors. I have taken the liberty of removing Windows > 95 from my hard drive." > --The winning entry in a "What were HAL's first words" contest judged > by 2001: A SPACE ODYSSEY creator Arthur C. Clarke > -- +-----------------------------------------------------------+ Carlos Henrique Grohmann - Guano Visiting Researcher at Kingston University London - UK Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - carlos dot grohmann at gmail dot com +-----------------------------------------------------------+ _________________ "Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive." --The winning entry in a "What were HAL's first words" contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke From tutey at o2.pl Tue Jul 3 16:58:08 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Jul 3 16:58:12 2007 Subject: [GRASS-dev] how to deal with the @mapset in scripts? In-Reply-To: <18058.18659.813821.751284@cerise.gclements.plus.com> References: <1183413178.25087.103.camel@localhost.localdomain> <18058.18659.813821.751284@cerise.gclements.plus.com> Message-ID: <468A6400.9070600@o2.pl> Glynn Clements wrote: > Why do you actually need to use g.findfile? In most cases, you should > just pass the map name directly to the command, and let the command > handle the checking. It's better to check if the output exists in the initial stage of my script, than to let it run for an hour and then fail with an error that the output already exists in the end. Maciek From tutey at o2.pl Tue Jul 3 17:06:24 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Jul 3 17:06:29 2007 Subject: [GRASS-dev] how to deal with the @mapset in scripts? In-Reply-To: <468A6400.9070600@o2.pl> References: <1183413178.25087.103.camel@localhost.localdomain> <18058.18659.813821.751284@cerise.gclements.plus.com> <468A6400.9070600@o2.pl> Message-ID: <468A65F0.1070407@o2.pl> Maciej Sieczka wrote: > Glynn Clements wrote: >> Why do you actually need to use g.findfile? In most cases, you should >> just pass the map name directly to the command, and let the command >> handle the checking. > It's better to check if the output exists Oops! Sorry, I missed the fact that you are talking about the *input*. GRASS always handled well the non-existance of input, for me. Only output name needs to be controlled in the script to avoid running long scripts for nothing. Maciek From michael.barton at asu.edu Tue Jul 3 17:51:54 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jul 3 17:52:00 2007 Subject: [GRASS-dev] barscale in latlong region In-Reply-To: <20070703225451.2f4f4a53.hamish_nospam@yahoo.com> Message-ID: Oh well. Guess I wasn't thinking big enough. Michael On 7/3/07 3:54 AM, "Hamish" wrote: > Michael Barton wrote: >> >> How about making d.barscale be approximately accurate in latlon near >> the bottom of the map and say so in the docs? Not ideal, but useable >> perhaps. > > > In short, no. > > e.g. whole world etopo2/nasa blue marble/admin98: > g.region n=90 s=-90 w=-180 e=180 > > horizontal scale at the bottom of the map (s pole) is a singularity. > even if you use the center of the region (equator) it is badly wrong > over most of the map. I though about testing to see if the region was > small enough for the scale not to change much (>1-2 pixel) over the > spread of the map, but then it is still a different scale in the x and y > dirs unless you are on the equator. > > > Hamish __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Tue Jul 3 18:06:23 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jul 3 18:06:34 2007 Subject: [GRASS-dev] [grass-code R][438] min:max options for r.recode In-Reply-To: <18058.18402.641144.399513@cerise.gclements.plus.com> Message-ID: On 7/3/07 5:58 AM, "Glynn Clements" wrote: >> Initial Comment: >> It would be really great if r.recode had a flag/option where the >> min:max:0:255 >> operation would automatically performed. This is a very useful option. >> >> Also, if the keywords "min" and "max" could be included as permitted >> in the rules, much time would be saved. > > Alternatively, allow percentages as with colour rules (i.e. 0% = min, > 100% = max). > > -- > Glynn Clements > This would be even better than min/max IMHO. Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Tue Jul 3 18:10:00 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jul 3 18:10:06 2007 Subject: [GRASS-dev] moving r.cva into GRASS CVS In-Reply-To: <468A541D.6060308@ufg.uni-kiel.de> Message-ID: There have been some mention of possible licensing issues. If these are solved, I think that this is a great idea. One suggestion is to have defaults that make r.cva operate like r.los. Since I don't use it a lot yet (due to installation issues that have come and gone), I have trouble remembering the settings that let it do simple viewsheds--though I know that it does them. Michael On 7/3/07 6:50 AM, "Benjamin Ducke" wrote: > I am getting more and more requests about r.cva. Obviously, there > is a lot of people who know about and want to use it. > So far, none of them has been able to make any sense of the GEM > installation routine. > > I suggest we include r.cva in the main GRASS CVS tree. > It is stable but with some poorly tested options. Together, we could > test and improve it in time for the GRASS 6.2.3 release. > > With some recent fixes I made, r.cva (as opposed to r.los) runs fine > on Win32, as well. > > Since r.cva can do all that r.los can do, I suggest replacing r.los > with a script that calls r.cva with the same parameters you would pass > to r.los. That way, we need to maintain only on code base. > It would probably be necessary to add an option to r.cva to specify > observer coordinates directly but that should not be hard to do. > > If you all agree to that, I will just get in touch with Mark Lake > to make sure we have no licensing issues here and can put the code > under GPL. > > Benjamin __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From cdavilam at jemila.jazztel.es Tue Jul 3 23:37:09 2007 From: cdavilam at jemila.jazztel.es (=?ISO-8859-15?Q?Carlos_D=E1vila?=) Date: Tue Jul 3 23:34:26 2007 Subject: [GRASS-dev] Some questions about standardization In-Reply-To: <4689DE46.80800@bergenheim.net> References: <4689303B.4050604@jemila.jazztel.es> <4689DE46.80800@bergenheim.net> Message-ID: <468AC185.6030905@jemila.jazztel.es> >> c) How can I pass from "Unable to open the temporary file." to "Unable >> to open temporary file <%s>"? E.g. from /display/d.text.freetype/main.c: >> >> tmpfile = G_tempfile(); >> if(!(fp = fopen(tmpfile, "w"))) >> error(_("Unable to write the temporary file")); >> >> > > Do this: > tmpfile = G_tempfile(); > if(!(fp = fopen(tmpfile, "w"))) > error(_("Unable to write temporary file <%s>"), tempfile); > > --Wolf > > I have done some changes as suggested in /display/d.text, d.text.new and d.title ("Unable to open the temporary file." to "Unable to open temporary file <%s>". Despite they compile without problems for me, could anyone check they are right? :-\ Greetings Carlos From wolf+grass at bergenheim.net Tue Jul 3 23:57:05 2007 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Tue Jul 3 23:57:41 2007 Subject: [GRASS-dev] barscale in latlong region In-Reply-To: References: Message-ID: <468AC631.6030304@bergenheim.net> I wonder... how hard would it be to make the barscale be the "national-geographic-like" when dealing with lat-long locations? Is this too much work / to hard to do? I think it could give an additional edge to GRASS. --Wolf On 03.07.2007 18:51, Michael Barton wrote: > Oh well. Guess I wasn't thinking big enough. > > Michael > > > On 7/3/07 3:54 AM, "Hamish" wrote: > >> Michael Barton wrote: >>> How about making d.barscale be approximately accurate in latlon near >>> the bottom of the map and say so in the docs? Not ideal, but useable >>> perhaps. >> >> In short, no. >> >> e.g. whole world etopo2/nasa blue marble/admin98: >> g.region n=90 s=-90 w=-180 e=180 >> >> horizontal scale at the bottom of the map (s pole) is a singularity. >> even if you use the center of the region (equator) it is badly wrong >> over most of the map. I though about testing to see if the region was >> small enough for the scale not to change much (>1-2 pixel) over the >> spread of the map, but then it is still a different scale in the x and y >> dirs unless you are on the equator. >> >> >> Hamish > > __________________________________________ > Michael Barton, Professor of Anthropology > Director of Graduate Studies > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- <:3 )---- Wolf Bergenheim ----( 8:> From wolf+grass at bergenheim.net Wed Jul 4 00:05:19 2007 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Wed Jul 4 00:05:53 2007 Subject: [GRASS-dev] Some questions about standardization In-Reply-To: <468AC185.6030905@jemila.jazztel.es> References: <4689303B.4050604@jemila.jazztel.es> <4689DE46.80800@bergenheim.net> <468AC185.6030905@jemila.jazztel.es> Message-ID: <468AC81F.8080009@bergenheim.net> On 04.07.2007 00:37, Carlos D?vila wrote: > > I have done some changes as suggested in /display/d.text, d.text.new and > d.title ("Unable to open the temporary file." to "Unable to open > temporary file <%s>". Despite they compile without problems for me, > could anyone check they are right? :-\ They are fine. They should work just fine. --Wolf -- <:3 )---- Wolf Bergenheim ----( 8:> From hmitaso at unity.ncsu.edu Wed Jul 4 04:18:41 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Wed Jul 4 04:18:55 2007 Subject: [GRASS-dev] using slope/aspect functions inside our module In-Reply-To: <200707031329.04522.yann.chemin@gmail.com> References: <200707031329.04522.yann.chemin@gmail.com> Message-ID: <6A5C4B17-38A9-4C17-A943-B67D98F4F742@unity.ncsu.edu> On Jul 3, 2007, at 2:29 AM, Yann wrote: > Hello, > > In a given chain processing module (DN->high-level product) in > development, > there is a need of calculating slope and aspect, i would like to > use the > existing code as a library or something to the similar effect. > > Anyone could explain if it is possible and how it could be possible? it would be useful to have such library functions but you would have write them based on r.slope.aspect. You can also look at aspect.c in raster/r.flow it should be easy to add slope to it or modify it as a separate function for slope. It should use the same algorithm as r.slope.aspect but double check that. If you need to handle lat/long, look at r.slope.aspect how to do it. Helena > > thank you > Yann > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From woklist at kyngchaos.com Wed Jul 4 04:50:02 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Wed Jul 4 04:50:36 2007 Subject: [GRASS-dev] Postgres DB driver links to TclTk? Message-ID: <4F77643C-2F0F-4785-A8B6-320747B2EE6C@kyngchaos.com> I was poking around and noticed that the GRASS Postgres DB driver links the TclTk libraries. It also has the the TclTk include dirs in the CFLAGS. But it doesn't appear to use any TclTk functions. None of the other DB drivers uses TclTk. mistake? ----- William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect From hamish_nospam at yahoo.com Wed Jul 4 05:46:35 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jul 4 05:47:01 2007 Subject: [GRASS-dev] how to deal with the @mapset in scripts? In-Reply-To: References: <1183413178.25087.103.camel@localhost.localdomain> <18058.18659.813821.751284@cerise.gclements.plus.com> Message-ID: <20070704154635.68a72fa9.hamish_nospam@yahoo.com> Carlos \ wrote: > the @mapset is not a problem when the maps are used by some command, > like r.mapcalc, bu it is a problem because the default output map (if > you don't give a name) will be based on the input, like: > input : in_map > output : in_map_roughness_3x3 > > so I need to get rid of the @mapset, or else it will be set to > > in_map@mapset_roughness_3x3 > > and r.mapcalc will fail. OUTMAP="`echo "$INMAP" | cut -f1 -d'@'`_roughness_3x3" Hamish From soerengebbert at gmx.de Wed Jul 4 07:52:01 2007 From: soerengebbert at gmx.de (=?ISO-8859-1?Q?S=F6ren_Gebbert?=) Date: Wed Jul 4 07:52:58 2007 Subject: Fwd: Re: [GRASS-dev] VTK export for lat-long locations In-Reply-To: <17902.19497.769116.476585@cerise.gclements.plus.com> References: <20070306150813.116740@gmx.net> <17902.19497.769116.476585@cerise.gclements.plus.com> Message-ID: <468B3581.5050405@gmx.de> Hi, Glynn Clements wrote: > "S?ren Gebbert" wrote: > >> please dont use the vtk export modules with lat/lon projections. >> The vtk export modules in grass are not >> usable with lat/lon projections right now. >> I think i should put this info to the html docs. >> >> The lat/lon coordiantes are used to define the coordinates for each point. >> VTK interpret these coordinates as planimetric and not as lat/lon. >> This is not that bad for x,y coordinates, but for the height (z coordinate). >> Because if x and y lat/lon coordiantes are of type [54.001/34.002] and the >> height varies from 0m - 500m you will get a senseless result. >> >> I still dont know exactly how to implement a meaningful >> lat/lon ->planimetric coordinate transformation to get rid >> fo this behaviour. >> >> Any suggestions are welcome. > > In increasing order of complexity and accuracy: > > 1. Convert the lat/lon coordinates to radians then multiply by the > radius of the earth (in whatever units the z values use). > > E.g. if the Z values are in metres, using the radius of 6378137m for > the WGS ellipsoid gives a scale factor of pi/180*6378137 ~ 111320 > > [I've noticed Hamish' comment, which essentially suggests the inverse, > i.e. scale the Z values by 1/111320 = 9e-6, so that everything is in > degrees.] > > For a whole-earth map, this should be adequate; you will still get > horizontal stretching as you move towards the poles, but no more so > than is inherent with lat/lon. I have implemented this approach in r.out.vtk, r3.out.vtk and v.out.vtk. The code is available in CVS. Soeren > > 2. As above, but scale the y coordinates by 111320 and the x > coordinates by 111320*cos(lat), where lat is the mean latitude of your > region. The main issue here is that, if the range of latitudes is > significant, the choice of centre for the x scaling will make a > difference to the shape of the projected data. > > 3. Pick an "appropriate" geographic projection and transform the > coordinates into that projection. The choice of projection needs to be > done manually, based upon the size, shape and location of your region, > and the relative importance of various properties (equidistant, > equal-area, conformal, etc). > From neteler at itc.it Wed Jul 4 09:14:21 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Jul 4 09:14:48 2007 Subject: [GRASS-dev] time to release 6.2.2 In-Reply-To: <18057.20573.933692.445915@cerise.gclements.plus.com> References: <20070701190509.GA28159@bartok.itc.it> <4688BB2B.8030908@itc.it> <46892DF0.2000003@itc.it> <18057.20573.933692.445915@cerise.gclements.plus.com> Message-ID: <468B48CD.3070204@itc.it> Glynn Clements wrote on 07/02/2007 09:22 PM: > Markus Neteler wrote: > >> I found this documentation: >> http://cvsnt.org/manual/html/Modifying-tags.html >> >> Anyone with experience...? >> > > If you want to discard the existing grass_6_2_2 tag and tag the > current version: > > cvs rtag -d grass_6_2_2 grass6 Tag removed. Now we can start with more sensible tag names :) Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From neteler at itc.it Wed Jul 4 09:35:43 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Jul 4 09:35:55 2007 Subject: [GRASS-dev] using slope/aspect functions inside our module In-Reply-To: <200707031329.04522.yann.chemin@gmail.com> References: <200707031329.04522.yann.chemin@gmail.com> Message-ID: <468B4DCF.5010103@itc.it> Yann wrote on 07/03/2007 08:29 AM: > Hello, > > In a given chain processing module (DN->high-level product) in development, > there is a need of calculating slope and aspect, i would like to use the > existing code as a library or something to the similar effect. > > Anyone could explain if it is possible and how it could be possible? > A fancy solution would be to wrap r.slope.aspect in SWIG. See swig/perl/R_slope_aspect/ But a good solution would not make a local copy of the code. FYI: I have just updated the PERL part of the SWIG interface to the current 6.3 state. Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From hamish_nospam at yahoo.com Wed Jul 4 09:44:14 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jul 4 09:44:36 2007 Subject: [GRASS-dev] v.rast.stats - was Re: QGIS winGRASS blank space problem In-Reply-To: <11273304.post@talk.nabble.com> References: <20070604132305.GE4703@bartok.itc.it> <18020.14673.312942.124098@cerise.gclements.plus.com> <20070605131147.3a68513a.hamish_nospam@yahoo.com> <18021.29141.175622.88333@cerise.gclements.plus.com> <20070606153207.24c24e92.hamish_nospam@yahoo.com> <18022.50007.138879.861506@cerise.gclements.plus.com> <11273304.post@talk.nabble.com> Message-ID: <20070704194414.2d6087e0.hamish_nospam@yahoo.com> > Glynn Clements wrote: > >> > Also, I would be inclined to clean up the above by looping over > >> > the column names i.e.: > >> > > >> > ( > >> > for var in n min max range mean stddev variance cf_var sum ; do > >> > eval val=\${$var} > >> > if [ $DBFDRIVER -eq 1 ] ; then > >> > col="`echo ${COLPREFIX}_${var}| cut -b1-10`" > >> > else > >> > col="${COLPREFIX}_${var}" > >> > fi > >> > echo "UPDATE $VECTOR SET ${col}=${val} WHERE cat=$i;" > >> > ) | db.execute database=$DB_DATABASE driver=$DB_SQLDRIVER Markus: > I have seen the changes in CVS. Is the module now (way) faster? > That would be great. db.execute is now run once per session when it used to run once per cat. It should be slightly faster. The bigger improvement is with code readability/simplicity. Note it doesn't follow the (...) | db.execute method shown above, it writes all commands to a file and then passes that to db.execute. (debugging is easier with a paper trail) Hamish From hamish_nospam at yahoo.com Wed Jul 4 10:02:32 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jul 4 10:02:52 2007 Subject: [GRASS-dev] GUI region setting In-Reply-To: References: Message-ID: <20070704200232.59567494.hamish_nospam@yahoo.com> Michael Barton wrote: > > One very useful tool would be one that could allow a user to change > the working environment among different locations. There is a tool to > do this currently (I think it uses g.gisenv internally), but it > doesn't work very well due to internal issues in GRASS. g.mapset (not ending with a "s") An advantage of this module is that it is softer than the g.gisenv solution, e.g. it calls $GISBASE/etc/clean_temp as it leaves the old mapset. Description: Change current mapset Keywords: general Usage: g.mapset [-c] mapset=string [location=string] [gisdbase=string] [--verbose] [--quiet] Flags: -c Create mapset if it doesn't exist --v Verbose module output --q Quiet module output Parameters: mapset New MAPSET name location New LOCATION name (not location path) gisdbase New GISDBASE (full path to the directory where the new location is) Hamish From hamish_nospam at yahoo.com Wed Jul 4 10:16:03 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jul 4 10:16:21 2007 Subject: [GRASS-dev] r.recode workaround In-Reply-To: References: Message-ID: <20070704201603.3d4db17a.hamish_nospam@yahoo.com> Michael Barton wrote: > I've identified why r.recode was not recognizing the last term of the > last recode rule. It needs a newline (\n) after the last recode rule > in order to read all terms. > > I don't think it worked like that before, but it is not a problem once > you know what to do. I've modified both the wxPython and TclTk GUI's > for rules entry to add a newline to r.recode rules and it all works > fine. The first task is to change the fgets() call in r.recode/read_rules.c to G_getl2(). Then see if the bug is still there. G_getl2() doesn't store the newline but fgets() does. if (isatty(fileno(fp))) fprintf (stderr,"> "); if (!fgets(buf,1024,fp)) return nrules; buf[strlen(buf)-1] = '\0'; // ^^^ chops off the newline char using a blind brute force method. // if fgets() ended because of EOF, the last char is real data. for (n=0;buf[n];n++) if(buf[n] == ',') buf[n] = ' '; G_strip(buf); if (*buf == 0) continue; if (*buf == '#') continue; if (strcmp(buf, "end") == 0) break; Hamish From hamish_nospam at yahoo.com Wed Jul 4 10:26:49 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jul 4 10:26:57 2007 Subject: [GRASS-dev] [grass-code I][436] Concurrent quiet and verbose mode in v.in.gpsbabel In-Reply-To: <20070629192716.A5C34400B9@pyrosoma.intevation.org> References: <20070629192716.A5C34400B9@pyrosoma.intevation.org> Message-ID: <20070704202649.60bb4c7e.hamish_nospam@yahoo.com> > code I item #436, was opened at 2007-06-29 21:27 http://wald.intevation.org/tracker/?func=detail&atid=204&aid=436&group_id=21 > Submitted By: Carlos D??vila (carluti) > Summary: Concurrent quiet and verbose mode in v.in.gpsbabel > Issue type: module bad feature .. > In the v.in.gpsbabel both quiet and verbose mode can be chosen at the > same time. Isn't it contradictory? This is true of all modules. Sure it makes no sense, but why is it a problem? Hamish From neteler at itc.it Wed Jul 4 11:06:59 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Jul 4 11:07:01 2007 Subject: [GRASS-dev] Postgres DB driver links to TclTk? In-Reply-To: <4F77643C-2F0F-4785-A8B6-320747B2EE6C@kyngchaos.com> References: <4F77643C-2F0F-4785-A8B6-320747B2EE6C@kyngchaos.com> Message-ID: <468B6333.3020200@itc.it> William Kyngesburye wrote on 07/04/2007 04:50 AM: > I was poking around and noticed that the GRASS Postgres DB driver > links the TclTk libraries. It also has the the TclTk include dirs in > the CFLAGS. But it doesn't appear to use any TclTk functions. None > of the other DB drivers uses TclTk. > Indeed: cd grass63/dist.x86_64-unknown-linux-gnu/driver/db/ ldd pg | tr -s ' ' ' ' | cut -d' ' -f1 | sort /lib64/ld-linux-x86-64.so.2 libcom_err.so.2 libcrypto.so.4 libcrypt.so.1 libc.so.6 libdl.so.2 libgrass_datetime.so libgrass_dbmibase.so libgrass_dbmidriver.so libgrass_dbstubs.so libgrass_gis.so libgrass_sqlp.so libgssapi_krb5.so.2 libk5crypto.so.3 libkrb5.so.3 libm.so.6 libnsl.so.1 libpq.so.4 libpthread.so.0 libresolv.so.2 libssl.so.4 libtcl8.4.so libtk8.4.so libX11.so.6 libz.so.1 > mistake? It doesn't seem to be GRASS: cd grass63/dist.x86_64-unknown-linux-gnu/lib/ for i in `ls -1 *.so | grep -v cvs` ; do echo "======= $i:" ; ldd $i ; done | grep tcl -> nothing No idea where it creeps in (didn't check the system libs). Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From hamish_nospam at yahoo.com Wed Jul 4 11:08:24 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jul 4 11:08:38 2007 Subject: [GRASS-dev] d.rast.edit in wxgrass In-Reply-To: References: Message-ID: <20070704210824.12a3c53c.hamish_nospam@yahoo.com> Michael wrote: > >> 2nd splitting that allows for multiple d.* commands to be separated > >> by semi-colons. This may or may not be a good idea in the end, but > >> I thought I'd see how it worked out. Paul: > > Shell uses semi-colons. But you could you not just enter the two > > commands separately one after the other? I suppose if it was > > something that would take a long time to draw then that would be > > slow. Michael: > The problem is that you need a defined separator that indicates where > one command AND its arguments stop and another one starts. You could > perhaps look for another "d." string, but a defined separator is > easier to use and perhaps more reliable. If you don't like semi-colons, would the newline char work? Hamish From carlos.grohmann at gmail.com Wed Jul 4 13:23:01 2007 From: carlos.grohmann at gmail.com (=?ISO-8859-1?Q?Carlos_"Gu=E2no"_Grohmann?=) Date: Wed Jul 4 13:23:04 2007 Subject: [GRASS-dev] how to deal with the @mapset in scripts? In-Reply-To: <20070704154635.68a72fa9.hamish_nospam@yahoo.com> References: <1183413178.25087.103.camel@localhost.localdomain> <18058.18659.813821.751284@cerise.gclements.plus.com> <20070704154635.68a72fa9.hamish_nospam@yahoo.com> Message-ID: Many thanks Hamish. Carlos On 7/4/07, Hamish wrote: > Carlos \ wrote: > > the @mapset is not a problem when the maps are used by some command, > > like r.mapcalc, bu it is a problem because the default output map (if > > you don't give a name) will be based on the input, like: > > input : in_map > > output : in_map_roughness_3x3 > > > > so I need to get rid of the @mapset, or else it will be set to > > > > in_map@mapset_roughness_3x3 > > > > and r.mapcalc will fail. > > > OUTMAP="`echo "$INMAP" | cut -f1 -d'@'`_roughness_3x3" > > > > Hamish > -- +-----------------------------------------------------------+ Carlos Henrique Grohmann - Guano Visiting Researcher at Kingston University London - UK Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - carlos dot grohmann at gmail dot com +-----------------------------------------------------------+ _________________ "Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive." --The winning entry in a "What were HAL's first words" contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke From glynn at gclements.plus.com Wed Jul 4 13:56:15 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Jul 4 13:56:18 2007 Subject: [GRASS-dev] how to deal with the @mapset in scripts? In-Reply-To: <20070704154635.68a72fa9.hamish_nospam@yahoo.com> References: <1183413178.25087.103.camel@localhost.localdomain> <18058.18659.813821.751284@cerise.gclements.plus.com> <20070704154635.68a72fa9.hamish_nospam@yahoo.com> Message-ID: <18059.35551.95457.131563@cerise.gclements.plus.com> Hamish wrote: > > the @mapset is not a problem when the maps are used by some command, > > like r.mapcalc, bu it is a problem because the default output map (if > > you don't give a name) will be based on the input, like: > > input : in_map > > output : in_map_roughness_3x3 > > > > so I need to get rid of the @mapset, or else it will be set to > > > > in_map@mapset_roughness_3x3 > > > > and r.mapcalc will fail. > > OUTMAP="`echo "$INMAP" | cut -f1 -d'@'`_roughness_3x3" OUTMAP="${INMAP%%@*}_roughness_3x3" The ${var%%pattern} syntax should be portable, according to: http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_02 -- Glynn Clements From glynn at gclements.plus.com Wed Jul 4 13:59:56 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Jul 4 13:59:59 2007 Subject: [GRASS-dev] how to deal with the @mapset in scripts? In-Reply-To: <468A6400.9070600@o2.pl> References: <1183413178.25087.103.camel@localhost.localdomain> <18058.18659.813821.751284@cerise.gclements.plus.com> <468A6400.9070600@o2.pl> Message-ID: <18059.35772.717729.838323@cerise.gclements.plus.com> Maciej Sieczka wrote: > > Why do you actually need to use g.findfile? In most cases, you should > > just pass the map name directly to the command, and let the command > > handle the checking. > > It's better to check if the output exists in the initial stage of my > script, than to let it run for an hour and then fail with an error that > the output already exists in the end. If the output map is specified by an option whose "gisprompt" setting includes "new", g.parser will automatically ensure that it doesn't exist unless --o[verwrite] is given or $GRASS_OVERWRITE == 1. Also, if --o is passed to the script, GRASS_OVERWRITE will be set automatically, so any commands invoked from the script will overwrite output maps. -- Glynn Clements From glynn at gclements.plus.com Wed Jul 4 14:14:40 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Jul 4 14:14:48 2007 Subject: [GRASS-dev] using slope/aspect functions inside our module In-Reply-To: <200707031329.04522.yann.chemin@gmail.com> References: <200707031329.04522.yann.chemin@gmail.com> Message-ID: <18059.36656.52488.619918@cerise.gclements.plus.com> Yann wrote: > In a given chain processing module (DN->high-level product) in development, > there is a need of calculating slope and aspect, i would like to use the > existing code as a library or something to the similar effect. > > Anyone could explain if it is possible and how it could be possible? It isn't practical to use code from a module in a library. Even if it was, calculating slope/aspect is so trivial that it's easier to just write it from scratch than to extract the code from r.slope.aspect. FWIW, the calculation which r.slope.aspect uses is essentially: dx = ((c1 + 2*c4 + c7) - (c3 + 2*c6 + c9)) / (4 * ewres); dy = ((c7 + 2*c8 + c9) - (c1 + 2*c2 + c3)) / (4 * nsres); key = dx*dx + dy*dy; slp_in_perc = 100*sqrt(key); slp_in_deg = atan(sqrt(key)) * radians_to_degrees; aspect = (atan2(dy,dx)/degrees_to_radians); where the cells are labelled: c1 c2 c3 c4 c5 c6 c7 c8 c9 -- Glynn Clements From glynn at gclements.plus.com Wed Jul 4 14:28:47 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Jul 4 14:28:50 2007 Subject: [GRASS-dev] Postgres DB driver links to TclTk? In-Reply-To: <468B6333.3020200@itc.it> References: <4F77643C-2F0F-4785-A8B6-320747B2EE6C@kyngchaos.com> <468B6333.3020200@itc.it> Message-ID: <18059.37503.510693.442803@cerise.gclements.plus.com> Markus Neteler wrote: > > I was poking around and noticed that the GRASS Postgres DB driver > > links the TclTk libraries. It also has the the TclTk include dirs in > > the CFLAGS. But it doesn't appear to use any TclTk functions. None > > of the other DB drivers uses TclTk. > > > Indeed: > cd grass63/dist.x86_64-unknown-linux-gnu/driver/db/ > ldd pg | tr -s ' ' ' ' | cut -d' ' -f1 | sort > /lib64/ld-linux-x86-64.so.2 > libcom_err.so.2 > libcrypto.so.4 > libcrypt.so.1 > libc.so.6 > libdl.so.2 > libgrass_datetime.so > libgrass_dbmibase.so > libgrass_dbmidriver.so > libgrass_dbstubs.so > libgrass_gis.so > libgrass_sqlp.so > libgssapi_krb5.so.2 > libk5crypto.so.3 > libkrb5.so.3 > libm.so.6 > libnsl.so.1 > libpq.so.4 > libpthread.so.0 > libresolv.so.2 > libssl.so.4 > libtcl8.4.so > libtk8.4.so > libX11.so.6 > libz.so.1 > > > mistake? > > It doesn't seem to be GRASS: > cd grass63/dist.x86_64-unknown-linux-gnu/lib/ > for i in `ls -1 *.so | grep -v cvs` ; do echo "======= $i:" ; ldd $i ; > done | grep tcl > -> nothing > > No idea where it creeps in (didn't check the system libs). It's in db/drivers/postgres/Makefile: 14 EXTRA_CFLAGS = $(PQINCPATH) $(TCLINCDIR) $(TKINCDIR) 26 $(CC) $(LDFLAGS) -o $@ $(ARCH_OBJS) $(FMODE_OBJ) $(PQLIBPATH) $(LIBES) $(TCLTKLIBPATH) $(TCLTKLIBS) \ Those options were added in: revision 1.4 date: 2003/01/15 15:36:24; author: radim; state: Exp; lines: +6 -3 parser for database, user/password dialog No idea why; I'll remove them. -- Glynn Clements From neteler at itc.it Wed Jul 4 14:32:41 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Jul 4 14:32:43 2007 Subject: [GRASS-dev] time to release 6.2.2 In-Reply-To: <18057.19960.314582.189066@cerise.gclements.plus.com> References: <20070701190509.GA28159@bartok.itc.it> <4688BB2B.8030908@itc.it> <18057.19960.314582.189066@cerise.gclements.plus.com> Message-ID: <468B9369.4020504@itc.it> Glynn Clements wrote on 07/02/2007 09:11 PM: > Markus Neteler wrote: >>> I still think it is a good idea to include the date of releases in the >>> tag name, less confusion that way, e.g. release_20070702_grass_6_2_2 - >>> what do you think? Or is there any other way of telling from CVS on >>> what date the tag was created? >>> >> I don't know but I remember that someone (Glynn?) suggested to NOT >> include the date so that it wasn't done any more. >> > > I don't have any recollection of that. > > Ok. Since everybody is happy, we'll re-introduce the date into the tag. Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From neteler at itc.it Wed Jul 4 14:36:52 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Jul 4 14:36:54 2007 Subject: [GRASS-dev] Postgres DB driver links to TclTk? In-Reply-To: <18059.37503.510693.442803@cerise.gclements.plus.com> References: <4F77643C-2F0F-4785-A8B6-320747B2EE6C@kyngchaos.com> <468B6333.3020200@itc.it> <18059.37503.510693.442803@cerise.gclements.plus.com> Message-ID: <20070704123652.GD5227@bartok.itc.it> On Wed, Jul 04, 2007 at 01:28:47PM +0100, Glynn Clements wrote: ... > It's in db/drivers/postgres/Makefile: > > 14 EXTRA_CFLAGS = $(PQINCPATH) $(TCLINCDIR) $(TKINCDIR) > > 26 $(CC) $(LDFLAGS) -o $@ $(ARCH_OBJS) $(FMODE_OBJ) $(PQLIBPATH) $(LIBES) $(TCLTKLIBPATH) $(TCLTKLIBS) \ Ah! Obvious place to look at first... > Those options were added in: > > revision 1.4 > date: 2003/01/15 15:36:24; author: radim; state: Exp; lines: +6 -3 > parser for database, user/password dialog > > No idea why; I'll remove them. AFAIR, there was for a (short) time a tcl/tk based login dialogue, but: 2004-10-25 19:09 radim * Makefile, db.c: login dialog removed Markus From tutey at o2.pl Wed Jul 4 15:17:29 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Jul 4 15:17:35 2007 Subject: [GRASS-dev] how to deal with the @mapset in scripts? In-Reply-To: <18059.35772.717729.838323@cerise.gclements.plus.com> References: <1183413178.25087.103.camel@localhost.localdomain> <18058.18659.813821.751284@cerise.gclements.plus.com> <468A6400.9070600@o2.pl> <18059.35772.717729.838323@cerise.gclements.plus.com> Message-ID: <468B9DE9.3050800@o2.pl> Glynn Clements wrote: > Maciej Sieczka wrote: > >>> Why do you actually need to use g.findfile? In most cases, you should >>> just pass the map name directly to the command, and let the command >>> handle the checking. >> It's better to check if the output exists in the initial stage of my >> script, than to let it run for an hour and then fail with an error that >> the output already exists in the end. > > If the output map is specified by an option whose "gisprompt" setting > includes "new", g.parser will automatically ensure that it doesn't > exist unless --o[verwrite] is given or $GRASS_OVERWRITE == 1. You are correct. The reason that this has not worked for me like that is that I've been using "gisprompt: new,dig,vector" instead of "gisprompt: new,vector,vector". I must have copied this "gisprompt: new,dig,vector" from some GRASS 5 script and sticked to that. None of the scripts in 6.3 uses it. Is this not supposed to be recognised by g.parser indeed? There isn't any error message that this is incorrect. Should there be one? Grepping through the GRASS 6.3 source code I can see that v.surf.rst still uses the old syntax in main.c twice. Should that be fixed? Maciek From carlos.grohmann at gmail.com Wed Jul 4 15:42:39 2007 From: carlos.grohmann at gmail.com (=?ISO-8859-1?Q?Carlos_"Gu=E2no"_Grohmann?=) Date: Wed Jul 4 15:42:41 2007 Subject: [GRASS-dev] using slope/aspect functions inside our module In-Reply-To: <18059.36656.52488.619918@cerise.gclements.plus.com> References: <200707031329.04522.yann.chemin@gmail.com> <18059.36656.52488.619918@cerise.gclements.plus.com> Message-ID: Interesting. Why r.slope.aspect uses dx = ... / (4 * ewres); while r.shaded.relief uses dx = ... / (8 * ewres); ?? BTW there is a typo in r.shaded.relief in line 137 ("Nap"): g.message -e "Nap <$elev> not found." Carlos On 7/4/07, Glynn Clements wrote: > > Yann wrote: > > > In a given chain processing module (DN->high-level product) in development, > > there is a need of calculating slope and aspect, i would like to use the > > existing code as a library or something to the similar effect. > > > > Anyone could explain if it is possible and how it could be possible? > > It isn't practical to use code from a module in a library. > > Even if it was, calculating slope/aspect is so trivial that it's > easier to just write it from scratch than to extract the code from > r.slope.aspect. > > FWIW, the calculation which r.slope.aspect uses is essentially: > > dx = ((c1 + 2*c4 + c7) - (c3 + 2*c6 + c9)) / (4 * ewres); > dy = ((c7 + 2*c8 + c9) - (c1 + 2*c2 + c3)) / (4 * nsres); > key = dx*dx + dy*dy; > slp_in_perc = 100*sqrt(key); > slp_in_deg = atan(sqrt(key)) * radians_to_degrees; > aspect = (atan2(dy,dx)/degrees_to_radians); > > where the cells are labelled: > > c1 c2 c3 > c4 c5 c6 > c7 c8 c9 > > -- > Glynn Clements > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- +-----------------------------------------------------------+ Carlos Henrique Grohmann - Guano Visiting Researcher at Kingston University London - UK Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - carlos dot grohmann at gmail dot com +-----------------------------------------------------------+ _________________ "Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive." --The winning entry in a "What were HAL's first words" contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke From woklist at kyngchaos.com Wed Jul 4 16:29:35 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Wed Jul 4 16:29:43 2007 Subject: [GRASS-dev] Postgres DB driver links to TclTk? In-Reply-To: <20070704123652.GD5227@bartok.itc.it> References: <4F77643C-2F0F-4785-A8B6-320747B2EE6C@kyngchaos.com> <468B6333.3020200@itc.it> <18059.37503.510693.442803@cerise.gclements.plus.com> <20070704123652.GD5227@bartok.itc.it> Message-ID: On Jul 4, 2007, at 7:36 AM, Markus Neteler wrote: >> Those options were added in: >> >> revision 1.4 >> date: 2003/01/15 15:36:24; author: radim; state: Exp; lines: >> +6 -3 >> parser for database, user/password dialog >> >> No idea why; I'll remove them. > > AFAIR, there was for a (short) time a tcl/tk based login > dialogue, but: > > 2004-10-25 19:09 radim > * Makefile, db.c: login dialog removed I thought it might be some kind of leftover (I haven't got the hang of looking back thru revision history yet). So, will you remove it from 6.2 also? ----- William Kyngesburye http://www.kyngchaos.com/ "I ache, therefore I am. Or in my case - I am, therefore I ache." - Marvin From neteler at itc.it Wed Jul 4 17:01:07 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Jul 4 17:01:09 2007 Subject: [GRASS-dev] Postgres DB driver links to TclTk? In-Reply-To: References: <4F77643C-2F0F-4785-A8B6-320747B2EE6C@kyngchaos.com> <468B6333.3020200@itc.it> <18059.37503.510693.442803@cerise.gclements.plus.com> <20070704123652.GD5227@bartok.itc.it> Message-ID: <468BB633.7090703@itc.it> William Kyngesburye wrote on 07/04/2007 04:29 PM: > On Jul 4, 2007, at 7:36 AM, Markus Neteler wrote: > >>> Those options were added in: >>> >>> revision 1.4 >>> date: 2003/01/15 15:36:24; author: radim; state: Exp; lines: >>> +6 -3 >>> parser for database, user/password dialog >>> >>> No idea why; I'll remove them. >> >> AFAIR, there was for a (short) time a tcl/tk based login >> dialogue, but: >> >> 2004-10-25 19:09 radim >> * Makefile, db.c: login dialog removed > > I thought it might be some kind of leftover (I haven't got the hang of > looking back thru revision history yet). > > So, will you remove it from 6.2 also? Yes. Both Makefiles cleaned. Thanks for catching. Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From neteler at itc.it Wed Jul 4 17:10:01 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Jul 4 17:10:02 2007 Subject: [GRASS-dev] how to deal with the @mapset in scripts? In-Reply-To: <468B9DE9.3050800@o2.pl> References: <1183413178.25087.103.camel@localhost.localdomain> <18058.18659.813821.751284@cerise.gclements.plus.com> <468A6400.9070600@o2.pl> <18059.35772.717729.838323@cerise.gclements.plus.com> <468B9DE9.3050800@o2.pl> Message-ID: <468BB849.3010006@itc.it> Maciej Sieczka wrote on 07/04/2007 03:17 PM: > Grepping through the GRASS 6.3 source code I can see that v.surf.rst > still uses the old syntax in main.c twice. Should that be fixed? > Yes. Done so, also applied predefined parser macros. Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From glynn at gclements.plus.com Wed Jul 4 17:35:27 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Jul 4 17:35:31 2007 Subject: [GRASS-dev] how to deal with the @mapset in scripts? In-Reply-To: <468B9DE9.3050800@o2.pl> References: <1183413178.25087.103.camel@localhost.localdomain> <18058.18659.813821.751284@cerise.gclements.plus.com> <468A6400.9070600@o2.pl> <18059.35772.717729.838323@cerise.gclements.plus.com> <468B9DE9.3050800@o2.pl> Message-ID: <18059.48703.917314.314840@cerise.gclements.plus.com> Maciej Sieczka wrote: > >>> Why do you actually need to use g.findfile? In most cases, you should > >>> just pass the map name directly to the command, and let the command > >>> handle the checking. > >> It's better to check if the output exists in the initial stage of my > >> script, than to let it run for an hour and then fail with an error that > >> the output already exists in the end. > > > > If the output map is specified by an option whose "gisprompt" setting > > includes "new", g.parser will automatically ensure that it doesn't > > exist unless --o[verwrite] is given or $GRASS_OVERWRITE == 1. > > You are correct. The reason that this has not worked for me like that > is that I've been using "gisprompt: new,dig,vector" instead of > "gisprompt: new,vector,vector". > > I must have copied this "gisprompt: new,dig,vector" from some GRASS 5 > script and sticked to that. None of the scripts in 6.3 uses it. Is this > not supposed to be recognised by g.parser indeed? There isn't any error > message that this is incorrect. Should there be one? g.parser is just a front-end to G_parser(). The syntax of "valid" options is essentially whatever G_parser() accepts. In turn, G_parser() silently ignores any gisprompt keys which it doesn't understand. > Grepping through the GRASS 6.3 source code I can see that v.surf.rst > still uses the old syntax in main.c twice. Should that be fixed? Probably. -- Glynn Clements From glynn at gclements.plus.com Wed Jul 4 17:41:50 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Jul 4 17:41:53 2007 Subject: [GRASS-dev] using slope/aspect functions inside our module In-Reply-To: References: <200707031329.04522.yann.chemin@gmail.com> <18059.36656.52488.619918@cerise.gclements.plus.com> Message-ID: <18059.49086.129208.14164@cerise.gclements.plus.com> "Carlos \"Gu?no\" Grohmann" wrote: > Interesting. > Why r.slope.aspect uses > > dx = ... / (4 * ewres); > > while r.shaded.relief uses > > dx = ... / (8 * ewres); > > ?? Oops. It should be 8; the ewres/nsres values are actually the distances between the centres of the top/bottom rows and left/right columns in the 3x3 window, which are two rows/columns apart. IOW, the 4*ewres should have been 4*(2*ewres) = 8*ewres, ditto for nsres. -- Glynn Clements From michael.barton at asu.edu Wed Jul 4 20:31:29 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Jul 4 20:31:39 2007 Subject: [GRASS-dev] datumtransform.table question Message-ID: Glynn and Paul, I'm hoping you can help me clear up an issue with datum transforms. I've got the location wizard in wxgrass creating PROJ.4 strings and ready to test it making new locations that way. I've run into an odd problem. I went to test it using my home state of Arizona, wanting to see the PROJ.4 string for UTM, zone 12, with a NAD83 datum. The problem is in the datum transform table. If I use the old g.setproj and pick UTM zone 12, I am prompted to enter a datum transform. There are 6 choices, listed here... Enter 'list' to see the list of available Parameter sets Enter the corresponding number, or to cancel request >list Number Details --- 1 Used in whole nad83 region (PROJ.4 Params towgs84=0.000,0.000,0.000) Default 3-Parameter Transformation (May not be optimum for older datums; use this only if no more appropriate options are available.) --- 2 Used in Florida (PROJ.4 Params nadgrids=FL) Transforms 'Old NAD83' to 'HPGN NAD83' --- 3 Used in Maryland (PROJ.4 Params nadgrids=MD) Transforms 'Old NAD83' to 'HPGN NAD83' --- 4 Used in Tennessee (PROJ.4 Params nadgrids=TN) Transforms 'Old NAD83' to 'HPGN NAD83' --- 5 Used in Wisconsin (PROJ.4 Params nadgrids=WI) Transforms 'Old NAD83' to 'HPGN NAD83' --- 6 Used in Washington - Oregon (PROJ.4 Params nadgrids=WO) Transforms 'Old NAD83' to 'HPGN NAD83' --- When I pick #1 for Arizona, this create a location with PROJ.4 settings as follows (retrieved with g.proj -j)... +proj=utm +zone=12 +a=6378137 +rf=298.257222101 +no_defs +towgs84=0.000,0.000,0.000 +to_meter=1.0 However, the datumtransform.table file lacks transform #1. Here are all the NAD83 entries. You can see, that they include transforms #2-6, but that #1 is missing. nad83 "nadgrids=FL" "Florida" "Transforms 'Old NAD83' to 'HPGN NAD83'" nad83 "nadgrids=MD" "Maryland" "Transforms 'Old NAD83' to 'HPGN NAD83'" nad83 "nadgrids=TN" "Tennessee" "Transforms 'Old NAD83' to 'HPGN NAD83'" nad83 "nadgrids=WI" "Wisconsin" "Transforms 'Old NAD83' to 'HPGN NAD83'" nad83 "nadgrids=WO" "Washington - Oregon" "Transforms 'Old NAD83' to 'HPGN NAD83'" Transform #1 seems to be a kind of generic one for NAD83, but is quite useful programmatically. I've got error checking such that, if there is a match for datum transforms between datum.table and datumtransform.table, you need to pick a transform before continuing--the same as with g.setproj. This prevents users from picking a datum without transforms when one is required. I can drop this check, but it could be confusing to users to be presented with a list of transforms, none of which fit their situation. It would be better to have a generic transform, like #1, available so that there is always something to pick if transforms show up. Since datumtransform.table is created out of the same data used by g.setproj, I'm wondering what happened to transform #1 in the example above. Could this also be a problem with other datum/transform combinations? Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Wed Jul 4 20:33:16 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Jul 4 20:33:22 2007 Subject: [GRASS-dev] d.rast.edit in wxgrass In-Reply-To: <20070704210824.12a3c53c.hamish_nospam@yahoo.com> Message-ID: I'm happy with semicolons, but want to know if everyone else is. Newlines won't work. A newline (hitting enter/return from the keyboard) causes the command to be parsed. Michael On 7/4/07 2:08 AM, "Hamish" wrote: > Michael wrote: >>>> 2nd splitting that allows for multiple d.* commands to be separated >>>> by semi-colons. This may or may not be a good idea in the end, but >>>> I thought I'd see how it worked out. > Paul: >>> Shell uses semi-colons. But you could you not just enter the two >>> commands separately one after the other? I suppose if it was >>> something that would take a long time to draw then that would be >>> slow. > Michael: >> The problem is that you need a defined separator that indicates where >> one command AND its arguments stop and another one starts. You could >> perhaps look for another "d." string, but a defined separator is >> easier to use and perhaps more reliable. > > If you don't like semi-colons, would the newline char work? > > > Hamish __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From paul-grass at stjohnspoint.co.uk Thu Jul 5 00:21:48 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Thu Jul 5 00:21:59 2007 Subject: [GRASS-dev] Re: datumtransform.table question In-Reply-To: References: Message-ID: On Wed, 4 Jul 2007, Michael Barton wrote: > Glynn and Paul, > > I'm hoping you can help me clear up an issue with datum transforms. > > I've got the location wizard in wxgrass creating PROJ.4 strings and ready to > test it making new locations that way. I've run into an odd problem. I went > to test it using my home state of Arizona, wanting to see the PROJ.4 string > for UTM, zone 12, with a NAD83 datum. > > The problem is in the datum transform table. > > If I use the old g.setproj and pick UTM zone 12, I am prompted to enter a > datum transform. There are 6 choices, listed here... > > Enter 'list' to see the list of available Parameter sets > Enter the corresponding number, or to cancel request >> list > > Number Details > --- > 1 Used in whole nad83 region > (PROJ.4 Params towgs84=0.000,0.000,0.000) > Default 3-Parameter Transformation (May not be optimum for older > datums; > use this only if no more appropriate options are available.) > --- > 2 Used in Florida > (PROJ.4 Params nadgrids=FL) > Transforms 'Old NAD83' to 'HPGN NAD83' > --- > 3 Used in Maryland > (PROJ.4 Params nadgrids=MD) > Transforms 'Old NAD83' to 'HPGN NAD83' > --- > 4 Used in Tennessee > (PROJ.4 Params nadgrids=TN) > Transforms 'Old NAD83' to 'HPGN NAD83' > --- > 5 Used in Wisconsin > (PROJ.4 Params nadgrids=WI) > Transforms 'Old NAD83' to 'HPGN NAD83' > --- > 6 Used in Washington - Oregon > (PROJ.4 Params nadgrids=WO) > Transforms 'Old NAD83' to 'HPGN NAD83' > --- > > When I pick #1 for Arizona, this create a location with PROJ.4 settings as > follows (retrieved with g.proj -j)... > > +proj=utm > +zone=12 > +a=6378137 > +rf=298.257222101 > +no_defs > +towgs84=0.000,0.000,0.000 > +to_meter=1.0 > > > However, the datumtransform.table file lacks transform #1. Here are all the > NAD83 entries. You can see, that they include transforms #2-6, but that #1 > is missing. In datum.table, the values specified by dx= dy= and dz= , if all less than 99999 (see notes at the top of this file), will be offered to the user as parameter set number 1 in the form towgs84=dx,dy,dz. Sorry for the obscurity of this; it's just an historical artefact of the first (generally unsuccessful) attempt to add datum transformation support to GRASS in the 1990s and something that had to be kept for backwards compatibility when the capability to have multiple parameter sets per datum was added. Paul > > nad83 "nadgrids=FL" "Florida" "Transforms 'Old NAD83' to 'HPGN > NAD83'" > nad83 "nadgrids=MD" "Maryland" "Transforms 'Old NAD83' to 'HPGN > NAD83'" > nad83 "nadgrids=TN" "Tennessee" "Transforms 'Old NAD83' to > 'HPGN NAD83'" > nad83 "nadgrids=WI" "Wisconsin" "Transforms 'Old NAD83' to > 'HPGN NAD83'" > nad83 "nadgrids=WO" "Washington - Oregon" "Transforms 'Old > NAD83' to 'HPGN NAD83'" > > Transform #1 seems to be a kind of generic one for NAD83, but is quite > useful programmatically. I've got error checking such that, if there is a > match for datum transforms between datum.table and datumtransform.table, you > need to pick a transform before continuing--the same as with g.setproj. This > prevents users from picking a datum without transforms when one is required. > > I can drop this check, but it could be confusing to users to be presented > with a list of transforms, none of which fit their situation. It would be > better to have a generic transform, like #1, available so that there is > always something to pick if transforms show up. > > Since datumtransform.table is created out of the same data used by > g.setproj, I'm wondering what happened to transform #1 in the example above. > Could this also be a problem with other datum/transform combinations? > > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > Director of Graduate Studies > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > > From paul-grass at stjohnspoint.co.uk Thu Jul 5 00:26:54 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Thu Jul 5 00:26:57 2007 Subject: [GRASS-dev] Re: g.proj won't parse PROJ.4 string In-Reply-To: References: Message-ID: On Wed, 4 Jul 2007, Michael Barton wrote: > I'm trying to make the location wizard actually create a location and, to my > surprise, it wouldn't parse a PROJ.4 string. There is not example of > inputting a PROJ.4 string in the docs, so I've done some experimentation and > found out why. Here is the PROJ.4 string created out of the values in > projection.table and ellipse.table > > GRASS 6.3.cvs (spearfish60_test):~ > g.proj -c location=test1 > proj4="+proj=ll +a=6378137.000 +f=1/298.257223563 +no_defs" > ERROR: Can't parse PROJ.4-style parameter string > > For this to be accepted by PROJ.4, 'll' must be rewritten as 'longlat', and > the 'f=' parameter must be rewritten as 'rf='. > > Did I just happen to find the 2 problematic spots in these files, or could > there be others? Do either of you happen to know where the GRASS format > differs from PROJ.4 in other places? That's two of the main places - others are datum and ellipsoid names although if you put them in numerical format as above the lib/proj code should do it's best at extracting an alphanumeric ellipsoid name now. But the datum names are still a problem. In fact yes I've been thinking about this the last few days and realised it would be a problem. Using g.proj in this way is more complicated than it first appeared. It may be simpler to manually create the directories (in Python) and write out the PROJ_INFO and PROJ_UNITS files directly. Skeleton DEFAULT_WIND and WIND files would also have to put in too. As I said I don't have a lot of time to devote to this but I'm working on a proposal for how I think a location creation wizard should work (what is included on each screen etc.) and when finished I will post it to the list, in the hope that the thinking behind it will prove to be some help. I'm doing it blind, i.e. without looking at what's there already in the new GUI - hopefully we can then share the best ideas from both approaches. Paul From michael.barton at asu.edu Thu Jul 5 00:37:32 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jul 5 00:37:49 2007 Subject: [GRASS-dev] Re: datumtransform.table question In-Reply-To: Message-ID: On 7/4/07 3:21 PM, "Paul Kelly" wrote: > On Wed, 4 Jul 2007, Michael Barton wrote: > >> Glynn and Paul, >> >> I'm hoping you can help me clear up an issue with datum transforms. >> >> I've got the location wizard in wxgrass creating PROJ.4 strings and ready to >> test it making new locations that way. I've run into an odd problem. I went >> to test it using my home state of Arizona, wanting to see the PROJ.4 string >> for UTM, zone 12, with a NAD83 datum. >> >> The problem is in the datum transform table. >> >> If I use the old g.setproj and pick UTM zone 12, I am prompted to enter a >> datum transform. There are 6 choices, listed here... >> >> Enter 'list' to see the list of available Parameter sets >> Enter the corresponding number, or to cancel request >>> list >> >> Number Details >> --- >> 1 Used in whole nad83 region >> (PROJ.4 Params towgs84=0.000,0.000,0.000) >> Default 3-Parameter Transformation (May not be optimum for older >> datums; >> use this only if no more appropriate options are available.) >> --- >> 2 Used in Florida >> (PROJ.4 Params nadgrids=FL) >> Transforms 'Old NAD83' to 'HPGN NAD83' >> --- >> 3 Used in Maryland >> (PROJ.4 Params nadgrids=MD) >> Transforms 'Old NAD83' to 'HPGN NAD83' >> --- >> 4 Used in Tennessee >> (PROJ.4 Params nadgrids=TN) >> Transforms 'Old NAD83' to 'HPGN NAD83' >> --- >> 5 Used in Wisconsin >> (PROJ.4 Params nadgrids=WI) >> Transforms 'Old NAD83' to 'HPGN NAD83' >> --- >> 6 Used in Washington - Oregon >> (PROJ.4 Params nadgrids=WO) >> Transforms 'Old NAD83' to 'HPGN NAD83' >> --- >> >> When I pick #1 for Arizona, this create a location with PROJ.4 settings as >> follows (retrieved with g.proj -j)... >> >> +proj=utm >> +zone=12 >> +a=6378137 >> +rf=298.257222101 >> +no_defs >> +towgs84=0.000,0.000,0.000 >> +to_meter=1.0 >> >> >> However, the datumtransform.table file lacks transform #1. Here are all the >> NAD83 entries. You can see, that they include transforms #2-6, but that #1 >> is missing. > > In datum.table, the values specified by dx= dy= and dz= , if all less than > 99999 (see notes at the top of this file), will be offered to the user as > parameter set number 1 in the form towgs84=dx,dy,dz. OK. I understand. > > Sorry for the obscurity of this; it's just an historical artefact of the > first (generally unsuccessful) attempt to add datum transformation support > to GRASS in the 1990s and something that had to be kept for backwards > compatibility when the capability to have multiple parameter sets per > datum was added. Is there any way that this can be built explicitly into datumtransform.table when it is created? That is, can this virtual transform 1 be added? It is doable, but not easy, to parse this out after datum.table and datumtransform.table have been created and I'm trying to read them into the location wizard. Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Thu Jul 5 00:41:32 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jul 5 00:41:40 2007 Subject: [GRASS-dev] Re: g.proj won't parse PROJ.4 string In-Reply-To: Message-ID: On 7/4/07 3:26 PM, "Paul Kelly" wrote: > In fact yes I've been thinking about this the last few days and realised > it would be a problem. Using g.proj in this way is more complicated than > it first appeared. It may be simpler to manually create the directories > (in Python) and write out the PROJ_INFO and PROJ_UNITS files directly. > Skeleton DEFAULT_WIND and WIND files would also have to put in too. This also not as easy as it sounds. > > As I said I don't have a lot of time to devote to this but I'm working on > a proposal for how I think a location creation wizard should work (what is > included on each screen etc.) and when finished I will post it to the > list, in the hope that the thinking behind it will prove to be some help. > I'm doing it blind, i.e. without looking at what's there already in the > new GUI - hopefully we can then share the best ideas from both approaches. > Before doing this, can you take a look at the existing location wizard, since it is about 90+% done and represents a big investment. Suggestions for improvements are very welcome, but I'd be loathe to scrap the whole thing unless there is very good reason to do so. I'm currently debugging it since g.proj is not accepting the PROJ.4 strings it is creating, but they've got to be close. All is otherwise working except extents. Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hamish_nospam at yahoo.com Thu Jul 5 05:11:30 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Jul 5 05:11:38 2007 Subject: [GRASS-dev] using slope/aspect functions inside our module In-Reply-To: References: <200707031329.04522.yann.chemin@gmail.com> <18059.36656.52488.619918@cerise.gclements.plus.com> Message-ID: <20070705151130.79d6b5bb.hamish_nospam@yahoo.com> Carlos wrote: > > BTW there is a typo in r.shaded.relief in line 137 ("Nap"): > > g.message -e "Nap <$elev> not found." thanks, fixed. Hamish From hamish_nospam at yahoo.com Thu Jul 5 05:19:32 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Jul 5 05:19:38 2007 Subject: [GRASS-dev] Postgres DB driver links to TclTk? In-Reply-To: References: <4F77643C-2F0F-4785-A8B6-320747B2EE6C@kyngchaos.com> <468B6333.3020200@itc.it> <18059.37503.510693.442803@cerise.gclements.plus.com> <20070704123652.GD5227@bartok.itc.it> Message-ID: <20070705151932.6b750052.hamish_nospam@yahoo.com> William Kyngesburye wrote: > > I thought it might be some kind of leftover (I haven't got the hang > of looking back thru revision history yet). the CVS web interface is very nice for this, http://freegis.org/cgi-bin/viewcvs.cgi/grass6/db/drivers/postgres/Makefile (try "annotate" on an earlier revision to see when the change was made, then look at the cvs comment for that rev, rinse, repeat) Hamish From cdavilam at jemila.jazztel.es Thu Jul 5 18:17:50 2007 From: cdavilam at jemila.jazztel.es (=?ISO-8859-1?Q?Carlos_D=E1vila?=) Date: Thu Jul 5 18:15:05 2007 Subject: [GRASS-dev] time to release 6.2.2 In-Reply-To: <20070701190509.GA28159@bartok.itc.it> References: <20070701190509.GA28159@bartok.itc.it> Message-ID: <468D19AE.6050302@jemila.jazztel.es> Markus Neteler escribi?: > Hi, > > during the testing period of 6.2.2-RC1 we got the following > issues fixed: > ... > * Czech translation updated (Jachym Cepicky) > What about the other languages? Will they be included in the new release and packages? Carlos From michael.barton at asu.edu Thu Jul 5 18:53:02 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jul 5 18:53:14 2007 Subject: [GRASS-dev] Re: g.proj won't parse PROJ.4 string In-Reply-To: Message-ID: I've got the location wizard working and making locations. I haven't committed my newest changes because I'm having trouble with Python parsing of the g.proj command. The main way we are parsing commands is through a custom class cmd.Command. However, this is choking on the g.proj proj4= command. It is probably because of some of the characters, but I'm not getting any meaningful error messages and so it is difficult to debug. The simple os.popen works for datum strings, but won't parse ellipse strings because it stops reading at the forward slash "/" in the f=1/nnnnn parameter. I don't know why, since it's NOT a backslash. I'm going to try subprocess.Popen (the Python command that underlies cmd.Command), but haven't yet had a chance. But the bottom line is that the wizard is now constructing valid PROJ.4 strings and passing them correctly to g.proj. As a brief overview, the wizard does the following: 1. Create a location by choosing a projection (including latlon, not technically a projection) and ellipse OR datum with transform parameters. 2. Create a location using EPSG code 3. Create a location using a georeferenced file 4. Create a location by entering your own PROJ.4 string 5. Create an XY location (this is not yet working because I'm not sure what the best way to do this is). I haven't messed with the extents yet. Michael On 7/4/07 3:26 PM, "Paul Kelly" wrote: > On Wed, 4 Jul 2007, Michael Barton wrote: > >> I'm trying to make the location wizard actually create a location and, to my >> surprise, it wouldn't parse a PROJ.4 string. There is not example of >> inputting a PROJ.4 string in the docs, so I've done some experimentation and >> found out why. Here is the PROJ.4 string created out of the values in >> projection.table and ellipse.table >> >> GRASS 6.3.cvs (spearfish60_test):~ > g.proj -c location=test1 >> proj4="+proj=ll +a=6378137.000 +f=1/298.257223563 +no_defs" >> ERROR: Can't parse PROJ.4-style parameter string >> >> For this to be accepted by PROJ.4, 'll' must be rewritten as 'longlat', and >> the 'f=' parameter must be rewritten as 'rf='. >> >> Did I just happen to find the 2 problematic spots in these files, or could >> there be others? Do either of you happen to know where the GRASS format >> differs from PROJ.4 in other places? > > That's two of the main places - others are datum and ellipsoid names > although if you put them in numerical format as above the lib/proj code > should do it's best at extracting an alphanumeric ellipsoid name now. But > the datum names are still a problem. > > In fact yes I've been thinking about this the last few days and realised > it would be a problem. Using g.proj in this way is more complicated than > it first appeared. It may be simpler to manually create the directories > (in Python) and write out the PROJ_INFO and PROJ_UNITS files directly. > Skeleton DEFAULT_WIND and WIND files would also have to put in too. > > As I said I don't have a lot of time to devote to this but I'm working on > a proposal for how I think a location creation wizard should work (what is > included on each screen etc.) and when finished I will post it to the > list, in the hope that the thinking behind it will prove to be some help. > I'm doing it blind, i.e. without looking at what's there already in the > new GUI - hopefully we can then share the best ideas from both approaches. > > Paul > __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From neteler at itc.it Thu Jul 5 23:38:27 2007 From: neteler at itc.it (Markus Neteler) Date: Thu Jul 5 23:38:30 2007 Subject: [GRASS-dev] time to release 6.2.2 In-Reply-To: <468D19AE.6050302@jemila.jazztel.es> References: <20070701190509.GA28159@bartok.itc.it> <468D19AE.6050302@jemila.jazztel.es> Message-ID: <11455121.post@talk.nabble.com> Carlos D?vila wrote: > > Markus Neteler escribi?: >> Hi, >> >> during the testing period of 6.2.2-RC1 we got the following >> issues fixed: >> ... >> * Czech translation updated (Jachym Cepicky) >> > What about the other languages? Will they be included in the new release > and packages? > Carlos > Carlos, would be great to merge back. But I tried once and actually *lost* many messages. So, after a try one must check if this doesn't reduce the translations in 6.2.x. I can send you a script "po_merge.sh" which does it for all 3 files automatically The script will ask you for the country code and then it uses "msgmerge". The script is just a few lines. Markus -- View this message in context: http://www.nabble.com/time-to-release-6.2.2-tf4008762.html#a11455121 Sent from the Grass - Dev mailing list archive at Nabble.com. From michael.barton at asu.edu Fri Jul 6 04:54:34 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jul 6 04:54:45 2007 Subject: [GRASS-dev] more proj4 inconsistencies in g.proj Message-ID: Paul and Glyn, I've been tearing my hair out for 2 days over what I thought was a Python problem only to discover that it's another inconsistency with the projection information files--with ellipse.table again. For example, the line for wgs84 is... wgs84 "World Geodetic System 1984" a=6378137.000 f=1/298.257223563 But for it to be read into g.proj in acceptable format, it needs to be... wgs84 "World Geodetic System 1984" a=6378137.000 rf=298.257223563 That is, 1/298.257223563 needs to be 298.257223563 Why is it 1/298.257223563? Is this correct in some kind of format acceptable to g.proj? Anyway, with this solved, the location wizard works for all except xy locations (suggestions on how to make?) and extents. Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070705/5c5d3027/attachment.html From cdavilam at jemila.jazztel.es Fri Jul 6 12:49:26 2007 From: cdavilam at jemila.jazztel.es (=?UTF-8?B?Q2FybG9zIETDoXZpbGE=?=) Date: Fri Jul 6 12:46:37 2007 Subject: [GRASS-dev] time to release 6.2.2 In-Reply-To: <11455121.post@talk.nabble.com> References: <20070701190509.GA28159@bartok.itc.it> <468D19AE.6050302@jemila.jazztel.es> <11455121.post@talk.nabble.com> Message-ID: <468E1E36.3040404@jemila.jazztel.es> Markus Neteler escribi?: > Carlos D?vila wrote: > >> Markus Neteler escribi?: >> >>> Hi, >>> >>> during the testing period of 6.2.2-RC1 we got the following >>> issues fixed: >>> ... >>> * Czech translation updated (Jachym Cepicky) >>> >>> >> What about the other languages? Will they be included in the new release >> and packages? >> Carlos >> >> > > Carlos, > > would be great to merge back. But I tried once and actually *lost* > many messages. So, after a try one must check if this doesn't > reduce the translations in 6.2.x. > > I can send you a script "po_merge.sh" which does it for all 3 files > automatically The script will ask you for the country code and then > it uses "msgmerge". The script is just a few lines. > I already had the script. I've done a test with es.po files and this is the result: libs: same total and more fuzzy, so discarded. mods and tcl: total amount of messages raises from 3910 and 871 to 4775 and 1148 respectively. Are all these new messages useful in 6.2.2 or I shall look only to the variation in fuzzy and untranslated? Shall I make pot & make update-po after running the script? As you can see, many doubts. Regards Carlos From landa.martin at gmail.com Fri Jul 6 13:34:18 2007 From: landa.martin at gmail.com (Martin Landa) Date: Fri Jul 6 13:34:21 2007 Subject: [GRASS-dev] Re: [GRASS-CVS] carlos: grass6/raster/r.his main.c, 2.6, 2.7 In-Reply-To: <20070706110312.482BC60C4C6@lists.intevation.de> References: <20070706110312.482BC60C4C6@lists.intevation.de> Message-ID: Hi, just a stupid note > - G_fatal_error(_("Unable to open raster map [%s]"), name_h); > + G_fatal_error(_("Unable to open raster map <%s>"), name_h); wouldn't be better to use "Cannot open raster map <%s>"?, see wiki and discussion in grass-dev mailing list... Martin PS: Thanks to Carlos for this hard job! -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From cdavilam at jemila.jazztel.es Fri Jul 6 14:24:26 2007 From: cdavilam at jemila.jazztel.es (=?ISO-8859-1?Q?Carlos_D=E1vila?=) Date: Fri Jul 6 14:21:38 2007 Subject: [GRASS-dev] Re: [GRASS-CVS] carlos: grass6/raster/r.his main.c, 2.6, 2.7 In-Reply-To: References: <20070706110312.482BC60C4C6@lists.intevation.de> Message-ID: <468E347A.4050709@jemila.jazztel.es> Se ha borrado un adjunto en formato HTML... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070706/79a5ca84/attachment-0001.html From landa.martin at gmail.com Fri Jul 6 14:33:33 2007 From: landa.martin at gmail.com (Martin Landa) Date: Fri Jul 6 14:33:36 2007 Subject: [GRASS-dev] Re: [GRASS-CVS] carlos: grass6/raster/r.his main.c, 2.6, 2.7 In-Reply-To: <468E347A.4050709@jemila.jazztel.es> References: <20070706110312.482BC60C4C6@lists.intevation.de> <468E347A.4050709@jemila.jazztel.es> Message-ID: Ciao Carlos, I am not sure too (it is the question for native speakers...) http://www.nabble.com/message-standardization-on-wiki-tf3559274.html#a9939189 "Cannot open raster map" X "Unable to open raster map" Martin 2007/7/6, Carlos D?vila : > > Martin Landa escribi?: > Hi, > > just a stupid note > > > - G_fatal_error(_("Unable to open raster map [%s]"), name_h); > + G_fatal_error(_("Unable to open raster map <%s>"), name_h); > > wouldn't be better to use "Cannot open raster map <%s>"?, see wiki and > discussion in grass-dev mailing list... > For sure I may be wrong, but I've been revising wiki and lists (dev and > translations) and I can't see where it is suggested to use cannot instead of > unable to. > What I found is: > >From wiki > > Standard messages sandbox > > First letter should be capitalized > Use the present tense (cannot instead of could not; better: unable to) ... > > > G_open_cell_old "Unable to open raster map <%s>" >From translation list: > > > > I would prefer not using "Cannot...". It's bad grammar. I would much > > > > prefer "Unable to..." or something to that effect. > > > > > > > While I can see your point, that construction is quite common in error > > > messages, e.g.: > > > > > > $ ls -l foo > > > ls: cannot access foo: No such file or directory > > > > > > Neither "cannot ..." nor "unable to ..." form complete sentences. > > > > > > If you're concerned about grammar, you can provide an explicit subject > > > ("The program cannot ..."), or use the third person (e.g. "The file > > > cannot be found"). > > > > > > Personally, I don't have a problem with just omitting the subject. > > > Point taken. I was really referring to the usage of "Cannot". Some > > dictionaries do not recognize it as 'real word', yet others (that are > > generally more progressive with slang and contractions) say that it > > should replace "can not" in modern English. > > > > > It's a non-problem. In modules I've [re]written, I've used "Unable to", > > but I can go back and change them for consistency. > > > It seems to me that "Unable to" is the most impartial form. > > > > Martin > > PS: Thanks to Carlos for this hard job! > Thanks to all of you for the support. > > > _______________________________________________ > 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 benjamin.ducke at ufg.uni-kiel.de Fri Jul 6 16:17:44 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Fri Jul 6 16:18:14 2007 Subject: [GRASS-dev] Some progress on Win32 attribute deadlock problem Message-ID: <468E4F08.80502@ufg.uni-kiel.de> Dear GRASS friends, I know it is getting boring, but this problem with attribute data on Win32 is totally wrecking the show for me, so I took a few more hours of tedious Win32 (brrrr!) debugging to see what I can find. Again, I used this data set: ftp://ftp.rz.uni-kiel.de/pub/ufg/qgis-test.zip and v.out.ogr to export all points (ca. 3000) in vector map 'dgm' incl. attributes. Deadlock occurs randomly on attribute data access, hanging v.out.ogr (or any (!) other module that accesses attribute data -- I confirmed this at least for DBF and sqlite tables). Since debugging under Win32 is a nightmare, I decided to put in lots of debugging messages by hand to try and locate the problem. In unaltered form, v.out.ogr managed to export all points before hanging in one(!) of 50 tries on a Machine with just 176 megs RAM. In ca. 50% of the cases, hangs occured when Vect_read_line was called (but there were several other funcs involved, too). So I removed Vect_read_line from the main program loop and only called it once before entering the loop to have a valid struct in memory to work with. Now, v.out.ogr finished in ca. 50% of the cases. So Vect_read_line must be involved somehow, but it is not the original source of the problem (read on). Next, I reduced vector API calls to only Vect_read_line and Vect_cat_get. Got rid of all attribute handling code. Now everything worked fine. Out of 30 attempts, 30 worked. So these two funcs by themselves don't cause any problems. Next, I put some attribute handling code back in bit by bit to see when the trouble would start again. It did not take long. Basically, managing SQL strings with db_init_string and db_set_string works fine, but as soon as the attribute database is queried (using db_open_select_cursor), the lockups come back in full number! SUMMARY * The problem does not originate in a specific DB driver (such as DBF.EXE), but is buried deep in the basic functions if the GRASS DBMI lib. * The basic Vect_read_line and Vect_cat_get functions work fine on Win32 by themselves. Trouble starts when there is interaction with DBMI calls. * The function db_open_select_cursor is at least one of the possible culprits, but chances are that more functions are involved. In any case, lockups occur more frequently when calls to Vect_read_line are done often, suggesting that there is some unwholesome interaction or competition for resources between Vect and DBMI libs. * For some reason, this problem does not show up in Linux. There is strong evidence that it is a system resource allocation problem (mem, file handlers???), because lockups occur less frequently on systems with more available RAM. The problem exists on both Windows 2000 and Windows XP systems (Vista untested). For today, I am giving up. At least now it seems to become clearer where to look for the culprit. If any of you have any bright ideas, I'd be grateful to hear about them. Best, Benjamin -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From cdavilam at jemila.jazztel.es Fri Jul 6 17:26:31 2007 From: cdavilam at jemila.jazztel.es (=?ISO-8859-1?Q?Carlos_D=E1vila?=) Date: Fri Jul 6 17:23:40 2007 Subject: [GRASS-dev] Re: [GRASS-CVS] carlos: grass6/raster/r.his main.c, 2.6, 2.7 In-Reply-To: References: <20070706110312.482BC60C4C6@lists.intevation.de> <468E347A.4050709@jemila.jazztel.es> Message-ID: <468E5F27.5050605@jemila.jazztel.es> Martin Landa escribi?: > Ciao Carlos, > > I am not sure too (it is the question for native speakers...) > > http://www.nabble.com/message-standardization-on-wiki-tf3559274.html#a9939189 > > > "Cannot open raster map" X "Unable to open raster map" > > Martin OK, now I see. I'm afraid we have a contradiction in wiki, as in "Standard messages sandbox > Raster messages" we have "Cannot open raster map <%s>" and in "Messages discussion > G_open_cell_old" proposed standard response is "Unable open raster map <%s>", so we have to choose. Any help from native speakers is welcome. Regards Carlos > > > > 2007/7/6, Carlos D?vila : >> >> Martin Landa escribi?: >> Hi, >> >> just a stupid note >> >> >> - G_fatal_error(_("Unable to open raster map [%s]"), >> name_h); >> + G_fatal_error(_("Unable to open raster map <%s>"), >> name_h); >> >> wouldn't be better to use "Cannot open raster map <%s>"?, see wiki and >> discussion in grass-dev mailing list... >> For sure I may be wrong, but I've been revising wiki and lists (dev and >> translations) and I can't see where it is suggested to use cannot >> instead of >> unable to. >> What I found is: >> >From wiki >> >> Standard messages sandbox >> >> First letter should be capitalized >> Use the present tense (cannot instead of could not; better: unable >> to) ... >> >> >> G_open_cell_old "Unable to open raster map <%s>" >From translation >> list: >> > > > I would prefer not using "Cannot...". It's bad grammar. I >> would much >> > > > prefer "Unable to..." or something to that effect. >> >> > > >> > > While I can see your point, that construction is quite common in >> error >> > > messages, e.g.: >> > > >> > > $ ls -l foo >> > > ls: cannot access foo: No such file or directory >> > > >> > > Neither "cannot ..." nor "unable to ..." form complete sentences. >> > > >> > > If you're concerned about grammar, you can provide an explicit >> subject >> > > ("The program cannot ..."), or use the third person (e.g. "The file >> > > cannot be found"). >> > > >> > > Personally, I don't have a problem with just omitting the subject. >> >> > Point taken. I was really referring to the usage of "Cannot". Some >> > dictionaries do not recognize it as 'real word', yet others (that are >> > generally more progressive with slang and contractions) say that it >> > should replace "can not" in modern English. >> >> > >> > It's a non-problem. In modules I've [re]written, I've used "Unable >> to", >> > but I can go back and change them for consistency. >> >> >> It seems to me that "Unable to" is the most impartial form. >> >> >> >> Martin >> >> PS: Thanks to Carlos for this hard job! >> Thanks to all of you for the support. >> >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev >> > > From neteler at itc.it Fri Jul 6 17:30:21 2007 From: neteler at itc.it (Markus Neteler) Date: Fri Jul 6 17:30:23 2007 Subject: [GRASS-dev] time to release 6.2.2 In-Reply-To: <468E1E36.3040404@jemila.jazztel.es> References: <20070701190509.GA28159@bartok.itc.it> <468D19AE.6050302@jemila.jazztel.es> <11455121.post@talk.nabble.com> <468E1E36.3040404@jemila.jazztel.es> Message-ID: <468E600D.4050604@itc.it> Carlos D?vila wrote on 07/06/2007 12:49 PM: > Markus Neteler escribi?: >> Carlos D?vila wrote: >> >>> Markus Neteler escribi?: >>> >>>> Hi, >>>> >>>> during the testing period of 6.2.2-RC1 we got the following >>>> issues fixed: >>>> ... >>>> * Czech translation updated (Jachym Cepicky) >>>> >>> What about the other languages? Will they be included in the new >>> release and packages? >>> Carlos >>> >>> >> >> Carlos, >> >> would be great to merge back. But I tried once and actually *lost* >> many messages. So, after a try one must check if this doesn't >> reduce the translations in 6.2.x. >> >> I can send you a script "po_merge.sh" which does it for all 3 files >> automatically The script will ask you for the country code and then >> it uses "msgmerge". The script is just a few lines. >> > I already had the script. I've done a test with es.po files and this > is the result: > libs: same total and more fuzzy, so discarded. > mods and tcl: total amount of messages raises from 3910 and 871 to > 4775 and 1148 respectively. Are all these new messages useful in 6.2.2 > or I shall look only to the variation in fuzzy and untranslated? Shall > I make pot & make update-po after running the script? > As you can see, many doubts. I think that only "good" messages count (so, translated, non-fuzzy) and the rest isn't important. If you observe a growing number of correctly translated messages, then I suggest to submit to 6.2.cvs. Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From grass-codep at wald.intevation.org Fri Jul 6 18:21:33 2007 From: grass-codep at wald.intevation.org (grass-codep@wald.intevation.org) Date: Fri Jul 6 18:20:12 2007 Subject: [GRASS-dev] [grass-code P][441] v.in.gns does fails to import data Message-ID: <20070706162133.B36F540196@pyrosoma.intevation.org> code P item #441, was opened at 2007-07-06 16:21 Status: Open Priority: 3 Submitted By: Artur Wroblewski (wrobell) Assigned to: Nobody (None) Summary: v.in.gns does fails to import data Patch status: None Patch type: fix GRASS component: vector GRASS version: 6.2.1 GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: running v.in.gns to import pl or nl data from GNS i am getting an error ERROR: Length of column 19 (2) is less than maximum value length (3) this is about LC column described at http://earth-info.nga.mil/gns/html/help.htm above specification says that LC column consists of 3 characters but v.in.gns defines it as 2 character string. patch attached. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=205&aid=441&group_id=21 From tlaronde at polynum.com Fri Jul 6 19:34:10 2007 From: tlaronde at polynum.com (tlaronde@polynum.com) Date: Fri Jul 6 19:36:46 2007 Subject: [GRASS-dev] GPL GRASS, CSP and distributed systems Message-ID: <20070706173410.GA330@polynum.com> Hello, Since KerGIS and myself are part of GPL GRASS IRC mockery: ------ 00:49:20 jachym: and say "hallo" to kergis developers, if you meet them 00:49:22 jachym: ;- ) 00:50:21 huhabla: jachym: the kergis dev like the old 4.1 GRASS gis, not new technology 06:36:11 : * huhabla just tried kergis ... wow what a waste of development time ... what a pity ------ I will give you some more fun. "What this retarded developer is losing his time about?": CSP and distributed systems. Because still aiming to understand the "old technology", I stumbled upon an old feature of GRASS that matches the principles of the most advanced, simple distributed system: Plan 9. You know, this thing made by the creators of Unix, the Bell Labs, that run from handhelds to Blue Gene. Curiously enough, KerGIS/GRASS has to run from handhelds (to gather data on the field) to mainframe---to do the huge computations. One of the principle underneath the distributed system, is to be able to dispatch processing on different machines. An analyze of the needs also leads to the conclusion that the user interface shall be disconnected from the heavy processing, that is that handling the user interface is a different task than computing the data. A graphical interface mainly allows to select graphically commands to process data. With the current windowing systems---X11 for example---using a toolkit for the menu handling does _not_ disconnect the user handling---remember the consequences of polling the mouse...---from the processing of the data, since the menu handling is done on the client side, leading to heavy network loads (to the server) and consuming a lot of processing power on the client (CPU) with the problematic of blocking processes (waiting for input, or freezing the interface since the system is doing an heavy computation). Curiously enough, the "old GRASS technology", sending graphical request to a communication channel (a fifo, a socket) is the first step to allow this and can be seen as a way to implement CSP (since the problem is that you have to share the data---a vector file you are editing for example). Furthermore, once you understand that even the curses interface is just a peculiar case of a 2D interface (cli is line oriented; curses is plan, screen oriented), one can start to wonder if there could be such a thing as a 2D interface description that will be converted in whatever 2D interface system is available (one menu description for a program; the interpreter launched by d.mon building it depending on the interface defined in the gisenv; and the ability then to customize this text description for local use). The answer is: this already exists to some extend. Plan9/Inferno uses, in Limbo, tk for the description; and tk is such a description. Public Domain Curses allows to link a curses interface to an X11 "interpretation" transforming a curses interface into an X11 application (meaning that KerGIS can be already transformed with an X11 look with little work---but this is not the aim). Etc. It was just to let you have other subjects to bash my, I admit it, lonely efforts. I must simply be the less gifted one that plagues every family. The black sheep so erroneous that it has the colour of a wolf. Since it is the end of the week and the beginning of the holidays period, some refreshing jokes were needed. You have. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C From rez at touchofmadness.com Sat Jul 7 00:23:07 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Sat Jul 7 00:23:13 2007 Subject: [GRASS-dev] Re: [GRASS-CVS] carlos: grass6/raster/r.his main.c, 2.6, 2.7 In-Reply-To: References: <20070706110312.482BC60C4C6@lists.intevation.de> <468E347A.4050709@jemila.jazztel.es> Message-ID: <1183760587.22994.104.camel@dev64.localdomain> On Fri, 2007-07-06 at 14:33 +0200, Martin Landa wrote: > Ciao Carlos, > > I am not sure too (it is the question for native speakers...) > > http://www.nabble.com/message-standardization-on-wiki-tf3559274.html#a9939189 > > "Cannot open raster map" X "Unable to open raster map" There is no issue with tense here. I prefer "Unable to". It's negative without being so forcefully negative (if that makes any sense). Either will work, but I believe there are fewer cases of "Cannot..." than "Unable to..." in source. -- 73, de Brad KB8UYR/6 From paul-grass at stjohnspoint.co.uk Sat Jul 7 01:48:22 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sat Jul 7 01:48:29 2007 Subject: [GRASS-dev] Re: [GRASS-CVS] carlos: grass6/raster/r.his main.c, 2.6, 2.7 In-Reply-To: <1183760587.22994.104.camel@dev64.localdomain> References: <20070706110312.482BC60C4C6@lists.intevation.de> <468E347A.4050709@jemila.jazztel.es> <1183760587.22994.104.camel@dev64.localdomain> Message-ID: On Fri, 6 Jul 2007, Brad Douglas wrote: > On Fri, 2007-07-06 at 14:33 +0200, Martin Landa wrote: >> Ciao Carlos, >> >> I am not sure too (it is the question for native speakers...) >> >> http://www.nabble.com/message-standardization-on-wiki-tf3559274.html#a9939189 >> >> "Cannot open raster map" X "Unable to open raster map" > > There is no issue with tense here. > > I prefer "Unable to". It's negative without being so forcefully > negative (if that makes any sense). Either will work, but I believe > there are fewer cases of "Cannot..." than "Unable to..." in source. I'm just replying to make the point how there really seems to be no difference between the two forms: I disagree with the above and feel "unable to" sounds much more harsh and formal than "can not", "cannot" or "can't", which IMHO correspond more with every day speech. But perhaps there is a American/European English difference here. In which case given GRASS's roots the American is probably the way to go I guess? Are there any languages into which, when translated, the two phrases mean something substantially different? In any case I think it is clearer if error messages like these (resulting from filesystem errors) are augmented where possible with the system error message from strerror(errno()) - see e.g. in lib/gis/copy_file.c: G_warning( "Cannot open %s for reading: %s", infile, strerror(errno) ); Here's a thought - to me, "unable to" suggests that the reason why something could not be done is outside GRASS's control, and perhaps would suit the above example from G_copy_file() better than "cannot" as the reason (the system error message) is presented after the GRASS error. Whereas perhaps "cannot" suggests that's simply all there is to it and the program is unable to go into any more depth on what caused the error. i.e. "unable to": error/warning caused by something outside GRASS; say what it is "cannot": error/warning is something within GRASS that genuinely isn't possible. But I'm really splitting hairs here, trying to justify why we have the two forms in GRASS. But perhaps it isn't possible to justify that... Paul From paul-grass at stjohnspoint.co.uk Sat Jul 7 02:12:26 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sat Jul 7 02:12:30 2007 Subject: [GRASS-dev] Re: more proj4 inconsistencies in g.proj In-Reply-To: References: Message-ID: On Thu, 5 Jul 2007, Michael Barton wrote: > Paul and Glyn, > > I've been tearing my hair out for 2 days over what I thought was a Python > problem only to discover that it's another inconsistency with the projection > information files--with ellipse.table again. > > For example, the line for wgs84 is... > > wgs84 "World Geodetic System 1984" a=6378137.000 > f=1/298.257223563 > > But for it to be read into g.proj in acceptable format, it needs to be... > > wgs84 "World Geodetic System 1984" a=6378137.000 > rf=298.257223563 > > That is, 1/298.257223563 needs to be 298.257223563 > > Why is it 1/298.257223563? Is this correct in some kind of format acceptable > to g.proj? No idea. I suspect whoever was originally putting the State Plane support (which required PROJ) into GRASS in the early 90s got a bit confused and it's been like that ever since. Note that f=flattening, rf=reciprocal flattening. So f=1/xxx is obviously wrong but that's just the way it always has been in GRASS. > Anyway, with this solved, the location wizard works for all except xy > locations (suggestions on how to make?) and extents. What about datum names? I suspect they aren't put into the PROJ_INFO? Like I said in an earlier e-mail, I really don't think using g.proj for the custom projections is going to be a long-term workable solution unless we add an option to g.proj to read a PROJ_INFO, PROJ_UNITS and WIND file outside of a GRASS location - in which case we'd still have to create those files manually from the GUI wizard, so why not do that directly? I think that will be easier. Anyway I'm still working on my ideas for the GUI wizard (mostly based around what how it should logically progress to best emphasise the important concepts of GRASS locations to new users..) but I have to go away for a few days.. I'll get back to it next week though all being well. Paul From rez at touchofmadness.com Sat Jul 7 03:07:19 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Sat Jul 7 03:07:24 2007 Subject: [GRASS-dev] Unable/Can not wording (was: Re: [GRASS-CVS] carlos: grass6/raster/r.his main.c, 2.6, 2.7) In-Reply-To: References: <20070706110312.482BC60C4C6@lists.intevation.de> <468E347A.4050709@jemila.jazztel.es> <1183760587.22994.104.camel@dev64.localdomain> Message-ID: <1183770440.22994.149.camel@dev64.localdomain> On Sat, 2007-07-07 at 00:48 +0100, Paul Kelly wrote: > On Fri, 6 Jul 2007, Brad Douglas wrote: > > > On Fri, 2007-07-06 at 14:33 +0200, Martin Landa wrote: > >> Ciao Carlos, > >> > >> I am not sure too (it is the question for native speakers...) > >> > >> http://www.nabble.com/message-standardization-on-wiki-tf3559274.html#a9939189 > >> > >> "Cannot open raster map" X "Unable to open raster map" > > > > There is no issue with tense here. > > > > I prefer "Unable to". It's negative without being so forcefully > > negative (if that makes any sense). Either will work, but I believe > > there are fewer cases of "Cannot..." than "Unable to..." in source. > > I'm just replying to make the point how there really seems to be no > difference between the two forms: I disagree with the above and feel > "unable to" sounds much more harsh and formal than "can not", "cannot" or > "can't", which IMHO correspond more with every day speech. But perhaps > there is a American/European English difference here. In which case given > GRASS's roots the American is probably the way to go I guess? Are there > any languages into which, when translated, the two phrases mean something > substantially different? Correct, that there is essentially no different. For me, it's a matter of flow, rather than flipping a coin. Contractions are EVIL and should not be used. That includes "cannot" and "can't". Those are both out. We're left with "Can not". I don't like it because it negates a positive, but that's my personal choice. I could care less which of the two gets used, as long as it is consistent. > In any case I think it is clearer if error messages like these (resulting > from filesystem errors) are augmented where possible with the system error > message from strerror(errno()) - see e.g. in lib/gis/copy_file.c: > G_warning( "Cannot open %s for reading: %s", infile, > strerror(errno) ); See above. > Here's a thought - to me, "unable to" suggests that the reason why > something could not be done is outside GRASS's control, and perhaps would > suit the above example from G_copy_file() better than "cannot" as the > reason (the system error message) is presented after the GRASS error. > Whereas perhaps "cannot" suggests that's simply all there is to it and > the program is unable to go into any more depth on what caused the error. > i.e. > "unable to": error/warning caused by something outside GRASS; say what it > is > "cannot": error/warning is something within GRASS that genuinely isn't > possible. > But I'm really splitting hairs here, trying to justify why we have the two > forms in GRASS. But perhaps it isn't possible to justify that... Maybe we should put it to a vote, even though it is a mundane issue. Both are acceptable choices...it's just a matter of choosing one and not looking back. -- 73, de Brad KB8UYR/6 From grass-codep at wald.intevation.org Sat Jul 7 11:20:10 2007 From: grass-codep at wald.intevation.org (grass-codep@wald.intevation.org) Date: Sat Jul 7 11:18:47 2007 Subject: [GRASS-dev] [grass-code P][442] v.in.gns documentation is out-to-date Message-ID: <20070707092010.E5D154016D@pyrosoma.intevation.org> code P item #442, was opened at 2007-07-07 09:20 Status: Open Priority: 3 Submitted By: Artur Wroblewski (wrobell) Assigned to: Nobody (None) Summary: v.in.gns documentation is out-to-date Patch status: None Patch type: fix GRASS component: vector GRASS version: None GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: GNS columns description page moved from http://earth-info.nga.mil/gns/html/gis_contryfiles.html to http://earth-info.nga.mil/gns/html/help.htm patch to fix documentation attached. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=205&aid=442&group_id=21 From glynn at gclements.plus.com Sat Jul 7 13:00:40 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jul 7 13:00:44 2007 Subject: [GRASS-dev] Some progress on Win32 attribute deadlock problem In-Reply-To: <468E4F08.80502@ufg.uni-kiel.de> References: <468E4F08.80502@ufg.uni-kiel.de> Message-ID: <18063.29272.14994.576966@cerise.gclements.plus.com> Benjamin Ducke wrote: > Next, I put some attribute handling code back in bit by bit to see when > the trouble would start again. It did not take long. Basically, managing > SQL strings with db_init_string and db_set_string works fine, but as > soon as the attribute database is queried (using db_open_select_cursor), > the lockups come back in full number! > > SUMMARY > > * The problem does not originate in a specific DB driver (such as > DBF.EXE), but is buried deep in the basic functions if the GRASS DBMI lib. > > * The basic Vect_read_line and Vect_cat_get functions work fine on Win32 > by themselves. Trouble starts when there is interaction with DBMI calls. > > * The function db_open_select_cursor is at least one of the possible > culprits, but chances are that more functions are involved. In any case, > lockups occur more frequently when calls to Vect_read_line are done > often, suggesting that there is some unwholesome interaction or > competition for resources between Vect and DBMI libs. > > * For some reason, this problem does not show up in Linux. > There is strong evidence that it is a system resource allocation problem > (mem, file handlers???), because lockups occur less frequently on > systems with more available RAM. The problem exists on both Windows 2000 > and Windows XP systems (Vista untested). > > > > For today, I am giving up. > At least now it seems to become clearer where to look for the culprit. > If any of you have any bright ideas, I'd be grateful to hear about them. My first guesses would be: 1. The "#ifdef __MINGW32__" portion of lib/db/dbmi_client/start.c 2. The Windows port of the RPC/XDR library. If the behaviour is non-deterministic (i.e. you don't get exactly the same behaviour from consecutive runs), I would suspect that it's timing related. Checking that incomplete read/write operations are correctly handled might be a good place to start. -- Glynn Clements From benjamin.ducke at ufg.uni-kiel.de Sat Jul 7 15:57:38 2007 From: benjamin.ducke at ufg.uni-kiel.de (benjamin.ducke@ufg.uni-kiel.de) Date: Sat Jul 7 15:57:40 2007 Subject: [GRASS-dev] Some progress on Win32 attribute deadlock problem In-Reply-To: <18063.29272.14994.576966@cerise.gclements.plus.com> References: <468E4F08.80502@ufg.uni-kiel.de> <18063.29272.14994.576966@cerise.gclements.plus.com> Message-ID: <33858.86.103.128.3.1183816658.squirrel@webmail.mail.uni-kiel.de> >> If any of you have any bright ideas, I'd be grateful to hear about them. > > My first guesses would be: > > 1. The "#ifdef __MINGW32__" portion of lib/db/dbmi_client/start.c > 2. The Windows port of the RPC/XDR library. > > If the behaviour is non-deterministic (i.e. you don't get exactly the > same behaviour from consecutive runs), I would suspect that it's > timing related. Checking that incomplete read/write operations are > correctly handled might be a good place to start. > > -- > Glynn Clements > > Interesting. I've had some other folks suggest a timing/priority problem, too. I think we are getting closer here. I was going to look into XDR lib on a hunch, too. How would you advice to check for incomplete read/write ops: keep a count of open files and compare it to the number of closed files once for every run through the main export loop in v.out.ogr? I haven't done a lot of system level programming for a long time so I am somewhat out of practice. Cheers, Benjamin From glynn at gclements.plus.com Sat Jul 7 21:09:30 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jul 7 21:09:33 2007 Subject: [GRASS-dev] Some progress on Win32 attribute deadlock problem In-Reply-To: <33858.86.103.128.3.1183816658.squirrel@webmail.mail.uni-kiel.de> References: <468E4F08.80502@ufg.uni-kiel.de> <18063.29272.14994.576966@cerise.gclements.plus.com> <33858.86.103.128.3.1183816658.squirrel@webmail.mail.uni-kiel.de> Message-ID: <18063.58602.401705.756221@cerise.gclements.plus.com> benjamin.ducke@ufg.uni-kiel.de wrote: > >> If any of you have any bright ideas, I'd be grateful to hear about them. > > > > My first guesses would be: > > > > 1. The "#ifdef __MINGW32__" portion of lib/db/dbmi_client/start.c > > 2. The Windows port of the RPC/XDR library. > > > > If the behaviour is non-deterministic (i.e. you don't get exactly the > > same behaviour from consecutive runs), I would suspect that it's > > timing related. Checking that incomplete read/write operations are > > correctly handled might be a good place to start. > > Interesting. I've had some other folks suggest a timing/priority problem, > too. I think we are getting closer here. I was going to look into XDR lib > on a hunch, too. > How would you advice to check for incomplete read/write ops: keep a count > of open files and compare it to the number of closed files once for every > run through the main export loop in v.out.ogr? No, that won't help. I'm referring to the situation where read/write return a short count, e.g. "write(fd, buf, count) < count". But, I've remembered that XDR uses stdio rather than POSIX I/O, and I don't think that fread/fwrite can return a short count (except for EOF). According to the MSVCRT documentation, the O_NOINHERIT flag should be used when using _dup2(), e.g.: _pipe(p1, 250000, _O_BINARY|_O_NOINHERIT) Another suggestion: try changing the size passed to the _pipe() function in dbmi_client/start.c. If that affects the tendency to deadlock, it strongly suggests that the issue is related to the way that a full pipe is handled. Beyond that, the only thing which I can suggest is to instrument the XDR code with debug code to log all I/O operations (including the data which is read/written). -- Glynn Clements From rez at touchofmadness.com Sun Jul 8 08:07:39 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Sun Jul 8 08:07:45 2007 Subject: [GRASS-dev] Directory security/permission issue Message-ID: <1183874859.30110.35.camel@dev64.localdomain> Hello, While looking over my working dirs, today, I noticed that all of my recent locations were created with 0777 permissions, instead of the traditional 0755 mask. Temp directories are still created properly. 0777 is bad form and a potential security problem. Is there a reason for the change I missed? A quick search through the archives didn't turn up anything. It seems to have come as an accidental result of the MINGW changes. The offending code can be found in lib/gis/paths.c in G_mkdir(). This should be explained or corrected before 6.2.2 is released. -- 73, de Brad KB8UYR/6 From hamish_nospam at yahoo.com Sun Jul 8 08:58:41 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Jul 8 08:58:50 2007 Subject: [GRASS-dev] Re: g.proj won't parse PROJ.4 string In-Reply-To: References: Message-ID: <20070708185841.1295ccb8.hamish_nospam@yahoo.com> Michael Barton wrote: > As a brief overview, the wizard does the following: .. > 5. Create an XY location (this is not yet working because I'm not sure > what the best way to do this is). as Paul suggested just write out the needed files for a simple XY location, don't bother trying to do it as a projection. If you create an XY location using the old way, you will notice there is no PROJ_UNITS file created in PERMANENT/, only DEFAULT_WIND and MYNAME. So skip the g.proj step for that altogether and just make the dir structure yourself. Hamish From hamish_nospam at yahoo.com Sun Jul 8 09:39:05 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Jul 8 09:39:13 2007 Subject: [GRASS-dev] Some questions about standardization In-Reply-To: <4689303B.4050604@jemila.jazztel.es> References: <4689303B.4050604@jemila.jazztel.es> Message-ID: <20070708193905.130704d5.hamish_nospam@yahoo.com> Carlos D?vila wrote: > I would like to get some feedback about the changes I'm doing to > standardize. As some questions in the air do not get answers I'm > following what is in wiki, but I wouldn't like to bother anyone with > the changes. > > I need some help to continue with further changes. As I'm not > programmer I don't know well what can be changed in code and what > can't, so I ask you some cases: > a) %s: can't open tempfile -> Unable to open temporary file <%s> (does > it affect where is the %s?) The meaning of the string matters, I suspect the first %s string is the program name, and the second is the filename. So just moving it is wrong for meaning but ok for C syntax. FWIW, the program name will be mostly redundant unless it is a module mainly used as a scripting tool (for example g.*). And giving the exact name of a non-existant tmp file does not help the user much, the main point is that they couldn't write to $MAPSET/.tmp/$HOST/<>. (e.g. mapset copied from read-only CD-ROM without resetting permissions or user name) It may be more useful to know that if Paul moves some tmp file creation into /tmp/, but for now, in my 2c opinion, it is just minorly-helpful noise. > b) can't open raster map <%s> in mapset %s -> Unable to open raster > map <%s> (Can I drop last %s without problems?) not without changing the variables passed to G_fatal_error() > c) How can I pass from "Unable to open the temporary file." to "Unable > to open temporary file <%s>"? E.g. from > /display/d.text.freetype/main.c: > > tmpfile = G_tempfile(); > if(!(fp = fopen(tmpfile, "w"))) > error(_("Unable to write the temporary file")); (don't bother to spend much effort on d.text.freetype, it is scheduled for oblivion) but, G_fatal_error(_("Unable to write the temporary file <%s>"), tmpfile); Hamish ps - I just added this to the wiki and reverted associated changes in v.to.rast and g.list. http://grass.gdf-hannover.de/wiki/Development_Specs * Only user derived variables should be bracketed, not GRASS derived variables. for example: Yes: Creating raster map <%s>. Pass 1 of 7 ... No: Creating map <%s>. Pass [1] of [7] ... Hope everyone agrees, discussion on the grass-dev ML is preferable, as the wiki reflects the opinion of the last editor, not == to the group consensus. pps- also added on the wiki: ("Cannot find input map <%s>" instead of "It could not be find input map <%s>") Added: avoid the issue altogether by rewording "possibly better: "Input map <%s> not found." From neteler at itc.it Sun Jul 8 12:08:26 2007 From: neteler at itc.it (Markus Neteler) Date: Sun Jul 8 12:08:27 2007 Subject: [GRASS-dev] [grass-code I][359] GRASS fails to build with make -j3 In-Reply-To: <17940.62513.704845.161917@cerise.gclements.plus.com> References: <20070405100155.BE9171973F9B@pyrosoma.intevation.org> <17940.62513.704845.161917@cerise.gclements.plus.com> Message-ID: <20070708100826.GA9749@krokus.itc.it> On Thu, Apr 05, 2007 at 02:05:53PM +0100, Glynn Clements wrote: > > grass-codei@wald.intevation.org wrote: > > > code I item #359, was opened at 2007-04-05 12:01 > > Status: Open > > Priority: 4 > > Submitted By: Maciej Sieczka (msieczka) > > Assigned to: Nobody (None) > > Summary: GRASS fails to build with make -j3 > > Issue type: other bug > > Issue status: None > > GRASS version: CVS HEAD > > GRASS component: build > > Operating system: all > > Operating system version: > > GRASS CVS checkout date, if applies (YYMMDD): 050407 > > > > > > Initial Comment: > > On multi cpu machines it is possible to speed up compilation time > > greatly using the -j switch with make (eg. -j3 for 2 cpus). > > > > make -j3 works fine on my dual core Intel with all the software I'm > > building from source (including eg. PROJ, GEOS, HDF4, POSTGIS, GDAL, > > QT4). > > > > But when I build GRASS with make -j3, plenty of errors crop out > > after "Waiting for unfinished jobs...." information. In a result, no > > single GRASS module is build properly. However, GRASS builds fine on > > the same machine if -j3 is not used. > > > > configure and make logs attached. > > The first thing I notice is that the first error is usually a missing > header file, e.g.: > > copy.c:7:28: error: grass/datetime.h: No such file or directory > > adj_cellhd.c:14:23: error: grass/gis.h: No such file or directory > > This is due to the "headers" target in the "libs" directory being run > in parallel with other jobs. > > > This specific issue can probably be solved by changing lib/Makefile > from: > > default: headers subdirs > to: > > default: subdirs > > subdirs: headers > > This should prevent the subdirs target from being run before the > headers target has completed. > > However: I'm not sure whether parallel make will actually be useful > with the existing Makefiles, due to the use of a shell "for" loop for > building subdirectories: > > subdirs: > @list='$(SUBDIRS)'; \ > for subdir in $$list; do \ > echo $$subdir ; \ > $(MAKE) -C $$subdir || echo $(CURDIR)/$$subdir >> $(GRASS_HOME)/error.log; \ > done > > [From include/Make/Dir.make] > > To have the subdirectories built in parallel, you would need to use > something like: > > .PHONY: subdirs $(SUBDIRS) > > subdirs: $(SUBDIRS) > > $(SUBDIRS): > $(MAKE) -C $@ I am interested to get this working but failed to get the second part in include/Make/Dir.make successfully running. Any further hints? My Makefile knowledge is fairly limited unfortunately. Markus From hamish_nospam at yahoo.com Mon Jul 9 11:44:07 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jul 9 11:44:17 2007 Subject: [GRASS-dev] time to release 6.2.2 In-Reply-To: <11455121.post@talk.nabble.com> References: <20070701190509.GA28159@bartok.itc.it> <468D19AE.6050302@jemila.jazztel.es> <11455121.post@talk.nabble.com> Message-ID: <20070709214407.7d58fcb4.hamish_nospam@yahoo.com> proposal: tag 6.2.2rc2 circa now, and if no more major changes are applied release it mostly unchanged as 6.2.2 final in the next 2 weeks. aka any more outstanding issues that are reasonably expected to be fixed? I think it is late in the game to start thinking about backporting translations; iff there is a chance of regressions (?). (Markus, does your pull-in script only add in new untranslated messages, vs wholesale replacement of the .po files based on some a>b test? I worry a bit if the entire file is replaced based on a a>b basis) AFAICT, we're ready to go. ?, Hamish From rez at touchofmadness.com Mon Jul 9 13:21:19 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Mon Jul 9 13:21:25 2007 Subject: [GRASS-dev] time to release 6.2.2 In-Reply-To: <20070709214407.7d58fcb4.hamish_nospam@yahoo.com> References: <20070701190509.GA28159@bartok.itc.it> <468D19AE.6050302@jemila.jazztel.es> <11455121.post@talk.nabble.com> <20070709214407.7d58fcb4.hamish_nospam@yahoo.com> Message-ID: <1183980079.30110.54.camel@dev64.localdomain> On Mon, 2007-07-09 at 21:44 +1200, Hamish wrote: > proposal: tag 6.2.2rc2 circa now, and if no more major changes are applied > release it mostly unchanged as 6.2.2 final in the next 2 weeks. > aka > any more outstanding issues that are reasonably expected to be fixed? Tag, but please do NOT release 6.2.2 until I get a reply on the directory permission/security issue I sent to the list over the weekend. This is a show-stopper until explained or fixed, IMHO. I'm sure you'll all agree when user X does 'rm -rf *' on your working dir. ;-) -- 73, de Brad KB8UYR/6 From neteler at itc.it Mon Jul 9 15:18:13 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Jul 9 15:18:16 2007 Subject: [GRASS-dev] time to release 6.2.2 In-Reply-To: <20070709214407.7d58fcb4.hamish_nospam@yahoo.com> References: <20070701190509.GA28159@bartok.itc.it> <468D19AE.6050302@jemila.jazztel.es> <11455121.post@talk.nabble.com> <20070709214407.7d58fcb4.hamish_nospam@yahoo.com> Message-ID: <46923595.6000909@itc.it> Hamish wrote on 07/09/2007 11:44 AM: > proposal: tag 6.2.2rc2 circa now, and if no more major changes are applied > release it mostly unchanged as 6.2.2 final in the next 2 weeks. > aka > any more outstanding issues that are reasonably expected to be fixed? > The v.in.gns patch needs to be applied I think. And my todays v.db.addtable bugfix needs a test > I think it is late in the game to start thinking about backporting > translations; iff there is a chance of regressions (?). > (Markus, does your pull-in script only add in new untranslated messages, > vs wholesale replacement of the .po files based on some a>b test? I > worry a bit if the entire file is replaced based on a a>b basis) > The script only runs msgmerge in a convenient way, so it is up to gettext. > AFAICT, we're ready to go. > Yes, almost. Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From cdavilam at jemila.jazztel.es Mon Jul 9 17:58:51 2007 From: cdavilam at jemila.jazztel.es (=?ISO-8859-1?Q?Carlos_D=E1vila?=) Date: Mon Jul 9 17:55:45 2007 Subject: [GRASS-dev] time to release 6.2.2 In-Reply-To: <20070709214407.7d58fcb4.hamish_nospam@yahoo.com> References: <20070701190509.GA28159@bartok.itc.it> <468D19AE.6050302@jemila.jazztel.es> <11455121.post@talk.nabble.com> <20070709214407.7d58fcb4.hamish_nospam@yahoo.com> Message-ID: <46925B3B.9010506@jemila.jazztel.es> Hamish escribi?: > > I think it is late in the game to start thinking about backporting > translations; iff there is a chance of regressions (?). > (Markus, does your pull-in script only add in new untranslated messages, > vs wholesale replacement of the .po files based on some a>b test? I > worry a bit if the entire file is replaced based on a a>b basis) > Last Friday I applied Markus script to all languages po files and sent to cvs (releasebranch_6_2 grass6) all those with increased number of translated messages, so it's supposed current translations are backported. As it's the first time I work with this branch, could anyone check I sent them to the right place? Regards Carlos From cdavilam at jemila.jazztel.es Mon Jul 9 19:01:14 2007 From: cdavilam at jemila.jazztel.es (=?ISO-8859-1?Q?Carlos_D=E1vila?=) Date: Mon Jul 9 18:58:07 2007 Subject: [GRASS-dev] Some questions about standardization In-Reply-To: <20070708193905.130704d5.hamish_nospam@yahoo.com> References: <4689303B.4050604@jemila.jazztel.es> <20070708193905.130704d5.hamish_nospam@yahoo.com> Message-ID: <469269DA.2000808@jemila.jazztel.es> Hamish escribi?: > Carlos D?vila wrote: >> a) %s: can't open tempfile -> Unable to open temporary file <%s> (does >> it affect where is the %s?) >> > > The meaning of the string matters, I suspect the first %s string is the > program name, and the second is the filename. So just moving it is wrong > for meaning but ok for C syntax. > OK, I have reverted those files I changed in which %s was program name. Thanks for the point Carlos From benjamin.ducke at ufg.uni-kiel.de Mon Jul 9 19:01:43 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Mon Jul 9 19:02:07 2007 Subject: [GRASS-dev] Some progress on Win32 attribute deadlock problem In-Reply-To: <18063.58602.401705.756221@cerise.gclements.plus.com> References: <468E4F08.80502@ufg.uni-kiel.de> <18063.29272.14994.576966@cerise.gclements.plus.com> <33858.86.103.128.3.1183816658.squirrel@webmail.mail.uni-kiel.de> <18063.58602.401705.756221@cerise.gclements.plus.com> Message-ID: <469269F7.4040604@ufg.uni-kiel.de> OK, I tried some of the suggestion Glynn made below: > > I'm referring to the situation where read/write return a short count, > e.g. "write(fd, buf, count) < count". But, I've remembered that XDR > uses stdio rather than POSIX I/O, and I don't think that fread/fwrite > can return a short count (except for EOF). > > According to the MSVCRT documentation, the O_NOINHERIT flag should be > used when using _dup2(), e.g.: > > _pipe(p1, 250000, _O_BINARY|_O_NOINHERIT) > > Another suggestion: try changing the size passed to the _pipe() > function in dbmi_client/start.c. If that affects the tendency to > deadlock, it strongly suggests that the issue is related to the way > that a full pipe is handled. > > Beyond that, the only thing which I can suggest is to instrument the > XDR code with debug code to log all I/O operations (including the data > which is read/written). > After hundreds of test runs with different Windows versions, these are my conclusions: The problem has to do with the pipe mechanism in Windows. I tried changing the pipe size as suggest, using extremely small (25) and extremely high (250000000) values. On Windows 2000, with the very small value, no module run makes it past 33 percent. So there is a clear correlation. As soon as I set it to some "sane" value (at least 25000), I get the same situation: ca. 4-6 out of 50 runs complete. Increasing the value from here won't make a difference, the differences are always within measuring precision. This is no surprise, since the comment in dbmi_client/start.c states that the pipe buffer value is not directly related to the pipe size. Apparently, Windows choose some fixed value as soon as the size is greated than some threshold. The same thing happens when I set the size to "0". However, the fact that I can block the piping effectively with very small values leaves me believing that this is, as Glynn suggests, the source of the troubles: A full pipe gets stuck and no process ever takes anything out of it to make some room, so the next bit of data cannot be pushed into it. Puller waits for pusher, pusher never pushes, because nothing gets pulled = deadlock. (I think...) Another thing makes me believe that Windows itself is the culprit here: I tested the same stuff on a Windows XP SP2 system, clean install from scratch. On this system, almost all the runs (97%) finished cleanly! Obviously MS did some improvements to process communication in that release ... Setting the _NO_INHERIT flag makes no difference. So, how are we going to go ahead? Best, Benjamin -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From dylan.beaudette at gmail.com Mon Jul 9 21:47:56 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Mon Jul 9 21:48:03 2007 Subject: [GRASS-dev] using slope/aspect functions inside our module In-Reply-To: <18059.49086.129208.14164@cerise.gclements.plus.com> References: <200707031329.04522.yann.chemin@gmail.com> <18059.49086.129208.14164@cerise.gclements.plus.com> Message-ID: <200707091247.57104.dylan.beaudette@gmail.com> On Wednesday 04 July 2007 08:41, Glynn Clements wrote: > "Carlos \"Gu?no\" Grohmann" wrote: > > Interesting. > > Why r.slope.aspect uses > > > > dx = ... / (4 * ewres); > > > > while r.shaded.relief uses > > > > dx = ... / (8 * ewres); > > > > ?? > > Oops. It should be 8; the ewres/nsres values are actually the > distances between the centres of the top/bottom rows and left/right > columns in the 3x3 window, which are two rows/columns apart. IOW, the > 4*ewres should have been 4*(2*ewres) = 8*ewres, ditto for nsres. Yikes, does this mean that previous calculations are now wrong? dylan From hmitaso at unity.ncsu.edu Mon Jul 9 22:04:42 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Mon Jul 9 22:04:47 2007 Subject: [GRASS-dev] using slope/aspect functions inside our module In-Reply-To: <200707091247.57104.dylan.beaudette@gmail.com> References: <200707031329.04522.yann.chemin@gmail.com> <18059.49086.129208.14164@cerise.gclements.plus.com> <200707091247.57104.dylan.beaudette@gmail.com> Message-ID: <9163CF5B-E5BF-4DAF-8BB4-312734AAA5E1@unity.ncsu.edu> On Jul 9, 2007, at 3:47 PM, Dylan Beaudette wrote: > On Wednesday 04 July 2007 08:41, Glynn Clements wrote: >> "Carlos \"Gu?no\" Grohmann" wrote: >>> Interesting. >>> Why r.slope.aspect uses >>> >>> dx = ... / (4 * ewres); >>> >>> while r.shaded.relief uses >>> >>> dx = ... / (8 * ewres); >>> >>> ?? >> >> Oops. It should be 8; the ewres/nsres values are actually the >> distances between the centres of the top/bottom rows and left/right >> columns in the 3x3 window, which are two rows/columns apart. IOW, the >> 4*ewres should have been 4*(2*ewres) = 8*ewres, ditto for nsres. > > Yikes, does this mean that previous calculations are now wrong? no - it is correctly implemented - you would have found that it is wrong by now. It is just that the variable that you divide with in the r.slope.aspect uses 2*ewres (twice the resolution, not just one as is usual in the published equations) - I got caught on that many times when checking the r.slope.aspect code. Helena > > dylan > > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From dylan.beaudette at gmail.com Mon Jul 9 22:25:34 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Mon Jul 9 22:25:37 2007 Subject: [GRASS-dev] using slope/aspect functions inside our module In-Reply-To: <9163CF5B-E5BF-4DAF-8BB4-312734AAA5E1@unity.ncsu.edu> References: <200707031329.04522.yann.chemin@gmail.com> <200707091247.57104.dylan.beaudette@gmail.com> <9163CF5B-E5BF-4DAF-8BB4-312734AAA5E1@unity.ncsu.edu> Message-ID: <200707091325.34724.dylan.beaudette@gmail.com> On Monday 09 July 2007 13:04, Helena Mitasova wrote: > On Jul 9, 2007, at 3:47 PM, Dylan Beaudette wrote: > > On Wednesday 04 July 2007 08:41, Glynn Clements wrote: > >> "Carlos \"Gu?no\" Grohmann" wrote: > >>> Interesting. > >>> Why r.slope.aspect uses > >>> > >>> dx = ... / (4 * ewres); > >>> > >>> while r.shaded.relief uses > >>> > >>> dx = ... / (8 * ewres); > >>> > >>> ?? > >> > >> Oops. It should be 8; the ewres/nsres values are actually the > >> distances between the centres of the top/bottom rows and left/right > >> columns in the 3x3 window, which are two rows/columns apart. IOW, the > >> 4*ewres should have been 4*(2*ewres) = 8*ewres, ditto for nsres. > > > > Yikes, does this mean that previous calculations are now wrong? > > no - it is correctly implemented - you would have found that it is > wrong by now. > It is just that the variable that you divide with in the r.slope.aspect > uses 2*ewres (twice the resolution, not just one as is usual in > the published equations) - I got caught on that many times when checking > the r.slope.aspect code. > > Helena Thanks for the quick reply! That is a relief (! no pun intended there). Cheers, Dylan From glynn at gclements.plus.com Mon Jul 9 23:25:32 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jul 9 23:25:37 2007 Subject: [GRASS-dev] Directory security/permission issue In-Reply-To: <1183874859.30110.35.camel@dev64.localdomain> References: <1183874859.30110.35.camel@dev64.localdomain> Message-ID: <18066.42956.899670.929947@cerise.gclements.plus.com> Brad Douglas wrote: > While looking over my working dirs, today, I noticed that all of my > recent locations were created with 0777 permissions, instead of the > traditional 0755 mask. Temp directories are still created properly. > > 0777 is bad form and a potential security problem. > > Is there a reason for the change I missed? A quick search through the > archives didn't turn up anything. > > It seems to have come as an accidental result of the MINGW changes. The > offending code can be found in lib/gis/paths.c in G_mkdir(). > > This should be explained or corrected before 6.2.2 is released. The mode passed to mkdir is modified by the process' umask to obtain the actual mode of the directory. If you're ending up with world-writable directories, that implies that your umask is zero, which is insecure. Your umask should normally be at least 0022, (or 0022 if you want files to be group-writable, which is sometimes useful); if you're paranoid, use 0077 (i.e. no permissions for anyone but yourself). In general, the permissions specified by a program when calling open(), mkdir(), etc should be the maximum which the user might possibly want (i.e. 0777 for directories and executable files, 0666 for non-executable files), as the umask can only remove permissions, not add them. -- Glynn Clements From glynn at gclements.plus.com Tue Jul 10 00:01:28 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jul 10 00:01:30 2007 Subject: [GRASS-dev] [grass-code I][359] GRASS fails to build with make -j3 In-Reply-To: <20070708100826.GA9749@krokus.itc.it> References: <20070405100155.BE9171973F9B@pyrosoma.intevation.org> <17940.62513.704845.161917@cerise.gclements.plus.com> <20070708100826.GA9749@krokus.itc.it> Message-ID: <18066.45112.122864.20162@cerise.gclements.plus.com> Markus Neteler wrote: > > > code I item #359, was opened at 2007-04-05 12:01 > > > Summary: GRASS fails to build with make -j3 > > However: I'm not sure whether parallel make will actually be useful > > with the existing Makefiles, due to the use of a shell "for" loop for > > building subdirectories: > > > > subdirs: > > @list='$(SUBDIRS)'; \ > > for subdir in $$list; do \ > > echo $$subdir ; \ > > $(MAKE) -C $$subdir || echo $(CURDIR)/$$subdir >> $(GRASS_HOME)/error.log; \ > > done > > > > [From include/Make/Dir.make] > > > > To have the subdirectories built in parallel, you would need to use > > something like: > > > > .PHONY: subdirs $(SUBDIRS) > > > > subdirs: $(SUBDIRS) > > > > $(SUBDIRS): > > $(MAKE) -C $@ > > I am interested to get this working but failed to get the > second part in include/Make/Dir.make successfully running. > > Any further hints? My Makefile knowledge is fairly limited > unfortunately. Note that this cannot be done for all directories. In particular, the inter-dependencies between libraries mean that you cannot build the lib/* directories in an arbitrary order. You would have to either use the existing "for" loop in lib/Makefile, or explicitly list the dependencies, e.g.: gis: datetime driver: gis pngdriver: driver gis psdriver: driver gis raster: driver gis pngdriver psdriver display: gis raster Using the na?ve parallel version for the lib directory will result in severe failure, due to attempting to link other libraries against libgis before libgis has been generated. The top-level directories may as well be built sequentially, but presumably you would want to parallelise within the raster, vector, general etc directories. Parallelising lib is less important as most of the subdirectories contain enough files that parallelising within individual lib/* subdirectories would probably be sufficient. As a first attempt, I'd suggest trying the above idiom in Dir.make, and using the existing loop in lib/Makefile (name the target somthing other than "subdirs" to avoid a conflict with Dir.make). Hopefully, that should keep the number of errors down to manageable proportions (it's a safe bet that at least some of the individual module/lib Makefiles rely upon sequential processing). -- Glynn Clements From rez at touchofmadness.com Tue Jul 10 02:37:10 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Tue Jul 10 02:37:16 2007 Subject: [GRASS-dev] Directory security/permission issue In-Reply-To: <18066.42956.899670.929947@cerise.gclements.plus.com> References: <1183874859.30110.35.camel@dev64.localdomain> <18066.42956.899670.929947@cerise.gclements.plus.com> Message-ID: <1184027830.30110.97.camel@dev64.localdomain> On Mon, 2007-07-09 at 22:25 +0100, Glynn Clements wrote: > Brad Douglas wrote: > > > While looking over my working dirs, today, I noticed that all of my > > recent locations were created with 0777 permissions, instead of the > > traditional 0755 mask. Temp directories are still created properly. > > > > 0777 is bad form and a potential security problem. > > > > Is there a reason for the change I missed? A quick search through the > > archives didn't turn up anything. > > > > It seems to have come as an accidental result of the MINGW changes. The > > offending code can be found in lib/gis/paths.c in G_mkdir(). > > > > This should be explained or corrected before 6.2.2 is released. > > The mode passed to mkdir is modified by the process' umask to obtain > the actual mode of the directory. If you're ending up with > world-writable directories, that implies that your umask is zero, > which is insecure. > > Your umask should normally be at least 0022, (or 0022 if you want > files to be group-writable, which is sometimes useful); if you're > paranoid, use 0077 (i.e. no permissions for anyone but yourself). umask...figures. Your lack of cerebral bitrot astounds me. I had completely forgotten about it and I, apparently, was too arrogant to look at a manpage. ;-) Don't know how, but my umask was set to 0002. -- 73, de Brad KB8UYR/6 From peter.loewe at gmx.de Tue Jul 10 09:53:09 2007 From: peter.loewe at gmx.de (peter.loewe@gmx.de) Date: Tue Jul 10 09:53:11 2007 Subject: [GRASS-dev] v.out.kml: calling for betatesters Message-ID: <20070710075309.313410@gmx.net> Hello, there is a new add-on script to create KML from GRASS vectors. It is available at http://grasslab.gisix.com/scripts/v.out.kml/ and also linked under http://grass.gdf-hannover.de/wiki/GRASS_AddOns It works pretty good for me, but please send feedback if things need to be improved. Peter -- Dr. Peter L?we Psssst! Schon vom neuen GMX MultiMessenger geh?rt? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger From cavallini at faunalia.it Tue Jul 10 10:10:35 2007 From: cavallini at faunalia.it (Paolo Cavallini) Date: Tue Jul 10 10:10:42 2007 Subject: [GRASS-dev] v.out.kml: calling for betatesters In-Reply-To: <20070710075309.313410@gmx.net> References: <20070710075309.313410@gmx.net> Message-ID: <46933EFB.90005@faunalia.it> small typo on the web page: The requested URL /scripts/v.out.kml/v.out.kml.sh/ was not found on this server. final / should be removed. pc peter.loewe@gmx.de ha scritto: > Hello, > > there is a new add-on script to create KML from GRASS vectors. > > It is available at > http://grasslab.gisix.com/scripts/v.out.kml/ > and also linked under > http://grass.gdf-hannover.de/wiki/GRASS_AddOns > > It works pretty good for me, but please send feedback if things need to be improved. > > Peter > > -- Paolo Cavallini http://www.faunalia.it/pc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070710/01641a90/signature.bin From grass-codei at wald.intevation.org Tue Jul 10 12:36:54 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Tue Jul 10 12:35:08 2007 Subject: [GRASS-dev] [grass-code I][444] v.in.ogr: false optional 'dsn' and 'output' Message-ID: <20070710103654.7DEBA400D5@pyrosoma.intevation.org> code I item #444, was opened at 2007-07-10 12:36 Status: Open Priority: 3 Submitted By: Maciej Sieczka (msieczka) Assigned to: Nobody (None) Summary: v.in.ogr: false optional 'dsn' and 'output' Issue type: module bug Issue status: None GRASS version: CVS HEAD GRASS component: vector Operating system: all Operating system version: GRASS CVS checkout date, if applies (YYMMDD): 070710 Initial Comment: v.in.ogr advertises the 'dsn' and 'output' as optional in 6.3 CVS: GRASS 6.3.cvs (spearfish60):~ > v.in.ogr help 2>&1 | grep Usage -A1 Usage: v.in.ogr [-lfcztoew] [dsn=string] [output=name] (see the brackets around options dsn and output; their presence is interpreted as "optional" by the autogenerated tcl/tk GUI) In current CVS GRASS 6.2 these options are required: GRASS 6.2.2cvs (spearfish60):~ > v.in.ogr help 2>&1 | grep Usage -A1 Usage: v.in.ogr [-lfcztoe] dsn=string output=name [layer=string[,string,...]] (no brackets around options dsn and output) And they should be required for sure: $ v.in.ogr -l dsn=. Data source contains 11 layers: cieki, drogi, laka, las, park, rowy, sciezki, waly, woda, zabudowa, zarosla $ v.in.ogr out=something ERROR: Required parameter not set $ v.in.ogr dsn=. ERROR: Required parameter not set $ v.in.ogr dsn=cieki.shp ERROR: Required parameter not set Maciek ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=444&group_id=21 From Agustin.Diez at uv.es Tue Jul 10 15:49:42 2007 From: Agustin.Diez at uv.es (Agustin Diez Castillo) Date: Tue Jul 10 15:52:14 2007 Subject: [GRASS-dev] v.out.kml: calling for betatesters In-Reply-To: <20070710075309.313410@gmx.net> References: <20070710075309.313410@gmx.net> Message-ID: Peter, I was looking for that, thanks. I have tested it against the new nc_spm_05 mapset with both NO success and success (see link below) and the following error twice icontransparency=255/Applications/GRASS-6.3.app/Contents/Resources/ scripts/v.out.kml.sh: line 471: ${$THE_OGR_PATH}: bad substitution First from the popup menu ************************** v.out.kml.sh -l map=roadsmajor@PERMANENT output=/Users/adiez/Desktop/ pruebakmloutgrass.kml color=00:200:00 transparency=255 fcolor=00:100:00 ftransparency=255 size=1 iconcode=1 iconpalette=1 iconcolor=00:200:00 icontransparency=255 /Applications/GRASS-6.3.app/Contents/Resources/scripts/v.out.kml.sh: line 471: ${$THE_OGR_PATH}: bad substitution Location latlon_location_8464 created! Input Projection Parameters: +proj=lcc +lat_1=34.33333333333334 +lat_2=36.16666666666666 +lat_0=33.75 +lon_0=-79 +x_0=609601.22 +y_0=0 +no_defs +a=6378137 +rf=298.257222101 +towgs84=0.000,0.000,0.000 Input Unit Factor: 1 Output Projection Parameters: +proj=longlat +no_defs +a=6378137 +rf=298.257223563 +towgs84=0.000,0.000,0.000 Output Unit Factor: 1 Re-projecting vector map... WARNING: Default driver / database set to: driver: dbf database: $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ dbmi: Protocol error WARNING: Cannot create new table dbmi: Protocol error WARNING: Cannot copy table Building topology ... 355 primitives registered Building areas: 100% 0 areas built 0 isles built Attaching islands: Attaching centroids: 100% Topology was built. Number of nodes : 266 Number of primitives: 355 Number of points : 0 Number of lines : 355 Number of boundaries: 0 Number of centroids : 0 Number of areas : 0 Number of isles : 0 ERROR: Could not find input vector map -f KML /Users/adiez/Desktop/pruebakmloutgrass.kml.raw roadsmajor@PERMANENT.sh /Applications/GRASS-6.3.app/Contents/Resources/scripts/v.out.kml.sh: line 571: FAILURE:: command not found ERROR: aborted. ******************* Then from cli, after copying roadsmajor@PERMANENT to roadmajors at current mapset ****** v.out.kml.sh -l map=roadsmajorc output=/Users/adiez/Desktop/ pruebakmloutgrass.kml color=00:200:00 transparency=255 fcolor=00:100:00 ftransparency=255 size=1 iconcode=1 iconpalette=1 iconcolor=00:200:00 icontransparency=255/Applications/GRASS-6.3.app/ Contents/Resources/scripts/v.out.kml.sh: line 471: ${$THE_OGR_PATH}: bad substitution Location latlon_location_8938 created! Input Projection Parameters: +proj=lcc +lat_1=34.33333333333334 +lat_2=36.16666666666666 +lat_0=33.75 +lon_0=-79 +x_0=609601.22 +y_0=0 +no_defs +a=6378137 +rf=298.257222101 +towgs84=0.000,0.000,0.000 Input Unit Factor: 1 Output Projection Parameters: +proj=longlat +no_defs +a=6378137 +rf=298.257223563 +towgs84=0.000,0.000,0.000 Output Unit Factor: 1 Re-projecting vector map... WARNING: Default driver / database set to: driver: dbf database: $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ Building topology ... 355 primitives registered Building areas: 100% 0 areas built 0 isles built Attaching islands: Attaching centroids: 100% Topology was built. Number of nodes : 266 Number of primitives: 355 Number of points : 0 Number of lines : 355 Number of boundaries: 0 Number of centroids : 0 Number of areas : 0 Number of isles : 0 Exporting 355 points/lines... 100% 355 features written -f KML /Users/adiez/Desktop/pruebakmloutgrass.kml.raw roadsmajorc.sh See for results, in green grass kml http://www.uv.es/adiez/images/grassoutkml.png On Jul 10, 2007, at 9:53 AM, peter.loewe@gmx.de wrote: > Hello, > > there is a new add-on script to create KML from GRASS vectors. > > It is available at > http://grasslab.gisix.com/scripts/v.out.kml/ > and also linked under > http://grass.gdf-hannover.de/wiki/GRASS_AddOns > > It works pretty good for me, but please send feedback if things > need to be improved. > > Peter > > > -- > Dr. Peter L?we > > > > > > > Psssst! Schon vom neuen GMX MultiMessenger geh?rt? > Der kanns mit allen: http://www.gmx.net/de/go/multimessenger > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070710/e689db18/attachment-0001.html From benjamin.ducke at ufg.uni-kiel.de Tue Jul 10 16:57:23 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Tue Jul 10 16:58:02 2007 Subject: [GRASS-dev] Win32 DBMI lockups: change to nonblocking pipes? In-Reply-To: <20070710103654.7DEBA400D5@pyrosoma.intevation.org> References: <20070710103654.7DEBA400D5@pyrosoma.intevation.org> Message-ID: <46939E53.6050206@ufg.uni-kiel.de> After doing some more testing (QGIS and GRASS on Linux, GRASS native w/o QGIS from http://qgis.org/uploadfiles/testbuilds/), I still think that possible pipe blocking is the hottest lead so far. There are some comments (maybe written by Radim Blazek?) in start.c which suggest the same: /* I have seen problems with pipes on NT 5.1 probably related * to buffer size (psize, originaly 512 bytes). * But I am not sure, some problems were fixed by bigger * buffer but others remain. * Simple test which failed on NT 5.1 worked on NT 5.2 * But there are probably other factors. I would like to change the pipes in lib/db/dbmi_client/start.c to nonblocking I/O. If those hints are right, then this should fix the problem, I guess. However, as always with Windows, things are more frustrating then they should be. I have been digging into Win32 internals and it seems that you cannot open anonymous pipes (which is what start.c does) in nonblocking mode on Win32 (on Linux you can use fctl for this): http://en.wikipedia.org/wiki/Anonymous_pipe What puzzles me is this comment in start.c: /* More info about pipes from MSDN: - Anonymous pipes are implemented using a named pipe with a unique name. So there must be a way to open pipes "p1" and "p2" in nonblocking mode!? If not: is there a way to switch to a named pipe for the DBMI driver? If there are any Windows hackers here that would like to give it a try but don't want to invest the time setting up a compile and test environment: let me know and I'll upload the complete toolset and sample data. Thanks for any help, Benjamin -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From glynn at gclements.plus.com Tue Jul 10 17:00:00 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jul 10 17:00:04 2007 Subject: [GRASS-dev] Some progress on Win32 attribute deadlock problem In-Reply-To: <469269F7.4040604@ufg.uni-kiel.de> References: <468E4F08.80502@ufg.uni-kiel.de> <18063.29272.14994.576966@cerise.gclements.plus.com> <33858.86.103.128.3.1183816658.squirrel@webmail.mail.uni-kiel.de> <18063.58602.401705.756221@cerise.gclements.plus.com> <469269F7.4040604@ufg.uni-kiel.de> Message-ID: <18067.40688.442971.607995@cerise.gclements.plus.com> Benjamin Ducke wrote: > > I'm referring to the situation where read/write return a short count, > > e.g. "write(fd, buf, count) < count". But, I've remembered that XDR > > uses stdio rather than POSIX I/O, and I don't think that fread/fwrite > > can return a short count (except for EOF). > > > > According to the MSVCRT documentation, the O_NOINHERIT flag should be > > used when using _dup2(), e.g.: > > > > _pipe(p1, 250000, _O_BINARY|_O_NOINHERIT) > > > > Another suggestion: try changing the size passed to the _pipe() > > function in dbmi_client/start.c. If that affects the tendency to > > deadlock, it strongly suggests that the issue is related to the way > > that a full pipe is handled. > > > > Beyond that, the only thing which I can suggest is to instrument the > > XDR code with debug code to log all I/O operations (including the data > > which is read/written). > > After hundreds of test runs with different Windows versions, these > are my conclusions: > > The problem has to do with the pipe mechanism in Windows. > I tried changing the pipe size as suggest, using extremely small (25) > and extremely high (250000000) values. On Windows 2000, with > the very small value, no module run makes it past 33 percent. So there > is a clear correlation. As soon as I set it to some "sane" value > (at least 25000), I get the same situation: ca. 4-6 out of 50 runs > complete. Increasing the value from here won't make a difference, > the differences are always within measuring precision. > > This is no surprise, since the comment in dbmi_client/start.c states > that the pipe buffer value is not directly related to the pipe size. > Apparently, Windows choose some fixed value as soon as the size > is greated than some threshold. The same thing happens when I set > the size to "0". > > However, the fact that I can block the piping effectively with > very small values leaves me believing that this is, as Glynn > suggests, the source of the troubles: > A full pipe gets stuck and no process ever takes anything out of > it to make some room, so the next bit of data cannot be pushed into > it. Puller waits for pusher, pusher never pushes, because nothing > gets pulled = deadlock. (I think...) The reader won't be waiting for the writer if it already has a full pipe of data available. The usual reason for co-processes (two processes connected via a read/write pair of pipes) to deadlock is that both are trying to write to full pipes. Neither process can continue until their write pipe is drained, which won't happen as each process is blocked. [The situation where both are blocked trying to read from empty pipes is theoretically possible but uncommon in practice, as it indicates a fundamental design error, whereas the both-blocked-on-write case is usually due to a relatively simple oversight.] Briefly, the drivers use a synchronous RPC mechanism: Phase Client Driver 1. Client sends request write(1) read(1) 2. Driver reads request read(2) read(1) 3. Driver processes request read(2) busy(2) 4. Driver sends response read(2) write(3) 5. Client reads response read(2) read(1) Client: do_request(...) { 1: send_request(); 2: read_response(); } Driver: main_loop(...) { while (!eof(...)) { 1: read_request(); 2: process_request(); 3: send_response(); } } For this mechanism to work, each process (client and driver) must read exactly what it is sent before proceeding, and must send exactly what the client expects to receive. The driver must not send the response before it has read the entire request, even if it intends to discard it. Similarly, the client must read any response before sending the next request; it can't send a bunch of requests then read all of the responses later. Having said all of that, there can't be any fundamental design problems if it works fine on Unix. One possibility is incorrect handling of an error condition which only occurs on Windows. It's also possible that the Windows stdio implementation doesn't like _pipe(). If it doesn't handle short reads/writes correctly, that won't affect files, and it probably won't affect pipes which never fill up, but it may fall down on a full pipe. > Another thing makes me believe that Windows itself is the culprit > here: I tested the same stuff on a Windows XP SP2 system, clean > install from scratch. On this system, almost all the runs (97%) > finished cleanly! > > Obviously MS did some improvements to process communication in that > release ... Not necessarily. If the issue is related to timing, it could just be that everything runs more smoothly due to the clean install (rather than SP2). > Setting the _NO_INHERIT flag makes no difference. > > So, how are we going to go ahead? Figure out how to debug the processes. If you can't get gdb to work, I can only suggest logging every significant event at the lowest level, i.e. log every read/write operation: the arguments, the return code, and the complete data (i.e. the buffer contents before read and after write). This is all done in the RPC/XDR library, in xdr_stdio.c. It will probably help to also log the beginning/end of each procedure call (i.e. lib/db/dbmi_base/xdrprocedure.c). -- Glynn Clements From benjamin.ducke at ufg.uni-kiel.de Tue Jul 10 17:02:55 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Tue Jul 10 17:03:36 2007 Subject: [GRASS-dev] Some progress on Win32 attribute deadlock problem In-Reply-To: <18067.40688.442971.607995@cerise.gclements.plus.com> References: <468E4F08.80502@ufg.uni-kiel.de> <18063.29272.14994.576966@cerise.gclements.plus.com> <33858.86.103.128.3.1183816658.squirrel@webmail.mail.uni-kiel.de> <18063.58602.401705.756221@cerise.gclements.plus.com> <469269F7.4040604@ufg.uni-kiel.de> <18067.40688.442971.607995@cerise.gclements.plus.com> Message-ID: <46939F9F.1020902@ufg.uni-kiel.de> Glynn, my last posting to the GRASS dev list overlapped with yours. I'll try to find the time and do as you suggested. Best, Ben Glynn Clements wrote: > Benjamin Ducke wrote: > >>> I'm referring to the situation where read/write return a short count, >>> e.g. "write(fd, buf, count) < count". But, I've remembered that XDR >>> uses stdio rather than POSIX I/O, and I don't think that fread/fwrite >>> can return a short count (except for EOF). >>> >>> According to the MSVCRT documentation, the O_NOINHERIT flag should be >>> used when using _dup2(), e.g.: >>> >>> _pipe(p1, 250000, _O_BINARY|_O_NOINHERIT) >>> >>> Another suggestion: try changing the size passed to the _pipe() >>> function in dbmi_client/start.c. If that affects the tendency to >>> deadlock, it strongly suggests that the issue is related to the way >>> that a full pipe is handled. >>> >>> Beyond that, the only thing which I can suggest is to instrument the >>> XDR code with debug code to log all I/O operations (including the data >>> which is read/written). >> After hundreds of test runs with different Windows versions, these >> are my conclusions: >> >> The problem has to do with the pipe mechanism in Windows. >> I tried changing the pipe size as suggest, using extremely small (25) >> and extremely high (250000000) values. On Windows 2000, with >> the very small value, no module run makes it past 33 percent. So there >> is a clear correlation. As soon as I set it to some "sane" value >> (at least 25000), I get the same situation: ca. 4-6 out of 50 runs >> complete. Increasing the value from here won't make a difference, >> the differences are always within measuring precision. >> >> This is no surprise, since the comment in dbmi_client/start.c states >> that the pipe buffer value is not directly related to the pipe size. >> Apparently, Windows choose some fixed value as soon as the size >> is greated than some threshold. The same thing happens when I set >> the size to "0". >> >> However, the fact that I can block the piping effectively with >> very small values leaves me believing that this is, as Glynn >> suggests, the source of the troubles: >> A full pipe gets stuck and no process ever takes anything out of >> it to make some room, so the next bit of data cannot be pushed into >> it. Puller waits for pusher, pusher never pushes, because nothing >> gets pulled = deadlock. (I think...) > > The reader won't be waiting for the writer if it already has a full > pipe of data available. > > The usual reason for co-processes (two processes connected via a > read/write pair of pipes) to deadlock is that both are trying to write > to full pipes. Neither process can continue until their write pipe is > drained, which won't happen as each process is blocked. > > [The situation where both are blocked trying to read from empty pipes > is theoretically possible but uncommon in practice, as it indicates a > fundamental design error, whereas the both-blocked-on-write case is > usually due to a relatively simple oversight.] > > Briefly, the drivers use a synchronous RPC mechanism: > > Phase Client Driver > > 1. Client sends request write(1) read(1) > 2. Driver reads request read(2) read(1) > 3. Driver processes request read(2) busy(2) > 4. Driver sends response read(2) write(3) > 5. Client reads response read(2) read(1) > > Client: > > do_request(...) > { > 1: send_request(); > 2: read_response(); > } > > Driver: > > main_loop(...) > { > while (!eof(...)) > { > 1: read_request(); > 2: process_request(); > 3: send_response(); > } > } > > For this mechanism to work, each process (client and driver) must read > exactly what it is sent before proceeding, and must send exactly what > the client expects to receive. The driver must not send the response > before it has read the entire request, even if it intends to discard > it. Similarly, the client must read any response before sending the > next request; it can't send a bunch of requests then read all of the > responses later. > > Having said all of that, there can't be any fundamental design > problems if it works fine on Unix. One possibility is incorrect > handling of an error condition which only occurs on Windows. > > It's also possible that the Windows stdio implementation doesn't like > _pipe(). If it doesn't handle short reads/writes correctly, that won't > affect files, and it probably won't affect pipes which never fill up, > but it may fall down on a full pipe. > >> Another thing makes me believe that Windows itself is the culprit >> here: I tested the same stuff on a Windows XP SP2 system, clean >> install from scratch. On this system, almost all the runs (97%) >> finished cleanly! >> >> Obviously MS did some improvements to process communication in that >> release ... > > Not necessarily. If the issue is related to timing, it could just be > that everything runs more smoothly due to the clean install (rather > than SP2). > >> Setting the _NO_INHERIT flag makes no difference. >> >> So, how are we going to go ahead? > > Figure out how to debug the processes. If you can't get gdb to work, I > can only suggest logging every significant event at the lowest level, > i.e. log every read/write operation: the arguments, the return code, > and the complete data (i.e. the buffer contents before read and after > write). This is all done in the RPC/XDR library, in xdr_stdio.c. It > will probably help to also log the beginning/end of each procedure > call (i.e. lib/db/dbmi_base/xdrprocedure.c). > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From cdavilam at jemila.jazztel.es Tue Jul 10 17:47:14 2007 From: cdavilam at jemila.jazztel.es (=?ISO-8859-15?Q?Carlos_D=E1vila?=) Date: Tue Jul 10 17:44:02 2007 Subject: [GRASS-dev] Possible error in r.flow error message Message-ID: <4693AA02.5000904@jemila.jazztel.es> I have tested r.flow looking for messages to standardize. I gave a non existing input elevation raster map, so I waited "Cannot find file %s" but error message is "out of memory". Is it the right behaviour? Does it check memory before looking for the input map? If so, why doesn't it get memory? I thank any help. Carlos From hmitaso at unity.ncsu.edu Tue Jul 10 17:55:14 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Tue Jul 10 17:55:18 2007 Subject: [GRASS-dev] Possible error in r.flow error message In-Reply-To: <4693AA02.5000904@jemila.jazztel.es> References: <4693AA02.5000904@jemila.jazztel.es> Message-ID: <1184082914.13812.38.camel@deliboz> On Tue, 2007-07-10 at 17:47 +0200, Carlos D?vila wrote: > I have tested r.flow looking for messages to standardize. I gave a non > existing input elevation raster map, so I waited "Cannot find file %s" > but error message is "out of memory". Is it the right behaviour? Does it > check memory before looking for the input map? If so, why doesn't it get > memory? that is certainly not a right behavior - let me look at it, Helena > I thank any help. > Carlos > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From glynn at gclements.plus.com Tue Jul 10 18:03:03 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jul 10 18:03:07 2007 Subject: [GRASS-dev] using slope/aspect functions inside our module In-Reply-To: <200707091247.57104.dylan.beaudette@gmail.com> References: <200707031329.04522.yann.chemin@gmail.com> <18059.49086.129208.14164@cerise.gclements.plus.com> <200707091247.57104.dylan.beaudette@gmail.com> Message-ID: <18067.44471.335333.381140@cerise.gclements.plus.com> Dylan Beaudette wrote: > > > Interesting. > > > Why r.slope.aspect uses > > > > > > dx = ... / (4 * ewres); > > > > > > while r.shaded.relief uses > > > > > > dx = ... / (8 * ewres); > > > > > > ?? > > > > Oops. It should be 8; the ewres/nsres values are actually the > > distances between the centres of the top/bottom rows and left/right > > columns in the 3x3 window, which are two rows/columns apart. IOW, the > > 4*ewres should have been 4*(2*ewres) = 8*ewres, ditto for nsres. > > Yikes, does this mean that previous calculations are now wrong? No. I just made a mistake in "paraphrasing" the code. The actual code for r.slope.aspect has: V = G_distance(east, north, east, south) * 4 / zfactor; H = G_distance(east, ns_med, west, ns_med) * 4 / zfactor; ... dx = ((*c1 + *c4 + *c4 + *c7) - (*c3 + *c6 + *c6 + *c9)) / H; dy = ((*c7 + *c8 + *c8 + *c9) - (*c1 + *c2 + *c2 + *c3)) / V; I paraphrased the result of G_distance nsres/ewres, but it's actually twice that. The factor of 4 corresponds to the weights of 1+2+1 = 4, while the factor of 2 corresponds to the distance in cells. It might be clearer to write the calculation as: dx = ((c1/4 + c4/2 + c7/4) - (c3/4 + c6/2 + c9/4)) / (2 * ewres); dy = ((c7/4 + c8/2 + c9/4) - (c1/4 + c2/2 + c3/4)) / (2 * nsres); r.slope.aspect premultiplies the 4 into the divisors to eliminate the divisions from the weighting. I'm not sure of the theoretical basis behind the weights used. A simpler approach would be to ignore the corners and use: dx = (c4 - c6) / (2 * ewres); dy = (c8 - c2) / (2 * nsres); This still produces the correct result for a sampled planar surface (it's also the approach used by r.bilinear and r.resamp.interp). Ultimately, computing the slope of a DEM requires some form of interpolation, and the choice of algorithm is largely arbitrary (if you don't interpolate, the surface is a grid of horizontal rectangles, so the slope is always either zero or infinite). -- Glynn Clements From glynn at gclements.plus.com Tue Jul 10 18:27:18 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jul 10 18:27:21 2007 Subject: [GRASS-dev] Directory security/permission issue In-Reply-To: <1184027830.30110.97.camel@dev64.localdomain> References: <1183874859.30110.35.camel@dev64.localdomain> <18066.42956.899670.929947@cerise.gclements.plus.com> <1184027830.30110.97.camel@dev64.localdomain> Message-ID: <18067.45926.245689.116789@cerise.gclements.plus.com> Brad Douglas wrote: > > > While looking over my working dirs, today, I noticed that all of my > > > recent locations were created with 0777 permissions, instead of the > > > traditional 0755 mask. Temp directories are still created properly. > > > > > > 0777 is bad form and a potential security problem. > > > > > > Is there a reason for the change I missed? A quick search through the > > > archives didn't turn up anything. > > > > > > It seems to have come as an accidental result of the MINGW changes. The > > > offending code can be found in lib/gis/paths.c in G_mkdir(). > > > > > > This should be explained or corrected before 6.2.2 is released. > > > > The mode passed to mkdir is modified by the process' umask to obtain > > the actual mode of the directory. If you're ending up with > > world-writable directories, that implies that your umask is zero, > > which is insecure. > > > > Your umask should normally be at least 0022, (or 0022 if you want > > files to be group-writable, which is sometimes useful); if you're > > paranoid, use 0077 (i.e. no permissions for anyone but yourself). > > umask...figures. Your lack of cerebral bitrot astounds me. I had > completely forgotten about it and I, apparently, was too arrogant to > look at a manpage. ;-) > > Don't know how, but my umask was set to 0002. Odd; 0002 should give mode 775 for directories. init sets it to 0002, and that will propagate to anything which doesn't change it. It's quite common to set it in the bash startup scripts (/etc/profile, ~/.bash_profile, ~/.bashrc etc). If it's set in the "login" scripts (/etc/profile, ~/.bash_profile, ~/.bash_login), it may not take effect for X sessions. The X startup scripts don't normally source those scripts, and bash will only source them for a login shell (and xterm doesn't create a login shell by default; use "-ls" or set "XTerm.vt100.loginShell: true"). -- Glynn Clements From hmitaso at unity.ncsu.edu Tue Jul 10 18:32:41 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Tue Jul 10 18:32:44 2007 Subject: [GRASS-dev] using slope/aspect functions inside our module In-Reply-To: <18067.44471.335333.381140@cerise.gclements.plus.com> References: <200707031329.04522.yann.chemin@gmail.com> <18059.49086.129208.14164@cerise.gclements.plus.com> <200707091247.57104.dylan.beaudette@gmail.com> <18067.44471.335333.381140@cerise.gclements.plus.com> Message-ID: <1184085161.13812.55.camel@deliboz> On Tue, 2007-07-10 at 17:03 +0100, Glynn Clements wrote: > Dylan Beaudette wrote: > > > > > Interesting. > > > > Why r.slope.aspect uses > > > > > > > > dx = ... / (4 * ewres); > > > > > > > > while r.shaded.relief uses > > > > > > > > dx = ... / (8 * ewres); > > > > > > > > ?? > > > > > > Oops. It should be 8; the ewres/nsres values are actually the > > > distances between the centres of the top/bottom rows and left/right > > > columns in the 3x3 window, which are two rows/columns apart. IOW, the > > > 4*ewres should have been 4*(2*ewres) = 8*ewres, ditto for nsres. > > > > Yikes, does this mean that previous calculations are now wrong? > > No. I just made a mistake in "paraphrasing" the code. > > The actual code for r.slope.aspect has: > > V = G_distance(east, north, east, south) * 4 / zfactor; > H = G_distance(east, ns_med, west, ns_med) * 4 / zfactor; > ... > dx = ((*c1 + *c4 + *c4 + *c7) - (*c3 + *c6 + *c6 + *c9)) / H; > dy = ((*c7 + *c8 + *c8 + *c9) - (*c1 + *c2 + *c2 + *c3)) / V; > > I paraphrased the result of G_distance nsres/ewres, but it's actually > twice that. > > The factor of 4 corresponds to the weights of 1+2+1 = 4, while the > factor of 2 corresponds to the distance in cells. > > It might be clearer to write the calculation as: > > dx = ((c1/4 + c4/2 + c7/4) - (c3/4 + c6/2 + c9/4)) / (2 * ewres); > dy = ((c7/4 + c8/2 + c9/4) - (c1/4 + c2/2 + c3/4)) / (2 * nsres); > > r.slope.aspect premultiplies the 4 into the divisors to eliminate the > divisions from the weighting. > > I'm not sure of the theoretical basis behind the weights used. A > simpler approach would be to ignore the corners and use: > > dx = (c4 - c6) / (2 * ewres); > dy = (c8 - c2) / (2 * nsres); > > This still produces the correct result for a sampled planar surface > (it's also the approach used by r.bilinear and r.resamp.interp). > > Ultimately, computing the slope of a DEM requires some form of > interpolation, and the choice of algorithm is largely arbitrary (if > you don't interpolate, the surface is a grid of horizontal rectangles, > so the slope is always either zero or infinite). just a note for record - the choice of algorithm does make a difference (I think it was Brad who sent me an excellent paper on it some time ago),the equation for the polynomial that is used for approximation here is in the GRAS book appendix and also in the upcoming Geomorphometry book (it has a chapter about Geomorphometry in GRASS). As long as the 3x3 neighborhood and a bivariate 2nd order polynomial is enough, this is a very simple and accurate algorithm (introduced by Horn in 1981 for a pioneering work for computing illuminated terrain maps). Some simpler algorithms can produce pretty bad results. But the way how it is written in r.slope.aspect is quite confusing - I think it is mostly due to the fact that it needs to call G_distance rather than using plain ewres to get the latlong converted to actual distance. We already had a discussion on that topic too, Helena > From dylan.beaudette at gmail.com Tue Jul 10 18:42:34 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Tue Jul 10 18:42:39 2007 Subject: [GRASS-dev] using slope/aspect functions inside our module In-Reply-To: <1184085161.13812.55.camel@deliboz> References: <200707031329.04522.yann.chemin@gmail.com> <18067.44471.335333.381140@cerise.gclements.plus.com> <1184085161.13812.55.camel@deliboz> Message-ID: <200707100942.34815.dylan.beaudette@gmail.com> On Tuesday 10 July 2007 09:32, Helena Mitasova wrote: > On Tue, 2007-07-10 at 17:03 +0100, Glynn Clements wrote: > > Dylan Beaudette wrote: > > > > > Interesting. > > > > > Why r.slope.aspect uses > > > > > > > > > > dx = ... / (4 * ewres); > > > > > > > > > > while r.shaded.relief uses > > > > > > > > > > dx = ... / (8 * ewres); > > > > > > > > > > ?? > > > > > > > > Oops. It should be 8; the ewres/nsres values are actually the > > > > distances between the centres of the top/bottom rows and left/right > > > > columns in the 3x3 window, which are two rows/columns apart. IOW, the > > > > 4*ewres should have been 4*(2*ewres) = 8*ewres, ditto for nsres. > > > > > > Yikes, does this mean that previous calculations are now wrong? > > > > No. I just made a mistake in "paraphrasing" the code. > > > > The actual code for r.slope.aspect has: > > > > V = G_distance(east, north, east, south) * 4 / zfactor; > > H = G_distance(east, ns_med, west, ns_med) * 4 / zfactor; > > ... > > dx = ((*c1 + *c4 + *c4 + *c7) - (*c3 + *c6 + *c6 + *c9)) / H; > > dy = ((*c7 + *c8 + *c8 + *c9) - (*c1 + *c2 + *c2 + *c3)) / V; > > > > I paraphrased the result of G_distance nsres/ewres, but it's actually > > twice that. > > > > The factor of 4 corresponds to the weights of 1+2+1 = 4, while the > > factor of 2 corresponds to the distance in cells. > > > > It might be clearer to write the calculation as: > > > > dx = ((c1/4 + c4/2 + c7/4) - (c3/4 + c6/2 + c9/4)) / (2 * ewres); > > dy = ((c7/4 + c8/2 + c9/4) - (c1/4 + c2/2 + c3/4)) / (2 * nsres); > > > > r.slope.aspect premultiplies the 4 into the divisors to eliminate the > > divisions from the weighting. > > > > I'm not sure of the theoretical basis behind the weights used. A > > simpler approach would be to ignore the corners and use: > > > > dx = (c4 - c6) / (2 * ewres); > > dy = (c8 - c2) / (2 * nsres); > > > > This still produces the correct result for a sampled planar surface > > (it's also the approach used by r.bilinear and r.resamp.interp). > > > > Ultimately, computing the slope of a DEM requires some form of > > interpolation, and the choice of algorithm is largely arbitrary (if > > you don't interpolate, the surface is a grid of horizontal rectangles, > > so the slope is always either zero or infinite). > > just a note for record - the choice of algorithm does make a difference > (I think it was Brad who sent me an excellent paper on it some time > ago),the equation for the polynomial that is used for approximation here > is in the GRAS book appendix and also in the upcoming Geomorphometry > book (it has a chapter about Geomorphometry in GRASS). As long as the > 3x3 neighborhood and a bivariate 2nd order polynomial is enough, this is > a very simple and accurate algorithm (introduced by Horn in 1981 for a > pioneering work for computing illuminated terrain maps). Some simpler > algorithms can produce pretty bad results. > > But the way how it is written in r.slope.aspect is quite confusing - I > think it is mostly due to the fact that it needs to call G_distance > rather than using plain ewres to get the latlong converted to actual > distance. We already had a discussion on that topic too, > > Helena > > While we are on this topic, it might be interesting to allow power users to specify the algorithm. I think that the paper that you are mentioning might be in my filing cabinet... just cannot quite recall the authors! I will check when back in town. cheers, dylan From neteler at itc.it Tue Jul 10 19:06:32 2007 From: neteler at itc.it (Markus Neteler) Date: Tue Jul 10 19:06:34 2007 Subject: [GRASS-dev] [grass-code I][359] GRASS fails to build with make -j3 In-Reply-To: <18066.45112.122864.20162@cerise.gclements.plus.com> References: <20070405100155.BE9171973F9B@pyrosoma.intevation.org> <17940.62513.704845.161917@cerise.gclements.plus.com> <20070708100826.GA9749@krokus.itc.it> <18066.45112.122864.20162@cerise.gclements.plus.com> Message-ID: <11525174.post@talk.nabble.com> Glynn Clements wrote: > > > Markus Neteler wrote: > >> > > code I item #359, was opened at 2007-04-05 12:01 >> > > Summary: GRASS fails to build with make -j3 > >> > However: I'm not sure whether parallel make will actually be useful >> > with the existing Makefiles, due to the use of a shell "for" loop for >> > building subdirectories: >> > >> > subdirs: >> > @list='$(SUBDIRS)'; \ >> > for subdir in $$list; do \ >> > echo $$subdir ; \ >> > $(MAKE) -C $$subdir || echo $(CURDIR)/$$subdir >> >> $(GRASS_HOME)/error.log; \ >> > done >> > >> > [From include/Make/Dir.make] >> > >> > To have the subdirectories built in parallel, you would need to use >> > something like: >> > >> > .PHONY: subdirs $(SUBDIRS) >> > >> > subdirs: $(SUBDIRS) >> > >> > $(SUBDIRS): >> > $(MAKE) -C $@ >> >> I am interested to get this working but failed to get the >> second part in include/Make/Dir.make successfully running. >> >> Any further hints? My Makefile knowledge is fairly limited >> unfortunately. > > Note that this cannot be done for all directories. In particular, the > inter-dependencies between libraries mean that you cannot build the > lib/* directories in an arbitrary order. You would have to either use > the existing "for" loop in lib/Makefile, or explicitly list the > dependencies, e.g.: > > gis: datetime > driver: gis > pngdriver: driver gis > psdriver: driver gis > raster: driver gis pngdriver psdriver > display: gis raster > > Using the na?ve parallel version for the lib directory will result in > severe failure, due to attempting to link other libraries against > libgis before libgis has been generated. > Yes, confirmed. > The top-level directories may as well be built sequentially, but > presumably you would want to parallelise within the raster, vector, > general etc directories. Parallelising lib is less important as most > of the subdirectories contain enough files that parallelising within > individual lib/* subdirectories would probably be sufficient. > > As a first attempt, I'd suggest trying the above idiom in Dir.make, > and using the existing loop in lib/Makefile (name the target somthing > other than "subdirs" to avoid a conflict with Dir.make). Hopefully, > that should keep the number of errors down to manageable proportions > (it's a safe bet that at least some of the individual module/lib > Makefiles rely upon sequential processing). > Will do. Concerning modules: candidates for sequential processing are certainly the r.li suite (r.li.daemon comes first), raster/simwe/lib/, vector/v.lrs/lib/ vector/lidar/lidarlib/ and so forth. For these subdirectories some trick must be implemented to get them sequentially processed (which this could go in parallel with other raster/vector programs). Anyway, slowly we'll arrive. Markus -- View this message in context: http://www.nabble.com/-grass-code-I--359--GRASS-fails-to-build-with-make--j3-tf3530677.html#a11525174 Sent from the Grass - Dev mailing list archive at Nabble.com. From hmitaso at unity.ncsu.edu Tue Jul 10 19:15:13 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Tue Jul 10 19:15:16 2007 Subject: [GRASS-dev] Possible error in r.flow error message In-Reply-To: <4693AA02.5000904@jemila.jazztel.es> References: <4693AA02.5000904@jemila.jazztel.es> Message-ID: <1184087713.15445.1.camel@deliboz> On Tue, 2007-07-10 at 17:47 +0200, Carlos D?vila wrote: > I have tested r.flow looking for messages to standardize. I gave a non > existing input elevation raster map, so I waited "Cannot find file %s" > but error message is "out of memory". Is it the right behaviour? Does it > check memory before looking for the input map? If so, why doesn't it get > memory? are you sure the file that you gave it was indeed non-existing? I tried it and it gave me the right message: GRASS 6.3.cvs > r.flow elevin=junk dsout=dsdtest Reading input files: elevation ERROR: Cannot find file junk Helena > I thank any help. > Carlos > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From cdavilam at jemila.jazztel.es Tue Jul 10 19:45:20 2007 From: cdavilam at jemila.jazztel.es (=?UTF-8?B?Q2FybG9zIETDoXZpbGE=?=) Date: Tue Jul 10 19:42:08 2007 Subject: [GRASS-dev] Possible error in r.flow error message In-Reply-To: <1184087713.15445.1.camel@deliboz> References: <4693AA02.5000904@jemila.jazztel.es> <1184087713.15445.1.camel@deliboz> Message-ID: <4693C5B0.5010006@jemila.jazztel.es> Helena Mitasova escribi?: > On Tue, 2007-07-10 at 17:47 +0200, Carlos D?vila wrote: > >> I have tested r.flow looking for messages to standardize. I gave a non >> existing input elevation raster map, so I waited "Cannot find file %s" >> but error message is "out of memory". Is it the right behaviour? Does it >> check memory before looking for the input map? If so, why doesn't it get >> memory? >> > > are you sure the file that you gave it was indeed non-existing? > > I tried it and it gave me the right message: > > GRASS 6.3.cvs > r.flow elevin=junk dsout=dsdtest > Reading input files: elevation > ERROR: Cannot find file junk > > Helena > Yes, sure. GRASS 6.3.cvs (Extremadura_h29):~ > r.flow elevin=junk dsout=dsdtest ERROR: G_calloc: sin memoria (out of memory) May be I need to make distclean, but I have no time now to recompile. Send result later. From rez at touchofmadness.com Tue Jul 10 20:11:36 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Tue Jul 10 20:11:43 2007 Subject: [GRASS-dev] using slope/aspect functions inside our module In-Reply-To: <1184085161.13812.55.camel@deliboz> References: <200707031329.04522.yann.chemin@gmail.com> <18059.49086.129208.14164@cerise.gclements.plus.com> <200707091247.57104.dylan.beaudette@gmail.com> <18067.44471.335333.381140@cerise.gclements.plus.com> <1184085161.13812.55.camel@deliboz> Message-ID: <1184091096.30110.130.camel@dev64.localdomain> On Tue, 2007-07-10 at 12:32 -0400, Helena Mitasova wrote: > On Tue, 2007-07-10 at 17:03 +0100, Glynn Clements wrote: > > Dylan Beaudette wrote: > > > > > > > Interesting. > > > > > Why r.slope.aspect uses > > > > > > > > > > dx = ... / (4 * ewres); > > > > > > > > > > while r.shaded.relief uses > > > > > > > > > > dx = ... / (8 * ewres); > > > > > > > > > > ?? > > > > > > > > Oops. It should be 8; the ewres/nsres values are actually the > > > > distances between the centres of the top/bottom rows and left/right > > > > columns in the 3x3 window, which are two rows/columns apart. IOW, the > > > > 4*ewres should have been 4*(2*ewres) = 8*ewres, ditto for nsres. > > > > > > Yikes, does this mean that previous calculations are now wrong? > > > > No. I just made a mistake in "paraphrasing" the code. > > > > The actual code for r.slope.aspect has: > > > > V = G_distance(east, north, east, south) * 4 / zfactor; > > H = G_distance(east, ns_med, west, ns_med) * 4 / zfactor; > > ... > > dx = ((*c1 + *c4 + *c4 + *c7) - (*c3 + *c6 + *c6 + *c9)) / H; > > dy = ((*c7 + *c8 + *c8 + *c9) - (*c1 + *c2 + *c2 + *c3)) / V; > > > > I paraphrased the result of G_distance nsres/ewres, but it's actually > > twice that. > > > > The factor of 4 corresponds to the weights of 1+2+1 = 4, while the > > factor of 2 corresponds to the distance in cells. > > > > It might be clearer to write the calculation as: > > > > dx = ((c1/4 + c4/2 + c7/4) - (c3/4 + c6/2 + c9/4)) / (2 * ewres); > > dy = ((c7/4 + c8/2 + c9/4) - (c1/4 + c2/2 + c3/4)) / (2 * nsres); > > > > r.slope.aspect premultiplies the 4 into the divisors to eliminate the > > divisions from the weighting. > > > > I'm not sure of the theoretical basis behind the weights used. A > > simpler approach would be to ignore the corners and use: > > > > dx = (c4 - c6) / (2 * ewres); > > dy = (c8 - c2) / (2 * nsres); > > > > This still produces the correct result for a sampled planar surface > > (it's also the approach used by r.bilinear and r.resamp.interp). > > > > Ultimately, computing the slope of a DEM requires some form of > > interpolation, and the choice of algorithm is largely arbitrary (if > > you don't interpolate, the surface is a grid of horizontal rectangles, > > so the slope is always either zero or infinite). > > just a note for record - the choice of algorithm does make a difference > (I think it was Brad who sent me an excellent paper on it some time > ago),the equation for the polynomial that is used for approximation here > is in the GRAS book appendix and also in the upcoming Geomorphometry > book (it has a chapter about Geomorphometry in GRASS). As long as the > 3x3 neighborhood and a bivariate 2nd order polynomial is enough, this is > a very simple and accurate algorithm (introduced by Horn in 1981 for a > pioneering work for computing illuminated terrain maps). Some simpler > algorithms can produce pretty bad results. Yeah, that was a paper from PE&RS. Recently, there was a new paper with a "new" algorithm, but it wasn't compared to many others. Paper I sent Helena: Q. Zhou, et. al., 2004, Error Analysis on Grid-Based Slope and Aspect Algorithms, PE&RS (Photogrammetric Engineering & Remote Sensing), 70(8):957-962 > But the way how it is written in r.slope.aspect is quite confusing - I > think it is mostly due to the fact that it needs to call G_distance > rather than using plain ewres to get the latlong converted to actual > distance. We already had a discussion on that topic too, I implemented several of the algorithms in r.slope.aspect, but I never committed them to CVS. I didn't think others would be terribly interested because the default one used is acceptable for most everyone and it might confuse users with so many (3-4) options. If there is interest, I'll find some time to commit it. Interpolation algorithms included: 3rd Order Finite Distace 3rd Order Finite Distance Weighted by Reciprocal of Distance 3rd Order Finite Distance Weighted by Reciprocal of Squared Distance The algorithms are similar, but can improve results depending on the situation. The last one is the overall best performer (and I believe the algorithm already used in r.slope.aspect). -- 73, de Brad KB8UYR/6 From dylan.beaudette at gmail.com Tue Jul 10 21:13:41 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Tue Jul 10 21:13:48 2007 Subject: [GRASS-dev] using slope/aspect functions inside our module In-Reply-To: <1184091096.30110.130.camel@dev64.localdomain> References: <200707031329.04522.yann.chemin@gmail.com> <1184085161.13812.55.camel@deliboz> <1184091096.30110.130.camel@dev64.localdomain> Message-ID: <200707101213.41857.dylan.beaudette@gmail.com> On Tuesday 10 July 2007 11:11, Brad Douglas wrote: > On Tue, 2007-07-10 at 12:32 -0400, Helena Mitasova wrote: > > On Tue, 2007-07-10 at 17:03 +0100, Glynn Clements wrote: > > > Dylan Beaudette wrote: > > > > > > Interesting. > > > > > > Why r.slope.aspect uses > > > > > > > > > > > > dx = ... / (4 * ewres); > > > > > > > > > > > > while r.shaded.relief uses > > > > > > > > > > > > dx = ... / (8 * ewres); > > > > > > > > > > > > ?? > > > > > > > > > > Oops. It should be 8; the ewres/nsres values are actually the > > > > > distances between the centres of the top/bottom rows and left/right > > > > > columns in the 3x3 window, which are two rows/columns apart. IOW, > > > > > the 4*ewres should have been 4*(2*ewres) = 8*ewres, ditto for > > > > > nsres. > > > > > > > > Yikes, does this mean that previous calculations are now wrong? > > > > > > No. I just made a mistake in "paraphrasing" the code. > > > > > > The actual code for r.slope.aspect has: > > > > > > V = G_distance(east, north, east, south) * 4 / zfactor; > > > H = G_distance(east, ns_med, west, ns_med) * 4 / zfactor; > > > ... > > > dx = ((*c1 + *c4 + *c4 + *c7) - (*c3 + *c6 + *c6 + *c9)) / H; > > > dy = ((*c7 + *c8 + *c8 + *c9) - (*c1 + *c2 + *c2 + *c3)) / V; > > > > > > I paraphrased the result of G_distance nsres/ewres, but it's actually > > > twice that. > > > > > > The factor of 4 corresponds to the weights of 1+2+1 = 4, while the > > > factor of 2 corresponds to the distance in cells. > > > > > > It might be clearer to write the calculation as: > > > > > > dx = ((c1/4 + c4/2 + c7/4) - (c3/4 + c6/2 + c9/4)) / (2 * ewres); > > > dy = ((c7/4 + c8/2 + c9/4) - (c1/4 + c2/2 + c3/4)) / (2 * nsres); > > > > > > r.slope.aspect premultiplies the 4 into the divisors to eliminate the > > > divisions from the weighting. > > > > > > I'm not sure of the theoretical basis behind the weights used. A > > > simpler approach would be to ignore the corners and use: > > > > > > dx = (c4 - c6) / (2 * ewres); > > > dy = (c8 - c2) / (2 * nsres); > > > > > > This still produces the correct result for a sampled planar surface > > > (it's also the approach used by r.bilinear and r.resamp.interp). > > > > > > Ultimately, computing the slope of a DEM requires some form of > > > interpolation, and the choice of algorithm is largely arbitrary (if > > > you don't interpolate, the surface is a grid of horizontal rectangles, > > > so the slope is always either zero or infinite). > > > > just a note for record - the choice of algorithm does make a difference > > (I think it was Brad who sent me an excellent paper on it some time > > ago),the equation for the polynomial that is used for approximation here > > is in the GRAS book appendix and also in the upcoming Geomorphometry > > book (it has a chapter about Geomorphometry in GRASS). As long as the > > 3x3 neighborhood and a bivariate 2nd order polynomial is enough, this is > > a very simple and accurate algorithm (introduced by Horn in 1981 for a > > pioneering work for computing illuminated terrain maps). Some simpler > > algorithms can produce pretty bad results. > > Yeah, that was a paper from PE&RS. Recently, there was a new paper with > a "new" algorithm, but it wasn't compared to many others. > > Paper I sent Helena: > Q. Zhou, et. al., 2004, Error Analysis on Grid-Based Slope and Aspect > Algorithms, PE&RS (Photogrammetric Engineering & Remote Sensing), > 70(8):957-962 > > > But the way how it is written in r.slope.aspect is quite confusing - I > > think it is mostly due to the fact that it needs to call G_distance > > rather than using plain ewres to get the latlong converted to actual > > distance. We already had a discussion on that topic too, > > I implemented several of the algorithms in r.slope.aspect, but I never > committed them to CVS. I didn't think others would be terribly > interested because the default one used is acceptable for most everyone > and it might confuse users with so many (3-4) options. > > If there is interest, I'll find some time to commit it. > > Interpolation algorithms included: > 3rd Order Finite Distace > 3rd Order Finite Distance Weighted by Reciprocal of Distance > 3rd Order Finite Distance Weighted by Reciprocal of Squared Distance > > The algorithms are similar, but can improve results depending on the > situation. The last one is the overall best performer (and I believe > the algorithm already used in r.slope.aspect). I would be interested in these, and have a rather high-density slope and aspect field-data set which could be used for some comparisons. Dylan From glynn at gclements.plus.com Wed Jul 11 07:12:08 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Jul 11 07:12:48 2007 Subject: [GRASS-dev] Win32 DBMI lockups: change to nonblocking pipes? In-Reply-To: <46939E53.6050206@ufg.uni-kiel.de> References: <20070710103654.7DEBA400D5@pyrosoma.intevation.org> <46939E53.6050206@ufg.uni-kiel.de> Message-ID: <18068.26280.313372.959453@cerise.gclements.plus.com> Benjamin Ducke wrote: > After doing some more testing (QGIS and GRASS on Linux, > GRASS native w/o QGIS from http://qgis.org/uploadfiles/testbuilds/), > I still think that possible pipe blocking is the hottest lead so far. > > There are some comments (maybe written by Radim Blazek?) in start.c > which suggest the same: > > /* I have seen problems with pipes on NT 5.1 probably related > * to buffer size (psize, originaly 512 bytes). > * But I am not sure, some problems were fixed by bigger > * buffer but others remain. > * Simple test which failed on NT 5.1 worked on NT 5.2 > * But there are probably other factors. > > I would like to change the pipes in lib/db/dbmi_client/start.c to > nonblocking I/O. If those hints are right, then this should fix the > problem, I guess. Unlikely. The XDR library uses ANSI stdio (fread/fwrite), which (AFAICT) never return short counts. Even if you make the underlying pipes non-blocking, fread/fwrite are going to block until they have read/written all of the data. -- Glynn Clements From hamish_nospam at yahoo.com Wed Jul 11 09:32:16 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jul 11 09:33:22 2007 Subject: [GRASS-dev] r.in.xyz can now read from stdin Message-ID: <20070711193216.0afa5fba.hamish_nospam@yahoo.com> Hi, I just added redirection from stdin support to r.in.xyz. Everything seems to work, but of course testing is appreciated. This bypasses the bulk of the code which may trigger LFS issues for very large input files (many GB). ie it skips scanning the filesize -- which was only needed for G_percent() anyway. You can't rewind a piped stream so the percent= multi-pass option won't work, and it must keep 100% of the raster map in memory. (limits region size) Hopefully if you are working with massive datasets you already have lots of RAM installed. I used G_clicker()- I'm pretty sure it does not have GUI hooks like G_percent() does for the progress bar, but then you can't feed data from stdin using the GUI so you can't trigger it anyway. (this is the \b\b\b\b\b... GUI window output problem) Q: is realloc() needed here? it works for me but I'm not sure if it'll segfault for someone someday. char *infile; ... infile = input_opt->answer; ... if (strcmp ("-", infile) == 0) { from_stdin = TRUE; ... strcpy(infile, "stdin"); /* filename for history metadata */ ? I found that the new r.colors inverse + equalized color flags make the Jockey's Ridge, NC sample LIDAR dataset look really nice. It brings out the ground features (roads, homes) well without having to manually filter-out the bogus outliers. ============================= Re: [GRASS-user] Re: some interesting tools for working with LAS format Dylan wrote: > > Perhaps we can talk to these people, and integrate a LAS reader into > > GRASS, or better yet figure out how to use it with r.in.xyz! Bernhard Hoefle wrote: > the LAS Tools by M. Isenburg ... > The tool "las2txt" can be used to generate ASCII Files that can be > imported with r.in.xyz or v.in.ascii. Dylan: > As a start we can include references to the LAS tools in the relevant > man pages and wiki, with build and useage examples. This would get > new users up to speed on the 'toolchain' approach to processing data > with GRASS+external tools. now: las2txt | r.in.xyz in=- fs='' enjoy, Hamish From hamish_nospam at yahoo.com Wed Jul 11 10:41:28 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jul 11 10:41:35 2007 Subject: [GRASS-dev] [grass-code I][444] v.in.ogr: false optional 'dsn' and 'output' In-Reply-To: <20070710103654.7DEBA400D5@pyrosoma.intevation.org> References: <20070710103654.7DEBA400D5@pyrosoma.intevation.org> Message-ID: <20070711204128.353c5481.hamish_nospam@yahoo.com> http://wald.intevation.org/tracker/?func=detail&atid=204&aid=444&group_id=21 > code I item #444, was opened at 2007-07-10 12:36 > Submitted By: Maciej Sieczka (msieczka) > Summary: v.in.ogr: false optional 'dsn' and 'output' .. > v.in.ogr advertises the 'dsn' and 'output' as optional in 6.3 CVS: > > GRASS 6.3.cvs (spearfish60):~ > v.in.ogr help 2>&1 | grep Usage -A1 > Usage: > v.in.ogr [-lfcztoew] [dsn=string] [output=name] > > (see the brackets around options dsn and output; their presence is > interpreted as "optional" by the autogenerated tcl/tk GUI) this is so you can use the -l and -f flags without supplying dummy values to dsn= and output=. I don't know what the correct answer is, but that was the logic behind the change, AFAIU. Hamish From cdavilam at jemila.jazztel.es Wed Jul 11 10:47:09 2007 From: cdavilam at jemila.jazztel.es (=?UTF-8?B?Q2FybG9zIETDoXZpbGE=?=) Date: Wed Jul 11 10:43:57 2007 Subject: [GRASS-dev] Possible error in r.flow error message In-Reply-To: <4693C5B0.5010006@jemila.jazztel.es> References: <4693AA02.5000904@jemila.jazztel.es> <1184087713.15445.1.camel@deliboz> <4693C5B0.5010006@jemila.jazztel.es> Message-ID: <4694990D.2010308@jemila.jazztel.es> Carlos D?vila escribi?: > Helena Mitasova escribi?: >> On Tue, 2007-07-10 at 17:47 +0200, Carlos D?vila wrote: >> >>> I have tested r.flow looking for messages to standardize. I gave a >>> non existing input elevation raster map, so I waited "Cannot find >>> file %s" but error message is "out of memory". Is it the right >>> behaviour? Does it check memory before looking for the input map? If >>> so, why doesn't it get memory? >>> >> >> are you sure the file that you gave it was indeed non-existing? >> >> I tried it and it gave me the right message: >> >> GRASS 6.3.cvs > r.flow elevin=junk dsout=dsdtest >> Reading input files: elevation >> ERROR: Cannot find file junk >> >> Helena >> > Yes, sure. > GRASS 6.3.cvs (Extremadura_h29):~ > r.flow elevin=junk dsout=dsdtest > ERROR: G_calloc: sin memoria (out of memory) > May be I need to make distclean, but I have no time now to recompile. > Send result later. Still the same problem after make distclean and cvs update. From hamish_nospam at yahoo.com Wed Jul 11 10:45:23 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jul 11 10:45:30 2007 Subject: [GRASS-dev] Possible error in r.flow error message In-Reply-To: <4693C5B0.5010006@jemila.jazztel.es> References: <4693AA02.5000904@jemila.jazztel.es> <1184087713.15445.1.camel@deliboz> <4693C5B0.5010006@jemila.jazztel.es> Message-ID: <20070711204523.6ab958e5.hamish_nospam@yahoo.com> Carlos: > >> I have tested r.flow looking for messages to standardize. I gave a > >> non existing input elevation raster map, so I waited "Cannot find > >> file %s" but error message is "out of memory". Is it the right > >> behaviour? Does it check memory before looking for the input map? > >> If so, why doesn't it get memory? > > > > are you sure the file that you gave it was indeed non-existing? > > > > I tried it and it gave me the right message: > > > > GRASS 6.3.cvs > r.flow elevin=junk dsout=dsdtest > > Reading input files: elevation > > ERROR: Cannot find file junk > > Yes, sure. > GRASS 6.3.cvs (Extremadura_h29):~ > r.flow elevin=junk dsout=dsdtest > ERROR: G_calloc: sin memoria (out of memory) > May be I need to make distclean, but I have no time now to recompile. > Send result later. I too get: Reading input files: elevation ERROR: Cannot find file junk maybe some hints if run with DEBUG=5 ? Hamish From cdavilam at jemila.jazztel.es Wed Jul 11 11:01:02 2007 From: cdavilam at jemila.jazztel.es (=?ISO-8859-1?Q?Carlos_D=E1vila?=) Date: Wed Jul 11 10:57:48 2007 Subject: [GRASS-dev] Possible error in r.flow error message In-Reply-To: <20070711204523.6ab958e5.hamish_nospam@yahoo.com> References: <4693AA02.5000904@jemila.jazztel.es> <1184087713.15445.1.camel@deliboz> <4693C5B0.5010006@jemila.jazztel.es> <20070711204523.6ab958e5.hamish_nospam@yahoo.com> Message-ID: <46949C4E.1090307@jemila.jazztel.es> Hamish escribi?: > Carlos: > >>>> I have tested r.flow looking for messages to standardize. I gave a >>>> non existing input elevation raster map, so I waited "Cannot find >>>> file %s" but error message is "out of memory". Is it the right >>>> behaviour? Does it check memory before looking for the input map? >>>> If so, why doesn't it get memory? >>>> >>> are you sure the file that you gave it was indeed non-existing? >>> >>> I tried it and it gave me the right message: >>> >>> GRASS 6.3.cvs > r.flow elevin=junk dsout=dsdtest >>> Reading input files: elevation >>> ERROR: Cannot find file junk >>> >> >> Yes, sure. >> GRASS 6.3.cvs (Extremadura_h29):~ > r.flow elevin=junk dsout=dsdtest >> ERROR: G_calloc: sin memoria (out of memory) >> May be I need to make distclean, but I have no time now to recompile. >> Send result later. >> > > > I too get: > Reading input files: elevation > ERROR: Cannot find file junk > > > maybe some hints if run with DEBUG=5 ? > Just the same result: GRASS 6.3.cvs (Extremadura_h29):~ > DEBUG=5 GRASS 6.3.cvs (Extremadura_h29):~ > r.flow elevin=junk dsout=dsdtest ERROR: G_calloc: sin memoria From neteler at itc.it Wed Jul 11 16:03:44 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Jul 11 16:03:46 2007 Subject: [GRASS-dev] configuration X fails with strict gcc flags Message-ID: <20070711140344.GB15382@bartok.itc.it> Hi, I have a new laptop with Mandriva 2007.1 (so x.org). X is not recognised although all header files are apparently there. I debugged a bit and found the following (conftest.c and confdefs.h manually extracted from configure): cat conftest.c #line 4672 "configure" #include "confdefs.h" #include int main() { XtMalloc() ; return 0; } cat confdefs.h #define PEEK_XCLOSEIM 1 #define HAVE_LIMITS_H 1 #define HAVE_TERMIO_H 1 #define HAVE_TERMIOS_H 1 #define HAVE_UNISTD_H 1 #define HAVE_VALUES_H 1 #define HAVE_SYS_IOCTL_H 1 #define HAVE_SYS_MTIO_H 1 #define HAVE_SYS_RESOURCE_H 1 #define HAVE_SYS_TIME_H 1 #define HAVE_SYS_TIMEB_H 1 #define HAVE_SYS_TYPES_H 1 #define HAVE_SYS_UTSNAME_H 1 #define HAVE_LIBINTL_H 1 #define HAVE_ICONV_H 1 #define HAVE_LANGINFO_H 1 #define TIME_WITH_SYS_TIME 1 #define RETSIGTYPE void #define HAVE_FTIME 1 #define HAVE_GETHOSTNAME 1 #define HAVE_GETTIMEOFDAY 1 #define HAVE_LSEEK 1 #define HAVE_NICE 1 #define HAVE_TIME 1 #define HAVE_UNAME 1 #define HAVE_SETEUID 1 #define HAVE_SETPRIORITY 1 #define HAVE_SETREUID 1 #define HAVE_DRAND48 1 #define HAVE_PUTENV 1 #define HAVE_SETENV 1 #define HAVE_NANOSLEEP 1 #define SETPGRP_VOID 1 gcc -o conftest -g -Wall -Werror-implicit-function-declaration -fno-common -mtune=nocona -m64 -minline-all-stringops -Wl,--export-dynamic -L/usr/lib64 conftest.c -lXt configure: In function 'main': configure:4676: error: too few arguments to function 'XtMalloc' I think that -Werror-implicit-function-declaration is the problem here, taking it out helps. But: For years I am using -Wall -Werror-implicit-function-declaration -fno-common as flags for gcc to catch potential errors. How to work around? Do we need to modify the XtMalloc() test? grep XtMalloc /usr/include/X11/Intrinsic.h extern char *XtMalloc( extern char *_XtMalloc( /* implementation-private */ #define XtMalloc(size) _XtMalloc(size, __FILE__, __LINE__) #define XtNew(type) ((type *) XtMalloc((unsigned) sizeof(type))) ((str) != NULL ? (strcpy(XtMalloc((unsigned)strlen(str) + 1), str)) : NULL) thanks Markus From neteler at itc.it Wed Jul 11 16:19:05 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Jul 11 16:19:08 2007 Subject: [GRASS-dev] time to release 6.2.2 In-Reply-To: <1183980079.30110.54.camel@dev64.localdomain> References: <20070701190509.GA28159@bartok.itc.it> <468D19AE.6050302@jemila.jazztel.es> <11455121.post@talk.nabble.com> <20070709214407.7d58fcb4.hamish_nospam@yahoo.com> <1183980079.30110.54.camel@dev64.localdomain> Message-ID: <11541249.post@talk.nabble.com> Brad Douglas wrote: > > On Mon, 2007-07-09 at 21:44 +1200, Hamish wrote: >> proposal: tag 6.2.2rc2 circa now, and if no more major changes are >> applied >> release it mostly unchanged as 6.2.2 final in the next 2 weeks. >> aka >> any more outstanding issues that are reasonably expected to be fixed? > > Tag, but please do NOT release 6.2.2 until I get a reply on the > directory permission/security issue I sent to the list over the weekend. > > This is a show-stopper until explained or fixed, IMHO. I'm sure you'll > all agree when user X does 'rm -rf *' on your working dir. ;-) > Brad, is this still an issue? done: - translation backport - .in.gns bugfix open: - v.db.addtable bugfix needs a test - ? Markus -- View this message in context: http://www.nabble.com/time-to-release-6.2.2-tf4008762.html#a11541249 Sent from the Grass - Dev mailing list archive at Nabble.com. From michael.barton at asu.edu Wed Jul 11 17:16:19 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Jul 11 17:16:29 2007 Subject: [GRASS-dev] Re: [GRASS-user] thanks to GRASS! In-Reply-To: <339717.35268.qm@web53705.mail.re2.yahoo.com> Message-ID: I wonder if we should start a GRASS "library" on the main site or the WIKI where users could post PDF's or links to papers on using GRASS? Michael On 7/11/07 1:03 AM, "Jaime Carrera" wrote: > Dear list, > > I would just like to thank the GRASS development team for creating such a nice > piece of software, as without it I couldn't have done my PhD work. One of my > ideas was to show that Open Source software can be used to develop a large > project (as some people think that free stuff is not good) and the use of > GRASS, R, GMT, The GIMP and Inkscape was crucial to prove my point. > > If someone is interested in some of this work, please follow these links; if > someone can't access these links, please let me know and I can send a PDF copy > of them. > > On the use of GRASS with R and GSTAT to interpolate daily climatological > variables (rainfall, and both minimum and maximum temperature) using different > Kriging methods: > > Carrera-Hernandez, J. J. and Gaskin, S.J. (2007). Spatio temporal analysis of > daily precipitation and temperature in the Basin of Mexico. Journal of > Hydrology. DOI: http://dx.doi.org/10.1016/j.jhydrol.2006.12.021 > > On the use of GRASS in groundwater modeling (Now I have time to update it for > GRASS 6.2 and MODFLOW 2005 !) > > Carrera-Hernandez, J. J. and Gaskin, S. J. (2006). The Groundwater Modelling > Tool for GRASS (GMTG). Open Source groundwater flow modelling. Computers & > Geosciences 32(3):339-351. DOI: http://dx.doi.org/10.1016/j.cageo.2005.06.018 > > There is another paper (in press, Hydrogeology Journal) on which I used GRASS, > R and GMT to analyze the evolution of the groundwater level in the Basin of > Mexico. The DOI It should be available within the next week. > > Cheers, > > Jaime > > > __________________________________________________ > Correo Yahoo! > Espacio para todos tus mensajes, antivirus y antispam ?gratis! > Reg?strate ya - http://correo.espanol.yahoo.com/ __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070711/3c9924f5/attachment-0001.html From carlos.grohmann at gmail.com Wed Jul 11 17:27:04 2007 From: carlos.grohmann at gmail.com (=?ISO-8859-1?Q?Carlos_"Gu=E2no"_Grohmann?=) Date: Wed Jul 11 17:27:07 2007 Subject: [GRASS-dev] Re: [GRASS-user] thanks to GRASS! In-Reply-To: References: <339717.35268.qm@web53705.mail.re2.yahoo.com> Message-ID: This could be a nice addition to the BibTeX list on the Wiki Carlos On 7/11/07, Michael Barton wrote: > > I wonder if we should start a GRASS "library" on the main site or the WIKI > where users could post PDF's or links to papers on using GRASS? > > Michael > > > > On 7/11/07 1:03 AM, "Jaime Carrera" wrote: > > > Dear list, > > I would just like to thank the GRASS development team for creating such a > nice piece of software, as without it I couldn't have done my PhD work. One > of my ideas was to show that Open Source software can be used to develop a > large project (as some people think that free stuff is not good) and the use > of GRASS, R, GMT, The GIMP and Inkscape was crucial to prove my point. > > If someone is interested in some of this work, please follow these links; > if someone can't access these links, please let me know and I can send a PDF > copy of them. > > On the use of GRASS with R and GSTAT to interpolate daily climatological > variables (rainfall, and both minimum and maximum temperature) using > different Kriging methods: > > Carrera-Hernandez, J. J. and Gaskin, S.J. (2007). Spatio temporal analysis > of daily precipitation and temperature in the Basin of Mexico. Journal of > Hydrology. DOI: > http://dx.doi.org/10.1016/j.jhydrol.2006.12.021 > > On the use of GRASS in groundwater modeling (Now I have time to update it > for GRASS 6.2 and MODFLOW 2005 !) > > Carrera-Hernandez, J. J. and Gaskin, S. J. (2006). The Groundwater > Modelling Tool for GRASS (GMTG). Open Source groundwater flow modelling. > Computers & Geosciences 32(3):339-351. DOI: > http://dx.doi.org/10.1016/j.cageo.2005.06.018 > > There is another paper (in press, Hydrogeology Journal) on which I used > GRASS, R and GMT to analyze the evolution of the groundwater level in the > Basin of Mexico. The DOI It should be available within the next week. > > Cheers, > > Jaime > > > __________________________________________________ > Correo Yahoo! > Espacio para todos tus mensajes, antivirus y antispam ?gratis! > Reg?strate ya - http://correo.espanol.yahoo.com/ > > > __________________________________________ > Michael Barton, Professor of Anthropology > Director of Graduate Studies > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- +-----------------------------------------------------------+ Carlos Henrique Grohmann - Guano Visiting Researcher at Kingston University London - UK Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - carlos dot grohmann at gmail dot com +-----------------------------------------------------------+ _________________ "Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive." --The winning entry in a "What were HAL's first words" contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke From glynn at gclements.plus.com Wed Jul 11 19:54:40 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Jul 11 19:54:44 2007 Subject: [GRASS-dev] Re: [GRASS-user] r.in.xyz can now read from stdin In-Reply-To: <20070711193216.0afa5fba.hamish_nospam@yahoo.com> References: <20070711193216.0afa5fba.hamish_nospam@yahoo.com> Message-ID: <18069.6496.282887.985971@cerise.gclements.plus.com> Hamish wrote: > I just added redirection from stdin support to r.in.xyz. Everything seems to > work, but of course testing is appreciated. > > This bypasses the bulk of the code which may trigger LFS issues for > very large input files (many GB). ie it skips scanning the filesize -- > which was only needed for G_percent() anyway. Reading from stdin and the progress indication should be orthogonal. I would have thought that the easiest solution would be to attempt to determine the file size with fseek/ftell, and disable progress if that fails, e.g. because the input is a pipe or is too large for a "long" (fseek/ftell use long, not off_t). > You can't rewind a piped stream so the percent= multi-pass option won't > work, If you redirect stdin from a file, stdin will be a file, not a pipe. There is no inherent reason why stdin cannot be rewound. Conversely, someone could use input=/dev/tape, which cannot be rewound (in the sense of rewind() or fseek()). If you want to determine whether it's possible to seek on a stream, either try seeking on it, or use fstat(), e.g.: struct stat st; if (fstat(filename, &st) != 0) /* error */ if (S_ISREG(st.st_mode)) /* it's a regular file */ > and it must keep 100% of the raster map in memory. (limits region > size) Hopefully if you are working with massive datasets you already > have lots of RAM installed. > > I used G_clicker()- I'm pretty sure it does not have GUI hooks like > G_percent() does for the progress bar, but then you can't feed data from > stdin using the GUI so you can't trigger it anyway. (this is the > \b\b\b\b\b... GUI window output problem) > > > Q: is realloc() needed here? it works for me but I'm not sure if it'll > segfault for someone someday. > > char *infile; > ... > infile = input_opt->answer; > ... > if (strcmp ("-", infile) == 0) { > from_stdin = TRUE; > ... > strcpy(infile, "stdin"); /* filename for history metadata */ Yes. There's no guarantee that infile will be large enough. I suggest: infile = G_store("stdin"); ISTR that the malloc() in GNU libc always effectively rounds up allocations to multiples of 8 bytes (blocks are always aligned to 8-byte multiples, so nothing else will be stored in the 8 bytes following the start of the block), so you'll get away with it on Linux, but it's conceivable that other platforms might use 4 bytes (the x86 architecture itself doesn't have *any* alignment constraints). -- Glynn Clements From glynn at gclements.plus.com Wed Jul 11 20:32:39 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Jul 11 20:32:46 2007 Subject: [GRASS-dev] configuration X fails with strict gcc flags In-Reply-To: <20070711140344.GB15382@bartok.itc.it> References: <20070711140344.GB15382@bartok.itc.it> Message-ID: <18069.8775.354608.241932@cerise.gclements.plus.com> Markus Neteler wrote: > I have a new laptop with Mandriva 2007.1 (so x.org). X is not > recognised although all header files are apparently there. > I debugged a bit and found the following (conftest.c and confdefs.h > manually extracted from configure): > > cat conftest.c > #line 4672 "configure" > #include "confdefs.h" > #include > > int main() { > XtMalloc() > ; return 0; } > gcc -o conftest -g -Wall -Werror-implicit-function-declaration -fno-common -mtune=nocona -m64 -minline-all-stringops -Wl,--export-dynamic -L/usr/lib64 conftest.c -lXt > configure: In function 'main': > configure:4676: error: too few arguments to function 'XtMalloc' Odd; my config.log has: configure:4675: warning: implicit declaration of function `XtMalloc' which implies that it isn't picking up the header. In fact, the relevant portion of the configure script is: cat > conftest.$ac_ext < From maris.gis at gmail.com Wed Jul 11 22:12:11 2007 From: maris.gis at gmail.com (Maris Nartiss) Date: Wed Jul 11 22:12:14 2007 Subject: [GRASS-dev] Re: [GRASS-user] thanks to GRASS! In-Reply-To: References: <339717.35268.qm@web53705.mail.re2.yahoo.com> Message-ID: <2b3d8c1c0707111312l32aeb94alacb644e0c6e8470b@mail.gmail.com> I think there could be some legal issues. I.e. from COMPUTERS & GEOSCIENCES Guide for Authors [1] "e) if accepted, will not be published elsewhere in the same form, in English or in any other language, without the written consent of the Publisher." IANAL but putting article PDF on wiki may be threated as "publishing"? Maris. [1] http://www.elsevier.com/wps/find/journaldescription.cws_home/398/authorinstructions 2007/7/11, Michael Barton : > I wonder if we should start a GRASS "library" on the main site or the WIKI > where users could post PDF's or links to papers on using GRASS? > > Michael > > > On 7/11/07 1:03 AM, "Jaime Carrera" wrote: > > > Dear list, > > > > I would just like to thank the GRASS development team for creating such a > nice > > piece of software, as without it I couldn't have done my PhD work. One of > my > > ideas was to show that Open Source software can be used to develop a large > > project (as some people think that free stuff is not good) and the use of > > GRASS, R, GMT, The GIMP and Inkscape was crucial to prove my point. > > > > If someone is interested in some of this work, please follow these links; > if > > someone can't access these links, please let me know and I can send a PDF > copy > > of them. > > > > On the use of GRASS with R and GSTAT to interpolate daily climatological > > variables (rainfall, and both minimum and maximum temperature) using > different > > Kriging methods: > > > > Carrera-Hernandez, J. J. and Gaskin, S.J. (2007). Spatio temporal analysis > of > > daily precipitation and temperature in the Basin of Mexico. Journal of > > Hydrology. DOI: http://dx.doi.org/10.1016/j.jhydrol.2006.12.021 > > > > On the use of GRASS in groundwater modeling (Now I have time to update it > for > > GRASS 6.2 and MODFLOW 2005 !) > > > > Carrera-Hernandez, J. J. and Gaskin, S. J. (2006). The Groundwater > Modelling > > Tool for GRASS (GMTG). Open Source groundwater flow modelling. Computers & > > Geosciences 32(3):339-351. DOI: > http://dx.doi.org/10.1016/j.cageo.2005.06.018 > > > > There is another paper (in press, Hydrogeology Journal) on which I used > GRASS, > > R and GMT to analyze the evolution of the groundwater level in the Basin > of > > Mexico. The DOI It should be available within the next week. > > > > Cheers, > > > > Jaime > > > > > > __________________________________________________ > > Correo Yahoo! > > Espacio para todos tus mensajes, antivirus y antispam ?gratis! > > Reg?strate ya - http://correo.espanol.yahoo.com/ > > > __________________________________________ > Michael Barton, Professor of Anthropology > Director of Graduate Studies > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > From carlos.grohmann at gmail.com Wed Jul 11 22:37:34 2007 From: carlos.grohmann at gmail.com (=?ISO-8859-1?Q?Carlos_"Gu=E2no"_Grohmann?=) Date: Wed Jul 11 22:37:37 2007 Subject: [GRASS-dev] Re: [GRASS-user] thanks to GRASS! In-Reply-To: <2b3d8c1c0707111312l32aeb94alacb644e0c6e8470b@mail.gmail.com> References: <339717.35268.qm@web53705.mail.re2.yahoo.com> <2b3d8c1c0707111312l32aeb94alacb644e0c6e8470b@mail.gmail.com> Message-ID: I vaguely remember of somewhere in Elsevier's site where it said that authors even could put the pdfs on personal home-pages, but that the prefence was for Elsevier to distribute it.. So, yes, it is not legal to put the pdfs on the wiki. BUT it's OK to put the pdfs of the _uncorrected proofs_ (not sure about the corrected proofs). So I guess we can set up a page in the wiki with a list of references, BibTeX entries, pdfs of uncorrected proofs, and a link (DOI) to the journal. Carlos On 7/11/07, Maris Nartiss wrote: > I think there could be some legal issues. > > I.e. from COMPUTERS & GEOSCIENCES Guide for Authors [1] "e) if > accepted, will not be published elsewhere in the same form, in English > or in any > other language, without the written consent of the Publisher." > IANAL but putting article PDF on wiki may be threated as "publishing"? > > Maris. > > [1] http://www.elsevier.com/wps/find/journaldescription.cws_home/398/authorinstructions > > 2007/7/11, Michael Barton : > > I wonder if we should start a GRASS "library" on the main site or the WIKI > > where users could post PDF's or links to papers on using GRASS? > > > > Michael > > > > > > On 7/11/07 1:03 AM, "Jaime Carrera" wrote: > > > > > Dear list, > > > > > > I would just like to thank the GRASS development team for creating such a > > nice > > > piece of software, as without it I couldn't have done my PhD work. One of > > my > > > ideas was to show that Open Source software can be used to develop a large > > > project (as some people think that free stuff is not good) and the use of > > > GRASS, R, GMT, The GIMP and Inkscape was crucial to prove my point. > > > > > > If someone is interested in some of this work, please follow these links; > > if > > > someone can't access these links, please let me know and I can send a PDF > > copy > > > of them. > > > > > > On the use of GRASS with R and GSTAT to interpolate daily climatological > > > variables (rainfall, and both minimum and maximum temperature) using > > different > > > Kriging methods: > > > > > > Carrera-Hernandez, J. J. and Gaskin, S.J. (2007). Spatio temporal analysis > > of > > > daily precipitation and temperature in the Basin of Mexico. Journal of > > > Hydrology. DOI: http://dx.doi.org/10.1016/j.jhydrol.2006.12.021 > > > > > > On the use of GRASS in groundwater modeling (Now I have time to update it > > for > > > GRASS 6.2 and MODFLOW 2005 !) > > > > > > Carrera-Hernandez, J. J. and Gaskin, S. J. (2006). The Groundwater > > Modelling > > > Tool for GRASS (GMTG). Open Source groundwater flow modelling. Computers & > > > Geosciences 32(3):339-351. DOI: > > http://dx.doi.org/10.1016/j.cageo.2005.06.018 > > > > > > There is another paper (in press, Hydrogeology Journal) on which I used > > GRASS, > > > R and GMT to analyze the evolution of the groundwater level in the Basin > > of > > > Mexico. The DOI It should be available within the next week. > > > > > > Cheers, > > > > > > Jaime > > > > > > > > > __________________________________________________ > > > Correo Yahoo! > > > Espacio para todos tus mensajes, antivirus y antispam ?gratis! > > > Reg?strate ya - http://correo.espanol.yahoo.com/ > > > > > > __________________________________________ > > Michael Barton, Professor of Anthropology > > Director of Graduate Studies > > School of Human Evolution & Social Change > > Center for Social Dynamics & Complexity > > Arizona State University > > > > phone: 480-965-6213 > > fax: 480-965-7671 > > www: http://www.public.asu.edu/~cmbarton > > > > > > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- +-----------------------------------------------------------+ Carlos Henrique Grohmann - Guano Visiting Researcher at Kingston University London - UK Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - carlos dot grohmann at gmail dot com +-----------------------------------------------------------+ _________________ "Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive." --The winning entry in a "What were HAL's first words" contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke From rez at touchofmadness.com Thu Jul 12 00:25:59 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Thu Jul 12 00:26:14 2007 Subject: [GRASS-dev] Re: [GRASS-user] thanks to GRASS! In-Reply-To: References: Message-ID: <1184192759.28744.31.camel@dev64.localdomain> On Wed, 2007-07-11 at 08:16 -0700, Michael Barton wrote: > I wonder if we should start a GRASS "library" on the main site or the > WIKI where users could post PDF's or links to papers on using GRASS? That's a great idea, but I wonder how practical it is. I don't know how journals work in other countries, but in the US, many prominent journals strongly discourage such behavior (pre-publication). After publication, the journal typically owns copyright to the article, not the author. This does not apply to US government employees, who's papers are required to be put in the public domain. -- 73, de Brad KB8UYR/6 From dfinlayson at usgs.gov Thu Jul 12 01:18:57 2007 From: dfinlayson at usgs.gov (David Finlayson) Date: Thu Jul 12 01:19:00 2007 Subject: [GRASS-dev] How to specify custom include directories Message-ID: First time compiling GRASS on SuSE. I do not have su privileges on this machine and so I am forced to build my entire tool chain in my home directory ($HOME)=/we/davidf). So far fftw-3.1.2, gdal-1.4.2 and proj-4.5.0 have all compiled using the following: ./configure --prefix=$HOME make make install Which has built a directory tree in $HOME like this: $HOME/bin $HOME/include $HOME/lib $HOME/man $HOME/share Now, trying the same with grass results in a configure error: albacore src/grass-6.2.cvs_src_snapshot_2007_07_07> ./configure --prefix=$HOME --enable-64bit --with-libs=/usr/lib64 checking host system type... x86_64-unknown-linux-gnu checking for gcc... gcc checking whether the C compiler (gcc ) works... yes ... etc ... checking for deflate in -lz... yes checking for location of External PROJ.4 includes... checking for proj_api.h... no configure: error: *** Unable to locate External PROJ.4 includes. However, proj_api.h is in $HOME/include I have tried adding --includedir=$HOME/include to the above but that didn't change anything. I'm sure it's something simple. How do I tell configure where my local includes are (and why didn't --prefix=$HOME work?) Thanks, -- David Finlayson, Ph.D. Operational Geologist U.S. Geological Survey Pacific Science Center 400 Natural Bridges Drive Santa Cruz, CA 95060, USA Tel: 831-427-4757, Fax: 831-427-4748, E-mail: dfinlayson@usgs.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070711/26199214/attachment-0001.html From hmitaso at unity.ncsu.edu Thu Jul 12 01:37:16 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Thu Jul 12 01:37:22 2007 Subject: [GRASS-dev] How to specify custom include directories In-Reply-To: References: Message-ID: David, this is the configure I use to compile GRASS with everything (gdal, proj and grass, all CVS versions) in my home directory: CFLAGS="-g -Wall" ./configure \ --prefix=/local/home/helena/grassdev \ --with-cxx \ --enable-64bit --with-libs=/usr/lib64 --enable-largefile --enable- shared \ --with-bindir=/local/home/helena/grassdev \ --with-gdal=/local/home/helena/gsgdal/bin/gdal-config \ --with-gdal-includes=/local/home/helena/gsgdal/include \ --with-gdal-libs=/local/home/helena/gsgdal/lib \ --with-proj=yes \ --with-proj-includes=/local/home/helena/gproj/include \ --with-proj-libs=/local/home/helena/gproj/lib \ --with-proj-share=/local/home/helena/gproj/share/proj \ --with-motif \ --with-python I also had to add the path here (advice from Markus): system-wide add it to (if you can use sudo ) /etc/ld.so.conf Then run ldconfig solution just for your login: modify $HOME/.bashrc or $HOME/.cshrc depending on your shell and define it there. The GRASS path is added automatically, so just add /home/helena/gdal/lib there (or in /etc/ld.so.conf). I have been compiling and running the GRASS CVS version from home directory for years so hopefully it will work for you too, Helena Helena Mitasova Dept. of Marine, Earth and Atm. Sciences 1125 Jordan Hall, NCSU Box 8208, Raleigh NC 27695 http://skagit.meas.ncsu.edu/~helena/ On Jul 11, 2007, at 7:18 PM, David Finlayson wrote: > First time compiling GRASS on SuSE. I do not have su privileges on > this machine and so I am forced to build my entire tool chain in my > home directory ($HOME)=/we/davidf). > > So far fftw-3.1.2, gdal-1.4.2 and proj-4.5.0 have all compiled > using the following: > > ./configure --prefix=$HOME > make > make install > > Which has built a directory tree in $HOME like this: > > $HOME/bin > $HOME/include > $HOME/lib > $HOME/man > $HOME/share > > Now, trying the same with grass results in a configure error: > > albacore src/grass-6.2.cvs_src_snapshot_2007_07_07> ./configure -- > prefix=$HOME --enable-64bit --with-libs=/usr/lib64 > checking host system type... x86_64-unknown-linux-gnu > checking for gcc... gcc > checking whether the C compiler (gcc ) works... yes > ... etc ... > checking for deflate in -lz... yes > checking for location of External PROJ.4 includes... > checking for proj_api.h... no > configure: error: *** Unable to locate External PROJ.4 includes. > > However, proj_api.h is in $HOME/include > > I have tried adding --includedir=$HOME/include to the above but > that didn't change anything. I'm sure it's something simple. How > do I tell configure where my local includes are (and why didn't -- > prefix=$HOME work?) > > Thanks, > > > > -- > David Finlayson, Ph.D. > Operational Geologist > > U.S. Geological Survey > Pacific Science Center > 400 Natural Bridges Drive > Santa Cruz, CA 95060, USA > > Tel: 831-427-4757, Fax: 831-427-4748, E-mail: dfinlayson@usgs.gov > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From paul-grass at stjohnspoint.co.uk Thu Jul 12 01:49:52 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Thu Jul 12 01:50:01 2007 Subject: [GRASS-dev] How to specify custom include directories In-Reply-To: References: Message-ID: On Wed, 11 Jul 2007, David Finlayson wrote: > First time compiling GRASS on SuSE. I do not have su privileges on this > machine and so I am forced to build my entire tool chain in my home > directory ($HOME)=/we/davidf). > > So far fftw-3.1.2, gdal-1.4.2 and proj-4.5.0 have all compiled using the > following: > > ./configure --prefix=$HOME > make > make install > > Which has built a directory tree in $HOME like this: > > $HOME/bin > $HOME/include > $HOME/lib > $HOME/man > $HOME/share > > Now, trying the same with grass results in a configure error: > > albacore src/grass-6.2.cvs_src_snapshot_2007_07_07> ./configure > --prefix=$HOME --enable-64bit --with-libs=/usr/lib64 > checking host system type... x86_64-unknown-linux-gnu > checking for gcc... gcc > checking whether the C compiler (gcc ) works... yes > ... etc ... > checking for deflate in -lz... yes > checking for location of External PROJ.4 includes... > checking for proj_api.h... no > configure: error: *** Unable to locate External PROJ.4 includes. > > However, proj_api.h is in $HOME/include > > I have tried adding --includedir=$HOME/include to the above but that didn't > change anything. I'm sure it's something simple. How do I tell configure > where my local includes are (and why didn't --prefix=$HOME work?) See ./configure --help Summary: --with-includes=$HOME/include or if it was just PROJ there then you could use --with-proj-includes=$HOME/include --prefix is where GRASS will be installed when you type "make install" - consistent with your use of it to indicate where you wanted the supporting libraries installed. As Helena says you also need to specify where the libraries are too using --with-libs or --with-proj-libs. That's only for compiling though; if you also want to *run* GRASS without installing the libraries into a system library location you will need to add $HOME/lib to the LD_LIBRARY_PATH environment variable (DYLD_LIBRARY_PATH on OS X) or (on Linux, if you have root access) adding it to /etc/ld.so.conf and running ldconfig after you compile the new libraries. Paul From rez at touchofmadness.com Thu Jul 12 02:06:59 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Thu Jul 12 02:07:04 2007 Subject: [GRASS-dev] Directory security/permission issue In-Reply-To: <18067.45926.245689.116789@cerise.gclements.plus.com> References: <1183874859.30110.35.camel@dev64.localdomain> <18066.42956.899670.929947@cerise.gclements.plus.com> <1184027830.30110.97.camel@dev64.localdomain> <18067.45926.245689.116789@cerise.gclements.plus.com> Message-ID: <1184198819.28744.58.camel@dev64.localdomain> On Tue, 2007-07-10 at 17:27 +0100, Glynn Clements wrote: > Brad Douglas wrote: > > > > > While looking over my working dirs, today, I noticed that all of my > > > > recent locations were created with 0777 permissions, instead of the > > > > traditional 0755 mask. Temp directories are still created properly. > > > > > > > > 0777 is bad form and a potential security problem. > > > > > > > > Is there a reason for the change I missed? A quick search through the > > > > archives didn't turn up anything. > > > > > > > > It seems to have come as an accidental result of the MINGW changes. The > > > > offending code can be found in lib/gis/paths.c in G_mkdir(). > > > > > > > > This should be explained or corrected before 6.2.2 is released. > > > > > > The mode passed to mkdir is modified by the process' umask to obtain > > > the actual mode of the directory. If you're ending up with > > > world-writable directories, that implies that your umask is zero, > > > which is insecure. > > > > > > Your umask should normally be at least 0022, (or 0022 if you want > > > files to be group-writable, which is sometimes useful); if you're > > > paranoid, use 0077 (i.e. no permissions for anyone but yourself). > > > > umask...figures. Your lack of cerebral bitrot astounds me. I had > > completely forgotten about it and I, apparently, was too arrogant to > > look at a manpage. ;-) > > > > Don't know how, but my umask was set to 0002. > > Odd; 0002 should give mode 775 for directories. I know. I figured that at one point, the umask must have been 0, but after some further testing, all new directory permissions are 0777 REGARDLESS of manual change to umask. This leads me to believe it is getting set somewhere in GRASS. Maybe lib/init/set_data.c? This does not happen when a new location is created when already in the GRASS shell (r.in.gdal). I also noticed that Fedora has recently changed /etc/bashrc to set the umask to 0002 for normal users. -- 73, de Brad KB8UYR/6 From dfinlayson at usgs.gov Thu Jul 12 02:19:53 2007 From: dfinlayson at usgs.gov (David Finlayson) Date: Thu Jul 12 02:19:55 2007 Subject: [GRASS-dev] How to specify custom include directories In-Reply-To: References: Message-ID: I'm an idiot. As soon as I saw your configure line I remembered about the long list of configure options. In fact, there is a nifty script on the Wiki that carefully documents everything you need to compile grass on Ubuntu. That script happens to have been written by an idot...me. Thanks, David On 7/11/07, Helena Mitasova wrote: > > David, > > this is the configure I use to compile GRASS with everything (gdal, > proj and grass, all CVS versions) > in my home directory: > > CFLAGS="-g -Wall" ./configure \ > --prefix=/local/home/helena/grassdev \ > --with-cxx \ > --enable-64bit --with-libs=/usr/lib64 --enable-largefile --enable- > shared \ > --with-bindir=/local/home/helena/grassdev \ > --with-gdal=/local/home/helena/gsgdal/bin/gdal-config \ > --with-gdal-includes=/local/home/helena/gsgdal/include \ > --with-gdal-libs=/local/home/helena/gsgdal/lib \ > --with-proj=yes \ > --with-proj-includes=/local/home/helena/gproj/include \ > --with-proj-libs=/local/home/helena/gproj/lib \ > --with-proj-share=/local/home/helena/gproj/share/proj \ > --with-motif \ > --with-python > > I also had to add the path here (advice from Markus): > > system-wide add it to (if you can use sudo ) > /etc/ld.so.conf > Then run > ldconfig > > solution just for your login: > modify $HOME/.bashrc or $HOME/.cshrc depending on your shell > and define it there. The GRASS path is added automatically, > so just add /home/helena/gdal/lib there (or in /etc/ld.so.conf). > > I have been compiling and running the GRASS CVS version from home > directory for years so hopefully it will work for you too, > > Helena > > Helena Mitasova > Dept. of Marine, Earth and Atm. Sciences > 1125 Jordan Hall, NCSU Box 8208, > Raleigh NC 27695 > http://skagit.meas.ncsu.edu/~helena/ > > > > On Jul 11, 2007, at 7:18 PM, David Finlayson wrote: > > > First time compiling GRASS on SuSE. I do not have su privileges on > > this machine and so I am forced to build my entire tool chain in my > > home directory ($HOME)=/we/davidf). > > > > So far fftw-3.1.2, gdal-1.4.2 and proj-4.5.0 have all compiled > > using the following: > > > > ./configure --prefix=$HOME > > make > > make install > > > > Which has built a directory tree in $HOME like this: > > > > $HOME/bin > > $HOME/include > > $HOME/lib > > $HOME/man > > $HOME/share > > > > Now, trying the same with grass results in a configure error: > > > > albacore src/grass-6.2.cvs_src_snapshot_2007_07_07> ./configure -- > > prefix=$HOME --enable-64bit --with-libs=/usr/lib64 > > checking host system type... x86_64-unknown-linux-gnu > > checking for gcc... gcc > > checking whether the C compiler (gcc ) works... yes > > ... etc ... > > checking for deflate in -lz... yes > > checking for location of External PROJ.4 includes... > > checking for proj_api.h... no > > configure: error: *** Unable to locate External PROJ.4 includes. > > > > However, proj_api.h is in $HOME/include > > > > I have tried adding --includedir=$HOME/include to the above but > > that didn't change anything. I'm sure it's something simple. How > > do I tell configure where my local includes are (and why didn't -- > > prefix=$HOME work?) > > > > Thanks, > > > > > > > > -- > > David Finlayson, Ph.D. > > Operational Geologist > > > > U.S. Geological Survey > > Pacific Science Center > > 400 Natural Bridges Drive > > Santa Cruz, CA 95060, USA > > > > Tel: 831-427-4757, Fax: 831-427-4748, E-mail: dfinlayson@usgs.gov > > _______________________________________________ > > 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 > -- David Finlayson, Ph.D. Operational Geologist U.S. Geological Survey Pacific Science Center 400 Natural Bridges Drive Santa Cruz, CA 95060, USA Tel: 831-427-4757, Fax: 831-427-4748, E-mail: dfinlayson@usgs.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070711/ee510c18/attachment.html From michael.barton at asu.edu Thu Jul 12 03:26:03 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jul 12 03:26:13 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS 6.3 Installation Woes on OS X In-Reply-To: <09E065C8-9319-4F4C-96C7-2FC7A68E24BC@kyngchaos.com> Message-ID: If you have a .grassrc6 file that has a set gisdbase, location, and/or mapset (e.g., from using GRASS previously) and then you delete or rename any of the above, GRASS init.sh will generate an error and GRASS will crash on launch with the error message below. The only fix is to either make the gisdbase, location, or mapset directory that is listed in .grassrc6, or directly edit .grassrc6 to change or remove the offending line. Init.sh needs to trap this kind of error--or maybe better just ignore it. If any of these files is not present, GRASS should simply go to either a) the initial text based startup screen if the text interface or no interface is selected in .grassrc6, or b) go to the GUI for selecting gisdbase/location/mapset as if the gisdbase/location/mapset line was missing from .grassrc6. In any case this should not cause a crash. Michael ERROR ON STARTUP WITH INCORRECT LOCATION SET IN .GRASSRC6 access: No such file or directory ERROR: LOCATION << /Users/Shared/grassdata/test6 >> not available Traceback (most recent call last): File "/Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/gis_set.py", line 749, in GRASSStartUp = StartUp(0) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packag es/wx-2.8-mac-ansi/wx/_core.py", line 7757, in __init__ self._BootstrapApp() File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packag es/wx-2.8-mac-ansi/wx/_core.py", line 7354, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File "/Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/gis_set.py", line 740, in OnInit StartUp = GRASSStartup(None, -1, "") File "/Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/gis_set.py", line 463, in __init__ self.__set_properties() File "/Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/wx/gis_set.py", line 515, in __set_properties self.lblocations.SetSelection(self.listOfLocations.index(location)) ValueError: list.index(x): x not in list /Users/Shared/grassdata/test6/PERMANENT/.gislock: No such file or directory ERROR: /Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/lock: cmbarton is currently running GRASS in selected mapset (file /Users/Shared/grassdata/test6/PERMANENT/.gislock found). Concurrent use not allowed. logout [Process completed] On 7/11/07 10:41 AM, "William Kyngesburye" wrote: > On Jul 11, 2007, at 12:25 PM, Ryan Rosario wrote: > >> Thanks. All I have seen is .grassrc6 but that must have been from >> Lorenzo's build. To get a similar environment I just created a >> grass directory under /Users/ryan and then entered /Users/ryan/ >> grass into the GIS Data Directory field. I no longer get the error >> I asked about. >> >> Another user recommended creating my own .grassrc6 file which has >> apparently worked for other users, but it seems that my way works >> as well (both methods are probably doing the same thing). I >> downloaded the Spearfish dataset and all appears good as new. >> > The .grassrc6 file is (it should be) created automatically the first > time you run GRASS. I'm not sure, but it may require a successful > location/mapset selection/creation - ie you get the main GRASS > command prompt. > > There is no need to create .grassrc6 before running GRASS. Or to > edit it after creation, GRASS' g.gisenv maintains it. > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > "Time is an illusion - lunchtime doubly so." > > - Ford Prefect > > > __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From woklist at kyngchaos.com Thu Jul 12 04:48:49 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Thu Jul 12 04:48:58 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS 6.3 Installation Woes on OS X In-Reply-To: References: Message-ID: On Jul 11, 2007, at 8:26 PM, Michael Barton wrote: > If you have a .grassrc6 file that has a set gisdbase, location, and/or > mapset (e.g., from using GRASS previously) and then you delete or > rename any > of the above, GRASS init.sh will generate an error and GRASS will > crash on > launch with the error message below. > > The only fix is to either make the gisdbase, location, or mapset > directory > that is listed in .grassrc6, or directly edit .grassrc6 to change > or remove > the offending line. > Ah, yeah, that's an annoying one. Though the text and TclTk GUI don't quit, just notify you of the problem. > Init.sh needs to trap this kind of error--or maybe better just > ignore it. If > any of these files is not present, GRASS should simply go to either > a) the > initial text based startup screen if the text interface or no > interface is > selected in .grassrc6, or b) go to the GUI for selecting > gisdbase/location/mapset as if the gisdbase/location/mapset line > was missing > from .grassrc6. In any case this should not cause a crash. > Part of the problem, specifically for the OSX app startup, is that double-clicking the app doesn't give you the option to start directly into a mapset, like you can do with 'grass6 /path/to/location/mapset/ map' from the command line, or adding -text to the startup command, so it makes editing .grassrc6 necessary to correct problems. I just thought of one thing I can do for the app startup - drag-n- drop. I can have the AppleScript app take a folder dropped onto it as the '/path/to/location/mapset/map' option. I didn't use /path/to/ location/mapset/map much in the past, so it didn't occur to me to use drag-n-drop in the app ^_^ The selection of text/gui startup I deliberately avoided in the app startup, because I didn't want a dialog at startup every time, like Lorenzo does in his binary. I wonder if I can get AppleScript to intercept a modifier like shift or option at startup, hmmm... [wanders off to ponder AppleScript ideas...] ----- William Kyngesburye http://www.kyngchaos.com/ Earth: "Mostly harmless" - revised entry in the HitchHiker's Guide to the Galaxy From hamish_nospam at yahoo.com Thu Jul 12 04:56:49 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Jul 12 04:56:56 2007 Subject: [GRASS-dev] Re: [GRASS-user] thanks to GRASS! In-Reply-To: References: <339717.35268.qm@web53705.mail.re2.yahoo.com> Message-ID: <20070712145649.5dc6c737.hamish_nospam@yahoo.com> Michael wrote: > > I wonder if we should start a GRASS "library" on the main site or > > the WIKI where users could post PDF's or links to papers on using > > GRASS? (we already have one) Carlos wrote: > This could be a nice addition to the BibTeX list on the Wiki link: http://grass.gdf-hannover.de/wiki/GRASS_Citation_Repository Mars wrote: > Just out of curiosity, is there any presence of say, an OpenSource > style Journaling? The OSGeo journal uses a Creative Commons By Attribution - No Derivatives license: http://wiki.osgeo.org/index.php/Journal_License_and_Guidelines Hamish From neteler at itc.it Thu Jul 12 08:03:43 2007 From: neteler at itc.it (Markus Neteler) Date: Thu Jul 12 08:03:48 2007 Subject: [GRASS-dev] configuration X fails with strict gcc flags In-Reply-To: <18069.8775.354608.241932@cerise.gclements.plus.com> References: <20070711140344.GB15382@bartok.itc.it> <18069.8775.354608.241932@cerise.gclements.plus.com> Message-ID: <11554206.post@talk.nabble.com> Glynn Clements wrote: > > > Markus Neteler wrote: > >> I have a new laptop with Mandriva 2007.1 (so x.org). X is not >> recognised although all header files are apparently there. >> I debugged a bit and found the following (conftest.c and confdefs.h >> manually extracted from configure): >> >> cat conftest.c >> #line 4672 "configure" >> #include "confdefs.h" >> #include >> >> int main() { >> XtMalloc() >> ; return 0; } > >> gcc -o conftest -g -Wall -Werror-implicit-function-declaration >> -fno-common -mtune=nocona -m64 -minline-all-stringops >> -Wl,--export-dynamic -L/usr/lib64 conftest.c -lXt >> configure: In function 'main': >> configure:4676: error: too few arguments to function 'XtMalloc' > > Odd; my config.log has: > > configure:4675: warning: implicit declaration of function `XtMalloc' > Mine, too. Sorry, had added a ine of debug output and forgot to mention. configure:4510: checking for W11 configure:4538: checking for X configure:4603: gcc -E conftest.c >/dev/null 2>conftest.out configure:4679: gcc -o conftest -g -Wall -Werror-implicit-function-declaration -fno-common -mtune=nocona -m64 -minline-all-stringops -Wl,--export-dynamic -L/usr/lib64 conftest.c -lXt 1>&5 configure: In function 'main': configure:4675: error: implicit declaration of function 'XtMalloc' configure: failed program was: #line 4672 "configure" #include "confdefs.h" int main() { XtMalloc() ; return 0; } configure:5346: checking whether to use Curses > which implies that it isn't picking up the header. In fact, the > relevant portion of the configure script is: > > cat > conftest.$ac_ext < #line 4672 "configure" > #include "confdefs.h" > > int main() { > ${x_direct_test_function}() > ; return 0; } > EOF > > which doesn't include any X headers. > > Have you re-built your configure script using a different version of > autoconf? > Probably I added it in the debug output since I assumed that it was there. So, after reset to CVS version, it turns out to be this problem: configure:4675: error: implicit declaration of function 'XtMalloc' probably still caused by the -Werror-implicit-function-declaration flag. Maybe the gcc behaviour changed? It is Target: x86_64-mandriva-linux-gnu gcc version 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1) On my office box (RHEL4, 64bit), it works with identical flags, but it is: Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs gcc version 3.4.6 20060404 (Red Hat 3.4.6-8) I wonder why only this test fails. Markus -- View this message in context: http://www.nabble.com/configuration-X-fails-with-strict-gcc-flags-tf4062146.html#a11554206 Sent from the Grass - Dev mailing list archive at Nabble.com. From glynn at gclements.plus.com Thu Jul 12 13:17:38 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jul 12 13:17:40 2007 Subject: [GRASS-dev] Directory security/permission issue In-Reply-To: <1184198819.28744.58.camel@dev64.localdomain> References: <1183874859.30110.35.camel@dev64.localdomain> <18066.42956.899670.929947@cerise.gclements.plus.com> <1184027830.30110.97.camel@dev64.localdomain> <18067.45926.245689.116789@cerise.gclements.plus.com> <1184198819.28744.58.camel@dev64.localdomain> Message-ID: <18070.3538.284012.198141@cerise.gclements.plus.com> Brad Douglas wrote: > > > Don't know how, but my umask was set to 0002. > > > > Odd; 0002 should give mode 775 for directories. > > I know. I figured that at one point, the umask must have been 0, but > after some further testing, all new directory permissions are 0777 > REGARDLESS of manual change to umask. This leads me to believe it is > getting set somewhere in GRASS. Maybe lib/init/set_data.c? object | symbol -------------------------------------------------+-------- general/g.tempfile/OBJ.i686-pc-linux-gnu/main.o | umask lib/gis/OBJ.i686-pc-linux-gnu/gisinit.o | umask lib/init/OBJ.i686-pc-linux-gnu/set_data.o | umask lib/init/OBJ.i686-pc-linux-gnu/lock.o | umask (4 rows) lib/gis/gisinit.c has umask(022), while the others all have umask(0). Every single one of these is wrong. The umask is for the user; programs should leave it alone. I've removed all four umask() calls from CVS. Also, lib/init/init.sh had two occurrences of: echo "umask 022" >> "$bashrc" which I have removed. The remaining occurrence: tmp=/tmp/grass6-$USER-$GIS_LOCK (umask 077 && mkdir "$tmp") || { has been retained, although I'm not sure why this doesn't just use "mkdir -m 007" rather than (temporarily) setting the umask. -- Glynn Clements From glynn at gclements.plus.com Thu Jul 12 13:23:34 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jul 12 13:23:37 2007 Subject: [GRASS-dev] How to specify custom include directories In-Reply-To: References: Message-ID: <18070.3894.603687.530338@cerise.gclements.plus.com> David Finlayson wrote: > First time compiling GRASS on SuSE. I do not have su privileges on this > machine and so I am forced to build my entire tool chain in my home > directory ($HOME)=/we/davidf). > > So far fftw-3.1.2, gdal-1.4.2 and proj-4.5.0 have all compiled using the > following: > > ./configure --prefix=$HOME > make > make install > > Which has built a directory tree in $HOME like this: > > $HOME/bin > $HOME/include > $HOME/lib > $HOME/man > $HOME/share > > Now, trying the same with grass results in a configure error: > > albacore src/grass-6.2.cvs_src_snapshot_2007_07_07> ./configure > --prefix=$HOME --enable-64bit --with-libs=/usr/lib64 > checking host system type... x86_64-unknown-linux-gnu > checking for gcc... gcc > checking whether the C compiler (gcc ) works... yes > ... etc ... > checking for deflate in -lz... yes > checking for location of External PROJ.4 includes... > checking for proj_api.h... no > configure: error: *** Unable to locate External PROJ.4 includes. > > However, proj_api.h is in $HOME/include > > I have tried adding --includedir=$HOME/include to the above but that didn't > change anything. I'm sure it's something simple. How do I tell configure > where my local includes are (and why didn't --prefix=$HOME work?) Use the --with-includes= and/or --with-libs= switches to specify additional -I/-L switches to be used for all headers and libraries, or use the package-specific --with--includes= and/or --with--libs= switches to add directories for specific packages. Also, ensure that $LD_LIBRARY_PATH contains $HOME/lib. The --includedir= switch indicates where to install the package's own header files, not where it can find other packages' header files. But GRASS' doesn't honour those switches; everything goes into /grass-, except for the grass62 (etc) script which goes into the directory specified by the --bindir= switch, or into /bin if not specified. -- Glynn Clements From glynn at gclements.plus.com Thu Jul 12 13:46:22 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jul 12 13:46:24 2007 Subject: [GRASS-dev] configuration X fails with strict gcc flags In-Reply-To: <11554206.post@talk.nabble.com> References: <20070711140344.GB15382@bartok.itc.it> <18069.8775.354608.241932@cerise.gclements.plus.com> <11554206.post@talk.nabble.com> Message-ID: <18070.5262.51458.917963@cerise.gclements.plus.com> Markus Neteler wrote: > > Have you re-built your configure script using a different version of > > autoconf? > > Probably I added it in the debug output since I assumed that it was > there. So, after reset to CVS version, it turns out to be this problem: > > configure:4675: error: implicit declaration of function 'XtMalloc' > > probably still caused by the -Werror-implicit-function-declaration > flag. Yes. You may need to add that flag manually to Platform.make after configure has run. The autoconf linking checks (AC_CHECK_FUNCS, AC_CHECK_LIB etc) never include the header files, as that would give "too few arguments" errors, like the one you encountered (configure only knows the name of the function, not its type, so it has to call it without arguments). > Maybe the gcc behaviour changed? It is > Target: x86_64-mandriva-linux-gnu > gcc version 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1) > > On my office box (RHEL4, 64bit), it works with identical flags, but it is: > Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs > gcc version 3.4.6 20060404 (Red Hat 3.4.6-8) > > I wonder why only this test fails. The test program created by AC_CHECK_FUNC[S] normally includes a dummy prototype for the function, e.g.: #line 4893 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ ===> char dnet_ntoa(); int main() { dnet_ntoa() ; return 0; } However, the X checks call AC_TRY_LINK directly, without providing a prototype. I don't know why, and I don't know why this didn't trigger an error before. The XtMalloc check is part of AC_PATH_X, and calling that isn't really optional if we want to use X. -- Glynn Clements From neteler at itc.it Thu Jul 12 14:30:15 2007 From: neteler at itc.it (Markus Neteler) Date: Thu Jul 12 14:30:20 2007 Subject: [GRASS-dev] Re: Directory security/permission issue In-Reply-To: <18070.3538.284012.198141@cerise.gclements.plus.com> References: <1183874859.30110.35.camel@dev64.localdomain> <18066.42956.899670.929947@cerise.gclements.plus.com> <1184027830.30110.97.camel@dev64.localdomain> <18067.45926.245689.116789@cerise.gclements.plus.com> <1184198819.28744.58.camel@dev64.localdomain> <18070.3538.284012.198141@cerise.gclements.plus.com> Message-ID: <11558689.post@talk.nabble.com> Glynn Clements wrote: > > object | symbol > -------------------------------------------------+-------- > general/g.tempfile/OBJ.i686-pc-linux-gnu/main.o | umask > lib/gis/OBJ.i686-pc-linux-gnu/gisinit.o | umask > lib/init/OBJ.i686-pc-linux-gnu/set_data.o | umask > lib/init/OBJ.i686-pc-linux-gnu/lock.o | umask > (4 rows) > > lib/gis/gisinit.c has umask(022), while the others all have umask(0). > Every single one of these is wrong. The umask is for the user; > programs should leave it alone. > > I've removed all four umask() calls from CVS. > > Also, lib/init/init.sh had two occurrences of: > > echo "umask 022" >> "$bashrc" > > which I have removed. > > The remaining occurrence: > > tmp=/tmp/grass6-$USER-$GIS_LOCK > (umask 077 && mkdir "$tmp") || { > > has been retained, although I'm not sure why this doesn't just use > "mkdir -m 007" rather than (temporarily) setting the umask. > > -- > Glynn Clements > I have backported this to GRASS 6.2.CVS (for 6.2.2). Markus -- View this message in context: http://www.nabble.com/Directory-security-permission-issue-tf4043722.html#a11558689 Sent from the Grass - Dev mailing list archive at Nabble.com. From benjamin.ducke at ufg.uni-kiel.de Thu Jul 12 18:44:17 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Thu Jul 12 18:44:56 2007 Subject: [GRASS-dev] GRASS 6.3.CVS on Cygwin Message-ID: <46965A61.6070101@ufg.uni-kiel.de> Hi all, I am trying to create an up-to-date GRASS version with Cygwin. As usual, GDAL + GRASS is the biggest problem. I have compiled and install GDAL 1.4.2 successfully and now am trying to compile GRASS. In /lib/vector/Vlib in the linking stage I get: gcc -shared -o /home/tmp/grass6/dist.i686-pc-cygwin/lib/libgrass_vect.6.3.cvs.dll -L/home/tmp/grass6/dist.i686-pc-cygwin/lib -Wl,--export-dynamic OBJ.i686-pc-cygwin/area.o OBJ.i686-pc-cygwin/array.o OBJ.i686-pc-cygwin/box.o OBJ.i686-pc-cygwin/break_lines.o OBJ.i686-pc-cygwin/break_polygons.o OBJ.i686-pc-cygwin/bridges.o OBJ.i686-pc-cygwin/buffer.o OBJ.i686-pc-cygwin/build.o OBJ.i686-pc-cygwin/build_nat.o OBJ.i686-pc-cygwin/build_ogr.o OBJ.i686-pc-cygwin/cats.o OBJ.i686-pc-cygwin/cindex.o OBJ.i686-pc-cygwin/clean_nodes.o OBJ.i686-pc-cygwin/close.o OBJ.i686-pc-cygwin/close_nat.o OBJ.i686-pc-cygwin/close_ogr.o OBJ.i686-pc-cygwin/constraint.o OBJ.i686-pc-cygwin/dangles.o OBJ.i686-pc-cygwin/dbcolumns.o OBJ.i686-pc-cygwin/error.o OBJ.i686-pc-cygwin/field.o OBJ.i686-pc-cygwin/find.o OBJ.i686-pc-cygwin/graph.o OBJ.i686-pc-cygwin/header.o OBJ.i686-pc-cygwin/hist.o OBJ.i686-pc-cygwin/init_head.o OBJ.i686-pc-cygwin/intersect.o OBJ.i686-pc-cygwin/legal_vname.o OBJ.i686-pc-cygwin/level.o OBJ.i686-pc-cygwin/level_two.o OBJ.i686-pc-cygwin/line.o OBJ.i686-pc-cygwin/list.o OBJ.i686-pc-cygwin/map.o OBJ.i686-pc-cygwin/net.o OBJ.i686-pc-cygwin/open.o OBJ.i686-pc-cygwin/open_nat.o OBJ.i686-pc-cygwin/open_ogr.o OBJ.i686-pc-cygwin/overlap.o OBJ.i686-pc-cygwin/overlay.o OBJ.i686-pc-cygwin/poly.o OBJ.i686-pc-cygwin/read.o OBJ.i686-pc-cygwin/read_nat.o OBJ.i686-pc-cygwin/read_ogr.o OBJ.i686-pc-cygwin/remove_areas.o OBJ.i686-pc-cygwin/remove_duplicates.o OBJ.i686-pc-cygwin/rewind.o OBJ.i686-pc-cygwin/rewind_nat.o OBJ.i686-pc-cygwin/rewind_ogr.o OBJ.i686-pc-cygwin/select.o OBJ.i686-pc-cygwin/sindex.o OBJ.i686-pc-cygwin/snap.o OBJ.i686-pc-cygwin/tin.o OBJ.i686-pc-cygwin/type.o OBJ.i686-pc-cygwin/window.o OBJ.i686-pc-cygwin/write.o OBJ.i686-pc-cygwin/write_nat.o -lgrass_gis -lgrass_datetime -lrpclib -lz -lintl -lgrass_dig2 -lgrass_gis -lgrass_datetime -lrpclib -lz -lintl -lgrass_rtree -lgrass_dgl -lgrass_rtree -lgrass_linkm -lgrass_dbmiclient -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lrpclib -lz -lintl -lgrass_gis -lgrass_datetime -lrpclib -lz -lintl -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lrpclib -lz -lintl -L/usr/lib -lgdal && \ (cd /home/tmp/grass6/dist.i686-pc-cygwin/lib; ln -f -s libgrass_vect.6.3.cvs.dll /home/tmp/grass6/dist.i686-pc-cygwin/lib/libgrass_vect.dll) /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: BFD 2.17.50 20060817 assertion fail /netrel/src/binutils-20060817-1/bfd/cofflink.c:2266 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: /usr/lib/libgdal.dll(d000691.o): illegal symbol index -200 in relocs collect2: ld returned 1 exit status make: *** [/home/tmp/grass6/dist.i686-pc-cygwin/lib/libgrass_vect.6.3.cvs.dll] Error 1 --- The value '-200' is just a random number that seems to change every time I start another compile attempt. I checked GDAL-1.4.1. Same problem. Does anyone have a clue what the problem is, this time? Cheers, Benjamin -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From dca.gis at gmail.com Thu Jul 12 20:12:55 2007 From: dca.gis at gmail.com (Daniel Calvelo) Date: Thu Jul 12 20:12:59 2007 Subject: [GRASS-dev] Re: [GRASS-user] thanks to GRASS! In-Reply-To: References: <339717.35268.qm@web53705.mail.re2.yahoo.com> <2b3d8c1c0707111312l32aeb94alacb644e0c6e8470b@mail.gmail.com> Message-ID: <1a486f560707121112l1d755afdx224cf68749e73b9e@mail.gmail.com> Been there. You sign a copyright transfer to the publisher on the finished article, after any rounds of corrections. So you still own the copyright to the pre-prints. >From there to release those under CC licences, it's legally possible. Indeed, see: http://romeo.eprints.org/publishers.html for a list of those publishers that have explicitly stated they encourage this. Daniel. On 7/11/07, Carlos Gu?no Grohmann wrote: > I vaguely remember of somewhere in Elsevier's site where it said that > authors even could put the pdfs on personal home-pages, but that the > prefence was for Elsevier to distribute it.. > > So, yes, it is not legal to put the pdfs on the wiki. BUT it's OK to > put the pdfs of the _uncorrected proofs_ (not sure about the corrected > proofs). > > So I guess we can set up a page in the wiki with a list of references, > BibTeX entries, pdfs of uncorrected proofs, and a link (DOI) to the > journal. > > Carlos > > > > On 7/11/07, Maris Nartiss wrote: > > I think there could be some legal issues. > > > > I.e. from COMPUTERS & GEOSCIENCES Guide for Authors [1] "e) if > > accepted, will not be published elsewhere in the same form, in English > > or in any > > other language, without the written consent of the Publisher." > > IANAL but putting article PDF on wiki may be threated as "publishing"? > > > > Maris. > > > > [1] http://www.elsevier.com/wps/find/journaldescription.cws_home/398/authorinstructions > > > > 2007/7/11, Michael Barton : > > > I wonder if we should start a GRASS "library" on the main site or the WIKI > > > where users could post PDF's or links to papers on using GRASS? > > > > > > Michael > > > > > > > > > On 7/11/07 1:03 AM, "Jaime Carrera" wrote: > > > > > > > Dear list, > > > > > > > > I would just like to thank the GRASS development team for creating such a > > > nice > > > > piece of software, as without it I couldn't have done my PhD work. One of > > > my > > > > ideas was to show that Open Source software can be used to develop a large > > > > project (as some people think that free stuff is not good) and the use of > > > > GRASS, R, GMT, The GIMP and Inkscape was crucial to prove my point. > > > > > > > > If someone is interested in some of this work, please follow these links; > > > if > > > > someone can't access these links, please let me know and I can send a PDF > > > copy > > > > of them. > > > > > > > > On the use of GRASS with R and GSTAT to interpolate daily climatological > > > > variables (rainfall, and both minimum and maximum temperature) using > > > different > > > > Kriging methods: > > > > > > > > Carrera-Hernandez, J. J. and Gaskin, S.J. (2007). Spatio temporal analysis > > > of > > > > daily precipitation and temperature in the Basin of Mexico. Journal of > > > > Hydrology. DOI: http://dx.doi.org/10.1016/j.jhydrol.2006.12.021 > > > > > > > > On the use of GRASS in groundwater modeling (Now I have time to update it > > > for > > > > GRASS 6.2 and MODFLOW 2005 !) > > > > > > > > Carrera-Hernandez, J. J. and Gaskin, S. J. (2006). The Groundwater > > > Modelling > > > > Tool for GRASS (GMTG). Open Source groundwater flow modelling. Computers & > > > > Geosciences 32(3):339-351. DOI: > > > http://dx.doi.org/10.1016/j.cageo.2005.06.018 > > > > > > > > There is another paper (in press, Hydrogeology Journal) on which I used > > > GRASS, > > > > R and GMT to analyze the evolution of the groundwater level in the Basin > > > of > > > > Mexico. The DOI It should be available within the next week. > > > > > > > > Cheers, > > > > > > > > Jaime > > > > > > > > > > > > __________________________________________________ > > > > Correo Yahoo! > > > > Espacio para todos tus mensajes, antivirus y antispam ?gratis! > > > > Reg?strate ya - http://correo.espanol.yahoo.com/ > > > > > > > > > __________________________________________ > > > Michael Barton, Professor of Anthropology > > > Director of Graduate Studies > > > School of Human Evolution & Social Change > > > Center for Social Dynamics & Complexity > > > Arizona State University > > > > > > phone: 480-965-6213 > > > fax: 480-965-7671 > > > www: http://www.public.asu.edu/~cmbarton > > > > > > > > > > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev > > > > > -- > +-----------------------------------------------------------+ > Carlos Henrique Grohmann - Guano > Visiting Researcher at Kingston University London - UK > Geologist M.Sc - Doctorate Student at IGc-USP - Brazil > Linux User #89721 - carlos dot grohmann at gmail dot com > +-----------------------------------------------------------+ > _________________ > "Good morning, doctors. I have taken the liberty of removing Windows > 95 from my hard drive." > --The winning entry in a "What were HAL's first words" contest judged > by 2001: A SPACE ODYSSEY creator Arthur C. Clarke > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- -- Daniel Calvelo Aros From epatton at nrcan.gc.ca Thu Jul 12 20:47:28 2007 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Thu Jul 12 20:47:36 2007 Subject: [GRASS-dev] r.in.xyz can now read from stdin References: <20070711193216.0afa5fba.hamish_nospam@yahoo.com> Message-ID: Hello, Hamish: >I just added redirection from stdin support to r.in.xyz. Everything seems to >work, but of course testing is appreciated. Thanks very much for this. I've tested r.in.xyz on a massive Simrad EM710 swath bathymetry dataset. Results follow: $ g.region -p projection: 1 (UTM) zone: 20 datum: wgs84 ellipsoid: wgs84 north: 5027110 south: 4878260 west: 169140 east: 404580 nsres: 10 ewres: 10 rows: 14885 cols: 23544 cells: 350452440 $ r.out.xyz input=Matthew_EM710_2007_July4_10m.grd fs=, output=- | r.in.xyz input=- output=TESTING_R_IN_XYZ fs=, Scanning data ... 100% Writing to map ... 100% r.in.xyz complete. 35315212 points found in region. $ r.info TESTING_R_IN_XYZ +----------------------------------------------------------------------------+ | Layer: TESTING_R_IN_XYZ Date: Thu Jul 12 15:30:19 2007 | | Mapset: 2007006 Login of Creator: epatton | | Location: FundyBathy | | DataBase: /home/epatton/Projects | | Title: Raw x,y,z data binned into a raster grid by cell mean ( TESTING_ | | Timestamp: none | |----------------------------------------------------------------------------| | | | Type of Map: raster Number of Categories: 255 | | Data Type: FCELL | | Rows: 14885 | | Columns: 23544 | | Total Cells: 350452440 | | Projection: UTM (zone 20) | | N: 5027110 S: 4878260 Res: 10 | | E: 404580 W: 169140 Res: 10 | | Range of data: min = -278.542236 max = -3.504807 | | | | Data Source: | | stdin | | | | | | Data Description: | | generated by r.in.xyz | | | | Comments: | | r.in.xyz input="-" output="TESTING_R_IN_XYZ" method="mean" type="FCE\ | | LL" x=1 y=2 z=3 percent=100 | | | +----------------------------------------------------------------------------+ The newly-gridded bathy looks fine; identical to the original. Before I leave work today I'm going to halve the resolution (quadruple the number of cells), and start another r.out.xyz --> r.in.xyz run, and let it run overnight. I'll let you know how it goes tomorrow morning (wee hours Saturday morning your time). Just for fun, I'll 'time' it as well. Cheers, ~ Eric. From epatton at nrcan.gc.ca Thu Jul 12 21:20:07 2007 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Thu Jul 12 21:20:10 2007 Subject: [GRASS-dev] r.in.xyz can now read from stdin References: <20070711193216.0afa5fba.hamish_nospam@yahoo.com> Message-ID: Well, never mind. We won't have to wait that long. I ran out of memory trying to pipe the text file in question to r.in.xyz: $ g.region -p projection: 1 (UTM) zone: 20 datum: wgs84 ellipsoid: wgs84 north: 5027110 south: 4878260 west: 169140 east: 404580 nsres: 5 ewres: 5 rows: 29770 cols: 47088 cells: 1401809760 $ r.out.xyz input=Matthew_EM710_2007_July4_10m.grd fs=, output=TESTING_R_IN_XYZ_5m.txt 100% # Input: TESTING_R_IN_XYZ_5m.txt Size: ~4.6GB $ cat TESTING_R_IN_XYZ_5m.txt | r.in.xyz input=- output=TESTING_R_IN_XYZ_5m fs=, percent=100 ERROR: G_calloc: out of memory I realize I'm using a ridiculously large region. Should r.in.xyz have been able to accept a file this large? ~ Eric. From hamish_nospam at yahoo.com Fri Jul 13 02:59:58 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Jul 13 03:00:16 2007 Subject: [GRASS-dev] Directory security/permission issue In-Reply-To: <18070.3538.284012.198141@cerise.gclements.plus.com> References: <1183874859.30110.35.camel@dev64.localdomain> <18066.42956.899670.929947@cerise.gclements.plus.com> <1184027830.30110.97.camel@dev64.localdomain> <18067.45926.245689.116789@cerise.gclements.plus.com> <1184198819.28744.58.camel@dev64.localdomain> <18070.3538.284012.198141@cerise.gclements.plus.com> Message-ID: <20070713125958.69020087.hamish_nospam@yahoo.com> Glynn Clements wrote: > Also, lib/init/init.sh had two occurrences of: > > echo "umask 022" >> "$bashrc" > > which I have removed. any g.access repercussions to this? (beyond the obvious) > The remaining occurrence: > > tmp=/tmp/grass6-$USER-$GIS_LOCK > (umask 077 && mkdir "$tmp") || { > > has been retained, although I'm not sure why this doesn't just use > "mkdir -m 007" rather than (temporarily) setting the umask. my inspiration for that: http://www.linuxsecurity.com/content/view/115462/151/#mozTocId648982 Is 'mkdir -m' portable? Hamish From hamish_nospam at yahoo.com Fri Jul 13 05:38:37 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Jul 13 05:38:45 2007 Subject: [GRASS-dev] r.in.xyz can now read from stdin In-Reply-To: References: <20070711193216.0afa5fba.hamish_nospam@yahoo.com> Message-ID: <20070713153837.3a4694d9.hamish_nospam@yahoo.com> > Hamish: > >I just added redirection from stdin support to r.in.xyz. Everything > >seems to work, but of course testing is appreciated. Eric wrote: > Thanks very much for this. I've tested r.in.xyz on a massive Simrad > EM710 swath bathymetry dataset. Results follow: > > $ g.region -p .. > nsres: 10 > ewres: 10 > rows: 14885 > cols: 23544 > cells: 350452440 > > $ r.out.xyz input=Matthew_EM710_2007_July4_10m.grd fs=, output=- | > r.in.xyz input=- output=TESTING_R_IN_XYZ fs=, Scanning data ... > 100% > Writing to map ... > 100% > r.in.xyz complete. 35315212 points found in region. > > $ r.info TESTING_R_IN_XYZ .. > The newly-gridded bathy looks fine; identical to the original. r.univar results the same? (n and sum) or r.mapcalc diff_map=old-new r.univar diff_map maybe we need a r.md5sum option added to r.info? > Before I leave work today I'm going to halve the resolution (quadruple > the number of cells), and start another r.out.xyz --> r.in.xyz run, > and let it run overnight. I'll let you know how it goes tomorrow > morning (wee hours Saturday morning your time). Just for fun, I'll > 'time' it as well. .. > Well, never mind. We won't have to wait that long. I ran out of memory > trying to pipe the text file in question to r.in.xyz: .. > nsres: 5 .. > cells: 1401809760 .. > I realize I'm using a ridiculously large region. Should r.in.xyz have > been able to accept a file this large? It's not anything to do with the input file size, it's the region size that is the problem. r.in.xyz from stdin has to keep the entire region in memory at once. See the (updated) help page section about memory issues. If the input comes from a file and not a stream, you can use the input= filename and percent=25 to run it using 4 passes using a quarter of the memory. You can get the same effect by importing a number of subregions and r.patch-ing them back together. thanks for the feedback, Hamish From carlos.grohmann at gmail.com Fri Jul 13 10:31:48 2007 From: carlos.grohmann at gmail.com (=?ISO-8859-1?Q?Carlos_"Gu=E2no"_Grohmann?=) Date: Fri Jul 13 10:31:53 2007 Subject: [GRASS-dev] Re: [GRASS-user] thanks to GRASS! In-Reply-To: <1a486f560707121112l1d755afdx224cf68749e73b9e@mail.gmail.com> References: <339717.35268.qm@web53705.mail.re2.yahoo.com> <2b3d8c1c0707111312l32aeb94alacb644e0c6e8470b@mail.gmail.com> <1a486f560707121112l1d755afdx224cf68749e73b9e@mail.gmail.com> Message-ID: This is from Elsevier's web site: What rights do I retain as a journal author*? As a journal author, you retain rights for large number of author uses, including use by your employing institute or company. These rights are retained and permitted without the need to obtain specific permission from Elsevier. These include: * the right to make copies (print or electric) of the journal article for their own personal use, including for their own classroom teaching use; * the right to make copies and distribute copies (including via e-mail) of the journal article to research colleagues, for personal use by such colleagues (but not for Commercial Purposes**, as listed below); * the right to post a pre-print version of the journal article on Internet web sites including electronic pre-print servers, and to retain indefinitely such version on such servers or sites (see also our information on electronic preprints for a more detailed discussion on these points); * the right to post a revised personal version of the text of the final journal article (to reflect changes made in the peer review process) on the author's personal or institutional web site or server, incorporating the complete citation and with a link to the Digital Object Identifier (DOI) of the article; * the right to present the journal article at a meeting or conference and to distribute copies of such paper or article to the delegates attending the meeting; * for the author's employer, if the journal article is a 'work for hire', made within the scope of the author's employment, the right to use all or part of the information in (any version of) the journal article for other intra-company use (e.g. training), including by posting the article on secure, internal corporate intranets; * patent and trademark rights and rights to any process or procedure described in the journal article; * the right to include the journal article, in full or in part, in a thesis or dissertation; * the right to use the journal article or any part thereof in a printed compilation of works of the author, such as collected writings or lecture notes (subsequent to publication of the article in the journal); and * the right to prepare other derivative works, to extend the journal article into book-length form, or to otherwise re-use portions or excerpts in other works, with full acknowledgement of its original publication in the journal. so we _can_ post the pre-print versions. Carlos On 7/12/07, Daniel Calvelo wrote: > Been there. You sign a copyright transfer to the publisher on the > finished article, after any rounds of corrections. So you still own > the copyright to the pre-prints. > > From there to release those under CC licences, it's legally possible. > Indeed, see: http://romeo.eprints.org/publishers.html for a list of > those publishers that have explicitly stated they encourage this. > > Daniel. > > On 7/11/07, Carlos Gu?no Grohmann wrote: > > I vaguely remember of somewhere in Elsevier's site where it said that > > authors even could put the pdfs on personal home-pages, but that the > > prefence was for Elsevier to distribute it.. > > > > So, yes, it is not legal to put the pdfs on the wiki. BUT it's OK to > > put the pdfs of the _uncorrected proofs_ (not sure about the corrected > > proofs). > > > > So I guess we can set up a page in the wiki with a list of references, > > BibTeX entries, pdfs of uncorrected proofs, and a link (DOI) to the > > journal. > > > > Carlos > > > > > > > > On 7/11/07, Maris Nartiss wrote: > > > I think there could be some legal issues. > > > > > > I.e. from COMPUTERS & GEOSCIENCES Guide for Authors [1] "e) if > > > accepted, will not be published elsewhere in the same form, in English > > > or in any > > > other language, without the written consent of the Publisher." > > > IANAL but putting article PDF on wiki may be threated as "publishing"? > > > > > > Maris. > > > > > > [1] http://www.elsevier.com/wps/find/journaldescription.cws_home/398/authorinstructions > > > > > > 2007/7/11, Michael Barton : > > > > I wonder if we should start a GRASS "library" on the main site or the WIKI > > > > where users could post PDF's or links to papers on using GRASS? > > > > > > > > Michael > > > > > > > > > > > > On 7/11/07 1:03 AM, "Jaime Carrera" wrote: > > > > > > > > > Dear list, > > > > > > > > > > I would just like to thank the GRASS development team for creating such a > > > > nice > > > > > piece of software, as without it I couldn't have done my PhD work. One of > > > > my > > > > > ideas was to show that Open Source software can be used to develop a large > > > > > project (as some people think that free stuff is not good) and the use of > > > > > GRASS, R, GMT, The GIMP and Inkscape was crucial to prove my point. > > > > > > > > > > If someone is interested in some of this work, please follow these links; > > > > if > > > > > someone can't access these links, please let me know and I can send a PDF > > > > copy > > > > > of them. > > > > > > > > > > On the use of GRASS with R and GSTAT to interpolate daily climatological > > > > > variables (rainfall, and both minimum and maximum temperature) using > > > > different > > > > > Kriging methods: > > > > > > > > > > Carrera-Hernandez, J. J. and Gaskin, S.J. (2007). Spatio temporal analysis > > > > of > > > > > daily precipitation and temperature in the Basin of Mexico. Journal of > > > > > Hydrology. DOI: http://dx.doi.org/10.1016/j.jhydrol.2006.12.021 > > > > > > > > > > On the use of GRASS in groundwater modeling (Now I have time to update it > > > > for > > > > > GRASS 6.2 and MODFLOW 2005 !) > > > > > > > > > > Carrera-Hernandez, J. J. and Gaskin, S. J. (2006). The Groundwater > > > > Modelling > > > > > Tool for GRASS (GMTG). Open Source groundwater flow modelling. Computers & > > > > > Geosciences 32(3):339-351. DOI: > > > > http://dx.doi.org/10.1016/j.cageo.2005.06.018 > > > > > > > > > > There is another paper (in press, Hydrogeology Journal) on which I used > > > > GRASS, > > > > > R and GMT to analyze the evolution of the groundwater level in the Basin > > > > of > > > > > Mexico. The DOI It should be available within the next week. > > > > > > > > > > Cheers, > > > > > > > > > > Jaime > > > > > > > > > > > > > > > __________________________________________________ > > > > > Correo Yahoo! > > > > > Espacio para todos tus mensajes, antivirus y antispam ?gratis! > > > > > Reg?strate ya - http://correo.espanol.yahoo.com/ > > > > > > > > > > > > __________________________________________ > > > > Michael Barton, Professor of Anthropology > > > > Director of Graduate Studies > > > > School of Human Evolution & Social Change > > > > Center for Social Dynamics & Complexity > > > > Arizona State University > > > > > > > > phone: 480-965-6213 > > > > fax: 480-965-7671 > > > > www: http://www.public.asu.edu/~cmbarton > > > > > > > > > > > > > > > > > > _______________________________________________ > > > grass-dev mailing list > > > grass-dev@grass.itc.it > > > http://grass.itc.it/mailman/listinfo/grass-dev > > > > > > > > > -- > > +-----------------------------------------------------------+ > > Carlos Henrique Grohmann - Guano > > Visiting Researcher at Kingston University London - UK > > Geologist M.Sc - Doctorate Student at IGc-USP - Brazil > > Linux User #89721 - carlos dot grohmann at gmail dot com > > +-----------------------------------------------------------+ > > _________________ > > "Good morning, doctors. I have taken the liberty of removing Windows > > 95 from my hard drive." > > --The winning entry in a "What were HAL's first words" contest judged > > by 2001: A SPACE ODYSSEY creator Arthur C. Clarke > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev > > > > > -- > -- Daniel Calvelo Aros > -- +-----------------------------------------------------------+ Carlos Henrique Grohmann - Guano Visiting Researcher at Kingston University London - UK Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - carlos dot grohmann at gmail dot com +-----------------------------------------------------------+ _________________ "Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive." --The winning entry in a "What were HAL's first words" contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke From benjamin.ducke at ufg.uni-kiel.de Fri Jul 13 15:26:10 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Fri Jul 13 15:26:53 2007 Subject: [GRASS-dev] GRASS 6.3.CVS on Cygwin In-Reply-To: <46965A61.6070101@ufg.uni-kiel.de> References: <46965A61.6070101@ufg.uni-kiel.de> Message-ID: <46977D72.6010206@ufg.uni-kiel.de> It seems to be a problem with the binutils included in the latest Cygwin setup. With a more recent version compiled from CVS, it works! Cheers, Benjamin Benjamin Ducke wrote: > Hi all, > > I am trying to create an up-to-date GRASS version with Cygwin. > As usual, GDAL + GRASS is the biggest problem. > I have compiled and install GDAL 1.4.2 successfully and now am > trying to compile GRASS. > > In /lib/vector/Vlib in the linking stage I get: > > gcc -shared -o > /home/tmp/grass6/dist.i686-pc-cygwin/lib/libgrass_vect.6.3.cvs.dll > -L/home/tmp/grass6/dist.i686-pc-cygwin/lib -Wl,--export-dynamic > OBJ.i686-pc-cygwin/area.o OBJ.i686-pc-cygwin/array.o > OBJ.i686-pc-cygwin/box.o OBJ.i686-pc-cygwin/break_lines.o > OBJ.i686-pc-cygwin/break_polygons.o OBJ.i686-pc-cygwin/bridges.o > OBJ.i686-pc-cygwin/buffer.o OBJ.i686-pc-cygwin/build.o > OBJ.i686-pc-cygwin/build_nat.o OBJ.i686-pc-cygwin/build_ogr.o > OBJ.i686-pc-cygwin/cats.o OBJ.i686-pc-cygwin/cindex.o > OBJ.i686-pc-cygwin/clean_nodes.o OBJ.i686-pc-cygwin/close.o > OBJ.i686-pc-cygwin/close_nat.o OBJ.i686-pc-cygwin/close_ogr.o > OBJ.i686-pc-cygwin/constraint.o OBJ.i686-pc-cygwin/dangles.o > OBJ.i686-pc-cygwin/dbcolumns.o OBJ.i686-pc-cygwin/error.o > OBJ.i686-pc-cygwin/field.o OBJ.i686-pc-cygwin/find.o > OBJ.i686-pc-cygwin/graph.o OBJ.i686-pc-cygwin/header.o > OBJ.i686-pc-cygwin/hist.o OBJ.i686-pc-cygwin/init_head.o > OBJ.i686-pc-cygwin/intersect.o OBJ.i686-pc-cygwin/legal_vname.o > OBJ.i686-pc-cygwin/level.o OBJ.i686-pc-cygwin/level_two.o > OBJ.i686-pc-cygwin/line.o OBJ.i686-pc-cygwin/list.o > OBJ.i686-pc-cygwin/map.o OBJ.i686-pc-cygwin/net.o > OBJ.i686-pc-cygwin/open.o OBJ.i686-pc-cygwin/open_nat.o > OBJ.i686-pc-cygwin/open_ogr.o OBJ.i686-pc-cygwin/overlap.o > OBJ.i686-pc-cygwin/overlay.o OBJ.i686-pc-cygwin/poly.o > OBJ.i686-pc-cygwin/read.o OBJ.i686-pc-cygwin/read_nat.o > OBJ.i686-pc-cygwin/read_ogr.o OBJ.i686-pc-cygwin/remove_areas.o > OBJ.i686-pc-cygwin/remove_duplicates.o OBJ.i686-pc-cygwin/rewind.o > OBJ.i686-pc-cygwin/rewind_nat.o OBJ.i686-pc-cygwin/rewind_ogr.o > OBJ.i686-pc-cygwin/select.o OBJ.i686-pc-cygwin/sindex.o > OBJ.i686-pc-cygwin/snap.o OBJ.i686-pc-cygwin/tin.o > OBJ.i686-pc-cygwin/type.o OBJ.i686-pc-cygwin/window.o > OBJ.i686-pc-cygwin/write.o OBJ.i686-pc-cygwin/write_nat.o -lgrass_gis > -lgrass_datetime -lrpclib -lz -lintl -lgrass_dig2 -lgrass_gis > -lgrass_datetime -lrpclib -lz -lintl -lgrass_rtree -lgrass_dgl > -lgrass_rtree -lgrass_linkm -lgrass_dbmiclient -lgrass_dbmibase > -lgrass_gis -lgrass_datetime -lrpclib -lz -lintl -lgrass_gis > -lgrass_datetime -lrpclib -lz -lintl -lgrass_dbmibase -lgrass_gis > -lgrass_datetime -lrpclib -lz -lintl -L/usr/lib -lgdal && \ > (cd /home/tmp/grass6/dist.i686-pc-cygwin/lib; ln -f -s > libgrass_vect.6.3.cvs.dll > /home/tmp/grass6/dist.i686-pc-cygwin/lib/libgrass_vect.dll) > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: BFD > 2.17.50 20060817 assertion fail > /netrel/src/binutils-20060817-1/bfd/cofflink.c:2266 > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: > /usr/lib/libgdal.dll(d000691.o): illegal symbol index -200 in relocs > collect2: ld returned 1 exit status > make: *** > [/home/tmp/grass6/dist.i686-pc-cygwin/lib/libgrass_vect.6.3.cvs.dll] Error 1 > > --- > > The value '-200' is just a random number that seems to change every time > I start another compile attempt. > I checked GDAL-1.4.1. Same problem. > > Does anyone have a clue what the problem is, this time? > > Cheers, > > Benjamin > > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From glynn at gclements.plus.com Fri Jul 13 17:26:09 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jul 13 17:26:12 2007 Subject: [GRASS-dev] Directory security/permission issue In-Reply-To: <20070713125958.69020087.hamish_nospam@yahoo.com> References: <1183874859.30110.35.camel@dev64.localdomain> <18066.42956.899670.929947@cerise.gclements.plus.com> <1184027830.30110.97.camel@dev64.localdomain> <18067.45926.245689.116789@cerise.gclements.plus.com> <1184198819.28744.58.camel@dev64.localdomain> <18070.3538.284012.198141@cerise.gclements.plus.com> <20070713125958.69020087.hamish_nospam@yahoo.com> Message-ID: <18071.39313.25060.838048@cerise.gclements.plus.com> Hamish wrote: > Glynn Clements wrote: > > Also, lib/init/init.sh had two occurrences of: > > > > echo "umask 022" >> "$bashrc" > > > > which I have removed. > > any g.access repercussions to this? (beyond the obvious) > > > The remaining occurrence: > > > > tmp=/tmp/grass6-$USER-$GIS_LOCK > > (umask 077 && mkdir "$tmp") || { > > > > has been retained, although I'm not sure why this doesn't just use > > "mkdir -m 007" rather than (temporarily) setting the umask. > > > my inspiration for that: > http://www.linuxsecurity.com/content/view/115462/151/#mozTocId648982 > > Is 'mkdir -m' portable? It is according to: http://www.opengroup.org/onlinepubs/009695399/utilities/mkdir.html OTOH, umask is probably more portable, so I don't see any reason to change it. -- Glynn Clements From woklist at kyngchaos.com Fri Jul 13 18:21:16 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Fri Jul 13 18:21:31 2007 Subject: [GRASS-dev] new drag-n-drop mapset for Mac .app build Message-ID: <8E230BD0-DA1B-436C-9914-8EDE2E52BA2A@kyngchaos.com> It's now possible to drag a mapset folder to the Mac GRASS.app binary to have it open that mapset immediately on startup. This is exactly the same as the commandline startup (which doesn't directly work with GRASS.app): grass63 /path/to/db/location/mapset AND, the equivalent commandline startup for GRASS.app (so you don't need to type the full path to the grass.sh script or mess with your PATH) is: open -a "GRASS-6.3.app" /path/to/db/location/mapset Note that this will open a new Terminal window, instead of running it in the current window. In working this out, I also seem to have fixed the odd PPC problem where running grass-xterm-wrapper once made it impossible to run GRASS.app again until Terminal is quit (which meant GRASS also must be quit). ----- William Kyngesburye http://www.kyngchaos.com/ "I ache, therefore I am. Or in my case - I am, therefore I ache." - Marvin From neteler at itc.it Sat Jul 14 13:33:44 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Jul 14 13:33:48 2007 Subject: [GRASS-dev] flags --o and --q in g.parser/scripts? Message-ID: <11593116.post@talk.nabble.com> Hi, I wonder how to make use of --o (and --q) in shell scripts (have to conditionalize a test). Markus -- View this message in context: http://www.nabble.com/flags---o-and---q-in-g.parser-scripts--tf4078828.html#a11593116 Sent from the Grass - Dev mailing list archive at Nabble.com. From glynn at gclements.plus.com Sat Jul 14 15:15:45 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jul 14 15:15:49 2007 Subject: [GRASS-dev] flags --o and --q in g.parser/scripts? In-Reply-To: <11593116.post@talk.nabble.com> References: <11593116.post@talk.nabble.com> Message-ID: <18072.52353.727809.680704@cerise.gclements.plus.com> Markus Neteler wrote: > I wonder how to make use of --o (and --q) in shell scripts (have to > conditionalize a test). If a script is run with --o, G_parser() will set GRASS_OVERWRITE=1, which has the same effect as passing --o to every module which is run from the script. Similarly, passing --q or --v will set GRASS_VERBOSE to 0 or 3 respectively, which has the same effect as passing --q or --v to every module which is run from the script. Rather than checking whether --o, --q or --v were used, you should be checking $GRASS_OVERWRITE and/or $GRASS_VERBOSE instead. If those variables are set, the script should behave the same way regardless of whether they were set by --o, --q or --v being passed to the script or set by other means. -- Glynn Clements From benjamin.ducke at ufg.uni-kiel.de Sat Jul 14 18:00:20 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Sat Jul 14 18:00:59 2007 Subject: [GRASS-dev] GRASS 6.3 on Cygwin Message-ID: <4698F314.9060908@ufg.uni-kiel.de> Did anyone here try to get a recent version of GRASS CVS running under Cygwin? I got GDAL and GRASS to compile just fine, but when I want to start ANY GRASS module that uses the GDAL libs directly or get linked to Vlib which in turn is linked to GDAL. I get nothing at all. Really: nothing at all, no error message, nothing. Just get kicked to the prompt again. --help does not provoke a reaction, neither does any other option. It seems that the modules just die silently. Great. GDAL itself seems to work fine. I can e.g. use ogr2ogr w/o problems. I tried all GDAL versions from 1.3.1 to 1.4.2 with GRASS support built in and using the gdal-grass plugin. Nothing. I tried down and upgrading the binutils to several different versions. Doesn't help. I tried compiling absolutely minimal versions of both GRASS and GDAL. No luck, either. How hard can it be to get a recent version of GRASS to SOMEHOW run under Windows? -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From benjamin.ducke at ufg.uni-kiel.de Sat Jul 14 18:40:17 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Sat Jul 14 18:40:54 2007 Subject: [GRASS-dev] GRASS 6.3 on Cygwin In-Reply-To: <20070714113347.ASZ76306@expms1.cites.uiuc.edu> References: <20070714113347.ASZ76306@expms1.cites.uiuc.edu> Message-ID: <4698FC71.6090206@ufg.uni-kiel.de> Yes I have. It's not usable in practice because all modules that access an attribute table through the DBMI driver on native Win32 are prone to random deadlocks. In effect this means GRASS is useless for vector data processing on Win32. I have filed a bug report to the QGIS team and there was some discussion of this on this list recently. So far, the bug could not be identified or removed. That's why I wanted to give Cygwin a try. Benjamin Gerald Nelson wrote: > Have you tried the new wingrass? It's still experimental but some (most?) things work great. It looks and feels like grass. The last time I tried it (on a Vista) machine, I ran into a problem with one of the commands giving me a tcl error. > > Jerry > > ---- Original message ---- >> Date: Sat, 14 Jul 2007 18:00:20 +0200 >> From: Benjamin Ducke >> Subject: [GRASS-dev] GRASS 6.3 on Cygwin >> To: GRASS devel >> >> Did anyone here try to get a recent version of GRASS CVS running under >> Cygwin? >> >> I got GDAL and GRASS to compile just fine, but when I want to start ANY >> GRASS module that uses the GDAL libs directly or get linked to Vlib >> which in turn is linked to GDAL. >> I get nothing at all. Really: nothing at all, no error message, nothing. >> Just get kicked to the prompt again. --help does not provoke a reaction, >> neither does any other option. It seems that the modules just die >> silently. Great. >> >> GDAL itself seems to work fine. I can e.g. use ogr2ogr w/o problems. >> >> I tried all GDAL versions from 1.3.1 to 1.4.2 with GRASS support built >> in and using the gdal-grass plugin. Nothing. >> >> I tried down and upgrading the binutils to several different versions. >> Doesn't help. >> >> I tried compiling absolutely minimal versions of both GRASS and GDAL. >> No luck, either. >> >> How hard can it be to get a recent version of GRASS to SOMEHOW run under >> Windows? >> >> >> -- >> Benjamin Ducke, M.A. >> Arch?oinformatik >> (Archaeoinformation Science) >> Institut f?r Ur- und Fr?hgeschichte >> (Inst. of Prehistoric and Historic Archaeology) >> Christian-Albrechts-Universit?t zu Kiel >> Johanna-Mestorf-Stra?e 2-6 >> D 24098 Kiel >> Germany >> >> Tel.: ++49 (0)431 880-3378 / -3379 >> Fax : ++49 (0)431 880-7300 >> www.uni-kiel.de/ufg >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev > Gerald Nelson > Professor, Dept. of Agricultural and Consumer Economics > University of Illinois, Urbana-Champaign > office: 217-333-6465 > cell: 217-390-7888 > 315 Mumford Hall > 1301 W. Gregory > Urbana, IL 61801 > > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From grass-codei at wald.intevation.org Sun Jul 15 10:20:56 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Sun Jul 15 10:18:49 2007 Subject: [GRASS-dev] [grass-code I][446] Illegal filename. Character <'> not allowed. Message-ID: <20070715082056.BDCD0400E3@pyrosoma.intevation.org> code I item #446, was opened at 2007-07-15 10:20 Status: Open Priority: 3 Submitted By: Markus Neteler (markusn) Assigned to: Nobody (None) Summary: Illegal filename. Character <'> not allowed. Issue type: None Issue status: None GRASS version: None GRASS component: None Operating system: None Operating system version: GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: In winQGIS/GRASS, this problem happens for a couple of commands (but eg r.average works, see also https://svn.qgis.org/trac/ticket/736): r.median base=CEA_cat@CEA_dati cover=CEA_aspect@CEA_dati output=aspect_median Illegal filename. Character <'> not allowed. ########################## Glynn Clements answered: r.median invokes r.stats via system(), using a single quote: strcpy (command, "r.stats -a '"); strcat (command, G_fully_qualified_name (basemap, base_mapset)); strcat (command, ","); strcat (command, G_fully_qualified_name (covermap, cover_mapset)); strcat (command, "'"); /* strcpy (command,"cat /tmp/t"); */ stats_fd = popen (command, "r"); sprintf (command, "r.reclass i='%s' o='%s'", G_fully_qualified_name (basemap, base_mapset), outmap); system() uses the platform's shell: /bin/sh on Unix, cmd.exe on Windows NT/2K/XP, command.com on 95/98/ME. Single quotes won't work with the Windows shells. r.average doesn't quote the map names, and uses double quotes around the output filename: sprintf (command, "%s -anC input=%s,%s fs=space > \"%s\"", STATS, basemap->answer, covermap->answer, tempfile1); Using double quotes should suffice so long as the map name doesn't contain $ or ` (a double quote would also be problematic, but isn't legal in map names). Ultimately, we need a Windows implementation of G_spawn_ex(), so that we can avoid the shell altogether. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=446&group_id=21 From neteler at itc.it Sun Jul 15 14:45:59 2007 From: neteler at itc.it (Markus Neteler) Date: Sun Jul 15 14:46:06 2007 Subject: [GRASS-dev] [grass-code I][446] Illegal filename. Character <'> not allowed. In-Reply-To: <20070715082056.BDCD0400E3@pyrosoma.intevation.org> References: <20070715082056.BDCD0400E3@pyrosoma.intevation.org> Message-ID: <11602107.post@talk.nabble.com> For now, I have changed - r.mode - r.median - r.statistics - r.rescale.eq - r.rescale to use escaped double quotes instead of single quotes. Markus grass-codei wrote: > > code I item #446, was opened at 2007-07-15 10:20 > Status: Open > Priority: 3 > Submitted By: Markus Neteler (markusn) > Assigned to: Nobody (None) > Summary: Illegal filename. Character <'> not allowed. > Issue type: None > Issue status: None > GRASS version: None > GRASS component: None > Operating system: None > Operating system version: > GRASS CVS checkout date, if applies (YYMMDD): > > > Initial Comment: > In winQGIS/GRASS, this problem happens for a couple of commands (but eg > r.average works, see also https://svn.qgis.org/trac/ticket/736): > > r.median base=CEA_cat@CEA_dati cover=CEA_aspect@CEA_dati > output=aspect_median > Illegal filename. Character <'> not allowed. > > ########################## > Glynn Clements answered: > r.median invokes r.stats via system(), using a single quote: > > strcpy (command, "r.stats -a '"); > strcat (command, G_fully_qualified_name (basemap, base_mapset)); > strcat (command, ","); > strcat (command, G_fully_qualified_name (covermap, cover_mapset)); > strcat (command, "'"); > > /* strcpy (command,"cat /tmp/t"); */ > stats_fd = popen (command, "r"); > > sprintf (command, "r.reclass i='%s' o='%s'", > G_fully_qualified_name (basemap, base_mapset), outmap); > > system() uses the platform's shell: /bin/sh on Unix, cmd.exe on > Windows NT/2K/XP, command.com on 95/98/ME. Single quotes won't work > with the Windows shells. > > r.average doesn't quote the map names, and uses double quotes around > the output filename: > > sprintf (command, "%s -anC input=%s,%s fs=space > \"%s\"", > STATS, basemap->answer, covermap->answer, tempfile1); > > Using double quotes should suffice so long as the map name doesn't > contain $ or ` (a double quote would also be problematic, but isn't > legal in map names). > > Ultimately, we need a Windows implementation of G_spawn_ex(), so that > we can avoid the shell altogether. > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://wald.intevation.org/tracker/?func=detail&atid=204&aid=446&group_id=21 > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > > -- View this message in context: http://www.nabble.com/-grass-code-I--446--Illegal-filename.-Character-%3C%27%3E-not-allowed.-tf4081449.html#a11602107 Sent from the Grass - Dev mailing list archive at Nabble.com. From neteler at itc.it Sun Jul 15 14:55:24 2007 From: neteler at itc.it (Markus Neteler) Date: Sun Jul 15 14:55:26 2007 Subject: [GRASS-dev] r.median (non)functionality Message-ID: <11602182.post@talk.nabble.com> Trying out r.median, I discovered GRASS 6.3.cvs (spearfish60):~/ > r.median base=fields cover=soils.Kfactor output=K.by.farm.median --o 100% ERROR: Reading r.stats output I compared to r.mode: this fix seems to be necessary: --- main.c 15 Jul 2007 12:30:37 -0000 2.9 +++ main.c 15 Jul 2007 12:48:43 -0000 @@ -79,7 +79,7 @@ if (G_read_cats (covermap, cover_mapset, &cover_cats) < 0) G_fatal_error (_("Cannot read category labels of raster map <%s>"), covermap); - strcpy (command, "r.stats -a \""); + strcpy (command, "r.stats -an \""); strcat (command, G_fully_qualified_name (basemap, base_mapset)); strcat (command, ","); strcat (command, G_fully_qualified_name (covermap, cover_mapset)); Should I submit? Markus -- View this message in context: http://www.nabble.com/r.median-%28non%29functionality-tf4082074.html#a11602182 Sent from the Grass - Dev mailing list archive at Nabble.com. From glynn at gclements.plus.com Sun Jul 15 17:08:23 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jul 15 17:08:26 2007 Subject: [GRASS-dev] GRASS 6.3 on Cygwin In-Reply-To: <4698F314.9060908@ufg.uni-kiel.de> References: <4698F314.9060908@ufg.uni-kiel.de> Message-ID: <18074.14439.830886.129774@cerise.gclements.plus.com> Benjamin Ducke wrote: > Did anyone here try to get a recent version of GRASS CVS running under > Cygwin? > > I got GDAL and GRASS to compile just fine, but when I want to start ANY > GRASS module that uses the GDAL libs directly or get linked to Vlib > which in turn is linked to GDAL. > I get nothing at all. Really: nothing at all, no error message, nothing. > Just get kicked to the prompt again. --help does not provoke a reaction, > neither does any other option. It seems that the modules just die > silently. Great. This usually indicates that a DLL wasn't found. Run cygcheck on the program in question to identify the DLLs which it uses. Any DLLs need to be in the path (or in the same directory as the executable, which is probably why GDAL's own utilities work). -- Glynn Clements From glynn at gclements.plus.com Sun Jul 15 17:11:40 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jul 15 17:11:42 2007 Subject: [GRASS-dev] r.median (non)functionality In-Reply-To: <11602182.post@talk.nabble.com> References: <11602182.post@talk.nabble.com> Message-ID: <18074.14636.595454.844936@cerise.gclements.plus.com> Markus Neteler wrote: > Trying out r.median, I discovered > > GRASS 6.3.cvs (spearfish60):~/ > r.median base=fields cover=soils.Kfactor > output=K.by.farm.median --o > 100% > ERROR: Reading r.stats output > > I compared to r.mode: this fix seems to be necessary: > > --- main.c 15 Jul 2007 12:30:37 -0000 2.9 > +++ main.c 15 Jul 2007 12:48:43 -0000 > @@ -79,7 +79,7 @@ > if (G_read_cats (covermap, cover_mapset, &cover_cats) < 0) > G_fatal_error (_("Cannot read category labels of raster map <%s>"), covermap); > > - strcpy (command, "r.stats -a \""); > + strcpy (command, "r.stats -an \""); > strcat (command, G_fully_qualified_name (basemap, base_mapset)); > strcat (command, ","); > strcat (command, G_fully_qualified_name (covermap, cover_mapset)); Presumably r.median fails if you have any null cells? > Should I submit? Yes. -- Glynn Clements From neteler at itc.it Sun Jul 15 17:26:22 2007 From: neteler at itc.it (Markus Neteler) Date: Sun Jul 15 17:26:25 2007 Subject: [GRASS-dev] time to release 6.2.2 In-Reply-To: <11541249.post@talk.nabble.com> References: <20070701190509.GA28159@bartok.itc.it> <468D19AE.6050302@jemila.jazztel.es> <11455121.post@talk.nabble.com> <20070709214407.7d58fcb4.hamish_nospam@yahoo.com> <1183980079.30110.54.camel@dev64.localdomain> <11541249.post@talk.nabble.com> Message-ID: <11603233.post@talk.nabble.com> GRASS 6.2.2 release plan update: done: * The directory permission/security issue fixes are backported. * broken r.median fixed open: nothing. TODO: Review (completeness, language) http://grass.itc.it/announces/announce_grass622.html I'll package GRASS 6.2.2 today or tomorrow. Markus -- View this message in context: http://www.nabble.com/time-to-release-6.2.2-tf4008762.html#a11603233 Sent from the Grass - Dev mailing list archive at Nabble.com. From neteler at itc.it Sun Jul 15 18:02:14 2007 From: neteler at itc.it (Markus Neteler) Date: Sun Jul 15 18:02:16 2007 Subject: [GRASS-dev] r.median (non)functionality In-Reply-To: <18074.14636.595454.844936@cerise.gclements.plus.com> References: <11602182.post@talk.nabble.com> <18074.14636.595454.844936@cerise.gclements.plus.com> Message-ID: <11603531.post@talk.nabble.com> Glynn Clements wrote: > > Markus Neteler wrote: >> Trying out r.median, I discovered >> >> GRASS 6.3.cvs (spearfish60):~/ > r.median base=fields cover=soils.Kfactor >> output=K.by.farm.median --o >> 100% >> ERROR: Reading r.stats output >> >> I compared to r.mode: this fix seems to be necessary: >>... > > Presumably r.median fails if you have any null cells? > No, it continues. >> Should I submit? > > Yes. > Done. Markus -- View this message in context: http://www.nabble.com/r.median-%28non%29functionality-tf4082074.html#a11603531 Sent from the Grass - Dev mailing list archive at Nabble.com. From hamish_nospam at yahoo.com Mon Jul 16 02:16:21 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jul 16 02:16:26 2007 Subject: [GRASS-dev] GRASS 6.3 on Cygwin In-Reply-To: <18074.14439.830886.129774@cerise.gclements.plus.com> References: <4698F314.9060908@ufg.uni-kiel.de> <18074.14439.830886.129774@cerise.gclements.plus.com> Message-ID: <20070716121621.761f8232.hamish_nospam@yahoo.com> > Benjamin Ducke wrote: > > Did anyone here try to get a recent version of GRASS CVS running > > under Cygwin? > > > > I got GDAL and GRASS to compile just fine, but when I want to start > > ANY GRASS module that uses the GDAL libs directly or get linked to > > Vlib which in turn is linked to GDAL. > > I get nothing at all. Really: nothing at all, no error message, > > nothing. Just get kicked to the prompt again. --help does not > > provoke a reaction, neither does any other option. It seems that the > > modules just die silently. Great. Glynn: > This usually indicates that a DLL wasn't found. Run cygcheck on the > program in question to identify the DLLs which it uses. Any DLLs need > to be in the path (or in the same directory as the executable, which > is probably why GDAL's own utilities work). more on cygcheck and failing cygwin executables here: http://grass.ibiblio.org/grass62/binary/mswindows/#trouble Hamish From glynn at gclements.plus.com Mon Jul 16 02:30:08 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jul 16 02:30:12 2007 Subject: [GRASS-dev] GRASS 6.3 on Cygwin In-Reply-To: <50652.86.103.128.3.1184519692.squirrel@webmail.mail.uni-kiel.de> References: <4698F314.9060908@ufg.uni-kiel.de> <18074.14439.830886.129774@cerise.gclements.plus.com> <50652.86.103.128.3.1184519692.squirrel@webmail.mail.uni-kiel.de> Message-ID: <18074.48144.826962.874471@cerise.gclements.plus.com> benjamin.ducke@ufg.uni-kiel.de wrote: > Glynn and all of you interested in getting rid of the Win32 DBMI deadlock > problem, This message didn't make it to the list; I suspect that it exceeds the upper limit on the size of a message. > I have spent some time adding debugging statements to the parts that Glynn > suggested. The result is that the problem is definitely in the XDR I/O > handling. Basically, the problem is a premature EOF in DBMI driver/client > communication via piped I/O streams. > > There are just two situations where the program hangs and both of > them occur in function xdrstdio_getlong() in xdr_stdio.c (part of the SUN > RPC library). This is one of four functions in xdr_stdio.c which read and > write data from/to the DBMI client and driver streams (called STREAM1 and > STREAM2 in the debugging output) connected via the pipelines. I have added > verbose debugging statements to all four functions showing you what is > read/written, to what address in memory and the contents of that address > before and after the I/O operation. Some suggestions: 0. Separate the client/driver output; see below. 1. omit the addresses; they don't tell you anything useful, and they enlarge the output. 2. Write one record per line, with the output formatted to aligned columns; this will make it easer to read. In particular, it should make it easier to compare the client and driver logs. 3. For the get/put bytes operations, output the actual data (hex will probably be simplest and most useful). 4. Swap the 2nd and 3rd arguments (size+count) of the fread/fwrite calls; i.e. rather than reading a long as 1 4-byte record, read it as 4 1-byte records. This has the advantage that in the event of a short count, you'll find out exactly how many bytes were read. > If you take a look at the 10 logfiles that I have attached to this email, > you will see the two deadlock contexts. The more common one looks like > this: > > GETBYTES: STREAM 2 at addr (2013505168). > addr (3654160) length = 3. > stream count was: -19281 Bytes. > --> OK. > stream count is now: -19284 Bytes. > GETLONG: STREAM 2 at addr (2013505168). > put to addr (2293516); current val = 2013505200. > stream count was: -19284 Bytes. > --> FAILED: count = 0. EOF. > dbmi: Protocol error > > (the "dbmi: Protocol error" occurs after aborting with CTRL+C). > > It is always the same: some caller tries to get a long value from stream 2 > but finds the stream empty (EOF). Actually, this isn't necessarily EOF. Because you're always reading 1 record (of however many bytes), a return value of zero could mean that there were too few bytes rather than none at all. > The function xdrstdio_getlong() returns > a FALSE value in this case. But this does not seem to be handled in any > way other than sending the program to sleep. > > The other, much less frequent one looks like this: > > PUTLONG: STREAM 1 at addr (2013505200). > get from addr (2293456); current val = 0. > stream count was: 33852 Bytes. > --> OK. > new val = 2293332 written to stream. > stream count is now: 33856 Bytes. > GETLONG: STREAM 2 at addr (2013505168). > put to addr (2293568); current val = 206. > stream count was: -7448 Bytes. > --> FAILED: count = 0. EOF. > > Very similar (see log-03.txt). > > Now, I have added some debugging code to xdrprocedure.c (in GRASS > lib/db/dbmibase) > to see what the caller contexts are, but it's hard to make sense of the > output as it does not seem to be in sync with XDR I/O. It looks as if both the client and driver are logging to the same log file. AFAIK, the driver will inherit the client's stderr, so you'll end up with the client's and server's output interleaved. I suggest explicitly opening a separate log file with a unique name. Use setbuf(fp, NULL) to disable buffering, to ensure that you don't lose the tail end of the file if the process terminates abnormally. In order to understand what's going on, it's necessary to be able to match the client's writes with the driver's reads, and vice-versa. > However, if you check > the full log output, you will find always find the values "203" and "206" > in the streams which indicate that the latest callers were (see GRASS > include/dbmi.h): > > DB_PROC_FETCH 203 > DB_PROC_OPEN_SELECT_CURSOR 206 > > This corresponds to the debugging output from xdrprocedure.c. > So I also added some debug statements to c_fetch.c (in GRASS > lib/db/dbmi_client). I don't see anything obviously wrong with those procedures (at least in the case where no errors occur; if there's an error, you cannot recover from it). > Re. my debugging code: you will notice that the count for the stream size > sometimes goes < 0. I don't know if that's because I am missing some > writes or adding wrong size counts. The get operations only ever subtract from the count, while the put operations only ever add to it. IOW, the count will always be <= 0 for a read stream and >= 0 for a write stream. Each process (client, driver) has one read stream and one write stream; there are no bi-directional streams. > Anyway, I have attached the sources with my debugging codes so you can judge > for yourselves if the output makes any sense. > > Any ideas how to proceed from here? Separate the client and driver output, and re-format it as described above, so that it's straightforward to match the client's writes with the driver's reads, and vice-versa. -- Glynn Clements From neteler at itc.it Mon Jul 16 08:15:38 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Jul 16 08:15:41 2007 Subject: [GRASS-dev] GRASS 6.3 on Cygwin In-Reply-To: <18074.48144.826962.874471@cerise.gclements.plus.com> References: <4698F314.9060908@ufg.uni-kiel.de> <18074.14439.830886.129774@cerise.gclements.plus.com> <50652.86.103.128.3.1184519692.squirrel@webmail.mail.uni-kiel.de> <18074.48144.826962.874471@cerise.gclements.plus.com> Message-ID: <469B0D0A.3070607@itc.it> Glynn Clements wrote on 07/16/2007 02:30 AM: > benjamin.ducke@ufg.uni-kiel.de wrote: > >> Glynn and all of you interested in getting rid of the Win32 DBMI deadlock >> problem, >> > > This message didn't make it to the list; I suspect that it exceeds the > upper limit on the size of a message. I just checked, the message was trapped and rejected by Mailman due to its size (3.5MB!). The limit is 100kb. Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From benjamin.ducke at ufg.uni-kiel.de Mon Jul 16 10:49:00 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Mon Jul 16 10:49:36 2007 Subject: [GRASS-dev] GRASS 6.3 on Cygwin In-Reply-To: <18074.14439.830886.129774@cerise.gclements.plus.com> References: <4698F314.9060908@ufg.uni-kiel.de> <18074.14439.830886.129774@cerise.gclements.plus.com> Message-ID: <469B30FC.6030706@ufg.uni-kiel.de> Yes, that was it! Thanks a lot for the hint. Now I have a beautifully complete version of GRASS 6.3 on Cygwin running. It's a little slower than native Win, but it has complete features (except SQLite, I am still having trouble getting that to work on Cygwin). Benjamin Glynn Clements wrote: > Benjamin Ducke wrote: > >> Did anyone here try to get a recent version of GRASS CVS running under >> Cygwin? >> >> I got GDAL and GRASS to compile just fine, but when I want to start ANY >> GRASS module that uses the GDAL libs directly or get linked to Vlib >> which in turn is linked to GDAL. >> I get nothing at all. Really: nothing at all, no error message, nothing. >> Just get kicked to the prompt again. --help does not provoke a reaction, >> neither does any other option. It seems that the modules just die >> silently. Great. > > This usually indicates that a DLL wasn't found. Run cygcheck on the > program in question to identify the DLLs which it uses. Any DLLs need > to be in the path (or in the same directory as the executable, which > is probably why GDAL's own utilities work). > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From neteler at itc.it Mon Jul 16 12:06:00 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Jul 16 12:06:02 2007 Subject: [GRASS-dev] starting new GRASS session in GRASS terminal? Message-ID: <20070716100559.GF15037@bartok.itc.it> Hi, one of our students regularly launches a new GRASS session in an existing one... (they have all sorts of funky ideas) - is that harmful? I feel yes but don't really know. If yes, we should add a test to the startup script based on a GISBASE test. ? Markus From woklist at kyngchaos.com Mon Jul 16 17:53:28 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Jul 16 17:53:46 2007 Subject: [GRASS-dev] Re: [GRASS-user] ECW data In-Reply-To: <9B64C3F2-C4CA-42F7-AF7F-AA818FA0637C@telus.net> References: <965DFEF4-D515-4BEC-B683-627075BF65E1@telus.net> <9B64C3F2-C4CA-42F7-AF7F-AA818FA0637C@telus.net> Message-ID: <9D54BDE0-11DC-49F1-A4C3-1A371C3DE17E@kyngchaos.com> Well, you can try, but that's what I'm doing and then getting the problems. And, for OSX, ECW still needs a bit of patching - a fix for Mac Intel and a reversion to an earlier source and a couple other minor changes. On Jul 16, 2007, at 10:20 AM, Mars Sjoden wrote: > Just to add, > > I found this: > > http://trac.osgeo.org/gdal/wiki/ECW > > I'll give it a try. > > Mars > > > > On 16-Jul-07, at 7:59 AM, Mars Sjoden wrote: > >> Thanks William, >> >> Good to know. >> >> I'll keep digging. >> >> Mars >> >> >> On 16-Jul-07, at 7:06 AM, William Kyngesburye wrote: >> >>> Normally you would use GDAL compiled with the ECW library support. >>> >>> BUT, I can't get it to work on OSX. It always gives me invalid >>> image errors, and others have the same problem so it's not just >>> me. I've asked ERmapper (uh, Leica) about it, but they only >>> officially support 10.3.9 PPC, which is not usable on 10.4 >>> because of C++ compiler version differences. I've asked in their >>> forums for any user/programmers that could help, but no response. >>> >>> Strangely enough, GraphicConverter uses the ECW library and >>> works, I think it uses different library calls to read them. But >>> GC loses the geographic info, and it doesn't handle large files >>> very well. Because it works in GC, I also have a bug report for >>> GDAL, but also no action on it yet. >>> >>> On Jul 16, 2007, at 12:30 AM, Mars Sjoden wrote: >>> >>>> Hello, >>>> >>>> I'm just wondering what the best way to import a 3.5GB .ecw file >>>> into GRASS is? >>>> >>>> cheers, >>>> >>>> Mars >>> ----- 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 neteler at itc.it Mon Jul 16 17:57:42 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Jul 16 17:57:48 2007 Subject: [GRASS-dev] GRASS GIS 6.2.2 released Message-ID: <20070716155742.GA23636@bartok.itc.it> For Immediate Release GRASS GIS releases version 6.2.2 16 June 2007 http://grass.itc.it GRASS 6.2.2 is a new stable release which fixes several bugs discovered in the 6.2.1 source code. This release is solely for stability purposes and adds no new features. The default Graphical User Interface has been further stabilised, and the LIDAR processing tools and Linear Reference System support significantly improved. GRASS 6.2.2 also includes a number of new message translations, and updates for the help pages. The Geographic Resources Analysis Support System (GRASS) is a Geographic Information System (GIS) used for spatial modeling, visualization of both raster and vector data, geospatial data management and analysis, processing of satellite and aerial imagery, and production of sophisticated presentation graphics and hardcopy maps. GRASS combines powerful raster, vector, and geospatial processing engines into a single integrated software package. The GRASS GIS project is developed under the terms of the GNU General Public License (the GPL) by volunteers the world over. GRASS differs from many other GIS software packages used in the professional world in that it is developed and distributed by users for users, mostly on a volunteer basis, in the open, and is given away for free. Emphasis is placed on interoperability and unlimited access to data as well as on software flexibility and evolution rate. The source code is freely available allowing for immediate customization, examination of the underlying algorithms, addition of new features, and fast bug fixing. GRASS is currently used around the world in academic and commercial settings as well as by many governmental agencies and environmental consulting companies. Software download at http://grass.itc.it/download/ and numerous mirror sites. Full story at http://grass.itc.it/announces/announce_grass622.html From benjamin.ducke at ufg.uni-kiel.de Mon Jul 16 18:08:48 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Mon Jul 16 18:09:24 2007 Subject: [GRASS-dev] Win32 and bison m4sugar.m4 In-Reply-To: <20070716155742.GA23636@bartok.itc.it> References: <20070716155742.GA23636@bartok.itc.it> Message-ID: <469B9810.5040608@ufg.uni-kiel.de> http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status says: "If you get an error such as 'cannot open file `/msys/share/bison/m4sugar/m4sugar.m4': No such file or directory', one solution is to move around the msys bison installation a bit, so that m4sugar.m4 is available in the indicated path." But move it to where exactly? c:\msys\ does not work. Neither the default path c:\msys\1.0\ Thanks, Benjamin Markus Neteler wrote: > For Immediate Release > > GRASS GIS releases version 6.2.2 > 16 June 2007 > http://grass.itc.it > > GRASS 6.2.2 is a new stable release which fixes several bugs > discovered in the 6.2.1 source code. This release is solely for > stability purposes and adds no new features. The default Graphical > User Interface has been further stabilised, and the LIDAR processing > tools and Linear Reference System support significantly > improved. GRASS 6.2.2 also includes a number of new message > translations, and updates for the help pages. > > The Geographic Resources Analysis Support System (GRASS) is a > Geographic Information System (GIS) used for spatial modeling, > visualization of both raster and vector data, geospatial data > management and analysis, processing of satellite and aerial imagery, > and production of sophisticated presentation graphics and hardcopy > maps. GRASS combines powerful raster, vector, and geospatial > processing engines into a single integrated software package. > > The GRASS GIS project is developed under the terms of the GNU General > Public License (the GPL) by volunteers the world over. GRASS differs > from many other GIS software packages used in the professional world > in that it is developed and distributed by users for users, mostly on > a volunteer basis, in the open, and is given away for free. Emphasis is > placed on interoperability and unlimited access to data as well as on > software flexibility and evolution rate. The source code is freely > available allowing for immediate customization, examination of the > underlying algorithms, addition of new features, and fast bug fixing. > > GRASS is currently used around the world in academic and commercial > settings as well as by many governmental agencies and environmental > consulting companies. > > Software download at http://grass.itc.it/download/ and numerous mirror > sites. > > Full story at http://grass.itc.it/announces/announce_grass622.html > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From glynn at gclements.plus.com Mon Jul 16 18:33:38 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jul 16 18:33:41 2007 Subject: [GRASS-dev] starting new GRASS session in GRASS terminal? In-Reply-To: <20070716100559.GF15037@bartok.itc.it> References: <20070716100559.GF15037@bartok.itc.it> Message-ID: <18075.40418.993746.346536@cerise.gclements.plus.com> Markus Neteler wrote: > one of our students regularly launches a new GRASS session > in an existing one... (they have all sorts of funky ideas) - > is that harmful? I feel yes but don't really know. AFAICT, no. -- Glynn Clements From paul-grass at stjohnspoint.co.uk Mon Jul 16 19:07:29 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Jul 16 19:07:32 2007 Subject: [GRASS-dev] Win32 and bison m4sugar.m4 In-Reply-To: <469B9810.5040608@ufg.uni-kiel.de> References: <20070716155742.GA23636@bartok.itc.it> <469B9810.5040608@ufg.uni-kiel.de> Message-ID: On Mon, 16 Jul 2007, Benjamin Ducke wrote: > http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status says: > > "If you get an error such as 'cannot open file > `/msys/share/bison/m4sugar/m4sugar.m4': No such file or directory', one > solution is to move around the msys bison installation a bit, so that > m4sugar.m4 is available in the indicated path." > > But move it to where exactly? c:\msys\ does not work. Neither the I have mine in /mingw/share/bison/m4sugar/m4sugar.m4 Maybe that helps? ISTR though that there was somewhere else that we should have got bison from and that would have led to an easier install (some pre-compiled Windows binaries somewhere). Paul > default path c:\msys\1.0\ > > Thanks, > > Benjamin > > Markus Neteler wrote: >> For Immediate Release >> >> GRASS GIS releases version 6.2.2 >> 16 June 2007 >> http://grass.itc.it >> >> GRASS 6.2.2 is a new stable release which fixes several bugs >> discovered in the 6.2.1 source code. This release is solely for >> stability purposes and adds no new features. The default Graphical >> User Interface has been further stabilised, and the LIDAR processing >> tools and Linear Reference System support significantly >> improved. GRASS 6.2.2 also includes a number of new message >> translations, and updates for the help pages. >> >> The Geographic Resources Analysis Support System (GRASS) is a >> Geographic Information System (GIS) used for spatial modeling, >> visualization of both raster and vector data, geospatial data >> management and analysis, processing of satellite and aerial imagery, >> and production of sophisticated presentation graphics and hardcopy >> maps. GRASS combines powerful raster, vector, and geospatial >> processing engines into a single integrated software package. >> >> The GRASS GIS project is developed under the terms of the GNU General >> Public License (the GPL) by volunteers the world over. GRASS differs >> from many other GIS software packages used in the professional world >> in that it is developed and distributed by users for users, mostly on >> a volunteer basis, in the open, and is given away for free. Emphasis is >> placed on interoperability and unlimited access to data as well as on >> software flexibility and evolution rate. The source code is freely >> available allowing for immediate customization, examination of the >> underlying algorithms, addition of new features, and fast bug fixing. >> >> GRASS is currently used around the world in academic and commercial >> settings as well as by many governmental agencies and environmental >> consulting companies. >> >> Software download at http://grass.itc.it/download/ and numerous mirror >> sites. >> >> Full story at http://grass.itc.it/announces/announce_grass622.html >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev >> >> > > -- > Benjamin Ducke, M.A. > Arch?oinformatik > (Archaeoinformation Science) > Institut f?r Ur- und Fr?hgeschichte > (Inst. of Prehistoric and Historic Archaeology) > Christian-Albrechts-Universit?t zu Kiel > Johanna-Mestorf-Stra?e 2-6 > D 24098 Kiel > Germany > > Tel.: ++49 (0)431 880-3378 / -3379 > Fax : ++49 (0)431 880-7300 > www.uni-kiel.de/ufg > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > > From wollez at gmx.net Tue Jul 17 16:31:28 2007 From: wollez at gmx.net (WolfgangZ) Date: Tue Jul 17 16:31:58 2007 Subject: [GRASS-dev] GRASS GIS 6.2.2 released In-Reply-To: <20070716155742.GA23636__41408.2201001749$1184601486$gmane$org@bartok.itc.it> References: <20070716155742.GA23636__41408.2201001749$1184601486$gmane$org@bartok.itc.it> Message-ID: Markus Neteler schrieb: > For Immediate Release > > GRASS GIS releases version 6.2.2 > 16 June 2007 > http://grass.itc.it > > GRASS 6.2.2 is a new stable release which fixes several bugs > discovered in the 6.2.1 source code. This release is solely for > stability purposes and adds no new features. The default Graphical > User Interface has been further stabilised, and the LIDAR processing > tools and Linear Reference System support significantly > improved. GRASS 6.2.2 also includes a number of new message > translations, and updates for the help pages. > > The Geographic Resources Analysis Support System (GRASS) is a > Geographic Information System (GIS) used for spatial modeling, > visualization of both raster and vector data, geospatial data > management and analysis, processing of satellite and aerial imagery, > and production of sophisticated presentation graphics and hardcopy > maps. GRASS combines powerful raster, vector, and geospatial > processing engines into a single integrated software package. > > The GRASS GIS project is developed under the terms of the GNU General > Public License (the GPL) by volunteers the world over. GRASS differs > from many other GIS software packages used in the professional world > in that it is developed and distributed by users for users, mostly on > a volunteer basis, in the open, and is given away for free. Emphasis is > placed on interoperability and unlimited access to data as well as on > software flexibility and evolution rate. The source code is freely > available allowing for immediate customization, examination of the > underlying algorithms, addition of new features, and fast bug fixing. > > GRASS is currently used around the world in academic and commercial > settings as well as by many governmental agencies and environmental > consulting companies. > > Software download at http://grass.itc.it/download/ and numerous mirror > sites. > > Full story at http://grass.itc.it/announces/announce_grass622.html Dear Grass-Development Team, are there any plannings to release 6.2.2 also for cygwin-users? Kind regards Wolfgang From glynn at gclements.plus.com Tue Jul 17 21:08:58 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jul 17 21:09:01 2007 Subject: [GRASS-dev] GRASS GIS 6.2.2 released In-Reply-To: References: <20070716155742.GA23636__41408.2201001749$1184601486$gmane$org@bartok.itc.it> Message-ID: <18077.5066.594155.950237@cerise.gclements.plus.com> WolfgangZ wrote: > > GRASS GIS releases version 6.2.2 > are there any plannings to release 6.2.2 also for cygwin-users? I have compiled 6.2.2 on Cygwin. If someone with write access to the GRASS site wants it, contact me on IRC. -- Glynn Clements From neteler at itc.it Wed Jul 18 15:54:00 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Jul 18 15:54:03 2007 Subject: [GRASS-dev] GRASS GIS 6.2.2 released In-Reply-To: <18077.5066.594155.950237@cerise.gclements.plus.com> References: <20070716155742.GA23636@bartok.itc.it> <18077.5066.594155.950237@cerise.gclements.plus.com> Message-ID: <11669184.post@talk.nabble.com> Glynn Clements wrote: > > WolfgangZ wrote: > >> > GRASS GIS releases version 6.2.2 > >> are there any plannings to release 6.2.2 also for cygwin-users? > > I have compiled 6.2.2 on Cygwin. If someone with write access to the > GRASS site wants it, contact me on IRC. > > -- > Glynn Clements > Now available at http://grass.itc.it/grass62/binary/mswindows/ On the mirrors soon. Markus -- View this message in context: http://www.nabble.com/GRASS-GIS-6.2.2-released-tf4088443.html#a11669184 Sent from the Grass - Dev mailing list archive at Nabble.com. From hamish_nospam at yahoo.com Thu Jul 19 02:38:59 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Jul 19 02:39:46 2007 Subject: [GRASS-dev] GRASS GIS 6.2.2 released In-Reply-To: <11669184.post@talk.nabble.com> References: <20070716155742.GA23636@bartok.itc.it> <18077.5066.594155.950237@cerise.gclements.plus.com> <11669184.post@talk.nabble.com> Message-ID: <20070719123859.669738ec.hamish_nospam@yahoo.com> > Glynn Clements wrote: > > I have compiled 6.2.2 on Cygwin. If someone with write access to the > > GRASS site wants it, contact me on IRC. Markus: > Now available at > http://grass.itc.it/grass62/binary/mswindows/ > > On the mirrors soon. Is this still compiled against GDAL 1.3.1? Upstream is up to ver 1.4.2; 1.3.1 was released 4 Oct 2005. thanks, Hamish From hamish_nospam at yahoo.com Thu Jul 19 09:14:29 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Jul 19 09:14:35 2007 Subject: [GRASS-dev] ramdisk as mapset? Message-ID: <20070719191429.6d317753.hamish_nospam@yahoo.com> Hi, * I have some scripts which are very heavy on raster map disk i/o. r.cost chugs heavily on the hard drive & the script can take days to loop through. I don't want to wear a hole in it if I don't have to. * I have many GB of RAM to play with (enough to hold the region as DCELL) * The raster modules typically don't use much ram at all. (low overheads to compete with for RAM) I am trying to think of a way to get the raster ops to happen all in RAM to save time & wear on the hard drive. (script spans a number of r.* modules) ideas so far: 1) [Linux] create a 2GB ramdisk using ramfs. use g.mapset to swich into it, do the heavy i/o. switch back to the original mapset, g.copy the results map back to the "real" mapset, then destroy the ramdisk. advantages: easy to do. disadvantages: it's more of a local hack than a general solution. mkdir /mnt/ramdrive # default max_size is 1/2 physical ram, auto-resizes 'til then mount -t ramfs none /mnt/ramdrive mkdir -p /mnt/ramdrive/tmp_mapset TMP_MAPSET="/mnt/ramdrive/tmp_mapset" ln -s "$TMP_MAPSET" $USER/grassdata/$LOCATION/tmp_mapset cp $USER/grassdata/$LOCATION/$MAPSET/WIND "$TMP_MAPSET" g.mapset mapset=tmp_mapset ... g.module in=map@$MAPSET out=result ... g.mapset mapset=$MAPSET g.copy result@tmp_mapset,result umount /mnt/ramdrive problem: how to set group ID and mode/umask for ramdrive without having to do chown+chmod as root? 2) Some backgrounded "grass_mapd" process to dynamically allocate and hold a single map in memory. It's a child of the main GRASS process so exiting GRASS tears it down. It could be a "virtual" map sort of like how a reclass map is just a wrapper for something else. This is just a very rough idea, probably not so easy to do; but if possible I reckon it would be a cool tool to have. anyone have ideas? thanks, Hamish From carlos.grohmann at gmail.com Thu Jul 19 12:47:08 2007 From: carlos.grohmann at gmail.com (=?ISO-8859-1?Q?Carlos_"Gu=E2no"_Grohmann?=) Date: Thu Jul 19 12:47:12 2007 Subject: [GRASS-dev] gdal import an nodata cells Message-ID: I just imported a DEM that was sent to to in Erdas IMG format (HFA), with r.in.gdal, and after importing I had to use r.mapcalc to make the NODATA cells -- which were tagged as -32768 -- became NULL. I was just wondering if there is a way to do this automatically? can I pass the -32768 value as an option to r.in.gdal so the cell will be imported as null? cheers Carlos -- +-----------------------------------------------------------+ Carlos Henrique Grohmann - Guano Visiting Researcher at Kingston University London - UK Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - carlos dot grohmann at gmail dot com +-----------------------------------------------------------+ _________________ "Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive." --The winning entry in a "What were HAL's first words" contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke From wollez at gmx.net Thu Jul 19 13:36:28 2007 From: wollez at gmx.net (WolfgangZ) Date: Thu Jul 19 13:36:51 2007 Subject: [GRASS-dev] gdal import an nodata cells In-Reply-To: References: Message-ID: Carlos "Gu?no" Grohmann schrieb: > I just imported a DEM that was sent to to in Erdas IMG format (HFA), > with r.in.gdal, and after importing I had to use r.mapcalc to make the > NODATA cells -- which were tagged as -32768 -- became NULL. > > I was just wondering if there is a way to do this automatically? can I > pass the -32768 value as an option to r.in.gdal so the cell will be > imported as null? > > cheers > > Carlos > you can use r.null to set the null flag. From soerengebbert at gmx.de Thu Jul 19 13:42:14 2007 From: soerengebbert at gmx.de (=?iso-8859-1?Q?=22S=F6ren_Gebbert=22?=) Date: Thu Jul 19 13:42:16 2007 Subject: [GRASS-dev] ramdisk as mapset? In-Reply-To: <20070719191429.6d317753.hamish_nospam@yahoo.com> References: <20070719191429.6d317753.hamish_nospam@yahoo.com> Message-ID: <20070719114214.115700@gmx.net> Hi Hamish, interesting idea. But lets put this idea into the library of grass. :) I would like to suggest to extent the grass lib to read the entire map into the memory if needed. G_get_rast_row() will still work with no modification, but will read the rows from memory and not from the disk. And while implementing this, a tile caching mechanism would be good to. IMHO we have to add new special --flags to allow every module to use this feature. eg: --cache-all will read all tiles (in this case a tile is a row) into the memory. --cache-size-y= will set the number of rows which should be in the cache. And in case we will have "real" tile's (x,y size), we need a flag like --tile-size-x= and --tile-size-y= to set the size of each tile which should be loaded into the cache. But we need to rewrite the modules so they can benefit from this kind of tiles, because G_get_rast_row() needs extra overhead to create a single row from different tiles. IIRC that is approximately what Glynn suggested about a new implementation of the raster map storage. Just my 2 cent. S?ren btw.: A 3d tile cache mechanism is already present in the g3d lib. -------- Original-Nachricht -------- Datum: Thu, 19 Jul 2007 19:14:29 +1200 Von: Hamish An: grass5 Betreff: [GRASS-dev] ramdisk as mapset? > Hi, > > * I have some scripts which are very heavy on raster map disk i/o. > r.cost chugs heavily on the hard drive & the script can take days > to loop through. I don't want to wear a hole in it if I don't have to. > * I have many GB of RAM to play with (enough to hold the region as DCELL) > * The raster modules typically don't use much ram at all. (low overheads > to compete with for RAM) > > I am trying to think of a way to get the raster ops to happen all in RAM > to save time & wear on the hard drive. (script spans a number of r.* > modules) > > ideas so far: > > 1) [Linux] create a 2GB ramdisk using ramfs. use g.mapset to swich into > it, do the heavy i/o. switch back to the original mapset, g.copy the > results map back to the "real" mapset, then destroy the ramdisk. > advantages: easy to do. > disadvantages: it's more of a local hack than a general solution. > > mkdir /mnt/ramdrive > > # default max_size is 1/2 physical ram, auto-resizes 'til then > mount -t ramfs none /mnt/ramdrive > mkdir -p /mnt/ramdrive/tmp_mapset > TMP_MAPSET="/mnt/ramdrive/tmp_mapset" > ln -s "$TMP_MAPSET" $USER/grassdata/$LOCATION/tmp_mapset > cp $USER/grassdata/$LOCATION/$MAPSET/WIND "$TMP_MAPSET" > g.mapset mapset=tmp_mapset > ... > g.module in=map@$MAPSET out=result > ... > g.mapset mapset=$MAPSET > g.copy result@tmp_mapset,result > umount /mnt/ramdrive > > > problem: how to set group ID and mode/umask for ramdrive without > having to do chown+chmod as root? > > > 2) Some backgrounded "grass_mapd" process to dynamically allocate and > hold a single map in memory. It's a child of the main GRASS process so > exiting GRASS tears it down. It could be a "virtual" map sort of like > how a reclass map is just a wrapper for something else. This is just a > very rough idea, probably not so easy to do; but if possible I reckon it > would be a cool tool to have. > > > anyone have ideas? > > thanks, > Hamish > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From carlos.grohmann at gmail.com Thu Jul 19 13:42:45 2007 From: carlos.grohmann at gmail.com (=?ISO-8859-1?Q?Carlos_"Gu=E2no"_Grohmann?=) Date: Thu Jul 19 13:42:49 2007 Subject: [GRASS-dev] gdal import an nodata cells In-Reply-To: References: Message-ID: Yes, but I was thinking how to do this _at once_ ,in the import process. C On 7/19/07, WolfgangZ wrote: > Carlos "Gu?no" Grohmann schrieb: > > I just imported a DEM that was sent to to in Erdas IMG format (HFA), > > with r.in.gdal, and after importing I had to use r.mapcalc to make the > > NODATA cells -- which were tagged as -32768 -- became NULL. > > > > I was just wondering if there is a way to do this automatically? can I > > pass the -32768 value as an option to r.in.gdal so the cell will be > > imported as null? > > > > cheers > > > > Carlos > > > > you can use r.null to set the null flag. > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- +-----------------------------------------------------------+ Carlos Henrique Grohmann - Guano Visiting Researcher at Kingston University London - UK Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - carlos dot grohmann at gmail dot com +-----------------------------------------------------------+ _________________ "Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive." --The winning entry in a "What were HAL's first words" contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke From glynn at gclements.plus.com Thu Jul 19 18:18:57 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jul 19 18:19:00 2007 Subject: [GRASS-dev] GRASS GIS 6.2.2 released In-Reply-To: <20070719123859.669738ec.hamish_nospam@yahoo.com> References: <20070716155742.GA23636@bartok.itc.it> <18077.5066.594155.950237@cerise.gclements.plus.com> <11669184.post@talk.nabble.com> <20070719123859.669738ec.hamish_nospam@yahoo.com> Message-ID: <18079.36593.961321.49537@cerise.gclements.plus.com> Hamish wrote: > > > I have compiled 6.2.2 on Cygwin. If someone with write access to the > > > GRASS site wants it, contact me on IRC. > > > Now available at > > http://grass.itc.it/grass62/binary/mswindows/ > > > > On the mirrors soon. > > Is this still compiled against GDAL 1.3.1? It's built against 1.3.1; specifically, against the version at the above URL. If a consensus favours using a different version, I can build new GRASS binaries to use that instead, but I don't intend to build GDAL myself. -- Glynn Clements From Thomas.Adams at noaa.gov Thu Jul 19 18:20:29 2007 From: Thomas.Adams at noaa.gov (Thomas Adams) Date: Thu Jul 19 18:20:38 2007 Subject: [GRASS-dev] What is the status of F-tools for Floodplane analysis? Message-ID: <469F8F4D.8000500@noaa.gov> Can anyone tell me what is the status of F-tools for Floodplane analysis is? It may not have been updated since GRASS 4.1. It's possible I may have found someone to update this if it is not current. Regards, Tom -- Thomas E Adams National Weather Service Ohio River Forecast Center 1901 South State Route 134 Wilmington, OH 45177 EMAIL: thomas.adams@noaa.gov VOICE: 937-383-0528 FAX: 937-383-0033 From glynn at gclements.plus.com Thu Jul 19 18:33:44 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jul 19 18:33:46 2007 Subject: [GRASS-dev] ramdisk as mapset? In-Reply-To: <20070719191429.6d317753.hamish_nospam@yahoo.com> References: <20070719191429.6d317753.hamish_nospam@yahoo.com> Message-ID: <18079.37480.543762.390223@cerise.gclements.plus.com> Hamish wrote: > * I have some scripts which are very heavy on raster map disk i/o. > r.cost chugs heavily on the hard drive & the script can take days > to loop through. I don't want to wear a hole in it if I don't have to. > * I have many GB of RAM to play with (enough to hold the region as DCELL) > * The raster modules typically don't use much ram at all. (low overheads > to compete with for RAM) > > I am trying to think of a way to get the raster ops to happen all in RAM > to save time & wear on the hard drive. (script spans a number of r.* > modules) > > ideas so far: > > 1) [Linux] create a 2GB ramdisk using ramfs. use g.mapset to swich into > it, do the heavy i/o. switch back to the original mapset, g.copy the > results map back to the "real" mapset, then destroy the ramdisk. > advantages: easy to do. > disadvantages: it's more of a local hack than a general solution. It's also an inefficient use of RAM. Bear in mind that the kernel will automatically cache files; if you use them frequently enough, they'll be in RAM anyhow, and creating a RAM disk reduces the amount of RAM that the kernel can use for caching. > mkdir /mnt/ramdrive > > # default max_size is 1/2 physical ram, auto-resizes 'til then > mount -t ramfs none /mnt/ramdrive > mkdir -p /mnt/ramdrive/tmp_mapset > TMP_MAPSET="/mnt/ramdrive/tmp_mapset" > ln -s "$TMP_MAPSET" $USER/grassdata/$LOCATION/tmp_mapset > cp $USER/grassdata/$LOCATION/$MAPSET/WIND "$TMP_MAPSET" > g.mapset mapset=tmp_mapset > ... > g.module in=map@$MAPSET out=result > ... > g.mapset mapset=$MAPSET > g.copy result@tmp_mapset,result > umount /mnt/ramdrive > > problem: how to set group ID and mode/umask for ramdrive without > having to do chown+chmod as root? Mounting filesytems inevitably requires the cooperation of root. You can allow normal users to mount specific filesystems by adding them to /etc/fstab with the "user" option; you can normally set the permissions of the root directory there. > 2) Some backgrounded "grass_mapd" process to dynamically allocate and > hold a single map in memory. It's a child of the main GRASS process so > exiting GRASS tears it down. It could be a "virtual" map sort of like > how a reclass map is just a wrapper for something else. This is just a > very rough idea, probably not so easy to do; but if possible I reckon it > would be a cool tool to have. For programs which perform sequential I/O, you won't improve much on the kernel's built in caching. If you have enough RAM, it will get used. A large proportion of the overhead is in the processing which occurs between read() -> G_get_*_row() and G_put_*_row() -> write(), rather than in the "actual" I/O (i.e. read() and write()). Creating uncompressed maps would eliminate some of this; a better implementation of nulls would also help. For programs which perform random I/O (e.g. r.cost), consider replacing the use of the segment library (which is rather poorly implemented) with the segment code from r.proj.seg. -- Glynn Clements From glynn at gclements.plus.com Thu Jul 19 18:38:26 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jul 19 18:38:50 2007 Subject: [GRASS-dev] ramdisk as mapset? In-Reply-To: <20070719114214.115700@gmx.net> References: <20070719191429.6d317753.hamish_nospam@yahoo.com> <20070719114214.115700@gmx.net> Message-ID: <18079.37762.237139.886789@cerise.gclements.plus.com> "S?ren Gebbert" wrote: > interesting idea. But lets put this idea into the library of grass. :) > > I would like to suggest to extent the grass lib to > read the entire map into the memory if needed. There's no advantage if you're doing sequential I/O, which is most of GRASS. Programs which do random I/O already have mechanisms to deal with this; e.g. r.proj reads the entire useful region into memory, r.proj.seg has its own tile cache, other programs (e.g. r.cost) use the segment library. If you are concerned about efficiency, build GRASS with profiling support, and look at where the actual inefficiency lies. It would help to do the same for 4.x, as that is reported to be an order of magnitude faster than 5.x/6.x for some tasks. -- Glynn Clements From neteler at itc.it Thu Jul 19 22:51:14 2007 From: neteler at itc.it (Markus Neteler) Date: Thu Jul 19 22:51:22 2007 Subject: [GRASS-dev] r.proj.seg -> r.proj Message-ID: <11697515.post@talk.nabble.com> Hi, if there are no objections, I will retire r.proj and rename r.proj.seg -> r.proj in GRASS 6.3-CVS. The file bilinear.c still contains a "Press" reference, does it still hold true since it uses G_interp_bilinear()? Markus -- View this message in context: http://www.nabble.com/r.proj.seg--%3E-r.proj-tf4113655.html#a11697515 Sent from the Grass - Dev mailing list archive at Nabble.com. From woklist at kyngchaos.com Thu Jul 19 23:49:33 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Thu Jul 19 23:49:47 2007 Subject: [GRASS-dev] r.proj.seg -> r.proj In-Reply-To: <11697515.post@talk.nabble.com> References: <11697515.post@talk.nabble.com> Message-ID: OK by me. I was thinking of suggesting it. Been using it on OSX for huge rasters for a while with no problems (once I got a big enough HD ;) On Jul 19, 2007, at 3:51 PM, Markus Neteler wrote: > > Hi, > > if there are no objections, I will retire r.proj and > rename r.proj.seg -> r.proj in GRASS 6.3-CVS. > > The file bilinear.c still contains a "Press" reference, > does it still hold true since it uses G_interp_bilinear()? > > Markus ----- William Kyngesburye http://www.kyngchaos.com/ Earth: "Mostly harmless" - revised entry in the HitchHiker's Guide to the Galaxy From glynn at gclements.plus.com Fri Jul 20 04:16:52 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jul 20 04:16:55 2007 Subject: [GRASS-dev] r.proj.seg -> r.proj In-Reply-To: <11697515.post@talk.nabble.com> References: <11697515.post@talk.nabble.com> Message-ID: <18080.6932.904327.347804@cerise.gclements.plus.com> Markus Neteler wrote: > if there are no objections, I will retire r.proj and > rename r.proj.seg -> r.proj in GRASS 6.3-CVS. > > The file bilinear.c still contains a "Press" reference, > does it still hold true since it uses G_interp_bilinear()? No idea, but it may as well be removed. Ditto for the Richards reference in cubic.c. The G_interp_* functions were written from scratch (several modules originally had bogus gradient calculations for bicubic interpolation). There probably isn't much point referring to a source when the code wasn't written with reference to that source, even if the equations are the same (for bilinear interpolation, they're bound to be equivalent, but that isn't necessarily true for bicubic). -- Glynn Clements From neteler at itc.it Fri Jul 20 09:44:39 2007 From: neteler at itc.it (Markus Neteler) Date: Fri Jul 20 09:44:43 2007 Subject: [GRASS-dev] r.proj.seg -> r.proj In-Reply-To: <11697515.post@talk.nabble.com> References: <11697515.post@talk.nabble.com> Message-ID: <11703602.post@talk.nabble.com> Done. Old r.proj is deprecated; r.proj.seg was renamed to r.proj (in the Makefile). Markus Markus Neteler wrote: > > Hi, > > if there are no objections, I will retire r.proj and > rename r.proj.seg -> r.proj in GRASS 6.3-CVS. > > The file bilinear.c still contains a "Press" reference, > does it still hold true since it uses G_interp_bilinear()? > > Markus > -- View this message in context: http://www.nabble.com/r.proj.seg--%3E-r.proj-tf4113655.html#a11703602 Sent from the Grass - Dev mailing list archive at Nabble.com. From wichmann at laserdata.at Fri Jul 20 11:00:06 2007 From: wichmann at laserdata.at (Volker Wichmann) Date: Fri Jul 20 11:02:17 2007 Subject: [GRASS-dev] [grass-code I][431] g.copy segmentation fault In-Reply-To: <46810AD4.4080905@o2.pl> References: <20070620135314.9534A40FB3@pyrosoma.intevation.org> <46810AD4.4080905@o2.pl> Message-ID: <46A07996.7040300@laserdata.at> Hi, discussing this topic off-list it showed up that this topic is NOT solved so far. I encounter the same error with a cvs install from scratch (about 2 weeks old). I tried some debugging, that's what I found: do_copy.c (in .../general/manage/lib) seems to produce the segfault, especially the function recursive_copy. I can't catch the return value of this function as the segfault happens immediately after returning from this function. Within recursive_copy the /* src is a file */ section is entered, and all "if" queries and "while" loops are simply passed. The variables that get set have the following values: fd = 3 fd2 = 4 len = 0 Any ideas? Thanks, Volker Maciej Sieczka wrote: >> example >> g.copy rast=objekthoehen20,muell10 >> Copy raster to current mapset as >> Speicherzugriffsfehler >> > > It showed to be problem due to two conflicting GRASS 6.3 instalations. > Case closed. > > Maciek > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From dfinlayson at usgs.gov Fri Jul 20 22:09:55 2007 From: dfinlayson at usgs.gov (David Finlayson) Date: Fri Jul 20 22:09:57 2007 Subject: [GRASS-dev] ramdisk as mapset? In-Reply-To: <18079.37762.237139.886789@cerise.gclements.plus.com> References: <20070719191429.6d317753.hamish_nospam@yahoo.com> <20070719114214.115700@gmx.net> <18079.37762.237139.886789@cerise.gclements.plus.com> Message-ID: What about running GRASS in something like Xgrid or Grid Engine? I am about to purchase a cluster of Mac Pros for filtering and rendering sonar data and I have been curious what has been done to parallelize GRASS buy enterprising people. Grass isn't threaded so it might work well on a cluster if you can keep the nodes fed with data. Maybe some Franken-script could divide the raster data into segments and launch a node on each segment. I read a paper recently that documented using GRASS on GeoWalls via a series of shell scripts that controlled the batch processing, but I haven't looked into it in detail and can't remember the authors off the top of my head. Our data sets are toping 100 million points a piece and I am looking for ways to divide and conquer the work load. Currently, I use GMT across 8 nodes and it works well (if a bit clunky as far as job management goes). David On 7/19/07, Glynn Clements wrote: > > "S?ren Gebbert" wrote: > > > interesting idea. But lets put this idea into the library of grass. :) > > > > I would like to suggest to extent the grass lib to > > read the entire map into the memory if needed. > > There's no advantage if you're doing sequential I/O, which is most of > GRASS. > > Programs which do random I/O already have mechanisms to deal with > this; e.g. r.proj reads the entire useful region into memory, > r.proj.seg has its own tile cache, other programs (e.g. r.cost) use > the segment library. > > If you are concerned about efficiency, build GRASS with profiling > support, and look at where the actual inefficiency lies. It would help > to do the same for 4.x, as that is reported to be an order of > magnitude faster than 5.x/6.x for some tasks. > > -- > Glynn Clements > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- David Finlayson, Ph.D. Operational Geologist U.S. Geological Survey Pacific Science Center 400 Natural Bridges Drive Santa Cruz, CA 95060, USA Tel: 831-427-4757, Fax: 831-427-4748, E-mail: dfinlayson@usgs.gov From qba at sztormik.com Sat Jul 21 20:24:41 2007 From: qba at sztormik.com (Jakub Kulczynski) Date: Sat Jul 21 20:24:54 2007 Subject: [GRASS-dev] ramdisk as mapset? In-Reply-To: <20070719191429.6d317753.hamish_nospam@yahoo.com> References: <20070719191429.6d317753.hamish_nospam@yahoo.com> Message-ID: On 2007-07-19, at 09:14, Hamish wrote: > ideas so far: > 1) [Linux] create a 2GB ramdisk using ramfs. use g.mapset to swich > into > it, do the heavy i/o. switch back to the original mapset, g.copy the > results map back to the "real" mapset, then destroy the ramdisk. > advantages: easy to do. > disadvantages: it's more of a local hack than a general solution. [...] > problem: how to set group ID and mode/umask for ramdrive without > having to do chown+chmod as root? You can't. Well actually you could use sudo (preferably with nopasswd option) to chown+chmod the dir. Apart from that I'd suggest using something from BSD family, but that's not that important :) You'll get a great speed boost - the problem with a lot of disk I/O operations isn't about caching (you could probably increase the cache size, but that's not it) but I/Os themselves. RAMdrive gets rid of this problem :) Tested and working great (not with GRASS though :) ) regards -------------- następna czę¶ć --------- Zał±cznik, który nie był tekstem został usunięty... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070721/ad94f484/PGP.bin From wichmann at laserdata.at Mon Jul 23 08:40:51 2007 From: wichmann at laserdata.at (Volker Wichmann) Date: Mon Jul 23 08:42:45 2007 Subject: [GRASS-dev] [grass-code I][431] g.copy segmentation fault In-Reply-To: <46A07996.7040300@laserdata.at> References: <20070620135314.9534A40FB3@pyrosoma.intevation.org> <46810AD4.4080905@o2.pl> <46A07996.7040300@laserdata.at> Message-ID: <46A44D73.9050908@laserdata.at> Digging a little deeper, I found that the return values of the two 'open' commands (variables fd and fd2) are reasonable - but what about the return value of the read command (line 146, do_copy.c): len = read(fd, buf, 1024) Why is a 0 returned at the first call - my dataset is a valid raster, so why an EOF before reading anything? Maybe this is an issue of file permission? Any help is appreciated! Thanks, Volker Volker Wichmann wrote: > Hi, > > discussing this topic off-list it showed up that this topic is NOT > solved so far. I encounter the same error with a cvs install from > scratch (about 2 weeks old). > > I tried some debugging, that's what I found: > do_copy.c (in .../general/manage/lib) seems to produce the segfault, > especially the function recursive_copy. I can't catch the return value > of this function as the segfault happens immediately after returning > from this function. > Within recursive_copy the /* src is a file */ section is entered, and > all "if" queries and "while" loops are simply passed. The variables > that get set have the following values: > fd = 3 > fd2 = 4 > len = 0 > > Any ideas? > Thanks, > Volker > > Maciej Sieczka wrote: >>> example >>> g.copy rast=objekthoehen20,muell10 >>> Copy raster to current mapset as >>> Speicherzugriffsfehler >>> >> >> It showed to be problem due to two conflicting GRASS 6.3 instalations. >> Case closed. >> >> Maciek >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev >> > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From hamish_nospam at yahoo.com Mon Jul 23 09:12:46 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jul 23 09:13:01 2007 Subject: [GRASS-dev] mutli-core GRASS [was: ramdisk as mapset?] In-Reply-To: <18079.37480.543762.390223@cerise.gclements.plus.com> References: <20070719191429.6d317753.hamish_nospam@yahoo.com> <18079.37480.543762.390223@cerise.gclements.plus.com> Message-ID: <20070723191246.4a6a6cdf.hamish_nospam@yahoo.com> > Hamish wrote: > > * I have some scripts which are very heavy on raster map disk i/o. > > r.cost chugs heavily on the hard drive & the script can take days > > to loop through. I don't want to wear a hole in it if I don't > > have to. .. > > I am trying to think of a way to get the raster ops to happen all in > > RAM .. > > 1) [Linux] create a 2GB ramdisk using ramfs. use g.mapset to swich > > into it, do the heavy i/o. .. Glynn: > It's also an inefficient use of RAM. Bear in mind that the kernel will > automatically cache files; if you use them frequently enough, they'll > be in RAM anyhow, and creating a RAM disk reduces the amount of RAM > that the kernel can use for caching. True. I could do (pseudo) `cat -r $MAPSET/*`, but that's no faster than just letting the kernel do it itself as it happens. the ramdisk helps train the caching ahead of time. next time I do a big r.cost loop I might experiment with this and see how much of a difference it makes. Hamish: > > problem: how to set group ID and mode/umask for ramdrive without > > having to do chown+chmod as root? Jakub Kulczynski wrote: > You can't. Well actually you could use sudo (preferably with nopasswd > option) to chown+chmod the dir. Ok. I now see the `mount` man page says that ramfs has no mount options. (slightly older 2.4 kernel + gnu) I did try setting in fstab; was ignored. Glynn: > For programs which perform random I/O (e.g. r.cost), consider > replacing the use of the segment library (which is rather poorly > implemented) with the segment code from r.proj.seg. This is the heart of my wish really. The ramfs stuff is just a workaround for that issue. Dylan wrote: > I am about to purchase a cluster of Mac Pros for filtering and > rendering sonar data and I have been curious what has been done to > parallelize GRASS buy enterprising people. Q: is the GRASS segmentation process inherently thread-friendly? (I mean theoretically, not as written) ie if the segmentation library was rewritten to be better, could it use some sort of n_proc value set at compile time, (or (better) a gis var set with g.gisenv, or even a shell enviro var) to determine how many simultaneous processes to run at once? Given our manpower, the best way I see to get GRASS more multi-core and multi-processor ready is a piecemeal approach, starting will the low- hanging fruit / biggest bang-for-buck libraries. Simultaneously we can gradually remove as many global variables as possible from the libs. I wonder if Thiery has any thoughts here, as he is probably in a better position to fundamentally & quickly rework the architecture than we are. (ie less baggage to worry about) I think it is very safe to say that for the next decade or so multi-core scaling is going to be the future of number crunching. Eventually new paradigms and languages will arrive, but for now we have to fight with making our serial languages thread-safe.... some sort of plan of action, in order of priority: 1) [if plausible] Make the segment lib multi-proc'able. If it's currently crappy, then all the more reason to start rewrites here. 2) Work on quad-tree stuff (v.surf.*, r.terraflow) individually (???) 3) Create new row-by-row libgis fns and start migrating r.modules, 1 by 1. (what would the module logic look like instead of two for loops?) 4) I don't know, but suspect, MPIing vector ops will be much much harder. After the segment lib & one-offs, the next big multi-proc task I see is the row-by-row raster ops. This of course means replacing G_{get|put}_*_row() in the raster modules with a more abstract method. Then, in some new libgis fn, splitting the map up into n_proc parts and applying the operation to each. Worry about multi-row r.neighbors etc later? This is getting near to writing r.mapcalc as a lib fn. (!) I wonder if the python-C SWIG interface helps with prototyping? Then slowly move as many of the 150 raster modules to the new MPI-aware lib fns as are suited for it, one by one. Again I think the low-hanging fruit will be obvious and the most important modules (r.mapcalc, r.cost) will be taken care of first, and the lesser used raster modules on a needs basis by contributors. (as long as we offer a clean API method) I've read that "n" in 'make -j n' should be n_procs + 1. Is that just true for quick little processes where you always want a job ready at the door and there's a lot of overhead creating & destroying the process? thoughts? Hamish From hamish_nospam at yahoo.com Mon Jul 23 09:41:49 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jul 23 09:42:23 2007 Subject: [GRASS-dev] ramdisk as mapset? In-Reply-To: <18079.37762.237139.886789@cerise.gclements.plus.com> References: <20070719191429.6d317753.hamish_nospam@yahoo.com> <20070719114214.115700@gmx.net> <18079.37762.237139.886789@cerise.gclements.plus.com> Message-ID: <20070723194149.6b12b957.hamish_nospam@yahoo.com> Glynn Clements wrote: > > If you are concerned about efficiency, build GRASS with profiling > support, and look at where the actual inefficiency lies. It would help > to do the same for 4.x, as that is reported to be an order of > magnitude faster than 5.x/6.x for some tasks. Could you suggest a quick usage guide as to how to do that? What's the best tool? * 'gcc -pg' + gprof? * valgrind's calltree -> kcachegrind? (calltree doesn't need a special recompile) How to look at the output? Preferably compose directly to one of the wiki pages: (or make a new one) http://grass.gdf-hannover.de/wiki/GRASS_Debugging http://grass.gdf-hannover.de/wiki/Development thanks, Hamish From neteler at itc.it Mon Jul 23 11:49:03 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Jul 23 11:49:04 2007 Subject: [GRASS-dev] GRASS 6.3-CVS: EPSG updated to V6.13 Message-ID: <20070723094903.GA9805@bartok.itc.it> Hi, following GDAL, I have updated the CSV files in lib/proj/ to EPSG 6.13. As always, the files are taken from GDAL-SVN-HEAD. There are two new files - gcs.override.csv - pcs.override.csv which fix a couple of entries. Markus From hamish_nospam at yahoo.com Mon Jul 23 11:54:57 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jul 23 11:55:05 2007 Subject: [GRASS-dev] Re: [GRASS-user] db.in.ogr [was dbf File not being Created with v.in.ascii] In-Reply-To: <46A45C8A.8000403@itc.it> References: <72fc09510707222240i26ac013dvb10081d97c2d7591@mail.gmail.com> <46A45C8A.8000403@itc.it> Message-ID: <20070723215457.713ac966.hamish_nospam@yahoo.com> Markus Neteler wrote: > > PS: Unrelated - for table only input I have added 'db.in.ogr' to GRASS > 6.3-CVS which imports DBF, CSV etc. v.in.garmin: # "COPY table FROM 'filename.txt'" does not work for DBF and there is no # db.in.ascii yet, so we use a hack... Is db.in.ogr the solution? Hamish From neteler at itc.it Mon Jul 23 13:41:52 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Jul 23 13:41:54 2007 Subject: [GRASS-dev] Re: [GRASS-user] db.in.ogr In-Reply-To: <20070723215457.713ac966.hamish_nospam@yahoo.com> References: <72fc09510707222240i26ac013dvb10081d97c2d7591@mail.gmail.com> <46A45C8A.8000403@itc.it> <20070723215457.713ac966.hamish_nospam@yahoo.com> Message-ID: <46A49400.2030409@itc.it> Hamish wrote on 07/23/2007 11:54 AM: > Markus Neteler wrote: > >> PS: Unrelated - for table only input I have added 'db.in.ogr' to GRASS >> 6.3-CVS which imports DBF, CSV etc. >> > > v.in.garmin: > # "COPY table FROM 'filename.txt'" does not work for DBF and there is no > # db.in.ascii yet, so we use a hack... > > > Is db.in.ogr the solution? > Yes, I think so. It reads CSV, but it must be comma separated. Best read with .csvt file, see http://www.gdal.org/ogr/drv_csv.html "Limited type recognition can be done for Integer, Real and String columns through a descriptive file with same name as the CSV file, but .csvt extension. In a single line the types for each column have to be listed: double quoted and comma separated (e.g., "Integer","String"). The driver will then use these types as specified for the csv columns. " Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From soerengebbert at gmx.de Mon Jul 23 18:27:03 2007 From: soerengebbert at gmx.de (Soeren Gebbert) Date: Mon Jul 23 18:17:10 2007 Subject: [GRASS-dev] mutli-core GRASS [was: ramdisk as mapset?] In-Reply-To: <20070723191246.4a6a6cdf.hamish_nospam@yahoo.com> References: <20070719191429.6d317753.hamish_nospam@yahoo.com> <18079.37480.543762.390223@cerise.gclements.plus.com> <20070723191246.4a6a6cdf.hamish_nospam@yahoo.com> Message-ID: <200707231827.04408.soerengebbert@gmx.de> Hi, > > Dylan wrote: > > I am about to purchase a cluster of Mac Pros for filtering and > > rendering sonar data and I have been curious what has been done to > > parallelize GRASS buy enterprising people. > > Q: is the GRASS segmentation process inherently thread-friendly? > (I mean theoretically, not as written) Code which should run on a cluster must not be thread safe, unless you are using a single system image (SSI) linux with distributed thread support (SGI Altix series). Most cluster do not support thread spreading to different cluster nodes (the network connection is in most cases the limiting factor -> exception: take a look at numa links from SGI). I prefer threaded parallelism, because it is easier to implement and we do not need to handle with message passing overhead. But this code will not run on a cluster (unless you use OpenMP and the Intel OpenMP on Cluster compiler extension). > ie if the segmentation library was rewritten to be better, could it use > some sort of n_proc value set at compile time, (or (better) a gis var > set with g.gisenv, or even a shell enviro var) to determine how many > simultaneous processes to run at once? A variable would be the best. The gpde library uses OpenMP to run some tasks in parallel. The number of threads can be controlled via the environment variable OMP_NUM_THREADS. But why multi-threading the segment library? IMHO it is currently not useful to mult-thread io operations. IO is mostly serial (except cluster fs). > Given our manpower, the best way I see to get GRASS more multi-core and > multi-processor ready is a piecemeal approach, starting will the low- > hanging fruit / biggest bang-for-buck libraries. Simultaneously we can > gradually remove as many global variables as possible from the libs. I currently design the N_array stuff within the gpde library from scratch to support multi threaded processing of raster and volume data loaded into the memory. For now some higher level array functions are implemented which are using OpenMP to speed up some tasks. The current N_array implementation only support the 3 data types of grass and is not designed for performance, but for easy usage. This may change in the future. Future task are: * Use a more abstact approach for the N_array struct handling ** 1d, 2d and 3d arrays should be managed as one structure ** Use function pointer and member functions for a more OO like approach ** A flag decides the type of the array -> easy conversion of 1d into 2d or 3d arrays ** the access member function will be set while allocating an array eg: 1d array: double array_1d->get_d_value(array_1d, col); 2d array: double array_2d->get_d_value(array_2d, col, row); 3d array: double array_3d->get_d_value(array_3d, col, row, depth); and so on ... ** support for data references in the internal data structure eg: setting an already allocated raster row buffer as data pointer for an 1d array, in case the array is deleted (free) the buffer will not be freed * Implement new data types into the N_array library ** unsigned char, signed char, unsigned short, signed short, unsigned int, signed int, float, double * create a more abstact interface to 2d and 3d raster data ** implementation of so called "data sources" in 2d and 3d ** data sources will have member functions to access the raster and volume data eg: double data_source_2d->get_d_value(data_source_2d, col, row); N_array * data_source_2d->get_row(data_source_2d, row); N_array * data_source_3d->get_tile(data_source_3d, x, y, z); and so on * High level functions like: ** array copy; statistic calculation of an array (mean, max, min, ...); sorting, basic mathematical tasks like array substraction, addition, multiplication, division, modulo and so on should be implemented multi threaded (take a look at N_arrays_calc.c for current implementations) ** Neighbourhood searching routines should be implemented using N_arrays eg: N_array * array_2d->get_neighbours(array_2d, row, col, size) Some of these functionality are already implemented and tested in the gpde lib. > I wonder if Thiery has any thoughts here, as he is probably in a better > position to fundamentally & quickly rework the architecture than we are. > (ie less baggage to worry about) I think it is very safe to say that for > the next decade or so multi-core scaling is going to be the future of > number crunching. Eventually new paradigms and languages will arrive, but > for now we have to fight with making our serial languages thread-safe.... Indeed. > > > some sort of plan of action, in order of priority: > 1) [if plausible] Make the segment lib multi-proc'able. If it's currently > crappy, then all the more reason to start rewrites here. > 2) Work on quad-tree stuff (v.surf.*, r.terraflow) individually (???) AFAIC the quad-tree stuff implemented in v.surf.rst is not usable for raster data storage or handling. > 3) Create new row-by-row libgis fns and start migrating r.modules, 1 by 1. > (what would the module logic look like instead of two for loops?) > 4) I don't know, but suspect, MPIing vector ops will be much much harder. > > > After the segment lib & one-offs, the next big multi-proc task I see is > the row-by-row raster ops. This of course means replacing > G_{get|put}_*_row() in the raster modules with a more abstract method. I would like to suggest to implement the raster row and tile handling in a new library called Gdata_ which should implement the functionality i explained above. The abstact Gdata interface should be able to handle different storage implementations (current raster storage, segemt and rowio lib, an interface to gdal, g3d lib ...) with the data_source approach. > Then, in some new libgis fn, splitting the map up into n_proc parts and > applying the operation to each. Worry about multi-row r.neighbors etc > later? This is getting near to writing r.mapcalc as a lib fn. (!) Indeed. Best regards Soeren > I wonder if the python-C SWIG interface helps with prototyping? > Then slowly move as many of the 150 raster modules to the new MPI-aware > lib fns as are suited for it, one by one. Again I think the low-hanging > fruit will be obvious and the most important modules (r.mapcalc, r.cost) > will be taken care of first, and the lesser used raster modules on a needs > basis by contributors. (as long as we offer a clean API method) > > > I've read that "n" in 'make -j n' should be n_procs + 1. Is that just > true for quick little processes where you always want a job ready at the > door and there's a lot of overhead creating & destroying the process? > > > > thoughts? > Hamish > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From glynn at gclements.plus.com Mon Jul 23 18:34:39 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jul 23 18:34:42 2007 Subject: [GRASS-dev] [grass-code I][431] g.copy segmentation fault In-Reply-To: <46A44D73.9050908@laserdata.at> References: <20070620135314.9534A40FB3@pyrosoma.intevation.org> <46810AD4.4080905@o2.pl> <46A07996.7040300@laserdata.at> <46A44D73.9050908@laserdata.at> Message-ID: <18084.55455.521934.169287@cerise.gclements.plus.com> Volker Wichmann wrote: > Digging a little deeper, I found that the return values of the two > 'open' commands (variables fd and fd2) are reasonable - but what about > the return value of the read command (line 146, do_copy.c): > len = read(fd, buf, 1024) > Why is a 0 returned at the first call - my dataset is a valid raster, so > why an EOF before reading anything? Some of the files comprising the map may be empty, e.g. FP maps have an empty "cell" file (the actual data is in the "fcell" file). > Maybe this is an issue of file permission? If you don't have the necessary permissions, the open() call will fail; read() and write() can't fail due to permissions. -- Glynn Clements From glynn at gclements.plus.com Mon Jul 23 18:49:07 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jul 23 18:49:10 2007 Subject: [GRASS-dev] ramdisk as mapset? In-Reply-To: <20070723194149.6b12b957.hamish_nospam@yahoo.com> References: <20070719191429.6d317753.hamish_nospam@yahoo.com> <20070719114214.115700@gmx.net> <18079.37762.237139.886789@cerise.gclements.plus.com> <20070723194149.6b12b957.hamish_nospam@yahoo.com> Message-ID: <18084.56323.151795.156604@cerise.gclements.plus.com> Hamish wrote: > > If you are concerned about efficiency, build GRASS with profiling > > support, and look at where the actual inefficiency lies. It would help > > to do the same for 4.x, as that is reported to be an order of > > magnitude faster than 5.x/6.x for some tasks. > > Could you suggest a quick usage guide as to how to do that? > What's the best tool? > * 'gcc -pg' + gprof? > * valgrind's calltree -> kcachegrind? > (calltree doesn't need a special recompile) I trust gcc/gprof more than valgrind, particularly where most of the CPU time is in "leaf" functions (i.e. the module making many calls to trivial functions in shared libraries, e.g. G_is_?_null_value()). However, it's harder to use, and can't trace into shared libraries (or any libraries built without profiling support), so you have to build GRASS with --disable-shared. -- Glynn Clements From glynn at gclements.plus.com Mon Jul 23 19:23:48 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jul 23 19:23:52 2007 Subject: [GRASS-dev] mutli-core GRASS [was: ramdisk as mapset?] In-Reply-To: <20070723191246.4a6a6cdf.hamish_nospam@yahoo.com> References: <20070719191429.6d317753.hamish_nospam@yahoo.com> <18079.37480.543762.390223@cerise.gclements.plus.com> <20070723191246.4a6a6cdf.hamish_nospam@yahoo.com> Message-ID: <18084.58404.700303.499935@cerise.gclements.plus.com> Hamish wrote: > > I am about to purchase a cluster of Mac Pros for filtering and > > rendering sonar data and I have been curious what has been done to > > parallelize GRASS buy enterprising people. > > Q: is the GRASS segmentation process inherently thread-friendly? > (I mean theoretically, not as written) > > ie if the segmentation library was rewritten to be better, could it use > some sort of n_proc value set at compile time, (or (better) a gis var > set with g.gisenv, or even a shell enviro var) to determine how many > simultaneous processes to run at once? No. You can't avoid modifying code. > Given our manpower, the best way I see to get GRASS more multi-core and > multi-processor ready is a piecemeal approach, starting will the low- > hanging fruit / biggest bang-for-buck libraries. Simultaneously we can > gradually remove as many global variables as possible from the libs. It isn't just global variables (although those are a major issue, not just for threading). For most applications, you would want to be able to have multiple threads reading/writing the input/output maps, so the issue also applies to the fields of "struct fileinfo". > I wonder if Thiery has any thoughts here, as he is probably in a better > position to fundamentally & quickly rework the architecture than we are. > (ie less baggage to worry about) I think it is very safe to say that for > the next decade or so multi-core scaling is going to be the future of > number crunching. Eventually new paradigms and languages will arrive, but > for now we have to fight with making our serial languages thread-safe.... > > some sort of plan of action, in order of priority: > 1) [if plausible] Make the segment lib multi-proc'able. If it's currently > crappy, then all the more reason to start rewrites here. The segment library isn't really helpful here. It's essentially just a home-grown virtual memory system. AFAICT, the only advantage over the OS' virtual memory is that you aren't limited to (at most) 4GiB on a 32-bit system. On a 64-bit system, you may as well just read the entire map into (virtual) memory. BTW, unless the module explicitly opens the segment file in 64-bit mode (LFS), it will hit the 2GiB file limit. Many systems have more than 2GiB of RAM, so using the segment library may actually reduce the maximum size of a map compared to just reading it into memory. > 2) Work on quad-tree stuff (v.surf.*, r.terraflow) individually (???) > 3) Create new row-by-row libgis fns and start migrating r.modules, 1 by 1. > (what would the module logic look like instead of two for loops?) If the complexity is in the algorithm, then there's no alternative to restructuring the code. Obviously, this requires that the algorithm is actually parallelisable. There are a few things which can be done in libraries, e.g. using separate threads for {get,put}_row operations, so that the actual algorithm gets a complete CPU core to itself. As for parallelising individual modules, r.mapcalc would be an obvious priority. It's current structure isn't conducive to that (the buffers are stored in the expression nodes), but that isn't too hard to change. There's still the issue that the {get,put}_row operations have to be serialised, so you won't be able to process data faster than a single core can read/write a map. Still, for complex calculations, it might be worth the effort. > 4) I don't know, but suspect, MPIing vector ops will be much much harder. The main issue is likely to be the difficulty of making the output operations thread-safe. Making read operations thread-safe is usually simple (if you have a read "cursor", that needs to be updated atomically). > After the segment lib & one-offs, the next big multi-proc task I see is > the row-by-row raster ops. This of course means replacing > G_{get|put}_*_row() in the raster modules with a more abstract method. > Then, in some new libgis fn, splitting the map up into n_proc parts and > applying the operation to each. Worry about multi-row r.neighbors etc > later? This is getting near to writing r.mapcalc as a lib fn. (!) Most "filters" can be parallelised easily enough. This includes those which need a "window", e.g. r.neighbors; it doesn't matter if multiple threads are reading the same row. You do need to make the rowio window large enough to account for the number of active threads (e.g. if you have 4 threads and a 5x5 window, you need at least 2+4+2 = 8 rows). The main issue is that the core raster I/O needs to be made thread-safe, including multiple threads using a single map. That means either replacing the {work,null,mask,temp,compressed}_buf fields in the fileinfo structure with an array of such buffers (one per thread), or using automatic buffers (i.e. alloca(); does any supported platform not provide this?). -- Glynn Clements From wichmann at laserdata.at Tue Jul 24 14:54:00 2007 From: wichmann at laserdata.at (Volker Wichmann) Date: Tue Jul 24 14:56:01 2007 Subject: [GRASS-dev] [grass-code I][431] g.copy segmentation fault In-Reply-To: <18084.55455.521934.169287@cerise.gclements.plus.com> References: <20070620135314.9534A40FB3@pyrosoma.intevation.org> <46810AD4.4080905@o2.pl> <46A07996.7040300@laserdata.at> <46A44D73.9050908@laserdata.at> <18084.55455.521934.169287@cerise.gclements.plus.com> Message-ID: <46A5F668.1000903@laserdata.at> Glynn Clements wrote: > Volker Wichmann wrote: > > >> Digging a little deeper, I found that the return values of the two >> 'open' commands (variables fd and fd2) are reasonable - but what about >> the return value of the read command (line 146, do_copy.c): >> len = read(fd, buf, 1024) >> Why is a 0 returned at the first call - my dataset is a valid raster, so >> why an EOF before reading anything? >> > > Some of the files comprising the map may be empty, e.g. FP maps have > an empty "cell" file (the actual data is in the "fcell" file). > > ok, thanks for that hint. I was indeed using a FP map ... trying to copy a map of type CELL reads and writes the map until EOF but the segmentation fault on return remains. Capturing the return value I sometimes get a corrupted output (e.g. ?? ???????? ???????? ??u?????? ???? ??u??????) in other cases I get none before the seg fault. I get these results on Fedora 6 and 7 installs from scratch. I know of others having the same problem (using Fedora 6) that they use a g.copy version from 6.2 as a workaround. I had a look at the diffs but didn't find anything I would put the blame on. Any help is appreciated, thanks, Volker By the way, trying to display the copied/corrupted map I get the following errors: WARNING: Can't open header file for [test@PERMANENT in PERMANENT] WARNING: category support for [test@PERMANENT] in mapset [PERMANENT] missing WARNING: can't get history information for [test@PERMANENT] in mapset [PERMANENT] WARNING: can't read range file for [test@PERMANENT in PERMANENT] ERROR: Unable to read range file ... but I have to remove the map before each new debug attempt as g.copy states the map is already in existence >> Maybe this is an issue of file permission? >> > > If you don't have the necessary permissions, the open() call will > fail; read() and write() can't fail due to permissions. > > From glynn at gclements.plus.com Tue Jul 24 21:52:26 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jul 24 21:52:30 2007 Subject: [GRASS-dev] Re: [GRASS-user] g.list pager In-Reply-To: <20070724151926.16a54bc7.hamish_nospam@yahoo.com> References: <20070724151926.16a54bc7.hamish_nospam@yahoo.com> Message-ID: <18086.22650.532856.625093@cerise.gclements.plus.com> [CC to grass-dev] Hamish wrote: > > > I recall that some time ago, when I issued "g.list rast" I would get > > > the list of rasters and the command prompt right after it. Now, when > > > I run the command I get the raster list and no command prompt. I > > > have to hit q to get back to the prompt and the raster list is gone, > > > just like when reading a man page. I tried to change GRASS_PAGER env > > > to more, cat but nothing happened. What am I doing wrong? I'm using > > > Debian > > Paul Kelly wrote: > > Yes, setting GRASS_PAGER to cat should give you the behaviour you > > describe, I think. Are you sure it was set properly? > > Debian packaging rules state that the default pager will be 'less', not > GRASS's default of 'more'. IMHO, the default value of GRASS_PAGER ought to be $PAGER, if that is set. > My personal preference is if not using 'more' > then use 'cat' or rip out the pager code all together. Some people might actually need the pager, so I wouldn't recommend removeing the code. Those who don't want a pager can always use GRASS_PAGER=cat (as I do). > > Funny thing is that the pager is set correctly at the .grassrc6 file > > but grass ignores it. Will have to put it on bashrc > > .grassrc6 is not what you expect. It holds the g.gisenv GIS variables, > it's not a shell script containing commands like .bashrc is. We should change the name for 7.x. It isn't an "rc" file in the conventional sense. > Use .grass.bashrc for setting shell enviro variables instead. (or .bashrc) Note that ~/.grass.bashrc only affects the interactive shell which is spawned from Init.sh; it doesn't affect the operation of Init.sh itself. For that, use ~/.bashrc (or similar). It might be worth having a separate rc file which is sourced from the top of Init.sh. Also, on the subject of potential Init.sh changes, I'd suggest getting rid of the $HOME "games" and just setting HISTFILE to put the history file in the mapset directory (AFAICT, that is the primary purpose of the $HOME stuff). -- Glynn Clements From glynn at gclements.plus.com Tue Jul 24 21:56:08 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jul 24 21:56:11 2007 Subject: [GRASS-dev] [grass-code I][431] g.copy segmentation fault In-Reply-To: <46A5F668.1000903@laserdata.at> References: <20070620135314.9534A40FB3@pyrosoma.intevation.org> <46810AD4.4080905@o2.pl> <46A07996.7040300@laserdata.at> <46A44D73.9050908@laserdata.at> <18084.55455.521934.169287@cerise.gclements.plus.com> <46A5F668.1000903@laserdata.at> Message-ID: <18086.22872.250450.40350@cerise.gclements.plus.com> Volker Wichmann wrote: > >> Digging a little deeper, I found that the return values of the two > >> 'open' commands (variables fd and fd2) are reasonable - but what about > >> the return value of the read command (line 146, do_copy.c): > >> len = read(fd, buf, 1024) > >> Why is a 0 returned at the first call - my dataset is a valid raster, so > >> why an EOF before reading anything? > >> > > > > Some of the files comprising the map may be empty, e.g. FP maps have > > an empty "cell" file (the actual data is in the "fcell" file). > > ok, thanks for that hint. I was indeed using a FP map ... > trying to copy a map of type CELL reads and writes the map until EOF but > the segmentation fault on return remains. Capturing the return value I > sometimes get a corrupted output (e.g. $(0!;!;(B$(0!;!;(B$(0!;!;!;!;(B$(0!;!;(B$(0!;!;(B$(0!;!;!;!;(B$(0!;!;(B$(0!;!;(Bu$(0!;!;!;!;(B?-BČ-A > $(0!;!;(B$(0!;!;(B$(0!;!;(Bu$(0!;!;!;!;(B?-BČ) in other cases I get none before the seg fault.-A You will need to provide more detailed information, i.e. the complete backtrace at the point of the segfault and the values of any relevant variables. -- Glynn Clements From neteler at itc.it Tue Jul 24 22:16:10 2007 From: neteler at itc.it (Markus Neteler) Date: Tue Jul 24 22:16:13 2007 Subject: [GRASS-dev] d.font -l: please sort alphabetically Message-ID: <11770995.post@talk.nabble.com> Hi, d.font -l prints out 190 fonts on my system (happy me) but they aren't sorted. Could this be added to print_font_list() in display/d.font/main.c ? Thanks Markus -- View this message in context: http://www.nabble.com/d.font--l%3A-please-sort-alphabetically-tf4138371.html#a11770995 Sent from the Grass - Dev mailing list archive at Nabble.com. From paul-grass at stjohnspoint.co.uk Tue Jul 24 22:46:30 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Jul 24 22:46:36 2007 Subject: [GRASS-dev] d.font -l: please sort alphabetically In-Reply-To: <11770995.post@talk.nabble.com> References: <11770995.post@talk.nabble.com> Message-ID: Hello Markus, On Tue, 24 Jul 2007, Markus Neteler wrote: > d.font -l prints out 190 fonts on my system (happy me) but they aren't > sorted. The list *is* sorted (see function compare_fonts() in general/g.mkfontcap/main.c), first by type (stroke font or freetype-compatible), and then by name. But it sorts case-insensitively on the long descriptive name (I thought this would be most logical for human-readable viewing), not on the short name. Unfortunately we haven't yet added the capability to d.font to also view the more descriptive name - Glynn mentioned that adding a d.font -L flag (capital L rather than lower-case l) might be a good idea for that. It isn't entirely simple though, but just needs some work. Do you think that would be enough? Or should we change the search to sort on the short name - case-insensitively perhaps? You could try that if you want and see if it gives you good results on your system - just change the two references to "longname" in that function to "name". I'm not sure how much info the d.font -L flag should produce though - just the short name and long name, or the path to the file, index within the file etc.? And funnily enough, just today I've been working on some tidying and improvements to the fontcap generation stuff. Main points being: 1) Add a text file to the lib/fonts/fonts directory to be installed into $GISBASE/etc/fonts, to identify a descriptive long name with each stroke font (actually copied from d.font man page) 2) Removed the capability from g.mkfontcap to generate an old-style freetypecap file, to simplify and reduce confusion 3) Adjusted "make install" to adjust the path to the stroke fonts in the fontcap file, when GRASS is installed to a different location on the local system 4) Adjusted the binary install script binaryInstall.src to run g.mkfontcap during the install process, to find all the fonts on the local system. After some more local testing I should hopefully get these changes committed tomorrow. They don't affect the sorting of the d.font output though. Paul From hamish_nospam at yahoo.com Wed Jul 25 08:46:03 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jul 25 08:46:46 2007 Subject: [GRASS-dev] Re: [GRASS-user] g.list pager In-Reply-To: <18086.22650.532856.625093@cerise.gclements.plus.com> References: <20070724151926.16a54bc7.hamish_nospam@yahoo.com> <18086.22650.532856.625093@cerise.gclements.plus.com> Message-ID: <20070725184603.608fea23.hamish_nospam@yahoo.com> > Hamish wrote: > > Debian packaging rules state that the default pager will be 'less', > > not GRASS's default of 'more'. Glynn: > IMHO, the default value of GRASS_PAGER ought to be $PAGER, if that is > set. On the DebianGIS list Francesco corrected me (again), it's actually patched to use the default system `pager` (set in /usr/bin with a symlink). The default alternative just happens to be a symlink to /usr/bin/less. So in practice YHO is already in force on Debian. If GRASS_PAGER is set it is respected. H: > > .grassrc6 is not what you expect. It holds the g.gisenv GIS > > variables, it's not a shell script containing commands like .bashrc > > is. G: > We should change the name for 7.x. It isn't an "rc" file in the > conventional sense. Name change gets my vote. -> .grass_env or .grass7_env? Is the major version needed in the filename? > > Use .grass.bashrc for setting shell enviro variables instead. (or > > .bashrc) > > Note that ~/.grass.bashrc only affects the interactive shell which is > spawned from Init.sh; it doesn't affect the operation of Init.sh > itself. For that, use ~/.bashrc (or similar). > > It might be worth having a separate rc file which is sourced from the > top of Init.sh. is there a point to having two rc files? ie when would you want to use the second one if you have the first? better to just source .grass.bashrc at the start of Init.sh and dispense with the idea of a second script? > Also, on the subject of potential Init.sh changes, I'd suggest getting > rid of the $HOME "games" and just setting HISTFILE to put the history > file in the mapset directory (AFAICT, that is the primary purpose of > the $HOME stuff). I agree. You say "primary purpose", what else does it touch? Hamish From wichmann at laserdata.at Wed Jul 25 09:22:20 2007 From: wichmann at laserdata.at (Volker Wichmann) Date: Wed Jul 25 09:24:58 2007 Subject: [GRASS-dev] [grass-code I][431] g.copy segmentation fault In-Reply-To: <18086.22872.250450.40350@cerise.gclements.plus.com> References: <20070620135314.9534A40FB3@pyrosoma.intevation.org> <46810AD4.4080905@o2.pl> <46A07996.7040300@laserdata.at> <46A44D73.9050908@laserdata.at> <18084.55455.521934.169287@cerise.gclements.plus.com> <46A5F668.1000903@laserdata.at> <18086.22872.250450.40350@cerise.gclements.plus.com> Message-ID: <46A6FA2C.2090509@laserdata.at> Glynn Clements wrote: > > You will need to provide more detailed information, i.e. the complete > backtrace at the point of the segfault and the values of any relevant > variables. > I did a backtrace, placed a break point a few lines before the crash and did a re-run. Here is the output: ------------------------------------------------------------------------------------------------- Starting program: /usr/local/grass-6.3.cvs/bin/g.copy rast=last.min,test5 [Thread debugging using libthread_db enabled] [New Thread -1208260912 (LWP 4913)] Copy raster to current mapset as [Switching to Thread -1208260912 (LWP 4913)] Breakpoint 1, do_copy (n=0, old=0x897c270 "last.min", mapset=0x897c2b8 "PERMANENT", new=0x897c280 "test5") at do_copy.c:31 31 hold_signals(1); (gdb) next 32 if ( G_strcasecmp (list[n].alias, "vect") == 0 ) { (gdb) next 40 for (i = 0; i < list[n].nelem; i++) (gdb) next 35 G_warning ("Cannot copy <%s> to current mapset as <%s>", (gdb) next 42 G__make_mapset_element (list[n].element[i]); (gdb) next 43 G__file_name (path, list[n].element[i], old, mapset); (gdb) next 44 if (access (path, 0) != 0) (gdb) next 52 G__file_name (path2, list[n].element[i], new, G_mapset()); (gdb) next 53 if ( recursive_copy(path, path2) == 1 ) (gdb) print path $1 = "/data/grassdb/demo/PERMANENT/cell/last.min\000\217\221\000\001\000\000\000\b\000\000\000????????\000\000\000\000\200s?\000??\227\b\003\000\000\000\000\000\000\000???\000\000\000\000\000Q???", '\0' , "?o?\000\000\000\000\000?\227\b\001\000\000\000\000\000\000\000\002\000\000\000?\227\b???\000????8???\202B\025\000?{?\000?\227\b \000\000\000?xP?\000\000\000\000?\227\b\202??\000K?\000\202??\000 \201?\000Q\000\000\000L\201?\000\000\000\000\000"... (gdb) print path2 $2 = "/data/grassdb/demo/PERMANENT/cell/test5\000\227\b\001\000\000\000 \000\000\000\002\000\000\000??3d.view:3dview:3D viewing parameters:3D view parameters\000\000n files\000\000???\217\221\000x\221??L?\200??h \220\000\000\000\000\000kI \024\000?\000?\217\221\000?'???q?\000n?\000\ f\226\227\b\000\000\000\000 \212\224\227\b?o?\000W\030\031\000\000\000\000\000T?"... (gdb) next 59 if (G_verbose() == G_verbose_max()) (gdb) next 40 for (i = 0; i < list[n].nelem; i++) (gdb) next Program received signal SIGSEGV, Segmentation fault. do_copy (n=0, old=0x897c270 "last.min", mapset=0x897c2b8 "PERMANENT", new=0x897c280 "test5") at do_copy.c:40 40 for (i = 0; i < list[n].nelem; i++) (gdb) print i $3 = 0 (gdb) print n $4 = 0 (gdb) print list[n].nelem $5 = 8 (gdb) print path $6 = "/data/grassdb/demo/PERMANENT/cell/last.min\000\217\221\000\001\000\000\000\b\000\000\000????????\000\000\000\000\200s?\000??\227\b\003\000\000\000\000\000\000\000???\000\000\000\000\000Q???", '\0' , "?o?\000\000\000\000\000?\227\b\001\000\000\000\000\000\000\000\002\000\000\000?\227\b???\000????8???\202B\025\000?{?\000?\227\b \000\000\000?xP?\000\000\000\000?\227\b\202??\000K?\000\202??\000 \201?\000Q\000\000\000L\201?\000\000\000\000\000"... (gdb) print path2 $7 = "/data/grassdb/demo/PERMANENT/cell/test5\000\227\b\001\000\000\000 \000\000\000\002\000\000\000??3d.view:3dview:3D viewing parameters:3D view parameters\000\000n files\000\000???\217\221\000x\221??L?\200??h \220\000\000\000\000\000kI \024\000?\000?\217\221\000?'???q?\000n?\000\ f\226\227\b\000\000\000\000 \212\224\227\b?o?\000W\030\031\000\000\000\000\000T?"... (gdb) bt full #0 do_copy (n=0, old=0x897c270 "last.min", mapset=0x897c2b8 "PERMANENT", new=0x897c280 "test5") at do_copy.c:40 i = 0 ret = path = "/data/grassdb/demo/PERMANENT/cell/last.min\000\217\221\000\001\000\000\000\b\000\000\000????????\000\000\000\000\200s?\000??\227\b\003\000\000\000\000\000\000\000???\000\000\000\000\000Q???", '\0' , "?o?\000\000\000\000\000?\227\b\001\000\000\000\000\000\000\000\002\000\000\000?\227\b???\000????8???\202B\025\000?{?\000?\227\b \000\000\000?xP?\000\000\000\000?\227\b\202??\000K?\000\202??\000 \201?\000Q\000\000\000L\201?\000\000\000\000\000"... path2 = "/data/grassdb/demo/PERMANENT/cell/test5\000\227\b\001\000\000\000 \000\000\000\002\000\000\000??3d.view:3dview:3D viewing parameters:3D view parameters\000\000n files\000\000???\217\221\000x\221??L?\200??h \220\000\000\000\000\000kI \024\000?\000?\217\221\000?'???q?\000n?\000\ f\226\227\b\000\000\000\000 \212\224\227\b?o?\000W\030\031\000\000\000\000\000T?"... result = 0 #1 0x080493eb in main (argc=2, argv=0xbfbcf1a4) at copy.c:95 n = mapset = 0x897c2b8 "PERMANENT" module = (struct GModule *) 0x199b90 parm = (struct Option **) 0x897b5d8 p = ---Type to continue, or q to quit--- to = 0x897c280 "test5" result = 0 (gdb) continue Continuing. Program terminated with signal SIGSEGV, Segmentation fault. ------------------------------------------------------------------------------------------------- Seems to me that path and path2 are corrupted? What I'm also unsure about is why line 35 is entered while stepping through the code - a gdb issue I can forget about? Thanks, Volker From wichmann at laserdata.at Wed Jul 25 11:25:04 2007 From: wichmann at laserdata.at (Volker Wichmann) Date: Wed Jul 25 11:27:09 2007 Subject: [GRASS-dev] r.in.xyz upgrade Message-ID: <46A716F0.4080408@laserdata.at> Hi, I have upgraded r.in.xyz to allow for the following aggregate functions: - skewness - median - percentile - trimmed mean To make this possible, I created singly linked lists for all points falling into a cell. I followed a suggestion of Glynn and used arrays instead of pointers and stored the head of each list in a raster map ([GRASS-dev] storing pointers in CELL_TYPE maps? (from April 2007)). The linked lists are then used to calculate the corresponding statistics before binning the values. So far we encountered no problems with this approach in our working group, but I'm not sure about some details. Maybe there should be some more checks, e.g. to prevent the index to overflow because of too many cells. If you are interested I'd like to share the code. Maybe it would be best to send a copy to Hamish first? Volker From carlos.grohmann at gmail.com Wed Jul 25 12:44:19 2007 From: carlos.grohmann at gmail.com (=?ISO-8859-1?Q?Carlos_"Gu=E2no"_Grohmann?=) Date: Wed Jul 25 12:44:24 2007 Subject: [GRASS-dev] bugs in r.shaded.relief and r.fillnulls Message-ID: Hi Just realized that r.shaded.relief doesn't deal properly with the "@mapset" names when no output map is given. I fixed it by changing ELEVSHADE="${elev}.shade" to ELEVSHADE="${elev%%@*}.shade" the fixed file is attached. Also I noticed that r.fillnulls doesn't allow input/output filenames to have "-" or "." Carlos -- +-----------------------------------------------------------+ Carlos Henrique Grohmann - Guano Visiting Researcher at Kingston University London - UK Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - carlos dot grohmann at gmail dot com +-----------------------------------------------------------+ _________________ "Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive." --The winning entry in a "What were HAL's first words" contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke Can't stop the signal. -------------- next part -------------- A non-text attachment was scrubbed... Name: r.shaded.relief Type: application/octet-stream Size: 6322 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070725/792ecc72/r.shaded-0001.obj From carlos.grohmann at gmail.com Wed Jul 25 12:56:34 2007 From: carlos.grohmann at gmail.com (=?ISO-8859-1?Q?Carlos_"Gu=E2no"_Grohmann?=) Date: Wed Jul 25 12:56:40 2007 Subject: [GRASS-dev] add-ons to gism (tcl) Message-ID: I've made a few add-ons to the tcl gism, which will add a r.info/v.info button for the selected maps and a g.region button that will set the region to the selected raster/vector. If anyone would like to try, get the file http://www.igc.usp.br/pessoais/guano/downloads/gism_addon.zip the gifs (icons) goes to GISBASE/etc/gui/icons and the .tcl file goes to GISBASE/etc/gm cheers Carlos -- +-----------------------------------------------------------+ Carlos Henrique Grohmann - Guano Visiting Researcher at Kingston University London - UK Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - carlos dot grohmann at gmail dot com +-----------------------------------------------------------+ _________________ "Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive." --The winning entry in a "What were HAL's first words" contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke Can't stop the signal. From neteler at itc.it Wed Jul 25 16:34:36 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Jul 25 16:34:39 2007 Subject: [GRASS-dev] v.net.path and v.net.iso examples (Spearfish) In-Reply-To: <20070502221342.GA5624@bartok.itc.it> References: <20070502221342.GA5624@bartok.itc.it> Message-ID: <11783866.post@talk.nabble.com> Markus Neteler wrote: > > Hi, > > I have added some examples based on Spearfish: > v.net.iso/description.html > v.net.path/description.html > ... > > Markus > Thanks to Martin Landa who implemented a new "connect" tool in v.net, it is now pretty easy to prepare a graph network. This "connect" tool in v.net connects points from a point map to a second lines map (the network). The resulting graph is input for v.net.iso, v.net.path etc. I have updated the examples accordingly in the manual pages (essentially simplifying the procedure). Markus -- View this message in context: http://www.nabble.com/v.net.path-and-v.net.iso-examples-%28Spearfish%29-tf3683617.html#a11783866 Sent from the Grass - Dev mailing list archive at Nabble.com. From glynn at gclements.plus.com Wed Jul 25 21:55:15 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Jul 25 21:55:19 2007 Subject: [GRASS-dev] Re: [GRASS-user] g.list pager In-Reply-To: <20070725184603.608fea23.hamish_nospam@yahoo.com> References: <20070724151926.16a54bc7.hamish_nospam@yahoo.com> <18086.22650.532856.625093@cerise.gclements.plus.com> <20070725184603.608fea23.hamish_nospam@yahoo.com> Message-ID: <18087.43683.702465.309588@cerise.gclements.plus.com> Hamish wrote: > > > Use .grass.bashrc for setting shell enviro variables instead. (or > > > .bashrc) > > > > Note that ~/.grass.bashrc only affects the interactive shell which is > > spawned from Init.sh; it doesn't affect the operation of Init.sh > > itself. For that, use ~/.bashrc (or similar). > > > > It might be worth having a separate rc file which is sourced from the > > top of Init.sh. > > is there a point to having two rc files? ie when would you want to use > the second one if you have the first? better to just source > .grass.bashrc at the start of Init.sh and dispense with the idea of a > second script? You might want to run commands which only make sense for an interactive shell. rc files aren't limited to environment variables. > > Also, on the subject of potential Init.sh changes, I'd suggest getting > > rid of the $HOME "games" and just setting HISTFILE to put the history > > file in the mapset directory (AFAICT, that is the primary purpose of > > the $HOME stuff). > > I agree. You say "primary purpose", what else does it touch? bash reads various files under $HOME at startup. All of these will be read from the mapset directory, as that is the value of $HOME when the interactive shell is spawned. The changes to $HOME are also used to force bash to read the generated .bashrc file instead of the user's ~/.bashrc, although you can use --rcfile for that. -- Glynn Clements From glynn at gclements.plus.com Wed Jul 25 22:03:52 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Jul 25 22:03:55 2007 Subject: [GRASS-dev] [grass-code I][431] g.copy segmentation fault In-Reply-To: <46A6FA2C.2090509@laserdata.at> References: <20070620135314.9534A40FB3@pyrosoma.intevation.org> <46810AD4.4080905@o2.pl> <46A07996.7040300@laserdata.at> <46A44D73.9050908@laserdata.at> <18084.55455.521934.169287@cerise.gclements.plus.com> <46A5F668.1000903@laserdata.at> <18086.22872.250450.40350@cerise.gclements.plus.com> <46A6FA2C.2090509@laserdata.at> Message-ID: <18087.44200.396477.767347@cerise.gclements.plus.com> Volker Wichmann wrote: > > You will need to provide more detailed information, i.e. the complete > > backtrace at the point of the segfault and the values of any relevant > > variables. > > > > I did a backtrace, placed a break point a few lines before the crash and > did a re-run. Here is the output: > Seems to me that path and path2 are corrupted? No; they're both NUL-terminated. When printing the contents of a char[], gdb prints the entire array; it doesn't stop at the first NUL. > What I'm also unsure about is why line 35 is entered while stepping > through the code - a gdb issue I can forget about? The code was compiled with optimisation enabled (the default CFLAGS are '-g -O2'), so the object code doesn't directly correspond to the source code. It might help if you re-compile the general/manage directory without optimisation, e.g.: make -C general/manage clean make -C general/manage CFLAGS1='-g' That will certainly make it easier to debug; OTOH, it might simply make the bug disappear. -- Glynn Clements From glynn at gclements.plus.com Wed Jul 25 22:06:27 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Jul 25 22:06:30 2007 Subject: [GRASS-dev] d.font -l: please sort alphabetically In-Reply-To: References: <11770995.post@talk.nabble.com> Message-ID: <18087.44355.983185.441675@cerise.gclements.plus.com> Paul Kelly wrote: > - Glynn mentioned that adding a d.font -L flag (capital L rather than > lower-case l) might be a good idea for that. It isn't entirely simple > though, but just needs some work. Do you think that would be enough? Or > should we change the search to sort on the short name - case-insensitively > perhaps? You could try that if you want and see if it gives you good > results on your system - just change the two references to "longname" in > that function to "name". > > I'm not sure how much info the d.font -L flag should produce though - just > the short name and long name, or the path to the file, index within the > file etc.? I've added R_font_info(), which behaves like R_font_list() except that each string is the entire fontcap entry rather than just the name. I've also added a -L switch to d.font. Currently, this dumps the raw string (with fields separated by the | character); some formatting would probably be desirable. -- Glynn Clements From neteler at itc.it Wed Jul 25 22:21:47 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Jul 25 22:21:49 2007 Subject: [GRASS-dev] d.font -l: please sort alphabetically In-Reply-To: <18087.44355.983185.441675@cerise.gclements.plus.com> References: <11770995.post@talk.nabble.com> <18087.44355.983185.441675@cerise.gclements.plus.com> Message-ID: <11799136.post@talk.nabble.com> Glynn Clements wrote: > > Paul Kelly wrote: >> - Glynn mentioned that adding a d.font -L flag (capital L rather than >> lower-case l) might be a good idea for that. It isn't entirely simple >> though, but just needs some work. Do you think that would be enough? Or >> should we change the search to sort on the short name - >> case-insensitively >> perhaps? You could try that if you want and see if it gives you good >> results on your system - just change the two references to "longname" in >> that function to "name". >> >> I'm not sure how much info the d.font -L flag should produce though - >> just >> the short name and long name, or the path to the file, index within the >> file etc.? > > I've added R_font_info(), which behaves like R_font_list() except that > each string is the entire fontcap entry rather than just the name. > > I've also added a -L switch to d.font. Currently, this dumps the raw > string (with fields separated by the | character); some formatting > would probably be desirable. > > -- > Glynn Clements > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > > Glynn, I have tried but both -l and -L don't report anything (any more). Doing a bit of debugging, I found that num_fonts is zero in print_font_list() at: for (i = 0; i < num_fonts; i++) But wc -l $GISBASE/etc/fontcap 268 /home/neteler/soft/63grass_cvsexp/dist.i686-pc-linux-gnu/etc/fontcap The debugger doesn't step into read_freetype_fonts(), not sure why (maybe due to my lack of knowledge of ddd/gdb). I didn't run "make distclean" if that matters. Markus -- View this message in context: http://www.nabble.com/d.font--l%3A-please-sort-alphabetically-tf4138371.html#a11799136 Sent from the Grass - Dev mailing list archive at Nabble.com. From Thomas.Adams at noaa.gov Thu Jul 26 00:48:18 2007 From: Thomas.Adams at noaa.gov (Thomas Adams) Date: Thu Jul 26 00:48:28 2007 Subject: [GRASS-dev] GRASS "custom" applications Message-ID: <46A7D332.8080901@noaa.gov> Folks: Please take a look at this: http://www.erh.noaa.gov/er/ohrfc/fop.html which was created using ArcGIS 9.x through some customization of the GUI to make the creation of the graphic a one-step process. Now, this graphic could easily be created using a script in GRASS (or, presumably, in ArcGIS), so it's an uninteresting example. But we use the graphic to depict areas of potential flooding (as indicated by the legend) by drawing color-filled polygons with text annotations to indicate the period over which the flooding is likely, as shown here: http://www.srh.noaa.gov/wgrfc/fop/wgrfcfop.html for a different region of the U.S. My question is this: how should I proceed to do this through some customization of the GRASS interface to "hide" GRASS details using a somewhat simplified GUI tool. I should add, that the flood risk polygons are exported to a text format file, which is then transmitted to a national center to generate a National product like this: http://www.srh.noaa.gov/wgrfc/fop/wgrfcfop.html I am also interested in an unrelated 'custom applcation' that would essentially combine a series of GRASS analyses into single step processes utilizing the GRASS GUI to initiate the analyses and set some parameters ? for various hydrologic analyses, including: (1) identification of snow elevation zones (disconnected regions within a watershed, above a certain elevation) (2) basin boundary delineation for a set of watershed outlets (utilizing r.water.outlet, etc.) (3) model parameter estimation I think most of this could be done as GRASS add-ons; would this be the way to go, or would embellishing the GRASS Tcl/Tk interface be necessary (something I would rather NOT do for several reasons). Thanks for any and all feedback! Tom -- Thomas E Adams National Weather Service Ohio River Forecast Center 1901 South State Route 134 Wilmington, OH 45177 EMAIL: thomas.adams@noaa.gov VOICE: 937-383-0528 FAX: 937-383-0033 From glynn at gclements.plus.com Thu Jul 26 01:07:27 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jul 26 01:07:35 2007 Subject: [GRASS-dev] cvs compilation problem - nviz? In-Reply-To: <18055.5306.430438.363624@cerise.gclements.plus.com> References: <4686BAB0.3070908@laserdata.at> <18055.5306.430438.363624@cerise.gclements.plus.com> Message-ID: <18087.55215.422823.172560@cerise.gclements.plus.com> Glynn Clements wrote: > > almost similar to a recent post of Helena, I have problems compiling cvs > > on a fedora 7 / NVIDIA machine. But I get another error: > > Errors in: > > /usr/local/src/grass-cvs/grass6/lib/ogsf > > /usr/local/src/grass-cvs/grass6/visualization/nviz > > > > Changing to /lib/ogsf and running make: > > gcc -I/usr/local/src/grass-cvs/grass6/dist.i686-pc-linux-gnu/include -g > > -O2 -fPIC -DPACKAGE=\""grasslibs"\" -I/usr/local/include > > -DPACKAGE=\""grasslibs"\" -I/usr/local/include/ffmpeg > > -I/usr/local/src/grass-cvs/grass6/dist.i686-pc-linux-gnu/include \ > > -o OBJ.i686-pc-linux-gnu/gsd_img_ppm.o -c gsd_img_ppm.c > > In file included from gsd_img_ppm.c:20: > > /usr/local/include/ffmpeg/avcodec.h:2252: warning: "ImgReSampleContext" is deprecated > > /usr/local/include/ffmpeg/avcodec.h:2258: warning: "ImgReSampleContext" is deprecated > > gsd_img_ppm.c: In function "gsd_init_mpeg": > > gsd_img_ppm.c:122: error: "mpeg1video_encoder" undeclared (first use in this function) > > gsd_img_ppm.c:122: error: (Each undeclared identifier is reported only once > > gsd_img_ppm.c:122: error: for each function it appears in.) > > make: *** [OBJ.i686-pc-linux-gnu/gsd_img_ppm.o] Error 1 > > > > As far as I can tell ffmpeg is installed correctly (mpeg1video_encoder > > is defined in config.h, no errors) ... any tip? > > It should be declared in avcodec.h: > > extern AVCodec mpeg1video_encoder; > > I don't have a config.h in the ffmpeg include directory, and > gsd_image_ppm.c doesn't #include it (in fact, if it did have > "#include ", there's no guarantee that it would be ffmpeg's > config.h which was included; config.h is a rather common name). > > It appears that your version of ffmpeg isn't compatible with the OGSF > library; I can only suggest removing --with-ffmpeg from your configure > command. I've just upgraded to ffmpeg 0.4.9, and I see the same problem. None of the installed headers define the *_encoder variables, so I assume that the only solution which will work with recent versions of ffmpeg is to replace register_avcodec() with avcodec_register_all(). -- Glynn Clements From glynn at gclements.plus.com Thu Jul 26 01:23:47 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jul 26 01:23:52 2007 Subject: [GRASS-dev] d.font -l: please sort alphabetically In-Reply-To: <11799136.post@talk.nabble.com> References: <11770995.post@talk.nabble.com> <18087.44355.983185.441675@cerise.gclements.plus.com> <11799136.post@talk.nabble.com> Message-ID: <18087.56195.354633.889423@cerise.gclements.plus.com> Markus Neteler wrote: > I have tried but both -l and -L don't report anything (any more). > I didn't run "make distclean" if that matters. It matters. The architecture of the graphics subsystem is such that adding new operations invariably requires substantial re-compilation. Unless you're especially familiar[1] with the graphics subsystem, it's easier to just start from scratch with "make distclean" than to figure out what needs to be re-compiled. [1] Actually, even if you are familiar, it's easy to get bitten. I spent 10 minutes tracking down a problem caused by failing to run "make -C lib headers" (which copies include/* to dist./include) after modifying include/graphics.h. -- Glynn Clements From hamish_nospam at yahoo.com Thu Jul 26 02:16:01 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Jul 26 02:16:13 2007 Subject: [GRASS-dev] r.in.xyz upgrade In-Reply-To: <46A716F0.4080408@laserdata.at> References: <46A716F0.4080408@laserdata.at> Message-ID: <20070726121601.2ef93b59.hamish_nospam@yahoo.com> Volker Wichmann wrote: > I have upgraded r.in.xyz to allow for the following aggregate > functions: - skewness > - median > - percentile > - trimmed mean > > To make this possible, I created singly linked lists for all points > falling into a cell. I followed a suggestion of Glynn and used arrays > instead of pointers and stored the head of each list in a raster map > ([GRASS-dev] storing pointers in CELL_TYPE maps? (from April 2007)). > The linked lists are then used to calculate the corresponding > statistics before binning the values. > So far we encountered no problems with this approach in our working > group, but I'm not sure about some details. Maybe there should be some > more checks, e.g. to prevent the index to overflow because of too many > cells. > > If you are interested I'd like to share the code. Maybe it would be > best to send a copy to Hamish first? Hi Volker, cheers for the upgrade, I'm sure it will be useful for many folks. I will be travelling for the next couple of weeks and won't have a chance to look at it before then. In the mean time can you post the unidiff to the code patch tracker? http://wald.intevation.org/tracker/?group_id=21 thanks, Hamish From wichmann at laserdata.at Thu Jul 26 09:47:30 2007 From: wichmann at laserdata.at (Volker Wichmann) Date: Thu Jul 26 09:49:36 2007 Subject: [GRASS-dev] [grass-code I][431] g.copy segmentation fault In-Reply-To: <18087.44200.396477.767347@cerise.gclements.plus.com> References: <20070620135314.9534A40FB3@pyrosoma.intevation.org> <46810AD4.4080905@o2.pl> <46A07996.7040300@laserdata.at> <46A44D73.9050908@laserdata.at> <18084.55455.521934.169287@cerise.gclements.plus.com> <46A5F668.1000903@laserdata.at> <18086.22872.250450.40350@cerise.gclements.plus.com> <46A6FA2C.2090509@laserdata.at> <18087.44200.396477.767347@cerise.gclements.plus.com> Message-ID: <46A85192.8050708@laserdata.at> Glynn Clements wrote: > The code was compiled with optimisation enabled (the default CFLAGS > are '-g -O2'), so the object code doesn't directly correspond to the > source code. > > It might help if you re-compile the general/manage directory without > optimisation, e.g.: > > make -C general/manage clean > make -C general/manage CFLAGS1='-g' > > That will certainly make it easier to debug; OTOH, it might simply > make the bug disappear. > > Crazy, that did the trick - no segmentation fault anymore! Thanks a lot Glynn!! As I know of several people that they have the same problem, I would like to keep this solution for the record. Glynn, would you be so kind to give me some more background why this can happen? Does this 'feature' relate to specific CPUs, operating systems etc. ? Volker From wichmann at laserdata.at Thu Jul 26 09:50:56 2007 From: wichmann at laserdata.at (Volker Wichmann) Date: Thu Jul 26 09:53:02 2007 Subject: [GRASS-dev] r.in.xyz upgrade In-Reply-To: <20070726121601.2ef93b59.hamish_nospam@yahoo.com> References: <46A716F0.4080408@laserdata.at> <20070726121601.2ef93b59.hamish_nospam@yahoo.com> Message-ID: <46A85260.6020407@laserdata.at> Hamish wrote: > Hi Volker, > > cheers for the upgrade, I'm sure it will be useful for many folks. > > I will be travelling for the next couple of weeks and won't have a > chance to look at it before then. In the mean time can you post the > unidiff to the code patch tracker? > > http://wald.intevation.org/tracker/?group_id=21 > > > thanks, > Hamish > Hi Hamish, I will do so as soon as I've figured out how to do the diffs. Volker From grass-codei at wald.intevation.org Thu Jul 26 10:31:53 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Thu Jul 26 10:28:47 2007 Subject: [GRASS-dev] [grass-code I][448] i.taget missing in tcltk tool georeferencing Message-ID: <20070726083153.E402C400B2@pyrosoma.intevation.org> code I item #448, was opened at 2007-07-26 08:31 Status: Open Priority: 3 Submitted By: Otto Dassau (dassau) Assigned to: Nobody (None) Summary: i.taget missing in tcltk tool georeferencing Issue type: None Issue status: None GRASS version: 6.2 GRASS component: tcl/tk GUI Operating system: Linux Operating system version: debian testing GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: Hi, the tcltk menue "GRASS georectifier" in GRASS 6.2.2 needs a button for i.taget to define the target location. Currently it includes: 1) choose mapset 2) create/edit group 3) select group 4) select map 5) georectify error message is: child process exited abnormally child process exited abnormally while executing "exec -- i.rectify -ca group=muell extension=6856 order=1 >& /dev/null" ("eval" body line 1) invoked from within "eval [list exec -- $cmd] $args >& $devnull" (procedure "run" line 12) invoked from within "run i.rectify -ca group=muell extension=6856 order=1" ("eval" body line 1) invoked from within "eval run $cmd $args" (procedure "runcmd" line 6) invoked from within "runcmd $cmd" (procedure "GRMap::rectify" line 54) invoked from within "GRMap::rectify" ("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.b3" (command bound to event) defining it manually works of course i.target -c group=muell regards, Otto ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=448&group_id=21 From grass-codei at wald.intevation.org Thu Jul 26 11:03:07 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Thu Jul 26 11:00:02 2007 Subject: [GRASS-dev] [grass-code I][449] r.in.gdal - output test for parameter location= fails Message-ID: <20070726090307.3798E400B3@pyrosoma.intevation.org> code I item #449, was opened at 2007-07-26 09:03 Status: Open Priority: 3 Submitted By: Otto Dassau (dassau) Assigned to: Nobody (None) Summary: r.in.gdal - output test for parameter location= fails Issue type: module bug Issue status: None GRASS version: 6.2 GRASS component: raster Operating system: Linux Operating system version: debian testing GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: when I try create a new location using r.in.gdal with the parameter location=, there is a test for an existing map in the current mapset and the import fails. GRASS 6.2.2 (location_utm):~ > r.in.gdal in=karte.jpg out=karte location=karte_xy Error: option : exists -> of course there is no map "karte" in the not even existing location: karte_xy. BTW: For v.in.ogr it works correctly. regards, Otto ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=449&group_id=21 From jeshua at OpenOSX.com Thu Jul 26 11:48:33 2007 From: jeshua at OpenOSX.com (Jeshua Lacock) Date: Thu Jul 26 11:48:39 2007 Subject: [GRASS-dev] r.terraflow on Mac OS X 10.4.9 Message-ID: <871EF8B5-8BAE-4044-8CF8-497933CFAF32@OpenOSX.com> I just built 6.2.2 with one failed module here on Mac OS X: make[2]: *** No rule to make target `/usr/include/gcc