From glynn at gclements.plus.com Fri Jun 1 06:06:10 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jun 1 06:06:15 2007 Subject: [GRASS-dev] r.colors now producing bogus color files for 'ryg' case In-Reply-To: <20070531191329.3750e02f.hamish_nospam@yahoo.com> References: <200705291641.28049.dylan.beaudette@gmail.com> <20070530194409.7e3ff6b0.hamish_nospam@yahoo.com> <200705301533.16395.dylan.beaudette@gmail.com> <20070531191329.3750e02f.hamish_nospam@yahoo.com> Message-ID: <18015.39730.314797.220762@cerise.gclements.plus.com> Hamish wrote: > So FP maps are being treated as CELL maps? Oops: --- raster/r.colors/main.c 29 May 2007 04:43:14 -0000 2.17 +++ raster/r.colors/main.c 1 Jun 2007 04:06:38 -0000 @@ -306,7 +306,7 @@ exit(EXIT_FAILURE); } else if (find_rule(type)) - G_make_colors(&colors, type, min, max); + G_make_fp_colors(&colors, type, min, max); else G_fatal_error(_("%s - unknown color request"), type); } Fixed in CVS. -- Glynn Clements From hamish_nospam at yahoo.com Fri Jun 1 06:23:06 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Jun 1 06:23:17 2007 Subject: [GRASS-dev] cvs2svn at GRASSWiki In-Reply-To: <293995C6-7B7A-4528-A7E8-C441D814D1E4@kyngchaos.com> References: <20070530222543.5f5672e3.hamish_nospam@yahoo.com> <293995C6-7B7A-4528-A7E8-C441D814D1E4@kyngchaos.com> Message-ID: <20070601162306.3030892d.hamish_nospam@yahoo.com> > > Martin Landa wrote: > >> I have created the new page at GRASS-Wiki related to the planned > >> migration of GRASS CVS repository to SVN. Please feel free to add > >> useful link! > > > > http://grass.gdf-hannover.de/wiki/Migration_from_CVS_to_SVN William Kyngesburye wrote: > One annoying problem I've noticed with other projects using SVN - the > files timestamps get set to the packaging/download time. I hope > there is a way to avoid this. I realize SVN keeps track of date/time > for the files, but it's nice to see it in the file system also. You mean the file's timestamp in the file system, not the "Last Modified: $Date$" in the help pages, right? at least I hope the $LastChangedDate$ keyword refers to checkin date, not the checkout date! (I thought $Date$ was just an alias to that) http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.keywords.html Hamish From woklist at kyngchaos.com Fri Jun 1 06:42:16 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Fri Jun 1 06:42:22 2007 Subject: [GRASS-dev] cvs2svn at GRASSWiki In-Reply-To: <20070601162306.3030892d.hamish_nospam@yahoo.com> References: <20070530222543.5f5672e3.hamish_nospam@yahoo.com> <293995C6-7B7A-4528-A7E8-C441D814D1E4@kyngchaos.com> <20070601162306.3030892d.hamish_nospam@yahoo.com> Message-ID: On May 31, 2007, at 11:23 PM, Hamish wrote: > William Kyngesburye wrote: >> One annoying problem I've noticed with other projects using SVN - the >> files timestamps get set to the packaging/download time. I hope >> there is a way to avoid this. I realize SVN keeps track of date/time >> for the files, but it's nice to see it in the file system also. > > > You mean the file's timestamp in the file system, not the > "Last Modified: $Date$" in the help pages, right? Yes - the file system timestamp. ----- William Kyngesburye http://www.kyngchaos.com/ "This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind?" - The Ruler of the Universe From glynn at gclements.plus.com Fri Jun 1 06:43:06 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jun 1 06:43:08 2007 Subject: [GRASS-dev] psdriver docs drafted In-Reply-To: <20070529203554.GA15324@bartok.itc.it> References: <20070529203554.GA15324@bartok.itc.it> Message-ID: <18015.41946.345569.734511@cerise.gclements.plus.com> Markus Neteler wrote: > ... at display/drivers/PS/description.html > Please update. I have collected stuff from various > places. > > I still wonder how to define the resolution (DPI). > Example: for the GRASS book I would like to generate > screenshots and such as PDFs at reasonable resolution. PostScript itself doesn't have a resolution; the resolution is determined by the device on which the PostScript is rendered. Currently, R_* coordinates are interpreted as points, so all coordinates end up getting snapped to a one-point grid. If you want greater precision, you can choose a larger "screen" size via GRASS_PAPER or GRASS_{WIDTH,HEIGHT} and scale down. However, some modules (e.g. d.barscale) create graphics whose size (in coordinates) is hard-coded, so this will result in smaller graphics relative to the size of the "screen". If desired, reading the grid size from an environment variable would be trivial. Rasters are output as-is, with no scaling other than that performed by G_get_raster_row() etc. One outstanding issue is text. FreeType fonts will be pre-rendered at one-point resolution (i.e. 72 DPI) and output as bitmaps. I can modify text handling to allow the PS driver to use PostScript fonts, but it would be limited to ISO-8859-1, and R_get_text_box() would have to be an approximation. Alternatively, it would be possible to get the glyph outlines from FreeType and send those to the printer instead of bitmaps. This isn't trivial, but it isn't a vast amount of work either. -- Glynn Clements From Juan.Giraldo at upct.es Fri Jun 1 11:39:39 2007 From: Juan.Giraldo at upct.es (Juan Diego Giraldo Osorio) Date: Fri Jun 1 11:38:07 2007 Subject: [GRASS-dev] executing r.example In-Reply-To: <2849353596jdgiraldo@upct.es> References: <2849353596jdgiraldo@upct.es> Message-ID: <3341981699jdgiraldo@upct.es> Hi Today I have ran the r.example code. Thanks to all. However, I have several problems executing grass62: - When I get in to grass, the program shows a (new!!!) interface. I select the Mapset and Location, and when I do click on "Enter Grass", the prompt shows this: GRASS 6.2.1 (METEOSAT):~ > g.region: error while loading shared libraries: libgdal.so.1: cannot open shared object file: No such file or directory -When I execute g.region... GRASS 6.2.1 (METEOSAT):~ > g.region g.region: error while loading shared libraries: libgdal.so.1: cannot open shared object file: No such file or directory - When I try to execute r.in.gdal... GRASS 6.2.1 (METEOSAT):~ > r.in.gdal r.in.gdal: error while loading shared libraries: libproj.so.0: cannot open shared object file: No such file or directory I have the libgdal.so.1 in /usr/lib directory, and both files (libgdal.so.1 and libproj.so.0) in /usr/local/lib. How can I overcome these problems?? Thanks Juan From Agustin.Diez at uv.es Fri Jun 1 13:09:28 2007 From: Agustin.Diez at uv.es (Agustin Diez Castillo) Date: Fri Jun 1 13:11:14 2007 Subject: [GRASS-dev] wms in wxgrass? In-Reply-To: <465E9BE5.7020209@itc.it> References: <051F4DF9-5FDA-498E-BFA3-E719155D3562@uv.es> <20070531015812.66c5bafd.hamish_nospam@yahoo.com> <10877697.post@talk.nabble.com> <20070531182143.26cb5b5a.hamish_nospam@yahoo.com> <465E9BE5.7020209@itc.it> Message-ID: same command I got a somewhat different error All tiles downloaded successfully ################################# r.in.gdalwarp -c 'input=/Users/Shared/grassdata/wms_download/ terraserver-drg_rural_1m_0.tiff' 'output=terraserver-drg' 'method=nearest' 's_srs=EPSG:4326' gdalwarp -s_srs "EPSG:4326" -t_srs "PROJCS["Lambert Conformal Conic",GEOGCS["grs80",DATUM["North_American_Datum_1983",SPHEROID ["grs80",6378137,298.257222101]],PRIMEM["Greenwich",0],UNIT["degree", 0.0174532925199433]],PROJECTION ["Lambert_Conformal_Conic_2SP"],PARAMETER["standard_parallel_1", 34.33333333333334],PARAMETER["standard_parallel_2", 36.16666666666666],PARAMETER["latitude_of_origin",33.75],PARAMETER ["central_meridian",-79],PARAMETER["false_easting", 609601.22],PARAMETER["false_northing",0],UNIT["Meter",1]]" "/Users/ Shared/grassdata/wms_download/terraserver-drg_rural_1m_0.tiff" "/ Users/Shared/grassdata/nc_spm_05/user1/.tmp/regadiuet.prearq.uv.es/ 16540.0warped.geotiff" -rn ERROR 1: TIFFFetchDirectory:/Users/Shared/grassdata/wms_download/ terraserver-drg_rural_1m_0.tiff: Can not read TIFF directory count ERROR 1: TIFFReadDirectory:/Users/Shared/grassdata/wms_download/ terraserver-drg_rural_1m_0.tiff: Failed to read directory at offset 0 ERROR 4: `/Users/Shared/grassdata/nc_spm_05/user1/.tmp/ regadiuet.prearq.uv.es/16540.0warped.geotiff' does not exist in the file system, and is not recognised as a supported dataset name. On May 31, 2007, at 11:56 AM, Markus Neteler wrote: >>> g.region rural_1m -p >>> r.in.wms output=terraserver-drg >>> mapserver=http://terraserver.microsoft.com/ogcmap6.ashx >>> layers=DRG region=rural_1m format=tiff >> Requesting 1 tiles. >> Downloading tiles >> Tile already downloaded >> All tiles downloaded successfully >> ################################# >> OGCMap Test >> >>

Service Exception Report

>> >> > vvv > > >>

Found 1 errors

>>
Unable to parse EPSG code 3358 >> >> > ^^^ > > >> >> >> Any idea? >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070601/b7f8535e/attachment.html From epatton at nrcan.gc.ca Fri Jun 1 16:42:46 2007 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Fri Jun 1 16:43:29 2007 Subject: [GRASS-dev] r.colors: stack smashing detected when large floating point numbers added to rules References: Message-ID: Forwarding to Grass dev list; I forgot to CC: it, sorry. -----Original Message----- From: Patton, Eric Sent: Fri 6/1/2007 11:41 AM To: GRASSList (grassuser@grass.itc.it) Subject: r.colors: stack smashing detected when large floating point numbers added to rules Hi, r.colors terminates if a large floating-point number is added to the rules list (specifically, 12 decimal places or more). In spearfish: $ r.colors map=elevation.10m color=rules Enter rules, "end" when done, "help" if you need it. fp: Data range is 1061.0640869999999722494976595 to 1846.74340800000004492176231 >1061.064086999999 blue *** stack smashing detected ***: r.colors terminated Aborted (core dumped) It's not crucial for me to be able to enter color rules this precisely, but r.colors should probably handle cases like these without crashing. ~ Eric. From dylan.beaudette at gmail.com Fri Jun 1 20:40:51 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Fri Jun 1 20:39:02 2007 Subject: [GRASS-dev] r.colors now producing bogus color files for 'ryg' case In-Reply-To: <18015.39730.314797.220762@cerise.gclements.plus.com> References: <200705291641.28049.dylan.beaudette@gmail.com> <20070531191329.3750e02f.hamish_nospam@yahoo.com> <18015.39730.314797.220762@cerise.gclements.plus.com> Message-ID: <200706011140.51967.dylan.beaudette@gmail.com> On Thursday 31 May 2007 21:06, Glynn Clements wrote: > Hamish wrote: > > So FP maps are being treated as CELL maps? > > Oops: > > --- raster/r.colors/main.c 29 May 2007 04:43:14 -0000 2.17 > +++ raster/r.colors/main.c 1 Jun 2007 04:06:38 -0000 > @@ -306,7 +306,7 @@ > exit(EXIT_FAILURE); > } > else if (find_rule(type)) > - G_make_colors(&colors, type, min, max); > + G_make_fp_colors(&colors, type, min, max); > else > G_fatal_error(_("%s - unknown color request"), type); > } > > Fixed in CVS. Thanks Glynn! -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 From dylan.beaudette at gmail.com Fri Jun 1 21:33:54 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Fri Jun 1 21:32:02 2007 Subject: [GRASS-dev] small patch for lib/vector/transform/ Message-ID: <200706011233.55044.dylan.beaudette@gmail.com> I needed some functionality to print the transformation matrix, very simple patch - it might be useful to others. It prints out the matrix along with a small note: Transformation Matrix --------------------- 28155.882288 0.013530 1.002469 -5301.399323 0.997547 -0.009172 --------------------- the patch is attached. Perhaps diagnostics like this might be a general use. -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 -------------- next part -------------- A non-text attachment was scrubbed... Name: print_matrix-patch-transform.c Type: text/x-csrc Size: 477 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070601/45634bd9/print_matrix-patch-transform-0001.bin From debeaudette at ucdavis.edu Sat Jun 2 00:29:59 2007 From: debeaudette at ucdavis.edu (Dylan Beaudette) Date: Sat Jun 2 00:28:06 2007 Subject: [GRASS-dev] small patch for lib/vector/transform/ In-Reply-To: <200706011233.55044.dylan.beaudette@gmail.com> References: <200706011233.55044.dylan.beaudette@gmail.com> Message-ID: <200706011529.59761.debeaudette@ucdavis.edu> On Friday 01 June 2007 12:33, Dylan Beaudette wrote: > I needed some functionality to print the transformation matrix, very simple > patch - it might be useful to others. > > It prints out the matrix along with a small note: > > Transformation Matrix > --------------------- > 28155.882288 0.013530 1.002469 > -5301.399323 0.997547 -0.009172 > --------------------- > > the patch is attached. > > Perhaps diagnostics like this might be a general use. ack. attached is a better version, with the ordering better spelled out. Note that this matrix output is in the format that other applications like R and PostGIS create / expect. cheers -- Dylan Beaudette Soil Resource Laboratory http://casoilresource.lawr.ucdavis.edu/ University of California at Davis 530.754.7341 -------------- next part -------------- A non-text attachment was scrubbed... Name: print_matrix-patch-transform.c Type: text/x-csrc Size: 538 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070601/d02d01e8/print_matrix-patch-transform.bin From hamish_nospam at yahoo.com Sat Jun 2 01:39:36 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sat Jun 2 01:39:45 2007 Subject: [GRASS-dev] wms in wxgrass? In-Reply-To: References: <051F4DF9-5FDA-498E-BFA3-E719155D3562@uv.es> <20070531015812.66c5bafd.hamish_nospam@yahoo.com> <10877697.post@talk.nabble.com> <20070531182143.26cb5b5a.hamish_nospam@yahoo.com> <465E9BE5.7020209@itc.it> Message-ID: <20070602113936.6d5b4985.hamish_nospam@yahoo.com> Agustin Diez Castillo wrote: > same command I got a somewhat different error # skipped region setting r.in.wms output=terraserver-drg mapserver=http://terraserver.microsoft.com/ogcmap6.ashx layers=DRG format=tiff > All tiles downloaded successfully > ################################# > r.in.gdalwarp -c 'input=/Users/Shared/grassdata/wms_download/ .. > ERROR 1: TIFFFetchDirectory:/Users/Shared/grassdata/wms_download/ > terraserver-drg_rural_1m_0.tiff: Can not read TIFF directory count > ERROR 1: TIFFReadDirectory:/Users/Shared/grassdata/wms_download/ > terraserver-drg_rural_1m_0.tiff: Failed to read directory at offset 0 > ERROR 4: `/Users/Shared/grassdata/nc_spm_05/user1/.tmp/ > regadiuet.prearq.uv.es/16540.0warped.geotiff' does not exist in the > file system, > and is not recognised as a supported dataset name. same here, downloaded TIFF contains junk: (903K binary file) $ tiffinfo wms_download/terraserver-drg__0.tiff TIFFReadDirectory: wms_download/terraserver-drg__0.tiff: Can not read TIFF directory count. $ gdalinfo wms_download/terraserver-drg__0.tiff ERROR 1: TIFFReadDirectory:wms_download/terraserver-drg__0.tiff: Can not read TIFF directory count GDALOpen failed - 1 TIFFReadDirectory:wms_download/terraserver-drg__0.tiff: Can not read TIFF directory count Hamish From yann.chemin at gmail.com Sat Jun 2 08:02:34 2007 From: yann.chemin at gmail.com (Yann) Date: Sat Jun 2 08:03:05 2007 Subject: [GRASS-dev] wms in wxgrass? In-Reply-To: <051F4DF9-5FDA-498E-BFA3-E719155D3562@uv.es> References: <051F4DF9-5FDA-498E-BFA3-E719155D3562@uv.es> Message-ID: <200706021302.35494.yann.chemin@gmail.com> Hi, Trying r.in.wms and it asks install "bc" it is not in the dependency list, isn't it? Yann From tutey at o2.pl Sat Jun 2 08:28:25 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sat Jun 2 08:28:39 2007 Subject: [GRASS-dev] small patch for lib/vector/transform/ In-Reply-To: <200706011529.59761.debeaudette@ucdavis.edu> References: <200706011233.55044.dylan.beaudette@gmail.com> <200706011529.59761.debeaudette@ucdavis.edu> Message-ID: <46610E09.9010408@o2.pl> Dylan Beaudette wrote: > On Friday 01 June 2007 12:33, Dylan Beaudette wrote: >> I needed some functionality to print the transformation matrix, very simple >> patch - it might be useful to others. >> >> It prints out the matrix along with a small note: >> >> Transformation Matrix >> --------------------- >> 28155.882288 0.013530 1.002469 >> -5301.399323 0.997547 -0.009172 >> --------------------- >> >> the patch is attached. Please add it to patches tracker. Maciek From hamish_nospam at yahoo.com Sat Jun 2 09:05:32 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sat Jun 2 09:05:37 2007 Subject: [GRASS-dev] G_important_message() Message-ID: <20070602190532.6f0e030b.hamish_nospam@yahoo.com> Hi, I added G_important_message() which will do G_message() when GRASS_VERBOSE=1. Usually just G_percent() or G_clicker() would be printed at that verbosity level. To test try "g.message -i". Use sparingly. I also added some ideas+opinions to the message standardization wiki page: http://grass.gdf-hannover.de/wiki/Development_Specs (make distclean) Hamish From hamish_nospam at yahoo.com Sat Jun 2 09:52:21 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sat Jun 2 09:52:27 2007 Subject: [GRASS-dev] g.version message change? Message-ID: <20070602195221.75aa2dbb.hamish_nospam@yahoo.com> Hi, any objections to this patch? (script breakage....) Index: grass6/general/g.version/main.c =================================================================== RCS file: /grassrepository/grass6/general/g.version/main.c,v retrieving revision 2.5 diff -u -r2.5 main.c --- grass6/general/g.version/main.c 19 Aug 2006 12:52:20 -0000 2.5 +++ grass6/general/g.version/main.c 2 Jun 2007 07:51:49 -0000 @@ -44,7 +44,7 @@ if (argc > 1 && G_parser(argc, argv)) exit(EXIT_FAILURE); - fprintf (stdout, "GRASS %s (%s) %s\n", + fprintf (stdout, "GRASS GIS %s (%s) %s\n", GRASS_VERSION_NUMBER, GRASS_VERSION_DATE, GRASS_VERSION_UPDATE_PKG ); if (copyright->answer){ I'd like to include `g.version` in a script, and it reads better with the "GIS" in there. Hamish From neteler at itc.it Sat Jun 2 09:57:53 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Jun 2 09:57:55 2007 Subject: [GRASS-dev] r.statistics limitation to CELL Message-ID: <20070602075753.GA4917@bartok.itc.it> Hi, would it be much work to fix this: GRASS 6.3.cvs (nc_spm_05):~ > r.statistics base=landuse96_28m \ cover=elevation out=elevstats_avg method=average ERROR: This module currently only works for integer (CELL) maps Rounding elevation to CELL first isn't a great option. Markus From tutey at o2.pl Sat Jun 2 10:56:43 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sat Jun 2 10:56:55 2007 Subject: [GRASS-dev] [grass-code I][342] v.clean tool=snap: doubled vertices in the output In-Reply-To: <20070325114821.E037418565DC@pyrosoma.intevation.org> References: <20070325114821.E037418565DC@pyrosoma.intevation.org> Message-ID: <466130CB.4050508@o2.pl> This bug is fixed by Martin Landa in 6.3 and 6.2 CVS. I was wondering - could the vector cleaning that v.in.ogr performs suffer from this bug too? Or does v.in.ogr use the same code that v.clean does, so that a fix for v.clean fixes the problem for v.in.ogr too? Maciek From glynn at gclements.plus.com Sat Jun 2 13:35:57 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jun 2 13:36:00 2007 Subject: [GRASS-dev] small patch for lib/vector/transform/ In-Reply-To: <200706011233.55044.dylan.beaudette@gmail.com> References: <200706011233.55044.dylan.beaudette@gmail.com> Message-ID: <18017.22045.142647.679148@cerise.gclements.plus.com> Dylan Beaudette wrote: > I needed some functionality to print the transformation matrix, very simple > patch - it might be useful to others. > > It prints out the matrix along with a small note: > > Transformation Matrix > --------------------- > 28155.882288 0.013530 1.002469 > -5301.399323 0.997547 -0.009172 > --------------------- > > the patch is attached. > > Perhaps diagnostics like this might be a general use. > > > -- > Dylan Beaudette > Soils and Biogeochemistry Graduate Group > University of California at Davis > 530.754.7341 > Index: lib/vector/transform/transform.c > =================================================================== > RCS file: /home/grass/grassrepository/grass6/lib/vector/transform/transform.c,v > retrieving revision 1.2 > diff -r1.2 transform.c > 146a147,152 > > printf("Transformation Matrix\n"); > > printf("------------------------------------------\n"); > > printf("%f %f %f \n", B0, B1, B2); > > printf("%f %f %f \n", B3, B4, B5); > > printf("------------------------------------------\n"); First, patches should use either unified or context format (preferably unified). However ... Library code shouldn't be unconditionally printing diagnostic information (especially not to stdout); use G_debug() instead. If you need to print this information in normal use (without debugging enabled), add a separate get_transformation_matrix() function to that file. Alternatively, you can implement it within your module using transform_b_into_a(), i.e.: double B0, B1, B2, B3, B4, B5; transform_b_into_a(0, 0, &B0, &B3); transform_b_into_a(1, 0, &B1, &B4); B1 -= B0; B4 -= B3; transform_b_into_a(0, 1, &B2, &B5); B2 -= B0; B5 -= B3; -- Glynn Clements From glynn at gclements.plus.com Sat Jun 2 14:00:12 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jun 2 14:00:14 2007 Subject: [GRASS-dev] r.statistics limitation to CELL In-Reply-To: <20070602075753.GA4917@bartok.itc.it> References: <20070602075753.GA4917@bartok.itc.it> Message-ID: <18017.23500.221622.148504@cerise.gclements.plus.com> Markus Neteler wrote: > would it be much work to fix this: > > GRASS 6.3.cvs (nc_spm_05):~ > r.statistics base=landuse96_28m \ > cover=elevation out=elevstats_avg method=average > ERROR: This module currently only works for integer (CELL) maps > > Rounding elevation to CELL first isn't a great option. 1. r.statistics works by reclassing the base map, so the base map can't be FP. 2. r.statistics uses r.stats to calculate the statistics, and r.stats reads its inputs as CELL. r.stats is inherently based upon discrete categories. Even if it reads FP maps as FP, you would need to quantise the values, otherwise you would end up with every cell as its own category with count == 1. This would require memory proportional to the size of the input map multiplied by a significant factor (48-64 bytes per cell, or even more). To handle FP data, you really need a completely new approach which computes aggregates incrementally, using an accumulator. This would limit it to aggregates which can be computed that way, e.g. count, sum, mean, variance and standard deviation. [The last two would need to either use the one-pass algorithm (which can result in negative variance for near-constant data due to rounding error), or use two passes (computing the mean in the first pass so that the actual deviations can be used in the second pass). See also: the history of r.univar.] As I've mentioned several times before, computing quantiles (e.g. median) of large amounts of floating-point data is an open-ended problem; any given approach has both pros and cons. -- Glynn Clements From neteler at itc.it Sat Jun 2 14:05:56 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Jun 2 14:05:58 2007 Subject: [GRASS-dev] r.statistics limitation to CELL In-Reply-To: <18017.23500.221622.148504@cerise.gclements.plus.com> References: <20070602075753.GA4917@bartok.itc.it> <18017.23500.221622.148504@cerise.gclements.plus.com> Message-ID: <20070602120556.GE4917@bartok.itc.it> On Sat, Jun 02, 2007 at 01:00:12PM +0100, Glynn Clements wrote: > > Markus Neteler wrote: > > > would it be much work to fix this: > > > > GRASS 6.3.cvs (nc_spm_05):~ > r.statistics base=landuse96_28m \ > > cover=elevation out=elevstats_avg method=average > > ERROR: This module currently only works for integer (CELL) maps > > > > Rounding elevation to CELL first isn't a great option. > > 1. r.statistics works by reclassing the base map, so the base map > can't be FP. In this case I meant the cover map "elevation" which is rejected. landuse96_28m is a CELL map, elevation FCELL. > 2. r.statistics uses r.stats to calculate the statistics, and r.stats > reads its inputs as CELL. In this case, r.statistics could also accept an FCELL map without complaining? Currently I need extra steps to round elevation to a CELL map before running r.statistics. > r.stats is inherently based upon discrete categories. Even if it reads > FP maps as FP, you would need to quantise the values, otherwise you > would end up with every cell as its own category with count == 1. This > would require memory proportional to the size of the input map > multiplied by a significant factor (48-64 bytes per cell, or even > more). > > To handle FP data, you really need a completely new approach which > computes aggregates incrementally, using an accumulator. This would > limit it to aggregates which can be computed that way, e.g. count, > sum, mean, variance and standard deviation. I darkly remember that Soeren has something already in the works. > [The last two would need to either use the one-pass algorithm (which > can result in negative variance for near-constant data due to rounding > error), or use two passes (computing the mean in the first pass so > that the actual deviations can be used in the second pass). See also: > the history of r.univar.] > > As I've mentioned several times before, computing quantiles (e.g. > median) of large amounts of floating-point data is an open-ended > problem; any given approach has both pros and cons. > > -- > Glynn Clements Markus From hamish_nospam at yahoo.com Sat Jun 2 14:07:29 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sat Jun 2 14:07:34 2007 Subject: [GRASS-dev] make pdfdocs error Message-ID: <20070603000729.71a70394.hamish_nospam@yahoo.com> Hi, [6.3cvs] $ make pdfdocs ... make[2]: Leaving directory `/usr/local/src/grass/grass63/lib/vector/dglib/latex' PDF reference in directory ./latex/grass63dglib_2007_06_02_refman.pdf make[1]: Leaving directory `/usr/local/src/grass/grass63/lib/vector/dglib' (cd rfc/ ; make cleandocs ; make pdfdocs) make[1]: Entering directory `/usr/local/src/grass/grass63/rfc' rm -fr latex/ html/ make[1]: Leaving directory `/usr/local/src/grass/grass63/rfc' make[1]: Entering directory `/usr/local/src/grass/grass63/rfc' make[1]: *** No rule to make target `pdfdocs'. Stop. make[1]: Leaving directory `/usr/local/src/grass/grass63/rfc' make: *** [pdfdocs] Error 2 ? Hamish From muratasenel at gmail.com Sat Jun 2 14:14:26 2007 From: muratasenel at gmail.com (Murat =?utf-8?q?=C5=9Eenel?=) Date: Sat Jun 2 14:14:57 2007 Subject: [GRASS-dev] compiling error in grass-6.2.2RC1 with gdal-1.4.1 support Message-ID: <200706021514.27129.muratasenel@gmail.com> Hi all, I am the package maintainer of grass on Pardus GNU/Linux and I get the error below while trying to compile grass-6.2.2RC1 with gdal-1.4.1 support. checking whether to use GDAL... yes checking for gdal-config... /usr/bin/gdal-config checking for GDALOpen... no checking for GDALOpen... no configure: error: *** Unable to locate GDAL library. Any help would be appreciated. Regards, Murat From soerengebbert at gmx.de Sat Jun 2 14:55:44 2007 From: soerengebbert at gmx.de (=?ISO-8859-1?Q?S=F6ren_Gebbert?=) Date: Sat Jun 2 14:56:22 2007 Subject: [GRASS-dev] r.statistics limitation to CELL In-Reply-To: <20070602120556.GE4917@bartok.itc.it> References: <20070602075753.GA4917@bartok.itc.it> <18017.23500.221622.148504@cerise.gclements.plus.com> <20070602120556.GE4917@bartok.itc.it> Message-ID: <466168D0.4050500@gmx.de> Hi, Markus Neteler schrieb: > On Sat, Jun 02, 2007 at 01:00:12PM +0100, Glynn Clements wrote: >> Markus Neteler wrote: >> >>> would it be much work to fix this: >>> >>> GRASS 6.3.cvs (nc_spm_05):~ > r.statistics base=landuse96_28m \ >>> cover=elevation out=elevstats_avg method=average >>> ERROR: This module currently only works for integer (CELL) maps >>> >>> Rounding elevation to CELL first isn't a great option. >> 1. r.statistics works by reclassing the base map, so the base map >> can't be FP. > > In this case I meant the cover map "elevation" which is rejected. > landuse96_28m is a CELL map, elevation FCELL. > >> 2. r.statistics uses r.stats to calculate the statistics, and r.stats >> reads its inputs as CELL. > > In this case, r.statistics could also accept an FCELL map > without complaining? Currently I need extra steps to round > elevation to a CELL map before running r.statistics. > >> r.stats is inherently based upon discrete categories. Even if it reads >> FP maps as FP, you would need to quantise the values, otherwise you >> would end up with every cell as its own category with count == 1. This >> would require memory proportional to the size of the input map >> multiplied by a significant factor (48-64 bytes per cell, or even >> more). >> >> To handle FP data, you really need a completely new approach which >> computes aggregates incrementally, using an accumulator. This would >> limit it to aggregates which can be computed that way, e.g. count, >> sum, mean, variance and standard deviation. > > I darkly remember that Soeren has something already in the works. I have implemented r3.stats from scratch to handle fp ranges: GRASS 6.3.cvs > r3.stats help Description: Generates volume statistics for raster3d maps. Keywords: raster3d, statistics Usage: r3.stats [-e] input=name [nsteps=value] [--verbose] [--quiet] Flags: -e Calculate statistics based on equal value groups --v Verbose module output --q Quiet module output Parameters: input Name of input raster3d map nsteps Number of sub-ranges to collect stats from default: 20 Example: #region north: 1000 south: 0 west: 0 east: 2000 top: 10.00000000 bottom: 0.00000000 nsres: 50 nsres3: 50 ewres: 50 ewres3: 50 tbres: 1 rows: 20 rows3: 20 cols: 40 cols3: 40 depths: 10 cells: 800 3dcells: 8000 # create a 3d map r3.mapcalc "map3d = depth()" # automatically calculated value range sub-groups GRASS 6.3.cvs > r3.stats map3d nsteps=5 100% num | minimum <= value | value < maximum | volume | perc | cell count 1 1.000000000 2.800000000 4000000.000 20.00000 1600 2 2.800000000 4.600000000 4000000.000 20.00000 1600 3 4.600000000 6.400000000 4000000.000 20.00000 1600 4 6.400000000 8.200000000 4000000.000 20.00000 1600 5 8.200000000 10.000000001 4000000.000 20.00000 1600 6 * * 0.000 0.00000 0 Sum of non Null cells: Volume = 20000000.000 Percentage = 100.000 Cell count = 8000 Sum of all cells: Volume = 20000000.000 Percentage = 100.000 Cell count = 8000 # groups of equal values GRASS 6.3.cvs > r3.stats -e map3d 100% Sort non-null values num | value | volume | perc | cell count 1 1.000000 2000000.000 10.00000 800 2 2.000000 2000000.000 10.00000 800 3 3.000000 2000000.000 10.00000 800 4 4.000000 2000000.000 10.00000 800 5 5.000000 2000000.000 10.00000 800 6 6.000000 2000000.000 10.00000 800 7 7.000000 2000000.000 10.00000 800 8 8.000000 2000000.000 10.00000 800 9 9.000000 2000000.000 10.00000 800 10 10.000000 2000000.000 10.00000 800 11 * 0.000 0.00000 0 Number of groups with equal values: 10 Sum of non Null cells: Volume = 20000000.000 Percentage = 100.000 Cell count = 8000 Sum of all cells: Volume = 20000000.000 Percentage = 100.000 Cell count = 8000 The approach is based on binary tree search algorithm. The memory consumption increases with the number of sub-ranges or the number of groups of equal values. The map does not need to be read completely in memory. AFAICT the sub-range search algorithm has an O(nlog(n)) complexity. I guess the equal value computation can be improved, because the computation time increases with the number of detected equal value groups. S?ren > >> [The last two would need to either use the one-pass algorithm (which >> can result in negative variance for near-constant data due to rounding >> error), or use two passes (computing the mean in the first pass so >> that the actual deviations can be used in the second pass). See also: >> the history of r.univar.] >> >> As I've mentioned several times before, computing quantiles (e.g. >> median) of large amounts of floating-point data is an open-ended >> problem; any given approach has both pros and cons. >> >> -- >> Glynn Clements > > Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From neteler at itc.it Sat Jun 2 15:20:46 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Jun 2 15:20:47 2007 Subject: [GRASS-dev] make pdfdocs error In-Reply-To: <20070603000729.71a70394.hamish_nospam@yahoo.com> References: <20070603000729.71a70394.hamish_nospam@yahoo.com> Message-ID: <20070602132046.GG4917@bartok.itc.it> On Sun, Jun 03, 2007 at 12:07:29AM +1200, Hamish wrote: > Hi, > > [6.3cvs] > > $ make pdfdocs > ... > make[2]: Leaving directory `/usr/local/src/grass/grass63/lib/vector/dglib/latex' > PDF reference in directory ./latex/grass63dglib_2007_06_02_refman.pdf > make[1]: Leaving directory `/usr/local/src/grass/grass63/lib/vector/dglib' > (cd rfc/ ; make cleandocs ; make pdfdocs) > make[1]: Entering directory `/usr/local/src/grass/grass63/rfc' > rm -fr latex/ html/ > make[1]: Leaving directory `/usr/local/src/grass/grass63/rfc' > make[1]: Entering directory `/usr/local/src/grass/grass63/rfc' > make[1]: *** No rule to make target `pdfdocs'. Stop. > make[1]: Leaving directory `/usr/local/src/grass/grass63/rfc' > make: *** [pdfdocs] Error 2 Fixed. Markus From tutey at o2.pl Sat Jun 2 15:51:19 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sat Jun 2 15:51:35 2007 Subject: [GRASS-dev] [bug #2969] can wxPython GUI handle order of options for v.type and alike? In-Reply-To: References: <18004.56105.508529.519878@cerise.gclements.plus.com> <18005.62563.693102.109472@cerise.gclements.plus.com> <20070525172309.5e58ca89.hamish_nospam@yahoo.com> <4659F221.4030601@o2.pl> <20070528153226.30e471a6.hamish_nospam@yahoo.com> <465AF7F4.8050608@o2.pl> <20070529173542.2238a335.hamish_nospam@yahoo.com> <465BC1F7.9060103@o2.pl> <465C8F97.5080301@o2.pl> Message-ID: <466175D7.8000209@o2.pl> Martin Landa wrote: > 2007/5/29, Maciej Sieczka : >> $ time v.type in=mlns out=mlns_type_once >> type=point,centroid,line,boundary >> >> real 6m37.459s >> user 6m12.191s >> sys 0m23.673s >> >> >> $ time `v.type in=mlns out=mlns_type_first type=point,centroid; v.type >> in=mlns_type_first out=mlns_type_second type=point,centroid` > just stupid note -- shouldn't be ? > > time `v.type in=mlns out=mlns_type_first type=point,centroid; v.type > in=mlns_type_first out=mlns_type_second type=****line,boundary****` Not a stupid question at all. Thanks for pointing out my error. Having corrected the options I have tried again, on another machine. It shows that "v.type type=point,centroid,line,boundary" is about 35% faster than "v.type type=point,centroid; v.type type=line,boundary": $ time `v.type in=mlns out=mlns_type_once type=point,centroid,line,boundary` real 5m43.485s user 5m26.012s sys 0m12.829s $ time `v.type in=mlns out=mlns_type_first type=point,centroid; v.type in=mlns_type_first out=mlns_type_second type=line,boundary` real 8m42.153s user 8m6.122s sys 0m24.562s In that case, I think that eventual implementation of the new v.type scheme in GRASS 7 should be re-considered. Maciek From jachym.cepicky at gmail.com Sat Jun 2 17:51:33 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Sat Jun 2 17:51:39 2007 Subject: [GRASS-dev] gdal --with-grass on solaris Message-ID: hi, I try co compile GDAL --with-grass support on SunOS ul-wrk2 5.10 Generic_118833-03 sun4u sparc SUNW,A70 Solaris gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath) GNU Make 3.80 automake (GNU automake) 1.8.3 autoconf (GNU Autoconf) 2.59 and it does not work: 1) I managed to compile gdal with ./configure make make install 2) I managed to install grass with ./configure --with-proj-libs=/usr/local/lib/ --with-postgres-includes=/usr/local/pgsql/include/ --with-postgres-libs=/usr/local/pgsql/lib/ --without-fftw --with-tcltk-includes=/usr/local/include/ --with-tcltk-libs=/usr/local/lib/ make make install 3) I would like to install gdal --with-grass, however ./configure --with-grass=/usr/local/grass-6.2.2RC1/ [....] checking dynamic linker characteristics... f90: Warning: Option -print-search-dirs passed to ld, if ld is invoked, ignored otherwise Usage: f90 [ options ] files. Use 'f90 -flags' for details solaris2.10 ld.so [....] checking for pg_config... no checking for PostgreSQL... no checking for G_asprintf in -lgrass_gis... no configure: error: --with-grass=/usr/local/grass-6.2.2RC1/ requested, but libraries not found! but ls /usr/local/grass-6.2.2RC1/ bin bwidget docs driver etc fonts include lib man scripts and echo $LD_LIBRARY_PATH /usr/local/grass-6.2.2RC1/lib/ could anybody give me advice, how to approach on this operating system? On linux, it works :-/ Thanks Jachym -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub From dylan.beaudette at gmail.com Sun Jun 3 00:22:23 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Sun Jun 3 00:20:27 2007 Subject: [GRASS-dev] small patch for lib/vector/transform/ In-Reply-To: <18017.22045.142647.679148@cerise.gclements.plus.com> References: <200706011233.55044.dylan.beaudette@gmail.com> <18017.22045.142647.679148@cerise.gclements.plus.com> Message-ID: <200706021522.23243.dylan.beaudette@gmail.com> Hi Glynn, thanks for the pointers. Still a relatively new user of the conventional dev tools... On Saturday 02 June 2007 04:35, Glynn Clements wrote: > Dylan Beaudette wrote: > > I needed some functionality to print the transformation matrix, very > > simple patch - it might be useful to others. > > > > It prints out the matrix along with a small note: > > > > Transformation Matrix > > --------------------- > > 28155.882288 0.013530 1.002469 > > -5301.399323 0.997547 -0.009172 > > --------------------- > > > > the patch is attached. > > > > Perhaps diagnostics like this might be a general use. > > > > > > -- > > Dylan Beaudette > > Soils and Biogeochemistry Graduate Group > > University of California at Davis > > 530.754.7341 > > Index: lib/vector/transform/transform.c > > =================================================================== > > RCS file: > > /home/grass/grassrepository/grass6/lib/vector/transform/transform.c,v > > retrieving revision 1.2 > > diff -r1.2 transform.c > > 146a147,152 > > > > > printf("Transformation Matrix\n"); > > > printf("------------------------------------------\n"); > > > printf("%f %f %f \n", B0, B1, B2); > > > printf("%f %f %f \n", B3, B4, B5); > > > printf("------------------------------------------\n"); > > First, patches should use either unified or context format (preferably > unified). However ... ok, I will read up on how to do this. > Library code shouldn't be unconditionally printing diagnostic > information (especially not to stdout); use G_debug() instead. good call, that was definitely bad style on my part. Instead of debug, a flag might be a good option? > If you need to print this information in normal use (without debugging > enabled), add a separate get_transformation_matrix() function to that > file. This sounds reasonable. If possible it might be nice as a flag to v.transform. > Alternatively, you can implement it within your module using > transform_b_into_a(), i.e.: > > double B0, B1, B2, B3, B4, B5; > > transform_b_into_a(0, 0, &B0, &B3); > transform_b_into_a(1, 0, &B1, &B4); > B1 -= B0; B4 -= B3; > transform_b_into_a(0, 1, &B2, &B5); > B2 -= B0; B5 -= B3; I will submit the new patch to the tracker. thanks! -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 From grass-codep at wald.intevation.org Sun Jun 3 00:29:03 2007 From: grass-codep at wald.intevation.org (grass-codep@wald.intevation.org) Date: Sun Jun 3 00:27:27 2007 Subject: [GRASS-dev] [grass-code P][416] print transformation matrix after running v.transform Message-ID: <20070602222903.6E0E012D4EC@pyrosoma.intevation.org> code P item #416, was opened at 2007-06-02 15:29 Status: Open Priority: 3 Submitted By: Dylan Beaudette (dylan) Assigned to: Nobody (None) Summary: print transformation matrix after running v.transform Patch status: None Patch type: enhancement GRASS component: vector GRASS version: CVS HEAD GRASS CVS checkout date, if applies (YYMMDD): 2007-0 Initial Comment: small patch to v.transform/main.c and lib/vector/transform/transform.c which adds a flag to v.transform that will print the affine transformation matrix to stdout. This is a convinience enhancement for those who would like to inspect the matrix. This patch has been tested, and appears to work well. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=205&aid=416&group_id=21 From grass-codep at wald.intevation.org Sun Jun 3 00:43:34 2007 From: grass-codep at wald.intevation.org (grass-codep@wald.intevation.org) Date: Sun Jun 3 00:41:57 2007 Subject: [GRASS-dev] [grass-code P][417] update to documentation for v.transform Message-ID: <20070602224334.8C88512D4EC@pyrosoma.intevation.org> code P item #417, was opened at 2007-06-02 15:43 Status: Open Priority: 3 Submitted By: Dylan Beaudette (dylan) Assigned to: Nobody (None) Summary: update to documentation for v.transform Patch status: None Patch type: enhancement GRASS component: vector GRASS version: CVS HEAD GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: some extra information for the v.transform manual page ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=205&aid=417&group_id=21 From glynn at gclements.plus.com Sun Jun 3 04:58:40 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jun 3 04:58:44 2007 Subject: [GRASS-dev] r.statistics limitation to CELL In-Reply-To: <20070602120556.GE4917@bartok.itc.it> References: <20070602075753.GA4917@bartok.itc.it> <18017.23500.221622.148504@cerise.gclements.plus.com> <20070602120556.GE4917@bartok.itc.it> Message-ID: <18018.11872.630274.300840@cerise.gclements.plus.com> Markus Neteler wrote: > > > would it be much work to fix this: > > > > > > GRASS 6.3.cvs (nc_spm_05):~ > r.statistics base=landuse96_28m \ > > > cover=elevation out=elevstats_avg method=average > > > ERROR: This module currently only works for integer (CELL) maps > > > > > > Rounding elevation to CELL first isn't a great option. > > > > 1. r.statistics works by reclassing the base map, so the base map > > can't be FP. > > In this case I meant the cover map "elevation" which is rejected. > landuse96_28m is a CELL map, elevation FCELL. > > > 2. r.statistics uses r.stats to calculate the statistics, and r.stats > > reads its inputs as CELL. > > In this case, r.statistics could also accept an FCELL map > without complaining? Currently I need extra steps to round > elevation to a CELL map before running r.statistics. You should be able to simply remove the check at raster/r.statistics/main.c:83: if( G_raster_map_is_fp(covermap->answer, mapset) != 0 ) G_fatal_error (_("This module currently only works for integer (CELL) maps")); Or you might want to replace the error with a warning that the result is inaccurate. -- Glynn Clements From glynn at gclements.plus.com Sun Jun 3 05:12:38 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jun 3 05:12:41 2007 Subject: [GRASS-dev] small patch for lib/vector/transform/ In-Reply-To: <200706021522.23243.dylan.beaudette@gmail.com> References: <200706011233.55044.dylan.beaudette@gmail.com> <18017.22045.142647.679148@cerise.gclements.plus.com> <200706021522.23243.dylan.beaudette@gmail.com> Message-ID: <18018.12710.147798.730948@cerise.gclements.plus.com> Dylan Beaudette wrote: > > First, patches should use either unified or context format (preferably > > unified). However ... > > ok, I will read up on how to do this. Add the -u or -c flags to "diff" or "cvs diff". For CVS, you can add "diff -u" to ~/.cvsrc to make it the default. Some useful ~/.cvsrc settings: cvs -z3 checkout -P update -dP diff -u > > Library code shouldn't be unconditionally printing diagnostic > > information (especially not to stdout); use G_debug() instead. > > good call, that was definitely bad style on my part. Instead of debug, a flag > might be a good option? Within the module, you can use G_verbose_message() for messages which should only printed when --verbose is used. Or you could add a specific flag. The main point is that library code shouldn't have undesirable side-effects. What is desirable varies between modules, so library functions generally shouldn't do anything "extra"; that should be done by individual modules. -- Glynn Clements From neteler at itc.it Sun Jun 3 13:03:02 2007 From: neteler at itc.it (Markus Neteler) Date: Sun Jun 3 13:03:04 2007 Subject: [GRASS-dev] r.statistics limitation to CELL In-Reply-To: <18018.11872.630274.300840@cerise.gclements.plus.com> References: <20070602075753.GA4917@bartok.itc.it> <18017.23500.221622.148504@cerise.gclements.plus.com> <20070602120556.GE4917@bartok.itc.it> <18018.11872.630274.300840@cerise.gclements.plus.com> Message-ID: <20070603110302.GB22316@bartok.itc.it> On Sun, Jun 03, 2007 at 03:58:40AM +0100, Glynn Clements wrote: > Markus Neteler wrote: > > Glynn Clements wrote: > > > 2. r.statistics uses r.stats to calculate the statistics, and r.stats > > > reads its inputs as CELL. > > > > In this case, r.statistics could also accept an FCELL map > > without complaining? Currently I need extra steps to round > > elevation to a CELL map before running r.statistics. > > You should be able to simply remove the check at > raster/r.statistics/main.c:83: > > if( G_raster_map_is_fp(covermap->answer, mapset) != 0 ) > G_fatal_error (_("This module currently only works for integer (CELL) maps")); > > Or you might want to replace the error with a warning that the result > is inaccurate. If so, the latter. Currently I have to round() the elevation map before running r.statistics - so results are inaccurate anyway but the procedure requires more extra work. The master question is: is it possible to conditionalize calls in r3.stats to make it working for 2D maps. The new implementation from Soeren sounds promising and along the lines of your suggestion to rewrite r.stats from scratch. Markus From soerengebbert at gmx.de Mon Jun 4 02:08:20 2007 From: soerengebbert at gmx.de (=?ISO-8859-1?Q?S=F6ren_Gebbert?=) Date: Mon Jun 4 02:09:00 2007 Subject: [GRASS-dev] r.statistics limitation to CELL In-Reply-To: <20070603110302.GB22316@bartok.itc.it> References: <20070602075753.GA4917@bartok.itc.it> <18017.23500.221622.148504@cerise.gclements.plus.com> <20070602120556.GE4917@bartok.itc.it> <18018.11872.630274.300840@cerise.gclements.plus.com> <20070603110302.GB22316@bartok.itc.it> Message-ID: <466357F4.1070404@gmx.de> Hi, Markus Neteler schrieb: > On Sun, Jun 03, 2007 at 03:58:40AM +0100, Glynn Clements wrote: >> Markus Neteler wrote: >>> Glynn Clements wrote: >>>> 2. r.statistics uses r.stats to calculate the statistics, and r.stats >>>> reads its inputs as CELL. >>> In this case, r.statistics could also accept an FCELL map >>> without complaining? Currently I need extra steps to round >>> elevation to a CELL map before running r.statistics. >> You should be able to simply remove the check at >> raster/r.statistics/main.c:83: >> >> if( G_raster_map_is_fp(covermap->answer, mapset) != 0 ) >> G_fatal_error (_("This module currently only works for integer (CELL) maps")); >> >> Or you might want to replace the error with a warning that the result >> is inaccurate. > > If so, the latter. Currently I have to round() the elevation map > before running r.statistics - so results are inaccurate anyway > but the procedure requires more extra work. > > The master question is: is it possible to conditionalize calls in > r3.stats to make it working for 2D maps. The new implementation from > Soeren sounds promising and along the lines of your suggestion to > rewrite r.stats from scratch. The range and equal value group algorithm in r3.stats is generic, so it is not complicated to extend r3.stats with raster support. It is possible to call the statistic creation and computation functions in r3.stats for every double/float array of which volume/area statistics should be computed with very tiny modifications (eg: area instead of volume computation). It is mostly independently from raster, volume or what ever maps. But to implement all the nice features of r.stats in r3.stats is not that easy. I have currently no time to implement this. :( Currently more important for me is to finish the core design of the gpde library and to implement a faster preconditioned conjugate gradient solver (pcg) for better numerical stability in v.surf.rst. And to check the stability of the gpde lib to work with multiple threads (which is not easy). Best regards Soeren > > Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From michael.barton at asu.edu Mon Jun 4 07:28:20 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Jun 4 07:28:49 2007 Subject: [GRASS-dev] new source code search tool Message-ID: Poking around at Google this evening, I came across a new tool being previewed in Google Labs. It searches public source code. I put in a piece of the tcltk code and found a lot of old code floating around. Give it a try. http://www.google.com/codesearch?hl=en Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070603/59a500c0/attachment.html From glynn at gclements.plus.com Mon Jun 4 10:04:15 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jun 4 10:04:18 2007 Subject: [GRASS-dev] r.statistics limitation to CELL In-Reply-To: <20070603110302.GB22316@bartok.itc.it> References: <20070602075753.GA4917@bartok.itc.it> <18017.23500.221622.148504@cerise.gclements.plus.com> <20070602120556.GE4917@bartok.itc.it> <18018.11872.630274.300840@cerise.gclements.plus.com> <20070603110302.GB22316@bartok.itc.it> Message-ID: <18019.51071.620951.630720@cerise.gclements.plus.com> Markus Neteler wrote: > > > > 2. r.statistics uses r.stats to calculate the statistics, and r.stats > > > > reads its inputs as CELL. > > > > > > In this case, r.statistics could also accept an FCELL map > > > without complaining? Currently I need extra steps to round > > > elevation to a CELL map before running r.statistics. > > > > You should be able to simply remove the check at > > raster/r.statistics/main.c:83: > > > > if( G_raster_map_is_fp(covermap->answer, mapset) != 0 ) > > G_fatal_error (_("This module currently only works for integer (CELL) maps")); > > > > Or you might want to replace the error with a warning that the result > > is inaccurate. > > If so, the latter. Currently I have to round() the elevation map > before running r.statistics - so results are inaccurate anyway > but the procedure requires more extra work. But if you round() manually, you know that you're introducing inaccuracy, hence the suggestion of a warning if you allow r.stats to do it automatically. > The master question is: is it possible to conditionalize calls in > r3.stats to make it working for 2D maps. The new implementation from > Soeren sounds promising and along the lines of your suggestion to > rewrite r.stats from scratch. I don't know how r3.stats works. However, if we were to re-write something, it would probably be better to re-write r.statistics to avoid using r.stats than to re-write r.stats itself. r.stats has other uses beyond being a back-end for r.statistics. r.statistics is a simpler case, as I would expect the number of distinct categories in the base map to be low enough that you could comfortably store an accumulator per category. To simplify matters futher, I would use a linear array, indexed by base category, rather than an associative array (btree, hash table etc). Base categories would normally be small non-negative integers (i.e. suitable for use as indices), and if they aren't (i.e. the allocation is sparse or includes negative values), you can always "renumber" the categories using a reclass, e.g.: r.stats -n $inmap | awk '{print $1,"=",NR-1}' | r.reclass input=$inmap output=$outmap Finally, it may be better to move the "awkward" aggregates (median, mode) to a separate module, as the algorithms involved are completely different. It would probably be worth offering a choice of a single- or multiple-pass algorithm. Count, sum, mean, minimum and maximum only require a single pass. AFAICT, variance, standard deviation, skew and kurtosis can all be done in a single pass, but a multiple-pass algorithm would be more accurate. Actually, computing the mode of a large amount of FP data (or integer data with a large range) is even worse than computing quantiles. AFAICT, any general solution must have worst-case memory consumption proportional to either the number of cells in the input map or the number of possible values (i.e. 2^32 for CELL/FCELL, 2^64 for DCELL). For a large map with a small range, you need one counter for each possible value. For a map with a large range, the optimal solution is to simply sort the input map then scan the sorted data while tracking the most common value found to data. For a DCELL map which is too large to fit into memory, the only practical solution is to reduce the precision. -- Glynn Clements From hamish_nospam at yahoo.com Mon Jun 4 10:14:57 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 4 10:15:12 2007 Subject: [GRASS-dev] small patch for lib/vector/transform/ In-Reply-To: <18018.12710.147798.730948@cerise.gclements.plus.com> References: <200706011233.55044.dylan.beaudette@gmail.com> <18017.22045.142647.679148@cerise.gclements.plus.com> <200706021522.23243.dylan.beaudette@gmail.com> <18018.12710.147798.730948@cerise.gclements.plus.com> Message-ID: <20070604201457.0068fffd.hamish_nospam@yahoo.com> Dylan: > > good call, that was definitely bad style on my part. Instead of > > debug, a flag might be a good option? Glynn: > Within the module, you can use G_verbose_message() for messages which > should only printed when --verbose is used. Or you could add a > specific flag. Output intended to be parsable should use fprintf(stdout, "..." ,,,); G_*_message() and G_debug() will output to stderr and are more for messages than outputing data. A flag for output is a nice idea, whichever stdout or stderr you feel is more appropriate. Hamish From hamish_nospam at yahoo.com Mon Jun 4 10:17:13 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 4 10:17:22 2007 Subject: [GRASS-dev] compiling error in grass-6.2.2RC1 with gdal-1.4.1 support In-Reply-To: <200706021514.27129.muratasenel@gmail.com> References: <200706021514.27129.muratasenel@gmail.com> Message-ID: <20070604201713.78e01e57.hamish_nospam@yahoo.com> Murat ??enel wrote: > > I am the package maintainer of grass on Pardus GNU/Linux and I get the > error below while trying to compile grass-6.2.2RC1 with gdal-1.4.1 > support. > > checking whether to use GDAL... yes > checking for gdal-config... /usr/bin/gdal-config > checking for GDALOpen... no > checking for GDALOpen... no > configure: error: *** Unable to locate GDAL library. > > Any help would be appreciated. Can you see what the test-compile error was? You can find that at the end of config.log. Hamish From hamish_nospam at yahoo.com Mon Jun 4 10:50:56 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 4 10:51:03 2007 Subject: [GRASS-dev] [bug #2969] can wxPython GUI handle order of options for v.type and alike? In-Reply-To: <466175D7.8000209@o2.pl> References: <18004.56105.508529.519878@cerise.gclements.plus.com> <18005.62563.693102.109472@cerise.gclements.plus.com> <20070525172309.5e58ca89.hamish_nospam@yahoo.com> <4659F221.4030601@o2.pl> <20070528153226.30e471a6.hamish_nospam@yahoo.com> <465AF7F4.8050608@o2.pl> <20070529173542.2238a335.hamish_nospam@yahoo.com> <465BC1F7.9060103@o2.pl> <465C8F97.5080301@o2.pl> <466175D7.8000209@o2.pl> Message-ID: <20070604205056.2f020c87.hamish_nospam@yahoo.com> Maciej Sieczka wrote: > Having corrected the options I have tried again, on another machine. > It shows that "v.type type=point,centroid,line,boundary" is about 35% > faster than "v.type type=point,centroid; v.type type=line,boundary": the extra time overhead is because it has to open and close the map(s) an extra time. [Cost]/benefit: the extra time cost should be considered both in light of 1) how often a user wants to pack multiple conversions on the same command line (rare <-?-> common), and 2) how big the time penalty is (including how likely it is the module is to be used within a script where the extra time is likely to be a significant proportion of the iteration). My feeling WRT this time cost is that multiple conversions at once is probably more rare than common, and the extra few seconds time penalty when dealing with vector maps containing millions of features is tiny in comparison to anything else you will do with a map of that size. Considering it as just time a > time b is only one part of the story. To be honest I am much more curious about the shadow of the functionality change than the small time change. In my mind the benefits of a simple + easy to use and understand interface outweighs this small dt cost; or the cost of rewriting/ rethinking the parser logic (when only 2 of 393 modules are problematic). Hamish From neteler at itc.it Mon Jun 4 14:54:15 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Jun 4 14:54:17 2007 Subject: [GRASS-dev] SQLite driver now with transactions Message-ID: <20070604125415.GB4703@bartok.itc.it> Hi, thanks to Antonio Galea, we now have SQL transactions in the SQLite driver which speeds up "execute" for large attribute tables: ### EXECUTE, SQLite driver # TEST 1: geodetic_pts, 13 columns, points=29939 # without transactions, points map time g.copy vect=geodetic_pts,ggg real 0m8.076s user 0m4.135s sys 0m5.182s # with transactions, points map time g.copy vect=geodetic_pts,ggg2 real 0m7.789s user 0m4.192s sys 0m5.424s ##### # TEST 2: streets_wake, 35 columns, lines=49746 # without transactions, lines map time g.copy vect=streets_wake,ggg2 real 0m22.692s user 0m11.685s sys 0m15.315s # with transactions, lines map time g.copy vect=geodetic_pts,ggg2 real 0m7.663s user 0m4.101s sys 0m4.327s ##### # TEST 3, soils_wake, 7 columns, areas=47156 # without transactions, area map time g.copy vect=soils_wake,ggg2 real 0m9.856s user 0m4.940s sys 0m5.837s # with transactions, area map time g.copy vect=soils_wake,ggg2 real 0m10.208s user 0m4.986s sys 0m6.319s The improvement is (naturally) significant when you have (a) large attribute table(s) attached to the vector map. Markus From neteler at itc.it Mon Jun 4 15:23:05 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Jun 4 15:23:07 2007 Subject: [GRASS-dev] QGIS winGRASS blank space problem Message-ID: <20070604132305.GE4703@bartok.itc.it> Hi, a friend told me that with the latest QGIS release candidate, there is a winGRASS problem: $ v.rast.stats vector=CEA_riserve raster=CEA_slope colprefix=delete c:/Programmi/Quantum: c:/Programmi/Quantum: No such file or directory He uses a path with space: c:/Programmi/Quantum GIS/ ^ Is that a GRASS problem? Where to fix? To me it looks like ./scripts/windows_launch.bat but there it is quoted. If he changes the path to not include a white space, he gets: $ v.rast.stats vector=CEA_riserve raster=CEA_slope colprefix=delete 0 [main] sh 5080 open_stackdumpfile: Dumping stack trace to sh.exe.stackdump An error occurred reading the input raster map resolution. Clueless, Markus From cavallini at faunalia.it Mon Jun 4 15:31:11 2007 From: cavallini at faunalia.it (Paolo Cavallini) Date: Mon Jun 4 15:31:21 2007 Subject: [GRASS-dev] QGIS winGRASS blank space problem In-Reply-To: <20070604132305.GE4703@bartok.itc.it> References: <20070604132305.GE4703@bartok.itc.it> Message-ID: <4664141F.2020604@faunalia.it> As far as I remember, it is a known bug, that appears when qgis is installed in a path with spaces. pc Markus Neteler ha scritto: > Hi, > > a friend told me that with the latest QGIS release candidate, > there is a winGRASS problem: > > $ v.rast.stats vector=CEA_riserve raster=CEA_slope colprefix=delete > c:/Programmi/Quantum: c:/Programmi/Quantum: No such file or directory > > He uses a path with space: > c:/Programmi/Quantum GIS/ > ^ > > Is that a GRASS problem? Where to fix? To me it looks like > ./scripts/windows_launch.bat but there it is quoted. > > If he changes the path to not include a white space, > he gets: > > $ v.rast.stats vector=CEA_riserve raster=CEA_slope colprefix=delete > 0 [main] sh 5080 open_stackdumpfile: Dumping stack trace to sh.exe.stackdump > An error occurred reading the input raster map resolution. > > Clueless, > Markus -- 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/20070604/0f758d1a/signature.bin From neteler at itc.it Mon Jun 4 15:45:33 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Jun 4 15:45:36 2007 Subject: [GRASS-dev] QGIS winGRASS blank space problem In-Reply-To: <20070604132305.GE4703@bartok.itc.it> References: <20070604132305.GE4703@bartok.itc.it> Message-ID: <10950079.post@talk.nabble.com> Markus Neteler wrote: > > ... > If he changes the path to not include a white space, > he gets: > > $ v.rast.stats vector=CEA_riserve raster=CEA_slope colprefix=delete > 0 [main] sh 5080 open_stackdumpfile: Dumping stack trace to > sh.exe.stackdump > An error occurred reading the input raster map resolution. > Update: the latter problem goes away if QGIS is *reinstalled* into a path without white space. Remains the problem that it fails with white space which is pretty common on MS-Windows systems (and apparently the default of the QGIS installer). Markus -- View this message in context: http://www.nabble.com/QGIS-winGRASS-blank-space-problem-tf3865213.html#a10950079 Sent from the Grass - Dev mailing list archive at Nabble.com. From grass-codei at wald.intevation.org Mon Jun 4 16:27:38 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Mon Jun 4 16:27:01 2007 Subject: [GRASS-dev] [grass-code I][419] v.rast.stats fails for some features Message-ID: <20070604142738.D4EF5400A9@pyrosoma.intevation.org> code I item #419, was opened at 04/06/2007 14:27 Status: Open Priority: 3 Submitted By: Ferdi Urbano (feurbano) Assigned to: Nobody (None) Summary: v.rast.stats fails for some features Issue type: module bug Issue status: None GRASS version: None GRASS component: vector Operating system: Windows Operating system version: windows xp GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: v.rast.stats fails to update values for some (random?) features: in the "UPDATE myfields SET =1331 WHERE cat=9" strings, the field name is not included. ----------------- $ v.rast.stats myfields raster=elevation.dem colprefix=dem Adding column Adding column Adding column Adding column Adding column Adding column Adding column Adding column Adding column Processing category 1 (1/63) Processing category 2 (2/63) Processing category 3 (3/63) Processing category 4 (4/63) Processing category 5 (5/63) Processing category 6 (6/63) Processing category 7 (7/63) Processing category 8 (8/63) Processing category 9 (9/63) 0 [main] sh 26540 open_stackdumpfile: Dumping stack trace to sh.exe.stackd ump DBMI-DBF driver error: SQL parser error in statement: UPDATE myfields SET =1331 WHERE cat=9 Error in db_execute_immediate() ERROR: Error while executing: "UPDATE myfields SET =1331 WHERE cat=9" Processing category 10 (10/63) Processing category 11 (11/63) ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=419&group_id=21 From paul-grass at stjohnspoint.co.uk Mon Jun 4 16:36:16 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Jun 4 16:36:24 2007 Subject: [GRASS-dev] QGIS winGRASS blank space problem In-Reply-To: <20070604132305.GE4703@bartok.itc.it> References: <20070604132305.GE4703@bartok.itc.it> Message-ID: Hello Markus On Mon, 4 Jun 2007, Markus Neteler wrote: > Hi, > > a friend told me that with the latest QGIS release candidate, > there is a winGRASS problem: > > $ v.rast.stats vector=CEA_riserve raster=CEA_slope colprefix=delete > c:/Programmi/Quantum: c:/Programmi/Quantum: No such file or directory v.rast.stats is a shell script, so you are likely to have loads of problems if not finding it nearly impossible to get it working properly on Windows. I notice there are loads of places in it that paths aren't quoted so that is probably the first problem (although to be fair that is also a problem for Unix and isn't a problem for Windows if you don't install software in paths with spaces in them!). Then there is the fact that Msys doesn't understand Windows-style paths, but the output from g.tempfile will be a Windows-style path. (A question for another day: perhaps we could investigate other bourne-compatible shells for Windows that *do* understand Windows paths? But some GRASS scripts would probably need to be changed in other ways to be compatible with that; maybe more effort than it's worth.) Another thing is that v.rast.stats attempts to call v.db.addcol and fails - it's also a script, so on Windows is represented by the file v.db.addcol.bat - apparently Msys's shell can't run .bat files. That's actually something I didn't forsee when implementing the .bat script-launching mechanism for Windows. You could probably work around it by putting in the full path ($GISBASE/scripts) before calling another script from a script, but then you still have the issue with incompatible path names as I mentioned above. In general it's a pleasant surprise if some shell scripts to happen to work OK on Windows, and IMHO shouldn't really be considered a bug if they don't. I feel the fact that QGIS includes a copy of Msys with GRASS gives the "illusion" of GRASS being more compatible with Windows than it really is - the truly native WinGRASS we're working on is a more accurate expression of GRASS's compatiblity with Windows as I see it. Paul From frankie at debian.org Mon Jun 4 16:57:26 2007 From: frankie at debian.org (Francesco P. Lovergine) Date: Mon Jun 4 17:01:05 2007 Subject: [GRASS-dev] QGIS winGRASS blank space problem In-Reply-To: References: <20070604132305.GE4703@bartok.itc.it> Message-ID: <20070604145726.GF16954@mithrandir> On Mon, Jun 04, 2007 at 03:36:16PM +0100, Paul Kelly wrote: > In general it's a pleasant surprise if some shell scripts to happen to > work OK on Windows, and IMHO shouldn't really be considered a bug if they > don't. I feel the fact that QGIS includes a copy of Msys with GRASS gives > the "illusion" of GRASS being more compatible with Windows than it really > is - the truly native WinGRASS we're working on is a more accurate > expression of GRASS's compatiblity with Windows as I see it. > Isn't that the case to try re-writing those scripts in Tcl which has the suitable path helpers to be independent from the platform? Just my 2 cents... -- Francesco P. Lovergine From michael.barton at asu.edu Mon Jun 4 17:45:18 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Jun 4 17:45:24 2007 Subject: [GRASS-dev] [bug #2969] can wxPython GUI handle order of options for v.type and alike? In-Reply-To: <20070604205056.2f020c87.hamish_nospam@yahoo.com> Message-ID: I agree with Hamish about the analysis of costs and benefits here. Michael On 6/4/07 1:50 AM, "Hamish" wrote: > Maciej Sieczka wrote: >> Having corrected the options I have tried again, on another machine. >> It shows that "v.type type=point,centroid,line,boundary" is about 35% >> faster than "v.type type=point,centroid; v.type type=line,boundary": > > > the extra time overhead is because it has to open and close the map(s) > an extra time. > > > [Cost]/benefit: the extra time cost should be considered both in light > of 1) how often a user wants to pack multiple conversions on the same > command line (rare <-?-> common), and 2) how big the time penalty is > (including how likely it is the module is to be used within a script > where the extra time is likely to be a significant proportion of the > iteration). > > My feeling WRT this time cost is that multiple conversions at once is > probably more rare than common, and the extra few seconds time penalty > when dealing with vector maps containing millions of features is tiny in > comparison to anything else you will do with a map of that size. > Considering it as just time a > time b is only one part of the story. > To be honest I am much more curious about the shadow of the > functionality change than the small time change. > > > In my mind the benefits of a simple + easy to use and understand > interface outweighs this small dt cost; or the cost of rewriting/ > rethinking the parser logic (when only 2 of 393 modules are > problematic). > > > Hamish > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From paul-grass at stjohnspoint.co.uk Mon Jun 4 17:46:16 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Jun 4 17:46:19 2007 Subject: [GRASS-dev] QGIS winGRASS blank space problem In-Reply-To: <20070604132305.GE4703@bartok.itc.it> References: <20070604132305.GE4703@bartok.itc.it> Message-ID: On Mon, 4 Jun 2007, Markus Neteler wrote: > Hi, > > a friend told me that with the latest QGIS release candidate, > there is a winGRASS problem: > > $ v.rast.stats vector=CEA_riserve raster=CEA_slope colprefix=delete > c:/Programmi/Quantum: c:/Programmi/Quantum: No such file or directory > > He uses a path with space: > c:/Programmi/Quantum GIS/ > ^ > > Is that a GRASS problem? Where to fix? To me it looks like OK I've looked into this a bit more and it seems there is indeed a problem but I don't think it's GRASS. More to do with the way the Msys shell interprets the path to the script passed to it by the Windows _spawnlp() function. It reminds me strongly of what Glynn was saying about the difference between a list of strings, and one string with spaces used as separators: http://grass.itc.it/pipermail/grass-dev/2007-May/031394.html I wonder if something like that is going on with the way the Msys shell is interpreting its command-line arguments, or with the way Windows is passing them to it. As proof of concept, the patch below seems to make it work, but putting quotes in when they shouldn't be needed is very ugly and might break it for non-Msys shells so I don't want to fix that. Paul Index: general/g.parser/main.c =================================================================== RCS file: /home/grass/grassrepository/grass6/general/g.parser/main.c,v retrieving revision 2.15 diff -u -r2.15 main.c --- main.c 8 Mar 2007 17:42:51 -0000 2.15 +++ main.c 4 Jun 2007 15:45:52 -0000 @@ -412,10 +412,13 @@ /* _spawnlp ( _P_OVERLAY, "sh", "sh", filename, "@ARGS_PARSED@", NULL ); */ int ret; char *shell = getenv("GRASS_SH"); + char *quotedfile; + + G_asprintf("edfile, "\"%s\"", filename); if( shell == NULL ) shell = "sh"; - ret = _spawnlp ( _P_WAIT, shell, shell, filename, "@ARGS_PARSED@", NULL); + ret = _spawnlp ( _P_WAIT, shell, shell, quotedfile, "@ARGS_PARSED@", NULL ); G_debug ( 1, "ret = %d", ret ); if ( ret == -1 ) { From paul-grass at stjohnspoint.co.uk Mon Jun 4 17:49:08 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Jun 4 17:49:15 2007 Subject: [GRASS-dev] QGIS winGRASS blank space problem In-Reply-To: <20070604145726.GF16954@mithrandir> References: <20070604132305.GE4703@bartok.itc.it> <20070604145726.GF16954@mithrandir> Message-ID: On Mon, 4 Jun 2007, Francesco P. Lovergine wrote: > On Mon, Jun 04, 2007 at 03:36:16PM +0100, Paul Kelly wrote: >> In general it's a pleasant surprise if some shell scripts to happen to >> work OK on Windows, and IMHO shouldn't really be considered a bug if they >> don't. I feel the fact that QGIS includes a copy of Msys with GRASS gives >> the "illusion" of GRASS being more compatible with Windows than it really >> is - the truly native WinGRASS we're working on is a more accurate >> expression of GRASS's compatiblity with Windows as I see it. >> > > Isn't that the case to try re-writing those scripts in Tcl which has > the suitable path helpers to be independent from the platform? > Just my 2 cents... Yes although re-writing in Python has already been mentioned on the list so that's probably the more likely solution. Paul From glynn at gclements.plus.com Mon Jun 4 18:09:53 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jun 4 18:09:58 2007 Subject: [GRASS-dev] QGIS winGRASS blank space problem In-Reply-To: References: <20070604132305.GE4703@bartok.itc.it> Message-ID: <18020.14673.312942.124098@cerise.gclements.plus.com> Paul Kelly wrote: > > a friend told me that with the latest QGIS release candidate, > > there is a winGRASS problem: > > > > $ v.rast.stats vector=CEA_riserve raster=CEA_slope colprefix=delete > > c:/Programmi/Quantum: c:/Programmi/Quantum: No such file or directory > > v.rast.stats is a shell script, so you are likely to have loads of > problems if not finding it nearly impossible to get it working properly on > Windows. I notice there are loads of places in it that paths aren't > quoted so that is probably the first problem (although to be fair that is > also a problem for Unix and isn't a problem for Windows if you don't > install software in paths with spaces in them!). That's certainly a fundamental problem; $TMP and $SQLTMP appear to be the most likely candidates. Regardless of Windows-specific issues, failure to quote variables which contain pathnames is a bug and needs to be fixed. AFAICT, $SQLTMP is unnecessary. You can just as easily use a subshell with its output piped directly to db.execute; no need for a temporary file. > Then there is the fact that Msys doesn't understand Windows-style paths, That's incorrect; MSys itself understands Windows paths, with either a forward or backward slash. However, there may be individual scripts which can't handle this. > In general it's a pleasant surprise if some shell scripts to happen to > work OK on Windows, and IMHO shouldn't really be considered a bug if they > don't. I feel the fact that QGIS includes a copy of Msys with GRASS gives > the "illusion" of GRASS being more compatible with Windows than it really > is - the truly native WinGRASS we're working on is a more accurate > expression of GRASS's compatiblity with Windows as I see it. Ultimately, if we're serious about GRASS on Windows, we need to make it a priority to migrate away from Bourne shell to something more portable (with Python being the obvious choice). -- Glynn Clements From dylan.beaudette at gmail.com Mon Jun 4 18:51:32 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Mon Jun 4 18:49:24 2007 Subject: [GRASS-dev] small patch for lib/vector/transform/ In-Reply-To: <20070604201457.0068fffd.hamish_nospam@yahoo.com> References: <200706011233.55044.dylan.beaudette@gmail.com> <18018.12710.147798.730948@cerise.gclements.plus.com> <20070604201457.0068fffd.hamish_nospam@yahoo.com> Message-ID: <200706040951.32570.dylan.beaudette@gmail.com> On Monday 04 June 2007 01:14, Hamish wrote: > Dylan: > > > good call, that was definitely bad style on my part. Instead of > > > debug, a flag might be a good option? > > Glynn: > > Within the module, you can use G_verbose_message() for messages which > > should only printed when --verbose is used. Or you could add a > > specific flag. > > Output intended to be parsable should use fprintf(stdout, "..." ,,,); This looks like the best approach: however, I am getting a compile error on 'stdout' not being defined... ideas? > G_*_message() and G_debug() will output to stderr and are more for > messages than outputing data. > > > A flag for output is a nice idea, whichever stdout or stderr you feel is > more appropriate. > I have implemented it as a flag. Patch is attached If this looks ok, I can re-submit it to the grass tracker thanks! -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 -------------- next part -------------- A non-text attachment was scrubbed... Name: v.transform.patch Type: text/x-diff Size: 4420 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070604/2ed3285a/v.transform.bin From dylan.beaudette at gmail.com Mon Jun 4 18:53:03 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Mon Jun 4 18:50:56 2007 Subject: [GRASS-dev] small patch for lib/vector/transform/ In-Reply-To: <18018.12710.147798.730948@cerise.gclements.plus.com> References: <200706011233.55044.dylan.beaudette@gmail.com> <200706021522.23243.dylan.beaudette@gmail.com> <18018.12710.147798.730948@cerise.gclements.plus.com> Message-ID: <200706040953.03563.dylan.beaudette@gmail.com> On Saturday 02 June 2007 20:12, Glynn Clements wrote: > Dylan Beaudette wrote: > > > First, patches should use either unified or context format (preferably > > > unified). However ... > > > > ok, I will read up on how to do this. > > Add the -u or -c flags to "diff" or "cvs diff". For CVS, you can add > "diff -u" to ~/.cvsrc to make it the default. > > Some useful ~/.cvsrc settings: > > cvs -z3 > checkout -P > update -dP > diff -u > > > > Library code shouldn't be unconditionally printing diagnostic > > > information (especially not to stdout); use G_debug() instead. > > > > good call, that was definitely bad style on my part. Instead of debug, a > > flag might be a good option? > > Within the module, you can use G_verbose_message() for messages which > should only printed when --verbose is used. Or you could add a > specific flag. > > The main point is that library code shouldn't have undesirable > side-effects. What is desirable varies between modules, so library > functions generally shouldn't do anything "extra"; that should be done > by individual modules. Thanks for the tips Glynn. I have re-submitted some new ideas to the dev list. -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 From michael.barton at asu.edu Mon Jun 4 20:48:46 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Jun 4 20:48:54 2007 Subject: [GRASS-dev] QGIS winGRASS blank space problem In-Reply-To: <20070604145726.GF16954@mithrandir> Message-ID: This works for TclTk modules--and I think we fixed it throughout the TclTk gui. However, these are all written as bash shell scripts. The plan is to move the gui to wxPython, which makes Python a dependency of GRASS. If Python is installed, bash scripts can be re-written in Python and should work on all platforms natively. If anyone wants to try and start testing this, it would be great. Michael On 6/4/07 7:57 AM, "Francesco P. Lovergine" wrote: > On Mon, Jun 04, 2007 at 03:36:16PM +0100, Paul Kelly wrote: >> In general it's a pleasant surprise if some shell scripts to happen to >> work OK on Windows, and IMHO shouldn't really be considered a bug if they >> don't. I feel the fact that QGIS includes a copy of Msys with GRASS gives >> the "illusion" of GRASS being more compatible with Windows than it really >> is - the truly native WinGRASS we're working on is a more accurate >> expression of GRASS's compatiblity with Windows as I see it. >> > > Isn't that the case to try re-writing those scripts in Tcl which has > the suitable path helpers to be independent from the platform? > Just my 2 cents... __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From frankie at debian.org Mon Jun 4 21:02:11 2007 From: frankie at debian.org (Francesco P. Lovergine) Date: Mon Jun 4 21:02:03 2007 Subject: [GRASS-dev] QGIS winGRASS blank space problem In-Reply-To: References: <20070604145726.GF16954@mithrandir> Message-ID: <20070604190211.GC3865@ba.issia.cnr.it> On Mon, Jun 04, 2007 at 11:48:46AM -0700, Michael Barton wrote: > The plan is to move the gui to wxPython, which makes Python a dependency of > GRASS. If Python is installed, bash scripts can be re-written in Python and > should work on all platforms natively. > Talking about that, is it defined what wxwidget and python versions will be targeted? -- Francesco P. Lovergine From michael.barton at asu.edu Mon Jun 4 21:33:58 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Jun 4 21:34:04 2007 Subject: [GRASS-dev] QGIS winGRASS blank space problem In-Reply-To: <20070604190211.GC3865@ba.issia.cnr.it> Message-ID: Yes. wxPython 2.8.x and Python 2.4+ Michael On 6/4/07 12:02 PM, "Francesco P. Lovergine" wrote: > On Mon, Jun 04, 2007 at 11:48:46AM -0700, Michael Barton wrote: >> The plan is to move the gui to wxPython, which makes Python a dependency of >> GRASS. If Python is installed, bash scripts can be re-written in Python and >> should work on all platforms natively. >> > > Talking about that, is it defined what wxwidget and python versions will > be targeted? __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From dylan.beaudette at gmail.com Mon Jun 4 21:58:07 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Mon Jun 4 21:55:58 2007 Subject: [GRASS-dev] any nice screen shots of the new wxWindows GUI? Message-ID: <200706041258.07753.dylan.beaudette@gmail.com> thanks! -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 From frankie at debian.org Mon Jun 4 22:53:34 2007 From: frankie at debian.org (Francesco P. Lovergine) Date: Mon Jun 4 22:53:25 2007 Subject: [GRASS-dev] QGIS winGRASS blank space problem In-Reply-To: References: <20070604190211.GC3865@ba.issia.cnr.it> Message-ID: <20070604205334.GD3865@ba.issia.cnr.it> On Mon, Jun 04, 2007 at 12:33:58PM -0700, Michael Barton wrote: > Yes. > > wxPython 2.8.x and Python 2.4+ > > Michael > Sigh, our wxwidget maintainer is not very enthusiatic about the wannabe-stable 2.8 release. Until now, wxwidget showed a very sad and complicated stabilization process apparently due to a too early releasing spirit or so... -- Francesco P. Lovergine From michael.barton at asu.edu Mon Jun 4 23:09:33 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Jun 4 23:09:46 2007 Subject: [GRASS-dev] QGIS winGRASS blank space problem In-Reply-To: <20070604205334.GD3865@ba.issia.cnr.it> Message-ID: Francesco, >From what I can tell (which may not be much admittedly), wxPython seems more stable than wxWidgets--even though the former is based on the latter. Michael On 6/4/07 1:53 PM, "Francesco P. Lovergine" wrote: > On Mon, Jun 04, 2007 at 12:33:58PM -0700, Michael Barton wrote: >> Yes. >> >> wxPython 2.8.x and Python 2.4+ >> >> Michael >> > > Sigh, our wxwidget maintainer is not very enthusiatic about the > wannabe-stable 2.8 release. Until now, wxwidget showed a very > sad and complicated stabilization process apparently due to > a too early releasing spirit or so... __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hamish_nospam at yahoo.com Tue Jun 5 03:11:47 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jun 5 03:11:53 2007 Subject: [GRASS-dev] QGIS winGRASS blank space problem In-Reply-To: <18020.14673.312942.124098@cerise.gclements.plus.com> References: <20070604132305.GE4703@bartok.itc.it> <18020.14673.312942.124098@cerise.gclements.plus.com> Message-ID: <20070605131147.3a68513a.hamish_nospam@yahoo.com> Markus: > > > a friend told me that with the latest QGIS release candidate, > > > there is a winGRASS problem: > > > > > > $ v.rast.stats vector=CEA_riserve raster=CEA_slope > > > colprefix=delete c:/Programmi/Quantum: c:/Programmi/Quantum: No > > > such file or directory Paul: > > I notice there are loads of places in it that paths aren't quoted so > > that is probably the first problem Glynn: > That's certainly a fundamental problem; $TMP and $SQLTMP appear to be > the most likely candidates. > > Regardless of Windows-specific issues, failure to quote variables > which contain pathnames is a bug and needs to be fixed. done in 6.3cvs. > AFAICT, $SQLTMP is unnecessary. You can just as easily use a subshell > with its output piped directly to db.execute; no need for a temporary > file. It is used in a loop- that would make it call db.execute nine times per vector cat instead of once. db.execute is slow to start/stop, so it is much faster to use a single call with $SQLTMP. r.univar is the longest step in the loop, in the version I wrote before there was a v.rast.stats, I did the loop like: r.mapcalc MASK=if(v_to_rast == $cat) g.region zoom=MASK r.univar v_to_rast g.region region=original g.remove MASK not sure how much that sped it up, IIRC if the entire row is NULL then raster ops should skip past it very quickly, and the only gain is from the fewer rast column cells to process. "g.region zoom=" is not so fast though and I never did any time trials to see. Actually when I think about it, my data was buffers around points and I calculated the tmp region from the central coord, not zoom=. In practice r.univar of the full MASKed region may take the same time-to-run as g.region zoom=, so no speedup for arbitrary polygon shapes. shrug. Hamish From hamish_nospam at yahoo.com Tue Jun 5 03:25:05 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jun 5 03:25:48 2007 Subject: [GRASS-dev] QGIS winGRASS blank space problem In-Reply-To: <20070604205334.GD3865@ba.issia.cnr.it> References: <20070604190211.GC3865@ba.issia.cnr.it> <20070604205334.GD3865@ba.issia.cnr.it> Message-ID: <20070605132505.3f7e27ed.hamish_nospam@yahoo.com> Francesco Lovergine wrote: > > > Talking about that, is it defined what wxwidget and python > > > versions will be targeted? > Michael Barton wrote: > > Yes. > > > > wxPython 2.8.x and Python 2.4+ Francesco wrote: > Sigh, our wxwidget maintainer is not very enthusiatic about the > wannabe-stable 2.8 release. Until now, wxwidget showed a very > sad and complicated stabilization process apparently due to > a too early releasing spirit or so... good timing, I just pinged the bug report for this yesterday, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403237 It is my hope to backport the needed wx packages to Etch once they reach debian/testing. "You can't stop progress" so I expect 2.8 must eventually reach Sid and the current delay has been created as an opportunity to highlight an inefficient process and make a statement to the upstream wx devels WRT the quality of their x.0 releases. Hamish From benjamin.ducke at ufg.uni-kiel.de Tue Jun 5 09:35:21 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Tue Jun 5 09:36:15 2007 Subject: [GRASS-dev] wxWidgets GRASS GUI no. 2 Message-ID: <46651239.2070000@ufg.uni-kiel.de> What this? http://www.um.es/geograf/sigmur/wxgrass/wxGRASS.html Anybody ever try that one? 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 Juan.Giraldo at upct.es Tue Jun 5 13:41:57 2007 From: Juan.Giraldo at upct.es (Juan Diego Giraldo Osorio) Date: Tue Jun 5 13:40:22 2007 Subject: [GRASS-dev] about [--overwrite] flag In-Reply-To: <3341981699jdgiraldo@upct.es> References: <3341981699jdgiraldo@upct.es> Message-ID: <6279616535jdgiraldo@upct.es> Hi coworkers I'm working in a raster module (simply to read, cut and save the cut map. I'm defining the options and flags. The question is, the [--overwrite] flag is always present despite that I haven't defined it??? Thanks Juan Diego From glynn at gclements.plus.com Tue Jun 5 16:23:17 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jun 5 16:23:20 2007 Subject: [GRASS-dev] QGIS winGRASS blank space problem In-Reply-To: <20070605131147.3a68513a.hamish_nospam@yahoo.com> References: <20070604132305.GE4703@bartok.itc.it> <18020.14673.312942.124098@cerise.gclements.plus.com> <20070605131147.3a68513a.hamish_nospam@yahoo.com> Message-ID: <18021.29141.175622.88333@cerise.gclements.plus.com> Hamish wrote: > > AFAICT, $SQLTMP is unnecessary. You can just as easily use a subshell > > with its output piped directly to db.execute; no need for a temporary > > file. > > It is used in a loop- that would make it call db.execute nine times per > vector cat instead of once. db.execute is slow to start/stop, so it is > much faster to use a single call with $SQLTMP. That's incorrect. In terms of the number of times that db.execute is run, there is no difference between the existing code with a temporary file: if [ $DBFDRIVER -eq 1 ] ; then echo "UPDATE $VECTOR SET `echo ${COLPREFIX}_n| cut -b1-10`=$n WHERE cat=$i;" > $SQLTMP echo "UPDATE $VECTOR SET `echo ${COLPREFIX}_min| cut -b1-10`=$min WHERE cat=$i;" >> $SQLTMP echo "UPDATE $VECTOR SET `echo ${COLPREFIX}_max| cut -b1-10`=$max WHERE cat=$i;" >> $SQLTMP echo "UPDATE $VECTOR SET `echo ${COLPREFIX}_range| cut -b1-10`=$range WHERE cat=$i;" >> $SQLTMP echo "UPDATE $VECTOR SET `echo ${COLPREFIX}_mean| cut -b1-10`=$mean WHERE cat=$i;" >> $SQLTMP echo "UPDATE $VECTOR SET `echo ${COLPREFIX}_stddev| cut -b1-10`=$stddev WHERE cat=$i;" >> $SQLTMP echo "UPDATE $VECTOR SET `echo ${COLPREFIX}_variance| cut -b1-10`=$variance WHERE cat=$i;" >> $SQLTMP echo "UPDATE $VECTOR SET `echo ${COLPREFIX}_cf_var| cut -b1-10`=$coeff_var WHERE cat=$i;" >> $SQLTMP echo "UPDATE $VECTOR SET `echo ${COLPREFIX}_sum| cut -b1-10`=$sum WHERE cat=$i;" >> $SQLTMP else echo "UPDATE $VECTOR SET ${COLPREFIX}_n=$n WHERE cat=$i;" > $SQLTMP echo "UPDATE $VECTOR SET ${COLPREFIX}_min=$min WHERE cat=$i;" >> $SQLTMP echo "UPDATE $VECTOR SET ${COLPREFIX}_max=$max WHERE cat=$i;" >> $SQLTMP echo "UPDATE $VECTOR SET ${COLPREFIX}_range=$range WHERE cat=$i;" >> $SQLTMP echo "UPDATE $VECTOR SET ${COLPREFIX}_mean=$mean WHERE cat=$i;" >> $SQLTMP echo "UPDATE $VECTOR SET ${COLPREFIX}_stddev=$stddev WHERE cat=$i;" >> $SQLTMP echo "UPDATE $VECTOR SET ${COLPREFIX}_variance=$variance WHERE cat=$i;" >> $SQLTMP echo "UPDATE $VECTOR SET ${COLPREFIX}_cf_var=$coeff_var WHERE cat=$i;" >> $SQLTMP echo "UPDATE $VECTOR SET ${COLPREFIX}_sum=$sum WHERE cat=$i;" >> $SQLTMP fi cat $SQLTMP | db.execute database=$DB_DATABASE driver=$DB_SQLDRIVER and using a subshell: ( if [ $DBFDRIVER -eq 1 ] ; then echo "UPDATE $VECTOR SET `echo ${COLPREFIX}_n| cut -b1-10`=$n WHERE cat=$i;" echo "UPDATE $VECTOR SET `echo ${COLPREFIX}_min| cut -b1-10`=$min WHERE cat=$i;" echo "UPDATE $VECTOR SET `echo ${COLPREFIX}_max| cut -b1-10`=$max WHERE cat=$i;" echo "UPDATE $VECTOR SET `echo ${COLPREFIX}_range| cut -b1-10`=$range WHERE cat=$i;" echo "UPDATE $VECTOR SET `echo ${COLPREFIX}_mean| cut -b1-10`=$mean WHERE cat=$i;" echo "UPDATE $VECTOR SET `echo ${COLPREFIX}_stddev| cut -b1-10`=$stddev WHERE cat=$i;" echo "UPDATE $VECTOR SET `echo ${COLPREFIX}_variance| cut -b1-10`=$variance WHERE cat=$i;" echo "UPDATE $VECTOR SET `echo ${COLPREFIX}_cf_var| cut -b1-10`=$coeff_var WHERE cat=$i;" echo "UPDATE $VECTOR SET `echo ${COLPREFIX}_sum| cut -b1-10`=$sum WHERE cat=$i;" else echo "UPDATE $VECTOR SET ${COLPREFIX}_n=$n WHERE cat=$i;" echo "UPDATE $VECTOR SET ${COLPREFIX}_min=$min WHERE cat=$i;" echo "UPDATE $VECTOR SET ${COLPREFIX}_max=$max WHERE cat=$i;" echo "UPDATE $VECTOR SET ${COLPREFIX}_range=$range WHERE cat=$i;" echo "UPDATE $VECTOR SET ${COLPREFIX}_mean=$mean WHERE cat=$i;" echo "UPDATE $VECTOR SET ${COLPREFIX}_stddev=$stddev WHERE cat=$i;" echo "UPDATE $VECTOR SET ${COLPREFIX}_variance=$variance WHERE cat=$i;" echo "UPDATE $VECTOR SET ${COLPREFIX}_cf_var=$coeff_var WHERE cat=$i;" echo "UPDATE $VECTOR SET ${COLPREFIX}_sum=$sum WHERE cat=$i;" fi ) | db.execute database=$DB_DATABASE driver=$DB_SQLDRIVER In both cases, db.execute is run once per category. There might be further performance gains from moving db.execute outside of the loop, but that's true regardless of whether a temporary file is used. 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 -- Glynn Clements From glynn at gclements.plus.com Tue Jun 5 16:30:49 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jun 5 16:30:52 2007 Subject: [GRASS-dev] QGIS winGRASS blank space problem In-Reply-To: References: <20070604132305.GE4703@bartok.itc.it> Message-ID: <18021.29593.998833.140210@cerise.gclements.plus.com> Paul Kelly wrote: > > a friend told me that with the latest QGIS release candidate, > > there is a winGRASS problem: > > > > $ v.rast.stats vector=CEA_riserve raster=CEA_slope colprefix=delete > > c:/Programmi/Quantum: c:/Programmi/Quantum: No such file or directory > > > > He uses a path with space: > > c:/Programmi/Quantum GIS/ > > ^ > > > > Is that a GRASS problem? Where to fix? To me it looks like > > OK I've looked into this a bit more and it seems there is indeed a problem > but I don't think it's GRASS. More to do with the way the Msys shell > interprets the path to the script passed to it by the Windows _spawnlp() > function. It reminds me strongly of what Glynn was saying about the > difference between a list of strings, and one string with spaces used as > separators: http://grass.itc.it/pipermail/grass-dev/2007-May/031394.html > > I wonder if something like that is going on with the way the Msys shell is > interpreting its command-line arguments, or with the way Windows is > passing them to it. As proof of concept, the patch below seems to make it > work, but putting quotes in when they shouldn't be needed is very ugly and > might break it for non-Msys shells so I don't want to fix that. Ah. http://msdn2.microsoft.com/en-us/library/20y988d2(VS.80).aspx Arguments for the Spawned Process To pass arguments to the new process, give one or more pointers to character strings as arguments in the _spawn call. These character strings form the argument list for the spawned process. The combined length of the strings forming the argument list for the new process must not exceed 1024 bytes. The terminating null character ('\0') for each string is not included in the count, but space characters (automatically inserted to separate arguments) are included. Note Spaces embedded in strings may cause unexpected behavior; for example, passing _spawn the string "hi there" will result in the new process getting two arguments, "hi" and "there". If the intent was to have the new process open a file named "hi there", the process would fail. You can avoid this by quoting the string: "\"hi there\"". Needless to say, it doesn't say what happens (or what to do) if the argument itself contains quotes. Does anyone want to dig into the source code for Python's subprocess module to see how they handle this? -- Glynn Clements From andrea.antonello at gmail.com Tue Jun 5 23:26:51 2007 From: andrea.antonello at gmail.com (Andrea Antonello) Date: Tue Jun 5 23:27:02 2007 Subject: [GRASS-dev] questions for compatibility In-Reply-To: <20070602075753.GA4917@bartok.itc.it> References: <20070602075753.GA4917@bartok.itc.it> Message-ID: <4665D51B.1000600@gmail.com> Hi developers, can someone please tell me where the alpha blending value of a map is kept in grass? Inside the colorrules file? It is something that wasn't added lots of time ago, right? I couldn't find it by doing a quick search in the manuals and dev archives. Thanks Andrea From hamish_nospam at yahoo.com Wed Jun 6 02:36:01 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jun 6 02:36:11 2007 Subject: [GRASS-dev] about [--overwrite] flag In-Reply-To: <6279616535jdgiraldo@upct.es> References: <3341981699jdgiraldo@upct.es> <6279616535jdgiraldo@upct.es> Message-ID: <20070606123601.25f659fe.hamish_nospam@yahoo.com> Juan Diego Giraldo Osorio wrote: > > I'm working in a raster module (simply to read, cut and save the cut > map. I'm defining the options and flags. The question is, the > [--overwrite] flag is always present despite that I haven't defined > it??? it shows up automatically if you define any parser options that can create new maps. opt->gisprompt = "new,..,.." Hamish From hamish_nospam at yahoo.com Wed Jun 6 05:32:07 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jun 6 05:32:32 2007 Subject: [GRASS-dev] QGIS winGRASS blank space problem In-Reply-To: <18021.29141.175622.88333@cerise.gclements.plus.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> Message-ID: <20070606153207.24c24e92.hamish_nospam@yahoo.com> Glynn Clements wrote: > > Hamish wrote: > > > > AFAICT, $SQLTMP is unnecessary. You can just as easily use a > > > subshell with its output piped directly to db.execute; no need for > > > a temporary file. > > > > It is used in a loop- that would make it call db.execute nine times > > per vector cat instead of once. db.execute is slow to start/stop, so > > it is much faster to use a single call with $SQLTMP. > > That's incorrect. > > In terms of the number of times that db.execute is run, there is no > difference between the existing code with a temporary file: ah, I missed the "subshell", I thought you meant once per line. still, a .tmp file is nice for debugging (even better if db.execute was only run once), and it doesn't hurt much. > 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 yes, but in that case you'd have to do something about cf_var: > echo "UPDATE $VECTOR SET ${COLPREFIX}_cf_var=$coeff_var WHERE cat=$i;" it was shortended from 'r.univar -g's coeff_var to work within DBF column name width restrictions. Hamish From hamish_nospam at yahoo.com Wed Jun 6 07:46:48 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jun 6 07:47:09 2007 Subject: [GRASS-dev] broken polygon fills with d.vect render=l Message-ID: <20070606174648.2643a4c1.hamish_nospam@yahoo.com> Hi, I just threw up some new screenshots showing broken polygon fills with d.vect render=l. What should not be filled, is partially filled. Look near the end of the page: http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/ from those pics, and assuming we have to use the display library and not the old libgis render functions, it appears that "c" would be a nicer pick than "l", if the two bands of white at the edges could be corrected. Hamish From glynn at gclements.plus.com Wed Jun 6 16:19:13 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Jun 6 16:19:17 2007 Subject: [GRASS-dev] questions for compatibility In-Reply-To: <4665D51B.1000600@gmail.com> References: <20070602075753.GA4917@bartok.itc.it> <4665D51B.1000600@gmail.com> Message-ID: <18022.49761.546855.499139@cerise.gclements.plus.com> Andrea Antonello wrote: > can someone please tell me where the alpha blending value of a map is > kept in grass? Inside the colorrules file? It is something that wasn't > added lots of time ago, right? Maps don't have a translucency (alpha-blending) value. Translucency is a property of a layer in gis.m and the wx GUI; it doesn't exist outside of those applications. -- Glynn Clements From glynn at gclements.plus.com Wed Jun 6 16:23:19 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Jun 6 16:23:21 2007 Subject: [GRASS-dev] QGIS winGRASS blank space problem In-Reply-To: <20070606153207.24c24e92.hamish_nospam@yahoo.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> Message-ID: <18022.50007.138879.861506@cerise.gclements.plus.com> Hamish 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 > > yes, but in that case you'd have to do something about cf_var: > > > echo "UPDATE $VECTOR SET ${COLPREFIX}_cf_var=$coeff_var WHERE cat=$i;" Just add: cf_var=$coeff_var after r.univar is run. -- Glynn Clements From andrea.antonello at gmail.com Wed Jun 6 16:37:51 2007 From: andrea.antonello at gmail.com (Andrea Antonello) Date: Wed Jun 6 16:38:37 2007 Subject: [GRASS-dev] questions for compatibility In-Reply-To: <18022.49761.546855.499139@cerise.gclements.plus.com> References: <20070602075753.GA4917@bartok.itc.it> <4665D51B.1000600@gmail.com> <18022.49761.546855.499139@cerise.gclements.plus.com> Message-ID: <4666C6BF.7030206@gmail.com> Thanks Glynn, that means that there is also no plan to put it in some kind of persistence? I feel that this is pretty near to the colorrules system. Andrea Glynn Clements probaly wrote: > Andrea Antonello wrote: > >> can someone please tell me where the alpha blending value of a map is >> kept in grass? Inside the colorrules file? It is something that wasn't >> added lots of time ago, right? > > Maps don't have a translucency (alpha-blending) value. > > Translucency is a property of a layer in gis.m and the wx GUI; it > doesn't exist outside of those applications. > From thereddog at gmx.net Wed Jun 6 17:03:38 2007 From: thereddog at gmx.net (Reddog) Date: Wed Jun 6 17:03:34 2007 Subject: [GRASS-dev] IDE for development Message-ID: <238853207.20070606170338@gmx.net> Hello, GRASS-Team, I'm developing GRASS-modules for some time now. I'd like to ask, could you recommend an IDE to use. Because, at the moment, I'm still using a common editor. Thank you, Elshad Shirinov From jachym.cepicky at gmail.com Wed Jun 6 21:26:27 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Jun 6 21:28:49 2007 Subject: [GRASS-dev] gdal --with-grass on solaris In-Reply-To: <1181092688.3193.66.camel@dev64.localdomain> References: <1181092688.3193.66.camel@dev64.localdomain> Message-ID: <1181157987.7883.50.camel@mellon> hi, Brad Douglas p??e v ?t 05. 06. 2007 v 18:18 -0700: > A couple suggestions: > > `ldd` some of the GRASS libraries to ensure that there are no missing > library dependencies. well, I'm having problems while running configure script - how am I supposed to apply ldd on it? > > It may be beneficial to just add $YOUR_GRASS_PATH/lib to ld.conf since > you'll most likely have to anyway to run GRASS. I was searching for any ld.conf file, but did not found any :-/ could you point me to right place? > > Are there any required software that has multiple versions installed? as far as I know, no, there are not > Solaris is pretty good at confusing stuff like that. agree thanks for your reply jachym > > On Sat, 2007-06-02 at 15:51 +0000, Jachym Cepicky wrote: > > hi, > > > > I try co compile GDAL --with-grass support on > > > > SunOS ul-wrk2 5.10 Generic_118833-03 sun4u sparc SUNW,A70 Solaris > > gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath) > > GNU Make 3.80 > > automake (GNU automake) 1.8.3 > > autoconf (GNU Autoconf) 2.59 > > > > and it does not work: > > > > 1) I managed to compile gdal with > > ./configure > > make > > make install > > > > 2) I managed to install grass with > > > > ./configure --with-proj-libs=/usr/local/lib/ > > --with-postgres-includes=/usr/local/pgsql/include/ > > --with-postgres-libs=/usr/local/pgsql/lib/ --without-fftw > > --with-tcltk-includes=/usr/local/include/ > > --with-tcltk-libs=/usr/local/lib/ > > make > > make install > > > > 3) I would like to install gdal --with-grass, however > > > > ./configure --with-grass=/usr/local/grass-6.2.2RC1/ > > [....] > > checking dynamic linker characteristics... f90: Warning: Option > > -print-search-dirs passed to ld, if ld is invoked, ignored otherwise > > Usage: f90 [ options ] files. Use 'f90 -flags' for details > > solaris2.10 ld.so > > [....] > > checking for pg_config... no > > checking for PostgreSQL... no > > checking for G_asprintf in -lgrass_gis... no > > configure: error: --with-grass=/usr/local/grass-6.2.2RC1/ requested, > > but libraries not found! > > > > but > > > > ls /usr/local/grass-6.2.2RC1/ > > bin bwidget docs driver etc fonts include lib man scripts > > > > and > > > > echo $LD_LIBRARY_PATH > > /usr/local/grass-6.2.2RC1/lib/ > > > > could anybody give me advice, how to approach on this operating > > system? On linux, it works :-/ > > -- Jachym Cepicky e-mail: jachym.cepicky@gmail.com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?= =?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?= =?ISO-8859-1?Q?_zpr=E1vy?= Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070606/0fbe70d0/attachment.bin From jachym.cepicky at gmail.com Wed Jun 6 21:28:43 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Jun 6 21:28:52 2007 Subject: [GRASS-dev] gdal --with-grass on solaris In-Reply-To: <1181092688.3193.66.camel@dev64.localdomain> References: <1181092688.3193.66.camel@dev64.localdomain> Message-ID: <1181158123.3206.1.camel@mellon> hi, Brad Douglas p??e v ?t 05. 06. 2007 v 18:18 -0700: > A couple suggestions: > > `ldd` some of the GRASS libraries to ensure that there are no missing > library dependencies. but i get the problem while running the configure script - how to apply ldd on it? > > It may be beneficial to just add $YOUR_GRASS_PATH/lib to ld.conf since > you'll most likely have to anyway to run GRASS. I was searching for it, but did not found anything similar to it. Am I supposed to create one in /etc/ld.conf manualy? > > Are there any required software that has multiple versions installed? as far as I know, no, there are not > Solaris is pretty good at confusing stuff like that. agree thank you for the reply Jachym > > On Sat, 2007-06-02 at 15:51 +0000, Jachym Cepicky wrote: > > hi, > > > > I try co compile GDAL --with-grass support on > > > > SunOS ul-wrk2 5.10 Generic_118833-03 sun4u sparc SUNW,A70 Solaris > > gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath) > > GNU Make 3.80 > > automake (GNU automake) 1.8.3 > > autoconf (GNU Autoconf) 2.59 > > > > and it does not work: > > > > 1) I managed to compile gdal with > > ./configure > > make > > make install > > > > 2) I managed to install grass with > > > > ./configure --with-proj-libs=/usr/local/lib/ > > --with-postgres-includes=/usr/local/pgsql/include/ > > --with-postgres-libs=/usr/local/pgsql/lib/ --without-fftw > > --with-tcltk-includes=/usr/local/include/ > > --with-tcltk-libs=/usr/local/lib/ > > make > > make install > > > > 3) I would like to install gdal --with-grass, however > > > > ./configure --with-grass=/usr/local/grass-6.2.2RC1/ > > [....] > > checking dynamic linker characteristics... f90: Warning: Option > > -print-search-dirs passed to ld, if ld is invoked, ignored otherwise > > Usage: f90 [ options ] files. Use 'f90 -flags' for details > > solaris2.10 ld.so > > [....] > > checking for pg_config... no > > checking for PostgreSQL... no > > checking for G_asprintf in -lgrass_gis... no > > configure: error: --with-grass=/usr/local/grass-6.2.2RC1/ requested, > > but libraries not found! > > > > but > > > > ls /usr/local/grass-6.2.2RC1/ > > bin bwidget docs driver etc fonts include lib man scripts > > > > and > > > > echo $LD_LIBRARY_PATH > > /usr/local/grass-6.2.2RC1/lib/ > > > > could anybody give me advice, how to approach on this operating > > system? On linux, it works :-/ > > -- Jachym Cepicky e-mail: jachym.cepicky@gmail.com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?= =?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?= =?ISO-8859-1?Q?_zpr=E1vy?= Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070606/ca6d06d7/attachment.bin From michael.barton at asu.edu Wed Jun 6 22:12:27 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Jun 6 22:17:23 2007 Subject: [GRASS-dev] CLI working again Message-ID: I got the CLI for wxgrass working again. You can type in any command (GRASS or shell). Non-GRASS commands will simply be passed to the shell. GRASS commands without arguments (e.g. g.region) will open their properties dialogs for non-display commands. d.* commands without arguments will add a layer to the GUI layer tree and open their respective properties dialog (e.g., d.rast). GRASS commands with arguments (e.g., g.region rast=elevation.10m) will be passed to the GRASS command shell for processing. d.* commands with arguments (e.g., d.rast elevation.10m) will display their results in the currently selected map display. Multiple display commands separated by commas will send overlaying graphic results to the current map display (e.g., d.rast elevation.10m,d.vect roads color=red). Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070606/a5e7cd1b/attachment.html From debeaudette at ucdavis.edu Wed Jun 6 22:36:08 2007 From: debeaudette at ucdavis.edu (Dylan Beaudette) Date: Wed Jun 6 22:33:48 2007 Subject: [GRASS-dev] CLI working again In-Reply-To: References: Message-ID: <200706061336.08169.debeaudette@ucdavis.edu> On Wednesday 06 June 2007 13:12, Michael Barton wrote: > I got the CLI for wxgrass working again. You can type in any command (GRASS > or shell). > > Non-GRASS commands will simply be passed to the shell. > > GRASS commands without arguments (e.g. g.region) will open their properties > dialogs for non-display commands. d.* commands without arguments will add a > layer to the GUI layer tree and open their respective properties dialog > (e.g., d.rast). > > GRASS commands with arguments (e.g., g.region rast=elevation.10m) will be > passed to the GRASS command shell for processing. d.* commands with > arguments (e.g., d.rast elevation.10m) will display their results in the > currently selected map display. Multiple display commands separated by > commas will send overlaying graphic results to the current map display > (e.g., d.rast elevation.10m,d.vect roads color=red). > > Michael > __________________________________________ Great news. one small nitpick: wouldn't it be better to seperate commands with a semi-colon instead of a comma? There are some commands which use the comma to parse multiple entries. cheers, -- Dylan Beaudette Soil Resource Laboratory http://casoilresource.lawr.ucdavis.edu/ University of California at Davis 530.754.7341 From michael.barton at asu.edu Wed Jun 6 23:05:20 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Jun 6 23:05:26 2007 Subject: [GRASS-dev] CLI working again In-Reply-To: <200706061336.08169.debeaudette@ucdavis.edu> Message-ID: Good idea. I'll change it soon. Michael On 6/6/07 1:36 PM, "Dylan Beaudette" wrote: > Great news. one small nitpick: wouldn't it be better to seperate commands with > a semi-colon instead of a comma? There are some commands which use the comma > to parse multiple entries. > > cheers, __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hamish_nospam at yahoo.com Thu Jun 7 06:16:17 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Jun 7 06:16:27 2007 Subject: [GRASS-dev] questions for compatibility In-Reply-To: <18022.49761.546855.499139@cerise.gclements.plus.com> References: <20070602075753.GA4917@bartok.itc.it> <4665D51B.1000600@gmail.com> <18022.49761.546855.499139@cerise.gclements.plus.com> Message-ID: <20070607161617.4a816cb4.hamish_nospam@yahoo.com> Glynn Clements wrote: > Maps don't have a translucency (alpha-blending) value. Just to note, r.in.gdal will save the .alpha channel, if present in the input map. But AFAIK the GIS treats it as just another map. You can also try d.his to replicate the effect. Hamish From benjamin.ducke at ufg.uni-kiel.de Thu Jun 7 08:50:13 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Thu Jun 7 08:51:02 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS in th UK In-Reply-To: References: Message-ID: <4667AAA5.8000406@ufg.uni-kiel.de> Hi Carlos, Good idea. I will be in London July to Oct. and I know some people from the Archaeology department at UCL who might also be interested in a little GRASS inter-disciplinary exchange over a beer or two. Sometime in August, perhaps? Benjamin Carlos "Gu?no" Grohmann wrote: > Just thinking about UK GRASS users. How many out there? I'm not from > here, but I will be until October, so maybe we ca set up some sort of > meeting? pub? There will be a British Geomorphological Society > meeting, in July. Someone going? > > > cheers > > -- 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 Thu Jun 7 10:34:28 2007 From: carlos.grohmann at gmail.com (=?ISO-8859-1?Q?Carlos_"Gu=E2no"_Grohmann?=) Date: Thu Jun 7 10:34:30 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS in th UK In-Reply-To: <4667AAA5.8000406@ufg.uni-kiel.de> References: <4667AAA5.8000406@ufg.uni-kiel.de> Message-ID: August seems fine to me. Carlos On 6/7/07, Benjamin Ducke wrote: > Hi Carlos, > > Good idea. I will be in London July to Oct. and I know some people > from the Archaeology department at UCL who might also be interested > in a little GRASS inter-disciplinary exchange over a beer or two. > Sometime in August, perhaps? > > Benjamin > > Carlos "Gu?no" Grohmann wrote: > > Just thinking about UK GRASS users. How many out there? I'm not from > > here, but I will be until October, so maybe we ca set up some sort of > > meeting? pub? There will be a British Geomorphological Society > > meeting, in July. Someone going? > > > > > > cheers > > > > > > -- > 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 > -- +-----------------------------------------------------------+ 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 andrea.antonello at gmail.com Thu Jun 7 10:42:18 2007 From: andrea.antonello at gmail.com (Andrea Antonello) Date: Thu Jun 7 10:42:21 2007 Subject: [GRASS-dev] questions for compatibility In-Reply-To: <20070607161617.4a816cb4.hamish_nospam@yahoo.com> References: <20070602075753.GA4917@bartok.itc.it> <4665D51B.1000600@gmail.com> <18022.49761.546855.499139@cerise.gclements.plus.com> <20070607161617.4a816cb4.hamish_nospam@yahoo.com> Message-ID: <4667C4EA.2020300@gmail.com> That is interesting, since that seems to give really an alpha for every pixel. I was looking towards having alpha inside the rules in order to have parts of the maps at different translucency. However, if gdal creates another map for alpha, the path to persistence will be long. I'll have to check what QGis does for this case. In JGrass we would like to have alpha persistent and since we want to keep compatibility with GRASS, I would really love to hear some opinions from the developer team in order to follow their rules, instead of changing afterwards to fix compatibility. Any idea about what would be best? Andrea Hamish probaly wrote: > Glynn Clements wrote: >> Maps don't have a translucency (alpha-blending) value. > > Just to note, r.in.gdal will save the .alpha channel, if present in the > input map. But AFAIK the GIS treats it as just another map. > > You can also try d.his to replicate the effect. > > > Hamish > From grass-codei at wald.intevation.org Thu Jun 7 15:12:13 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Thu Jun 7 15:11:27 2007 Subject: [GRASS-dev] [grass-code I][420] v.transform pointsfile does not accept points in dd:mm:ss format Message-ID: <20070607131213.8786DB53A9@pyrosoma.intevation.org> code I item #420, was opened at 2007-06-07 15:12 Status: Open Priority: 3 Submitted By: Harri Kiiskinen (harrikoo) Assigned to: Nobody (None) Summary: v.transform pointsfile does not accept points in dd:mm:ss format Issue type: module bug Issue status: None GRASS version: CVS HEAD GRASS component: vector Operating system: Linux Operating system version: Debian 4.0 GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: v.transform does not accept point coordinated given as dd:mm:ss.ss in the 'pointsfile' option. If the coordinates are changed into decimal, everything works ok. Harri K. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=420&group_id=21 From michael.barton at asu.edu Fri Jun 8 06:45:59 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jun 8 06:48:39 2007 Subject: [GRASS-dev] d.extend in gui Message-ID: I?m going through and finishing up the menus for wxgrass. This is giving me the opportunity to look at the current gui menu structure and revisit all GRASS commands in excruciating detail. But there are some advantages. I noticed that d.extend is still on the menu. This is supposed to set the region to match the maximum extent of all displayed maps, but it won?t work without an xmon displaying a map. This makes it essentially useless in the context of the current GUI?s. However, it could be a useful function if you could optionally give it a list of maps to use for setting the region. You can almost do this with g.region. You can give g.region rast= a list of raster maps. But this won?t work for mixed raster and vector maps. I don?t know what is needed to get either one of these working outside of an xmon environment to zoom to max extent, but it would be nice to have this functionality if it is not too difficult to implement. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070607/4ebef950/attachment.html From michael.barton at asu.edu Fri Jun 8 07:11:07 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jun 8 07:15:32 2007 Subject: [GRASS-dev] g.gisenv in gui Message-ID: Found another minor item that a small change could improve. g.gisenv does not behave like other GRASS commands in that you cannot launch the autogenerated gui by typing ?g.gisenv? from the command line. Instead, you get the current environment settings. You can only get the gui if you run it through some special processing in the GUI. Likewise, you can?t get it to print out current environment settings from the gui unless you do some tricks with its execution. To behave more ?normally? it needs a ?p flag. Then... g.gisenv -> autogenerated gui g.gisenv ?p -> print current settings. I suppose that this would break a bunch of scripts, but it would be nice if it could work consistently with other commands. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070607/fb84e4d6/attachment.html From hamish_nospam at yahoo.com Fri Jun 8 08:34:29 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Jun 8 08:34:40 2007 Subject: [GRASS-dev] g.gisenv in gui In-Reply-To: References: Message-ID: <20070608183429.09753c49.hamish_nospam@yahoo.com> Michael Barton wrote: > > Found another minor item that a small change could improve. > > g.gisenv does not behave like other GRASS commands in that you cannot > launch the autogenerated gui by typing ?g.gisenv? from the command > line. Instead, you get the current environment settings. You can only > get the gui if you run it through some special processing in the GUI. for a GUI just launch with: g.gisenv --ui use that as the menu command. A number of modules work like this without command line args. > Likewise, you can?t get it to print out current environment settings > from the gui unless you do some tricks with its execution. g.gisenv store="" --ui [Run] Probably a nice GUI frontend should be used for that, vs exposing the user to the raw g.gisenv GUI. Hamish From Michael.Barton at asu.edu Fri Jun 8 08:55:50 2007 From: Michael.Barton at asu.edu (Michael Barton) Date: Fri Jun 8 09:10:19 2007 Subject: [GRASS-dev] g.gisenv in gui In-Reply-To: <20070608183429.09753c49.hamish_nospam@yahoo.com> Message-ID: Hamish, Thanks for this info. But... On 6/7/07 11:34 PM, "Hamish" wrote: > for a GUI just launch with: > g.gisenv --ui This does work to get the gui from the command line > > use that as the menu command. > > A number of modules work like this without command line args. > > >> Likewise, you can?t get it to print out current environment settings >> from the gui unless you do some tricks with its execution. > > g.gisenv store="" --ui > [Run] This doesn't work to get the settings printed to stdout. It just launches the gui. Michael > > Probably a nice GUI frontend should be used for that, vs exposing the > user to the raw g.gisenv GUI. __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From Michael.Barton at asu.edu Fri Jun 8 08:55:50 2007 From: Michael.Barton at asu.edu (Michael Barton) Date: Fri Jun 8 09:11:08 2007 Subject: [GRASS-dev] g.gisenv in gui In-Reply-To: <20070608183429.09753c49.hamish_nospam@yahoo.com> Message-ID: Hamish, Thanks for this info. But... On 6/7/07 11:34 PM, "Hamish" wrote: > for a GUI just launch with: > g.gisenv --ui This does work to get the gui from the command line > > use that as the menu command. > > A number of modules work like this without command line args. > > >> Likewise, you can?t get it to print out current environment settings >> from the gui unless you do some tricks with its execution. > > g.gisenv store="" --ui > [Run] This doesn't work to get the settings printed to stdout. It just launches the gui. Michael > > Probably a nice GUI frontend should be used for that, vs exposing the > user to the raw g.gisenv GUI. __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From glynn at gclements.plus.com Fri Jun 8 15:21:01 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jun 8 15:21:50 2007 Subject: [GRASS-dev] g.gisenv in gui In-Reply-To: <20070608183429.09753c49.hamish_nospam@yahoo.com> References: <20070608183429.09753c49.hamish_nospam@yahoo.com> Message-ID: <18025.22461.823465.920955@cerise.gclements.plus.com> Hamish wrote: > > Found another minor item that a small change could improve. > > > > g.gisenv does not behave like other GRASS commands in that you cannot > > launch the autogenerated gui by typing ?g.gisenv? from the command > > line. Instead, you get the current environment settings. You can only > > get the gui if you run it through some special processing in the GUI. > > for a GUI just launch with: > g.gisenv --ui > > use that as the menu command. > > A number of modules work like this without command line args. In general, modules where all options have a reasonable default value work this way. E.g. "d.erase" is equivalent to "d.erase color=white" rather than to "d.erase --ui". -- Glynn Clements From glynn at gclements.plus.com Fri Jun 8 15:30:23 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jun 8 15:30:26 2007 Subject: [GRASS-dev] g.gisenv in gui In-Reply-To: References: Message-ID: <18025.23023.512507.820597@cerise.gclements.plus.com> Michael Barton wrote: > Found another minor item that a small change could improve. > > g.gisenv does not behave like other GRASS commands in that you cannot launch > the autogenerated gui by typing ?g.gisenv? from the command line. Instead, > you get the current environment settings. You can only get the gui if you > run it through some special processing in the GUI. See Hamish's reply. > Likewise, you can?t get > it to print out current environment settings from the gui unless you do some > tricks with its execution. AFAICT, the problem with g.gisenv is that it checks for argc==1 before calling G_parser(), so e.g. "g.gisenv --quiet" causes that check to fail. What it should probably do is to call G_parser() unconditionally, then check for: if (!get->answer && !set->answer && !store_opt->answer) > To behave more ?normally? it needs a ?p flag. Then... > > g.gisenv -> autogenerated gui > g.gisenv ?p -> print current settings. > > I suppose that this would break a bunch of scripts, but it would be nice if > it could work consistently with other commands. I suspect that this is unnecessary if the no-arguments check is fixed. -- Glynn Clements From glynn at gclements.plus.com Fri Jun 8 15:18:00 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jun 8 15:37:06 2007 Subject: [GRASS-dev] d.extend in gui In-Reply-To: References: Message-ID: <18025.22280.219107.869953@cerise.gclements.plus.com> Michael Barton wrote: > I?m going through and finishing up the menus for wxgrass. This is giving me > the opportunity to look at the current gui menu structure and revisit all > GRASS commands in excruciating detail. But there are some advantages. > > I noticed that d.extend is still on the menu. This is supposed to set the > region to match the maximum extent of all displayed maps, but it won?t work > without an xmon displaying a map. This makes it essentially useless in the > context of the current GUI?s. However, it could be a useful function if you > could optionally give it a list of maps to use for setting the region. You > can almost do this with g.region. You can give g.region rast= a list of > raster maps. But this won?t work for mixed raster and vector maps. > > I don?t know what is needed to get either one of these working outside of an > xmon environment to zoom to max extent, but it would be nice to have this > functionality if it is not too difficult to implement. It shouldn't be particularly complicated to make g.region accept any combination of region=, rast=, rast3d=, vect= and zoom= (and possibly also n=/s=/e=/w=) and to set the region to the union of all of them. Actually, -d could also be used, and you might want an option to include the current region as well. -- Glynn Clements From woklist at kyngchaos.com Fri Jun 8 16:15:33 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Fri Jun 8 16:15:57 2007 Subject: [GRASS-dev] Re: [GRASSGUI] CLI working again In-Reply-To: References: Message-ID: <2CAF902F-25DD-4941-8E48-643E846024BF@kyngchaos.com> I've been meaning to ask about wxgrass and CLI stuff - you're obviously working on a GUI psuedo-terminal for running commands the old-fashioned CLI way. I take it there is/will be no need for something like 'grass-xterm-wrapper', and any place that the TclTk GUI used that this pseudo terminal will work in wxgrass? PS. did you ever get a chance to try my Terminal-enabled version of grass-xterm-wrapper? I've been lazy in committing it, so you'd have to dig it out of the email, or maybe I should just commit it anyways. It's in my binaries and I haven't heard of any problems yet... On Jun 6, 2007, at 3:12 PM, Michael Barton wrote: > I got the CLI for wxgrass working again. You can type in any > command (GRASS or shell). > > Non-GRASS commands will simply be passed to the shell. > > GRASS commands without arguments (e.g. g.region) will open their > properties dialogs for non-display commands. d.* commands without > arguments will add a layer to the GUI layer tree and open their > respective properties dialog (e.g., d.rast). > > GRASS commands with arguments (e.g., g.region rast=elevation.10m) > will be passed to the GRASS command shell for processing. d.* > commands with arguments (e.g., d.rast elevation.10m) will display > their results in the currently selected map display. Multiple > display commands separated by commas will send overlaying graphic > results to the current map display (e.g., d.rast elevation. > 10m,d.vect roads color=red). > > Michael > ----- William Kyngesburye http://www.kyngchaos.com/ "History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history." - Hitchhiker's Guide to the Galaxy From michael.barton at asu.edu Fri Jun 8 18:18:58 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jun 8 18:19:27 2007 Subject: [GRASS-dev] g.gisenv in gui In-Reply-To: <18025.23023.512507.820597@cerise.gclements.plus.com> Message-ID: I don't quite follow the proposed changes below, but I trust you that this will probably fix things. Michael On 6/8/07 6:30 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> Found another minor item that a small change could improve. >> >> g.gisenv does not behave like other GRASS commands in that you cannot launch >> the autogenerated gui by typing ?g.gisenv? from the command line. Instead, >> you get the current environment settings. You can only get the gui if you >> run it through some special processing in the GUI. > > See Hamish's reply. > >> Likewise, you can?t get >> it to print out current environment settings from the gui unless you do some >> tricks with its execution. > > AFAICT, the problem with g.gisenv is that it checks for argc==1 before > calling G_parser(), so e.g. "g.gisenv --quiet" causes that check to > fail. > > What it should probably do is to call G_parser() unconditionally, then > check for: > > if (!get->answer && !set->answer && !store_opt->answer) > >> To behave more ?normally? it needs a ?p flag. Then... >> >> g.gisenv -> autogenerated gui >> g.gisenv ?p -> print current settings. >> >> I suppose that this would break a bunch of scripts, but it would be nice if >> it could work consistently with other commands. > > I suspect that this is unnecessary if the no-arguments check is fixed. __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Fri Jun 8 18:26:55 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jun 8 18:27:09 2007 Subject: [GRASS-dev] Re: [GRASSGUI] CLI working again In-Reply-To: <2CAF902F-25DD-4941-8E48-643E846024BF@kyngchaos.com> Message-ID: Hi William, On 6/8/07 7:15 AM, "William Kyngesburye" wrote: > I've been meaning to ask about wxgrass and CLI stuff - you're > obviously working on a GUI psuedo-terminal for running commands the > old-fashioned CLI way. I take it there is/will be no need for > something like 'grass-xterm-wrapper', and any place that the TclTk > GUI used that this pseudo terminal will work in wxgrass? This should be unnecessary for a couple of reasons. One is that the new wxgrass is native Mac, rather than xwindows. So stuff will run from the regular terminal. The other is the desire to include a built in terminal feature. This already exists in the TclTk version, but most people don't notice or take advantage of it--probably because it's kind of on the 'busy' side. > > PS. did you ever get a chance to try my Terminal-enabled version of > grass-xterm-wrapper? I've been lazy in committing it, so you'd have > to dig it out of the email, or maybe I should just commit it > anyways. It's in my binaries and I haven't heard of any problems yet... I guess I didn't but I'm not sure. I assumed that it was in the cvs. I've probably buried your email somewhere. But it must be working somehow, since I use the terminal for everything in the TclTk/x11 version of GRASS and don't need to use the x11 terminal. I'm compiling from your *.app setup. Michael > > On Jun 6, 2007, at 3:12 PM, Michael Barton wrote: > >> I got the CLI for wxgrass working again. You can type in any >> command (GRASS or shell). >> >> Non-GRASS commands will simply be passed to the shell. >> >> GRASS commands without arguments (e.g. g.region) will open their >> properties dialogs for non-display commands. d.* commands without >> arguments will add a layer to the GUI layer tree and open their >> respective properties dialog (e.g., d.rast). >> >> GRASS commands with arguments (e.g., g.region rast=elevation.10m) >> will be passed to the GRASS command shell for processing. d.* >> commands with arguments (e.g., d.rast elevation.10m) will display >> their results in the currently selected map display. Multiple >> display commands separated by commas will send overlaying graphic >> results to the current map display (e.g., d.rast elevation. >> 10m,d.vect roads color=red). >> >> Michael >> > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > "History is an illusion caused by the passage of time, and time is an > illusion caused by the passage of history." > > - Hitchhiker's Guide to the Galaxy > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From woklist at kyngchaos.com Fri Jun 8 18:49:04 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Fri Jun 8 18:49:29 2007 Subject: [GRASS-dev] Re: [GRASSGUI] CLI working again In-Reply-To: References: Message-ID: <64FA9260-C6D2-462A-8418-819D8ECDDA9E@kyngchaos.com> On Jun 8, 2007, at 11:26 AM, Michael Barton wrote: > Hi William, > > > On 6/8/07 7:15 AM, "William Kyngesburye" > wrote: > >> I've been meaning to ask about wxgrass and CLI stuff - you're >> obviously working on a GUI psuedo-terminal for running commands the >> old-fashioned CLI way. I take it there is/will be no need for >> something like 'grass-xterm-wrapper', and any place that the TclTk >> GUI used that this pseudo terminal will work in wxgrass? > > This should be unnecessary for a couple of reasons. One is that the > new > wxgrass is native Mac, rather than xwindows. So stuff will run from > the > regular terminal. The other is the desire to include a built in > terminal > feature. This already exists in the TclTk version, but most people > don't > notice or take advantage of it--probably because it's kind of on > the 'busy' > side. > I kinda figured it wouldn't need some sort of external pseudo- terminal thing and be able to use its own. Just checking. >> >> PS. did you ever get a chance to try my Terminal-enabled version of >> grass-xterm-wrapper? I've been lazy in committing it, so you'd have >> to dig it out of the email, or maybe I should just commit it >> anyways. It's in my binaries and I haven't heard of any problems >> yet... > > I guess I didn't but I'm not sure. I assumed that it was in the > cvs. I've > probably buried your email somewhere. But it must be working > somehow, since > I use the terminal for everything in the TclTk/x11 version of GRASS > and > don't need to use the x11 terminal. I'm compiling from your *.app > setup. > So, the create location by projection values opens in a Terminal? Then yes, you must have installed it into your source. When you update your CVS you probably always get a line "M lib/init/grass- xterm-wrapper". I'll commit it then, to make it official. ----- William Kyngesburye http://www.kyngchaos.com/ Theory of the Universe There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened. -Hitchhiker's Guide to the Galaxy 2nd season intro From isaac.ullah at asu.edu Fri Jun 8 23:14:52 2007 From: isaac.ullah at asu.edu (Isaac Ullah) Date: Fri Jun 8 23:14:57 2007 Subject: [GRASS-dev] Compile error on Kubuntu 7.04 Message-ID: <4f33f75e0706081414n38357ffftdcbf7627fc0a16d@mail.gmail.com> Hi Listers, I am trying to compile GRASS-6.3.cvs on my recently installed Kubuntu ( 7.04, Fiesty Fawn) system. I've successfully compiled before on the same laptop (a toshiba r 10) under MEPIS 6 (also ubuntu based) and MEPIS 3.4.2(debian based). However this time I get the following error that I don't really understand: make[1]: Entering directory `/home/isaac/Desktop/grass63-cvs-source/locale' Creating translations (= 'make mo') make[2]: Entering directory `/home/isaac/Desktop/grass63-cvs-source/locale' grasslibs_ar.po: /bin/sh: msgfmt: not found grasslibs_cs.po: /bin/sh: msgfmt: not found grasslibs_de.po: /bin/sh: msgfmt: not found grasslibs_el.po: /bin/sh: msgfmt: not found grasslibs_es.po: /bin/sh: msgfmt: not found grasslibs_fr.po: /bin/sh: msgfmt: not found grasslibs_hi.po: /bin/sh: msgfmt: not found grasslibs_it.po: /bin/sh: msgfmt: not found grasslibs_ja.po: /bin/sh: msgfmt: not found grasslibs_ko.po: /bin/sh: msgfmt: not found grasslibs_lv.po: /bin/sh: msgfmt: not found grasslibs_mr.po: /bin/sh: msgfmt: not found grasslibs_pl.po: /bin/sh: msgfmt: not found grasslibs_pt_br.po: /bin/sh: msgfmt: not found grasslibs_ru.po: /bin/sh: msgfmt: not found grasslibs_sl.po: /bin/sh: msgfmt: not found grasslibs_tr.po: /bin/sh: msgfmt: not found grasslibs_vi.po: /bin/sh: msgfmt: not found grasslibs_zh.po: /bin/sh: msgfmt: not found grassmods_ar.po: /bin/sh: msgfmt: not found grassmods_cs.po: /bin/sh: msgfmt: not found grassmods_de.po: /bin/sh: msgfmt: not found grassmods_el.po: /bin/sh: msgfmt: not found grassmods_es.po: /bin/sh: msgfmt: not found grassmods_fr.po: /bin/sh: msgfmt: not found grassmods_hi.po: /bin/sh: msgfmt: not found grassmods_it.po: /bin/sh: msgfmt: not found grassmods_ja.po: /bin/sh: msgfmt: not found grassmods_ko.po: /bin/sh: msgfmt: not found grassmods_lv.po: /bin/sh: msgfmt: not found grassmods_mr.po: /bin/sh: msgfmt: not found grassmods_pl.po: /bin/sh: msgfmt: not found grassmods_pt_br.po: /bin/sh: msgfmt: not found grassmods_ru.po: /bin/sh: msgfmt: not found grassmods_sl.po: /bin/sh: msgfmt: not found grassmods_tr.po: /bin/sh: msgfmt: not found grassmods_vi.po: /bin/sh: msgfmt: not found grassmods_zh.po: /bin/sh: msgfmt: not found grasstcl_ar.po: /bin/sh: msgfmt: not found grasstcl_cs.po: /bin/sh: msgfmt: not found grasstcl_de.po: /bin/sh: msgfmt: not found grasstcl_el.po: /bin/sh: msgfmt: not found grasstcl_es.po: /bin/sh: msgfmt: not found grasstcl_fr.po: /bin/sh: msgfmt: not found grasstcl_hi.po: /bin/sh: msgfmt: not found grasstcl_it.po: /bin/sh: msgfmt: not found grasstcl_ja.po: /bin/sh: msgfmt: not found grasstcl_ko.po: /bin/sh: msgfmt: not found grasstcl_lv.po: /bin/sh: msgfmt: not found grasstcl_mr.po: /bin/sh: msgfmt: not found grasstcl_pl.po: /bin/sh: msgfmt: not found grasstcl_pt_br.po: /bin/sh: msgfmt: not found grasstcl_ru.po: /bin/sh: msgfmt: not found grasstcl_sl.po: /bin/sh: msgfmt: not found grasstcl_tr.po: /bin/sh: msgfmt: not found grasstcl_vi.po: /bin/sh: msgfmt: not found grasstcl_zh.po: /bin/sh: msgfmt: not found make[2]: *** [mo] Error 127 make[2]: Leaving directory `/home/isaac/Desktop/grass63-cvs-source/locale' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/isaac/Desktop/grass63-cvs-source/locale' make: *** [default] Error 2 Does anyone know what the problem is here? I've never seen this error during any of the other times I've compiled GRASS... Any help would be greatly appreciated! Cheers, Isaac -- Isaac I Ullah, M.A. Archaeology PhD Student, ASU School of Evolution and Social Change Research Assistant, Mediterranean Landscape Dynamics Project *************************************************** isaac.ullah@asu.edu ullah@archaeologist.com http://www.public.asu.edu/~iullah *************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070608/a631ba11/attachment-0001.html From dca.gis at gmail.com Fri Jun 8 23:45:16 2007 From: dca.gis at gmail.com (Daniel Calvelo) Date: Fri Jun 8 23:45:18 2007 Subject: [GRASS-dev] Compile error on Kubuntu 7.04 In-Reply-To: <4f33f75e0706081414n38357ffftdcbf7627fc0a16d@mail.gmail.com> References: <4f33f75e0706081414n38357ffftdcbf7627fc0a16d@mail.gmail.com> Message-ID: <1a486f560706081445q4ab40124hf7bf7643dfde7e74@mail.gmail.com> Hi Isaac. You don't seem to have gettext installed. Try to apt-get install gettext. Daniel. On 6/8/07, Isaac Ullah wrote: > Hi Listers, > > I am trying to compile GRASS-6.3.cvs on my recently installed Kubuntu > (7.04, Fiesty Fawn) system. I've successfully compiled before on the same > laptop (a toshiba r 10) under MEPIS 6 (also ubuntu based) and MEPIS 3.4.2 > (debian based). However this time I get the following error that I don't > really understand: > > make[1]: Entering directory > `/home/isaac/Desktop/grass63-cvs-source/locale' > Creating translations (= 'make mo') > make[2]: Entering directory > `/home/isaac/Desktop/grass63-cvs-source/locale' > grasslibs_ar.po: /bin/sh: msgfmt: not found > grasslibs_cs.po: /bin/sh: msgfmt: not found > grasslibs_de.po: /bin/sh: msgfmt: not found > grasslibs_el.po: /bin/sh: msgfmt: not found > grasslibs_es.po: /bin/sh: msgfmt: not found > grasslibs_fr.po: /bin/sh: msgfmt: not found > grasslibs_hi.po: /bin/sh: msgfmt: not found > grasslibs_it.po: /bin/sh: msgfmt: not found > grasslibs_ja.po: /bin/sh: msgfmt: not found > grasslibs_ko.po: /bin/sh: msgfmt: not found > grasslibs_lv.po: /bin/sh: msgfmt: not found > grasslibs_mr.po: /bin/sh: msgfmt: not found > grasslibs_pl.po: /bin/sh: msgfmt: not found > grasslibs_pt_br.po: /bin/sh: msgfmt: not found > grasslibs_ru.po: /bin/sh: msgfmt: not found > grasslibs_sl.po: /bin/sh: msgfmt: not found > grasslibs_tr.po: /bin/sh: msgfmt: not found > grasslibs_vi.po: /bin/sh: msgfmt: not found > grasslibs_zh.po: /bin/sh: msgfmt: not found > grassmods_ar.po: /bin/sh: msgfmt: not found > grassmods_cs.po: /bin/sh: msgfmt: not found > grassmods_de.po: /bin/sh: msgfmt: not found > grassmods_el.po: /bin/sh: msgfmt: not found > grassmods_es.po: /bin/sh: msgfmt: not found > grassmods_fr.po: /bin/sh: msgfmt: not found > grassmods_hi.po: /bin/sh: msgfmt: not found > grassmods_it.po: /bin/sh: msgfmt: not found > grassmods_ja.po: /bin/sh: msgfmt: not found > grassmods_ko.po: /bin/sh: msgfmt: not found > grassmods_lv.po: /bin/sh: msgfmt: not found > grassmods_mr.po: /bin/sh: msgfmt: not found > grassmods_pl.po: /bin/sh: msgfmt: not found > grassmods_pt_br.po: /bin/sh: msgfmt: not found > grassmods_ru.po: /bin/sh: msgfmt: not found > grassmods_sl.po: /bin/sh: msgfmt: not found > grassmods_tr.po: /bin/sh: msgfmt: not found > grassmods_vi.po: /bin/sh: msgfmt: not found > grassmods_zh.po: /bin/sh: msgfmt: not found > grasstcl_ar.po: /bin/sh: msgfmt: not found > grasstcl_cs.po: /bin/sh: msgfmt: not found > grasstcl_de.po: /bin/sh: msgfmt: not found > grasstcl_el.po: /bin/sh: msgfmt: not found > grasstcl_es.po: /bin/sh: msgfmt: not found > grasstcl_fr.po: /bin/sh: msgfmt: not found > grasstcl_hi.po: /bin/sh: msgfmt: not found > grasstcl_it.po: /bin/sh: msgfmt: not found > grasstcl_ja.po: /bin/sh: msgfmt: not found > grasstcl_ko.po: /bin/sh: msgfmt: not found > grasstcl_lv.po: /bin/sh: msgfmt: not found > grasstcl_mr.po: /bin/sh: msgfmt: not found > grasstcl_pl.po: /bin/sh: msgfmt: not found > grasstcl_pt_br.po: /bin/sh: msgfmt: not found > grasstcl_ru.po: /bin/sh: msgfmt: not found > grasstcl_sl.po: /bin/sh: msgfmt: not found > grasstcl_tr.po: /bin/sh: msgfmt: not found > grasstcl_vi.po: /bin/sh: msgfmt: not found > grasstcl_zh.po: /bin/sh: msgfmt: not found > make[2]: *** [mo] Error 127 > make[2]: Leaving directory > `/home/isaac/Desktop/grass63-cvs-source/locale' > make[1]: *** [default] Error 2 > make[1]: Leaving directory > `/home/isaac/Desktop/grass63-cvs-source/locale' > make: *** [default] Error 2 > > Does anyone know what the problem is here? I've never seen this error during > any of the other times I've compiled GRASS... Any help would be greatly > appreciated! > > Cheers, > > Isaac > > > -- > > Isaac I Ullah, M.A. > > Archaeology PhD Student, > ASU School of Evolution and Social Change > > Research Assistant, > Mediterranean Landscape Dynamics Project > *************************************************** > isaac.ullah@asu.edu > ullah@archaeologist.com > > http://www.public.asu.edu/~iullah > *************************************************** > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- -- Daniel Calvelo Aros From Michael.Barton at asu.edu Sat Jun 9 08:30:39 2007 From: Michael.Barton at asu.edu (Michael Barton) Date: Sat Jun 9 08:40:41 2007 Subject: [GRASS-dev] GRASS_ADDON_PATH question Message-ID: >From reading the docs, it appears that if you set the GRASS_ADDON_PATH variable, you should have access to any modules or scripts stored therein by simply typing the name of the module or script. However, it doesn?t seem to work. I?ve tried setting this from the GRASS command line, .grass.bashrc file for testing, and my .grassrc6 file Nothing seems to work. If I type the name of a script residing in the directory I?ve set in GRASS_ADDON_PATH, I simply get a file not found error. However, if I do ls $GRASS_ADDON_PATH, I get a valid listing of the directory specified. What am I missing here? Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From woklist at kyngchaos.com Sat Jun 9 17:33:48 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Sat Jun 9 17:34:15 2007 Subject: [GRASS-dev] GRASS_ADDON_PATH question In-Reply-To: References: Message-ID: GRASS_ADDON_PATH is used at startup, in init.sh. All that happens is that it is added to the shell PATH. So setting it after GRASS starts isn't going to work. And there is a quirk with .grass.bashrc that it is not loaded until after the mapset selection happens, which is also after GRASS_ADDON_PATH is processed. Try setting it in .bash_profile. Note: the OSX app has a couple 'standard' addon locations: /Library/GRASS/[version]/modules/bin $HOME/Library/GRASS/[version]/modules/bin so if you put scripts there you don't have to fiddle with GRASS_ADDON_PATH. As you might guess, /Library is available to all users and ~/Library is available only to one user. On Jun 9, 2007, at 1:30 AM, Michael Barton wrote: >> From reading the docs, it appears that if you set the >> GRASS_ADDON_PATH > variable, you should have access to any modules or scripts stored > therein by > simply typing the name of the module or script. However, it doesn?t > seem to > work. > > I?ve tried setting this from the GRASS command line, .grass.bashrc > file for > testing, and my .grassrc6 file > > Nothing seems to work. If I type the name of a script residing in the > directory I?ve set in GRASS_ADDON_PATH, I simply get a file not > found error. > However, if I do ls $GRASS_ADDON_PATH, I get a valid listing of the > directory specified. > > What am I missing here? ----- William Kyngesburye http://www.kyngchaos.com/ "We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty." "Don't you even hate 'em?" "What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the ____ it wouldn't kill one ___ nor shorten the war one day." "And it might give 'em all stomach ulcers." - Tarzan, on war From glynn at gclements.plus.com Sat Jun 9 19:11:44 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jun 9 19:11:48 2007 Subject: [GRASS-dev] GRASS_ADDON_PATH question In-Reply-To: References: Message-ID: <18026.57168.779254.933480@cerise.gclements.plus.com> Michael Barton wrote: > From reading the docs, it appears that if you set the GRASS_ADDON_PATH > variable, you should have access to any modules or scripts stored therein by > simply typing the name of the module or script. However, it doesn?t seem to > work. > > I?ve tried setting this from the GRASS command line, .grass.bashrc file for > testing, and my .grassrc6 file > > Nothing seems to work. If I type the name of a script residing in the > directory I?ve set in GRASS_ADDON_PATH, I simply get a file not found error. > However, if I do ls $GRASS_ADDON_PATH, I get a valid listing of the > directory specified. > > What am I missing here? If it is set, Init.sh adds $GRASS_ADDON_PATH to $PATH. IOW, to be of any use, it must be set prior to starting GRASS. Changing it once GRASS has started has no effect. Note that the contents of ~/.grass.bashrc are read by the session shell which is spawned from Init.sh; it will not affect the operation of Init.sh itself. -- Glynn Clements From michael.barton at asu.edu Sat Jun 9 21:31:09 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Jun 9 21:32:15 2007 Subject: [GRASS-dev] GRASS_ADDON_PATH question In-Reply-To: Message-ID: Thanks William. I'll give this a try. What I'm trying to do is see if I can set this for the scripts already in $GISBASE/etc/gm/script. Michael On 6/9/07 8:33 AM, "William Kyngesburye" wrote: > GRASS_ADDON_PATH is used at startup, in init.sh. All that happens is > that it is added to the shell PATH. So setting it after GRASS starts > isn't going to work. And there is a quirk with .grass.bashrc that it > is not loaded until after the mapset selection happens, which is also > after GRASS_ADDON_PATH is processed. > > Try setting it in .bash_profile. > > Note: the OSX app has a couple 'standard' addon locations: > > /Library/GRASS/[version]/modules/bin > $HOME/Library/GRASS/[version]/modules/bin > > so if you put scripts there you don't have to fiddle with > GRASS_ADDON_PATH. As you might guess, /Library is available to all > users and ~/Library is available only to one user. > > On Jun 9, 2007, at 1:30 AM, Michael Barton wrote: > >>> From reading the docs, it appears that if you set the >>> GRASS_ADDON_PATH >> variable, you should have access to any modules or scripts stored >> therein by >> simply typing the name of the module or script. However, it doesn?t >> seem to >> work. >> >> I?ve tried setting this from the GRASS command line, .grass.bashrc >> file for >> testing, and my .grassrc6 file >> >> Nothing seems to work. If I type the name of a script residing in the >> directory I?ve set in GRASS_ADDON_PATH, I simply get a file not >> found error. >> However, if I do ls $GRASS_ADDON_PATH, I get a valid listing of the >> directory specified. >> >> What am I missing here? > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > "We are at war with them. Neither in hatred nor revenge and with no > particular pleasure I shall kill every ___ I can until the war is > over. That is my duty." > > "Don't you even hate 'em?" > > "What good would it do if I did? If all the many millions of people > of the allied nations devoted an entire year exclusively to hating > the ____ it wouldn't kill one ___ nor shorten the war one day." > > "And it might give 'em all stomach ulcers." > > - Tarzan, on war > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Sat Jun 9 22:08:45 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Jun 9 22:17:05 2007 Subject: [GRASS-dev] GRASS_ADDON_PATH question In-Reply-To: <18026.57168.779254.933480@cerise.gclements.plus.com> Message-ID: Thanks. William Kyngesbury also let me know about this. I'm going to propose a more generic solution to the problem I'm having. Michael On 6/9/07 10:11 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> From reading the docs, it appears that if you set the GRASS_ADDON_PATH >> variable, you should have access to any modules or scripts stored therein by >> simply typing the name of the module or script. However, it doesn?t seem to >> work. >> >> I?ve tried setting this from the GRASS command line, .grass.bashrc file for >> testing, and my .grassrc6 file >> >> Nothing seems to work. If I type the name of a script residing in the >> directory I?ve set in GRASS_ADDON_PATH, I simply get a file not found error. >> However, if I do ls $GRASS_ADDON_PATH, I get a valid listing of the >> directory specified. >> >> What am I missing here? > > If it is set, Init.sh adds $GRASS_ADDON_PATH to $PATH. IOW, to be of > any use, it must be set prior to starting GRASS. Changing it once > GRASS has started has no effect. > > Note that the contents of ~/.grass.bashrc are read by the session > shell which is spawned from Init.sh; it will not affect the operation > of Init.sh itself. __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Sat Jun 9 22:25:14 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Jun 9 22:27:11 2007 Subject: [GRASS-dev] resolving more menu issues Message-ID: I?ve come across a couple more menu issues that I?d like to propose solving in a general way that will work with multiple GUI?s 1. Currently, there are scripts that are only used (or only easily used) by the GUI. These reside in $GISBASE/etc/gm/script. The reason for these scripts is to overcome some inherent limitations of the interface to several important GRASS commands. For example, one script (r.colors.rules) allows you to chose the file for which you want to manage colors interactively through the GUI, then launches r.colors so that it opens an interactive xterm for setting color rules. Another provides a functional GUI interface to v.type without needing an interactive xmon. Yet another allows you to use the GUI to specify a reclassification file to send to r.reclass. You get the idea. Having them buried in $GISBASE/etc/gm/script makes them more difficult for anything but the TclTk GUI to access these scripts. Some are primarily for the GUI, but others might be more broadly useful. I propose either moving these to a new directory $GISBASE/scripts/gui and adding this as a path in init.sh OR simply moving them to $GISBASE/scripts. Several are now obsolete (e.g., d.text.sh and v.in.asciipoints) and could be removed. I?d change the reference to them in the GUI (i.e., no longer necessary to specify a full path). Is this OK with everyone? 2. Related to this, I?d like to make a couple more of the scripts obsolete if someone can help. r.reclass and r.recode can use input files for reclass/recode rules. But the only way to get the file into either command is via a redirect. (e.g., [path to file] > r.reclass). Can a file= argument be added to both of these like it was recently added to r.colors? This would dispense with these scripts. Thanks Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070609/3502d1d9/attachment-0001.html From grass-bugs at intevation.de Sat Jun 9 23:22:30 2007 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Sat Jun 9 23:19:16 2007 Subject: [GRASS-dev] [bug #4487] (grass) TCLTK GUI: command window freezes due to a very verbose text output Message-ID: <20070609212230.2280561443A@lists.intevation.de> Hi Letting you know that this bug is still there. I have just experienced it with v.distance. Some modules prone to this bug (in general - any module which might print few hundred lines or more quite quickly): v.hull nviz v.distance r.stats db.select v.db.select v.report v.to.db When the bug crops out, it looks like if the given module freezed: 100% CPU usage, module's tcl/tk window does not refresh. For real the command still works, but it gets several times slower than if run from the terminal, which adds to the impression that the module has freezed. The bug is present in current 6.2 and 6.3 CVS. Using tcl/tk 8.4.12 at build time and run time. Ubuntu Dapper 32bit, kernel 2.6.15. As well as on 2 other machines, of which one is 64bit. It's quite a widespread and important problem for tcl/tk GUI users. Can we do anything about it? Maciek -------------------------------------------- Managed by Request Tracker From hamish_nospam at yahoo.com Sun Jun 10 10:15:40 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Jun 10 10:15:49 2007 Subject: [GRASS-dev] [grass-code I][420] v.transform pointsfile does not accept points in dd:mm:ss format In-Reply-To: <20070607131213.8786DB53A9@pyrosoma.intevation.org> References: <20070607131213.8786DB53A9@pyrosoma.intevation.org> Message-ID: <20070610201540.72df3023.hamish_nospam@yahoo.com> > code I item #420, was opened at 2007-06-07 15:12 > Submitted By: Harri Kiiskinen (harrikoo) .. > v.transform does not accept point coordinated given as dd:mm:ss.ss in > the 'pointsfile' option. If the coordinates are changed into decimal, > everything works ok. > You can respond by visiting: > http://wald.intevation.org/tracker/?func=detail&atid=204&aid=420&group_id=21 probably it is very easy to fix this. The module needs to call G_scan_northing() and G_scan_easting() which will convert a coordinate string to a double. Also there is G_scan_resolution() for scanning non-hemispheral degrees. It looks like they should go in v.transform/get_coor.c use for x,y,zshift command line options as well? Hamish From hamish_nospam at yahoo.com Sun Jun 10 10:25:14 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Jun 10 10:56:36 2007 Subject: [GRASS-dev] d.extend in gui In-Reply-To: <18025.22280.219107.869953@cerise.gclements.plus.com> References: <18025.22280.219107.869953@cerise.gclements.plus.com> Message-ID: <20070610202514.27c1d140.hamish_nospam@yahoo.com> Glynn Clements wrote: > It shouldn't be particularly complicated to make g.region accept any > combination of region=, rast=, rast3d=, vect= and zoom= (and possibly > also n=/s=/e=/w=) and to set the region to the union of all of them. > Actually, -d could also be used, and you might want an option to > include the current region as well. The mention of -d reminds me that g.region (or anything else) still lacks a way to reset the DEFAULT_WIND region. When creating new location from EPSG code the default region is just set to 0,1,0,1 IIRC. I'm not sure what happens if you create a new location from a datafile with r.in.gdal/v.in.ogr. Hopefully it sets the default region to match that map's region, but I'm not sure if it does or not. Hamish From michael.barton at asu.edu Sun Jun 10 06:47:46 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Jun 10 12:37:18 2007 Subject: [GRASS-dev] silly question - running a python script Message-ID: I made a python script (rules_colors.py) , following the template on the GRASS WIKI I can run the script from the command line... python rules_colors.py ...and it launches a TclTk GUI. When I try to launch it from within the wxPython GUI, it will not launch and gives the error... IOError: Couldn't fetch interface description for command . Indeed if I try to launch it from the command line with... python rules_colors.py --interface-description ...it gives me an error and does not recognize the ??interface-description? flag. This will need to work correctly if we are to start doing scripts in Python. Any suggestions? Mciahel __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070609/f0855506/attachment.html From hamish_nospam at yahoo.com Sun Jun 10 12:46:28 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Jun 10 12:46:38 2007 Subject: [GRASS-dev] resolving more menu issues In-Reply-To: References: Message-ID: <20070610224628.5b2aa024.hamish_nospam@yahoo.com> Michael Barton wrote: > I?ve come across a couple more menu issues that I?d like to propose > solving in a general way that will work with multiple GUI?s > > 1. Currently, there are scripts that are only used (or only easily > used) by the GUI. These reside in $GISBASE/etc/gm/script. The reason > for these scripts is to overcome some inherent limitations of the > interface to several important GRASS commands. .. > Having them buried in $GISBASE/etc/gm/script makes them more difficult > for anything but the TclTk GUI to access these scripts. Some are > primarily for the GUI, but others might be more broadly useful. > > I propose either moving these to a new directory $GISBASE/scripts/gui > and adding this as a path in init.sh OR simply moving them to > $GISBASE/scripts. Several are now obsolete (e.g., d.text.sh and > v.in.asciipoints) and could be removed. I?d change the reference to > them in the GUI (i.e., no longer necessary to specify a full path). Yes, it would be nice to move generic wrapper scripts which are just needed for a GUI/core interaction (ie nothing to do with tcl or wx) from gui/tcltk/gis.m/script/ to gui/script/ or somesuch place. right now we have: d.colors.sh d.path.sh d.shadedmap d.text.sh d.title.sh print.sh r.colors.rules r.reclass.file r.reclass.rules r.recode.file r.recode.rules r.support.sh v.in.asciipoints v.type.sh d.shademap is the only one I see there which might move to scripts/. for the others, probably one of: $GISBASE/etc/gui/scripts/ $GISBASE/scripts/gui/ $GISBASE/scripts/ Personally, I favour $GISBASE/etc/gui/scripts/. You shouldn't add anything init.sh, just change the existing references to $GB/etc/gm/scripts/ to the new place. I don't think there is anything complicated there to worry about losing the CVS history by moving the file in CVS to grass6/gui/scripts/. The history was already cropped when copied from d.m. Maybe add a comment in the CVS checkin message about their migration from d.m/scripts/ to gis.m/scripts/ to the new spot, so there is a trail to follow if someone wants to track a history. And of course these all exist due to deficiencies in modules, which should be fixed directly; and any outdated scripts should be removed. Note r.support.sh works around a very weird bug where the module quits after only the first few [y/N] questions in the xterm. https://intevation.de/rt/webrt?serial_num=5094 Hamish From glynn at gclements.plus.com Sun Jun 10 15:33:39 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jun 10 15:33:43 2007 Subject: [GRASS-dev] Re: [GRASSGUI] resolving more menu issues In-Reply-To: References: Message-ID: <18027.64947.87901.392291@cerise.gclements.plus.com> Michael Barton wrote: > 1. Currently, there are scripts that are only used (or only easily used) by > the GUI. These reside in $GISBASE/etc/gm/script. The reason for these > scripts is to overcome some inherent limitations of the interface to several > important GRASS commands. For example, one script (r.colors.rules) allows > you to chose the file for which you want to manage colors interactively > through the GUI, then launches r.colors so that it opens an interactive > xterm for setting color rules. Another provides a functional GUI interface > to v.type without needing an interactive xmon. Yet another allows you to use > the GUI to specify a reclassification file to send to r.reclass. You get the > idea. > > Having them buried in $GISBASE/etc/gm/script makes them more difficult for > anything but the TclTk GUI to access these scripts. Some are primarily for > the GUI, but others might be more broadly useful. > > I propose either moving these to a new directory $GISBASE/scripts/gui and > adding this as a path in init.sh OR simply moving them to $GISBASE/scripts. > Several are now obsolete (e.g., d.text.sh and v.in.asciipoints) and could be > removed. I?d change the reference to them in the GUI (i.e., no longer > necessary to specify a full path). > > Is this OK with everyone? I suggest using $GISBASE/scripts for anything which isn't inherently limited to the GUI. > 2. Related to this, I?d like to make a couple more of the scripts obsolete > if someone can help. > > r.reclass and r.recode can use input files for reclass/recode rules. But the > only way to get the file into either command is via a redirect. (e.g., [path > to file] > r.reclass). Can a file= argument be added to both of these like > it was recently added to r.colors? This would dispense with these scripts. An alternative is to add stdin= and stdout= pseudo-options to the module's GUI dialog, so that the user can redirect stdin/stdout of any command from/to a file. This can be done in addition to a file= option for modules where it would be useful. However: any module which is run from the GUI must behave in a non-interactive manner regardless of which flags/options the user selects. Having the module hang because the user chose a combination of options which results in the module trying to read from stdin isn't acceptable. You can probably eliminate hanging by simply closing stdin (or redirecting it from /dev/null), although that may just result in a different form of misbehaviour. Ultimately, the only complete solution is to adopt (and enforce) a policy that "modules" are never interactive. No exceptions. Absolutely no exceptions whatsoever. The last point won't happen before the 7.x branch comes into existence, but I guarantee[1] that it will happen immediately thereafter. [1] Well, so long as I'm still alive, sentient, and have commit access; if I can make it happen, I will. -- Glynn Clements From glynn at gclements.plus.com Sun Jun 10 15:57:05 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jun 10 15:57:09 2007 Subject: [GRASS-dev] Re: [GRASSGUI] silly question - running a python script In-Reply-To: References: Message-ID: <18028.817.799357.576820@cerise.gclements.plus.com> Michael Barton wrote: > I made a python script (rules_colors.py) Can we see the script? > following the template on the GRASS WIKI > > Oh no: for arg in sys.argv: args += arg+" " Jesus H %$&%*ing Christ, has no-one read anything I've said over the past however-many years about argv[] being an array/list, and not a string? os.system("g.parser %s" % (args)) Use os.execve(). > I can run the script from the command line... > > python rules_colors.py > > ...and it launches a TclTk GUI. You're running the command (which command? r.colors?) with no arguments. For many commands, this will bring up a Tcl/Tk GUI (unless GRASS_UI_TERM is set, in which case it will use a Q&A dialogue on the terminal). This behaviour is hard-coded into G_parser(). If you want to use a Python GUI, modify your script to invoke the command with --interface-description and feed that to the Python GUI. Or modify G_gui() to optionally invoke a wxPython GUI instead of the Tcl/Tk one. > When I try to launch it from within the wxPython GUI, it will not launch and > gives the error... > > IOError: Couldn't fetch interface description for command . > > > Indeed if I try to launch it from the command line with... > > python rules_colors.py --interface-description > > ...it gives me an error and does not recognize the ??interface-description? > flag. Is the Python interpreter trying to process --interface-description itself? Does: python -- rules_colors.py --interface-description work? What about: chmod +x rules_colors.py ./rules_colors.py --interface-description ? [BTW, please use a sane mail client, at least for mailing lists. If you have to use a Mac-specific encoding (MacRoman?), at least ensure that it's labelled as such, and not as ISO-8859-1. Although, that in itself won't affect the fact that it's decided to convert "--" to an em-dash. If it has a "smart quotes" option, turn it off.] -- Glynn Clements From michael.barton at asu.edu Sun Jun 10 20:21:42 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Jun 10 20:28:18 2007 Subject: [GRASS-dev] Re: [GRASSGUI] silly question - running a python script In-Reply-To: <18028.817.799357.576820@cerise.gclements.plus.com> Message-ID: Glynn, I went in to change the WIKI, but don't quite have enough information to make sure that I'm doing it correctly On 6/10/07 6:57 AM, "Glynn Clements" wrote: > Oh no: > > for arg in sys.argv: > args += arg+" " > > Jesus H %$&%*ing Christ, has no-one read anything I've said over the > past however-many years about argv[] being an array/list, and not a > string? > > os.system("g.parser %s" % (args)) Here is what is currently there... if __name__ == "__main__": args = "" for arg in sys.argv: args += arg+" " try: if ( sys.argv[1] != "@ARGS_PARSED@" ): os.system("g.parser %s " % (args)) except IndexError: os.system("g.parser %s" % (args)) if sys.argv[1] == "@ARGS_PARSED@": main(); I found an old email of yours I'd been saving (and couldn't initially find) that covers part of what needs to be done. Following that, I think it would change to... if __name__ == "__main__": # No need to make a string here, right? # args = "" # for arg in sys.argv: # args += arg+" " try: if ( sys.argv[1] != "@ARGS_PARSED@" ): os.execv("g.parser", [sys.argv[0]] + sys.argv) except IndexError: os.execv("g.parser", [sys.argv[0]] + sys.argv) if sys.argv[1] == "@ARGS_PARSED@": main(); Is this correct or is it still missing something? Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Sun Jun 10 20:53:17 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Jun 10 21:00:00 2007 Subject: [GRASS-dev] Re: [GRASSGUI] silly question - running a python script In-Reply-To: <18028.817.799357.576820@cerise.gclements.plus.com> Message-ID: I forgot, to send the script. Here it is. Doesn't work and I haven't updated main to use a list. But maybe a starting place for figuring out how to do scripting with python and GRASS. Michael On 6/10/07 6:57 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> I made a python script (rules_colors.py) > > Can we see the script? > >> following the template on the GRASS WIKI >> >> > > Oh no: > > for arg in sys.argv: > args += arg+" " > > Jesus H %$&%*ing Christ, has no-one read anything I've said over the > past however-many years about argv[] being an array/list, and not a > string? > > os.system("g.parser %s" % (args)) > > Use os.execve(). > >> I can run the script from the command line... >> >> python rules_colors.py >> >> ...and it launches a TclTk GUI. > > You're running the command (which command? r.colors?) with no > arguments. For many commands, this will bring up a Tcl/Tk GUI (unless > GRASS_UI_TERM is set, in which case it will use a Q&A dialogue on the > terminal). > > This behaviour is hard-coded into G_parser(). If you want to use a > Python GUI, modify your script to invoke the command with > --interface-description and feed that to the Python GUI. > > Or modify G_gui() to optionally invoke a wxPython GUI instead of the > Tcl/Tk one. > >> When I try to launch it from within the wxPython GUI, it will not launch and >> gives the error... >> >> IOError: Couldn't fetch interface description for command . >> >> >> Indeed if I try to launch it from the command line with... >> >> python rules_colors.py --interface-description >> >> ...it gives me an error and does not recognize the ??interface-description? >> flag. > > Is the Python interpreter trying to process --interface-description > itself? Does: > > python -- rules_colors.py --interface-description > > work? > > What about: > > chmod +x rules_colors.py > ./rules_colors.py --interface-description > > ? > > [BTW, please use a sane mail client, at least for mailing lists. If > you have to use a Mac-specific encoding (MacRoman?), at least ensure > that it's labelled as such, and not as ISO-8859-1. Although, that in > itself won't affect the fact that it's decided to convert "--" to an > em-dash. If it has a "smart quotes" option, turn it off.] __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- #!/usr/bin/env python import sys import os import wx import rules # ############################################################################ # # MODULE: rules_colors.py # AUTHOR(S): Michael Barton # PURPOSE: Permit use of color rules in r.colors from wxgrass GUI # COPYRIGHT: (C) 2007 by the GRASS Development Team # # This program is free software under the GNU General Public # License (>=v2). Read the file COPYING that comes with GRASS # for details. # ############################################################################# #%Module #% description: Use rules to set colors for raster map #%End #%option #% key: map #% type: string #% gisprompt: old,cell,raster #% description: Name of raster map for color management #% required : yes #%end #%Option #% key: file #% type: string #% required: no #% multiple: no #% description: Name of rules file (if not given user is prompted for interactive entry) #% gisprompt: old_file,file,input #%End def main(): if os.getenv("GIS_OPT_FILE"): # get from file os.popen('r.colors map=%s color=%s rules=%s' % (os.getenv('GIS_OPT_MAP'),'rules',os.getenv('GIS_OPT_FILE'))) else: dlg = rules.RulesText(self,id=wx.ID_ANY, title="Enter color rules", pos=wx.DefaultPosition, size=wx.DefaultSize) dlg.CenterOnScreen() # if OK button pressed in decoration control dialog if dlg.ShowModal() == wx.ID_OK: colorrules = dlg.rules # run r.colors with rules os.popen('r.colors map=%s color=%s rules=%s' % (os.getenv('GIS_OPT_MAP'),'rules',colorrules)) dlg.Destroy() #end of your code return if __name__ == "__main__": # if not os.getenv("GISBASE"): # print "You must be in GRASS GIS to run this program" # args = "" for arg in sys.argv: args += arg+" " try: if ( sys.argv[1] != "@ARGS_PARSED@" ): os.system("g.parser %s " % (args)) except IndexError: os.system("g.parser %s" % (args)) if sys.argv[1] == "@ARGS_PARSED@": main(); From Michael.Barton at asu.edu Sun Jun 10 20:53:17 2007 From: Michael.Barton at asu.edu (Michael Barton) Date: Sun Jun 10 21:04:18 2007 Subject: [GRASS-dev] Re: [GRASSGUI] silly question - running a python script In-Reply-To: <18028.817.799357.576820@cerise.gclements.plus.com> Message-ID: I forgot, to send the script. Here it is. Doesn't work and I haven't updated main to use a list. But maybe a starting place for figuring out how to do scripting with python and GRASS. Michael On 6/10/07 6:57 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> I made a python script (rules_colors.py) > > Can we see the script? > >> following the template on the GRASS WIKI >> >> > > Oh no: > > for arg in sys.argv: > args += arg+" " > > Jesus H %$&%*ing Christ, has no-one read anything I've said over the > past however-many years about argv[] being an array/list, and not a > string? > > os.system("g.parser %s" % (args)) > > Use os.execve(). > >> I can run the script from the command line... >> >> python rules_colors.py >> >> ...and it launches a TclTk GUI. > > You're running the command (which command? r.colors?) with no > arguments. For many commands, this will bring up a Tcl/Tk GUI (unless > GRASS_UI_TERM is set, in which case it will use a Q&A dialogue on the > terminal). > > This behaviour is hard-coded into G_parser(). If you want to use a > Python GUI, modify your script to invoke the command with > --interface-description and feed that to the Python GUI. > > Or modify G_gui() to optionally invoke a wxPython GUI instead of the > Tcl/Tk one. > >> When I try to launch it from within the wxPython GUI, it will not launch and >> gives the error... >> >> IOError: Couldn't fetch interface description for command . >> >> >> Indeed if I try to launch it from the command line with... >> >> python rules_colors.py --interface-description >> >> ...it gives me an error and does not recognize the ??interface-description? >> flag. > > Is the Python interpreter trying to process --interface-description > itself? Does: > > python -- rules_colors.py --interface-description > > work? > > What about: > > chmod +x rules_colors.py > ./rules_colors.py --interface-description > > ? > > [BTW, please use a sane mail client, at least for mailing lists. If > you have to use a Mac-specific encoding (MacRoman?), at least ensure > that it's labelled as such, and not as ISO-8859-1. Although, that in > itself won't affect the fact that it's decided to convert "--" to an > em-dash. If it has a "smart quotes" option, turn it off.] __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- #!/usr/bin/env python import sys import os import wx import rules # ############################################################################ # # MODULE: rules_colors.py # AUTHOR(S): Michael Barton # PURPOSE: Permit use of color rules in r.colors from wxgrass GUI # COPYRIGHT: (C) 2007 by the GRASS Development Team # # This program is free software under the GNU General Public # License (>=v2). Read the file COPYING that comes with GRASS # for details. # ############################################################################# #%Module #% description: Use rules to set colors for raster map #%End #%option #% key: map #% type: string #% gisprompt: old,cell,raster #% description: Name of raster map for color management #% required : yes #%end #%Option #% key: file #% type: string #% required: no #% multiple: no #% description: Name of rules file (if not given user is prompted for interactive entry) #% gisprompt: old_file,file,input #%End def main(): if os.getenv("GIS_OPT_FILE"): # get from file os.popen('r.colors map=%s color=%s rules=%s' % (os.getenv('GIS_OPT_MAP'),'rules',os.getenv('GIS_OPT_FILE'))) else: dlg = rules.RulesText(self,id=wx.ID_ANY, title="Enter color rules", pos=wx.DefaultPosition, size=wx.DefaultSize) dlg.CenterOnScreen() # if OK button pressed in decoration control dialog if dlg.ShowModal() == wx.ID_OK: colorrules = dlg.rules # run r.colors with rules os.popen('r.colors map=%s color=%s rules=%s' % (os.getenv('GIS_OPT_MAP'),'rules',colorrules)) dlg.Destroy() #end of your code return if __name__ == "__main__": # if not os.getenv("GISBASE"): # print "You must be in GRASS GIS to run this program" # args = "" for arg in sys.argv: args += arg+" " try: if ( sys.argv[1] != "@ARGS_PARSED@" ): os.system("g.parser %s " % (args)) except IndexError: os.system("g.parser %s" % (args)) if sys.argv[1] == "@ARGS_PARSED@": main(); From michael.barton at asu.edu Sun Jun 10 22:02:20 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Jun 10 22:07:08 2007 Subject: [GRASS-dev] d.extend in gui In-Reply-To: <20070610202514.27c1d140.hamish_nospam@yahoo.com> Message-ID: On 6/10/07 1:25 AM, "Hamish" wrote: > Glynn Clements wrote: >> It shouldn't be particularly complicated to make g.region accept any >> combination of region=, rast=, rast3d=, vect= and zoom= (and possibly >> also n=/s=/e=/w=) and to set the region to the union of all of them. >> Actually, -d could also be used, and you might want an option to >> include the current region as well. > > > The mention of -d reminds me that g.region (or anything else) still > lacks a way to reset the DEFAULT_WIND region. When creating new location > from EPSG code the default region is just set to 0,1,0,1 IIRC. I'm not > sure what happens if you create a new location from a datafile with > r.in.gdal/v.in.ogr. Hopefully it sets the default region to match that > map's region, but I'm not sure if it does or not. Isn't that what the -s flag does now? Michael > > > Hamish > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From Michael.Barton at asu.edu Sun Jun 10 22:14:36 2007 From: Michael.Barton at asu.edu (Michael Barton) Date: Sun Jun 10 22:22:27 2007 Subject: [GRASS-dev] resolving more menu issues In-Reply-To: <20070610224628.5b2aa024.hamish_nospam@yahoo.com> Message-ID: On 6/10/07 3:46 AM, "Hamish" wrote: > Michael Barton wrote: >> I?ve come across a couple more menu issues that I?d like to propose >> solving in a general way that will work with multiple GUI?s >> >> 1. Currently, there are scripts that are only used (or only easily >> used) by the GUI. These reside in $GISBASE/etc/gm/script. The reason >> for these scripts is to overcome some inherent limitations of the >> interface to several important GRASS commands. > .. >> Having them buried in $GISBASE/etc/gm/script makes them more difficult >> for anything but the TclTk GUI to access these scripts. Some are >> primarily for the GUI, but others might be more broadly useful. >> >> I propose either moving these to a new directory $GISBASE/scripts/gui >> and adding this as a path in init.sh OR simply moving them to >> $GISBASE/scripts. Several are now obsolete (e.g., d.text.sh and >> v.in.asciipoints) and could be removed. I?d change the reference to >> them in the GUI (i.e., no longer necessary to specify a full path). > > > Yes, it would be nice to move generic wrapper scripts which are just > needed for a GUI/core interaction (ie nothing to do with tcl or wx) > from gui/tcltk/gis.m/script/ to gui/script/ or somesuch place. > Here is my assessment FWIW. This applies to current GUI and new wxPython one (d.m could stay like it is) > right now we have: > d.colors.sh - Obsolete d.path.sh - Of general use (more useful for GUI, but also for scripting) d.shadedmap - Of general use (simple way to do same thing with d.his) d.text.sh - Obsolete d.title.sh - Obsolete print.sh _ ????? r.colors.rules - Of general use (GUI for picking map; will be obsolete with wxgrass) r.reclass.file- Of general use, but would be unnessary with a file= option r.reclass.rules- Of general use (GUI for picking map; will be obsolete with wxgrass) r.recode.file- Of general use, but would be unnessary with a file= option r.recode.rules- Of general use (GUI for picking map; will be obsolete with wxgrass) r.support.sh - Obsoletes (maybe not??) v.in.asciipoints - Obsolete v.type.sh- Of general use (should effectively replace GUI for v.type) > > > d.shademap is the only one I see there which might move to scripts/. > > > for the others, probably one of: > $GISBASE/etc/gui/scripts/ > $GISBASE/scripts/gui/ > $GISBASE/scripts/ > > Personally, I favour $GISBASE/etc/gui/scripts/. You shouldn't add > anything init.sh, just change the existing references to > $GB/etc/gm/scripts/ to the new place. One objective would be to allow any of these to be run by simply typing their name, without the full path. To do this, they would need to go into a directory already listed in the PATH in init.sh or to add the new directory to the PATH in init.sh. I don't think there is anything > complicated there to worry about losing the CVS history by moving the > file in CVS to grass6/gui/scripts/. The history was already cropped when > copied from d.m. Maybe add a comment in the CVS checkin message about > their migration from d.m/scripts/ to gis.m/scripts/ to the new spot, so > there is a trail to follow if someone wants to track a history. > > And of course these all exist due to deficiencies in modules, which > should be fixed directly; and any outdated scripts should be removed. > > Note r.support.sh works around a very weird bug where the module quits > after only the first few [y/N] questions in the xterm. > https://intevation.de/rt/webrt?serial_num=5094 Even the new and improved r.support? Do I need PSC OK to make this kind of change to the cvs structure after we've worked it out? Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From glynn at gclements.plus.com Sun Jun 10 22:28:43 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jun 10 22:28:46 2007 Subject: [GRASS-dev] Re: [GRASSGUI] silly question - running a python script In-Reply-To: References: <18028.817.799357.576820@cerise.gclements.plus.com> Message-ID: <18028.24315.837665.819591@cerise.gclements.plus.com> Michael Barton wrote: > Here is what is currently there... > > if __name__ == "__main__": > args = "" > for arg in sys.argv: > args += arg+" " > > try: > if ( sys.argv[1] != "@ARGS_PARSED@" ): > os.system("g.parser %s " % (args)) > except IndexError: > os.system("g.parser %s" % (args)) > > if sys.argv[1] == "@ARGS_PARSED@": > main(); > > I found an old email of yours I'd been saving (and couldn't initially find) > that covers part of what needs to be done. Following that, I think it would > change to... > > if __name__ == "__main__": > # No need to make a string here, right? > # args = "" > # for arg in sys.argv: > # args += arg+" " > > try: > if ( sys.argv[1] != "@ARGS_PARSED@" ): > os.execv("g.parser", [sys.argv[0]] + sys.argv) > except IndexError: > os.execv("g.parser", [sys.argv[0]] + sys.argv) > > if sys.argv[1] == "@ARGS_PARSED@": > main(); > > Is this correct or is it still missing something? That looks about right. Although the "try ... except IndexError" can be replaced with a length check on sys.argv, i.e.: if __name__ == "__main__": if ( len(sys.argv) > 1 && sys.argv[1] != "@ARGS_PARSED@" ): os.execv("g.parser", [sys.argv[0]] + sys.argv) else: main() -- Glynn Clements From glynn at gclements.plus.com Sun Jun 10 22:36:14 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jun 10 22:36:18 2007 Subject: [GRASS-dev] Re: [GRASSGUI] silly question - running a python script In-Reply-To: References: <18028.817.799357.576820@cerise.gclements.plus.com> Message-ID: <18028.24766.865947.337023@cerise.gclements.plus.com> Michael Barton wrote: > I forgot, to send the script. Here it is. Doesn't work and I haven't updated > main to use a list. But maybe a starting place for figuring out how to do > scripting with python and GRASS. If I comment out the "import wx" and "import rules", then both: python rules_colors.py --interface-description and: chmod +x rules_colors.py ./rules_colors.py --interface-description work fine. Ditto for --help etc. That indicates that the use of g.parser is okay. BTW, what's the point of using: #!/usr/bin/env python rather than: #!/usr/bin/python ? AFAICT, using env in this way is a no-op. -- Glynn Clements From glynn at gclements.plus.com Sun Jun 10 22:46:27 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jun 10 22:46:32 2007 Subject: [GRASS-dev] Re: [GRASSGUI] silly question - running a python script In-Reply-To: <18028.24315.837665.819591@cerise.gclements.plus.com> References: <18028.817.799357.576820@cerise.gclements.plus.com> <18028.24315.837665.819591@cerise.gclements.plus.com> Message-ID: <18028.25379.623018.377963@cerise.gclements.plus.com> Glynn Clements wrote: > Although the "try ... except IndexError" can be replaced with a length > check on sys.argv, i.e.: > > if __name__ == "__main__": > if ( len(sys.argv) > 1 && sys.argv[1] != "@ARGS_PARSED@" ): > os.execv("g.parser", [sys.argv[0]] + sys.argv) > else: > main() Correction: if __name__ == "__main__": if ( len(sys.argv) <= 1 or sys.argv[1] != "@ARGS_PARSED@" ): os.execvp("g.parser", [sys.argv[0]] + sys.argv) else: main(); -- Glynn Clements From michael.barton at asu.edu Sun Jun 10 22:53:14 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Jun 10 22:55:32 2007 Subject: [GRASS-dev] Re: [GRASSGUI] silly question - running a python script In-Reply-To: <18028.25379.623018.377963@cerise.gclements.plus.com> Message-ID: OK. I've changed the WIKI accordingly. Michael On 6/10/07 1:46 PM, "Glynn Clements" wrote: > > Glynn Clements wrote: > >> Although the "try ... except IndexError" can be replaced with a length >> check on sys.argv, i.e.: >> >> if __name__ == "__main__": >> if ( len(sys.argv) > 1 && sys.argv[1] != "@ARGS_PARSED@" ): >> os.execv("g.parser", [sys.argv[0]] + sys.argv) >> else: >> main() > > Correction: > > if __name__ == "__main__": > if ( len(sys.argv) <= 1 or sys.argv[1] != "@ARGS_PARSED@" ): > os.execvp("g.parser", [sys.argv[0]] + sys.argv) > else: > main(); __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From cdavilam at jemila.jazztel.es Sun Jun 10 22:58:44 2007 From: cdavilam at jemila.jazztel.es (=?ISO-8859-15?Q?Carlos_D=E1vila?=) Date: Sun Jun 10 22:57:42 2007 Subject: [GRASS-dev] Message standardization Message-ID: <466C6604.8010300@jemila.jazztel.es> Hello all I'm new in dev list, but I've been working in translations for some time. I would like to standardize some grass messages, according to what is proposed in http://grass.gdf-hannover.de/wiki/Development_Specs (please check last changes) in order to ease the work for translators and get a more consistent program. I don't know if standard messages proposed in wiki can already be used or if discussion is still open. Any feedback is welcome. If no objections are reported, I will start changing messages in the next days, at least the most obvious. Regards Carlos D?vila (translation manager) From cdavilam at jemila.jazztel.es Sun Jun 10 23:06:49 2007 From: cdavilam at jemila.jazztel.es (=?ISO-8859-1?Q?Carlos_D=E1vila?=) Date: Sun Jun 10 23:05:45 2007 Subject: [GRASS-dev] [Fwd: Re: Missing message in r.in.ogr] Message-ID: <466C67E9.9030409@jemila.jazztel.es> Does anybody knows how to solve what's described below? On Tue, May 15, 2007 at 07:33:49PM +0200, Carlos D?vila wrote: > I have translated all r.in.ogr messages, but there's still "Allow > overwrite" at the bottom of dialogue. I cannot find this string in > grassmods.po neither in any file in r.in.ogr folder. Where does it come > from? Hi Carlos, [v.in.ogr] it comes from the lib/gis/parser.c grep Allow lib/gis/parser.c fprintf(stderr," --o %s\n", _("Allow output files to overwrite existing files")); fprintf(stdout, "
Allow output files to overwrite existing files
\n"); fprintf(fp, " desc {Allow output files to overwrite existing files}\n"); fprintf(fp, " label {Allow overwrite}\n"); I don't know how to indicate the gettext macro there properly - could you ask on the list? Markus From michael.barton at asu.edu Sun Jun 10 23:18:25 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Jun 10 23:21:07 2007 Subject: [GRASS-dev] why won't this execute in cmd.py? Message-ID: Martin, Any idea why this won't execute in cmd.py? cmdlst = ['d.mon','start=%s' % xmon, '&'] p = cmd.Command(cmdlst) Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070610/f8977a51/attachment.html From dylan.beaudette at gmail.com Mon Jun 11 00:59:25 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Mon Jun 11 00:56:46 2007 Subject: [GRASS-dev] [grass-code I][420] v.transform pointsfile does not accept points in dd:mm:ss format In-Reply-To: <20070610201540.72df3023.hamish_nospam@yahoo.com> References: <20070607131213.8786DB53A9@pyrosoma.intevation.org> <20070610201540.72df3023.hamish_nospam@yahoo.com> Message-ID: <200706101559.25062.dylan.beaudette@gmail.com> On Sunday 10 June 2007 01:15, Hamish wrote: > > code I item #420, was opened at 2007-06-07 15:12 > > Submitted By: Harri Kiiskinen (harrikoo) > > .. > > > v.transform does not accept point coordinated given as dd:mm:ss.ss in > > the 'pointsfile' option. If the coordinates are changed into decimal, > > everything works ok. > > > > You can respond by visiting: > > http://wald.intevation.org/tracker/?func=detail&atid=204&aid=420&group_id > >=21 > > probably it is very easy to fix this. > > The module needs to call G_scan_northing() and G_scan_easting() which > will convert a coordinate string to a double. Also there is > G_scan_resolution() for scanning non-hemispheral degrees. > > It looks like they should go in v.transform/get_coor.c > > use for x,y,zshift command line options as well? > > > Hamish > Out of curiosity, do the methods in v.transform accurately work with spherical coordinates? cheers, -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 From michael.barton at asu.edu Mon Jun 11 02:08:44 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Jun 11 02:09:37 2007 Subject: [GRASS-dev] Re: [GRASSGUI] silly question - running a python script In-Reply-To: <18028.24766.865947.337023@cerise.gclements.plus.com> Message-ID: On 6/10/07 1:36 PM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> I forgot, to send the script. Here it is. Doesn't work and I haven't updated >> main to use a list. But maybe a starting place for figuring out how to do >> scripting with python and GRASS. > > If I comment out the "import wx" and "import rules", then both: > > python rules_colors.py --interface-description > and: > chmod +x rules_colors.py > ./rules_colors.py --interface-description > > work fine. Ditto for --help etc. I needed import wx and import rules to launch an interactive window in wxPython. I wonder why they cause problems. > > That indicates that the use of g.parser is okay. > > BTW, what's the point of using: > > #!/usr/bin/env python > > rather than: > > #!/usr/bin/python > It's that way in the modules in the svn. In the past, I've had trouble with the Python shbang on my Mac and so can't really tell which is better. My Python is in /usr/bin however. > > AFAICT, using env in this way is a no-op. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hamish_nospam at yahoo.com Mon Jun 11 02:39:52 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 11 02:43:45 2007 Subject: [GRASS-dev] d.extend in gui In-Reply-To: References: <20070610202514.27c1d140.hamish_nospam@yahoo.com> Message-ID: <20070611123952.500d6387.hamish_nospam@yahoo.com> Hamish wrote: > > The mention of -d reminds me that g.region (or anything else) still > > lacks a way to reset the DEFAULT_WIND region. Michael wrote: > Isn't that what the -s flag does now? And so it does. Nice work by Jachym. thanks, Hamish From hamish_nospam at yahoo.com Mon Jun 11 05:30:08 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 11 05:30:20 2007 Subject: [GRASS-dev] Re: [GRASSGUI] silly question - running a python script In-Reply-To: References: <18028.817.799357.576820@cerise.gclements.plus.com> Message-ID: <20070611153008.79482c07.hamish_nospam@yahoo.com> Glynn: > > Oh no: > > > > for arg in sys.argv: > > args += arg+" " I have updated the g.parser help page Python example with the fixed args usage, but I notice the Perl example there (6.3cvs version only) is broken as well. http://freegis.org/cgi-bin/viewcvs.cgi/grass6/general/g.parser/description.html if( $ARGV[0] ne '@ARGS_PARSED@' ){ my $arg = ""; for (my $i=0; $i < @ARGV;$i++) { $arg .= " $ARGV[$i] "; } system("$ENV{GISBASE}/bin/g.parser $0 $arg"); exit; } Also I notice a difference in the python version where main(): now ends with "return". Does this matter? Hamish From hamish_nospam at yahoo.com Mon Jun 11 07:44:05 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 11 07:44:14 2007 Subject: [GRASS-dev] [Fwd: Re: Missing message in r.in.ogr] In-Reply-To: <466C67E9.9030409@jemila.jazztel.es> References: <466C67E9.9030409@jemila.jazztel.es> Message-ID: <20070611174405.348821c6.hamish_nospam@yahoo.com> Markus: > it comes from the lib/gis/parser.c > grep Allow lib/gis/parser.c > > fprintf(stderr," --o %s\n", _("Allow output files to > overwrite existing files")); > fprintf(stdout, "
Allow output files to > overwrite existing files
\n"); > fprintf(fp, " desc {Allow output files to overwrite > existing files}\n"); fprintf(fp, " label {Allow > overwrite}\n"); > > I don't know how to indicate the gettext macro there > properly - could you ask on the list? > On Tue, May 15, 2007, Carlos D?vila wrote: > > I have translated all r.in.ogr messages, but there's still "Allow > > overwrite" at the bottom of dialogue. I cannot find this string in > > grassmods.po neither in any file in r.in.ogr folder. Where does it > > come from? Carlos: > Does anybody knows how to solve what's described below? Tcl bits already answered by Glynn and applied in 6.3-CVS two weeks ago. I've just now updated the Html bits in 6.3-CVS. Several of the fprintf(stdout, "\n"); lines in lib/gis/parser.c ended with commas, not semicolons. I assume these were a typo that got cut & pasted. I've changed them to be ';'. I see the same in the parser.c option defn example in the /*comments*/. ? Hamish From hamish_nospam at yahoo.com Mon Jun 11 08:02:45 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 11 08:02:51 2007 Subject: [GRASS-dev] Message standardization In-Reply-To: <466C6604.8010300@jemila.jazztel.es> References: <466C6604.8010300@jemila.jazztel.es> Message-ID: <20070611180245.4b2474b4.hamish_nospam@yahoo.com> Carlos D?vila wrote: > I'm new in dev list, but I've been working in translations for some > time. I would like to standardize some grass messages, according to > what is proposed in > http://grass.gdf-hannover.de/wiki/Development_Specs (please check > last changes) in order to ease the work for translators and get a > more consistent program. I don't know if standard messages proposed in > wiki can already be used or if discussion is still open. Any feedback > is welcome. If no objections are reported, I will start changing > messages in the next days, at least the most obvious. The ideas on the wiki page are just the opinions of a few of us who edited the page AFAICT, not a full consensus reached on the -dev mailing list which it needs to be before any mass change. So that it can be formalized and the discussion closed, I too would ask everyone to review what's listed there, and discuss here. There are several unresolved questions there which need to be answered. At least I hope with g.message and G_*message() we have all the tools we need now? My only gripe with G_message() is that it makes it impossible to use whitespace formatting as it drops \n and \t and leading spaces and compresses inline multiple spaces. But maybe that is good, as doing that will not work well with dynamic-width fonts, ie it makes GUI output ugly between lines, and tables should go to fprintf(stdout,..). It saves more work later to get this right the first time :) and kills motivation on all sides to have to revert changes later :( Hamish From hamish_nospam at yahoo.com Mon Jun 11 09:10:23 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 11 09:10:40 2007 Subject: [GRASS-dev] resolving more menu issues In-Reply-To: References: <20070610224628.5b2aa024.hamish_nospam@yahoo.com> Message-ID: <20070611191023.7c02f7a5.hamish_nospam@yahoo.com> Michael Barton wrote: > >> I?ve come across a couple more menu issues that I?d like to propose > >> solving in a general way that will work with multiple GUI?s > >> > >> 1. Currently, there are scripts that are only used (or only easily > >> used) by the GUI. These reside in $GISBASE/etc/gm/script. .. > >> I propose either moving these to a new directory > >> $GISBASE/scripts/gui and adding this as a path in init.sh OR simply > >> moving them to $GISBASE/scripts. Several are now obsolete (e.g., > >> d.text.sh and v.in.asciipoints) and could be removed. I?d change > >> the reference to them in the GUI (i.e., no longer necessary to > >> specify a full path). Hamish: > > Yes, it would be nice to move generic wrapper scripts which are just > > needed for a GUI/core interaction (ie nothing to do with tcl or wx) > > from gui/tcltk/gis.m/script/ to gui/script/ or somesuch place. Michael: > Here is my assessment FWIW. This applies to current GUI and new > wxPython one > (d.m could stay like it is) right. (s/could/should/) ... > d.path.sh - Of general use (more useful for GUI, but also for > scripting) It's a work around easily done by a script in a one-liner call to d.vect. Better done as a new flag in the module, e.g.: -d: draw input map as backdrop For scripts which exist to overcome module deficiencies, I think it is better to fix the module, not entrench the work-around as a formal script. Or another way, there shouldn't be multiple scripts to do the same task in a slightly different way- we are already up to ~392 modules- I have been using grass for a while now and still there are still modules I have never heard of (e.g. I never noticed r.bitpattern existed before a few days ago). Less noise is better. keeping them in $SOMEWHERE/gui/scripts/ makes them stick out badly (as you've noticed), which helps to motivate us to fix the real problem in the module, gui code, or the libgis glue between them, rather than perpetuate a work-around. Also, moving them to grass6/scripts/, then deleting them later, clutters the ViewCVS interface with empty directories (kept to store old attic history). > d.shadedmap - Of general use (simple way to do same thing with d.his) It performs a same technical task, but different conceptual task. IMO send it to grass6/scripts/ like the v.centoids, v.dissolve, v.what.vect scripts, as the module containing the functionality isn't obvious. > d.text.sh - Obsolete if so, drop it. > d.title.sh - Obsolete We need to add a flag to d.title to call system(d.text) to make it generally useful I think. Then we can drop this work-around script. (regardless if it is used by the GRASS 6.x GUIs or is dropped for 7.x) > print.sh _ ????? No idea; if not used by the GUI I'd say drop it or if you have some need for it then fully rewrite it. > r.colors.rules - Of general use (GUI for picking map; will be obsolete > with wxgrass) it's redundant now with the new "r.colors rules=filename" and -i. Can it be replaced by two menu items? > r.reclass.file- Of general use, but would be unnessary with a file= > option r.reclass.rules- Of general use (GUI for picking map; will be > obsolete with wxgrass) it doesn't add new functionality, it just redirects from stdin. Better handled by a new file= option as you say. > r.recode.file- Of general use, but would be unnessary with a file= > option ditto. > r.recode.rules- Of general use (GUI for picking map; will be obsolete > with wxgrass) ditto. > r.support.sh - Obsoletes (maybe not??) still needed AFAIK- > > Note r.support.sh works around a very weird bug where the module > > quits after only the first few [y/N] questions in the xterm. > > https://intevation.de/rt/webrt?serial_num=5094 > > Even the new and improved r.support? bug created 10 months ago, so yes AFAIK. (if you mean new by Brad) > v.in.asciipoints - Obsolete ok. (does it even work? I see an unmatched quoting error) > v.type.sh- Of general use (should effectively replace GUI for v.type) It's just there to work around GUI + parser issues, and just waits for GRASS 7 to be solved. No new functionality, keep it out of the main scripts/. > > d.shademap is the only one I see there which might move to scripts/. After looking at them more, I still stand by that. > One objective would be to allow any of these to be run by simply > typing their name, without the full path. To do this, they would need > to go into a directory already listed in the PATH in init.sh or to add > the new directory to the PATH in init.sh. if they only exist to make the GUI work inspite of misfeatures, then no, don't put them in the general path. banish them elsewhere. they are internal maintainance scripts not user scripts. aka if the misfeatures didn't exist, neither would they. > Do I need PSC OK to make this kind of change to the cvs structure > after we've worked it out? No. Technical decisions and implementation are explicitly the domain of the developers and consensus reached by the devels on this here grass-dev mailing list. RFC1 wrought: "In general, once write access has been granted, developers are allowed to make changes to the codebase as they see fit. For controversial or complicated changes consensus must be obtained on the developers' mailing list as far as reasonably practicable. It is recognised that the ultimate arbitration on technical issues should always lie with consensus on the developers' mailing list. Specifically, it is not the role of the PSC to impose technical solutions. Its role is in general limited to enforcing the quality control mechanisms outlined above." So the PSC's interest in the CVS server is primarily with making sure that all commiters understand + heed the GPL, submitting guidelines, etc. Is everyone happy with putting the relevant gui scripts in grass6/gui/scripts/ in the source code and then $GISBASE/etc/gui/scripts/ after "make"? Or have a better idea? another thing to note is that wrapper scripts won't load the parent module's help page. (eg v.type.sh, but there isn't much to say there) Hamish From hamish_nospam at yahoo.com Mon Jun 11 09:39:23 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 11 09:39:30 2007 Subject: [GRASS-dev] g.gisenv in gui In-Reply-To: <18025.23023.512507.820597@cerise.gclements.plus.com> References: <18025.23023.512507.820597@cerise.gclements.plus.com> Message-ID: <20070611193923.454eacf9.hamish_nospam@yahoo.com> Michael: > > Likewise, you can?t get it to print out current environment settings > > from the gui unless you do some tricks with its execution. Glynn: > AFAICT, the problem with g.gisenv is that it checks for argc==1 before > calling G_parser(), so e.g. "g.gisenv --quiet" causes that check to > fail. g.gisenv just outputs to stdout. There's no G_message() or G_percent() or anything that would use --quiet. Just treat g.gisenv like it were "ls" and send the output to a buffer or a temp file. for example: >>> import os >>> prog = os.popen("g.gisenv") >>> print prog.read() LOCATION_NAME='spearfish60'; MAPSET='user1'; DIGITIZER='none'; GISDBASE='/home/hamish/grassdata'; DEBUG='0'; MONITOR='x0'; GRASS_GUI='text'; # for shell vars (replace grep filter with python version) >>> import os >>> prog = os.popen("set | grep '^GIS\|^GRASS_'") >>> print prog.read() nothing more to do here AFAICS.... ? Hamish From grass-codei at wald.intevation.org Mon Jun 11 15:09:56 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Mon Jun 11 15:08:51 2007 Subject: [GRASS-dev] [grass-code I][422] v.transform pointsfile does not accept points in dd:mm:ss format Message-ID: <20070611130956.81250BD51E@pyrosoma.intevation.org> code I item #422, was opened at 2007-06-11 15:09 Status: Open Priority: 3 Submitted By: Harri Kiiskinen (harrikoo) Assigned to: Nobody (None) Summary: v.transform pointsfile does not accept points in dd:mm:ss format Issue type: module bug Issue status: None GRASS version: CVS HEAD GRASS component: vector Operating system: Linux Operating system version: Debian 4.0 GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: v.transform does not accept point coordinated given as dd:mm:ss.ss in the 'pointsfile' option. If the coordinates are changed into decimal, everything works ok. Harri K. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=422&group_id=21 From glynn at gclements.plus.com Mon Jun 11 15:12:35 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jun 11 15:12:43 2007 Subject: [GRASS-dev] Re: [GRASSGUI] why won't this execute in cmd.py? In-Reply-To: References: Message-ID: <18029.19011.360288.234010@cerise.gclements.plus.com> Michael Barton wrote: > Any idea why this won't execute in cmd.py? > > cmdlst = ['d.mon','start=%s' % xmon, '&'] > p = cmd.Command(cmdlst) Is the '&' supposed to be an argument? Shell syntax won't work if you aren't using a shell. If you want to run a command in the background, use Command(..., wait=False). -- Glynn Clements From glynn at gclements.plus.com Mon Jun 11 15:16:55 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jun 11 15:17:02 2007 Subject: [GRASS-dev] Re: [GRASSGUI] silly question - running a python script In-Reply-To: References: <18028.24766.865947.337023@cerise.gclements.plus.com> Message-ID: <18029.19271.627814.114767@cerise.gclements.plus.com> Michael Barton wrote: > >> I forgot, to send the script. Here it is. Doesn't work and I haven't updated > >> main to use a list. But maybe a starting place for figuring out how to do > >> scripting with python and GRASS. > > > > If I comment out the "import wx" and "import rules", then both: > > > > python rules_colors.py --interface-description > > and: > > chmod +x rules_colors.py > > ./rules_colors.py --interface-description > > > > work fine. Ditto for --help etc. > > I needed import wx and import rules to launch an interactive window in > wxPython. I wonder why they cause problems. I didn't say that they caused problems; I was treating the script as a normal GRASS script (rather than a wxgrass script), and removing the imports was simpler than setting up the operating environment to allow those modules to be imported. > > That indicates that the use of g.parser is okay. > > > > BTW, what's the point of using: > > > > #!/usr/bin/env python > > > > rather than: > > > > #!/usr/bin/python > > It's that way in the modules in the svn. In the past, I've had trouble with > the Python shbang on my Mac and so can't really tell which is better. My > Python is in /usr/bin however. Calling Python directly is definitely better. If #!/usr/bin/python doesn't work, you need to fix your system; other Python scripts aren't going to use that workaround. -- Glynn Clements From glynn at gclements.plus.com Mon Jun 11 15:30:13 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jun 11 15:30:17 2007 Subject: [GRASS-dev] [grass-code I][420] v.transform pointsfile does not accept points in dd:mm:ss format In-Reply-To: <200706101559.25062.dylan.beaudette@gmail.com> References: <20070607131213.8786DB53A9@pyrosoma.intevation.org> <20070610201540.72df3023.hamish_nospam@yahoo.com> <200706101559.25062.dylan.beaudette@gmail.com> Message-ID: <18029.20069.637208.166176@cerise.gclements.plus.com> Dylan Beaudette wrote: > Out of curiosity, do the methods in v.transform accurately work with spherical > coordinates? No. v.transform performs an affine transformation, which doesn't really make much sense for spherical coordinates. -- Glynn Clements From glynn at gclements.plus.com Mon Jun 11 15:45:56 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jun 11 15:46:00 2007 Subject: [GRASS-dev] Re: [GRASSGUI] silly question - running a python script In-Reply-To: <20070611153008.79482c07.hamish_nospam@yahoo.com> References: <18028.817.799357.576820@cerise.gclements.plus.com> <20070611153008.79482c07.hamish_nospam@yahoo.com> Message-ID: <18029.21012.428455.442846@cerise.gclements.plus.com> Hamish wrote: > > > Oh no: > > > > > > for arg in sys.argv: > > > args += arg+" " > > > I have updated the g.parser help page Python example with the fixed args > usage, but I notice the Perl example there (6.3cvs version only) is > broken as well. > > http://freegis.org/cgi-bin/viewcvs.cgi/grass6/general/g.parser/description.html > > if( $ARGV[0] ne '@ARGS_PARSED@' ){ > my $arg = ""; > for (my $i=0; $i < @ARGV;$i++) { > $arg .= " $ARGV[$i] "; > } > system("$ENV{GISBASE}/bin/g.parser $0 $arg"); > exit; > } Perl's system() supports both scalar and array context, so the array version should be used. Also, Perl has exec(), which is preferable to system()+exit(). > Also I notice a difference in the python version where main(): now ends > with "return". Does this matter? A "return" at the end of a method should be a no-op. -- Glynn Clements From glynn at gclements.plus.com Mon Jun 11 15:49:54 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jun 11 15:49:57 2007 Subject: [GRASS-dev] resolving more menu issues In-Reply-To: <20070611191023.7c02f7a5.hamish_nospam@yahoo.com> References: <20070610224628.5b2aa024.hamish_nospam@yahoo.com> <20070611191023.7c02f7a5.hamish_nospam@yahoo.com> Message-ID: <18029.21250.442208.45638@cerise.gclements.plus.com> Hamish wrote: > Is everyone happy with putting the relevant gui scripts in > grass6/gui/scripts/ in the source code and then $GISBASE/etc/gui/scripts/ > after "make"? Or have a better idea? If there's even a remote possibility that the script would be useful from the command line, it should be installed in $GISBASE/scripts (which is in $PATH). -- Glynn Clements From glynn at gclements.plus.com Mon Jun 11 15:54:31 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jun 11 15:54:33 2007 Subject: [GRASS-dev] g.gisenv in gui In-Reply-To: <20070611193923.454eacf9.hamish_nospam@yahoo.com> References: <18025.23023.512507.820597@cerise.gclements.plus.com> <20070611193923.454eacf9.hamish_nospam@yahoo.com> Message-ID: <18029.21527.177766.306492@cerise.gclements.plus.com> Hamish wrote: > Michael: > > > Likewise, you can?t get it to print out current environment settings > > > from the gui unless you do some tricks with its execution. > > Glynn: > > AFAICT, the problem with g.gisenv is that it checks for argc==1 before > > calling G_parser(), so e.g. "g.gisenv --quiet" causes that check to > > fail. > > g.gisenv just outputs to stdout. There's no G_message() or G_percent() > or anything that would use --quiet. Just treat g.gisenv like it were > "ls" and send the output to a buffer or a temp file. The point is that *any* options (even ones which have no effect, e.g. --quiet or --verbose) caused the argc==1 check to fail. I've now changed it so that if you specify neither get= nor set=, it will print the current settings. Apart from not being confused by --quiet etc, you should now be able to use "g.gisenv store=mapset" to list the VAR file. -- Glynn Clements From cdavilam at jemila.jazztel.es Mon Jun 11 16:02:19 2007 From: cdavilam at jemila.jazztel.es (=?ISO-8859-1?Q?Carlos_D=E1vila?=) Date: Mon Jun 11 16:01:13 2007 Subject: [GRASS-dev] [Fwd: Re: Missing message in r.in.ogr] In-Reply-To: <20070611174405.348821c6.hamish_nospam@yahoo.com> References: <466C67E9.9030409@jemila.jazztel.es> <20070611174405.348821c6.hamish_nospam@yahoo.com> Message-ID: <466D55EB.1020907@jemila.jazztel.es> Hamish escribi?: > Markus: > >> it comes from the lib/gis/parser.c >> grep Allow lib/gis/parser.c >> >> fprintf(stderr," --o %s\n", _("Allow output files to >> overwrite existing files")); >> fprintf(stdout, "
Allow output files to >> overwrite existing files
\n"); >> fprintf(fp, " desc {Allow output files to overwrite >> existing files}\n"); fprintf(fp, " label {Allow >> overwrite}\n"); >> >> I don't know how to indicate the gettext macro there >> properly - could you ask on the list? >> > > >> On Tue, May 15, 2007, Carlos D?vila wrote: >> >>> I have translated all r.in.ogr messages, but there's still "Allow >>> overwrite" at the bottom of dialogue. I cannot find this string in >>> grassmods.po neither in any file in r.in.ogr folder. Where does it >>> come from? >>> > > Carlos: > >> Does anybody knows how to solve what's described below? >> > > > Tcl bits already answered by Glynn and applied in 6.3-CVS two weeks ago. Sorry for my duplicated message. As I wasn't subscribed to dev list when I posted first time, I received and automatic advise saying my message was awaiting for moderator approval and I didn't receive any confirmation later, so I didn't know it was already answered and solved. Carlos From dylan.beaudette at gmail.com Mon Jun 11 16:42:23 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Mon Jun 11 16:42:36 2007 Subject: [GRASS-dev] [grass-code I][420] v.transform pointsfile does not accept points in dd:mm:ss format In-Reply-To: <18029.20069.637208.166176@cerise.gclements.plus.com> References: <20070607131213.8786DB53A9@pyrosoma.intevation.org> <20070610201540.72df3023.hamish_nospam@yahoo.com> <200706101559.25062.dylan.beaudette@gmail.com> <18029.20069.637208.166176@cerise.gclements.plus.com> Message-ID: <3c5546140706110742x3e156835y77b110e39dfe136@mail.gmail.com> On 6/11/07, Glynn Clements wrote: > > Dylan Beaudette wrote: > > > Out of curiosity, do the methods in v.transform accurately work with spherical > > coordinates? > > No. v.transform performs an affine transformation, which doesn't > really make much sense for spherical coordinates. > > -- > Glynn Clements > Ok- thanks for the affirmation- I was thinking the same thing. Would it then be a good idea to include a warning as such? dylan From michael.barton at asu.edu Mon Jun 11 17:30:07 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Jun 11 17:30:32 2007 Subject: [GRASS-dev] Message standardization In-Reply-To: <20070611180245.4b2474b4.hamish_nospam@yahoo.com> Message-ID: What a mess. But not at all surprising after over 20 years of volunteer programming by umteem people. I fully support the standardization of error messages. The suggestions all look good to me. There is considerable back and forth (thoughtful) about periods. For easy consistency, I'd simply go with: sentence ends with period; phrase does not end with period. (and as HB says sentence != phrase). Save ellipses for pending operations (Reading...). Looking this over didn't take much time and I recommend everyone follow Hamish's suggestion so we can move ahead with this. We'll need to do the same thing with the GUI, especially as we add more error traps and error message boxes. But let's do the main C modules first and then use these specs as guidance. Michael On 6/10/07 11:02 PM, "Hamish" wrote: > Carlos D?vila wrote: >> I'm new in dev list, but I've been working in translations for some >> time. I would like to standardize some grass messages, according to >> what is proposed in >> http://grass.gdf-hannover.de/wiki/Development_Specs (please check >> last changes) in order to ease the work for translators and get a >> more consistent program. I don't know if standard messages proposed in >> wiki can already be used or if discussion is still open. Any feedback >> is welcome. If no objections are reported, I will start changing >> messages in the next days, at least the most obvious. > > > The ideas on the wiki page are just the opinions of a few of us who > edited the page AFAICT, not a full consensus reached on the -dev mailing > list which it needs to be before any mass change. So that it can be > formalized and the discussion closed, I too would ask everyone to review > what's listed there, and discuss here. There are several unresolved > questions there which need to be answered. > > At least I hope with g.message and G_*message() we have all the tools we > need now? My only gripe with G_message() is that it makes it impossible > to use whitespace formatting as it drops \n and \t and leading spaces > and compresses inline multiple spaces. But maybe that is good, as doing > that will not work well with dynamic-width fonts, ie it makes GUI output > ugly between lines, and tables should go to fprintf(stdout,..). > > > It saves more work later to get this right the first time :) and kills > motivation on all sides to have to revert changes later :( > > > Hamish > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From tutey at o2.pl Mon Jun 11 18:58:56 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Jun 11 18:58:59 2007 Subject: [GRASS-dev] [grass-code I][422] v.transform pointsfile does not accept points in dd:mm:ss format In-Reply-To: <20070611130956.81250BD51E@pyrosoma.intevation.org> References: <20070611130956.81250BD51E@pyrosoma.intevation.org> Message-ID: <466D7F50.1070509@o2.pl> grass-codei@wald.intevation.org wrote: > code I item #422, was opened at 2007-06-11 15:09 This is a duplicate of Harri's ticket sumbitted on 07.06.2007. Deleted from tracker. Maciek From harkiisk at utu.fi Mon Jun 11 22:46:48 2007 From: harkiisk at utu.fi (Harri Kiiskinen) Date: Mon Jun 11 22:46:56 2007 Subject: [GRASS-dev] v.transform, wishlist #420 Message-ID: <1181594809.8471.37.camel@localhost.localdomain> Hello all, on advise from Maciek, I'll re-post here the comments I added to the wishlist item mentioned in the Subject. The item is about v.transform and how it does not accept lat/long in ascii format in the 'pointslist' file. Hamish responded, that it probably would be easy to fix by just modifying the module to use G_scan_easting() and G_scan_northing(). However, and here I quote myself: I looked into the matter somewhat deeper, and it turns out not to be as simple as just putting in G_scan_*()-functions. These functions delegate the work to ll_scan(), through G_lat_scan() and G_long_scan(), and ll_scan() normalizes its resulting arguments to the ranges [-180,180] and [-90,90]. The result is, that the coordinates can be given to these functions only if it is supposed to be lat/long-coordinate. As I have some interest for this module, this might be a chance for a first code contribution to the project. I have two possible options for the solution: 1. Check the coordinate string first to see if the character ':' can be found in it, and if it can be, assume the coordinate is lat/long and do the necessary conversion 2. Add two more flags to the module, to indicate that the from- and/or to-coordinates should be considered as lat/long. The first solution is more elegant, but the second one makes sure, that the user knows the form of the coordinates. Two questions: Which of these would be the preferred solution? Is is ok if I meddle with this module and send in diffs/patches at some point? In the long run, I'd like to further modify this module so, that the resulting vector could be placed in a different location/mapset, so it could be used to transform vector files from a location based on a local coordinate system to another, 'global' system. Harri K. From hamish_nospam at yahoo.com Tue Jun 12 06:37:34 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Jun 12 06:37:49 2007 Subject: [GRASS-dev] v.transform, wishlist #420 In-Reply-To: <1181594809.8471.37.camel@localhost.localdomain> References: <1181594809.8471.37.camel@localhost.localdomain> Message-ID: <20070612163734.1b7aa78b.hamish_nospam@yahoo.com> Harri Kiiskinen wrote: > I looked into the matter somewhat deeper, and it turns out not > to be as simple as just putting in G_scan_*()-functions. These > functions delegate the work to ll_scan(), through G_lat_scan() > and G_long_scan(), and ll_scan() normalizes its resulting arguments > to the ranges [-180,180] and [-90,90]. The result is, that the > coordinates can be given to these functions only if it is supposed > to be lat/long-coordinate. lib/gis/wind_scan.c int G_scan_northing ( const char *buf, double *northing, int projection) { if (projection == PROJECTION_LL) { if(G_lat_scan (buf, northing)) return 1; if (!scan_double (buf, northing)) return 0; return (*northing <= 90.0 && *northing >= -90.0); } return scan_double (buf, northing); } it only calls G_lat_scan() if the location's projection is lat/lon. No need for any extra checks. > In the long run, I'd like to further modify this module so, that the > resulting vector could be placed in a different location/mapset, so it > could be used to transform vector files from a location based on a > local coordinate system to another, 'global' system. could the derived transform parms be used as the +towgs84 7-term projection in the new location, then v.proj? Hamish From michael.barton at asu.edu Tue Jun 12 09:52:42 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jun 12 09:52:59 2007 Subject: [GRASS-dev] d.rast.edit in wxgrass Message-ID: d.rast.edit ought to run from wxgrass, assuming that TclTk is installed. It launches the wxPython properties dialog when called from the menu. However, the wxPython properties dialog, then launches the TclTk properties dialog instead of just running the command (note that running d.rast.edits with arguments runs fine from the wxgrass built in CLI). The place where the command is getting rerouted to call the TclTk dialog seems to be in line 636 of menuform.py retcode = subprocess.call(cmd, shell=True) Any idea why this might be? I could hack around this for the one command, but there should be a more generic solution it seems. BTW, I got the xterm launching method to work by using subprocess.Popen(cmdlist) for starting the needed xmon ['d.mon', 'start=xmon']. Both cmd.Command(cmdlist) and cmd.Command(cmdlist, wait=False) didn't work and hung up waiting on the xmon. Don't know why. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070612/9cdf5b2a/attachment.html From benjamin.ducke at ufg.uni-kiel.de Tue Jun 12 12:35:58 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Tue Jun 12 12:36:00 2007 Subject: [GRASS-dev] GRASS and GDAL 1.4.1 MingW Message-ID: <466E770E.8070103@ufg.uni-kiel.de> Hi all, concerning the troubles with the DBF driver under Win32 that I wrote about earlier, I am trying to compile a current version of GRASS with MingW. My problem is, that I cannot break the vicious GDAL-GRASS-GDAL cycle anymore. I was trying to follow the instructions in the gdal-grass plugin README: 1. GDAL 1.4.1 compiles fine without GRASS support. 2. However, the README is not clear on whether GRASS first needs to be compiled w/o GDAL support firdst, but I assume it has to, because it won't be able to find GDALOpen and the configure script aborts: checking whether to use GDAL... yes checking for gdal-config... /usr/local/bin/gdal-config checking for GDALOpen... no checking for GDALOpen... no configure: error: *** couldn't find GDAL 3. Fair enough, BUT: with the current CVS version, it seems impossible to compile GRASS without GDAL support, as compilation in lib/vector/Vlib aborts, even if I specify --without-gdal: field.c: In function `Vect_read_dblinks': field.c:388: error: `OGRDataSourceH' undeclared (first use in this function) field.c:388: error: (Each undeclared identifier is reported only once field.c:388: error: for each function it appears in.) field.c:388: error: syntax error before "Ogr_ds" field.c:389: error: `OGRLayerH' undeclared (first use in this function) field.c:390: error: `OGRFeatureDefnH' undeclared (first use in this function) field.c:400: error: `Ogr_ds' undeclared (first use in this function) field.c:412: error: `Ogr_layer' undeclared (first use in this function) field.c:417: error: `Ogr_featuredefn' undeclared (first use in this function) A 'make distclean' with fresh configure run did not help. I don't know how many hours of time I have already lost with this tricky GDAL-GRASS interdependency thing in the past without ever figuring it out 100% Are you all sure that including GDAL in the GRASS distribution in the future is not an option? 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 harkiisk at utu.fi Tue Jun 12 15:13:17 2007 From: harkiisk at utu.fi (Harri Kiiskinen) Date: Tue Jun 12 15:13:57 2007 Subject: [GRASS-dev] v.transform, wishlist #420 In-Reply-To: <20070612163734.1b7aa78b.hamish_nospam@yahoo.com> References: <1181594809.8471.37.camel@localhost.localdomain> <20070612163734.1b7aa78b.hamish_nospam@yahoo.com> Message-ID: <1181653997.661.35.camel@localhost.localdomain> On Tue, 2007-06-12 at 16:37 +1200, Hamish wrote: > Harri Kiiskinen wrote: > > I looked into the matter somewhat deeper, and it turns out not > > to be as simple as just putting in G_scan_*()-functions. These > > functions delegate the work to ll_scan(), through G_lat_scan() > > and G_long_scan(), and ll_scan() normalizes its resulting arguments > > to the ranges [-180,180] and [-90,90]. The result is, that the > > coordinates can be given to these functions only if it is supposed > > to be lat/long-coordinate. > > > lib/gis/wind_scan.c > > int G_scan_northing ( const char *buf, double *northing, int projection) > { > if (projection == PROJECTION_LL) > { > if(G_lat_scan (buf, northing)) > return 1; > if (!scan_double (buf, northing)) > return 0; > return (*northing <= 90.0 && *northing >= -90.0); > } > > return scan_double (buf, northing); > } > > > it only calls G_lat_scan() if the location's projection is lat/lon. > No need for any extra checks. That's what I thought when I looked at that code, but the thing is not so simple, as when using v.transform, there is not way to know, whether the 'to' or 'from' are coordinates are lat/long or not, because v.transform is used to transform between different coordinate systems, and the current location does not necessarily reflect either of these. An example: I have a location with a local coordinate system ( x = [6000,9000], y = [2000,5000] ) for use with an archaeological excavation. To 'fix' this system to a global system, some points are measured also in lat/long coordinates. So I have a group of points having coordinates in the local, metric system and in the global, lat/long system. Just what v.transform needs to perform the transformation. However, if I do the transformation in the original location, where the vector map is, the lat/long coordinates never go to G_lat_scan, as the 'projection' is not PROJECTION_LL. On the other hand, if I export the map and import it to the result location and do the transform there, the metric coordinates will be given to G_lat_scan(), as the 'projection' is PROJECTION_LL, even though for these points it is not true, and the resulting coordinates will suffer the normalization to the ranges mentioned above. I did test this already. So I still think, that there needs to be an additional test, either defined by the user or based on the probability, that ':' in the coordinate string means a lat/long that needs to be converted to decimal. > > In the long run, I'd like to further modify this module so, that the > > resulting vector could be placed in a different location/mapset, so it > > could be used to transform vector files from a location based on a > > local coordinate system to another, 'global' system. > > could the derived transform parms be used as the +towgs84 7-term > projection in the new location, then v.proj? After a quick look at lib/vector/transform, I'd say that not self-evidently. Someone with good enough knowledge of linear algebra might be able to figure out, what the different transformation and rotation coefficients actually mean, and if they could be used in +towgs84. As the TODO file in that directory says, the "means of generating the coefficients seems rather odd". Then again, v.transform is not really about re-projecting the data, only about changing the coordinates into a different system (I think there is a difference?) - usable just for the things its description says, putting dxf drawings in place, or, in my case, changing vectors from a very local, small scale coordinate system to something else - maybe another local system - just by defining some common points. I think it is nice just because it is simple, but I wouldn't use it for geographically large areas. Harri K. From dylan.beaudette at gmail.com Tue Jun 12 15:32:00 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Tue Jun 12 15:32:04 2007 Subject: [GRASS-dev] v.transform, wishlist #420 In-Reply-To: <1181653997.661.35.camel@localhost.localdomain> References: <1181594809.8471.37.camel@localhost.localdomain> <20070612163734.1b7aa78b.hamish_nospam@yahoo.com> <1181653997.661.35.camel@localhost.localdomain> Message-ID: <3c5546140706120632j57cc0612k7cb1e4d43620be01@mail.gmail.com> Hi Harri, It sounds like you are interested in a projection-based transformation, rather than the affine transformation which v.transform can apply. Here are the steps that I would take: 1. collect control points, using a projected coordinate system custom coordinates ( x,y ) UTM for example ( x', y' ) 2. apply affine transform in UTM coordinates 3. inverse project to geographic coordinates, if that is what you really want. You will need: 1. a new location in UTM 2. import your custom coordinates into that location, ignoring the fact that the coordinate systems do not match 3. use v.transform I think that v.transform should issue some kind of error if invoked within a LL location... cheers, Dylan On 6/12/07, Harri Kiiskinen wrote: > On Tue, 2007-06-12 at 16:37 +1200, Hamish wrote: > > Harri Kiiskinen wrote: > > > I looked into the matter somewhat deeper, and it turns out not > > > to be as simple as just putting in G_scan_*()-functions. These > > > functions delegate the work to ll_scan(), through G_lat_scan() > > > and G_long_scan(), and ll_scan() normalizes its resulting arguments > > > to the ranges [-180,180] and [-90,90]. The result is, that the > > > coordinates can be given to these functions only if it is supposed > > > to be lat/long-coordinate. > > > > > > lib/gis/wind_scan.c > > > > int G_scan_northing ( const char *buf, double *northing, int projection) > > { > > if (projection == PROJECTION_LL) > > { > > if(G_lat_scan (buf, northing)) > > return 1; > > if (!scan_double (buf, northing)) > > return 0; > > return (*northing <= 90.0 && *northing >= -90.0); > > } > > > > return scan_double (buf, northing); > > } > > > > > > it only calls G_lat_scan() if the location's projection is lat/lon. > > No need for any extra checks. > > That's what I thought when I looked at that code, but the thing is not > so simple, as when using v.transform, there is not way to know, whether > the 'to' or 'from' are coordinates are lat/long or not, because > v.transform is used to transform between different coordinate systems, > and the current location does not necessarily reflect either of these. > An example: > > I have a location with a local coordinate system ( x = [6000,9000], y = > [2000,5000] ) for use with an archaeological excavation. To 'fix' this > system to a global system, some points are measured also in lat/long > coordinates. So I have a group of points having coordinates in the > local, metric system and in the global, lat/long system. Just what > v.transform needs to perform the transformation. > However, if I do the transformation in the original location, where the > vector map is, the lat/long coordinates never go to G_lat_scan, as the > 'projection' is not PROJECTION_LL. On the other hand, if I export the > map and import it to the result location and do the transform there, the > metric coordinates will be given to G_lat_scan(), as the 'projection' is > PROJECTION_LL, even though for these points it is not true, and the > resulting coordinates will suffer the normalization to the ranges > mentioned above. I did test this already. > So I still think, that there needs to be an additional test, either > defined by the user or based on the probability, that ':' in the > coordinate string means a lat/long that needs to be converted to > decimal. > > > > In the long run, I'd like to further modify this module so, that the > > > resulting vector could be placed in a different location/mapset, so it > > > could be used to transform vector files from a location based on a > > > local coordinate system to another, 'global' system. > > > > could the derived transform parms be used as the +towgs84 7-term > > projection in the new location, then v.proj? > > After a quick look at lib/vector/transform, I'd say that not > self-evidently. Someone with good enough knowledge of linear algebra > might be able to figure out, what the different transformation and > rotation coefficients actually mean, and if they could be used in > +towgs84. As the TODO file in that directory says, the "means of > generating the coefficients seems rather odd". > Then again, v.transform is not really about re-projecting the data, > only about changing the coordinates into a different system (I think > there is a difference?) - usable just for the things its description > says, putting dxf drawings in place, or, in my case, changing vectors > from a very local, small scale coordinate system to something else - > maybe another local system - just by defining some common points. I > think it is nice just because it is simple, but I wouldn't use it for > geographically large areas. > > Harri K. > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From grass-codei at wald.intevation.org Tue Jun 12 17:23:39 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Tue Jun 12 17:22:25 2007 Subject: [GRASS-dev] [grass-code I][423] Duplicated punctuation at end of messages Message-ID: <20070612152339.1CDA640F89@pyrosoma.intevation.org> code I item #423, was opened at 2007-06-12 17:23 Status: Open Priority: 3 Submitted By: Carlos D?vila (carluti) Assigned to: Nobody (None) Summary: Duplicated punctuation at end of messages Issue type: module bad feature Issue status: None GRASS version: CVS HEAD GRASS component: database Operating system: Linux Operating system version: debian testing GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: In addition to the punctuation included in the messages of db.connect (. or :), program adds colon at the end, resulting .: or :: Not checked if it also happens in other modules. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=423&group_id=21 From glynn at gclements.plus.com Tue Jun 12 17:58:48 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jun 12 17:58:54 2007 Subject: [GRASS-dev] d.rast.edit in wxgrass In-Reply-To: References: Message-ID: <18030.49848.727746.145035@cerise.gclements.plus.com> Michael Barton wrote: > d.rast.edit ought to run from wxgrass, assuming that TclTk is installed. It > launches the wxPython properties dialog when called from the menu. However, > the wxPython properties dialog, then launches the TclTk properties dialog > instead of just running the command (note that running d.rast.edits with > arguments runs fine from the wxgrass built in CLI). > > The place where the command is getting rerouted to call the TclTk dialog > seems to be in line 636 of menuform.py It's being treated as a layer because it begins with "d.". The "d.*" hack is a bad idea; I suggest that you remove it. > retcode = subprocess.call(cmd, shell=True) Why are you using a string instead of a list? > Any idea why this might be? I could hack around this for the one command, > but there should be a more generic solution it seems. > > BTW, I got the xterm launching method to work by using > subprocess.Popen(cmdlist) for starting the needed xmon ['d.mon', > 'start=xmon']. Both cmd.Command(cmdlist) and cmd.Command(cmdlist, > wait=False) didn't work and hung up waiting on the xmon. Don't know why. Personally, I suggest not bothering with interactive d.* commands. wxgrass isn't going to be stable until 7.x (apart from anything else, wxPython 2.8 isn't going to be in widespread use before then), so I don't see much point in making an effort to support features which will have been removed by then. -- Glynn Clements From grass-codei at wald.intevation.org Tue Jun 12 18:05:03 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Tue Jun 12 18:03:52 2007 Subject: [GRASS-dev] [grass-code I][424] g.mapset dialog blinks and hangs grass Message-ID: <20070612160503.38C7A40F89@pyrosoma.intevation.org> code I item #424, was opened at 2007-06-12 18:05 Status: Open Priority: 3 Submitted By: Carlos D?vila (carluti) Assigned to: Nobody (None) Summary: g.mapset dialog blinks and hangs grass Issue type: module bug Issue status: None GRASS version: CVS HEAD GRASS component: general Operating system: Linux Operating system version: debian testing GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: When I open g.mapset, default width is not enough to display Spanish messages in one line. It makes dialog blink continuously with messages moving up and down. If dialog is widen to fit messages length it stops blinking and works fine, but if I leave it at the default width it finally hangs grass and the whole system. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=424&group_id=21 From michael.barton at asu.edu Tue Jun 12 18:11:11 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jun 12 18:11:21 2007 Subject: [GRASS-dev] d.rast.edit in wxgrass In-Reply-To: <18030.49848.727746.145035@cerise.gclements.plus.com> Message-ID: Glynn, On 6/12/07 8:58 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> d.rast.edit ought to run from wxgrass, assuming that TclTk is installed. It >> launches the wxPython properties dialog when called from the menu. However, >> the wxPython properties dialog, then launches the TclTk properties dialog >> instead of just running the command (note that running d.rast.edits with >> arguments runs fine from the wxgrass built in CLI). >> >> The place where the command is getting rerouted to call the TclTk dialog >> seems to be in line 636 of menuform.py > > It's being treated as a layer because it begins with "d.". > > The "d.*" hack is a bad idea; I suggest that you remove it. I'm not sure why the d.* clause is in this particular place--one reason to query Daniel who has done most of the work making menuform work well. We need to split out d.* commands elsewhere because they must be processed differently from other commands in order to show up in the display canvas, but this would not apply to d.rast.edit. It is the only command that I know of that would handle it's own display still. > >> retcode = subprocess.call(cmd, shell=True) > > Why are you using a string instead of a list? I looked at cmd coming in and I think it is a list. > >> Any idea why this might be? I could hack around this for the one command, >> but there should be a more generic solution it seems. >> >> BTW, I got the xterm launching method to work by using >> subprocess.Popen(cmdlist) for starting the needed xmon ['d.mon', >> 'start=xmon']. Both cmd.Command(cmdlist) and cmd.Command(cmdlist, >> wait=False) didn't work and hung up waiting on the xmon. Don't know why. > > Personally, I suggest not bothering with interactive d.* commands. > wxgrass isn't going to be stable until 7.x (apart from anything else, > wxPython 2.8 isn't going to be in widespread use before then), so I > don't see much point in making an effort to support features which > will have been removed by then. Well, my idea was to simply make it possible to call the few remaining commands like nviz d.rast.edit, that still need TlcTk canvases, and ones that still need an xterm, rather than really supporting them (i.e., no further development on their interfaces the way they are now). That way their functionality remains available while we work to replace them with wxPython. Kind of smoothing the transition somewhat. It should be possible to port d.rast.edit (or its functionality) to wxPython, since it is TclTk, at which time we'd just change the call in the menu to aim at the new one. Nviz launches fine, as do the xterm commands. d.rast.edit is the only one that doesn't launch quite right. It's not a biggie, but if it is an easy fix, it would be nice. Michael __________________________________________ Michael Barton, Professor of Anthropology and Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From glynn at gclements.plus.com Tue Jun 12 18:25:58 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jun 12 18:26:05 2007 Subject: [GRASS-dev] d.rast.edit in wxgrass In-Reply-To: References: <18030.49848.727746.145035@cerise.gclements.plus.com> Message-ID: <18030.51478.568398.685831@cerise.gclements.plus.com> Michael Barton wrote: > >> d.rast.edit ought to run from wxgrass, assuming that TclTk is installed. It > >> launches the wxPython properties dialog when called from the menu. However, > >> the wxPython properties dialog, then launches the TclTk properties dialog > >> instead of just running the command (note that running d.rast.edits with > >> arguments runs fine from the wxgrass built in CLI). > >> > >> The place where the command is getting rerouted to call the TclTk dialog > >> seems to be in line 636 of menuform.py > > > > It's being treated as a layer because it begins with "d.". > > > > The "d.*" hack is a bad idea; I suggest that you remove it. > > I'm not sure why the d.* clause is in this particular place--one reason to > query Daniel who has done most of the work making menuform work well. > > We need to split out d.* commands elsewhere because they must be processed > differently from other commands in order to show up in the display canvas, > but this would not apply to d.rast.edit. It is the only command that I know > of that would handle it's own display still. d.* commands used as map layers belong in a separate menu. The menu items for layer commands should have different bindings to normal commands. Determining how to run a command based upon its name is simply wrong. > >> retcode = subprocess.call(cmd, shell=True) > > > > Why are you using a string instead of a list? > > I looked at cmd coming in and I think it is a list. In which case, the shell=True doesn't belong there. > It should be possible to port d.rast.edit (or its functionality) to > wxPython, since it is TclTk, at which time we'd just change the call in the > menu to aim at the new one. Nviz launches fine, as do the xterm commands. > d.rast.edit is the only one that doesn't launch quite right. It's not a > biggie, but if it is an easy fix, it would be nice. The fix for d.rast.edit is to remove the hack which treats d.* commands differently. -- Glynn Clements From Juan.Giraldo at upct.es Tue Jun 12 18:47:17 2007 From: Juan.Giraldo at upct.es (Juan Diego Giraldo Osorio) Date: Tue Jun 12 18:45:37 2007 Subject: [GRASS-dev] Interpolation in grass for MSG images. Message-ID: <9519512868jdgiraldo@upct.es> Hi to all I'm working in a command to make the geometrical correction of MSG images. At this time, I have the points and its values (xy-coordinates and radiance values) to execute an interpolation procedure. However, I do not know how it do. At the moment, the best solution looks like to be to include the v.surf.idw command (obviusly, I have a lot of question too). Somebody have another solution??? Thanks for the attention. Juan Diego Giraldo Osorio UPCT Espa?a From michael.barton at asu.edu Tue Jun 12 19:26:49 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jun 12 19:26:59 2007 Subject: [GRASS-dev] d.rast.edit in wxgrass In-Reply-To: <18030.51478.568398.685831@cerise.gclements.plus.com> Message-ID: On 6/12/07 9:25 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >>>> d.rast.edit ought to run from wxgrass, assuming that TclTk is installed. It >>>> launches the wxPython properties dialog when called from the menu. However, >>>> the wxPython properties dialog, then launches the TclTk properties dialog >>>> instead of just running the command (note that running d.rast.edits with >>>> arguments runs fine from the wxgrass built in CLI). >>>> >>>> The place where the command is getting rerouted to call the TclTk dialog >>>> seems to be in line 636 of menuform.py >>> >>> It's being treated as a layer because it begins with "d.". >>> >>> The "d.*" hack is a bad idea; I suggest that you remove it. >> >> I'm not sure why the d.* clause is in this particular place--one reason to >> query Daniel who has done most of the work making menuform work well. >> >> We need to split out d.* commands elsewhere because they must be processed >> differently from other commands in order to show up in the display canvas, >> but this would not apply to d.rast.edit. It is the only command that I know >> of that would handle it's own display still. > > d.* commands used as map layers belong in a separate menu. The menu > items for layer commands should have different bindings to normal > commands. > > Determining how to run a command based upon its name is simply wrong. This is needed, at least in some spots to permit running d.* commands from the CLI. That's why it needs to look at the name. If it was only from the menu, then it would be easy. I don't know if this is the case in menuform. I don't know exactly what is going on in this spot and haven't had time yet to figure it out. > >>>> retcode = subprocess.call(cmd, shell=True) >>> >>> Why are you using a string instead of a list? >> >> I looked at cmd coming in and I think it is a list. > > In which case, the shell=True doesn't belong there. This may be the immediate problem. I'll test. Michael > >> It should be possible to port d.rast.edit (or its functionality) to >> wxPython, since it is TclTk, at which time we'd just change the call in the >> menu to aim at the new one. Nviz launches fine, as do the xterm commands. >> d.rast.edit is the only one that doesn't launch quite right. It's not a >> biggie, but if it is an easy fix, it would be nice. > > The fix for d.rast.edit is to remove the hack which treats d.* > commands differently. __________________________________________ Michael Barton, Professor of Anthropology and 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 hamish_nospam at yahoo.com Wed Jun 13 01:59:34 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jun 13 02:02:04 2007 Subject: [GRASS-dev] GRASS and GDAL 1.4.1 MingW In-Reply-To: <466E770E.8070103@ufg.uni-kiel.de> References: <466E770E.8070103@ufg.uni-kiel.de> Message-ID: <20070613115934.31c56135.hamish_nospam@yahoo.com> Benjamin Ducke wrote: > > 2. However, the README is not clear on whether GRASS first needs to be > compiled w/o GDAL support firdst, but I assume it has to, because it > won't be able to find GDALOpen and the configure script aborts: .. > 3. Fair enough, BUT: with the current CVS version, it seems impossible > to compile GRASS without GDAL support, as compilation in > lib/vector/Vlib aborts, even if I specify --without-gdal: GDAL is now a formal dependency. compiling without it is a bad idea. the order should be: 1. compile & install GDAL without grass support 2. compile & install GRASS linking to the new GDAL 3. compile & install GDAL's GRASS plugin linking to the new GRASS. > Are you all sure that including GDAL in the GRASS distribution in the > future is not an option? Yes. That would just make things worse. Hamish From hamish_nospam at yahoo.com Wed Jun 13 10:49:50 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jun 13 10:50:05 2007 Subject: [GRASS-dev] v.transform, wishlist #420 In-Reply-To: <1181653997.661.35.camel@localhost.localdomain> References: <1181594809.8471.37.camel@localhost.localdomain> <20070612163734.1b7aa78b.hamish_nospam@yahoo.com> <1181653997.661.35.camel@localhost.localdomain> Message-ID: <20070613204950.139ce153.hamish_nospam@yahoo.com> Harri Kiiskinen wrote: > That's what I thought when I looked at that code, but the thing is not > so simple, as when using v.transform, there is not way to know, > whether the 'to' or 'from' are coordinates are lat/long or not, > because v.transform is used to transform between different coordinate > systems, and the current location does not necessarily reflect either > of these. No, v.transform Is Not for transforming between different coordinate systems. Use v.proj for that. It's for adjusting coordinates in 3D space. It's description implies otherwise: "Transforms a vector map layer from one coordinate system into another coordinate system." but it's a bad bad bad habit to get into and corrupts the whole grass location paradigm. IMO the description should be changed. The r.region module description is better: "Sets the boundary definitions for a raster map." No more, no less. v.transform and r.region are for low-level adjusting of a map's coordinates. All maps within the same location are expected to use the same coordinate space, without exception. In practice v.transform may be used as a hack for transforming between different coordinate systems, but really it would be better to import your local data into a simple xy or custom projection, then pull/push the data into your target location with v.proj and r.proj. The problem is that a POINTS file with GCPs defines the relationship to a projection, not a projection itself. Currently for raster maps we have the i.rectify module which pushes raster maps into another location; r.proj and v.proj which pull from another location; the tcl gui georect tool which pulls maps from another location (hopefully from a XY location); and v.transform which tries to reproject in-place. This is a big pile of broken mess that needs to be sorted out IMHO, and I'm pretty sure that the in-place solution is the worst of the choices. ->We need to present the user with a single consistent process for rectification/reprojection. > An example: > > I have a location with a local coordinate system ( x = [6000,9000], y > = [2000,5000] ) for use with an archaeological excavation. To 'fix' > this system to a global system, some points are measured also in > lat/long coordinates. So I have a group of points having coordinates > in the local, metric system and in the global, lat/long system. Just > what v.transform needs to perform the transformation. Be careful as it only works if your study area is very small; as lines of longitude are not parallel. > However, if I do the transformation in the original location, where > the vector map is, the lat/long coordinates never go to G_lat_scan, as > the 'projection' is not PROJECTION_LL. On the other hand, if I export > the map and import it to the result location and do the transform > there, the metric coordinates will be given to G_lat_scan(), as the > 'projection' is PROJECTION_LL, even though for these points it is not > true, and the resulting coordinates will suffer the normalization to > the ranges mentioned above. I did test this already. The easiest solution is to convert your lat/lon GCPs into your local UTM zone coords (or other regional meter based system), then load your custom system data into the UTM location, and then use v.transform. Lat/lon is a pain for fine scale stuff anyway. Perhaps ask on the PROJ4 mailing list for help on better defining a custom projection if you wish. It's a fairly simple and empowering exercise. Then you could use v.proj. > So I still think, that there needs to be an additional test, either > defined by the user or based on the probability, that ':' in the > coordinate string means a lat/long that needs to be converted to > decimal. Applying radial (degrees) change in a cartesian coordinate system is not correct! Euclidean space != polar space. Adding hacks to allow the mixing of the two (only possible because the computer doesn't know better) is a path to pain. > > could the derived transform parms be used as the +towgs84 7-term > > projection in the new location, then v.proj? > > After a quick look at lib/vector/transform, I'd say that not > self-evidently. Someone with good enough knowledge of linear algebra > might be able to figure out, what the different transformation and > rotation coefficients actually mean, and if they could be used in > +towgs84. As the TODO file in that directory says, the "means of > generating the coefficients seems rather odd". The means aren't so important, as long as they work well enough. Once you have the 'ends' (coefficients), you have what you need to calculate the 7-term +towgs84 parm. (maybe?) +towgs84= 3x translation parameters (Dx, Dy, Dz) 3x rotational parameters (Rx, Ry, Rz) 1x scalar factor v.transform: xshift,yshift,zshift Shifting value for xyz coordinates xscale,yscale,zscale Scaling factor for xyz coordinates zrot Rotation around z axis in degrees CCW so Dx, Dy, Dz is the same, you "just" need to transform [Rx, Ry, Rz, scale] to [scaleX, scaleY, scaleZ, curlZ]. (is it possible??) After that the only frustrating bit is that you may have to adjust the +/- signs to get the reference frame convention right, but that's about it. see http://proj.maptools.org/gen_parms.html#towgs84 > Then again, v.transform is not really about re-projecting the data, > only about changing the coordinates into a different system It shifts them within the same system. It is quite deceptive. The libgis fn is not lacking, it's the module which is wrong in its presentation. > (I think there is a difference?) Reprojection *is* the changing of coordinates into a different system. (and by system I mean precisely the +proj= param in the EPSG file, but more generally as well, between two commonly used "systems" defined by the entire EPSG code definition) Note reprojection is not the same thing as rectification. x1,y1 can be reprojected into x2,y2 if the projection systems for both locations is known. This is v.proj,r.proj = Projection->Projection. Rectification (usually of remote imagery) consists of a perhaps uneven or warped input image and ground control points. The GCPs are visually applied by the user, and a mathematical fit between the two is derived and applied, so the output then exists in a known projection. This is i.rectify = XY location -> Projection. The mathematical relation is found and then forgotten when the i.rectify module exits. v.transform proably falls in this category (the mathematical relation is found by the user and then not useful for much after v.transform is done). > - usable just for the things its description says, putting dxf > drawings in place, or, in my case, changing vectors from a very local, > small scale coordinate system to something else - maybe another local > system - just by defining some common points. I think it is nice just > because it is simple, but I wouldn't use it for geographically large > areas. Right. Again a good solution is to transform your lat/lon points -> UTM or similar, then use v.transform in the UTM location. I think it is better to modify your method so it works within the existing GRASS paradigm, and fix the way v.transform is presented, than to muddy the GRASS paradigm even further by changing the way the libgis fns and/or how modules work. Sorry for the lengthy reply. If I were more of an expert in the ways and had a real solution I'm sure this email would be much shorter. But you raise an important problem that GRASS needs to address in a better and more consistent way. Hamish From hamish_nospam at yahoo.com Wed Jun 13 11:00:12 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jun 13 11:00:21 2007 Subject: [GRASS-dev] v.transform, wishlist #420 In-Reply-To: <3c5546140706120632j57cc0612k7cb1e4d43620be01@mail.gmail.com> References: <1181594809.8471.37.camel@localhost.localdomain> <20070612163734.1b7aa78b.hamish_nospam@yahoo.com> <1181653997.661.35.camel@localhost.localdomain> <3c5546140706120632j57cc0612k7cb1e4d43620be01@mail.gmail.com> Message-ID: <20070613210012.725dadfd.hamish_nospam@yahoo.com> Dylan Beaudette wrote: > > You will need: > > 1. a new location in UTM > 2. import your custom coordinates into that location, ignoring the > fact that the coordinate systems do not match > 3. use v.transform of course Dylan got to the same solution first.. :) > I think that v.transform should issue some kind of error if invoked > within a LL location... but, what if due to a transcription error or whatever you want to shift everything a degree to the west? (I do have a chart here where all lons are off by 1". It's a hand drawn 1853 nautical chart from the HMS Acheron which was only resurveyed and replaced in the last ~5 years. I met a guy from the British Admiralty service on a dive trip to the great barrier reef soon after- he said they had a big party as it was the last of their old-old maps still in service to be replaced. I guess that makes us the ends of the known world down here :) Hamish From hamish_nospam at yahoo.com Wed Jun 13 11:05:44 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jun 13 11:05:51 2007 Subject: [GRASS-dev] Interpolation in grass for MSG images. In-Reply-To: <9519512868jdgiraldo@upct.es> References: <9519512868jdgiraldo@upct.es> Message-ID: <20070613210544.0dba3581.hamish_nospam@yahoo.com> Juan Diego Giraldo Osorio wrote: > > I'm working in a command to make the geometrical correction of MSG > images. At this time, I have the points and its values (xy-coordinates > and radiance values) to execute an interpolation procedure. However, I > do not know how it do. At the moment, the best solution looks like to > be to include the v.surf.idw command (obviusly, I have a lot of > question too). Somebody have another solution??? v.surf.rst is nice for interpolating point data into smooth raster surfaces. Hamish From hamish_nospam at yahoo.com Wed Jun 13 11:36:29 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jun 13 11:36:42 2007 Subject: [GRASS-dev] Message standardization In-Reply-To: References: <20070611180245.4b2474b4.hamish_nospam@yahoo.com> Message-ID: <20070613213629.27dddaa2.hamish_nospam@yahoo.com> Michael Barton wrote: > > There is considerable back and forth (thoughtful) about periods. For > easy consistency, I'd simply go with: sentence ends with period; > phrase does not end with period. (and as HB says sentence != phrase). > Save ellipses for pending operations (Reading...). Standardization by place: module descriptions should be sentence-like and end with periods (consistently), option and flag descriptions are mostly phrase-like and don't end with punctuation. e.g. - the file tools/module_synopsis.sh makes looks weird if 1/4 of the modules' descriptions don't end with a dot. - as Carlos just noticed, the tcl GUI appends ":" after the option descriptions, and punctuation before that looks bad. If the option description is multi-sentence and it looks odd in the help page for the last sentence not to end with a period, while the first one does, the solution is to split the string up into short ->label and tooltip ->description parts. I am unsure if all G_fatal_error(), G_warning(), and G_message() should have "." or not. IMHO things like "Operation complete" and "Done" on a line by themselves look stronger as a punctuated statement, but others may disagree. We can agree that the first letter of all messages should be capitalized? Hamish From hamish_nospam at yahoo.com Wed Jun 13 12:51:51 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jun 13 12:51:58 2007 Subject: [GRASS-dev] Re: broken polygon fills with d.vect render=l In-Reply-To: <20070606174648.2643a4c1.hamish_nospam@yahoo.com> References: <20070606174648.2643a4c1.hamish_nospam@yahoo.com> Message-ID: <20070613225151.430af170.hamish_nospam@yahoo.com> Hamish wrote: > I just threw up some new screenshots showing broken polygon fills with > d.vect render=l. What should not be filled, is partially filled. > > Look near the end of the page: > > http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/ > > from those pics, and assuming we have to use the display library and > not the old libgis render functions, it appears that "c" would be a > nicer pick than "l", if the two bands of white at the edges could be > corrected. Another d.vect issue, in 6.3cvs the new D_line_width() forces the minimum line width to 1, which creates ugly jagged line output vs a line width of 0. This patch makes it nice again: Index: lib/display/draw2.c =================================================================== RCS file: /home/grass/grassrepository/grass6/lib/display/draw2.c,v retrieving revision 1.11 diff -u -r1.11 draw2.c --- lib/display/draw2.c 8 Apr 2007 18:03:29 -0000 1.11 +++ lib/display/draw2.c 13 Jun 2007 09:58:05 -0000 @@ -847,8 +847,8 @@ int w = round(d); double m; - if (w < 1) - w = 1; + if (w < 0) + w = 0; R_line_width(w); screenshots can be found at the URL at top of this email. (Spf roads buffered 5m) The screenshots also show some north-south shift error in some lines using different rendering methods. see also previous talk about line width=0,1 WRT v.digit and tcl minimum width inputs: Glynn wrote: http://thread.gmane.org/gmane.comp.gis.grass.user/17458/focus=18731 > Odd. I initially suspected that Tk may have a different interpretation > of "width" compared to X etc. However, having traced the Tk drawing > routines with GDB, I can confirm that the width entered in the > Settings dialog is passed directly[1] into the X GC. then: http://thread.gmane.org/gmane.comp.gis.grass.devel/20444/focus=20503 finally: (11 May 2007) Hamish: >>> n.b. the smallest D_line_width is 0, not 1. width=1 still looks a >>> little lumpy. (experiment with d.vect) Maciej: > > Are you absolutely sure? Glynn says it's really 1: > > http://grass.itc.it/pipermail/grass-dev/2007-February/029336.html Hamish: > Well I was sure, but not so much anymore! I could have sworn I could > see the difference in the past. Can't seem to now. (by then R_line_width() had changed to D_line_width()) .. something is funny here. As seen in the screenshots linked above there is a real difference, at least in the XDRIVER output. Hamish From hamish_nospam at yahoo.com Wed Jun 13 13:11:14 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Jun 13 13:11:33 2007 Subject: [GRASS-dev] Message standardization In-Reply-To: References: <20070611180245.4b2474b4.hamish_nospam@yahoo.com> Message-ID: <20070613231114.4ba91676.hamish_nospam@yahoo.com> more questions to answer before we go much further.... We need to sort out parentheticals before we go much further as well: just because something is a variable doesn't mean it sould be in brackets, especially if it is an integral part of the sentence structure. To me this is way too overformatted and difficult to read: (v.to.db/report.c) Updating database ... 100% [2] categories read from map [0] records selected from table [0] categories read from map exist in selection from table [1] categories read from map don't exist in selection from table [1] records updated/inserted [0] update/insert errors Current attribute table links: Vector map is connected by: layer <1> table in database through driver with key is ok, but <1>, [0], makes it too broken up IMO. Perhaps " with key 'cat' " might be nicer? also: G63> g.list vect files available in mapset : "vector" does not need to be in <>. Maybe if we could do syntax highlighting in the GUI this wouldn't look so bad, but as plain text it just doesn't work for me with the extra chars. >From the wiki page: How should Errors/Warnings/Messages be formatted * strings < > o e.g. Raster map <%s> not found * numbers [ ] o e.g. Line [%d] deleted ? The [bracketed] parenthetical disrupts the flow of the phrase and doesn't help enhance clarity of meaning. IMHO, this reads better without [] brackets: "Line %d deleted." [] Brackets should be used when value is outside of the phrase: "Unknown line [%d]". --HB ?, Hamish From glynn at gclements.plus.com Wed Jun 13 17:07:20 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Jun 13 17:07:25 2007 Subject: [GRASS-dev] d.rast.edit in wxgrass In-Reply-To: References: <18030.51478.568398.685831@cerise.gclements.plus.com> Message-ID: <18032.2088.14862.39790@cerise.gclements.plus.com> Michael Barton wrote: > > d.* commands used as map layers belong in a separate menu. The menu > > items for layer commands should have different bindings to normal > > commands. > > > > Determining how to run a command based upon its name is simply wrong. > > This is needed, at least in some spots to permit running d.* commands from > the CLI. That's why it needs to look at the name. No, it's needed to force d.* commands to be intercepted and used to create layers. It won't work if the d.* command isn't suitable as a layer command (e.g. d.rast.edit). It also precludes running d.* commands normally (i.e. using a monitor). Ignoring the last point, determining whether or not a command can be used as a layer command isn't as simple as matching against "d.*". > If it was only from the menu, then it would be easy. I don't know if this is > the case in menuform. I don't know exactly what is going on in this spot and > haven't had time yet to figure it out. The name "menuform.py" suggests that it has something to do with menus. In which case, what is: if cmd[0][0:2] != "d.": doing in that file (specifically, in mainFrame.OnRun())? Even if you are determined to use that hack for the CLI, it has no utility in regard to menus. -- Glynn Clements From glynn at gclements.plus.com Wed Jun 13 17:10:10 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Jun 13 17:10:13 2007 Subject: [GRASS-dev] v.transform, wishlist #420 In-Reply-To: <20070613204950.139ce153.hamish_nospam@yahoo.com> References: <1181594809.8471.37.camel@localhost.localdomain> <20070612163734.1b7aa78b.hamish_nospam@yahoo.com> <1181653997.661.35.camel@localhost.localdomain> <20070613204950.139ce153.hamish_nospam@yahoo.com> Message-ID: <18032.2258.868871.471514@cerise.gclements.plus.com> Hamish wrote: > > That's what I thought when I looked at that code, but the thing is not > > so simple, as when using v.transform, there is not way to know, > > whether the 'to' or 'from' are coordinates are lat/long or not, > > because v.transform is used to transform between different coordinate > > systems, and the current location does not necessarily reflect either > > of these. > > No, v.transform Is Not for transforming between different coordinate > systems. Use v.proj for that. It's for adjusting coordinates in 3D > space. > > It's description implies otherwise: "Transforms a vector map layer from > one coordinate system into another coordinate system." Whoever wrote that was presumably thinking about the use of the term "coordinate system" in mathematics/geometry rather than in cartography. As the user will probably view it from a cartographic perspective, it's rather misleading. -- Glynn Clements From michael.barton at asu.edu Wed Jun 13 17:12:22 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Jun 13 17:12:38 2007 Subject: [GRASS-dev] Message standardization In-Reply-To: <20070613213629.27dddaa2.hamish_nospam@yahoo.com> Message-ID: Module descriptions are a different sort of beast from error messages--and from GUI messages and other descriptors. All need standardization, but I'd recommend doing them one at a time so as not to overwhelm everyone. If we can standardize error messages first it might be the simplest piece to attack. Then move on to others like module descriptions in the module code, module doc formatting, GUI, etc. Michael On 6/13/07 2:36 AM, "Hamish" wrote: > Michael Barton wrote: >> >> There is considerable back and forth (thoughtful) about periods. For >> easy consistency, I'd simply go with: sentence ends with period; >> phrase does not end with period. (and as HB says sentence != phrase). >> Save ellipses for pending operations (Reading...). > > Standardization by place: module descriptions should be sentence-like > and end with periods (consistently), option and flag descriptions are > mostly phrase-like and don't end with punctuation. > > e.g. > - the file tools/module_synopsis.sh makes looks weird if 1/4 of the > modules' descriptions don't end with a dot. > > - as Carlos just noticed, the tcl GUI appends ":" after the option > descriptions, and punctuation before that looks bad. If the option > description is multi-sentence and it looks odd in the help page for the > last sentence not to end with a period, while the first one does, the > solution is to split the string up into short ->label and tooltip > ->description parts. > > > I am unsure if all G_fatal_error(), G_warning(), and G_message() should > have "." or not. IMHO things like "Operation complete" and "Done" on a > line by themselves look stronger as a punctuated statement, but others > may disagree. > > > We can agree that the first letter of all messages should be capitalized? > > > Hamish __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From glynn at gclements.plus.com Wed Jun 13 17:21:08 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Jun 13 17:21:11 2007 Subject: [GRASS-dev] Re: broken polygon fills with d.vect render=l In-Reply-To: <20070613225151.430af170.hamish_nospam@yahoo.com> References: <20070606174648.2643a4c1.hamish_nospam@yahoo.com> <20070613225151.430af170.hamish_nospam@yahoo.com> Message-ID: <18032.2916.987181.448096@cerise.gclements.plus.com> Hamish wrote: > > I just threw up some new screenshots showing broken polygon fills with > > d.vect render=l. What should not be filled, is partially filled. > > > > Look near the end of the page: > > > > http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/ > > > > from those pics, and assuming we have to use the display library and > > not the old libgis render functions, it appears that "c" would be a > > nicer pick than "l", if the two bands of white at the edges could be > > corrected. > > Another d.vect issue, in 6.3cvs the new D_line_width() forces the > minimum line width to 1, which creates ugly jagged line output vs a line > width of 0. > > This patch makes it nice again: > > Index: lib/display/draw2.c > =================================================================== > RCS file: /home/grass/grassrepository/grass6/lib/display/draw2.c,v > retrieving revision 1.11 > diff -u -r1.11 draw2.c > --- lib/display/draw2.c 8 Apr 2007 18:03:29 -0000 1.11 > +++ lib/display/draw2.c 13 Jun 2007 09:58:05 -0000 > @@ -847,8 +847,8 @@ > int w = round(d); > double m; > > - if (w < 1) > - w = 1; > + if (w < 0) > + w = 0; > > R_line_width(w); I suggest: if (w < 0) w = 0; R_line_width(w); if (w < 1) w = 1; Otherwise, D_line_width(0) will set a clip/cull margin of zero. > .. something is funny here. As seen in the screenshots linked above > there is a real difference, at least in the XDRIVER output. Notes: 1. X doesn't specify exactly which pixels are plotted when drawing lines. In practice, the definition may be "whichever pixels the video chip's line-drawing hardware decides to plot". IOW, the result can vary depending upon your video hardware. 2. There can be significant differences in the behaviour of XDrawLine() etc depending on whether the line width is zero. Essentially, a line width of 1 results in a "thick" line while 0 results in a "thin" line. Thick lines are treated as defining a filled area centred on the line, e.g. if a polyline intersects itself, the intersection will only be drawn once (which is significant if using e.g. the GXxor function). -- Glynn Clements From michael.barton at asu.edu Wed Jun 13 17:22:54 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Jun 13 17:23:06 2007 Subject: [GRASS-dev] Message standardization In-Reply-To: <20070613231114.4ba91676.hamish_nospam@yahoo.com> Message-ID: I agree. In fact, for this particular example, I don't think that [] or <> add anything at all--even to map names. Single quotes would be better for map names and variable names. I'd also remove an extraneous colon after "by" and add the word "to" after the layer (see below). A bit of white space wouldn't hurt. Michael On 6/13/07 4:11 AM, "Hamish" wrote: > more questions to answer before we go much further.... > > We need to sort out parentheticals before we go much further as well: > just because something is a variable doesn't mean it sould be in > brackets, especially if it is an integral part of the sentence > structure. > > > To me this is way too overformatted and difficult to read: > ### suggested reformatting ### ### changes include: removing all [] around counts, removing colon following ### "by", adding "to" following "1", replacing <> with '', adding "." at ### end. (v.to.db/report.c) Updating database ... 100% 2 categories read from map 0 records selected from table 0 categories read from map exist in selection from table 1 categories read from map don't exist in selection from table 1 records updated/inserted 0 update/insert errors Current attribute table links: Vector map 'roads_5m' is connected by layer 1 to table 'roads_5m' in database '/home/hamish/grassdata/spearfish60/user1/dbf/' through driver 'dbf' with key 'cat'. > > > is ok, but <1>, [0], makes it too broken up IMO. > > Perhaps " with key 'cat' " might be nicer? > > > > also: > G63> g.list vect > files available in mapset : > > "vector" does not need to be in <>. Maybe if we could do syntax > highlighting in the GUI this wouldn't look so bad, but as plain > text it just doesn't work for me with the extra chars. > > > From the wiki page: > How should Errors/Warnings/Messages be formatted > > * strings < > > o e.g. Raster map <%s> not found > * numbers [ ] > o e.g. Line [%d] deleted > > ? The [bracketed] parenthetical disrupts the flow of the phrase and > doesn't help enhance clarity of meaning. IMHO, this reads better without > [] brackets: "Line %d deleted." [] Brackets should be used when value is > outside of the phrase: "Unknown line [%d]". --HB > > > > ?, > Hamish __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Wed Jun 13 18:03:59 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Jun 13 18:04:14 2007 Subject: [GRASS-dev] d.rast.edit in wxgrass In-Reply-To: <18032.2088.14862.39790@cerise.gclements.plus.com> Message-ID: On 6/13/07 8:07 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >>> d.* commands used as map layers belong in a separate menu. The menu >>> items for layer commands should have different bindings to normal >>> commands. >>> >>> Determining how to run a command based upon its name is simply wrong. >> >> This is needed, at least in some spots to permit running d.* commands from >> the CLI. That's why it needs to look at the name. > > No, it's needed to force d.* commands to be intercepted and used to > create layers. It won't work if the d.* command isn't suitable as a > layer command (e.g. d.rast.edit). It also precludes running d.* > commands normally (i.e. using a monitor). > > Ignoring the last point, determining whether or not a command can be > used as a layer command isn't as simple as matching against "d.*". Clarification. No d.* commands come from the menus, except for d.rast.edit and some old ones that need xmons. The latter are specially routed through the OnXterm method and never are parsed by menuform.py. d.rast.edit is the only weird exception solely because you made a nice gui for it. "Normal" menu commands are all those that are not display commands and have no arguments. Explicitly in the menu, these are processed by OnMenuCmd in wxgui.py. They are sent to the menuform.py parser. d.* commands (e.g., d.rast, d.grid, etc) are simply not in the menu as a general rule because they need to handled differently, as you say. Menu commands with arguments (e.g., g.region -p) are explicitly handled by RunMenuCmd, which simply sends them on to the command processor (ultimately cmd.Command(cmdlist), rather than menuform.py. Menu commands which call wxPython modules have their own handlers (e.g., histogramming or the new rules dialogs). Menu commands which require an xterm (a few like r.digit) are handled by the new OnXTerm method, which launches an xmon and xterm. Jachym and others have been working on some Python scripts (e.g., p.mon) to give access to some the of the wxgrass functions from the *nix terminal. I don't really know how these function. The d.* trap within menuform.py may be related to these or it may be a holdover from an earlier iteration that should be dropped. For the CLI built into wxgrass (the one I DO know about), here is the parsing logic. A list of GRASS CLI commands is made by searching $GISBASE/bin and $GISBASE/scripts. If the first part (i.e., before the first space) of a string typed on the CLI is not in the list, it is passed on to the shell. If first part of the string IS in the GRASS command list, it is treated as a GRASS command. I realize that the following is not ideal, but it's the best I've been able to come up with so far and covers the great majority of cases. Suggestions for improvements are welcome. GRASS command parsing from the wxgrass CLI: Split the command into a list by spaces. I realize that this is a problem for any command with spaces in the arguments, but I know of no better way to do this in this context outside of making users type any command as a Python list. If we made people type ['g.region', 'rast=mymap', 'res=30'] instead of g.region rast=mymap res=30, I don't think anyone would want to use the CLI. If the command has no arguments (i.e., len(cmdlist) == 0) AND it is NOT a d.* command, send the original command string (not the list) to the menuform.py processor (just like the menu would) to create the autogenerated properties dialog. After this, the result of hitting "run" is the same as if the properties dialog were called from the menu. If the command has no arguments AND IS a d.* command AND is in a hard coded list of d.* commands for which we have defined layers in the layer tree, create a layer tree item for that command (e.g., a raster layer for d.rast). After that, the new layer is processed in the same way as one created by pressing a layer button on the layer manager toolbar. If the d.* command without arguments is NOT on the list for the layer tree, generate get a message that it cannot be processed. If the command HAS arguments and is NOT a d.* command, send the command list (i.e., made by splitting on spaces -- not the original command string) to cmd.Command for processing. If the command HAS arguments and IS a d.* command, it is added to the list of display layers managed within render.py for the map display that has the focus and the UpdateMap method is called to update that display. There is a 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. > >> If it was only from the menu, then it would be easy. I don't know if this is >> the case in menuform. I don't know exactly what is going on in this spot and >> haven't had time yet to figure it out. > > The name "menuform.py" suggests that it has something to do with > menus. In which case, what is: > > if cmd[0][0:2] != "d.": > > doing in that file (specifically, in mainFrame.OnRun())? I don't know. menuform.py parses the --interface-description xml data to create a properties dialog. The dialog takes the results of user choices and creates a command list for processing--ulitmately by cmd.Command. > > Even if you are determined to use that hack for the CLI, it has no > utility in regard to menus. I just don't know if it is related to the p.mon, p.rast, etc scripts or whether it can simply be removed. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From cdavilam at jemila.jazztel.es Wed Jun 13 18:29:44 2007 From: cdavilam at jemila.jazztel.es (=?ISO-8859-15?Q?Carlos_D=E1vila?=) Date: Wed Jun 13 18:28:33 2007 Subject: [GRASS-dev] Upload/download in v.in.garmin Message-ID: <46701B78.1030809@jemila.jazztel.es> In v.in.garmin dialog it can be read: *Upload* waypoints from gps *Upload* routes from gps *Upload* track from gps but Use gardump instead of gpstrans as the *download* program I think the same expression should be used in all cases (download IMHO). Carlos From hamish_nospam at yahoo.com Thu Jun 14 05:30:32 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Jun 14 05:30:40 2007 Subject: [GRASS-dev] Upload/download in v.in.garmin In-Reply-To: <46701B78.1030809@jemila.jazztel.es> References: <46701B78.1030809@jemila.jazztel.es> Message-ID: <20070614153032.0f98a49d.hamish_nospam@yahoo.com> Carlos D?vila wrote: > > In v.in.garmin dialog it can be read: > *Upload* waypoints from gps > *Upload* routes from gps > *Upload* track from gps > but > Use gardump instead of gpstrans as the *download* program > I think the same expression should be used in all cases (download > IMHO). I agree, and struggled with what to call it. It needs to be consistent with the g.messages within: "Receiving track ..." -e "Retrieving data." and v.in.gpsbabel also: #% description: Upload Waypoints from GPS "Loading Waypoints from <$GIS_OPT_INPUT> ..." I am happy with standardizing on "download", but it's slightly a matter of perspective. Hamish ps- hopefully these two modules can be combined one day (in another language), with the download program given as an option list. From michael.barton at asu.edu Thu Jun 14 06:47:53 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jun 14 06:48:12 2007 Subject: [GRASS-dev] report on raster point creation Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: impacts.png Type: application/octet-stream Size: 4496 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070613/e05dd6a5/impacts-0001.obj From michael.barton at asu.edu Thu Jun 14 06:53:04 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jun 14 06:53:22 2007 Subject: [GRASS-dev] still some intermittent instability in layer management Message-ID: Martin, I've run into some intermittent instability in layer management since the switch to the new approach a few weeks back. I don't know what triggers it, so I'm not much help but thought you should keep a watch for it too. Once in a while, a layer won't go away--unchecking it or even deleting it from the layer tree are insufficient to make it not display. I'm guessing it's somehow stuck in the layer list. I tried to make a force render button awhile back but can't really see that it does anything different. But we need something to force a complete refresh if needed. Not urgent, but something to be on the lookout for. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070613/f53e06a5/attachment.html From michael.barton at asu.edu Thu Jun 14 06:58:29 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jun 14 06:58:45 2007 Subject: [GRASS-dev] a suggestion for v.transform Message-ID: There has been a thread about how v.transform functions and Glynn pointed out that part of the problem is that the short description does not really describe what it does, at least from a GIS perspective: " Transforms a vector map layer from one coordinate system into another coordinate system." I'm working on wxgrass menus at the moment and trying to come up with useful menu entries. A better short description for v.transform might be: "Reposition (shift and rotate) vector file in coordinate space" Thoughts? Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Thu Jun 14 07:22:58 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jun 14 07:23:30 2007 Subject: [GRASS-dev] mysteries of rendering Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: impact_tcltk1.png Type: application/octet-stream Size: 3568 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070613/d2c54015/impact_tcltk1.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: impact_tcltk2.png Type: application/octet-stream Size: 3847 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070613/d2c54015/impact_tcltk2.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: impact_wxp1.png Type: application/octet-stream Size: 3859 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070613/d2c54015/impact_wxp1.obj From harkiisk at utu.fi Thu Jun 14 10:31:43 2007 From: harkiisk at utu.fi (Harri Kiiskinen) Date: Thu Jun 14 10:31:55 2007 Subject: [GRASS-dev] v.transform, wishlist #420 In-Reply-To: <18032.2258.868871.471514@cerise.gclements.plus.com> References: <1181594809.8471.37.camel@localhost.localdomain> <20070612163734.1b7aa78b.hamish_nospam@yahoo.com> <1181653997.661.35.camel@localhost.localdomain> <20070613204950.139ce153.hamish_nospam@yahoo.com> <18032.2258.868871.471514@cerise.gclements.plus.com> Message-ID: <1181809903.661.53.camel@localhost.localdomain> Thanks for Glynn and Hamish for clarifications; I fully accept your reasoning. I think I got slightly carried out by what could be done and thus ignoring whether it really should be done. Harri K. From hamish_nospam at yahoo.com Thu Jun 14 11:45:52 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Jun 14 11:46:05 2007 Subject: [GRASS-dev] Re: report on raster point creation In-Reply-To: References: Message-ID: <20070614214552.0c3b930f.hamish_nospam@yahoo.com> Michael Barton wrote: > We have finally had an initial production test of methods to create a > raster point using xy coordinates. If you remember, I've periodically > whined a bit about the lack of a way to create and change a raster > cell based on its xy coordinates instead of its cat value. > > The 2 suggestions I got to work around this were to... > > 1) use r.in.poly to create the raster map; make an input file such > that for each point, the input is set to line (L) with 2 points that > are identical. To make that method easier I have just added a "P" instruction to r.in.poly in 6.3cvs. That uses G_plot_point(), which draws a 0 length line using the same method, so probably it doesn't fix your 2 cell if on bound problem (?? try it and see). > 2) use v.in.ascii and then use v.to.rast to create the raster map. Note the v.to.rast code is ~95% a clone of the r.in.poly code, so results (and problems) should be mostly the same. Do you see the same multiple cell trouble if the point falls on a bound using this method? It probably needs to be noted in the v.to.rast help page if it does, at minimum. 3) use r.in.xyz (I expect this will be the fastest method) 4) r.mapcalc outmap='if( (abs(x() - $x)) < ewres()) \ && (abs(y() - $y) < nsres(), $val, null() )' [or something like that, for a single point; yuk] 5) do the gridding yourself and create a r.in.ascii file. all these would need to be followed by a call to r.patch. (see d.rast.edit.tcl method) > We are coupling an agent-based simulation to GRASS, such that the > simulated land use activities will affect land cover, which in turn > will affect a landscape evolution routine. are you updating a sequential string of cells, blocks of cells, or random cells at each update? > Optimizing the speed of this is critical, and so we prefer to reduce > the number of steps needed to accomplish this. This means that the > r.in.poly approach is the one we prefer. However, in tests conducted > today, we ran into an unexpected problem. > > If the coordinate of the point to be created happens to fall on a cell > boundary, we get a 2-cell 'line' instead of a point even though the > beginning and end points are identical. Apparently, r.in.poly looks > for a cell center closest to end point one and then searches for a > cell center for end point 2 that is different from the first cell, > resulting in a 2 cell line. This does not happen if the point does not > fall on a cell boundary. Attached is the raster file created from the > following r.in.poly input. The first input creates the 2 yellow cells, > the other 2 create the red and green single cells. r.in.poly/raster.c defines the "cont" continue line fn used by G_setup_plot() (and thus all following G_plot_*() commands) with G_bresenham_line(). That in turn uses the "dot" fn to draw the points; which "dot" is used depends on the result of the getformat() scan of the cat values (& I'm about foggy about what that's all about). for info on the Bresenham line rasterization method see: http://en.wikipedia.org/wiki/Bresenham's_line_algorithm > This is a potential problem, since an agent might not know that the > the coordinates it chooses for a field to farm or graze like on a cell > boundary. It is OK if r.in.poly substitutes the nearest grid cell > center to make the raster point for the xy coordinates that the agent > chooses, but not OK if it picks 2 different cells instead of one. Try r.in.xyz, it shouldn't suffer from this: on one side of the cell it tests for <= and on the other side <. So a point on a bound always fall in the <= cell. The exception is the outer E,W raster boundaries which will make values fall "into" the raster if on the bound. r.in.xyz doesn't let you add cat labels, but you can do that manually by creating a cats/ file. See spearfish60/PERMANENT/cats/landuse for an example, it's very simple. > The simplest solution is to allow r.in.poly to make points as well as > lines and areas. I'm not sure why it doesn't allow points in the first > place. It seems like an oversight. Is this difficult to implement? done, but I don't think it will help any due to the way G_plot_point() works. > * * * * > > Also, there is still no one-step way to change a cell value based on > its xy coordinates. So you want a non-interactive d.rast.edit, like v.edit? A couple of ways to do that, 1) get input x1,y1,cat1 ... from stdin, qsort() based on y then x, read each line and if there's an updated cell in it replace it before writing the row back out. (as r.patch) 2) calculate the array column,row which contains each x,y and update each in the order they arrive (as r.in.xyz). Probably the fastest way is a combination of the two. Sort by y, and for each row update the column values in the order they arrive, then write out the finished line and move on to the next row. > However, if there is interest in doing agent and cellular modeling > within a GRASS platform, it will become necessary to be able to do > this to simulate dynamics. Patching may simply not be practical for > this kind of work. As Python becomes more used as a scripting > environment, this is an attractive kind of application to build in > Python, given its object oriented structure, and couple with GRASS. The module probably isn't so hard to write, in C. r.example should give a nice start. It would be interesting to rewrite r.example.c using the SWIG Python interface, and see if that gains any simplicity over C, or if it just adds complexity without simplicity -- as you still need to go through all the same chores. Hamish From Juan.Giraldo at upct.es Thu Jun 14 13:12:50 2007 From: Juan.Giraldo at upct.es (Juan Diego Giraldo Osorio) Date: Thu Jun 14 13:11:10 2007 Subject: [GRASS-dev] correction to v.example In-Reply-To: <20070613210544.0dba3581.hamish_nospam@yahoo.com> References: <20070613210544.0dba3581.hamish_nospam@yahoo.com> Message-ID: <2623147663jdgiraldo@upct.es> Hi everyone I'm a beginner programmer in GRASS, but in the v.example code (main.c file) I have found a little mistake in this line: Vect_check_input_output_name ( new->answer, old->answer, GV_FATAL_EXIT ); The correct form (I think) is the next: Vect_check_input_output_name ( old->answer, new->answer, GV_FATAL_EXIT ); Only shift "new" by "old", because the first function parameter is the "input" file ("old") and the second funtion parameter is the "output" file ("new"). Without this correction the error message was. ERROR: Cannot find input map 'output_file' I hope this message help to anothers beginners. From gnelson at uiuc.edu Thu Jun 14 14:17:46 2007 From: gnelson at uiuc.edu (Gerald Nelson) Date: Thu Jun 14 14:17:56 2007 Subject: [GRASS-dev] Re: [GRASS-user] a suggestion for v.transform Message-ID: <20070614071746.ARJ82038@expms1.cites.uiuc.edu> Would it make sense to say something like "... in current coordinate space (add parenthetical phrase about what that is)." ---- Original message ---- >Date: Wed, 13 Jun 2007 21:58:29 -0700 >From: Michael Barton >Subject: [GRASS-user] a suggestion for v.transform >To: GRASS Support , GRASS devel > >There has been a thread about how v.transform functions and Glynn pointed >out that part of the problem is that the short description does not really >describe what it does, at least from a GIS perspective: > >" Transforms a vector map layer from one coordinate system into another >coordinate system." > >I'm working on wxgrass menus at the moment and trying to come up with useful >menu entries. A better short description for v.transform might be: > >"Reposition (shift and rotate) vector file in coordinate space" > >Thoughts? > >Michael >__________________________________________ >Michael Barton, Professor of Anthropology >School of Human Evolution & Social Change >Center for Social Dynamics & Complexity >Arizona State University > >phone: 480-965-6213 >fax: 480-965-7671 >www: http://www.public.asu.edu/~cmbarton > > >_______________________________________________ >grassuser mailing list >grassuser@grass.itc.it >http://grass.itc.it/mailman/listinfo/grassuser Gerald Nelson Professor, Dept. of Agricultural and Consumer Economics University of Illinois, Urbana-Champaign office: 217-333-6465 cell: 217-390-7888 315 Mumford Hall 1301 W. Gregory Urbana, IL 61801 From benjamin.ducke at ufg.uni-kiel.de Thu Jun 14 14:50:25 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Thu Jun 14 14:51:25 2007 Subject: [GRASS-dev] GRASS and GDAL 1.4.1 MingW In-Reply-To: <20070613115934.31c56135.hamish_nospam@yahoo.com> References: <466E770E.8070103@ufg.uni-kiel.de> <20070613115934.31c56135.hamish_nospam@yahoo.com> Message-ID: <46713991.1040409@ufg.uni-kiel.de> Hamish wrote: > Benjamin Ducke wrote: >> 2. However, the README is not clear on whether GRASS first needs to be >> compiled w/o GDAL support firdst, but I assume it has to, because it >> won't be able to find GDALOpen and the configure script aborts: > .. >> 3. Fair enough, BUT: with the current CVS version, it seems impossible >> to compile GRASS without GDAL support, as compilation in >> lib/vector/Vlib aborts, even if I specify --without-gdal: > > GDAL is now a formal dependency. compiling without it is a bad idea. > > > the order should be: > 1. compile & install GDAL without grass support > 2. compile & install GRASS linking to the new GDAL > 3. compile & install GDAL's GRASS plugin linking to the new GRASS. Step 1: OK Step 2: Fails: checking for gdal-config... /usr/local/bin/gdal-config checking for GDALOpen... no checking for GDALOpen... no configure: error: *** couldn't find GDAL Would this be the time to remove --without-gdal from the configure script? 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 benjamin.ducke at ufg.uni-kiel.de Thu Jun 14 15:42:04 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Thu Jun 14 15:43:05 2007 Subject: [GRASS-dev] GRASS and GDAL 1.4.1 MingW In-Reply-To: <46713991.1040409@ufg.uni-kiel.de> References: <466E770E.8070103@ufg.uni-kiel.de> <20070613115934.31c56135.hamish_nospam@yahoo.com> <46713991.1040409@ufg.uni-kiel.de> Message-ID: <467145AC.80505@ufg.uni-kiel.de> I just tried installing the GDAL version contained in the wingrass-extralibs package: http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status following the precise steps as outlined here: http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status With a fresh update of GRASS CVS Still the same configure error: checking for gdal-config... /usr/local/bin/gdal-config checking for GDALOpen... no checking for GDALOpen... no configure: error: *** couldn't find GDAL What am I doing wrong? Benjamin Benjamin Ducke wrote: > > Hamish wrote: >> Benjamin Ducke wrote: >>> 2. However, the README is not clear on whether GRASS first needs to be >>> compiled w/o GDAL support firdst, but I assume it has to, because it >>> won't be able to find GDALOpen and the configure script aborts: >> .. >>> 3. Fair enough, BUT: with the current CVS version, it seems impossible >>> to compile GRASS without GDAL support, as compilation in >>> lib/vector/Vlib aborts, even if I specify --without-gdal: >> GDAL is now a formal dependency. compiling without it is a bad idea. >> >> >> the order should be: >> 1. compile & install GDAL without grass support >> 2. compile & install GRASS linking to the new GDAL >> 3. compile & install GDAL's GRASS plugin linking to the new GRASS. > > Step 1: OK > Step 2: Fails: > > checking for gdal-config... /usr/local/bin/gdal-config > checking for GDALOpen... no > checking for GDALOpen... no > configure: error: *** couldn't find GDAL > > Would this be the time to remove --without-gdal from the configure > script? > > 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 paul-grass at stjohnspoint.co.uk Thu Jun 14 16:11:10 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Thu Jun 14 16:11:29 2007 Subject: [GRASS-dev] GRASS and GDAL 1.4.1 MingW In-Reply-To: <467145AC.80505@ufg.uni-kiel.de> References: <466E770E.8070103@ufg.uni-kiel.de> <20070613115934.31c56135.hamish_nospam@yahoo.com> <46713991.1040409@ufg.uni-kiel.de> <467145AC.80505@ufg.uni-kiel.de> Message-ID: On Thu, 14 Jun 2007, Benjamin Ducke wrote: > I just tried installing the GDAL version contained in the > wingrass-extralibs package: > > http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status > > following the precise steps as outlined here: > > http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status > > With a fresh update of GRASS CVS > > Still the same configure error: > > checking for gdal-config... /usr/local/bin/gdal-config > checking for GDALOpen... no > checking for GDALOpen... no > configure: error: *** couldn't find GDAL > > What am I doing wrong? Look in config.log to see what the error is and you should be able to work it out from there. However I suspect you may need to change the paths at the top of the gdal-config script to match where you have actually installed it, rather than where I installed it before I generated wingrass-extralibs.tar.gz. It's not designed to be fool-proof, just a help to save effort in compiling all the other libraries. Although maybe long-term we could move away from using the gdal-config command in the configure script to get away from problems like this. I think everything its used for should probably be able to be achieved without it. Paul From benjamin.ducke at ufg.uni-kiel.de Thu Jun 14 16:24:09 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Thu Jun 14 16:25:11 2007 Subject: [GRASS-dev] GRASS and GDAL 1.4.1 MingW In-Reply-To: References: <466E770E.8070103@ufg.uni-kiel.de> <20070613115934.31c56135.hamish_nospam@yahoo.com> <46713991.1040409@ufg.uni-kiel.de> <467145AC.80505@ufg.uni-kiel.de> Message-ID: <46714F89.5050707@ufg.uni-kiel.de> Cool. That fixed it. I think I am getting slowly to the point where I understand all the details of the MinGW compile process. I hope I'll be able to report back with some debugging news concerning the Win32 DBF.EXE deadlocks soon. Best, Benjamin Paul Kelly wrote: > On Thu, 14 Jun 2007, Benjamin Ducke wrote: > >> I just tried installing the GDAL version contained in the >> wingrass-extralibs package: >> >> http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status >> >> following the precise steps as outlined here: >> >> http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status >> >> With a fresh update of GRASS CVS >> >> Still the same configure error: >> >> checking for gdal-config... /usr/local/bin/gdal-config >> checking for GDALOpen... no >> checking for GDALOpen... no >> configure: error: *** couldn't find GDAL >> >> What am I doing wrong? > > Look in config.log to see what the error is and you should be able to > work it out from there. However I suspect you may need to change the > paths at the top of the gdal-config script to match where you have > actually installed it, rather than where I installed it before I > generated wingrass-extralibs.tar.gz. It's not designed to be fool-proof, > just a help to save effort in compiling all the other libraries. > Although maybe long-term we could move away from using the gdal-config > command in the configure script to get away from problems like this. I > think everything its used for should probably be able to be achieved > without it. > > Paul > > -- 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 JGillette at rfmd.com Thu Jun 14 16:40:10 2007 From: JGillette at rfmd.com (John Gillette) Date: Thu Jun 14 16:40:52 2007 Subject: [GRASS-dev] a suggestion for v.transform In-Reply-To: Message-ID: v.transform: perform affine transformation (translate and rotate) a vector file. See affine transformation in wikipedia. John From michael.barton at asu.edu Thu Jun 14 17:12:25 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jun 14 17:12:41 2007 Subject: [GRASS-dev] Re: report on raster point creation In-Reply-To: <20070614214552.0c3b930f.hamish_nospam@yahoo.com> Message-ID: Thanks very much. I'll need to digest all this useful information later today, but it is helpful. I'll check r.in.xyz and your update to r.in.poly and get back to you. Michael On 6/14/07 2:45 AM, "Hamish" wrote: > Michael Barton wrote: >> We have finally had an initial production test of methods to create a >> raster point using xy coordinates. If you remember, I've periodically >> whined a bit about the lack of a way to create and change a raster >> cell based on its xy coordinates instead of its cat value. >> >> The 2 suggestions I got to work around this were to... >> >> 1) use r.in.poly to create the raster map; make an input file such >> that for each point, the input is set to line (L) with 2 points that >> are identical. > > To make that method easier I have just added a "P" instruction to > r.in.poly in 6.3cvs. That uses G_plot_point(), which draws a 0 length > line using the same method, so probably it doesn't fix your 2 cell if > on bound problem (?? try it and see). > >> 2) use v.in.ascii and then use v.to.rast to create the raster map. > > Note the v.to.rast code is ~95% a clone of the r.in.poly code, so results > (and problems) should be mostly the same. Do you see the same multiple > cell trouble if the point falls on a bound using this method? > > It probably needs to be noted in the v.to.rast help page if it does, at > minimum. > > > 3) use r.in.xyz (I expect this will be the fastest method) > > 4) r.mapcalc outmap='if( (abs(x() - $x)) < ewres()) \ > && (abs(y() - $y) < nsres(), $val, null() )' > [or something like that, for a single point; yuk] > > 5) do the gridding yourself and create a r.in.ascii file. > > all these would need to be followed by a call to r.patch. > (see d.rast.edit.tcl method) > > >> We are coupling an agent-based simulation to GRASS, such that the >> simulated land use activities will affect land cover, which in turn >> will affect a landscape evolution routine. > > are you updating a sequential string of cells, blocks of cells, or > random cells at each update? > > >> Optimizing the speed of this is critical, and so we prefer to reduce >> the number of steps needed to accomplish this. This means that the >> r.in.poly approach is the one we prefer. However, in tests conducted >> today, we ran into an unexpected problem. >> >> If the coordinate of the point to be created happens to fall on a cell >> boundary, we get a 2-cell 'line' instead of a point even though the >> beginning and end points are identical. Apparently, r.in.poly looks >> for a cell center closest to end point one and then searches for a >> cell center for end point 2 that is different from the first cell, >> resulting in a 2 cell line. This does not happen if the point does not >> fall on a cell boundary. Attached is the raster file created from the >> following r.in.poly input. The first input creates the 2 yellow cells, >> the other 2 create the red and green single cells. > > r.in.poly/raster.c defines the "cont" continue line fn used by > G_setup_plot() (and thus all following G_plot_*() commands) with > G_bresenham_line(). That in turn uses the "dot" fn to draw the points; > which "dot" is used depends on the result of the getformat() scan of > the cat values (& I'm about foggy about what that's all about). > > for info on the Bresenham line rasterization method see: > http://en.wikipedia.org/wiki/Bresenham's_line_algorithm > > >> This is a potential problem, since an agent might not know that the >> the coordinates it chooses for a field to farm or graze like on a cell >> boundary. It is OK if r.in.poly substitutes the nearest grid cell >> center to make the raster point for the xy coordinates that the agent >> chooses, but not OK if it picks 2 different cells instead of one. > > Try r.in.xyz, it shouldn't suffer from this: on one side of the cell it > tests for <= and on the other side <. So a point on a bound always fall > in the <= cell. The exception is the outer E,W raster boundaries which > will make values fall "into" the raster if on the bound. > > r.in.xyz doesn't let you add cat labels, but you can do that manually by > creating a cats/ file. See spearfish60/PERMANENT/cats/landuse for an > example, it's very simple. > > >> The simplest solution is to allow r.in.poly to make points as well as >> lines and areas. I'm not sure why it doesn't allow points in the first >> place. It seems like an oversight. Is this difficult to implement? > > done, but I don't think it will help any due to the way G_plot_point() > works. > > >> * * * * >> >> Also, there is still no one-step way to change a cell value based on >> its xy coordinates. > > So you want a non-interactive d.rast.edit, like v.edit? > > A couple of ways to do that, 1) get input x1,y1,cat1 ... from stdin, > qsort() based on y then x, read each line and if there's an updated > cell in it replace it before writing the row back out. (as r.patch) > 2) calculate the array column,row which contains each x,y and update > each in the order they arrive (as r.in.xyz). Probably the fastest way is > a combination of the two. Sort by y, and for each row update the column > values in the order they arrive, then write out the finished line and > move on to the next row. > > >> However, if there is interest in doing agent and cellular modeling >> within a GRASS platform, it will become necessary to be able to do >> this to simulate dynamics. Patching may simply not be practical for >> this kind of work. As Python becomes more used as a scripting >> environment, this is an attractive kind of application to build in >> Python, given its object oriented structure, and couple with GRASS. > > The module probably isn't so hard to write, in C. r.example should give > a nice start. > > It would be interesting to rewrite r.example.c using the SWIG Python > interface, and see if that gains any simplicity over C, or if it just > adds complexity without simplicity -- as you still need to go through > all the same chores. > > > Hamish __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Thu Jun 14 17:13:15 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jun 14 17:13:27 2007 Subject: [GRASS-dev] Re: [GRASS-user] a suggestion for v.transform In-Reply-To: <20070614071746.ARJ82038@expms1.cites.uiuc.edu> Message-ID: On 6/14/07 5:17 AM, "Gerald Nelson" wrote: > Would it make sense to say something like "... in current coordinate space > (add parenthetical phrase about what that is)." Good idea. Michael > ---- Original message ---- >> Date: Wed, 13 Jun 2007 21:58:29 -0700 >> From: Michael Barton >> Subject: [GRASS-user] a suggestion for v.transform >> To: GRASS Support , GRASS devel >> >> >> There has been a thread about how v.transform functions and Glynn pointed >> out that part of the problem is that the short description does not really >> describe what it does, at least from a GIS perspective: >> >> " Transforms a vector map layer from one coordinate system into another >> coordinate system." >> >> I'm working on wxgrass menus at the moment and trying to come up with useful >> menu entries. A better short description for v.transform might be: >> >> "Reposition (shift and rotate) vector file in coordinate space" >> >> Thoughts? >> >> Michael >> __________________________________________ >> Michael Barton, Professor of Anthropology >> School of Human Evolution & Social Change >> Center for Social Dynamics & Complexity >> Arizona State University >> >> phone: 480-965-6213 >> fax: 480-965-7671 >> www: http://www.public.asu.edu/~cmbarton >> >> >> _______________________________________________ >> grassuser mailing list >> grassuser@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grassuser > 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 __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From dylan.beaudette at gmail.com Thu Jun 14 19:21:19 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Thu Jun 14 19:18:14 2007 Subject: [GRASS-dev] a suggestion for v.transform In-Reply-To: References: Message-ID: <200706141021.19414.dylan.beaudette@gmail.com> Indeed. I recently did some stuff with v.transform / affine transformation. perhaps I can summarize it, and include a helpful figure in the man page. http://casoilresource.lawr.ucdavis.edu/drupal/node/433 specifically the shifted grid example: http://casoilresource.lawr.ucdavis.edu/drupal/node/435 cheers, On Thursday 14 June 2007 07:40, John Gillette wrote: > v.transform: perform affine transformation (translate and rotate) a > vector file. > > See affine transformation in wikipedia. > > John > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 From cdavilam at jemila.jazztel.es Thu Jun 14 20:04:22 2007 From: cdavilam at jemila.jazztel.es (=?ISO-8859-1?Q?Carlos_D=E1vila?=) Date: Thu Jun 14 20:03:03 2007 Subject: [GRASS-dev] Message standardization In-Reply-To: <20070611180245.4b2474b4.hamish_nospam@yahoo.com> References: <466C6604.8010300@jemila.jazztel.es> <20070611180245.4b2474b4.hamish_nospam@yahoo.com> Message-ID: <46718326.6080200@jemila.jazztel.es> Hamish escribi?: > Carlos D?vila wrote: > >> I'm new in dev list, but I've been working in translations for some >> time. I would like to standardize some grass messages, according to >> what is proposed in >> http://grass.gdf-hannover.de/wiki/Development_Specs (please check >> last changes) in order to ease the work for translators and get a >> more consistent program. I don't know if standard messages proposed in >> wiki can already be used or if discussion is still open. Any feedback >> is welcome. If no objections are reported, I will start changing >> messages in the next days, at least the most obvious. >> > > > The ideas on the wiki page are just the opinions of a few of us who > edited the page AFAICT, not a full consensus reached on the -dev mailing > list which it needs to be before any mass change. So that it can be > formalized and the discussion closed, I too would ask everyone to review > what's listed there, and discuss here. There are several unresolved > questions there which need to be answered. > > At least I hope with g.message and G_*message() we have all the tools we > need now? My only gripe with G_message() is that it makes it impossible > to use whitespace formatting as it drops \n and \t and leading spaces > and compresses inline multiple spaces. But maybe that is good, as doing > that will not work well with dynamic-width fonts, ie it makes GUI output > ugly between lines, and tables should go to fprintf(stdout,..). > > > It saves more work later to get this right the first time :) and kills > motivation on all sides to have to revert changes later :( > > > Hamish > As I continue translating I find a lot messages that are affected by what is being discussed in this topic and it's a bit frustrating. I can leave messages untranslated, and so I will have to go back to them later, or I can translate them in the way proposed, with the risk of having to change them later if proposal are changed, while it would be easy for me to change messages in the moment if any agreement is reached. I would like to reduce this situation if possible, so I propose to split discussion by items listed in wiki and try to get an agreement at least in those easier. We could add votes under each item in wiki and finally take a decision and mark item as accepted. E.g.: * First letter should be capitalized +1 Carlos * Use the present tense (cannot instead of could not; *better: unable to*) +1 Carlos and so on What do you think about this? Carlos From glynn at gclements.plus.com Thu Jun 14 21:15:11 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jun 14 21:15:17 2007 Subject: [GRASS-dev] Re: [GRASS-user] a suggestion for v.transform In-Reply-To: References: Message-ID: <18033.37823.199104.235678@cerise.gclements.plus.com> Michael Barton wrote: > There has been a thread about how v.transform functions and Glynn pointed > out that part of the problem is that the short description does not really > describe what it does, at least from a GIS perspective: > > " Transforms a vector map layer from one coordinate system into another > coordinate system." > > I'm working on wxgrass menus at the moment and trying to come up with useful > menu entries. A better short description for v.transform might be: > > "Reposition (shift and rotate) vector file in coordinate space" > > Thoughts? It can also scale. -- Glynn Clements From glynn at gclements.plus.com Thu Jun 14 21:28:31 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jun 14 21:28:37 2007 Subject: [GRASS-dev] d.rast.edit in wxgrass In-Reply-To: References: <18032.2088.14862.39790@cerise.gclements.plus.com> Message-ID: <18033.38623.341392.551825@cerise.gclements.plus.com> Michael Barton wrote: > GRASS command parsing from the wxgrass CLI: > > Split the command into a list by spaces. I realize that this is a problem > for any command with spaces in the arguments, but I know of no better way to > do this in this context outside of making users type any command as a Python > list. If we made people type ['g.region', 'rast=mymap', 'res=30'] instead of > g.region rast=mymap res=30, I don't think anyone would want to use the CLI. This is one case where shell=True *is* legitimate. At least with a shell, the user can use quotes or backslashes to include spaces in arguments. Or you could implement equivalent functionality yourself. The latter is more work, but you can choose exactly which shell functionality you want, e.g. allowing spaces (and other metacharacters) without the other shell behaviour (sequences, pipelines, redirection, variables, ....). > If the command has no arguments (i.e., len(cmdlist) == 0) AND it is NOT a > d.* command, send the original command string (not the list) to the > menuform.py processor (just like the menu would) to create the autogenerated > properties dialog. After this, the result of hitting "run" is the same as if > the properties dialog were called from the menu. > > If the command has no arguments AND IS a d.* command AND is in a hard coded > list of d.* commands for which we have defined layers in the layer tree, > create a layer tree item for that command (e.g., a raster layer for d.rast). > After that, the new layer is processed in the same way as one created by > pressing a layer button on the layer manager toolbar. > > If the d.* command without arguments is NOT on the list for the layer tree, > generate get a message that it cannot be processed. > > If the command HAS arguments and is NOT a d.* command, send the command list > (i.e., made by splitting on spaces -- not the original command string) to > cmd.Command for processing. > > If the command HAS arguments and IS a d.* command, it is added to the list > of display layers managed within render.py for the map display that has the > focus and the UpdateMap method is called to update that display. There is a > 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. This all looks suspiciously like DWIM, which is normally a bad thing for non-trivial systems. > >> If it was only from the menu, then it would be easy. I don't know if this is > >> the case in menuform. I don't know exactly what is going on in this spot and > >> haven't had time yet to figure it out. > > > > The name "menuform.py" suggests that it has something to do with > > menus. In which case, what is: > > > > if cmd[0][0:2] != "d.": > > > > doing in that file (specifically, in mainFrame.OnRun())? > > I don't know. > > menuform.py parses the --interface-description xml data to create a > properties dialog. The dialog takes the results of user choices and creates > a command list for processing--ulitmately by cmd.Command. > > > Even if you are determined to use that hack for the CLI, it has no > > utility in regard to menus. > > I just don't know if it is related to the p.mon, p.rast, etc scripts or > whether it can simply be removed. As a general rule, if no-one knows why something is there, then it shouldn't be there. It's understandable if something as old as GRASS has legacy code for which the reason is unknown, but wxgrass shouldn't have reached that point already. -- Glynn Clements From glynn at gclements.plus.com Thu Jun 14 21:56:11 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Jun 14 21:56:14 2007 Subject: [GRASS-dev] GRASS and GDAL 1.4.1 MingW In-Reply-To: References: <466E770E.8070103@ufg.uni-kiel.de> <20070613115934.31c56135.hamish_nospam@yahoo.com> <46713991.1040409@ufg.uni-kiel.de> <467145AC.80505@ufg.uni-kiel.de> Message-ID: <18033.40283.738429.612130@cerise.gclements.plus.com> Paul Kelly wrote: > Although maybe > long-term we could move away from using the gdal-config command in the > configure script to get away from problems like this. I think everything > its used for should probably be able to be achieved without it. I wouldn't be so sure. GDAL can require a *lot* of other libraries (by its nature, it's a front-end to various raster data libraries), some of which might be in non-obvious locations, and may have substantial dependencies of their own. AFAICT, the only alternative is to provide a --with-gdal-ldflags= switch and require the user to specify exactly which flags are required to link against GDAL. Implementing such a switch would be straightforward; getting the average user (or developer) to figure out what value to provide would be rather less straightforward. -- Glynn Clements From michael.barton at asu.edu Thu Jun 14 22:03:01 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jun 14 22:03:08 2007 Subject: [GRASS-dev] d.rast.edit in wxgrass In-Reply-To: <18033.38623.341392.551825@cerise.gclements.plus.com> Message-ID: On 6/14/07 12:28 PM, "Glynn Clements" wrote: >>> The name "menuform.py" suggests that it has something to do with >>> menus. In which case, what is: >>> >>> if cmd[0][0:2] != "d.": >>> >>> doing in that file (specifically, in mainFrame.OnRun())? >> >> I don't know. >> >> menuform.py parses the --interface-description xml data to create a >> properties dialog. The dialog takes the results of user choices and creates >> a command list for processing--ulitmately by cmd.Command. >> >>> Even if you are determined to use that hack for the CLI, it has no >>> utility in regard to menus. >> >> I just don't know if it is related to the p.mon, p.rast, etc scripts or >> whether it can simply be removed. > > As a general rule, if no-one knows why something is there, then it > shouldn't be there. Daniel Cavelo knows. I don't. > > It's understandable if something as old as GRASS has legacy code for > which the reason is unknown, but wxgrass shouldn't have reached that > point already. Hopefully we're not creating legacy code already. It is just that, for the first time, there is an actual team working on the GUI. It is really nice, even if it means that I don't know the details of certain parts of the code. While I've done some work on the module called menuform.py, Daniel has done the greatest amount and would know what is going on here. He seems out of touch at the moment (as I will be next week). Michael __________________________________________ Michael Barton, Professor of Anthropology and Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Thu Jun 14 22:10:11 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jun 14 22:10:17 2007 Subject: [GRASS-dev] d.rast.edit in wxgrass In-Reply-To: <18033.38623.341392.551825@cerise.gclements.plus.com> Message-ID: On 6/14/07 12:28 PM, "Glynn Clements" wrote: >> If the command HAS arguments and IS a d.* command, it is added to the list >> of display layers managed within render.py for the map display that has the >> focus and the UpdateMap method is called to update that display. There is a >> 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. > > This all looks suspiciously like DWIM, which is normally a bad thing > for non-trivial systems. > I don't think it is a DWIM. The normal CLI behavior currently is... 1) type a command without arguments and it (normally) opens a properties dialog; 2) type a command with arguments and it runs the command. To run a d.* command and have it do anything useful in the wxgrass environment, it needs to be added to the list of display layers and the display updated. There is no straightforward way to choose which of multiple open display windows would show the d.* command results, so I'm simply picking the active one. This can be changed by the user by simply clicking on a different display. The added feature, which is particularly useful for running display commands is the ability to 'chain' them together so you can create a display with multiple overlaying maps. This is done here by separating d.* commands with a semicolon. I'm not sure if this is the best way to achieve this end, but it is convenient to have something along this line. Michael __________________________________________ Michael Barton, Professor of Anthropology and 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 dylan.beaudette at gmail.com Thu Jun 14 23:07:54 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Thu Jun 14 23:04:47 2007 Subject: [GRASS-dev] Re: [GRASS-user] a suggestion for v.transform In-Reply-To: <18033.37823.199104.235678@cerise.gclements.plus.com> References: <18033.37823.199104.235678@cerise.gclements.plus.com> Message-ID: <200706141407.54761.dylan.beaudette@gmail.com> On Thursday 14 June 2007 12:15, Glynn Clements wrote: > Michael Barton wrote: > > There has been a thread about how v.transform functions and Glynn pointed > > out that part of the problem is that the short description does not > > really describe what it does, at least from a GIS perspective: > > > > " Transforms a vector map layer from one coordinate system into another > > coordinate system." > > > > I'm working on wxgrass menus at the moment and trying to come up with > > useful menu entries. A better short description for v.transform might be: > > > > "Reposition (shift and rotate) vector file in coordinate space" > > > > Thoughts? > > It can also scale. ... and to be complete, it can also shear. -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 From michael.barton at asu.edu Thu Jun 14 23:43:27 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jun 14 23:43:32 2007 Subject: [GRASS-dev] question about scripting platforms Message-ID: I?m writing a paper that includes a discussion of GRASS scripting that we?re using to develop a suite of landscape evolution models. For that vast audience who are MS Windows users, I was going to say that BASH shell scripting is similar in a number of ways to using *.bat scripting in Windows. This got me to wondering if it is possible to create a GRASS script using a *.bat file for wingrass? I was also going to mention the option of using a high-level scripting language like Python, and again wonder if it is theoretically possible to also use Visual Basic to script in GRASS. Could *.bat files and VB be used with GRASS or are there technical obstacles to doing so? Michael __________________________________________ Michael Barton, Professor of Anthropology and Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070614/9e3c536f/attachment.html From michael.barton at asu.edu Thu Jun 14 23:49:04 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jun 14 23:49:10 2007 Subject: [GRASS-dev] d.rast.edit in wxgrass In-Reply-To: <18033.38623.341392.551825@cerise.gclements.plus.com> Message-ID: On 6/14/07 12:28 PM, "Glynn Clements" wrote: >> GRASS command parsing from the wxgrass CLI: >> >> Split the command into a list by spaces. I realize that this is a problem >> for any command with spaces in the arguments, but I know of no better way to >> do this in this context outside of making users type any command as a Python >> list. If we made people type ['g.region', 'rast=mymap', 'res=30'] instead of >> g.region rast=mymap res=30, I don't think anyone would want to use the CLI. > > This is one case where shell=True *is* legitimate. At least with a > shell, the user can use quotes or backslashes to include spaces in > arguments. Or you could implement equivalent functionality yourself. IIUC, if I keep these as strings, I don't think I can use the cmd.Command class and would have to do a custom version of Popen. Then I'd have to send them through a different processing path rather than the RunCmd method that everything else uses. Michael > > The latter is more work, but you can choose exactly which shell > functionality you want, e.g. allowing spaces (and other > metacharacters) without the other shell behaviour (sequences, > pipelines, redirection, variables, ....). __________________________________________ Michael Barton, Professor of Anthropology and 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 paul-grass at stjohnspoint.co.uk Fri Jun 15 02:17:49 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Fri Jun 15 02:17:51 2007 Subject: [GRASS-dev] d.extend in gui In-Reply-To: <20070610202514.27c1d140.hamish_nospam@yahoo.com> References: <18025.22280.219107.869953@cerise.gclements.plus.com> <20070610202514.27c1d140.hamish_nospam@yahoo.com> Message-ID: On Sun, 10 Jun 2007, Hamish wrote: > The mention of -d reminds me that g.region (or anything else) still > lacks a way to reset the DEFAULT_WIND region. When creating new location > from EPSG code the default region is just set to 0,1,0,1 IIRC. I'm not > sure what happens if you create a new location from a datafile with > r.in.gdal/v.in.ogr. Hopefully it sets the default region to match that > map's region, but I'm not sure if it does or not. It does. See set_gdal_region() and set_ogr_region() in general/g.proj/input.c, which are clones of the relevant code from r.in.gdal and v.in.ogr. Guessing at the resolution to use when we only have a vector map to work on is still a problem though. The case with EPSG code could be made less harsh by popping up a window with the pre-selected values and asking the user to verify them as part of the location creation process. I.e. run g.proj and let it save its default region data, then read the region back in with g.region, ask the user to verify it and save it back with the g.region -s flag. I've mentioned this before but I really think there should be a GUI region setting widget with all the functionality of the old interactive curses-based g.region. Someone was complaining recently that there should be a quick resolution adjust facility in the GUI monitor displays - I think that would be a hack but a button to access the interactive region setting widget, with further buttons there to save the region as the active display region or the mapset working region etc. would be very useful IMHO. Paul From michael.barton at asu.edu Fri Jun 15 09:08:37 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jun 15 09:08:55 2007 Subject: [GRASS-dev] raster point creation problem solved Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: impacts4.png Type: application/octet-stream Size: 6188 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070615/06abac3e/impacts4.obj From michael.barton at asu.edu Fri Jun 15 10:07:33 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jun 15 10:07:46 2007 Subject: [GRASS-dev] wxgrass ready for testing Message-ID: The new wxPython GRASS interface (AKA wxgrass) is pretty much equal in functionality to the standard TclTk interface, and so is ready for regular testing. All items from the TclTk menus are on the wxPython menus. There are a couple of caveats. There is not yet a comprehensive georectifying module like there is for TclTk The location setting wizard is not yet functional, meaning that you can't define projections using g.setproj. You will still need TclTk for NVIZ, v.digit, and d.rast.edit. There are also some enhancements over the TclTk interface, including: a prototype attribute data manager (works for interactive mouse queries) more sophisticated profile analysis module full command line access to all GRASS commands; d.* commands called from the command line can display in the wxPython canvas. easily positioned scalebar and legend A more compact (and aesthetic) appearance You can get wxgrass from the GRASS subversion repository at... Download the entire GUI tarball and follow the easy installation instructions. enjoy Michael PS: I'll be gone after tomorrow for a week. __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070615/ef874327/attachment.html From cavallini at faunalia.it Fri Jun 15 11:49:39 2007 From: cavallini at faunalia.it (Paolo Cavallini) Date: Fri Jun 15 11:49:51 2007 Subject: [GRASS-dev] wxgrass ready for testing In-Reply-To: References: Message-ID: <467260B3.4070505@faunalia.it> Pity wxPython is not yet in debian, which makes testing more complicated for me. All the best. pc Michael Barton ha scritto: > You can get wxgrass from the GRASS subversion repository at... > > Download the entire GUI tarball and follow the easy installation > instructions. -- 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/20070615/c4996d69/signature-0001.bin From mlennert at club.worldonline.be Fri Jun 15 14:06:22 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Jun 15 14:02:33 2007 Subject: [GRASS-dev] GRASS and GDAL 1.4.1 MingW In-Reply-To: <466E770E.8070103@ufg.uni-kiel.de> References: <466E770E.8070103@ufg.uni-kiel.de> Message-ID: <467280BE.5040507@club.worldonline.be> On 12/06/07 12:35, Benjamin Ducke wrote: > Hi all, > > concerning the troubles with the DBF driver under Win32 that I wrote > about earlier, I am trying to compile a current version of GRASS > with MingW. Just out of curiosity: any reason you do not wish to use the precompiled version available at: http://moritz.homelinux.org/grass/wingrass/ I try to be more or less regular in providing packages based on the latest CVS (although the latest one is ten days old...I'll put up a new one tonight or tomorrow). Moritz From benjamin.ducke at ufg.uni-kiel.de Fri Jun 15 14:08:56 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Fri Jun 15 14:09:57 2007 Subject: [GRASS-dev] GRASS and GDAL 1.4.1 MingW In-Reply-To: <467280BE.5040507@club.worldonline.be> References: <466E770E.8070103@ufg.uni-kiel.de> <467280BE.5040507@club.worldonline.be> Message-ID: <46728158.1010006@ufg.uni-kiel.de> Two reasons: a) I want to be sure that I understand all details involved in the compile process under MingW b) I have a lot of custom code that I need to merge into the current CVS tree and compile along with it, as GEM does not yet run w/o problems with the MSYS based version of GRASS ... my ultimate goal is to create a version of the current CVS of GRASS 6.3 for use in archaeology. This will include all the additional modules I have written for GRASS over the years. But I will also keep testing your CVS packages as time allows. Benjamin Moritz Lennert wrote: > On 12/06/07 12:35, Benjamin Ducke wrote: >> Hi all, >> >> concerning the troubles with the DBF driver under Win32 that I wrote >> about earlier, I am trying to compile a current version of GRASS >> with MingW. > > > Just out of curiosity: any reason you do not wish to use the precompiled > version available at: > > http://moritz.homelinux.org/grass/wingrass/ > > I try to be more or less regular in providing packages based on the > latest CVS (although the latest one is ten days old...I'll put up a new > one tonight or tomorrow). > > Moritz > > -- 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 gnelson at uiuc.edu Fri Jun 15 14:21:22 2007 From: gnelson at uiuc.edu (Gerald Nelson) Date: Fri Jun 15 14:21:26 2007 Subject: [GRASS-dev] GRASS and GDAL 1.4.1 MingW Message-ID: <20070615072122.ARL40190@expms1.cites.uiuc.edu> Any reason not to add your archeology modules to the set of grass addons? ---- Original message ---- >Date: Fri, 15 Jun 2007 14:08:56 +0200 >From: Benjamin Ducke >Subject: Re: [GRASS-dev] GRASS and GDAL 1.4.1 MingW >Cc: GRASS devel > >Two reasons: > >a) I want to be sure that I understand all details involved in the >compile process under MingW >b) I have a lot of custom code that I need to merge into the current >CVS tree and compile along with it, as GEM does not yet run w/o problems >with the MSYS based version of GRASS > >... my ultimate goal is to create a version of the current CVS of GRASS >6.3 for use in archaeology. This will include all the additional modules >I have written for GRASS over the years. > >But I will also keep testing your CVS packages as time allows. > >Benjamin > >Moritz Lennert wrote: >> On 12/06/07 12:35, Benjamin Ducke wrote: >>> Hi all, >>> >>> concerning the troubles with the DBF driver under Win32 that I wrote >>> about earlier, I am trying to compile a current version of GRASS >>> with MingW. >> >> >> Just out of curiosity: any reason you do not wish to use the precompiled >> version available at: >> >> http://moritz.homelinux.org/grass/wingrass/ >> >> I try to be more or less regular in providing packages based on the >> latest CVS (although the latest one is ten days old...I'll put up a new >> one tonight or tomorrow). >> >> Moritz >> >> > >-- >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 From Agustin.Diez at uv.es Fri Jun 15 14:28:08 2007 From: Agustin.Diez at uv.es (Agustin Diez Castillo) Date: Fri Jun 15 14:30:07 2007 Subject: [GRASS-dev] wxgrass ready for testing In-Reply-To: References: Message-ID: <76B019E9-E856-494A-9588-D810F2120732@uv.es> Michael, Do I miss a workspace menu? Is possible to read old .grc files? Agustin On Jun 15, 2007, at 10:07 AM, Michael Barton wrote: > The new wxPython GRASS interface (AKA wxgrass) is pretty much > equal in functionality to the standard TclTk interface, and so is > ready for regular testing. All items from the TclTk menus are on > the wxPython menus. There are a couple of caveats. > > There is not yet a comprehensive georectifying module like there is > for TclTk > The location setting wizard is not yet functional, meaning that you > can't define projections using g.setproj. > You will still need TclTk for NVIZ, v.digit, and d.rast.edit. > > There are also some enhancements over the TclTk interface, including: > a prototype attribute data manager (works for interactive mouse > queries) > more sophisticated profile analysis module > full command line access to all GRASS commands; d.* commands called > from the command line can display in the wxPython canvas. > easily positioned scalebar and legend > A more compact (and aesthetic) appearance > > You can get wxgrass from the GRASS subversion repository at... > > Download the entire GUI tarball and follow the easy installation > instructions. > > enjoy > Michael > > PS: I'll be gone after tomorrow for a week. > > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > _______________________________________________ > 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/20070615/b39069a6/attachment.html From benjamin.ducke at ufg.uni-kiel.de Fri Jun 15 14:32:41 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Fri Jun 15 14:33:39 2007 Subject: [GRASS-dev] GRASS and GDAL 1.4.1 MingW In-Reply-To: <20070615072122.ARL40190@expms1.cites.uiuc.edu> References: <20070615072122.ARL40190@expms1.cites.uiuc.edu> Message-ID: <467286E9.9060407@ufg.uni-kiel.de> It's pretty complex code with additional external dependencies and most of my archaeological colleagues simply don't have the technical know how to get it running from a source repository. This was the original reason why I created GEM which now comes with the current GRASS in CVS. Since I don't have the time to maintain my code in several repositories, I will maintain it only in GEM packages. In the near future, I want to make these work on MingW, as well, but for now I need a quicker solution because I want to use the software in a class this semester. Gerald Nelson wrote: > Any reason not to add your archeology modules to the set of grass addons? > > ---- Original message ---- >> Date: Fri, 15 Jun 2007 14:08:56 +0200 >> From: Benjamin Ducke >> Subject: Re: [GRASS-dev] GRASS and GDAL 1.4.1 MingW >> Cc: GRASS devel >> >> Two reasons: >> >> a) I want to be sure that I understand all details involved in the >> compile process under MingW >> b) I have a lot of custom code that I need to merge into the current >> CVS tree and compile along with it, as GEM does not yet run w/o problems >> with the MSYS based version of GRASS >> >> ... my ultimate goal is to create a version of the current CVS of GRASS >> 6.3 for use in archaeology. This will include all the additional modules >> I have written for GRASS over the years. >> >> But I will also keep testing your CVS packages as time allows. >> >> Benjamin >> >> Moritz Lennert wrote: >>> On 12/06/07 12:35, Benjamin Ducke wrote: >>>> Hi all, >>>> >>>> concerning the troubles with the DBF driver under Win32 that I wrote >>>> about earlier, I am trying to compile a current version of GRASS >>>> with MingW. >>> >>> Just out of curiosity: any reason you do not wish to use the precompiled >>> version available at: >>> >>> http://moritz.homelinux.org/grass/wingrass/ >>> >>> I try to be more or less regular in providing packages based on the >>> latest CVS (although the latest one is ten days old...I'll put up a new >>> one tonight or tomorrow). >>> >>> Moritz >>> >>> >> -- >> 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 mlennert at club.worldonline.be Fri Jun 15 14:52:51 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Jun 15 14:49:00 2007 Subject: [GRASS-dev] wxgrass ready for testing In-Reply-To: <467260B3.4070505@faunalia.it> References: <467260B3.4070505@faunalia.it> Message-ID: <46728BA3.7060802@club.worldonline.be> On 15/06/07 11:49, Paolo Cavallini wrote: > Pity wxPython is not yet in debian, which makes testing more complicated > for me. For me the ubuntu versions worked without a problem: http://wxpython.wxcommunity.com/apt/ubuntu/ (For my testing/unstable box, I use: deb http://wxpython.wxcommunity.com/apt/ubuntu/dapper / in my /etc/apt/sources.list Moritz From woklist at kyngchaos.com Fri Jun 15 15:52:22 2007 From: woklist at kyngchaos.com (woklist@kyngchaos.com) Date: Fri Jun 15 15:52:28 2007 Subject: [GRASS-dev] Re: [GRASSGUI] wxgrass ready for testing In-Reply-To: References: Message-ID: <49734.24.159.243.19.1181915542.squirrel@webmail.kyngchaos.com> > The new wxPython GRASS interface (AKA wxgrass) is pretty much equal in > functionality to the standard TclTk interface, and so is ready for regular > testing. All items from the TclTk menus are on the wxPython menus. There > are > a couple of caveats. Have you decided on a format for addon menu files? I didn't see with a quick look that it loads any menu files yet. I would like to get an automated menu builder into the OSX startup so I can have GUI access to addons in the standard OSX addon dirs. I won't be able to get to that for a few days, though - MacBook is in the shop - so I can wait until you get back from your break/vacation/trip/whatever. From Agustin.Diez at uv.es Fri Jun 15 16:32:34 2007 From: Agustin.Diez at uv.es (Agustin Diez Castillo) Date: Fri Jun 15 16:34:31 2007 Subject: [GRASS-dev] Mac binary Message-ID: I got a tcltk error with both 6.3 cvs, my last compilation and your 30 may installer. Same happens with 6.2 Application initialization failed: couldn't connect to display ":0.0" Error in startup script: couldn't connect to display ":0.0" while executing "load /Applications/GRASS-6.3.app/Contents/Resources/lib/tk8.4/../ libtk8.4.dylib Tk" ("package ifneeded" script) invoked from within "package require Tk 8.0" ("package ifneeded" script) invoked from within "package require -exact BWidget 1.2.1" (file "/Applications/GRASS-6.3.app/Contents/Resources/etc/dm/ d.m.tcl" line 23) [1]+ Exit 1 d.m Machine Name: iMac Machine Model: iMac5,1 Processor Name: Intel Core 2 Duo Processor Speed: 2 GHz Number Of Processors: 1 Total Number Of Cores: 2 L2 Cache (per processor): 4 MB Memory: 2 GB Bus Speed: 667 MHz Boot ROM Version: IM51.0090.B03 SMC Version: 1.8f2 __________________________________________________________ Dr. Agust?n Diez Castillo Departament de Prehist?ria i Arqueologia Fundaci? General Universitat de Val?ncia Phone: +34 963 98 38 93 Avda. Blasco Iba?ez, 28 Fax: +34 963 98 38 87 Val?ncia 46010 http://www.uv.es/sidgeipa Member of the European Network of Excellence EPOCH http://www.epoch.eu/ __________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070615/bc224504/attachment-0001.html From jachym.cepicky at gmail.com Fri Jun 15 17:17:43 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Fri Jun 15 17:17:50 2007 Subject: [GRASS-dev] Re: [GRASSGUI] wxgrass ready for testing In-Reply-To: References: Message-ID: <1181920663.7928.3.camel@mellon> Hi Michael, great work! I posted some blogposts about wxGRASS at my blog [1],[2] and I do continue to write about it more. I would also mention new attribute table manager (also not yet fully functional) :-) Have a nice holiday Jachym [1] http://www.les-ejk.cz/english/wxgrass-new-grass-gui-1 [2] http://www.les-ejk.cz/english/wxgrass-new-grass-gui-2 Michael Barton p??e v P? 15. 06. 2007 v 01:07 -0700: > The new wxPython GRASS interface (AKA wxgrass) is pretty much equal > in functionality to the standard TclTk interface, and so is ready for > regular testing. All items from the TclTk menus are on the wxPython > menus. There are a couple of caveats. > > There is not yet a comprehensive georectifying module like there is > for TclTk > The location setting wizard is not yet functional, meaning that you > can't define projections using g.setproj. > You will still need TclTk for NVIZ, v.digit, and d.rast.edit. > > There are also some enhancements over the TclTk interface, including: > a prototype attribute data manager (works for interactive mouse > queries) > more sophisticated profile analysis module > full command line access to all GRASS commands; d.* commands called > from the command line can display in the wxPython canvas. > easily positioned scalebar and legend > A more compact (and aesthetic) appearance > > You can get wxgrass from the GRASS subversion repository at... > > Download the entire GUI tarball and follow the easy installation > instructions. > > enjoy > Michael > > PS: I'll be gone after tomorrow for a week. > > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > _______________________________________________ > grassgui mailing list > grassgui@grass.itc.it > http://grass.itc.it/mailman/listinfo/grassgui -- Jachym Cepicky e-mail: jachym.cepicky@gmail.com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?= =?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?= =?ISO-8859-1?Q?_zpr=E1vy?= Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070615/fc03b361/attachment.bin From michael.barton at asu.edu Fri Jun 15 17:37:34 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jun 15 17:38:00 2007 Subject: [GRASS-dev] wxgrass ready for testing In-Reply-To: <76B019E9-E856-494A-9588-D810F2120732@uv.es> Message-ID: There is no workspace menu yet. Old .grc files cannot be read (yet). Michael On 6/15/07 5:28 AM, "Agustin Diez Castillo" wrote: > Michael, > Do I miss a workspace menu? Is possible to read old .grc files? > Agustin > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070615/aacfbb0e/attachment.html From michael.barton at asu.edu Fri Jun 15 17:38:31 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jun 15 17:38:45 2007 Subject: [GRASS-dev] Re: [GRASSGUI] wxgrass ready for testing In-Reply-To: <49734.24.159.243.19.1181915542.squirrel@webmail.kyngchaos.com> Message-ID: No decisions on that yet. Just getting the basics up and running. I'm gone for a week. Cheers Michael On 6/15/07 6:52 AM, "woklist@kyngchaos.com" wrote: >> The new wxPython GRASS interface (AKA wxgrass) is pretty much equal in >> functionality to the standard TclTk interface, and so is ready for regular >> testing. All items from the TclTk menus are on the wxPython menus. There >> are >> a couple of caveats. > > Have you decided on a format for addon menu files? I didn't see with a > quick look that it loads any menu files yet. I would like to get an > automated menu builder into the OSX startup so I can have GUI access to > addons in the standard OSX addon dirs. > > I won't be able to get to that for a few days, though - MacBook is in the > shop - so I can wait until you get back from your > break/vacation/trip/whatever. > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Fri Jun 15 17:40:06 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jun 15 17:40:19 2007 Subject: [GRASS-dev] Re: [GRASSGUI] wxgrass ready for testing In-Reply-To: <1181920663.7928.3.camel@mellon> Message-ID: On 6/15/07 8:17 AM, "Jachym Cepicky" wrote: > Hi Michael, > > great work! I posted some blogposts about wxGRASS at my blog [1],[2] and > I do continue to write about it more. > > I would also mention new attribute table manager (also not yet fully > functional) :-) I did (see below "attribute data manager"). It's very nice and quite promising. > > Have a nice holiday > > Jachym > > [1] http://www.les-ejk.cz/english/wxgrass-new-grass-gui-1 > [2] http://www.les-ejk.cz/english/wxgrass-new-grass-gui-2 > > Michael Barton p??e v P? 15. 06. 2007 v 01:07 -0700: >> The new wxPython GRASS interface (AKA wxgrass) is pretty much equal >> in functionality to the standard TclTk interface, and so is ready for >> regular testing. All items from the TclTk menus are on the wxPython >> menus. There are a couple of caveats. >> >> There is not yet a comprehensive georectifying module like there is >> for TclTk >> The location setting wizard is not yet functional, meaning that you >> can't define projections using g.setproj. >> You will still need TclTk for NVIZ, v.digit, and d.rast.edit. >> >> There are also some enhancements over the TclTk interface, including: >> a prototype attribute data manager (works for interactive mouse >> queries) >> more sophisticated profile analysis module >> full command line access to all GRASS commands; d.* commands called >> from the command line can display in the wxPython canvas. >> easily positioned scalebar and legend >> A more compact (and aesthetic) appearance >> >> You can get wxgrass from the GRASS subversion repository at... >> >> Download the entire GUI tarball and follow the easy installation >> instructions. >> >> enjoy >> Michael >> >> PS: I'll be gone after tomorrow for a week. >> >> __________________________________________ >> Michael Barton, Professor of Anthropology >> School of Human Evolution & Social Change >> Center for Social Dynamics & Complexity >> Arizona State University >> >> phone: 480-965-6213 >> fax: 480-965-7671 >> www: http://www.public.asu.edu/~cmbarton >> >> _______________________________________________ >> grassgui mailing list >> grassgui@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grassgui __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From dylan.beaudette at gmail.com Fri Jun 15 18:04:40 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Fri Jun 15 18:04:43 2007 Subject: [GRASS-dev] Re: [GRASSGUI] wxgrass ready for testing In-Reply-To: References: <1181920663.7928.3.camel@mellon> Message-ID: <3c5546140706150904j3b9f448maac4ab4043b4077b@mail.gmail.com> Strange... on Debian/Unstable I get this: Traceback (most recent call last): File "/usr/local/grass-6.3.cvs/etc/wx/wxgui.py", line 34, in ? import wx.aui ImportError: No module named aui I wonder if my wxWindows it too old? libwxbase2.6-0 libwxbase2.6-dev libwxgtk2.4-1 libwxgtk2.6-0 libwxgtk2.6-dev python-wxgtk2.4 python-wxgtk2.6 python-wxtools python-wxversion wx2.6-headers any tips on which packages I might be missing on Debian/unstable? It seems that I have a 'wx' module available in python 2.4, but not 'wx.aui' . cheers, dylan On 6/15/07, Michael Barton wrote: > > > > On 6/15/07 8:17 AM, "Jachym Cepicky" wrote: > > > Hi Michael, > > > > great work! I posted some blogposts about wxGRASS at my blog [1],[2] and > > I do continue to write about it more. > > > > I would also mention new attribute table manager (also not yet fully > > functional) :-) > > I did (see below "attribute data manager"). It's very nice and quite > promising. > > > > > Have a nice holiday > > > > Jachym > > > > [1] http://www.les-ejk.cz/english/wxgrass-new-grass-gui-1 > > [2] http://www.les-ejk.cz/english/wxgrass-new-grass-gui-2 > > > > Michael Barton p??e v P? 15. 06. 2007 v 01:07 -0700: > >> The new wxPython GRASS interface (AKA wxgrass) is pretty much equal > >> in functionality to the standard TclTk interface, and so is ready for > >> regular testing. All items from the TclTk menus are on the wxPython > >> menus. There are a couple of caveats. > >> > >> There is not yet a comprehensive georectifying module like there is > >> for TclTk > >> The location setting wizard is not yet functional, meaning that you > >> can't define projections using g.setproj. > >> You will still need TclTk for NVIZ, v.digit, and d.rast.edit. > >> > >> There are also some enhancements over the TclTk interface, including: > >> a prototype attribute data manager (works for interactive mouse > >> queries) > >> more sophisticated profile analysis module > >> full command line access to all GRASS commands; d.* commands called > >> from the command line can display in the wxPython canvas. > >> easily positioned scalebar and legend > >> A more compact (and aesthetic) appearance > >> > >> You can get wxgrass from the GRASS subversion repository at... > >> > >> Download the entire GUI tarball and follow the easy installation > >> instructions. > >> > >> enjoy > >> Michael > >> > >> PS: I'll be gone after tomorrow for a week. > >> > >> __________________________________________ > >> Michael Barton, Professor of Anthropology > >> School of Human Evolution & Social Change > >> Center for Social Dynamics & Complexity > >> Arizona State University > >> > >> phone: 480-965-6213 > >> fax: 480-965-7671 > >> www: http://www.public.asu.edu/~cmbarton > >> > >> _______________________________________________ > >> grassgui mailing list > >> grassgui@grass.itc.it > >> http://grass.itc.it/mailman/listinfo/grassgui > > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From glynn at gclements.plus.com Fri Jun 15 18:09:02 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jun 15 18:09:06 2007 Subject: [GRASSGUI] Re: [GRASS-dev] d.rast.edit in wxgrass In-Reply-To: References: <18033.38623.341392.551825@cerise.gclements.plus.com> Message-ID: <18034.47518.676630.186522@cerise.gclements.plus.com> Michael Barton wrote: > >> GRASS command parsing from the wxgrass CLI: > >> > >> Split the command into a list by spaces. I realize that this is a problem > >> for any command with spaces in the arguments, but I know of no better way to > >> do this in this context outside of making users type any command as a Python > >> list. If we made people type ['g.region', 'rast=mymap', 'res=30'] instead of > >> g.region rast=mymap res=30, I don't think anyone would want to use the CLI. > > > > This is one case where shell=True *is* legitimate. At least with a > > shell, the user can use quotes or backslashes to include spaces in > > arguments. Or you could implement equivalent functionality yourself. > > IIUC, if I keep these as strings, I don't think I can use the cmd.Command > class and would have to do a custom version of Popen. Then I'd have to send > them through a different processing path rather than the RunCmd method that > everything else uses. One option is to call the shell explicitly, i.e.: cmd.Command(['/bin/sh', '-c', cmdstr], ....) or (on Windows): cmd.Command(['cmd', '/c', cmdstr], ...) Simply adding quoting to the existing implementation would probably be preferable, though. -- Glynn Clements From glynn at gclements.plus.com Fri Jun 15 18:12:28 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jun 15 18:12:32 2007 Subject: [GRASS-dev] Re: [GRASS-user] a suggestion for v.transform In-Reply-To: <200706141407.54761.dylan.beaudette@gmail.com> References: <18033.37823.199104.235678@cerise.gclements.plus.com> <200706141407.54761.dylan.beaudette@gmail.com> Message-ID: <18034.47724.136903.125519@cerise.gclements.plus.com> Dylan Beaudette wrote: > > > There has been a thread about how v.transform functions and Glynn pointed > > > out that part of the problem is that the short description does not > > > really describe what it does, at least from a GIS perspective: > > > > > > " Transforms a vector map layer from one coordinate system into another > > > coordinate system." > > > > > > I'm working on wxgrass menus at the moment and trying to come up with > > > useful menu entries. A better short description for v.transform might be: > > > > > > "Reposition (shift and rotate) vector file in coordinate space" > > > > > > Thoughts? > > > > It can also scale. > > ... and to be complete, it can also shear. Only when using the pointsfile= option; there isn't any direct way to specify a transformation which includes shear. -- Glynn Clements From dylan.beaudette at gmail.com Fri Jun 15 18:17:52 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Fri Jun 15 18:17:55 2007 Subject: [GRASS-dev] Re: [GRASS-user] a suggestion for v.transform In-Reply-To: <18034.47724.136903.125519@cerise.gclements.plus.com> References: <18033.37823.199104.235678@cerise.gclements.plus.com> <200706141407.54761.dylan.beaudette@gmail.com> <18034.47724.136903.125519@cerise.gclements.plus.com> Message-ID: <3c5546140706150917n5007947atba9856d8d4c271e9@mail.gmail.com> On 6/15/07, Glynn Clements wrote: > > Dylan Beaudette wrote: > > > > > There has been a thread about how v.transform functions and Glynn pointed > > > > out that part of the problem is that the short description does not > > > > really describe what it does, at least from a GIS perspective: > > > > > > > > " Transforms a vector map layer from one coordinate system into another > > > > coordinate system." > > > > > > > > I'm working on wxgrass menus at the moment and trying to come up with > > > > useful menu entries. A better short description for v.transform might be: > > > > > > > > "Reposition (shift and rotate) vector file in coordinate space" > > > > > > > > Thoughts? > > > > > > It can also scale. > > > > ... and to be complete, it can also shear. > > Only when using the pointsfile= option; there isn't any direct way to > specify a transformation which includes shear. > Yes, good (point) . It would be an interesting add-on, to manually specify the components of the affine transformation matrix. perhaps in addition to the existing manual adjustments. Maybe I will have a try at this. cheers, dylan From tutey at o2.pl Fri Jun 15 18:18:54 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Fri Jun 15 18:18:57 2007 Subject: [GRASS-dev] wxgrass ready for testing In-Reply-To: References: Message-ID: <4672BBEE.5030703@o2.pl> Michael Barton wrote: > full command line access to all GRASS commands; d.* commands called from the > command line can display in the wxPython canvas. This is great. I was missing such functionality for gis.m's map canvas. Maciek From mlennert at club.worldonline.be Fri Jun 15 18:25:01 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Jun 15 18:21:10 2007 Subject: [GRASS-dev] Re: [GRASSGUI] wxgrass ready for testing In-Reply-To: <3c5546140706150904j3b9f448maac4ab4043b4077b@mail.gmail.com> References: <1181920663.7928.3.camel@mellon> <3c5546140706150904j3b9f448maac4ab4043b4077b@mail.gmail.com> Message-ID: <1628.164.15.134.65.1181924701.squirrel@geog-pc40.ulb.ac.be> On Fri, June 15, 2007 18:04, Dylan Beaudette wrote: > Strange... on Debian/Unstable I get this: > > Traceback (most recent call last): > File "/usr/local/grass-6.3.cvs/etc/wx/wxgui.py", line 34, in ? > import wx.aui > ImportError: No module named aui > > > I wonder if my wxWindows it too old? > > libwxbase2.6-0 > libwxbase2.6-dev > libwxgtk2.4-1 > libwxgtk2.6-0 > libwxgtk2.6-dev > python-wxgtk2.4 > python-wxgtk2.6 > python-wxtools > python-wxversion > wx2.6-headers > > > any tips on which packages I might be missing on Debian/unstable? It > seems that I have a 'wx' module available in python 2.4, but not > 'wx.aui' . Try adding deb http://wxpython.wxcommunity.com/apt/ubuntu/dapper / to your sources.list and install libwxgtk2.8-0 libwxbase2.8-0 python-wxgtk2.8 Moritz From jachym.cepicky at gmail.com Fri Jun 15 18:21:17 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Fri Jun 15 18:21:21 2007 Subject: [GRASS-dev] Re: [GRASSGUI] wxgrass ready for testing In-Reply-To: <3c5546140706150904j3b9f448maac4ab4043b4077b@mail.gmail.com> References: <1181920663.7928.3.camel@mellon> <3c5546140706150904j3b9f448maac4ab4043b4077b@mail.gmail.com> Message-ID: <1181924477.7928.5.camel@mellon> You need wxWidgets 2.8.x jachym Dylan Beaudette p??e v P? 15. 06. 2007 v 09:04 -0700: > Strange... on Debian/Unstable I get this: > > Traceback (most recent call last): > File "/usr/local/grass-6.3.cvs/etc/wx/wxgui.py", line 34, in ? > import wx.aui > ImportError: No module named aui > > > I wonder if my wxWindows it too old? > > libwxbase2.6-0 > libwxbase2.6-dev > libwxgtk2.4-1 > libwxgtk2.6-0 > libwxgtk2.6-dev > python-wxgtk2.4 > python-wxgtk2.6 > python-wxtools > python-wxversion > wx2.6-headers > > > any tips on which packages I might be missing on Debian/unstable? It > seems that I have a 'wx' module available in python 2.4, but not > 'wx.aui' . > > cheers, > > dylan > > > > > On 6/15/07, Michael Barton wrote: > > > > > > > > On 6/15/07 8:17 AM, "Jachym Cepicky" wrote: > > > > > Hi Michael, > > > > > > great work! I posted some blogposts about wxGRASS at my blog [1],[2] and > > > I do continue to write about it more. > > > > > > I would also mention new attribute table manager (also not yet fully > > > functional) :-) > > > > I did (see below "attribute data manager"). It's very nice and quite > > promising. > > > > > > > > Have a nice holiday > > > > > > Jachym > > > > > > [1] http://www.les-ejk.cz/english/wxgrass-new-grass-gui-1 > > > [2] http://www.les-ejk.cz/english/wxgrass-new-grass-gui-2 > > > > > > Michael Barton p??e v P? 15. 06. 2007 v 01:07 -0700: > > >> The new wxPython GRASS interface (AKA wxgrass) is pretty much equal > > >> in functionality to the standard TclTk interface, and so is ready for > > >> regular testing. All items from the TclTk menus are on the wxPython > > >> menus. There are a couple of caveats. > > >> > > >> There is not yet a comprehensive georectifying module like there is > > >> for TclTk > > >> The location setting wizard is not yet functional, meaning that you > > >> can't define projections using g.setproj. > > >> You will still need TclTk for NVIZ, v.digit, and d.rast.edit. > > >> > > >> There are also some enhancements over the TclTk interface, including: > > >> a prototype attribute data manager (works for interactive mouse > > >> queries) > > >> more sophisticated profile analysis module > > >> full command line access to all GRASS commands; d.* commands called > > >> from the command line can display in the wxPython canvas. > > >> easily positioned scalebar and legend > > >> A more compact (and aesthetic) appearance > > >> > > >> You can get wxgrass from the GRASS subversion repository at... > > >> > > >> Download the entire GUI tarball and follow the easy installation > > >> instructions. > > >> > > >> enjoy > > >> Michael > > >> > > >> PS: I'll be gone after tomorrow for a week. > > >> > > >> __________________________________________ > > >> Michael Barton, Professor of Anthropology > > >> School of Human Evolution & Social Change > > >> Center for Social Dynamics & Complexity > > >> Arizona State University > > >> > > >> phone: 480-965-6213 > > >> fax: 480-965-7671 > > >> www: http://www.public.asu.edu/~cmbarton > > >> > > >> _______________________________________________ > > >> grassgui mailing list > > >> grassgui@grass.itc.it > > >> http://grass.itc.it/mailman/listinfo/grassgui > > > > __________________________________________ > > Michael Barton, Professor of Anthropology > > School of Human Evolution & Social Change > > Center for Social Dynamics & Complexity > > Arizona State University > > > > phone: 480-965-6213 > > fax: 480-965-7671 > > www: http://www.public.asu.edu/~cmbarton > > > > > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev > > -- Jachym Cepicky e-mail: jachym.cepicky@gmail.com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?= =?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?= =?ISO-8859-1?Q?_zpr=E1vy?= Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070615/cfbec0d2/attachment.bin From glynn at gclements.plus.com Fri Jun 15 18:21:31 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jun 15 18:21:35 2007 Subject: [GRASS-dev] d.rast.edit in wxgrass In-Reply-To: References: <18033.38623.341392.551825@cerise.gclements.plus.com> Message-ID: <18034.48267.279976.431020@cerise.gclements.plus.com> Michael Barton wrote: > >> If the command HAS arguments and IS a d.* command, it is added to the list > >> of display layers managed within render.py for the map display that has the > >> focus and the UpdateMap method is called to update that display. There is a > >> 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. > > > > This all looks suspiciously like DWIM, which is normally a bad thing > > for non-trivial systems. > > > > I don't think it is a DWIM. The normal CLI behavior currently is... > > 1) type a command without arguments and it (normally) opens a properties > dialog; > > 2) type a command with arguments and it runs the command. To run a d.* > command and have it do anything useful in the wxgrass environment, it needs > to be added to the list of display layers and the display updated. Not all d.* commands generate graphics. Admittedly, most of the ones which don't are only useful with a standalone monitor. I don't know whether there are any other exceptions apart from d.rast.edit (technically, the original v.digit should have had a d.* prefix, e.g. d.vect.edit, but it doesn't). For the d.* hack to work, we will need to adopt (and enforce) a rule that the d.* prefix is reserved solely for commands which generate graphics. That will become more practical in 7.x, as the display "management" commands (d.mon, d.save, d.info etc) will no longer be relevant once standalone monitors cease to exist. -- Glynn Clements From dylan.beaudette at gmail.com Fri Jun 15 18:42:51 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Fri Jun 15 18:43:03 2007 Subject: [GRASS-dev] Re: [GRASSGUI] wxgrass ready for testing In-Reply-To: <1181924477.7928.5.camel@mellon> References: <1181920663.7928.3.camel@mellon> <3c5546140706150904j3b9f448maac4ab4043b4077b@mail.gmail.com> <1181924477.7928.5.camel@mellon> Message-ID: <3c5546140706150942p79d1649w7e82c065f65f0936@mail.gmail.com> That did it! Great job! Dylan On 6/15/07, Jachym Cepicky wrote: > You need wxWidgets 2.8.x > > jachym > > Dylan Beaudette p??e v P? 15. 06. 2007 v 09:04 -0700: > > Strange... on Debian/Unstable I get this: > > > > Traceback (most recent call last): > > File "/usr/local/grass-6.3.cvs/etc/wx/wxgui.py", line 34, in ? > > import wx.aui > > ImportError: No module named aui > > > > > > I wonder if my wxWindows it too old? > > > > libwxbase2.6-0 > > libwxbase2.6-dev > > libwxgtk2.4-1 > > libwxgtk2.6-0 > > libwxgtk2.6-dev > > python-wxgtk2.4 > > python-wxgtk2.6 > > python-wxtools > > python-wxversion > > wx2.6-headers > > > > > > any tips on which packages I might be missing on Debian/unstable? It > > seems that I have a 'wx' module available in python 2.4, but not > > 'wx.aui' . > > > > cheers, > > > > dylan > > > > > > > > > > On 6/15/07, Michael Barton wrote: > > > > > > > > > > > > On 6/15/07 8:17 AM, "Jachym Cepicky" wrote: > > > > > > > Hi Michael, > > > > > > > > great work! I posted some blogposts about wxGRASS at my blog [1],[2] and > > > > I do continue to write about it more. > > > > > > > > I would also mention new attribute table manager (also not yet fully > > > > functional) :-) > > > > > > I did (see below "attribute data manager"). It's very nice and quite > > > promising. > > > > > > > > > > > Have a nice holiday > > > > > > > > Jachym > > > > > > > > [1] http://www.les-ejk.cz/english/wxgrass-new-grass-gui-1 > > > > [2] http://www.les-ejk.cz/english/wxgrass-new-grass-gui-2 > > > > > > > > Michael Barton p??e v P? 15. 06. 2007 v 01:07 -0700: > > > >> The new wxPython GRASS interface (AKA wxgrass) is pretty much equal > > > >> in functionality to the standard TclTk interface, and so is ready for > > > >> regular testing. All items from the TclTk menus are on the wxPython > > > >> menus. There are a couple of caveats. > > > >> > > > >> There is not yet a comprehensive georectifying module like there is > > > >> for TclTk > > > >> The location setting wizard is not yet functional, meaning that you > > > >> can't define projections using g.setproj. > > > >> You will still need TclTk for NVIZ, v.digit, and d.rast.edit. > > > >> > > > >> There are also some enhancements over the TclTk interface, including: > > > >> a prototype attribute data manager (works for interactive mouse > > > >> queries) > > > >> more sophisticated profile analysis module > > > >> full command line access to all GRASS commands; d.* commands called > > > >> from the command line can display in the wxPython canvas. > > > >> easily positioned scalebar and legend > > > >> A more compact (and aesthetic) appearance > > > >> > > > >> You can get wxgrass from the GRASS subversion repository at... > > > >> > > > >> Download the entire GUI tarball and follow the easy installation > > > >> instructions. > > > >> > > > >> enjoy > > > >> Michael > > > >> > > > >> PS: I'll be gone after tomorrow for a week. > > > >> > > > >> __________________________________________ > > > >> Michael Barton, Professor of Anthropology > > > >> School of Human Evolution & Social Change > > > >> Center for Social Dynamics & Complexity > > > >> Arizona State University > > > >> > > > >> phone: 480-965-6213 > > > >> fax: 480-965-7671 > > > >> www: http://www.public.asu.edu/~cmbarton > > > >> > > > >> _______________________________________________ > > > >> grassgui mailing list > > > >> grassgui@grass.itc.it > > > >> http://grass.itc.it/mailman/listinfo/grassgui > > > > > > __________________________________________ > > > Michael Barton, Professor of Anthropology > > > School of Human Evolution & Social Change > > > Center for Social Dynamics & Complexity > > > Arizona State University > > > > > > phone: 480-965-6213 > > > fax: 480-965-7671 > > > www: http://www.public.asu.edu/~cmbarton > > > > > > > > > > > > _______________________________________________ > > > grass-dev mailing list > > > grass-dev@grass.itc.it > > > http://grass.itc.it/mailman/listinfo/grass-dev > > > > -- > Jachym Cepicky > e-mail: jachym.cepicky@gmail.com > URL: http://les-ejk.cz > GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > > > From glynn at gclements.plus.com Fri Jun 15 19:25:10 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jun 15 19:25:13 2007 Subject: [GRASS-dev] Problems posting to grass-gui Message-ID: <18034.52086.304734.826727@cerise.gclements.plus.com> Any idea why my attempts to post to grass-gui keep bouncing? > This is a MIME-encapsulated message > > --l5FGLYOc018107.1181924494/cerise.gclements.plus.com > > The original message was received at Fri, 15 Jun 2007 17:21:31 +0100 > from localhost [127.0.0.1] > > ----- The following addresses had permanent fatal errors ----- > > (reason: 550 5.1.1 ... User unknown) > > ----- Transcript of session follows ----- > ... while talking to grass.itc.it.: > >>> DATA > <<< 550 5.1.1 ... User unknown > 550 5.1.1 ... User unknown > > --l5FGLYOc018107.1181924494/cerise.gclements.plus.com > Content-Type: message/delivery-status > > Reporting-MTA: dns; cerise.gclements.plus.com > Received-From-MTA: DNS; localhost > Arrival-Date: Fri, 15 Jun 2007 17:21:31 +0100 > > Final-Recipient: RFC822; grass-gui@grass.itc.it > Action: failed > Status: 5.1.1 > Remote-MTA: DNS; grass.itc.it > Diagnostic-Code: SMTP; 550 5.1.1 ... User unknown > Last-Attempt-Date: Fri, 15 Jun 2007 17:21:34 +0100 > > --l5FGLYOc018107.1181924494/cerise.gclements.plus.com > Content-Type: message/rfc822 > > Return-Path: > Received: from cerise.gclements.plus.com (localhost [127.0.0.1]) > by cerise.gclements.plus.com (8.13.7/8.13.7) with ESMTP id l5FGLVOc018105; > Fri, 15 Jun 2007 17:21:31 +0100 > Received: (from glynn@localhost) > by cerise.gclements.plus.com (8.14.0/8.14.0/Submit) id l5FGLVw7018102; > Fri, 15 Jun 2007 17:21:31 +0100 > From: Glynn Clements > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > Message-ID: <18034.48267.279976.431020@cerise.gclements.plus.com> > Date: Fri, 15 Jun 2007 17:21:31 +0100 > To: Michael Barton > Cc: grass-gui@grass.itc.it, GRASS devel , > Daniel Calvelo > Subject: Re: [GRASS-dev] d.rast.edit in wxgrass > In-Reply-To: > References: <18033.38623.341392.551825@cerise.gclements.plus.com> > > X-Mailer: VM 7.07 under 21.4 (patch 20) "Double Solitaire" XEmacs Lucid -- Glynn Clements From michael.barton at asu.edu Fri Jun 15 20:00:52 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jun 15 20:01:07 2007 Subject: [GRASS-dev] d.extend in gui In-Reply-To: Message-ID: On 6/14/07 5:17 PM, "Paul Kelly" wrote: > > I've mentioned this before but I really think there should be a GUI region > setting widget with all the functionality of the old interactive > curses-based g.region. Someone was complaining recently that there should > be a quick resolution adjust facility in the GUI monitor displays - I > think that would be a hack but a button to access the interactive region > setting widget, with further buttons there to save the region as the > active display region or the mapset working region etc. would be very > useful IMHO. Exactly such a location setting wizard is about 80% completed for the wxPython gui. Problem: g.proj won't accept g.setproj style values that can pulled from the projection, transform, and other files in $GISBASE/etc, no will it take extents. And g.setproj won't run non-interactively. So we can (and have) replicate everything *except* actually using the values to create a location. Can either g.proj be extended to accept g.setproj-like values or g.setproj get an option to run non-interactively? Then we could finish the wizard. It runs with the wxgrass startup, so you can see where it's at currently. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Fri Jun 15 20:05:03 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jun 15 20:05:16 2007 Subject: [GRASS-dev] Re: [GRASSGUI] wxgrass ready for testing In-Reply-To: <3c5546140706150904j3b9f448maac4ab4043b4077b@mail.gmail.com> Message-ID: You need version 2.8. (2.8.4 is the most current). Michael On 6/15/07 9:04 AM, "Dylan Beaudette" wrote: > Strange... on Debian/Unstable I get this: > > Traceback (most recent call last): > File "/usr/local/grass-6.3.cvs/etc/wx/wxgui.py", line 34, in ? > import wx.aui > ImportError: No module named aui > > > I wonder if my wxWindows it too old? > > libwxbase2.6-0 > libwxbase2.6-dev > libwxgtk2.4-1 > libwxgtk2.6-0 > libwxgtk2.6-dev > python-wxgtk2.4 > python-wxgtk2.6 > python-wxtools > python-wxversion > wx2.6-headers > > > any tips on which packages I might be missing on Debian/unstable? It > seems that I have a 'wx' module available in python 2.4, but not > 'wx.aui' . > > cheers, > > dylan > > > > > On 6/15/07, Michael Barton wrote: >> >> >> >> On 6/15/07 8:17 AM, "Jachym Cepicky" wrote: >> >>> Hi Michael, >>> >>> great work! I posted some blogposts about wxGRASS at my blog [1],[2] and >>> I do continue to write about it more. >>> >>> I would also mention new attribute table manager (also not yet fully >>> functional) :-) >> >> I did (see below "attribute data manager"). It's very nice and quite >> promising. >> >>> >>> Have a nice holiday >>> >>> Jachym >>> >>> [1] http://www.les-ejk.cz/english/wxgrass-new-grass-gui-1 >>> [2] http://www.les-ejk.cz/english/wxgrass-new-grass-gui-2 >>> >>> Michael Barton p??e v P? 15. 06. 2007 v 01:07 -0700: >>>> The new wxPython GRASS interface (AKA wxgrass) is pretty much equal >>>> in functionality to the standard TclTk interface, and so is ready for >>>> regular testing. All items from the TclTk menus are on the wxPython >>>> menus. There are a couple of caveats. >>>> >>>> There is not yet a comprehensive georectifying module like there is >>>> for TclTk >>>> The location setting wizard is not yet functional, meaning that you >>>> can't define projections using g.setproj. >>>> You will still need TclTk for NVIZ, v.digit, and d.rast.edit. >>>> >>>> There are also some enhancements over the TclTk interface, including: >>>> a prototype attribute data manager (works for interactive mouse >>>> queries) >>>> more sophisticated profile analysis module >>>> full command line access to all GRASS commands; d.* commands called >>>> from the command line can display in the wxPython canvas. >>>> easily positioned scalebar and legend >>>> A more compact (and aesthetic) appearance >>>> >>>> You can get wxgrass from the GRASS subversion repository at... >>>> >>>> Download the entire GUI tarball and follow the easy installation >>>> instructions. >>>> >>>> enjoy >>>> Michael >>>> >>>> PS: I'll be gone after tomorrow for a week. >>>> >>>> __________________________________________ >>>> Michael Barton, Professor of Anthropology >>>> School of Human Evolution & Social Change >>>> Center for Social Dynamics & Complexity >>>> Arizona State University >>>> >>>> phone: 480-965-6213 >>>> fax: 480-965-7671 >>>> www: http://www.public.asu.edu/~cmbarton >>>> >>>> _______________________________________________ >>>> grassgui mailing list >>>> grassgui@grass.itc.it >>>> http://grass.itc.it/mailman/listinfo/grassgui >> >> __________________________________________ >> Michael Barton, Professor of Anthropology >> School of Human Evolution & Social Change >> Center for Social Dynamics & Complexity >> Arizona State University >> >> phone: 480-965-6213 >> fax: 480-965-7671 >> www: http://www.public.asu.edu/~cmbarton >> >> >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev >> __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Fri Jun 15 20:08:33 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jun 15 20:08:48 2007 Subject: [GRASSGUI] Re: [GRASS-dev] d.rast.edit in wxgrass In-Reply-To: <18034.47518.676630.186522@cerise.gclements.plus.com> Message-ID: Martin, Is this change in cmd.Command easy to implement? Michael On 6/15/07 9:09 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >>>> GRASS command parsing from the wxgrass CLI: >>>> >>>> Split the command into a list by spaces. I realize that this is a problem >>>> for any command with spaces in the arguments, but I know of no better way >>>> to >>>> do this in this context outside of making users type any command as a >>>> Python >>>> list. If we made people type ['g.region', 'rast=mymap', 'res=30'] instead >>>> of >>>> g.region rast=mymap res=30, I don't think anyone would want to use the CLI. >>> >>> This is one case where shell=True *is* legitimate. At least with a >>> shell, the user can use quotes or backslashes to include spaces in >>> arguments. Or you could implement equivalent functionality yourself. >> >> IIUC, if I keep these as strings, I don't think I can use the cmd.Command >> class and would have to do a custom version of Popen. Then I'd have to send >> them through a different processing path rather than the RunCmd method that >> everything else uses. > > One option is to call the shell explicitly, i.e.: > > cmd.Command(['/bin/sh', '-c', cmdstr], ....) > > or (on Windows): > > cmd.Command(['cmd', '/c', cmdstr], ...) > > Simply adding quoting to the existing implementation would probably be > preferable, though. __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Fri Jun 15 20:10:30 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jun 15 20:10:43 2007 Subject: [GRASS-dev] wxgrass ready for testing In-Reply-To: <4672BBEE.5030703@o2.pl> Message-ID: Because this is somewhat complicated to do, there are probably some hidden gotchas in there somewhere (command arguments with spaces will probably fail currently, for example; we're trying to fix this). But it should work for 90%+ of what people will do. Michael On 6/15/07 9:18 AM, "Maciej Sieczka" wrote: > Michael Barton wrote: > >> full command line access to all GRASS commands; d.* commands called from the >> command line can display in the wxPython canvas. > > This is great. I was missing such functionality for gis.m's map canvas. > > Maciek __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Fri Jun 15 20:15:05 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jun 15 20:15:21 2007 Subject: [GRASS-dev] d.rast.edit in wxgrass In-Reply-To: <18034.48267.279976.431020@cerise.gclements.plus.com> Message-ID: On 6/15/07 9:21 AM, "Glynn Clements" wrote: >> 2) type a command with arguments and it runs the command. To run a d.* >> command and have it do anything useful in the wxgrass environment, it needs >> to be added to the list of display layers and the display updated. > > Not all d.* commands generate graphics. Admittedly, most of the ones > which don't are only useful with a standalone monitor. I don't know > whether there are any other exceptions apart from d.rast.edit > (technically, the original v.digit should have had a d.* prefix, e.g. > d.vect.edit, but it doesn't). > > For the d.* hack to work, we will need to adopt (and enforce) a rule > that the d.* prefix is reserved solely for commands which generate > graphics. That will become more practical in 7.x, as the display > "management" commands (d.mon, d.save, d.info etc) will no longer be > relevant once standalone monitors cease to exist. > Good point. The current hack is to have a list of acceptable d.* commands that will actually work in the display. This needs to be extended to d.* commands with arguments. If something is not on the list, it generates a message dialog telling the user that this command is not implemented. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Fri Jun 15 20:19:03 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jun 15 20:19:18 2007 Subject: [GRASS-dev] Problems posting to grass-gui In-Reply-To: <18034.52086.304734.826727@cerise.gclements.plus.com> Message-ID: Glynn, I had the same problem. It's grassgui@grass.itc.it, not grass-gui@grass.itc.it. Michael On 6/15/07 10:25 AM, "Glynn Clements" wrote: > > Any idea why my attempts to post to grass-gui keep bouncing? > >> This is a MIME-encapsulated message >> >> --l5FGLYOc018107.1181924494/cerise.gclements.plus.com >> >> The original message was received at Fri, 15 Jun 2007 17:21:31 +0100 >> from localhost [127.0.0.1] >> >> ----- The following addresses had permanent fatal errors ----- >> >> (reason: 550 5.1.1 ... User unknown) >> >> ----- Transcript of session follows ----- >> ... while talking to grass.itc.it.: >>>>> DATA >> <<< 550 5.1.1 ... User unknown >> 550 5.1.1 ... User unknown >> >> --l5FGLYOc018107.1181924494/cerise.gclements.plus.com >> Content-Type: message/delivery-status >> >> Reporting-MTA: dns; cerise.gclements.plus.com >> Received-From-MTA: DNS; localhost >> Arrival-Date: Fri, 15 Jun 2007 17:21:31 +0100 >> >> Final-Recipient: RFC822; grass-gui@grass.itc.it >> Action: failed >> Status: 5.1.1 >> Remote-MTA: DNS; grass.itc.it >> Diagnostic-Code: SMTP; 550 5.1.1 ... User unknown >> Last-Attempt-Date: Fri, 15 Jun 2007 17:21:34 +0100 >> >> --l5FGLYOc018107.1181924494/cerise.gclements.plus.com >> Content-Type: message/rfc822 >> >> Return-Path: >> Received: from cerise.gclements.plus.com (localhost [127.0.0.1]) >> by cerise.gclements.plus.com (8.13.7/8.13.7) with ESMTP id l5FGLVOc018105; >> Fri, 15 Jun 2007 17:21:31 +0100 >> Received: (from glynn@localhost) >> by cerise.gclements.plus.com (8.14.0/8.14.0/Submit) id l5FGLVw7018102; >> Fri, 15 Jun 2007 17:21:31 +0100 >> From: Glynn Clements >> MIME-Version: 1.0 >> Content-Type: text/plain; charset=us-ascii >> Content-Transfer-Encoding: 7bit >> Message-ID: <18034.48267.279976.431020@cerise.gclements.plus.com> >> Date: Fri, 15 Jun 2007 17:21:31 +0100 >> To: Michael Barton >> Cc: grass-gui@grass.itc.it, GRASS devel , >> Daniel Calvelo >> Subject: Re: [GRASS-dev] d.rast.edit in wxgrass >> In-Reply-To: >> References: <18033.38623.341392.551825@cerise.gclements.plus.com> >> >> X-Mailer: VM 7.07 under 21.4 (patch 20) "Double Solitaire" XEmacs Lucid __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From mlennert at club.worldonline.be Fri Jun 15 23:09:59 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Jun 15 23:06:07 2007 Subject: [GRASS-dev] trying wxgrass on Windows Message-ID: <1552.85.10.65.118.1181941799.squirrel@geog-pc40.ulb.ac.be> On Fri, June 15, 2007 10:07, Michael Barton wrote: > The new wxPython GRASS interface (AKA wxgrass) is pretty much equal in > functionality to the standard TclTk interface, and so is ready for regular > testing. I decided to give it a try on Windows, directly launching 'python wxgui.py' from within a grass session in cmd.exe. There were quite a few errors, of which I don't know whether they are due to the fact that this is windows (the first is) or because of path definition issues or similar specificities. In cmd.py you have the following function call on line 89: self.module = subprocess.Popen(self.cmd, stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE, close_fds=True) However, close_fds is not supported on Windows... I can solve this by setting usePopenClass = False at line 25. I then get (end of the traceback): File "c:\grass\grass-6.3.cvs\etc\wx\gui_modules\mapdisp.py", line 1313, in __init__ self.projinfo = self.Map.ProjInfo() File "c:\grass\grass-6.3.cvs\etc\wx\gui_modules\render.py", line 460, in ProjInfo p = cmd.Command(cmdlist) File "c:\grass\grass-6.3.cvs\etc\wx\gui_modules\cmd.py", line 134, in __init__ (self.cmd, wait, self.returncode)) TypeError: int argument required Line 134 is part of a debug message, so I can just comment it out (although we should try to identify the reason for the error). This then leads to the wxgrass windows opening. Whenever I try to launch a command from the menu I get something like this: File "c:\grass\grass-6.3.cvs\etc\wx\wxgui.py", line 377, in OnMenuCmd menuform.GUI().ParseCommand(cmd,gmpath, parentframe=self) File "c:\grass\grass-6.3.cvs\etc\wx\gui_modules\menuform.py", line 1110, in ParseCommand xml.sax.parseString( getInterfaceDescription( cmd ) , handler ) File "c:\grass\grass-6.3.cvs\etc\wx\gui_modules\menuform.py", line 1059, in getInterfaceDescription cmdout = p.sub( gmpath+r'/grass-interface.dtd', cmdout) File "C:\Programme\Python25\lib\re.py", line 261, in _subx template = _compile_repl(template, pattern) File "C:\Programme\Python25\lib\re.py", line 248, in _compile_repl raise error, v # invalid expression sre_constants.error: bad group name Similar error when adding a vector or raster layer: File "c:\grass\grass-6.3.cvs\etc\wx\wxgui.py", line 693, in AddRaster self.curr_page.maptree.AddLayer('raster') File "C:\GRASSSRC\gui\gui_modules\wxgui_utils.py", line 446, in AddLayer self.PropertiesDialog(layer) File "C:\GRASSSRC\gui\gui_modules\wxgui_utils.py", line 459, in PropertiesDialog menuform.GUI().ParseCommand('d.rast', gmpath, completed=(self.getOptData,layer,params), parentframe=self) File "c:\grass\grass-6.3.cvs\etc\wx\gui_modules\menuform.py", line 1110, in ParseCommand xml.sax.parseString( getInterfaceDescription( cmd ) , handler ) File "c:\grass\grass-6.3.cvs\etc\wx\gui_modules\menuform.py", line 1059, in getInterfaceDescription cmdout = p.sub( gmpath+r'/grass-interface.dtd', cmdout) File "C:\Programme\Python25\lib\re.py", line 261, in _subx template = _compile_repl(template, pattern) File "C:\Programme\Python25\lib\re.py", line 248, in _compile_repl raise error, v # invalid expression sre_constants.error: bad group name Moritz From kyngchaos at kyngchaos.com Sat Jun 16 01:33:01 2007 From: kyngchaos at kyngchaos.com (kyngchaos@kyngchaos.com) Date: Sat Jun 16 01:33:09 2007 Subject: [GRASS-dev] Re: Mac binary In-Reply-To: References: Message-ID: <50461.24.159.243.19.1181950381.squirrel@webmail.kyngchaos.com> > I got a tcltk error with both 6.3 cvs, my last compilation and your > 30 may installer. Same happens with 6.2 > Application initialization failed: couldn't connect to display ":0.0" > Error in startup script: couldn't connect to display ":0.0" > while executing > "load /Applications/GRASS-6.3.app/Contents/Resources/lib/tk8.4/../ > libtk8.4.dylib Tk" > ("package ifneeded" script) > invoked from within > "package require Tk 8.0" > ("package ifneeded" script) > invoked from within > "package require -exact BWidget 1.2.1" > (file "/Applications/GRASS-6.3.app/Contents/Resources/etc/dm/ > d.m.tcl" line 23) I'm not sure. First, X11 needs to be running, of course. This should be taken of by the app startup. Do you have a DISPLAY setting in your .bash_profile? The app startup will set it to :0.0 for you, but only if it isn't set already. If you do have something in .bash_profile (or other shell init script), it may be set wrong. That's all I can think of. If it used to work, maybe you installed something that added a DISPLAY line to your .bash_profile? I don't use d.m, and only occassionally gis.m. gis.m works for me. From michael.barton at asu.edu Sat Jun 16 02:15:59 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Jun 16 02:16:15 2007 Subject: [GRASS-dev] Re: trying wxgrass on Windows In-Reply-To: <1552.85.10.65.118.1181941799.squirrel@geog-pc40.ulb.ac.be> Message-ID: Moritz, I'm very glad you've tried this on Windows. This is very important. On 6/15/07 2:09 PM, "Moritz Lennert" wrote: > On Fri, June 15, 2007 10:07, Michael Barton wrote: >> The new wxPython GRASS interface (AKA wxgrass) is pretty much equal in >> functionality to the standard TclTk interface, and so is ready for regular >> testing. > > I decided to give it a try on Windows, directly launching 'python > wxgui.py' from within a grass session in cmd.exe. > > There were quite a few errors, of which I don't know whether they are due > to the fact that this is windows (the first is) or because of path > definition issues or similar specificities. > > In cmd.py you have the following function call on line 89: > > self.module = subprocess.Popen(self.cmd, > stdin=subprocess.PIPE, > stdout=subprocess.PIPE, > stderr=subprocess.PIPE, > close_fds=True) > > However, close_fds is not supported on Windows... > > I can solve this by setting usePopenClass = False at line 25. cmd.Command is designed primarily to pass commands through Popen. Setting usePopenClass passes all commands to popen3. This is a backup for cases where subprocess.Popen is not available, but I doubt that this has been tested much or at all. In fact, we are set up to use an independent version of subprocess, if it is not available within Python. IMHO, it would be better to deal with the close_fds argument than to reroute all commands on Windows systems through popen3. I wouldn't be surprised if this is at the bottom of the other errors you are getting. We can either dispense with close_fds or add an if clause to have a version of Popen without close_fds for Windows systems and with close_fds for the rest of the systems. Michael > > I then get (end of the traceback): > > File "c:\grass\grass-6.3.cvs\etc\wx\gui_modules\mapdisp.py", line 1313, > in __init__ > self.projinfo = self.Map.ProjInfo() > File "c:\grass\grass-6.3.cvs\etc\wx\gui_modules\render.py", line 460, in > ProjInfo > p = cmd.Command(cmdlist) > File "c:\grass\grass-6.3.cvs\etc\wx\gui_modules\cmd.py", line 134, in > __init__ > > (self.cmd, wait, self.returncode)) > TypeError: int argument required > > Line 134 is part of a debug message, so I can just comment it out > (although we should try to identify the reason for the error). This then > leads to the wxgrass windows opening. > > Whenever I try to launch a command from the menu I get something like this: > > File "c:\grass\grass-6.3.cvs\etc\wx\wxgui.py", line 377, in OnMenuCmd > menuform.GUI().ParseCommand(cmd,gmpath, parentframe=self) > File "c:\grass\grass-6.3.cvs\etc\wx\gui_modules\menuform.py", line 1110, > in ParseCommand > xml.sax.parseString( getInterfaceDescription( cmd ) , handler ) > File "c:\grass\grass-6.3.cvs\etc\wx\gui_modules\menuform.py", line 1059, > in getInterfaceDescription > cmdout = p.sub( gmpath+r'/grass-interface.dtd', cmdout) > File "C:\Programme\Python25\lib\re.py", line 261, in _subx > template = _compile_repl(template, pattern) > File "C:\Programme\Python25\lib\re.py", line 248, in _compile_repl > raise error, v # invalid expression > sre_constants.error: bad group name > > Similar error when adding a vector or raster layer: > > File "c:\grass\grass-6.3.cvs\etc\wx\wxgui.py", line 693, in AddRaster > self.curr_page.maptree.AddLayer('raster') > File "C:\GRASSSRC\gui\gui_modules\wxgui_utils.py", line 446, in AddLayer > self.PropertiesDialog(layer) > File "C:\GRASSSRC\gui\gui_modules\wxgui_utils.py", line 459, in > PropertiesDialog > menuform.GUI().ParseCommand('d.rast', gmpath, > completed=(self.getOptData,layer,params), parentframe=self) > File "c:\grass\grass-6.3.cvs\etc\wx\gui_modules\menuform.py", line 1110, > in ParseCommand > xml.sax.parseString( getInterfaceDescription( cmd ) , handler ) > File "c:\grass\grass-6.3.cvs\etc\wx\gui_modules\menuform.py", line 1059, > in getInterfaceDescription > cmdout = p.sub( gmpath+r'/grass-interface.dtd', cmdout) > File "C:\Programme\Python25\lib\re.py", line 261, in _subx > template = _compile_repl(template, pattern) > File "C:\Programme\Python25\lib\re.py", line 248, in _compile_repl > raise error, v # invalid expression > sre_constants.error: bad group name > > > Moritz > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From pmarc.debian at gmail.com Sat Jun 16 04:30:08 2007 From: pmarc.debian at gmail.com (Paulo Marcondes) Date: Sat Jun 16 04:30:12 2007 Subject: [GRASS-dev] Renaming of PT_BR po-files to PT-only Message-ID: <8dbfdbff0706151930l230f9770p2f27a97be4bbc4af@mail.gmail.com> Hi All, We, the portuguese translation team, now sporting 3 members (2 brazilians, 1 portuguese), agreed on working our way through the po files, but as we are a mixed team, we would like to rename the po-file to grass*_pt.po, instead of the current grass*_pt_br.po Although I now have write access to the cvs, I was afraid to proceed without consulting the whole team. What is your take on this issue? Shall I proceed? -- PMarc: Debian, GIS, gpsd, OpenWRT user and wannabe-devel Lives @ -22.915 -42.224 From paul-grass at stjohnspoint.co.uk Sat Jun 16 10:12:50 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sat Jun 16 10:13:03 2007 Subject: [GRASS-dev] GUI region setting In-Reply-To: References: Message-ID: Hello Michael On Fri, 15 Jun 2007, Michael Barton wrote: > On 6/14/07 5:17 PM, "Paul Kelly" wrote: > >> >> I've mentioned this before but I really think there should be a GUI region >> setting widget with all the functionality of the old interactive >> curses-based g.region. Someone was complaining recently that there should >> be a quick resolution adjust facility in the GUI monitor displays - I >> think that would be a hack but a button to access the interactive region >> setting widget, with further buttons there to save the region as the >> active display region or the mapset working region etc. would be very >> useful IMHO. > > Exactly such a location setting wizard is about 80% completed for the > wxPython gui. OK that's good that it's there but I think it's utility, if implemented in the way I'm vaguely imagining, should extend far beyond one-time use when creating a new location and it could be something that would regularly be used all the time - for interactively managing the display regions and the computational region. > Problem: g.proj won't accept g.setproj style values that can pulled from the > projection, transform, and other files in $GISBASE/etc, I'm not sure exactly what you're asking for here. When creating a new location with the projection values input manually/interactively (i.e. a custom projection - you're not taking it from any prepared source such as a georeferenced file or an EPSG number) you don't really need to use much of the functionality of g.proj. Glynn split all the projection parameters that g.setproj out into separate text files (they used to be hard-coded in C) for the explicit purpose of making them also available to the GUI to prompt the user and form a valid projection definition. Probably the best thing to do with this would then be to pass it (as a PROJ.4 string) to g.proj and use it to create the location. There is a slight problem with this though in that the way g.setproj was written (and the text files of possible projection parameters have inherited this) doesn't properly allow for the way some projections can be described with complicated combinations of parameters, i.e. it isn't just as simple as saying which parameters are optional or not. Some day someone needs to read the PROJ.4 documentation in detail and re-implement this file. I used to think it's functionality might be included in one of the official PROJ distributions but as time goes on I see that as increasingly unlikely, even though it is a common wish. > no will it take extents. g.proj doesn't need to set the final region extents. g.region can do that. What I am saying is you can run g.proj first and it will do a best a job as it can of writing out a default region - then you can read that back in with g.region and present it to the user for verification, before a final writing back using the new g.region -s flag. > And g.setproj won't run non-interactively. As I said above, all the projection parameters are now extracted into text files so the GUI can access them. > So we can (and have) replicate everything *except* actually using the values > to create a location. > > Can either g.proj be extended to accept g.setproj-like values or g.setproj > get an option to run non-interactively? Form a PROJ.4 string from the projection values and pass it to g.proj using the proj4= option? I'm not really sure what you're asking here. Paul From paul-grass at stjohnspoint.co.uk Sat Jun 16 11:33:25 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sat Jun 16 11:33:30 2007 Subject: [GRASS-dev] d.rast.edit in wxgrass In-Reply-To: References: Message-ID: On Wed, 13 Jun 2007, Michael Barton wrote: > GRASS command parsing from the wxgrass CLI: > > Split the command into a list by spaces. I realize that this is a problem > for any command with spaces in the arguments, but I know of no better way to > do this in this context outside of making users type any command as a Python > list. If we made people type ['g.region', 'rast=mymap', 'res=30'] instead of > g.region rast=mymap res=30, I don't think anyone would want to use the CLI. > > If the command has no arguments (i.e., len(cmdlist) == 0) AND it is NOT a > d.* command, send the original command string (not the list) to the > menuform.py processor (just like the menu would) to create the autogenerated > properties dialog. After this, the result of hitting "run" is the same as if > the properties dialog were called from the menu. I don't get why it needs to do that specific processing - can you not just run whatever is entered - if a command is run without arguments it will pop up the GUI dialog anyway. Unless GRASS_UI_TERM is set. I suppose at the minute it will always be a Tcl/Tk dialog that pops up, but I'm sure it wouldn't be very hard to change G_parser() to check the GRASS_GUI variable (or do something similar) and generate the correct autogenerated dialog corresponding to the GUI that's in use. > If the command has no arguments AND IS a d.* command AND is in a hard coded > list of d.* commands for which we have defined layers in the layer tree, > create a layer tree item for that command (e.g., a raster layer for d.rast). > After that, the new layer is processed in the same way as one created by > pressing a layer button on the layer manager toolbar. Sounds neat, consistent with non-display commands. > If the d.* command without arguments is NOT on the list for the layer tree, > generate get a message that it cannot be processed. > > If the command HAS arguments and is NOT a d.* command, send the command list > (i.e., made by splitting on spaces -- not the original command string) to > cmd.Command for processing. I think Glynn commented on this in a later mail but could you not just take the whole string the user entered and pass it to the shell (or cmd.exe on Windows) for executing - that way all the quoting rules etc. that work in the shell will be consistent with how it works here and reduce user confusion, and avoid you having to implement quoting handling yourself in the space-splitting algorithm.. > If the command HAS arguments and IS a d.* command, it is added to the list > of display layers managed within render.py for the map display that has the > focus and the UpdateMap method is called to update that display. There is a That's a nice idea. I didn't realise it was so easily possible. Is it possible to edit a display layer by editing the underlying raw d.* command-line that it corresponds to, as an alternative to ticking boxes? There obviously must be code to convert the GUI representation of the layer to d.* command-line for drawing, and it sounds like you now have new code to parse the d.* command-line and convert it to a GUI representation (i.e. the display layer), so allowing editing of a layer by changing the raw command-line it uses should be possible. > 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. 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. All sounds good. I like the idea of the GUI having command-line features and most of the command-line functionality being still available should you need it. You could call it power-user features I suppose. Paul From glynn at gclements.plus.com Sat Jun 16 21:53:10 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jun 16 21:53:19 2007 Subject: [GRASSGUI] Re: [GRASS-dev] d.rast.edit in wxgrass In-Reply-To: References: <18034.47518.676630.186522@cerise.gclements.plus.com> Message-ID: <18036.16294.788054.24416@cerise.gclements.plus.com> Michael Barton wrote: > >>>> GRASS command parsing from the wxgrass CLI: > >>>> > >>>> Split the command into a list by spaces. I realize that this is a problem > >>>> for any command with spaces in the arguments, but I know of no better way > >>>> to > >>>> do this in this context outside of making users type any command as a > >>>> Python > >>>> list. If we made people type ['g.region', 'rast=mymap', 'res=30'] instead > >>>> of > >>>> g.region rast=mymap res=30, I don't think anyone would want to use the CLI. > >>> > >>> This is one case where shell=True *is* legitimate. At least with a > >>> shell, the user can use quotes or backslashes to include spaces in > >>> arguments. Or you could implement equivalent functionality yourself. > >> > >> IIUC, if I keep these as strings, I don't think I can use the cmd.Command > >> class and would have to do a custom version of Popen. Then I'd have to send > >> them through a different processing path rather than the RunCmd method that > >> everything else uses. > > > > One option is to call the shell explicitly, i.e.: > > > > cmd.Command(['/bin/sh', '-c', cmdstr], ....) > > > > or (on Windows): > > > > cmd.Command(['cmd', '/c', cmdstr], ...) > > > > Simply adding quoting to the existing implementation would probably be > > preferable, though. > > Martin, > > Is this change in cmd.Command easy to implement? The above isn't a change to cmd.Command(), but a change to how it is used. If you were to change cmd.Command(), the obvious change would be to add a shell= parameter, which would be propagated directly to Popen(). Ultimately, if all you have is a single string provided by the user, that string somehow has to be converted to a list of strings (as that's what argv[] is). The options are: 1. Split at each space. 2. As for 1, but with a quoting and/or escaping mechanism. 3. Use the shell. 1 fails to handle arguments which contain spaces. 2 solves this, but requires some work. 3 gets the shell to do the work, but the cost is that you get a lot of other stuff which you may not want (substitution, redirection, loops, subshells, ...). -- Glynn Clements From glynn at gclements.plus.com Sat Jun 16 21:59:40 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jun 16 21:59:43 2007 Subject: [GRASS-dev] Problems posting to grass-gui In-Reply-To: References: <18034.52086.304734.826727@cerise.gclements.plus.com> Message-ID: <18036.16684.907773.634906@cerise.gclements.plus.com> Michael Barton wrote: > > Any idea why my attempts to post to grass-gui keep bouncing? > > I had the same problem. It's grassgui@grass.itc.it, not > grass-gui@grass.itc.it. Duh; I had assumed that I was replying to messages posted to grassgui. They were actually posted to grass-dev and cross-posted to "grass-gui". Now that I look more closely, the messages to which I was replying don't show up there either. -- Glynn Clements From glynn at gclements.plus.com Sat Jun 16 22:06:51 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jun 16 22:06:56 2007 Subject: [GRASS-dev] d.rast.edit in wxgrass In-Reply-To: References: Message-ID: <18036.17115.635018.899702@cerise.gclements.plus.com> Paul Kelly wrote: > > GRASS command parsing from the wxgrass CLI: > > > > Split the command into a list by spaces. I realize that this is a problem > > for any command with spaces in the arguments, but I know of no better way to > > do this in this context outside of making users type any command as a Python > > list. If we made people type ['g.region', 'rast=mymap', 'res=30'] instead of > > g.region rast=mymap res=30, I don't think anyone would want to use the CLI. > > > > If the command has no arguments (i.e., len(cmdlist) == 0) AND it is NOT a > > d.* command, send the original command string (not the list) to the > > menuform.py processor (just like the menu would) to create the autogenerated > > properties dialog. After this, the result of hitting "run" is the same as if > > the properties dialog were called from the menu. > > I don't get why it needs to do that specific processing - can you not just > run whatever is entered - if a command is run without arguments it will > pop up the GUI dialog anyway. Unless GRASS_UI_TERM is set. I suppose at > the minute it will always be a Tcl/Tk dialog that pops up, but I'm sure it > wouldn't be very hard to change G_parser() to check the GRASS_GUI variable > (or do something similar) and generate the correct autogenerated dialog > corresponding to the GUI that's in use. If you're running the command from a GUI, it's preferable for the dialogs to be generated by the GUI process rather than as a standalone process. E.g. if you select a command from gis.m's menus, gis.m invokes the command using the --tcltk and evaluates the output (with certain procedures overriden, e.g. run_cmd), rather than simply running the command using --ui. This has the advantage that the GUI gets to see (and optionally modify) the arguments which were actually used, so that it can e.g. record the complete command in a history list. If you just use --ui, the re-invocation is hidden from the GUI. -- Glynn Clements From grass-coder at wald.intevation.org Sat Jun 16 23:39:01 2007 From: grass-coder at wald.intevation.org (grass-coder@wald.intevation.org) Date: Sat Jun 16 23:37:27 2007 Subject: [GRASS-dev] [grass-code R][428] Warn about wrong epsg code when creating a location in grass 6.2 Message-ID: <20070616213901.5C2AEB53C0@pyrosoma.intevation.org> code R item #428, was opened at 2007-06-16 18:39 Status: Open Priority: 3 Submitted By: Daniel Victoria (dvictori) Assigned to: Nobody (None) Summary: Warn about wrong epsg code when creating a location in grass 6.2 Issue status: None GRASS component: startup Operating system: None Operating system version: Linux Initial Comment: When creating a location based on a georeferenced files, if the EPSG code is wrong there is no clear warning and no location gets created. This feature is already present in 6.3. Could it be backported? Also, if a wrong EPSG code is input a tmp directory sometimes is created thanks Daniel ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=188&aid=428&group_id=21 From cdavilam at jemila.jazztel.es Sun Jun 17 00:18:00 2007 From: cdavilam at jemila.jazztel.es (=?ISO-8859-15?Q?Carlos_D=E1vila?=) Date: Sun Jun 17 00:16:29 2007 Subject: [GRASS-dev] Possible typos error in ./general/manage/cmd/rename.c:103 Message-ID: <46746198.4090700@jemila.jazztel.es> I think there may be an error in ./general/manage/cmd/rename.c:103 (Renaming in reclassed map%s), but not sure the right form (?map %s, mapset?) Carlos From hamish_nospam at yahoo.com Sun Jun 17 08:18:29 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Jun 17 08:18:39 2007 Subject: [GRASS-dev] Possible typos error in ./general/manage/cmd/rename.c:103 In-Reply-To: <46746198.4090700@jemila.jazztel.es> References: <46746198.4090700@jemila.jazztel.es> Message-ID: <20070617181829.4a7792c2.hamish_nospam@yahoo.com> Carlos D?vila wrote: > > I think there may be an error in ./general/manage/cmd/rename.c:103 > (Renaming in reclassed map%s), but not sure the right form (?map %s, G_message(_("Renaming in reclassed map%s"), (nrmaps > 1 ? "s" : "")); if there is more than 1 map it adds an "s" to the end of the string. this sort of pluralization trick is probably not very transaltion safe, and should be avoided. Beyond that, I'm not really sure what that message is trying to say. Hamish From glynn at gclements.plus.com Mon Jun 18 02:11:03 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jun 18 02:11:06 2007 Subject: [GRASS-dev] Possible typos error in ./general/manage/cmd/rename.c:103 In-Reply-To: <20070617181829.4a7792c2.hamish_nospam@yahoo.com> References: <46746198.4090700@jemila.jazztel.es> <20070617181829.4a7792c2.hamish_nospam@yahoo.com> Message-ID: <18037.52631.483007.713439@cerise.gclements.plus.com> Hamish wrote: > Carlos D?vila wrote: > > > > I think there may be an error in ./general/manage/cmd/rename.c:103 > > (Renaming in reclassed map%s), but not sure the right form (?map %s, > > > G_message(_("Renaming in reclassed map%s"), > (nrmaps > 1 ? "s" : "")); > > > if there is more than 1 map it adds an "s" to the end of the string. > this sort of pluralization trick is probably not very transaltion safe, > and should be avoided. Beyond that, I'm not really sure what that > message is trying to say. The "in" is a grammatical error; I've changed that line to: G_message(_("Renaming reclass maps")); It's usually better to just always use the plural in such situations than adding a special case for n == 1. -- Glynn Clements From hamish_nospam at yahoo.com Mon Jun 18 08:18:31 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 18 08:18:49 2007 Subject: [GRASS-dev] Re: [grass-code R][428] Warn about wrong epsg code when creating a location in grass 6.2 In-Reply-To: <20070616213901.5C2AEB53C0@pyrosoma.intevation.org> References: <20070616213901.5C2AEB53C0@pyrosoma.intevation.org> Message-ID: <20070618181831.0acd99af.hamish_nospam@yahoo.com> http://wald.intevation.org/tracker/?func=detail&atid=188&aid=428&group_id=21 > code R item #428, was opened at 2007-06-16 18:39 > Submitted By: Daniel Victoria (dvictori) > Summary: Warn about wrong epsg code when creating a location in grass > 6.2 > GRASS component: startup .. > When creating a location based on a georeferenced files, if the EPSG > code is wrong there is no clear warning and no location gets created. in 6.2 lib/init/epsg_option.tcl.in calls this: exec -- $env(GISBASE)/etc/grass-xterm-wrapper -e \ $env(GISBASE)/etc/make_location_epsg.sh \ $epsg_code $epsgLocation $locpath >@stdout 2>@stderr; make_location_epsg.sh.in then checks if "g.proj -c" worked, and exits with an error if it didn't, but the xterm closes as soon as the script is done so you don't see the error message and epsg_option.tcl doesn't check the return code to make its own error message. One option is to be like grass-run.sh and do something like: if [ $EXIT_VAL -ne 0 ] ; then echo echo "ERROR: $1 exited abnormally. Press to continue." read fi but make_location_epsg.sh is not just used by the startup GUI, so making it interactive might be bad. A compromise might be to do that, but give the `read` a timeout: read -t 10 -n 1 -p "Press any key to continue ... (or wait 10 seconds)" but AFAIK -t and -n are not portable. maybe echo "ERROR: ..." sleep 5 ? :-/ We could catch the "exec grass-xterm-wrapper" in epsg_option.tcl.in and check the exit code (I've no idea how to do that correctly). That doesn't help show what the g.proj error was though, just that make_location_epsg.sh.in failed. > This feature is already present in 6.3. Could it be backported? No, in 6.3 it is totally different, a Tcl script makes the location. But maybe we can find another solution. > Also, if a wrong EPSG code is input a tmp directory sometimes is > created 6.2's lib/init/make_location_epsg.sh.in goes: [...] # create new location: g.proj -c proj4='+init=epsg:'$EPSG location=$LOCATION if [ $? -eq 1 ] ; then echo "An error occured. Stop." exit 1 fi #restore previous .$GRASSRC if test -f "$GISDBASE"/"$TEMPDIR"/$GRASSRC ; then mv "$GISDBASE"/"$TEMPDIR"/$GRASSRC "$HOME"/.$GRASSRC fi #cleanup: rm -rf $GISDBASE/$TEMPDIR [...] so cleanup isn't done if "g.proj -c" had an error. Hamish From hamish_nospam at yahoo.com Mon Jun 18 08:56:56 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 18 08:57:03 2007 Subject: [GRASS-dev] cvs server's time wrong? Message-ID: <20070618185656.7386c07c.hamish_nospam@yahoo.com> Hi, I just got this error after adding a new file in CVS and local cvs update, make: Warning: File `Makefile' has modification time 2.2e+02 s in the future is ntpd working properly on the CVS server? it seems a few minutes out. $ ntpq -p thanks, Hamish From hamish_nospam at yahoo.com Mon Jun 18 10:02:29 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 18 10:02:38 2007 Subject: [GRASS-dev] simplify G_convert_dirseps_to_host(G_tempfile()) ? Message-ID: <20070618200229.206fca3d.hamish_nospam@yahoo.com> [r.average] should G_tempfile() be calling G_convert_dirseps_to_host() internally, rather than having individual modules calling it? (ie often forgetting to call it) Hamish From Agustin.Diez at uv.es Mon Jun 18 10:36:50 2007 From: Agustin.Diez at uv.es (Agustin Diez Castillo) Date: Mon Jun 18 10:38:50 2007 Subject: [GRASS-dev] Re: Mac binary In-Reply-To: <50461.24.159.243.19.1181950381.squirrel@webmail.kyngchaos.com> References: <50461.24.159.243.19.1181950381.squirrel@webmail.kyngchaos.com> Message-ID: After rebooting the mac machine, grass is working. Maybe the problem was that I did ssh -Y to a linux box and this takes display ":0.0". On Jun 16, 2007, at 1:33 AM, kyngchaos@kyngchaos.com wrote: >> I got a tcltk error with both 6.3 cvs, my last compilation and your >> 30 may installer. Same happens with 6.2 >> Application initialization failed: couldn't connect to display ":0.0" >> Error in startup script: couldn't connect to display ":0.0" >> while executing >> "load /Applications/GRASS-6.3.app/Contents/Resources/lib/tk8.4/../ >> libtk8.4.dylib Tk" >> ("package ifneeded" script) >> invoked from within >> "package require Tk 8.0" >> ("package ifneeded" script) >> invoked from within >> "package require -exact BWidget 1.2.1" >> (file "/Applications/GRASS-6.3.app/Contents/Resources/etc/dm/ >> d.m.tcl" line 23) > > I'm not sure. First, X11 needs to be running, of course. This > should be > taken of by the app startup. > > Do you have a DISPLAY setting in your .bash_profile? The app > startup will > set it to :0.0 for you, but only if it isn't set already. If you > do have > something in .bash_profile (or other shell init script), it may be set > wrong. That's all I can think of. > > If it used to work, maybe you installed something that added a DISPLAY > line to your .bash_profile? > > I don't use d.m, and only occassionally gis.m. gis.m works for me. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070618/ffdf978f/attachment.html From paul-grass at stjohnspoint.co.uk Mon Jun 18 11:20:20 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Jun 18 11:20:26 2007 Subject: [GRASS-dev] simplify G_convert_dirseps_to_host(G_tempfile()) ? In-Reply-To: <20070618200229.206fca3d.hamish_nospam@yahoo.com> References: <20070618200229.206fca3d.hamish_nospam@yahoo.com> Message-ID: On Mon, 18 Jun 2007, Hamish wrote: > [r.average] > > should G_tempfile() be calling G_convert_dirseps_to_host() internally, > rather than having individual modules calling it? (ie often forgetting > to call it) I don't think so - G_convert_dirseps_to_host() only needs to be called in certain situations, when the generated path will be used directly by external commands on the system. I think to unconditionally call it would confuse its purpose. But then again in the longrun it might be a good idea to generally simplify things as you said. Hmm, I'm not so sure now. But there may be cases which call it and expect to have '/' directory separators there for some further processing; I wouldn't like to just change it without an audit of where it is used. Which modules were you thinking of anyway? FWIW I've attached my proposed changes to lib/gis/tempfile.c that I still have in my local source tree. They were intended to split the usage of G_tempfile() between modules that are genuinely using it as a tempfile for creating large temporary maps as was originally intended, and those that are just using it as a general small tempfile function. They also make some changes to make it more Windows compatible. But we decided they were too controversial to commit in case they broke things - maybe in some way we can eventually merge them though. Paul From hamish_nospam at yahoo.com Mon Jun 18 11:33:31 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 18 11:33:44 2007 Subject: [GRASS-dev] resolving more menu issues In-Reply-To: References: <20070610224628.5b2aa024.hamish_nospam@yahoo.com> Message-ID: <20070618213331.049ded38.hamish_nospam@yahoo.com> Hamish: > > it would be nice to move generic wrapper scripts which are just > > needed for a GUI/core interaction (ie nothing to do with tcl or wx) > > from gui/tcltk/gis.m/script/ to gui/scripts/ Now done for non-obsolete scripts. After install they live in $GISBASE/etc/gui/scripts/. d.shadedmap moved to the main script/ dir, now it's a normal module. I added a -d flag to d.title to run G_system(d.text) automatically, so d.title.sh is now obsolete. the rest of the GUI wrapper scripts should be removed once the modules they wrap become more GUI-friendly (ie sometime before GRASS 7): - r.reclass, r.recode, r.colors, take input from a file= option as an alternative to stdin; better- write a GUI to help make the input file then run r.reclass with that) - d.path has a coor= option now, so it can be used non-interactively. i.e. the GUI can pick the two coords interactively and then run the module non-interactively and display the result. - The r.support bug is still weird. (breaks out after two [y/n] questions if run directly in an xterm) hopefully no problems, Hamish From paul-grass at stjohnspoint.co.uk Mon Jun 18 11:55:19 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Jun 18 11:55:24 2007 Subject: [GRASS-dev] simplify G_convert_dirseps_to_host(G_tempfile()) ? In-Reply-To: References: <20070618200229.206fca3d.hamish_nospam@yahoo.com> Message-ID: On Mon, 18 Jun 2007, Paul Kelly wrote: > On Mon, 18 Jun 2007, Hamish wrote: > >> [r.average] >> >> should G_tempfile() be calling G_convert_dirseps_to_host() internally, >> rather than having individual modules calling it? (ie often forgetting >> to call it) > > I don't think so - G_convert_dirseps_to_host() only needs to be called in > certain situations, when the generated path will be used directly by external > commands on the system. I think to unconditionally call it would confuse its > purpose. But then again in the longrun it might be a good idea to generally > simplify things as you said. Hmm, I'm not so sure now. But there may be cases > which call it and expect to have '/' directory separators there for some > further processing; I wouldn't like to just change it without an audit of > where it is used. Which modules were you thinking of anyway? > > FWIW I've attached my proposed changes to lib/gis/tempfile.c that I still ^^^^^^^^ Oops - didn't even upload the diff never mind attach it. But here it is now if anyone is interested. Interestingly, the patch forces all generated filenames to have '/' directory separators - presumably because I was concerned that some modules might expect this, although I can't remember to be sure... > have in my local source tree. They were intended to split the usage of > G_tempfile() between modules that are genuinely using it as a tempfile for > creating large temporary maps as was originally intended, and those that are > just using it as a general small tempfile function. They also make some > changes to make it more Windows compatible. But we decided they were too > controversial to commit in case they broke things - maybe in some way we can > eventually merge them though. > > Paul > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > > -------------- next part -------------- Index: lib/gis/tempfile.c =================================================================== RCS file: /home/grass/grassrepository/grass6/lib/gis/tempfile.c,v retrieving revision 2.5 diff -u -r2.5 tempfile.c --- lib/gis/tempfile.c 14 Apr 2007 23:02:01 -0000 2.5 +++ lib/gis/tempfile.c 18 Jun 2007 09:17:45 -0000 @@ -11,36 +11,62 @@ * \date 1999-2006 */ +#include +#include #include #include #include +#include #include - -/** - * \fn char *G_tempfile (void) +/*! + * \brief returns a temporary file name on the same disk as the current mapset * - * \brief Returns a temporary file name. + * This function returns a pointer to a string containing a unique file name + * that can be used as a temporary file within the module. Successive calls + * to the function will generate new names. + * + * Only the file name is generated. The file itself is not created. To create the + * file, the module must use standard UNIX functions which create and open files, + * e.g., creat() or fopen(). The filename is guaranteed to be on the same disk + * as the current mapset. This means that "draft" output maps can + * be moved (with either link()+remove() or rename()) into their final + * location upon closure. + * + * The programmer should take reasonable care to remove (unlink) the file + * before the module exits. However, GRASS database management will + * eventually remove all temporary files created by G_tempfile_in_mapset() + * that have been left behind by the modules which created them. + * + * \return char: pointer to a character string containing the name. + * the name is copied to allocated memory and may be + * released by the unix free () routine. + */ + +char *G_tempfile_in_mapset(void) +{ + return G__tempfile_in_mapset(getpid()); +} + +/*! + * \brief returns a temporary file name * - * This routine returns a pointer to a string containing a unique - * temporary file name that can be used as a temporary file within the - * module. Successive calls to G_tempfile() will generate new - * names. Only the file name is generated. The file itself is not - * created. To create the file, the module must use standard UNIX - * functions which create and open files, e.g., creat() or - * fopen().
- * - * Successive calls will generate different names the names are of the - * form pid.n where pid is the programs process id number and n is a - * unique identifier.
- * - * Note: It is recommended to unlink() (remove) the - * temp file on exit/error. Only if GRASS is left with 'exit', the GIS - * mapset manangement will clean up the temp directory (ETC/clean_temp). - * - * \return pointer to a character string containing the name. The name - * is copied to allocated memory and may be released by the unix free() - * routine. + * This function returns a pointer to a string containing a unique file name + * that can be used as a temporary file within the module. Successive calls + * to the function will generate new names. + * + * Only the file name is generated. The file itself is not created. To create the + * file, the module must use standard UNIX functions which create and open files, + * e.g., creat() or fopen(). + * + * The programmer should take care to remove (unlink) the file before + * the module exits. If a module requires not to immediately delete a + * temporary file and instead have it automatically deleted at the end of + * the GRASS session, G_tempfile_in_mapset() should be used instead. + * + * \return char: pointer to a character string containing the name. + * the name is copied to allocated memory and may be + * released by the unix free () routine. */ char *G_tempfile(void) @@ -48,10 +74,7 @@ return G__tempfile(getpid()); } - /** - * \fn char *G__tempfile (int pid) - * * \brief Create tempfile from process id. * * See G_tempfile(). @@ -62,6 +85,65 @@ char *G__tempfile (int pid) { + char *env_tmpdir = getenv("TMPDIR"); + char *env_temp = getenv("TEMP"); + char *prefix, *path = NULL; + char dirsep_char[2]; + static int uniq = 0; + struct stat st; + + if (pid <= 0) + pid = getpid(); + + if (env_tmpdir != NULL) + /* This should be somewhere in user home directory on Unix, + * thus ensuring write permission */ + prefix = G_store(env_tmpdir); + else if (env_temp != NULL) + /* This should be somewhere in user profile directory on Windows, + * thus ensuring write permission */ + prefix = G_store(env_temp); + else + /* Usually /tmp on Unix or root of current drive on Windows */ + prefix = G_store(P_tmpdir); + + /* Often there's no harm in having an extra directory separator character + * in the middle of a path but just being careful here. */ + if (G_is_dirsep( prefix[strlen(prefix)-1] )) { + dirsep_char[0] = '\0'; + } + else { + dirsep_char[0] = GRASS_DIRSEP; + dirsep_char[1] = '\0'; + } + + do { + if (path != NULL) + G_free(path); + path = G_malloc(strlen(prefix) + 40 ); + sprintf(path, "%s%sgrass-%d.%d", prefix, dirsep_char, pid, uniq++); + /* We use '/'-style dirseps within GRASS */ + G_convert_dirseps_from_host( path ); + } while (stat(path, &st) == 0); + + G_free(prefix); + + return path; + +} + + +/** + * \brief Create tempfile in current mapset from process id. + * + * See G_tempfile_in_mapset(). + * + * \param[in] pid + * \return Pointer to string path + */ + +char *G__tempfile_in_mapset (int pid) +{ char path[GPATH_MAX]; char name[GNAME_MAX]; char element[100]; @@ -78,13 +160,14 @@ } while (stat(path, &st) == 0) ; + /* We use '/'-style dirseps within GRASS */ + G_convert_dirseps_from_host (path); + return G_store (path); } /** - * \fn int G__temp_element (char *element) - * * \brief Populates element with a path string. * * \param[in,out] element From hamish_nospam at yahoo.com Mon Jun 18 12:10:09 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 18 12:10:21 2007 Subject: [GRASS-dev] Message standardization In-Reply-To: References: <20070613213629.27dddaa2.hamish_nospam@yahoo.com> Message-ID: <20070618221009.78c8ac55.hamish_nospam@yahoo.com> Michael Barton wrote: > > Module descriptions are a different sort of beast from error > messages--and from GUI messages and other descriptors. All need > standardization, but I'd recommend doing them one at a time so as not > to overwhelm everyone. > > If we can standardize error messages first it might be the simplest > piece to attack. Then move on to others like module descriptions in > the module code, module doc formatting, GUI, etc. I would consider module and option/flag descriptions much easier "low- hanging fruit" than error messages. For them the rules are simpler, - module descriptions end with a "." - option/flag descriptions do not. - Multi-sentence descriptions are probably good candidates to break up into a short ->label + a ->description to hold additional info. - Begin with a capital letter. - Don't pad whitespace. For standard error/warning messages (ie the ones that always come right after G_open_file() or whatever) we can pick something nice and specify that on the wiki page to avoid repetitious translations of almost identical messages. For the vast majority of error/warning/regular messages, they are single-use, module dependant, and maybe put there by the programmer on a just-in-case basis, ie they may never be seen by a user. Contrast that with the module description and option descriptions which have high exposure, & thus greater result from a translator's time. library translations have high-reuse value. GUI translations have high-exposure value. 2c, Hamish From hamish_nospam at yahoo.com Mon Jun 18 13:02:39 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Jun 18 13:02:48 2007 Subject: [GRASS-dev] simplify G_convert_dirseps_to_host(G_tempfile()) ? In-Reply-To: References: <20070618200229.206fca3d.hamish_nospam@yahoo.com> Message-ID: <20070618230239.5fe9b403.hamish_nospam@yahoo.com> Paul Kelly wrote: > > should G_tempfile() be calling G_convert_dirseps_to_host() > > internally, rather than having individual modules calling it? (ie > > often forgetting to call it) > > I don't think so - G_convert_dirseps_to_host() only needs to be called > > in certain situations, when the generated path will be used directly > by external commands on the system. I think to unconditionally call > it would confuse its purpose. But then again in the longrun it might > be a good idea to generally simplify things as you said. Hmm, I'm not > so sure now. But there may be cases which call it and expect to have > '/' directory separators there for some further processing; I > wouldn't like to just change it without an audit of where it is used. > Which modules were you thinking of anyway? I just added a G_tempfile() call in d.title, now with the -d flag it does fopen(),fclose() then like G_system("d.text < \"%s\"", tmpfile). Hamish From paul-grass at stjohnspoint.co.uk Mon Jun 18 13:04:33 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Jun 18 13:04:36 2007 Subject: [GRASS-dev] d.rast.edit in wxgrass In-Reply-To: <18036.17115.635018.899702@cerise.gclements.plus.com> References: <18036.17115.635018.899702@cerise.gclements.plus.com> Message-ID: On Sat, 16 Jun 2007, Glynn Clements wrote: > > Paul Kelly wrote: > >>> If the command has no arguments (i.e., len(cmdlist) == 0) AND it is NOT a >>> d.* command, send the original command string (not the list) to the >>> menuform.py processor (just like the menu would) to create the autogenerated >>> properties dialog. After this, the result of hitting "run" is the same as if >>> the properties dialog were called from the menu. >> >> I don't get why it needs to do that specific processing - can you not just >> run whatever is entered - if a command is run without arguments it will >> pop up the GUI dialog anyway. Unless GRASS_UI_TERM is set. I suppose at >> the minute it will always be a Tcl/Tk dialog that pops up, but I'm sure it >> wouldn't be very hard to change G_parser() to check the GRASS_GUI variable >> (or do something similar) and generate the correct autogenerated dialog >> corresponding to the GUI that's in use. > > If you're running the command from a GUI, it's preferable for the > dialogs to be generated by the GUI process rather than as a standalone > process. > > E.g. if you select a command from gis.m's menus, gis.m invokes the > command using the --tcltk and evaluates the output (with certain > procedures overriden, e.g. run_cmd), rather than simply running the > command using --ui. > > This has the advantage that the GUI gets to see (and optionally > modify) the arguments which were actually used, so that it can e.g. > record the complete command in a history list. If you just use --ui, > the re-invocation is hidden from the GUI. Ah I see, I think. That sounds pretty important. But it does it mean that tricks the module may do such as checking if there are any command-line arguments before running G_parser() will be ineffective? I was thinking of changing g.mkfontcap to work like that. But I suppose, I could still do that and then it will be OK when run from a script or the command-line. Not so bad for the GUI to add a GUI stage to running the command I suppose - it just means an extra click of "Run". I didn't realise gis.m worked like this too - might there be any value then in removing the functionality that commands run from the command-line pop up a GUI window when run with no arguments, i.e. behave as if GRASS_UI_TERM was set? Was this behaviour only needed for d.m perhaps? It's not important anyway I suppose. But the point about over-riding the Tcl/Tk GUI box's run_cmd to store this history - that's in the gronsole I think - is important and helps to understand it a lot better, thanks. Paul From mlennert at club.worldonline.be Mon Jun 18 13:35:18 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Mon Jun 18 13:31:24 2007 Subject: [GRASS-dev] simplify G_convert_dirseps_to_host(G_tempfile()) ? In-Reply-To: <20070618230239.5fe9b403.hamish_nospam@yahoo.com> References: <20070618200229.206fca3d.hamish_nospam@yahoo.com> <20070618230239.5fe9b403.hamish_nospam@yahoo.com> Message-ID: <46766DF6.40907@club.worldonline.be> On 18/06/07 13:02, Hamish wrote: > > I just added a G_tempfile() call in d.title, now with the -d flag it > does fopen(),fclose() then like G_system("d.text < \"%s\"", tmpfile). > Just wondering: how Windows-friendly is such usage of G_system ? Moritz From paul-grass at stjohnspoint.co.uk Mon Jun 18 14:02:07 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Jun 18 14:02:09 2007 Subject: [GRASS-dev] simplify G_convert_dirseps_to_host(G_tempfile()) ? In-Reply-To: <46766DF6.40907@club.worldonline.be> References: <20070618200229.206fca3d.hamish_nospam@yahoo.com> <20070618230239.5fe9b403.hamish_nospam@yahoo.com> <46766DF6.40907@club.worldonline.be> Message-ID: On Mon, 18 Jun 2007, Moritz Lennert wrote: > On 18/06/07 13:02, Hamish wrote: > >> >> I just added a G_tempfile() call in d.title, now with the -d flag it >> does fopen(),fclose() then like G_system("d.text < \"%s\"", tmpfile). >> > > Just wondering: how Windows-friendly is such usage of G_system ? I think it should be fine. cmd.exe understands the redirection operators like <, > and |. And using double quotes to quote pathnames is also Windows-compatible (single quotes won't work). Paul From pmarc.debian at gmail.com Mon Jun 18 14:27:57 2007 From: pmarc.debian at gmail.com (Paulo Marcondes) Date: Mon Jun 18 14:28:02 2007 Subject: [GRASS-dev] Message standardization In-Reply-To: <20070618221009.78c8ac55.hamish_nospam@yahoo.com> References: <20070613213629.27dddaa2.hamish_nospam@yahoo.com> <20070618221009.78c8ac55.hamish_nospam@yahoo.com> Message-ID: <8dbfdbff0706180527q6b4c4bbex60ab9c72bee8cfd4@mail.gmail.com> 2007/6/18, Hamish : > library translations have high-reuse value. > GUI translations have high-exposure value. This is the main reason why I decided to sprint on the gui messages. New users are much more likely put off by non native language in GUI than current/old users, which already used to CLI modules in english. -- PMarc: Debian, GIS, gpsd, OpenWRT user and wannabe-devel Lives @ -22.915 -42.224 From Agustin.Diez at uv.es Mon Jun 18 17:39:45 2007 From: Agustin.Diez at uv.es (Agustin Diez Castillo) Date: Mon Jun 18 17:41:47 2007 Subject: [GRASS-DEV] In wxgrass File menu import vector calls v.out.ogr In-Reply-To: References: Message-ID: <58C1BBA1-B89A-4F8C-8EC5-DB7FA73D1AF0@uv.es> Hi, wxgrass gui is calling the wrong command. At least here, menu Files -- Import raster map -- mutiple format using gdal is calling r.out.gdal instead of r.in.gdal same with Files -- Import vector map -- mutiple format using ogr is calling v.out.gdal instead of v.in.ogr On Jun 15, 2007, at 8:10 PM, Michael Barton wrote: > Because this is somewhat complicated to do, there are probably some > hidden > gotchas in there somewhere (command arguments with spaces will > probably fail > currently, for example; we're trying to fix this). But it should > work for > 90%+ of what people will do. > > Michael > > > On 6/15/07 9:18 AM, "Maciej Sieczka" wrote: > >> Michael Barton wrote: >> >>> full command line access to all GRASS commands; d.* commands >>> called from the >>> command line can display in the wxPython canvas. >> >> This is great. I was missing such functionality for gis.m's map >> canvas. >> >> Maciek > > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > _______________________________________________ > 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/20070618/3889be70/attachment.html From cdavilam at jemila.jazztel.es Mon Jun 18 20:09:55 2007 From: cdavilam at jemila.jazztel.es (=?ISO-8859-1?Q?Carlos_D=E1vila?=) Date: Mon Jun 18 20:08:16 2007 Subject: [GRASS-dev] Message standardization In-Reply-To: <20070618221009.78c8ac55.hamish_nospam@yahoo.com> References: <20070613213629.27dddaa2.hamish_nospam@yahoo.com> <20070618221009.78c8ac55.hamish_nospam@yahoo.com> Message-ID: <4676CA73.2000904@jemila.jazztel.es> Hamish escribi?: > Michael Barton wrote: > >> Module descriptions are a different sort of beast from error >> messages--and from GUI messages and other descriptors. All need >> standardization, but I'd recommend doing them one at a time so as not >> to overwhelm everyone. >> >> If we can standardize error messages first it might be the simplest >> piece to attack. Then move on to others like module descriptions in >> the module code, module doc formatting, GUI, etc. >> > > > I would consider module and option/flag descriptions much easier "low- > hanging fruit" than error messages. For them the rules are simpler, > > - module descriptions end with a "." > - option/flag descriptions do not. > - Multi-sentence descriptions are probably good candidates to break up > into a short ->label + a ->description to hold additional info. > - Begin with a capital letter. > - Don't pad whitespace. > > > For standard error/warning messages (ie the ones that always come right > after G_open_file() or whatever) we can pick something nice and specify > that on the wiki page to avoid repetitious translations of almost > identical messages. > > For the vast majority of error/warning/regular messages, they are > single-use, module dependant, and maybe put there by the programmer on a > just-in-case basis, ie they may never be seen by a user. Contrast that > with the module description and option descriptions which have high > exposure, & thus greater result from a translator's time. > > library translations have high-reuse value. > GUI translations have high-exposure value. > > > 2c, > Hamish > > Another issue to discuss: module descriptions currently have verbs both in infinitive and present, depending on the module. We should choose only one tense, infinitive IMHO. Carlos From glynn at gclements.plus.com Mon Jun 18 21:08:15 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jun 18 21:08:27 2007 Subject: [GRASS-dev] d.rast.edit in wxgrass In-Reply-To: References: <18036.17115.635018.899702@cerise.gclements.plus.com> Message-ID: <18038.55327.338952.805093@cerise.gclements.plus.com> Paul Kelly wrote: > >>> If the command has no arguments (i.e., len(cmdlist) == 0) AND it is NOT a > >>> d.* command, send the original command string (not the list) to the > >>> menuform.py processor (just like the menu would) to create the autogenerated > >>> properties dialog. After this, the result of hitting "run" is the same as if > >>> the properties dialog were called from the menu. > >> > >> I don't get why it needs to do that specific processing - can you not just > >> run whatever is entered - if a command is run without arguments it will > >> pop up the GUI dialog anyway. Unless GRASS_UI_TERM is set. I suppose at > >> the minute it will always be a Tcl/Tk dialog that pops up, but I'm sure it > >> wouldn't be very hard to change G_parser() to check the GRASS_GUI variable > >> (or do something similar) and generate the correct autogenerated dialog > >> corresponding to the GUI that's in use. > > > > If you're running the command from a GUI, it's preferable for the > > dialogs to be generated by the GUI process rather than as a standalone > > process. > > > > E.g. if you select a command from gis.m's menus, gis.m invokes the > > command using the --tcltk and evaluates the output (with certain > > procedures overriden, e.g. run_cmd), rather than simply running the > > command using --ui. > > > > This has the advantage that the GUI gets to see (and optionally > > modify) the arguments which were actually used, so that it can e.g. > > record the complete command in a history list. If you just use --ui, > > the re-invocation is hidden from the GUI. > > Ah I see, I think. That sounds pretty important. But it does it mean that > tricks the module may do such as checking if there are any command-line > arguments before running G_parser() will be ineffective? If you add --ui or --tcltk, an "argc > 1" check will pass, so G_parser() will be invoked. Such a check only makes sense if you have no required arguments. If you have required arguments, the user will either have to enter them or the command line or in the GUI dialog. If the defaults for any optional arguments are good, adding a check means that the user doesn't keep getting prompted for arguments where the defaults will suffice. E.g. d.erase has the check, so "d.erase" is equivalent to "d.erase color=white" rather than to "d.erase --ui". OTOH, if it's unlikely that the user will want to simply accept the defaults, the check should be omitted. > I didn't realise gis.m worked like this too - might there be any value > then in removing the functionality that commands run from the command-line > pop up a GUI window when run with no arguments, i.e. behave as if > GRASS_UI_TERM was set? Was this behaviour only needed for d.m perhaps? The current behaviour was intended as an improvement over the terminal-based Q&A dialogue; it wasn't designed with d.m or gis.m in mind. The --ui option was added later to allow the "argc>1" check to be bypassed, so that d.m could display a dialog for commands with such a check. The --tcltk option was added to allow better integration with gis.m. -- Glynn Clements From glynn at gclements.plus.com Mon Jun 18 21:16:14 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jun 18 21:16:17 2007 Subject: [GRASS-dev] simplify G_convert_dirseps_to_host(G_tempfile()) ? In-Reply-To: References: <20070618200229.206fca3d.hamish_nospam@yahoo.com> Message-ID: <18038.55806.39900.999786@cerise.gclements.plus.com> Paul Kelly wrote: > FWIW I've attached my proposed changes to lib/gis/tempfile.c that I still > have in my local source tree. They were intended to split the usage of > G_tempfile() between modules that are genuinely using it as a tempfile for > creating large temporary maps as was originally intended, and those that > are just using it as a general small tempfile function. They also make > some changes to make it more Windows compatible. But we decided they were > too controversial to commit in case they broke things - maybe in some way > we can eventually merge them though. A safe starting point would be to: 1. Rename G__tempfile() to G__tempfile_in_mapset(). 2. Add: char *G__tempfile(int pid) { return G__tempfile_in_mapset(pid); } 3. Change opencell.c (and anything else known to require the existing behaviour) to use G__tempfile_in_mapset() instead of G__tempfile(). Once that's done, any new G__tempfile() implementation can easily be reverted if it's found to cause problems. -- Glynn Clements From maris.gis at gmail.com Tue Jun 19 11:36:14 2007 From: maris.gis at gmail.com (Maris Nartiss) Date: Tue Jun 19 11:36:18 2007 Subject: [GRASS-dev] Compile error on Kubuntu 7.04 In-Reply-To: <1a486f560706081445q4ab40124hf7bf7643dfde7e74@mail.gmail.com> References: <4f33f75e0706081414n38357ffftdcbf7627fc0a16d@mail.gmail.com> <1a486f560706081445q4ab40124hf7bf7643dfde7e74@mail.gmail.com> Message-ID: <2b3d8c1c0706190236j105bef7fxd246c277d9186d8f@mail.gmail.com> Shouldn't missing gettext (msgfmt) executable been catched by "./configure --with-nls" as error? IMHO this should be reported as bug. Maris. 2007/6/9, Daniel Calvelo : > Hi Isaac. You don't seem to have gettext installed. Try to apt-get > install gettext. > > Daniel. > > On 6/8/07, Isaac Ullah wrote: > > Hi Listers, > > > > I am trying to compile GRASS-6.3.cvs on my recently installed Kubuntu > > (7.04, Fiesty Fawn) system. I've successfully compiled before on the same > > laptop (a toshiba r 10) under MEPIS 6 (also ubuntu based) and MEPIS 3.4.2 > > (debian based). However this time I get the following error that I don't > > really understand: > > > > make[1]: Entering directory > > `/home/isaac/Desktop/grass63-cvs-source/locale' > > Creating translations (= 'make mo') > > make[2]: Entering directory > > `/home/isaac/Desktop/grass63-cvs-source/locale' > > grasslibs_ar.po: /bin/sh: msgfmt: not found > > grasslibs_cs.po: /bin/sh: msgfmt: not found > > grasslibs_de.po: /bin/sh: msgfmt: not found > > grasslibs_el.po: /bin/sh: msgfmt: not found > > grasslibs_es.po: /bin/sh: msgfmt: not found > > grasslibs_fr.po: /bin/sh: msgfmt: not found > > grasslibs_hi.po: /bin/sh: msgfmt: not found > > grasslibs_it.po: /bin/sh: msgfmt: not found > > grasslibs_ja.po: /bin/sh: msgfmt: not found > > grasslibs_ko.po: /bin/sh: msgfmt: not found > > grasslibs_lv.po: /bin/sh: msgfmt: not found > > grasslibs_mr.po: /bin/sh: msgfmt: not found > > grasslibs_pl.po: /bin/sh: msgfmt: not found > > grasslibs_pt_br.po: /bin/sh: msgfmt: not found > > grasslibs_ru.po: /bin/sh: msgfmt: not found > > grasslibs_sl.po: /bin/sh: msgfmt: not found > > grasslibs_tr.po: /bin/sh: msgfmt: not found > > grasslibs_vi.po: /bin/sh: msgfmt: not found > > grasslibs_zh.po: /bin/sh: msgfmt: not found > > grassmods_ar.po: /bin/sh: msgfmt: not found > > grassmods_cs.po: /bin/sh: msgfmt: not found > > grassmods_de.po: /bin/sh: msgfmt: not found > > grassmods_el.po: /bin/sh: msgfmt: not found > > grassmods_es.po: /bin/sh: msgfmt: not found > > grassmods_fr.po: /bin/sh: msgfmt: not found > > grassmods_hi.po: /bin/sh: msgfmt: not found > > grassmods_it.po: /bin/sh: msgfmt: not found > > grassmods_ja.po: /bin/sh: msgfmt: not found > > grassmods_ko.po: /bin/sh: msgfmt: not found > > grassmods_lv.po: /bin/sh: msgfmt: not found > > grassmods_mr.po: /bin/sh: msgfmt: not found > > grassmods_pl.po: /bin/sh: msgfmt: not found > > grassmods_pt_br.po: /bin/sh: msgfmt: not found > > grassmods_ru.po: /bin/sh: msgfmt: not found > > grassmods_sl.po: /bin/sh: msgfmt: not found > > grassmods_tr.po: /bin/sh: msgfmt: not found > > grassmods_vi.po: /bin/sh: msgfmt: not found > > grassmods_zh.po: /bin/sh: msgfmt: not found > > grasstcl_ar.po: /bin/sh: msgfmt: not found > > grasstcl_cs.po: /bin/sh: msgfmt: not found > > grasstcl_de.po: /bin/sh: msgfmt: not found > > grasstcl_el.po: /bin/sh: msgfmt: not found > > grasstcl_es.po: /bin/sh: msgfmt: not found > > grasstcl_fr.po: /bin/sh: msgfmt: not found > > grasstcl_hi.po: /bin/sh: msgfmt: not found > > grasstcl_it.po: /bin/sh: msgfmt: not found > > grasstcl_ja.po: /bin/sh: msgfmt: not found > > grasstcl_ko.po: /bin/sh: msgfmt: not found > > grasstcl_lv.po: /bin/sh: msgfmt: not found > > grasstcl_mr.po: /bin/sh: msgfmt: not found > > grasstcl_pl.po: /bin/sh: msgfmt: not found > > grasstcl_pt_br.po: /bin/sh: msgfmt: not found > > grasstcl_ru.po: /bin/sh: msgfmt: not found > > grasstcl_sl.po: /bin/sh: msgfmt: not found > > grasstcl_tr.po: /bin/sh: msgfmt: not found > > grasstcl_vi.po: /bin/sh: msgfmt: not found > > grasstcl_zh.po: /bin/sh: msgfmt: not found > > make[2]: *** [mo] Error 127 > > make[2]: Leaving directory > > `/home/isaac/Desktop/grass63-cvs-source/locale' > > make[1]: *** [default] Error 2 > > make[1]: Leaving directory > > `/home/isaac/Desktop/grass63-cvs-source/locale' > > make: *** [default] Error 2 > > > > Does anyone know what the problem is here? I've never seen this error > during > > any of the other times I've compiled GRASS... Any help would be greatly > > appreciated! > > > > Cheers, > > > > Isaac > > > > > > -- > > > > Isaac I Ullah, M.A. > > > > Archaeology PhD Student, > > ASU School of Evolution and Social Change > > > > Research Assistant, > > Mediterranean Landscape Dynamics Project > > *************************************************** > > isaac.ullah@asu.edu > > ullah@archaeologist.com > > > > http://www.public.asu.edu/~iullah > > *************************************************** > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev > > > > > -- > -- Daniel Calvelo Aros > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From pmarc.debian at gmail.com Tue Jun 19 13:39:12 2007 From: pmarc.debian at gmail.com (Paulo Marcondes) Date: Tue Jun 19 13:39:20 2007 Subject: [GRASS-dev] Issues with font rendering in tkgrass Message-ID: <8dbfdbff0706190439y7b7d6f1amf399584f3d6a5e85@mail.gmail.com> Hi all, As I finished translating grasstcl to portuguese, I compiled and fired GRASS to see thee looks of it (the translation). The issue is with some accented characters that are far too common in portuguese to let them pass by. I means specificaly ?, ? ('a' or 'o' with a tilde) and also ? ('e' with a circumflex accent). Those were those I found in my quick look. Also, I have another 'complain' - in the GRASS initialization screen, the sentence is wrapping badly. I would change the wording if I could figure a better one. Maximizing screen has no efect on the wrap. There is a screenshot at http://paulomarcondes.googlepages.com/grass_ptbr.png -- PMarc: Debian, GIS, gpsd, OpenWRT user and wannabe-devel Lives @ -22.915 -42.224 From cdavilam at jemila.jazztel.es Tue Jun 19 16:19:27 2007 From: cdavilam at jemila.jazztel.es (=?UTF-8?B?Q2FybG9zIETDoXZpbGE=?=) Date: Tue Jun 19 16:17:44 2007 Subject: [GRASS-dev] Message standardization In-Reply-To: <8dbfdbff0706190426k10d156c3k41865b34edb8685e@mail.gmail.com> References: <20070613213629.27dddaa2.hamish_nospam@yahoo.com> <20070618221009.78c8ac55.hamish_nospam@yahoo.com> <4676CA73.2000904@jemila.jazztel.es> <8dbfdbff0706190426k10d156c3k41865b34edb8685e@mail.gmail.com> Message-ID: <4677E5EF.40401@jemila.jazztel.es> Paulo Marcondes escribi?: > 2007/6/18, Carlos D?vila : >> Another issue to discuss: module descriptions currently have verbs both >> in infinitive and present, depending on the module. We should choose >> only one tense, infinitive IMHO. > > +1 > > Shall I point the utility of a wikipage for all these musings? > > Carlos, as you are doing all the asking, could you sum it all up on a > page? > That should help other translators too. They are already here: http://grass.gdf-hannover.de/wiki/Development_Specs From grass-codei at wald.intevation.org Wed Jun 20 14:34:59 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Wed Jun 20 14:34:56 2007 Subject: [GRASS-dev] [grass-code I][430] i.group allows gr= and subgr= entries and creates group/REF file Message-ID: <20070620123459.0CB4840FB3@pyrosoma.intevation.org> code I item #430, was opened at 2007-06-20 12:34 Status: Open Priority: 3 Submitted By: Otto Dassau (dassau) Assigned to: Nobody (None) Summary: i.group allows gr= and subgr= entries and creates group/REF file Issue type: module bug Issue status: None GRASS version: CVS HEAD GRASS component: imagery Operating system: Linux Operating system version: GRASS CVS checkout date, if applies (YYMMDD): 070618 Initial Comment: Hi, nothing seriuos, the module i.group allows to define empty group and subgroup entries and writes a REF file to $MAPSET/group/REF. command: i.group gr= subgr= in=c.blue,c.green,c.red Gruppe [] existiert noch nicht. Erstelle sie... F?ge Dateien zur Gruppe [] hinzu. F?ge Rasterkarte [c.blue] hinzu. F?ge Rasterkarte [c.green] hinzu. F?ge Rasterkarte [c.red] hinzu. Schreibe Gruppen REF. Fertig. F?ge Dateien zur Untergruppe [] hinzu. F?ge Rasterkarte [c.blue] hinzu. F?ge Rasterkarte [c.green] hinzu. F?ge Rasterkarte [c.red] hinzu. Schreibe Untergruppen REF. Fertig. The new REF file is stored under: $MAPSET/group/REF c.blue testdata c.green testdata c.red testdata So, it would be helpful to test, if there are names provided for group and subgroup parameters. thanks a lot, Otto ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=430&group_id=21 From grass-codei at wald.intevation.org Wed Jun 20 15:53:14 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Wed Jun 20 15:53:12 2007 Subject: [GRASS-dev] [grass-code I][431] g.copy segmentation fault Message-ID: <20070620135314.9534A40FB3@pyrosoma.intevation.org> code I item #431, was opened at 2007-06-20 13:53 Status: Open Priority: 3 Submitted By: Otto Dassau (dassau) Assigned to: Nobody (None) Summary: g.copy segmentation fault Issue type: module bug Issue status: None GRASS version: CVS HEAD GRASS component: general Operating system: Linux Operating system version: debian testing GRASS CVS checkout date, if applies (YYMMDD): 070620 Initial Comment: the module g.copy segfaults. example g.copy rast=objekthoehen20,muell10 Copy raster to current mapset as Speicherzugriffsfehler with gdb I get following message (maybe helpful): Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1242368304 (LWP 12305)] do_copy (n=0, old=0x80506b8 "objekthoehen20", mapset=0x8050800 "testdaten", new=0x80506d0 "muell") at do_copy.c:40 /data/software/grass6/general/manage/lib/do_copy.c:40:964:beg:0x8049abd (gdb) I have another CVS version running from 20070604 and it works there. And I start the segfaulting grass version from cvs directory (no make install). Could that be a problem? thanks, Otto ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=431&group_id=21 From dfinlayson at usgs.gov Thu Jun 21 19:51:07 2007 From: dfinlayson at usgs.gov (David Finlayson) Date: Thu Jun 21 19:51:13 2007 Subject: [GRASS-dev] Re: report on raster point creation In-Reply-To: References: <20070614214552.0c3b930f.hamish_nospam@yahoo.com> Message-ID: Michael - I often couple GRASS to numerical models or complex grid-based computations using the following method: Step 1: Export the environmental grids needed for the model using r.out.arc(an easy format to parse in Python) or a simple binary format. Step 2: Read the data into a Python class that represents the grid as a 2D array (numeric is great for this). The class also has a few helper methods such as: read_grid(), write_grid(), get(x, y), set(x,y), etc. Step 3: Run the model Step 4: Dump the python grid back to the ASCII Grid format (or raw binary) Step 5: Read the data back into GRASS using r.in.arc (etc) Most of the work in the model occurs in Steps 2-4 where there is no overhead on the model due to carrying around the GIS baggage. You could use python, R, Matlab, whatever. As an unsolicited aside, C is actually a pretty good language for grid-based models when one uses a numerical library such as the GNU Scientific Library to handle the matrix (grid) stuff. Two bonuses to using C are the increase in performance of the model and by the end of the project, you have learned enough C to read and start using the GRASS source code directly. Not only that, but there are lots of GIS-related libraries (i.e., GDAL, Proj4, Shapelib) that are easy to use from C once you learn the basics. I resisted C for years because Python was good enough and C was "hard". Today I think that was being penny-wise and pound foolish. There are many projects in GIS where speed really matters. Whether you are filtering a very large Lidar data set, or running a very small model millions of times (such as in a Monte Carlo simulation), speed really matters in these cases. The huge library of existing C code is real boon, too. I find that for small projects (< 10k lines of code) C is a pretty good language; its warts don't show up until project get really large. And like I said, it's nice to be able to customize GRASS source when you need to. Cheers, David On 6/14/07, Michael Barton wrote: > > Thanks very much. I'll need to digest all this useful information later > today, but it is helpful. I'll check r.in.xyz and your update to r.in.poly > and get back to you. > > Michael > > > On 6/14/07 2:45 AM, "Hamish" wrote: > > > Michael Barton wrote: > >> We have finally had an initial production test of methods to create a > >> raster point using xy coordinates. If you remember, I've periodically > >> whined a bit about the lack of a way to create and change a raster > >> cell based on its xy coordinates instead of its cat value. > >> > >> The 2 suggestions I got to work around this were to... > >> > >> 1) use r.in.poly to create the raster map; make an input file such > >> that for each point, the input is set to line (L) with 2 points that > >> are identical. > > > > To make that method easier I have just added a "P" instruction to > > r.in.poly in 6.3cvs. That uses G_plot_point(), which draws a 0 length > > line using the same method, so probably it doesn't fix your 2 cell if > > on bound problem (?? try it and see). > > > >> 2) use v.in.ascii and then use v.to.rast to create the raster map. > > > > Note the v.to.rast code is ~95% a clone of the r.in.poly code, so > results > > (and problems) should be mostly the same. Do you see the same multiple > > cell trouble if the point falls on a bound using this method? > > > > It probably needs to be noted in the v.to.rast help page if it does, at > > minimum. > > > > > > 3) use r.in.xyz (I expect this will be the fastest method) > > > > 4) r.mapcalc outmap='if( (abs(x() - $x)) < ewres()) \ > > && (abs(y() - $y) < nsres(), $val, null() )' > > [or something like that, for a single point; yuk] > > > > 5) do the gridding yourself and create a r.in.ascii file. > > > > all these would need to be followed by a call to r.patch. > > (see d.rast.edit.tcl method) > > > > > >> We are coupling an agent-based simulation to GRASS, such that the > >> simulated land use activities will affect land cover, which in turn > >> will affect a landscape evolution routine. > > > > are you updating a sequential string of cells, blocks of cells, or > > random cells at each update? > > > > > >> Optimizing the speed of this is critical, and so we prefer to reduce > >> the number of steps needed to accomplish this. This means that the > >> r.in.poly approach is the one we prefer. However, in tests conducted > >> today, we ran into an unexpected problem. > >> > >> If the coordinate of the point to be created happens to fall on a cell > >> boundary, we get a 2-cell 'line' instead of a point even though the > >> beginning and end points are identical. Apparently, r.in.poly looks > >> for a cell center closest to end point one and then searches for a > >> cell center for end point 2 that is different from the first cell, > >> resulting in a 2 cell line. This does not happen if the point does not > >> fall on a cell boundary. Attached is the raster file created from the > >> following r.in.poly input. The first input creates the 2 yellow cells, > >> the other 2 create the red and green single cells. > > > > r.in.poly/raster.c defines the "cont" continue line fn used by > > G_setup_plot() (and thus all following G_plot_*() commands) with > > G_bresenham_line(). That in turn uses the "dot" fn to draw the points; > > which "dot" is used depends on the result of the getformat() scan of > > the cat values (& I'm about foggy about what that's all about). > > > > for info on the Bresenham line rasterization method see: > > http://en.wikipedia.org/wiki/Bresenham's_line_algorithm > > > > > >> This is a potential problem, since an agent might not know that the > >> the coordinates it chooses for a field to farm or graze like on a cell > >> boundary. It is OK if r.in.poly substitutes the nearest grid cell > >> center to make the raster point for the xy coordinates that the agent > >> chooses, but not OK if it picks 2 different cells instead of one. > > > > Try r.in.xyz, it shouldn't suffer from this: on one side of the cell it > > tests for <= and on the other side <. So a point on a bound always fall > > in the <= cell. The exception is the outer E,W raster boundaries which > > will make values fall "into" the raster if on the bound. > > > > r.in.xyz doesn't let you add cat labels, but you can do that manually by > > creating a cats/ file. See spearfish60/PERMANENT/cats/landuse for an > > example, it's very simple. > > > > > >> The simplest solution is to allow r.in.poly to make points as well as > >> lines and areas. I'm not sure why it doesn't allow points in the first > >> place. It seems like an oversight. Is this difficult to implement? > > > > done, but I don't think it will help any due to the way G_plot_point() > > works. > > > > > >> * * * * > >> > >> Also, there is still no one-step way to change a cell value based on > >> its xy coordinates. > > > > So you want a non-interactive d.rast.edit, like v.edit? > > > > A couple of ways to do that, 1) get input x1,y1,cat1 ... from stdin, > > qsort() based on y then x, read each line and if there's an updated > > cell in it replace it before writing the row back out. (as r.patch) > > 2) calculate the array column,row which contains each x,y and update > > each in the order they arrive (as r.in.xyz). Probably the fastest way is > > a combination of the two. Sort by y, and for each row update the column > > values in the order they arrive, then write out the finished line and > > move on to the next row. > > > > > >> However, if there is interest in doing agent and cellular modeling > >> within a GRASS platform, it will become necessary to be able to do > >> this to simulate dynamics. Patching may simply not be practical for > >> this kind of work. As Python becomes more used as a scripting > >> environment, this is an attractive kind of application to build in > >> Python, given its object oriented structure, and couple with GRASS. > > > > The module probably isn't so hard to write, in C. r.example should give > > a nice start. > > > > It would be interesting to rewrite r.example.c using the SWIG Python > > interface, and see if that gains any simplicity over C, or if it just > > adds complexity without simplicity -- as you still need to go through > > all the same chores. > > > > > > Hamish > > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > _______________________________________________ > 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/20070621/1f4da7f6/attachment-0001.html From michael.barton at asu.edu Sat Jun 23 17:07:17 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Jun 23 17:07:25 2007 Subject: [GRASS-dev] resolving more menu issues In-Reply-To: <20070618213331.049ded38.hamish_nospam@yahoo.com> Message-ID: Thanks. Are the menu references to these changed too? Now that I'm back, I hope to make r.reclass.rules and r.recode.rules obsolete for TclTk like I did for wxPython. I'm hoping that r.reclass.file and r.recode.file can be made obsolete with slight changes to the C-modules too. Michael On 6/18/07 2:33 AM, "Hamish" wrote: > Hamish: >>> it would be nice to move generic wrapper scripts which are just >>> needed for a GUI/core interaction (ie nothing to do with tcl or wx) >>> from gui/tcltk/gis.m/script/ to gui/scripts/ > > Now done for non-obsolete scripts. After install they live in > $GISBASE/etc/gui/scripts/. > > d.shadedmap moved to the main script/ dir, now it's a normal module. > > I added a -d flag to d.title to run G_system(d.text) automatically, so > d.title.sh is now obsolete. > > the rest of the GUI wrapper scripts should be removed once the modules > they wrap become more GUI-friendly (ie sometime before GRASS 7): > > - r.reclass, r.recode, r.colors, take input from a file= option as an > alternative to stdin; better- write a GUI to help make the input file > then run r.reclass with that) > > - d.path has a coor= option now, so it can be used non-interactively. > i.e. the GUI can pick the two coords interactively and then run the > module non-interactively and display the result. > > - The r.support bug is still weird. (breaks out after two [y/n] > questions if run directly in an xterm) > > > > hopefully no problems, > > Hamish __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Sat Jun 23 17:08:44 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Jun 23 17:08:49 2007 Subject: [GRASS-dev] Message standardization In-Reply-To: <20070618221009.78c8ac55.hamish_nospam@yahoo.com> Message-ID: You have my support for all of this. Michael On 6/18/07 3:10 AM, "Hamish" wrote: > Michael Barton wrote: >> >> Module descriptions are a different sort of beast from error >> messages--and from GUI messages and other descriptors. All need >> standardization, but I'd recommend doing them one at a time so as not >> to overwhelm everyone. >> >> If we can standardize error messages first it might be the simplest >> piece to attack. Then move on to others like module descriptions in >> the module code, module doc formatting, GUI, etc. > > > I would consider module and option/flag descriptions much easier "low- > hanging fruit" than error messages. For them the rules are simpler, > > - module descriptions end with a "." > - option/flag descriptions do not. > - Multi-sentence descriptions are probably good candidates to break up > into a short ->label + a ->description to hold additional info. > - Begin with a capital letter. > - Don't pad whitespace. > > > For standard error/warning messages (ie the ones that always come right > after G_open_file() or whatever) we can pick something nice and specify > that on the wiki page to avoid repetitious translations of almost > identical messages. > > For the vast majority of error/warning/regular messages, they are > single-use, module dependant, and maybe put there by the programmer on a > just-in-case basis, ie they may never be seen by a user. Contrast that > with the module description and option descriptions which have high > exposure, & thus greater result from a translator's time. > > library translations have high-reuse value. > GUI translations have high-exposure value. > > > 2c, > Hamish __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From grass-codei at wald.intevation.org Sat Jun 23 18:29:54 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Sat Jun 23 18:29:36 2007 Subject: [GRASS-dev] [grass-code I][434] g.proj -wef command returns WKT string without prefix Message-ID: <20070623162954.2216340129@pyrosoma.intevation.org> code I item #434, was opened at 2007-06-23 18:29 Status: Open Priority: 3 Submitted By: Markus Neteler (markusn) Assigned to: Nobody (None) Summary: g.proj -wef command returns WKT string without prefix Issue type: module bug Issue status: None GRASS version: CVS HEAD GRASS component: None Operating system: all Operating system version: GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: Cross-bug from GDAL: http://trac.osgeo.org/gdal/ticket/1656#comment:5 g.proj -wef command returns ESRI WKT string without the ESRI:: prefix, and that's why transformations fail. To simplify user's live, we should add the prefix in case of -e flag specified. Markus ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=434&group_id=21 From michael.barton at asu.edu Sat Jun 23 19:37:16 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Jun 23 19:37:22 2007 Subject: [GRASS-dev] [grass-code R][428] Warn about wrong epsg code when creating a location in grass 6.2 In-Reply-To: <20070616213901.5C2AEB53C0@pyrosoma.intevation.org> Message-ID: AFAICT, there is no way for the GUI to know if an EPSG code is bad. Perhaps g.proj can test for this, but I wouldn't count on it. The procedure to create a location from a georeferenced file is different from the procedure to create it from an EPSG code, so I'm not sure what you are referring to below. Michael On 6/16/07 2:39 PM, "grass-coder@wald.intevation.org" wrote: > code R item #428, was opened at 2007-06-16 18:39 > Status: Open > Priority: 3 > Submitted By: Daniel Victoria (dvictori) > Assigned to: Nobody (None) > Summary: Warn about wrong epsg code when creating a location in grass 6.2 > Issue status: None > GRASS component: startup > Operating system: None > Operating system version: Linux > > > Initial Comment: > When creating a location based on a georeferenced files, if the EPSG code is > wrong there is no clear warning and no location gets created. This feature is > already present in 6.3. Could it be backported? > > Also, if a wrong EPSG code is input a tmp directory sometimes is created > thanks > Daniel > > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://wald.intevation.org/tracker/?func=detail&atid=188&aid=428&group_id=21 > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From cdavilam at jemila.jazztel.es Sat Jun 23 20:16:49 2007 From: cdavilam at jemila.jazztel.es (=?ISO-8859-15?Q?Carlos_D=E1vila?=) Date: Sat Jun 23 20:14:47 2007 Subject: [GRASS-dev] GRASS translation statistics Message-ID: <467D6391.1040700@jemila.jazztel.es> Does anybody know why statistics in http://grass.itc.it/devel/i18n.php#statistics are not been updated? Carlos From neteler at itc.it Sat Jun 23 20:57:15 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Jun 23 20:57:19 2007 Subject: [GRASS-dev] GRASS translation statistics In-Reply-To: <467D6391.1040700@jemila.jazztel.es> References: <467D6391.1040700@jemila.jazztel.es> Message-ID: <11269185.post@talk.nabble.com> Carlos D?vila wrote: > > Does anybody know why statistics in > http://grass.itc.it/devel/i18n.php#statistics are not been updated? > > Carlos > Yes. The cronjob was broken due to a CVS update error (lib/init/grass-xterm-wrapper contained nonsense in the local directory for unknown reasons). Cronjob fixed, tables are updated now. Thanks for the hint. Markus -- View this message in context: http://www.nabble.com/GRASS-translation-statistics-tf3970090.html#a11269185 Sent from the Grass - Dev mailing list archive at Nabble.com. From neteler at itc.it Sat Jun 23 22:43:12 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Jun 23 22:43:17 2007 Subject: [GRASS-dev] d.vect.thematic: v.univar.sh -> v.univar? In-Reply-To: <1a486f560705022218k3317ed08wf3084f12807ebf68@mail.gmail.com> References: <20070501152503.GB19013@bartok.itc.it> <20070502090258.GA27153@bartok.itc.it> <1a486f560705021952o3c5787fbla35fe06afb9f93bd@mail.gmail.com> <1a486f560705022151x5e1fadf4xa2cc1451b0ef136c@mail.gmail.com> <1a486f560705022218k3317ed08wf3084f12807ebf68@mail.gmail.com> Message-ID: <11270068.post@talk.nabble.com> Daniel Calvelo wrote: > > Replying to myself twice, sorry. > > After reading v.univar/main.c more thoroughly, I think I'm > understanding the issue: v.univar.sh is *not* a shell equivalent of > v.univar. Actually, v.univar.sh should have been called v.db.univar. > > [...] > > -- > -- Daniel Calvelo Aros > While working on the book, I came across this issue again. I have added it now as scripts/v.db.univar in CVS. Markus -- View this message in context: http://www.nabble.com/d.vect.thematic%3A-v.univar.sh--%3E-v.univar--tf3675636.html#a11270068 Sent from the Grass - Dev mailing list archive at Nabble.com. From neteler at itc.it Sat Jun 23 23:41:22 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Jun 23 23:41:24 2007 Subject: [GRASS-dev] v.lrs.where users wanted Message-ID: <20070623214121.GA10369@bartok.itc.it> Hi, I finally got my LRS working (playing with the busroute in the new NC dataset). The trick is to have the route built as polyline (v.build.polylines), otherwise you will get crazy to figure out the milepost order. - documentation updated - v.lrs.label now works (SQL fix in CVS) - v.lrs.where: Then I tested v.lrs.where and discovered that the "offset" was reported incorrectly. I have fixed it in CVS but would like to ask LRS users to test if it still works ok for you. Please let me know. - v.lrs.segment: still to test, seems to do something Related question: how to add a new milepost into an existing LRS? 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 michael.barton at asu.edu Sun Jun 24 01:25:10 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Jun 24 01:25:16 2007 Subject: [GRASS-DEV] In wxgrass File menu import vector calls v.out.ogr In-Reply-To: <58C1BBA1-B89A-4F8C-8EC5-DB7FA73D1AF0@uv.es> Message-ID: I just fixed this (I hope) throughout the menu. I tried to make it compact and regular, but forgot that each menu item needs to be unique in order for wxPython to find the command associated with the menu item. So I've tried to differentiate each item with a little more text. Michael On 6/18/07 8:39 AM, "Agustin Diez Castillo" wrote: > Hi, > wxgrass gui is calling the wrong command. > At least here, menu Files -- Import raster map -- mutiple format using gdal is > calling r.out.gdal instead of r.in.gdal > same with?Files -- Import vector map -- mutiple format using ogr is calling > v.out.gdal instead of v.in.ogr > > > > On Jun 15, 2007, at 8:10 PM, Michael Barton wrote: > >> Because this is somewhat complicated to do, there are probably some hidden >> gotchas in there somewhere (command arguments with spaces will probably fail >> currently, for example; we're trying to fix this). But it should work for >> 90%+ of what people will do. >> >> Michael >> >> >> On 6/15/07 9:18 AM, "Maciej Sieczka" wrote: >> >> >>> Michael Barton wrote: >>> >>> >>>> full command line access to all GRASS commands; d.* commands called from >>>> the >>>> command line can display in the wxPython canv