http://blog.gmane.org/gmane.comp.gis.grass.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.gis.grass.devel/47891 <pre>Hi all! as reported in the new web page [0] of the pyGRASS project, at the moment you can interact with a raster map in this way (read-only): :: # import the raster function &gt;&gt;&gt; import obj # instantiate a Raster &gt;&gt;&gt; dtm = obj.Raster('dtm') # open the raster in read mode 'r' &gt;&gt;&gt; dtm.open() # get access &gt;&gt;&gt; for row in dtm[:5]: print(row[:3]) [718.0910034179688, 717.8709716796875, 717.551025390625] [718.0910034179688, 717.8709716796875, 717.551025390625] [718.0910034179688, 717.8709716796875, 717.551025390625] [718.0910034179688, 717.8709716796875, 717.551025390625] [718.0910034179688, 717.8709716796875, 717.551025390625] &gt;&gt;&gt; dtm[5][:3] [718.051025390625, 717.7310180664062, 717.4210205078125] &gt;&gt;&gt; dtm.close() Any hint or suggestion are welcome! The Raster class use only the grass ctypes library. This report and the following ones will be available to the wiki page [1]. [0] http://code.google.com/p/pygrass/ [1] http://grass.osgeo.org/wiki/GRASS_SoC_Ideas_2012/High_level_map_interaction#Weekly_reports </pre> Pietro 2012-05-25T14:57:12 http://comments.gmane.org/gmane.comp.gis.grass.devel/47890 <pre>Hi! In grass_trunk (compiled today), the command "d.rast -h" executed in the "Command console" tab, within GRASS GIS Layer Manager, adds a "-h" entry in the "Map layers" tab/list. Of course no map "-h" does exist. Moreover, it would be nice for the wx- command-console to automatically translate "-h" to "-help". Thanks, Nikos ps- playing a bit around with the latest wxGUI (within from/using grass_trunk). I wish many of the rich features in the (may I call it) wx- command-console (?) had been available long ago within the "default" grass- shell :-/ </pre> Nikos Alexandris 2012-05-25T14:38:15 http://comments.gmane.org/gmane.comp.gis.grass.devel/47889 <pre>#1664: Texts in command dialogs are garbled ----------------------------------+----------------------------------------- Reporter: wenzeslaus | Owner: grass-dev&lt; at &gt;… Type: defect | Status: new Priority: normal | Milestone: Component: Default | Version: unspecified Keywords: encoding translation | Platform: MSWindows 7 Cpu: Unspecified | ----------------------------------+----------------------------------------- Generated command dialogs show garbled texts. It does not apply to buttons and other strings which comes directly from Python code. It applies to string which comes from module option description (but with some translation activated). Acutes and other diacritics signs are shown before letters. However this is detail and it can differ between languages/encodings. It is necessary to test this with language which uses non-ascii characters. System encoding has to be other than UTF-8. It is not known if this can be reproduced on systems other than Windows. Problem can by in piping and reading piped text. It happens in files: {{{ lib/gis/parser_interface.c lib/python/task.py }}} </pre> GRASS GIS 2012-05-25T09:09:17 http://comments.gmane.org/gmane.comp.gis.grass.devel/47887 <pre>#1663: Tabs in C source code --------------------------------+------------------------------------------- Reporter: wenzeslaus | Owner: grass-dev&lt; at &gt;… Type: defect | Status: new Priority: normal | Milestone: Component: Default | Version: unspecified Keywords: indent tabs spaces | Platform: All Cpu: All | --------------------------------+------------------------------------------- I assume that GRASS C source code should be indented with spaces, more precisely with spaces only. And more over, mixing tabs and spaces is a bad practice. But C source files contains both spaces and tabs. For example changeset r47676 "code layout fixes with indent" only adds another tabs which are mixed with spaces. Here is a part of file worker.c (http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.li/r.li.daemon/worker.c): {{{ (tab)case FCELL_TYPE:{ (tab)(tab)for (i = 0; i &lt; ad-&gt;rl - used; i++) { (tab)(tab)(4spaces)fm-&gt;cache[used + i] = Rast_allocate_f_buf(); (tab)(tab)} (tab)(4spaces)} }}} Here is minimal working example which produces badly intended source code (GRASS indent script, tested on Ubuntu 10.04 with GNU indent 2.2.10). {{{ // file test.c void test() { int a,b,i; a =5; if ( a==5 ){ for (i = 0; i &lt; 10; i++) { b++; } b= b*10; } } }}} {{{ ./tools/grass_indent.sh test.c }}} {{{ // file test.c void test() { (4spaces)int a, b, i; (4spaces)a = 5; (4spaces)if (a == 5) { (tab)for (i = 0; i &lt; 10; i++) { (tab)(4spaces)b++; (tab)} (tab)b = b * 10; (4spaces)} } }}} </pre> GRASS GIS 2012-05-25T08:20:23 http://comments.gmane.org/gmane.comp.gis.grass.devel/47886 <pre>#1662: Caching bug in 3D raster library with large data -------------------------------------+-------------------------------------- Reporter: huhabla | Owner: grass-dev&lt; at &gt;… Type: defect | Status: new Priority: critical | Milestone: 7.0.0 Component: Raster3D | Version: svn-trunk Keywords: 3D raster, tiles, cache | Platform: Linux Cpu: x86-32 | -------------------------------------+-------------------------------------- There is a strange bug that appeared on an Intel Atom netbook while converting a list of raster maps into a 3D raster map. Operating system is a 32 Bit Ubuntu linux: {{{ GRASS 7.0.svn (etopo_epsg4326): t.rast.to.rast3 input=temptest output=temptest 100% Creating 3D raster map ERROR: Rast3d_cache_hash_remove_name: name not in hashtable ERROR: Unable to create raster3d map &lt;temptest&gt; GRASS 7.0.svn (etopo_epsg4326): g.region -p3 projection: 3 (Latitude-Longitude) zone: 0 datum: wgs84 ellipsoid: wgs84 north: 90N south: 90S west: 180W east: 180E top: 20.00000000 bottom: 0.00000000 nsres: 0:02 nsres3: 0:02 ewres: 0:02 ewres3: 0:02 tbres: 1 rows: 5400 rows3: 5400 cols: 10800 cols3: 10800 depths: 20 cells: 58320000 cells3: 1166400000 }}} I can not reproduce this bug on my 64Bit machine, since i have no 32Bit Linux available, it would be great if somebody with a 32Bit Linux can reproduce this. Best Soeren </pre> GRASS GIS 2012-05-25T07:59:31 http://comments.gmane.org/gmane.comp.gis.grass.devel/47882 <pre>Hi, Thanks everyone for the nice greetings, I'm very impressed with how polite and helpful the GRASS community is. There is a wiki [1] and source code repository [2] for the Image Segmentation - Google Summer of Code project. The mentors for the project have already provided a lot of advice, if there is anyone else with an interest in segmentation you are welcome to add to the Specifications or other areas of the wiki. For the "code" I have started an outline, but I think there are still too many questions to call it pseudocode yet!. Many of the questions are for myself to research and answer. Of course, I welcome input and suggestions for all of it, but some of the bigger questions are: 1. How to best deal with images that are larger then available memory. (I assume too much disk I/O would be slow, but simple tiling could lead to poor segmentation at the tile borders.) 2. How to find neighbors. (Is this already available somewhere in GRASS?) 3. Would any functions would be useful as a general library function. 4. If library functions are already available for any steps. I saw GSoC is on the agenda for the Sprint, if it would be helpful (and isn't too early in the day!) I can join by Google video / IRC / etc. Regards, Eric [1] http://grass.osgeo.org/wiki/GRASS_GSoC_2012_Image_Segmentation [2] https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.segment _______________________________________________ grass-dev mailing list grass-dev&lt; at &gt;lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev</pre> Eric Momsen 2012-05-24T17:29:29 http://comments.gmane.org/gmane.comp.gis.grass.devel/47876 <pre>Periodically, there are complaints about 'screen clutter' with GRASS. I realized yesterday that a big cause of this is that each time a module is called, a new instance of its dialog opens. So if you use v.buffer but don't close the dialog, and then call v.buffer again GRASS opens a second v.buffer dialog...and a third and a fourth, etc. So there seems to be the need to have the wxPython parser module to just bring the window for a module to the front if it is already open instead of opening another instance. Sounds simple but is probably somewhat complicated of course. But it would help the clutter problem a great deal. Michael _____________________ C. Michael Barton Visiting Scientist, Integrated Science Program National Center for Atmospheric Research &amp; University Consortium for Atmospheric Research 303-497-2889 (voice) Director, Center for Social Dynamics &amp; Complexity Professor of Anthropology, School of Human Evolution &amp; Social Change Arizona State University www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu _______________________________________________ grass-dev mailing list grass-dev&lt; at &gt;lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev</pre> Michael Barton 2012-05-24T10:19:39 http://comments.gmane.org/gmane.comp.gis.grass.devel/47875 <pre>There is a "stop" button in the GUI of all modules. When I press it, the GUI dialog returns to a state where I can reinitiate the module process. But looking in my system monitor, the old process is still continuing. Is this the case for all systems or just the Mac? If for all systems, the "stop" button seems somewhat misleading. Michael _____________________ C. Michael Barton Visiting Scientist, Integrated Science Program National Center for Atmospheric Research &amp; University Consortium for Atmospheric Research 303-497-2889 (voice) Director, Center for Social Dynamics &amp; Complexity Professor of Anthropology, School of Human Evolution &amp; Social Change Arizona State University www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu&lt;http://csdc.asu.edu/&gt; _______________________________________________ grass-dev mailing list grass-dev&lt; at &gt;lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev</pre> Michael Barton 2012-05-24T08:04:13 http://comments.gmane.org/gmane.comp.gis.grass.devel/47873 <pre>#1661: Wish: port the new wxgui histogram plotting tool from grass7 to grass6 -------------------------+-------------------------------------------------- Reporter: mlennert | Owner: grass-dev&lt; at &gt;… Type: enhancement | Status: new Priority: normal | Milestone: 6.4.3 Component: wxGUI | Version: unspecified Keywords: histogram | Platform: Unspecified Cpu: Unspecified | -------------------------+-------------------------------------------------- Michael's wxgui histogram tool in trunk is _very_ nice and useful. Any chance that this could be backported to the grass6 line ? Moritz </pre> GRASS GIS 2012-05-23T14:56:18 http://comments.gmane.org/gmane.comp.gis.grass.devel/47872 <pre>So the values for point to line distances are just as bad in GRASS 6.4.2 as they are in GRASS 7. Any suggestions on how to get this information for a latlon region? Michael _____________________ C. Michael Barton Visiting Scientist, Integrated Science Program National Center for Atmospheric Research &amp; University Consortium for Atmospheric Research 303-497-2889 (voice) Director, Center for Social Dynamics &amp; Complexity Professor of Anthropology, School of Human Evolution &amp; Social Change Arizona State University www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu _______________________________________________ grass-dev mailing list grass-dev&lt; at &gt;lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev</pre> Michael Barton 2012-05-23T14:48:37 http://comments.gmane.org/gmane.comp.gis.grass.devel/47871 <pre>Forgot to mention that the table selection pull-downs do not work in any version of the v.distance GUI--from 6.4.2 to 7.0 Michael _____________________ C. Michael Barton Visiting Scientist, Integrated Science Program National Center for Atmospheric Research &amp; University Consortium for Atmospheric Research 303-497-2889 (voice) Director, Center for Social Dynamics &amp; Complexity Professor of Anthropology, School of Human Evolution &amp; Social Change Arizona State University www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu _______________________________________________ grass-dev mailing list grass-dev&lt; at &gt;lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev</pre> Michael Barton 2012-05-23T14:47:08 http://comments.gmane.org/gmane.comp.gis.grass.devel/47870 <pre>Hi, I don't use the vector modules a lot and so they don't get a lot of testing from me. I'm trying to do a project with someone that uses vector module and I find that some key things are broken. The following apply to GRASS 7 and GRASS 6.4.3. 1) v.distance gives bogus results for point to line distance uploads in a latlon region. For example, the distance uploaded from one site point to the nearest waterway is 5767967.05475, yet measuring this with the distance tool gives a much more reasonable 33211 m. The uploaded distance is off by an order of 173X -- an enormous error. Nothing in the docs says that you cannot use v.distance with latlon regions. 2) To get around this, I thought I'd try to get the length of the line that connects each site point with its nearest waterway (a v.distance option). But when I tried to make a new table for this in the table manager, I find that I cannot access the "table description" section of the "manage layers" page in the attribute table manager. This is again because wx.StaticBox needs to be defined in a particular order or the Mac interface cannot access it. This has been a recurrent problem with wx.StaticBox. The StaticBox must be instantiated before any of its contents. 3) After creating a linked table using v.db.addtable instead of the attribute manager, I tried to modify the layer in the attribute table manager, but only received a message that "&lt;flag&gt; is not a valid value". Another bug. I did manage to get a length value into the lines connecting the points and they are quite reasonable values. But of course I have no way that I can see to link the distance lines back to the points from which they were created with v.distance. So I still don't have analysis results and my colleague is ready to try this in ArcGIS. Any suggestion for a workaround would be much appreciated. And of course, the multiple bugs here need to be fixed. Michael _____________________ C. Michael Barton Visiting Scientist, Integrated Science Program National Center for Atmospheric Research &amp; University Consortium for Atmospheric Research 303-497-2889 (voice) Director, Center for Social Dynamics &amp; Complexity Professor of Anthropology, School of Human Evolution &amp; Social Change Arizona State University www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu _______________________________________________ grass-dev mailing list grass-dev&lt; at &gt;lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev</pre> Michael Barton 2012-05-23T14:43:11 http://comments.gmane.org/gmane.comp.gis.grass.devel/47868 <pre>Hi, as Anne noted in her Hello World message*, the Summer of Code has just begun. [*] http://lists.osgeo.org/pipermail/soc/2012-May/001734.html In case you missed the selection efforts, GRASS was funded for 3 projects this year. They are: (see the wiki for detailed links) http://grass.osgeo.org/wiki/GRASS_SoC_Ideas_2012#Accepted_Ideas 1. Python high level map interaction for GRASS GIS (abstract) Student: Pietro Zambelli Mentor: Sören Gebbert Backup mentors: Luca Delucchi, Martin Landa Wiki page: GRASS SoC Ideas 2012/High level map interaction H:--- pythonize the grass py libs; the wiki page demonstrates the idea well 2. GRASS GIS WxGui front end for vector analysis modules (abstract) Student: Stepan Turek Mentor: Martin Landa Backup mentor: Markus Metz Wiki page: GRASS GSoC 2012 WxGUI front end for vector analysis modules H:--- interactive v.net gui app (d.path^2, dynamically redraw network paths+) 3. Image Segmentation in GRASS GIS (abstract) Student: Eric Momsen Mentor: Markus Metz Backup mentors: Moritz Lennert, Pierre Roudier Wiki page: GRASS GSoC 2012 Image Segmentation H:--- advanced image classification &amp; clumping techniques Please (everyone!) read through the abstracts &amp; proposals and get a feeling for what's been planned for the next few months. The students will be posting weekly updates here to keep you informed, but all 3 projects are all ambitious, and all will need all of our help to succeed! This is not a "consume" exercise, the student does the coding but it's supposed to be a collaborative process with all of us helping out. The more we put in to the students, the more we get out of them. do I make my point? :) I hope that those meeting for the upcoming Code Sprint can take some time to go through each of the proposals in a detailed way, and take the opportunity to discuss the path the student should take/brainstorm as a group. (No point in them spending all summer working on a project which has no developer buy-in at the end because we devs communicated poorly our wants ..) I'll try to be available via IRC as the GMT+12 timezone &amp; work allows. So Stepan, Pietro, and Eric, a big welcome! I hope you have fun here. There are some really talented coders on this list who know the codebase top to bottom and can help you out night or day. Any questions just drop an email or five. cheers, Hamish (OSGeo SoC co-admin) </pre> Hamish 2012-05-22T11:27:58 http://comments.gmane.org/gmane.comp.gis.grass.devel/47853 <pre>Hi, before any work begins on this in earnest at the code sprint, I'd just like to reiterate my take on the toolbox idea. i.e., (and insofar as I understand the proposal as it exists!) any move towards splitting up GRASS's build system and distribution package(s) would be a really really huge mistake. I would like to offer an alternate proposal which solves the same "new user confronted with an overwhelming 747 cockpit of controls" problem, but which does not splinter the core software. Namely, implement "views" in the wxGUI preferences section, with tick boxes where you can hide or show groups of modules as desired. A core set of common modules would always be ticked in a greyed-out box, and an "enable all" button would be present. Beyond that you can pick and choose. As our use cases vary widely, simply breaking up into "Core, Beginner, Advanced" is too simplistic, and rather a grouping based on keyword clusters (e.g. "remote sensing", "terrain analysis", ...) would be more useful.. anyway, this needs to be discussed well before doing anything radical. the problems as I understand people see them: * As a by product of GRASS's enormous number of modules, the discoverability and perceived learning curve can be a bit overwhelming to new users. * Even as an advanced user, when you try to find something in the menus there is a lot of scrolling past modules you don't use (e.g. for me, wildfire modeling) which slows you down. Both fair enough points, and hopefully with things like the wxGUI module search tool, the module synopsis PDF, and optional "views" of the menu tree we can go a long way to solving that. [*] n.b. I'd still like to split the d.vect GUI button up into simpler components (see d.stations, d.varea wrapper shortcuts in addons svn for an idea of what I mean), in addition to the "kitchen sink" advanced/full control access to the real module. One of the major benefits of GRASS compared to other kitchen-sink GIS is that you DON'T have to mess around with installing toolboxes. Every- thing you need is there already. We tend to take this for granted, but it is a huge plus in our favour. I came to GRASS after fighting for years with installing additional Matlab and Arc toolboxes, and GRASS was a huge breath of fresh air not to have to deal with that any more. (and this problem hasn't gotten any better, I still have to deal with and despise dongles and flexlm for proprietary toolboxes, and even without having to deal with those there is always the DDL-hell, 32/64bit versions, and missing libraries to deal with.. argh! &amp; yay pre-packaged everythings!) In addition to that, I (and I suspect many of our users) spend a lot of time out in the field, days away from any internet connection. Even the most robust "Click here to install the missing component" just doesn't work out there. Any often in the field you have to develop workflows on the fly, so you can't really know what you'll need until you get out there and the data starts coming in. And even when you think you've prepared everything you could possibly need, the one thing you can be sure of is that you haven't. I know for me, the "already there" availability of GRASS modules well outside the normal ones used in the common toolset/workflow of my field of study has helped my career and my personal understanding as a geoscientist enormously. It's the nexus of an interdisciplinary approach with different folks from different fields all repurposing the same tools for different ends and from different POVs. I think it is another thing we sort of take as normal around here, but really it is an incredibly valuable and rare thing, and should be jealously guarded with long ranting emails. * Another argument given: The the base installer is too big. Just to look at the (soon) Debian 64 bit package sizes: 15K grass_6.4.2-1_all.deb Meta-package, depending and recommending the rest 11M grass-core_6.4.2-1_amd64.deb The C, Python, and Shell libraries and modules 6.3M grass-doc_6.4.2-1_all.deb The man pages and help page images 2.3M grass-gui_6.4.2-1_amd64.deb The two Tcl/Tk GUIs, the WxPython GUI, NVIZ, xganim, etc 212K grass-dev_6.4.2-1_amd64.deb The header and build files needed to build GRASS modules 25M grass-dev-doc_6.4.2-1_all.deb The GRASS Programmer's manual So a typical install is under 20MB. This is incredibly small!, and no problem even over slow/broken/expensive internet like we have down here in the southern south Pacific. Add max dependency software and you approach the size of the MS Windows installer, 60MB. Still not so bad considering the commercial alternatives come on DVDs and want gigabytes. In short, the disk space / download-time argument is a non-issue. GRASS is smaller than the onboard-video driver download for my new motherboard. Users are more harmed by having to download (e.g.) six different files than they are by having to download a single larger file, which possibly contains some components which will go unused. One final concern is that by relegating modules seldom used by the dev team into what would essentially be second class toolboxes, those modules will wither and die, and our more outside-of-the-mainstream users will suffer for it. --- We have a great position catering to niche users who are not served by the other mainstream offerings. nurture them well! So keep all modules installed, just give an option to focus the menus on the relevant "toolkit(s)" of your choice. comments? criticisms! both most welcome.. united we stand, divided we fall, Hamish </pre> Hamish 2012-05-20T01:51:20 http://comments.gmane.org/gmane.comp.gis.grass.devel/47849 <pre>#1660: RFE: add new batch= command line option to main grass7 startup script -----------------------------+---------------------------------------------- Reporter: hamish | Owner: grass-dev&lt; at &gt;… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: Startup | Version: svn-trunk Keywords: GRASS_BATCH_JOB | Platform: All Cpu: All | -----------------------------+---------------------------------------------- Hi, to make running GRASS_BATCH_JOBs a bit easier to use (and to avoid the common :-) mistake of not `unset`ing it after), it would be nice if the main grass7 startup script could parse the command line argv[] options for batch=, check that the script exists and is executable, then use it instead of looking for a GRASS_BATCH_JOB enviro variable? perhaps with that done GRASS_BATCH_JOB could be retired for GRASS 7.0? (or would there still be some reason to keep it as an alternate method?) thanks, Hamish </pre> GRASS GIS 2012-05-19T03:24:36 http://comments.gmane.org/gmane.comp.gis.grass.devel/47848 <pre>Hi there I would like to contribute a script that I have used in my research to the broader field. The script carries out linear regression, except that rather than using two rasters for the x and y variables, it uses any number of pairs of rasters, allowing the regression to be carried out across a time series, resulting in a slope, intercept and R^2 values for each pixel. The crunch is that it is written in perl, as this is what I know best and it serves me well. I have done my best to conform to the stated standards, and I have produced a fairly detailed manual page. This will give you a better idea of what the script does, with examples. I attach the script and html here. I hope that you will consider making it available to others. Here at James Cook University, by the way, we are encouraging a switch from problematic and costly proprietary software to GRASS GIS. I am a major fan of GRASS, particularly on a Linux platform, and I am pleased that more and more students are listening. You should see a sharp rise in its use here in Queensland in the near future. Thanks Damien O'Grady _______________________________________________ grass-dev mailing list grass-dev&lt; at &gt;lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev</pre> Damien O'Grady 2012-05-18T23:45:09 http://comments.gmane.org/gmane.comp.gis.grass.devel/47845 <pre>#1659: v.net.salesman - add cat to node error output -------------------------+-------------------------------------------------- Reporter: gfleming | Owner: grass-dev&lt; at &gt;… Type: enhancement | Status: new Priority: normal | Milestone: 6.4.3 Component: Default | Version: unspecified Keywords: | Platform: Unspecified Cpu: Unspecified | -------------------------+-------------------------------------------------- When graph creation fails like this: ERROR: Destination node [56802] is unreachable from node [56811] It would be really useful to know the cats of the offending nodes, not just their internal DGlib node ids. This would help find the error in the network. </pre> GRASS GIS 2012-05-17T08:17:16 http://comments.gmane.org/gmane.comp.gis.grass.devel/47841 <pre>Dear all, JFYI i have added a new module called "r3.out.netcdf" to GRASS 7 that allows the export of 3D raster maps as NetCDF files. A special feature is that the vertical units time and space are supported, hence the export of space time voxel cubes is now possible. I have added NetCDF build support to the configure script, as r3.out.netcdf needs the NetCDF library to run. The Makefile variables NETCDFLIBS and NETCDFCFLAGS can now be used to link the NetCDF library to GRASS 7 modules. Best regards Soeren </pre> Sören Gebbert 2012-05-16T22:09:40 http://comments.gmane.org/gmane.comp.gis.grass.devel/47839 <pre>#1658: g.rename, g.copy do not ask for --overwrite, they just do it -----------------------------------------+---------------------------------- Reporter: hamish | Owner: grass-dev&lt; at &gt;… Type: defect | Status: new Priority: major | Milestone: 6.5.0 Component: Default | Version: svn-develbranch6 Keywords: g.rename, g.copy, overwrite | Platform: Linux Cpu: x86-64 | -----------------------------------------+---------------------------------- Hi, discovered in devbr6, but may happen in other branches too: {{{ G65&gt; r.mapcalc one=1 100% G65&gt; r.mapcalc two=2 100% G65&gt; g.rename one,two Rename raster &lt;one&gt; to &lt;two&gt; G65&gt; r.info -r two min=1 max=1 G65&gt; echo $GRASS_OVERWRITE G65&gt; r.mapcalc three=3 100% G65&gt; g.copy three,two Copy raster &lt;three&lt; at &gt;user1&gt; to current mapset as &lt;two&gt; G65&gt; r.info -r two min=3 max=3 }}} I just lost a map :-( Hamish </pre> GRASS GIS 2012-05-16T20:43:08 http://comments.gmane.org/gmane.comp.gis.grass.devel/47838 <pre>I am observing corrupted output from r.mapcalc in trunk if compiled --with-pthread. The result is not identical to the one obtained --without-pthread. The mapcalc expression included the functions eval(), min(), and max(), in case that helps. Open a ticket? Markus M </pre> Markus Metz 2012-05-16T16:01:02 http://comments.gmane.org/gmane.comp.gis.grass.devel/47832 <pre>Dear all, i would like to add a new configure option to enable NetCDF support in GRASS7. The new module r3.out.netcdf that exports 3d raster maps as three dimensional (space or space + time) NetCDF files and several other planed modules will need this library. My question is how to integrate NetCDF in the configuration process? I have patched the files "configure.in" and "Platform.make.in". Do i need to modify any additional files? How should i generate the configure script with autoconf, so that it is compatible with the current configure script? The "configure.in" and "Platform.make.in" patch is attached. Many thanks in advance. Best regards Soeren _______________________________________________ grass-dev mailing list grass-dev&lt; at &gt;lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev</pre> Sören Gebbert 2012-05-16T08:58:03 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.gis.grass.devel